Git pull --rebase until it hurts

Am I the only one here who's frustrated by this entire discussion? I've a very strong underbelly feeling that we should simply build tooling that make these entire discussions unnecessary.<p>I don't mean a non-sucky CLI for git. I mean something more fundamental, something that connects with common programming workflows so well that we can stop discussing the tool altogether.<p>I'm not sure what that would be, but I hope that one day someone smarter than me will invent it.

Like I said on the other thread, tread carefully friends; there's dogma at work here.<p>Also, take a step back and look at the history of git. Git was created by Linus Torvalds specifically for Linux kernel development. I'd argue that a key reason that the kernel is so successful is because people are able to maintain history as a first-class entity in their project. The idea the you can 'rebase -i' to build up small, neat commits that will almost always apply cleanly to a sane codebase is <i>wonderful</i>. The fact that I don't need extreme foresight to capture my meaningful units of work into individual commits means that years from now I can look back and see what I was actually doing instead of "wait, was that line deleted as part of the feature, or was he just cleaning up warnings?"<p>Remember that these features aren't for developers, they're for maintainers. If you want your code in the kernel, you follow the kernel development process or GTFO. Linus doesn't sit around saying "shucks darn, it didn't merge cleanly, I guess I'll go fix it for them." He just doesn't have the time, and neither do his "deputies."<p>That's not to say that these features don't benefit developers; they do. It's just that you need to have seen them in action to understand why.<p>And finally, I'm genuinely curious... Why are some people so obsessed with <i>perfect</i> preservation of history? Is this some sense of fear/paranoia? In practice I've never found project history to be useful <i>without</i> modification, so what am I missing? What are people trying to preserve?

Maybe I'm projecting, but I think the main point of doing a --rebase on every pull is that if you have upwards of 20 or so developers constantly doing a pull without a rebase, you will have a lot of merge commits that are essentially worthless. Especially because they'll probably just be the default message.<p>So, sure, falling back to the merge when things went wrong is ok and all, but odds are high you should go ahead and relook at all of your commits anyway. (Another thing, doesn't the rebase keep the initial author date? It isn't like the history is completely fabricated at this point.)<p>Of course, I'm a big fan of git rebase -i to do some basic cleanup of your commits before pushing. Leave an excessive amount of log messages in? Rebase them out. Neglect basic documentation since you weren't sure if things were going to change? Rebase them in. Sure, I can sympathise with the "you are messing with history" argument, but I find it challenging to believe that I actually care that you commented last. Or that you actually had a few extra helper classes at some point. etc.

&#62; It’s essentially an anonymous branch. ... Maybe you should have explicitly branched, but hey, we’re all human.<p>This is the real key here. Most don't really want git-merge(1) <i>or</i> git-rebase(1). They want git-go-back-and-extract-my-commits-into-a-topic-branch(1).

Is there any way to track both concepts with Git? The logical commit history, like what rebase will produce, and the physical Git history.<p>The reflog tracks this locally, but is there any way to push it alongside commits centrally so that the people who wish to preserve a physical development commit history can achieve that? I imagine it will work something like: by default, you see the logical history; but if you wish to delve into the physical history (including a history of who ran rebase commands, and when), you could do that.<p>Does this make sense and would it be valuable?

There's another post on the frontpage saying to NOT use rebase.<p>This video comes to mind: <a href="http://www.youtube.com/watch?v=CDeG4S-mJts" rel="nofollow">http://www.youtube.com/watch?v=CDeG4S-mJts</a><p>Git is fast, but it's a clusterfuck of weird command calls and esoteric flags. I kind of miss Mercurial in this regard, but I had to make the switch due to the popularity of Github. Having open source projects is a very nice way to show potential employers that you are a good asset.

This is what recent versions of GitHub for Windows does by default. There are definitely advantages to merge commits, the biggest one being that force-undoing an unwanted merge commit is as straightforward as resetting to the first parent of the merge commit.

I do the same thing really, because I'm lazy, it's easy, and it usually doesn't make much difference to how I'm using git. However, different strokes for different folks.

Sounds like the workflow of a developer working by himself.<p>I have 40 developers working in my company, all doing pull --rebase, I even blocked trivial merges on the server itself (see my answer at <a href="http://stackoverflow.com/a/8936474/258689" rel="nofollow">http://stackoverflow.com/a/8936474/258689</a>)<p>Laziness is only acceptable when you work alone.<p>If you are curious, check out this project: <a href="https://github.com/orefalo/g2" rel="nofollow">https://github.com/orefalo/g2</a>

You know, we wouldn't even be having this discussion if people just didn't commit work in progress onto their upstream tracking branches in the first place.

The central problem here is neglecting to identify the <i>purpose</i> of branches [1] and a haphazard attitude toward "merging from upstream" [2,3].<p>If you use topic branches for every feature and bug fix, then you can even test them in an integration branch (often called 'next') so that they can interact with other new features before graduating to 'master'. This makes 'master' more stable which is good for users and good for developers because they can be more confident that a bug in their topic branch was introduced in their branch. It is also easier to make releases.<p>Use of a 'next' integration branch also relieves some of the pressure from merging new features. Other developers' _work_ is not affected if 'next' is broken and the merge can be reverted without impacting the history that ultimately makes it into 'master'. Running 'git log --first-parent master' [4] will show only merges, one per feature, and each feature has already been tested in 'next', interacting with everything in 'master' as well as other new features. See gitworkflows(7) [5] for more on 'master'/'next'.<p>If we acknowledge that 'master' (and possibly 'next') are only for integration, then we don't have the problem of 'git pull' creating a funny merge commit because we're developing in a topic branch, but the same behavior occurs when we run 'git merge master' (or 'git pull origin master'). This is a merge from upstream and usually brings a lot of code that we don't understand into our branch. These "just keeping current" commits annoy Linus [2,3] because they do not advance the purpose of the topic branch ("to complete feature/bugfix X so that it can be merged to 'master'"). Linus' short and sweet rule of thumb [3] is<p><pre><code> If you cannot explain what and why you merged, you probably shouldn't be merging. </code></pre> We can usually only explain a merge from upstream when we (a) merge a known stable point like a release or (b) merge because of a specific conflict/interaction, in which case that should go into the merge commit. If you use 'git merge --log', merges from topic branches contain a nice summary while merges from upstream usually have hundreds or thousands of commits that are unrelated to the purpose of your branch.<p>[1] <a href="http://gitster.livejournal.com/42247.html" rel="nofollow">http://gitster.livejournal.com/42247.html</a> (Junio Hamano: Fun with merges and purposes of branches)<p>[2] <a href="http://lwn.net/Articles/328436/" rel="nofollow">http://lwn.net/Articles/328436/</a> (Rebasing and merging: some git best practices)<p>[3] <a href="http://yarchive.net/comp/linux/git_merges_from_upstream.html" rel="nofollow">http://yarchive.net/comp/linux/git_merges_from_upstream.html</a> (Linus Torvalds: Merges from upstream)<p>[4] <a href="http://git-blame.blogspot.com/2012/03/fun-with-first-parent.html" rel="nofollow">http://git-blame.blogspot.com/2012/03/fun-with-first-parent....</a> (Junio Hamano: Fun with --first-parent)<p>[5] <a href="https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html" rel="nofollow">https://www.kernel.org/pub/software/scm/git/docs/gitworkflow...</a>

I'm not a fan of rebasing as it makes for a confusing git history when you are working with Gitflow. I find it much nicer to see the merge bubbles which indicate how features were introduced into a release. Flattening the history makes it tricky to get a clean overview and pick precisely when certain actions were performed.<p>-imo

I usually suggest to change the config to avoid that people forgot the --rebase arguments<p>git config branch.master.rebase true git config branch.develop.rebase true<p>This will make any pull be a pull --rebase on the master/develop

I'm very confused. I work entirely from private feature branches; I use GitHub pull requests to manage merging those into master, but never touch master myself.<p>Does this fit into the above workflow at all, or is it only for those who are working off master or sharing branches with other developers?<p>(I usually follow something approximating this flow: <a href="http://julio-ody.tumblr.com/post/31694093196/working-remotely-with-github" rel="nofollow">http://julio-ody.tumblr.com/post/31694093196/working-remotel...</a>)

I still prefer trunk based development with very frequent commits and a strong test suite. Write 5 lines of code and a test, commit. When everyone is doing this, continuous integration is running and QA is testing continuously most problems get found fast. Merging is easy as well because all the changes are so small. For stability of the system and speed of development this is works pretty well.

Whats so wrong with a merge? Git is made for it. Sometimes things are nonlinear. I prefer to roll-forward anyway instead of rollback.