Re: git and rebasing

[Simos Xenitellis <simos lists googlemail com>]

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).

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.'

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

### 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.

### 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.

Are these OK? Is there a simpler version?

Simos