Re: git and rebasing

[Owen Taylor <otaylor redhat com>]

On Fri, 2009-04-10 at 00:36 +0100, Simos Xenitellis wrote:
> On Thu, Apr 9, 2009 at 3:21 PM, Owen Taylor <otaylor redhat com> wrote:
> > On Thu, 2009-04-09 at 00:55 +0100, Simos wrote:
> >> Hi All,
> >>
> >> In my latest push to gtk+, I noticed that I had a "Merge branch
> >> 'master' of ssh://simos git gnome org/git/gtk+" in the commit message.
> >> URL is
> >> http://git.gnome.org/cgit/gtk+/
> >> http://git.gnome.org/cgit/gtk+/commit/?id=fbbbf7a936f891dfc0d7f0e4b78aeefe972d6825
> >>
> >> Obviously, this happened because I committed my change before pulling.
> >> I suspect that this will be quite common once the translation teams
> >> start using git.
> >> I'ld like to figure out the best way to address the issue.
> >>
> >> Shall we instruct people to always
> >> $ git --rebase pull
> >> before they
> >> $ git push
> >
> > To a good approximation 'git pull' is *never* right when pulling from
> > git.gnome.org. Everybody - developers, translators, etc, always should
> > 'git pull --rebase'.
> >
> > The default behavior of 'git pull' is really designed for the case where
> > multiple cooperating developers are merging changes from each other.
> >
> > I'm wondering if I should put a pre-update hook into place that looks
> > for merge commits containing the text:...
> >
> >  Merge branch 'master' of ssh://
> >
> > Since that pretty much always means someone did a 'git pull' and got an
> > extraneous merge commit.
> >
> >> Obviously these two commands are not a single atomic operation, so
> >> there are always chances to get a merge branch.
> >
> > If someone else commits in between, a push won't be allowed (not a fast
> > forward.) Repeating 'git pull --rebase' will fix.
> 
> Reading
> http://wiki.videolan.org/Git#Setting_up_.22git_up.22_.28Tip.29
> there is a tip regarding the rebase issue.
> 
> $ git config --global alias.up "pull --rebase"
> 
> Then, 'git up' updates our local repository (there is no 'git update'
> git command, so it's not conflicting).

This strikes me as a nice shortcut, but I'm not sure that local aliases
improve usability... they just reduce typing.

> In usability terms, I think that "git config --global
> branch.master.rebase true" might work only if there is some
> notification from git.gnome.org when a mistake happens, as in
> 'You have used "git pull" to update your local repository. If you are
> not a maintainer, you normally
> configure once your user account with "git config --global
> branch.master.rebase true" so that all your "git pull"
> commands actually do "git pull --rebase" (the correct way).
> For more, see http://live.gnome.org/GitForGnomeDevelopers
> and http://live.gnome.org/TranslationProject/GitHowTo
> Thanks for developing GNOME.'

I don't think there is any difference between maintainers/developers and
translators here. 

Does this complicate things too much? It may be confusing to have:

 A) aliases that add commands that aren't standard git commands 
    (translator A tells translator B, "Just do a git up" and 
    translator B sees "git: 'up' is not a git-command.")

 B) Magic config settings that change the behavior of git builtins.
    Same problem. Plus, as you noted, it only affects the master
    branch and not stable branches.
    
Since git pull --rebase fixes any previous git pull without the
--rebase, if we can catch problem commits (by looking for bad commit
messages, perhaps), then maybe it's better to just say:

 Merge commit with repository detected. This means you had local changes
 and typed 'git pull' instead of 'git pull --rebase'. You can type 'git
 pull --rebase' now to fix the problem. Then please try 'git push'
 again.

(And maybe a link to a wiki page that explains things and detail tells
how to configure a 'git up' shortcut to save typing. I think this would
be better as a short specific page under
http://live.gnome.org/Git/Help/ )

> Translators will work with either 'master', or the 'gnome-2-xx' branch
> when a string freeze is in place and modules are branched. In the
> latter case, would "git config --global branch.master.rebase true" not
> work (is it only for 'master')?
> 
> Now, regarding the issue when mistakes happen and the user wants,
> without fuss, to revert the local repository
> when they do not mind clearing up all local changes.
> 
> ### A ### Reverting uncommitted changes to tracked files
> git status                    -> show modified files (uncommitted changes!)
> git checkout -f master

This looks fine.

> ### B ### Removing untracked files
> git status      -> show untracked files (uncommitted changes), or
> git clean -n   -> show untracked files (in local repository
> git clean -f     -> remove those untracked files.

Not sure this is worth cluttering people's heads with. If they see
untracked files in git status they can always just remove them however
they normally remove files.

> ### C ### Reverting local commits that where not pushed to git.gnome.org
> git checkout -f master       (shows a number of commits that need to be popped)
> git log origin..master         (shows how many commits have been made,
> with details)
>   and then
> git reset master^               (pop that last commit, repeat as necessary)
>   and finally go though A, B.

git reset master^ is going to leave uncommitted changes. It's normally
used for undoing a commit prior to redoing it. (Though 'git commit
--amend' is better in most cases.) With --hard it will actually discard
the local commit.

(And it's probably better to write HEAD^ rather than master^ since that
will work on any branch)

The simple recipe for "oops, I've screwed up", just make my local copy
of the current branch exactly the same as the upstream 'master' branch
is:

 git reset --hard origin/master

(assumes that the branch you've screwed up is the master branch)

- Owen