"Avery Pennarun" <apenwarr@xxxxxxxxx> writes:
> On 7/16/08, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> You said svn makes it easier because it makes it very hard to do merges
>> and forces users to stay away from them. This results in user doing "svn
>> update" which is to resolve conflicts with large uncommitted changes but
>> keeps the history straight single-strand-of-pearls.
>>
>> I am not saying the merge based workflow in git does not have any room to
>> improve. I am just saying that there is nothing we can learn from svn in
>> that area. "Solves it by not letting us to do merges" is not a solution.
>
> What svn does is essentially an unsafe version of
>
> git stash && git pull x y && git stash apply
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
> And that's actually a good example of what I'm talking about; in svn,
> that's just "svn up",...
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
