Re: Considering teaching plumbing to users harmful

"Avery Pennarun" [off-list ref] writes:

On 7/16/08, Junio C Hamano [off-list ref] wrote:

quoted

 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.

On Wed, Jul 16, 2008 at 01:12:53PM -0700, Junio C Hamano wrote:

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

Theodore Tso [off-list ref] writes:

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

Looks good, except:

	if git diff ....; then
		git pull "$@"
	else
        	git stash && git pull "$@" && git stash pop
	fi

to make sure the conflict notices won't be scrolled off by error messages
from the later commands.

Hi

On Wed, Jul 16, 2008 at 5:32 PM, Theodore Tso [off-list ref] wrote:

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

When one has 100 users in a company using a DVCS, you really need some
sort of simplified workflow documented and taught.  Not everyone who
writes code is particularly keen on the vagaries of a VCS' commands.
I know that must be shocking to this audience the GIT list, but it is
very very true.  They don't give a crap what sort of weird command
combination one can pull out of the 100 or so commands when you type
git-<tab> at a bash prompt.  They just want the damn thing to behave
in a somewhat friendly fashion.  They want to check in their code and
get on with software development and not over analyzing how many ways
they can do the same command.   In my experience, what Ted is
suggesting is the only way to handle it.  Most developers just want it
to work and focus on debugging their project.  Never expect your users
to have the same interest as you in VCS.

Sean

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.

That totally mirrors my experience.

Unless you're teaching people totally new to SCM, they're likely to
have experience of something else, and are likely to ask 'but how do I
do xyz'. And sometimes the reply is rather embarrassing, as the new
and powerful way involves 5x as many commands. That's where it gets
the reputation of complexity (when actually it might be more correct
to be a reputation of verbosity).

I tend to actually avoid the commands (porcelain or plumbing) to begin
with, and actually concentrate on the data structures (commits, blobs,
index etc) - then how various people's repos look when you do
particular commands. That way people tend to relax about the many
commands as they can grok that there's probably lots of things you
need to do bit by bit, but that aren't relevant to understand right
now - this seems to help in abstracting away the complexity without
sweeping it under the carpet.

So I pretty much agree. Your set looks good, but I always do fetch and
merge before pull, and also add rebase at the end.

On Wed, Jul 16, 2008 at 6:32 PM, Theodore Tso [off-list ref] wrote:

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

Wouldn't this be confusing if they have a few commits on the local
branch that aren't yet pushed to the remote branch?
They could suddenly have conflicts that have nothing to do with the
working tree, which could throw people off.  Not to mention the
meaningless merges that clutter the gitk display.

I know I was personally pretty confused the first few times this
happened and I had little trapezoidal patterns in gitk showing 2
commits being automerged between the local and remote branches.  This
was before I understood the concepts of local and remote branches.

Perhaps some warning when...

if git diff --quiet origin/master HEAD; then...

Personally I've since learned that git-pull is a command to think
about a little before doing, as opposed to svn up, since you might
have to resolve things you aren't prepared for, and we're trying to
avoid teaching git-reset here.  I've had to untrain myself from using
git-pull, switching to git-fetch/merge more and more often, because I
keep doing stupid 3-commit merges by mistake when I didn't intend to.
Some tracking of what's been pushed and what hasn't is helpful to keep
things in the expected order imho.


Steve

On Thu, Jul 17, 2008 at 4:12 AM, Junio C Hamano [off-list ref] wrote:

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.

Hmm, the first 3 commits are not pushed out, right? So by "rebase",
the history should be first the somebody else's commits
(origin/master), then the first 3 commits, then the remaining 2
commits?:


-- 
Ping Yin