Re: Considering teaching plumbing to users harmful

"Avery Pennarun" <apenwarr@gmail.com> writes:

If you are advocating that mode of operation to be easy in git, you should think again. That pull (be it with or without --rebase) can conflict and you would need to resolve it, and then your "stash pop" can conflict again. You can have your own "git avery-up" alias which is your "svn up" equivalent, but if you train users with that first, the users have to learn how to cope with conflicts in individual steps anyway.

Making these three into a single alias is not an improvement either. If you are not ready to incorporate other's changes to your history, why are you pulling? Being distributed gives the power of working independently and at your own pace. You should train your brain to think about the workflow first. "You should stash before pull" is _not_ a good advice. "Do not pull when you are not ready" is.

Suppose you are about to finish something you have been cooking (say a series of five logical commits), you've made three of these commits already, and what you have in your work tree and the index is to be split into the last two commits. Somehow you learn that $x above has a updated version.

Yes, running "git stash && git pull --rebase && git stash pop" would be better than running "git pull --rebase" alone from that state. But that would mean your history would have your first 3 commits (of 5 commit series), somebody else's totally unrelated commits, and then you will work on finishing the remaining 2 commits on top of it. Why? Why is such a bogus linear history any better?

With git, instead, you have the choice:

	* "git fetch" first to see if it is truly urgent; otherwise you
          don't even have to pull.  First finish whatever you were doing
          and then make the pull

	    $ make commit 1
            $ make commit 2
            $ git pull

	  This results in a merge but it is a good merge.  The resulting
	  history shows your 5 commits are isolated work independently
	  developed while that urgent thing was being done elsewhere.

	* if it is, then, you save away your work and pull first:

	    $ git branch mywork
            $ git stash save "remaining two commits' worth of changes"
            $ git reset --hard HEAD~3 # wipe your 3 commits
            $ git pull

	  and then continue working:

	    $ git checkout mywork
            $ git stash pop
            $ make commit 1
            $ make commit 2

	  and finally integrate:

            $ git checkout master
            $ git merge mywork

	  or if you really want linear, pretend all 5 of your commits
	  were done on top of that urgent thing.

            $ git rebase master
            $ git checkout master
            $ git merge mywork

What you forgot to add in the above is that in svn the equivalent of "pull x y" step will always fast forward because you will not be making forked development with the upstream. In svn it's just "svn up" and it results in a linear history because that command does not work with merges. By definition, not working with merges will result in linear history.