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
And that's actually a good example of what I'm talking about; in svn,
that's just "svn up", which is a daily operation that's easy and
leaves a clean, linear history. In git, it takes three commands
instead of one (and 'git stash' wasn't anywhere in Dscho's list of
commands he teaches to newbies).
I think there's value in thinking about the relative convenience of
svn's workflow for novice users in their day-to-day lives. Now, in
the case of svn, that "convenience" also leads to novice users blowing
up the local changes in their working copy occasionally, but that's
just an svn *architectural* problem. Git doesn't have that
architectural problem.
To be more concrete: would anyone object to a patch that simply made
'git pull' include the above stash commands (or something like them)
by default, rather than giving up when dirty files would be changed?
Or can we do even better?
Have fun,
Avery
--
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
