2

We're a small using Git and all us are new to it. In the month or two that we've used Git and began experimenting with feature branches and release branches, we've run into little spaghetti incidents like this one caused by merge conflicts, etc:

enter image description here

The black line is my development branch. Ignore the red one. You'll see how one single commit has broken away from that development tree and then merged back. Is it possible to clear out some of these old cobwebs by flattening the tree? My head is now about 500+ commits away from this.

I've read that this can be avoided by rebasing instead of merging.

Even though, it's a trivial thing, I'd like to fix this if possible both as a matter of a OCD and clarity.

Thanks.

Mridang Agarwalla
  • 43,201
  • 71
  • 221
  • 382
  • 2
    One of git's great strengths of git is that it accurately records exactly where commits were made and how they were merged in. Are you sure you want to flatten your history? Rewriting 500 commits of accurate history to replace them with a fake history feels wrong to me. – CB Bailey Sep 01 '11 at 13:06
  • I don't know much about rebasing/filtering or whatever is needed to accomplish this. The example I've shown is just one of many that are now scattered across our repo. If there simple way to flatten these, it would be great but other than that if it entails hours of sitting with an text-editor and resolving conflicts, I'd rather skip it. It would be great to clean looking commit tree though, I wouldn't mind deleting the commit itself if possible as quite a few of these haven't had considerable changes. Thanks. – Mridang Agarwalla Sep 01 '11 at 13:14

1 Answers1

5

If you really want to linearize the history after a commit A on the master branch, you could always do:

git checkout master
git rebase A

However, this means that you're rewriting the history of your master branch, so if you do (force-) push this new version, you'll have to brief everyone in your team about how to fetch the new version and reset their master branches to match the rewritten version. Otherwise, people are likely to pull, which will merge the rewritten branch with their existing one, defeating the object of the exercise.

These small divergences typically happen when someone creates a commit on their master branch, but master on the server has moved on in the mean time - this means that when they pull again, a merge commit is required. You can avoid this in the future either by measures like:

  • Encouraging people to use git pull --rebase
  • Telling people to use the branch.<name>.rebase and branch.autosetuprebase config options, so that they don't forget to add the --rebase
  • Adding a hook to the server that refuses pushes of non-linear history

However, personally I don't mind seeing these merges in the history - with a good history viewer it's still very clear what's going on.

Community
  • 1
  • 1
Mark Longair
  • 446,582
  • 72
  • 411
  • 327
  • 2
    If it's 500+ commits away and this is only one of many examples, I'd just leave it as is and use some of Mark's ideas to keep it from happening in the future... rewriting public history is generally not a good idea... – johnny Sep 01 '11 at 13:23
  • Hi Mark, I tried rebasing it and it wasn't easy. I'll just skip it and use the git hooks along with `branch..rebase` and `branch.autosetuprebase` — locally or on the server? What's the difference between the two? (Hopefully I don't get any flak for asking this here). I'm not looking to flatten my feature branch commits as yet. This was only to prevent these non-linear commits. Would i still need to enable these options? Thanks. – Mridang Agarwalla Sep 01 '11 at 14:22
  • These options are described [in the documentation](http://www.kernel.org/pub/software/scm/git/docs/git-config.html#_variables). In short `branch.autosetuprebase` causes `branch..rebase` to be set for newly created branches under certain circumstances. Both of those settings would be applied locally in each developer's repository. The hook should be added to the bare repository that you all push to, so that even if someone hasn't used those settings or forgotten to rebase, attempting to push will fail with a helpful error message. – Mark Longair Sep 01 '11 at 14:31
  • 1
    Although, when git gives you this wonderful gift of the commit graph, I wonder why everyone's so keen to make history linear again ;) – Mark Longair Sep 01 '11 at 14:32
  • It's a problem if every little commit ends up as a "merge" commit, most tools don't prevent beginners from making unnecessary merge commits. – prusswan Jun 10 '13 at 07:44