[gst-devel] [gst-cvs] gst-python: Merge branch 'bz-577735'

[Edward Hervey]

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 <bilboed at gmail.com>