Re: Considering teaching plumbing to users harmful

From: Stephen Sinclair <radarsat1@gmail.com>
Date: Jul 17, 2008, 03:21 UTC
Message-ID: <9b3e2dc20807162021v30fdedcar6ee104ed6bf4b0a3@mail.gmail.com>
In-Reply-To: <20080716223205.GK2167@mit.edu>

On Wed, Jul 16, 2008 at 6:32 PM, Theodore Tso <tytso@mit.edu> wrote:

Show 12 quoted lines

> 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