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

[Thomas Vander Stichele]

> > 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 ?

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

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

If these are the correct instructions for each scenario, let me know,
and I'll update the wiki.

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.

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 ?

Thomas

-- 
Secrets... are not my concern.
Keeping them, is.
--
Elisa - future TV today !
http://elisa.fluendo.com/