On Wed, Jul 16, 2008 at 01:12:53PM -0700, Junio C Hamano wrote:
quoted text
> 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.

What I've found is that some people will take that advice, and other
people won't.  Saying that you are thinking about things the wrong way
doesn't really help for people who have been so ingrained into an old
way of doing things.  Indeed, it can end up sounding very elistist.

So from a pedagogical perspective, what I would probably do is show
them how to replicate svn-up, and explain to them how this script
works:

#!/bin/sh
# git-up

if git diff --quiet && git diff --quiet --cached ; then
	git pull $*
else
	git stash ; git pull $*; git stash pop
fi

And then tell them that if this put this into their path, then "git
up" will work the same way as "svn up" --- but that git has a better
way of doing things, and why it is so.  And then what I would tell
them is that no really, merges are really easy with git, and that even
if they were to rely on the "git up" alias as a crutch, that over time
they would find that there are much more natural, easy, and powerful
ways of doing things.

In general, I find that people are more willing to listen to "we have
a more powerful way of doing things", if you can first give them the
equivalent of the "dumb and stupid" way that they are used to doing
things so they can switch to the new tool right away without too much
of a steep learning curve; they will then switch to the more
advanced/powerful workflows at their own pace.  Other people may have
other pedgogical techniques, but I find mine to work fairly well.

Regards,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html