On Thu, Apr 9, 2009 at 3:21 PM, Owen Taylor <[email protected]> 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://[email protected]/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 _______________________________________________ gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
