From: Edward H. <bi...@gm...> - 2009-04-16 10:49:21
|
On Thu, 2009-04-16 at 12:32 +0200, Thomas Vander Stichele wrote: > > > I did exactly that, asking for help as I did so to thaytan and ds. > > > Thaytan said on IRC that the commit looked fine to him. AFAICT the > > > commit looks like a single commit; the URL shows it as such. Feel free > > > to explain to me how I can see from that URL that I did it wrong. > > > > > > By the way, I did *exactly* what you said in your last 'telling off' > > > mail: > > > > > > * git rebase master > > > * git checkout master > > > * git merge whatever > > > > > > > That should have produced a fast-forward merge (i.e. without a merge > > commit). > > What might have happened (I cannot tell for sure from my history) is > that I was already on the master branch when entering these commands. > Would that explain the commit history ? Yes, that would most likely be the reason for those (causing the branch you want to merge to not be rebased). > > > > > What I see in giggle lets me believe you did: > > * git merge master (onto your bz-577735 branch) (as opposed to git > > rebase master) > > I definately did that at some point (it's also not clear to me why that > is wrong), but not yesterday before commiting. Ah, well use it before committing and pushing then. Doing it early on doesn't help in this scenario (but still, it does give you a nice graphical view). > > > * git checkout master > > * git merge bz-577735 > > > > I just rechecked with the branches at the following status: > > * bz-577735 : f99e67aa24878d26dbd7f494f310bb466c5bd1cd > > * master : bbedab4e6521fe7c813f23698fe650203b1d0820 > > And if you do the commands mentionned above or in the wiki... it does > > a fast-forward merge. > > > > > > > So if something is missing from this list, feel free to let me know, and > > > document it somewhere publically so people have something to look at > > > when they are really trying to do the right thing. > > > > I think http://gstreamer.freedesktop.org/wiki/GitDeveloperGuidelines > > already has the needed information (see Merging branches and the first > > line of Pushing changes), and virtually nobody seems to do it wrong in > > those regards except in very rare occasions (most of them being the > > first time people use git). > > I think those instructions are very unclear. Actual commands would be > helpful. > > For example: > > avoid 'merge commits': > * rebase your branch to master before merging it into master: > - git checkout branch > - git rebase master > - git checkout master > - git merge branch > * or do git rebase origin/master on master after merging - this > should get rid of any merge commits: > - git checkout master > - git merge branch > - git rebase origin/master > > * you might also want to use git pull --rebase instead of git pull > > This last point seems out of place here; I have no idea at what point I > would be doing either a git pull or git pull --rebase. git pull is the shortcut for: * git fetch * git merge Whereas git pull --rebase is the shortcut for: * git fetch * git rebase The remote branch (origin/master) after git fetch is no different than a local branch. > > If these are the correct instructions for each scenario, let me know, > and I'll update the wiki. Yes, those instructions are perfect and indeed clearer. > > Finally, some explanation on how to verify the push you're about to do > would be helpful. > > git push --dry-run is unhelpful to me - it doesn't show me what's about > to go in. > gitk can be confusing too if you don't understand all the UI bits. > A simple command that would say 'here are the x commits you are about to > push, plus their commit messages, plus their content' would be awesome. > I'm sure it's in there somewhere. Before pushing, do a 'git-log origin/master..' (showing you all the new commits that aren't in the remote master). If you see a 'Merge ...' commit message, you should rebase before pushing. > > Lastly, it sounds to me that, if we don't want non-fast-forward-merge > commits to happen, the tools should just not allow you to, no ? If we > can make sure people don't commit wrongly indented code, why can't we > make sure they don't do > random-abracadabra-screwup-that-git-allows-but-we-don't-want ? Because we *sometime* require non-fast-forward merges. There's a good article in today's (pay-for) LWN regarding git merge/rebase including comments by Linus about this. > > Thomas > -- Edward Hervey <bi...@gm...> |