[Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 0f2656669fbdf627a3ddf11bdb72e3ec9cef68fd

[Guillaume Rousse]

David Paleino a écrit :
> On Mon, 30 Mar 2009 23:50:53 +0300, Ville Skyttä wrote:
> 
>> On Monday 30 March 2009, Guillaume Rousse wrote:
>>> Guillaume Rousse a écrit :
>>>> The following commit has been merged in the master branch:
>>>> commit 0924d059c6c845069b10482882c821088ccaeefa
>>>> Merge: 91daa8de58a6e88d5a4b55621e2e7d5e732c65ea
>>>> dc88329e8eea8424f2e1dc7efc50a80e240708c4 Author: Guillaume Rousse
>>>> <guillomovitch at zarb.org>
>>>> Date:   Mon Mar 30 22:02:55 2009 +0200
>>>>
>>>>     Merge branch 'master' into guillomovitch
>>> This seems to be a commit related to my own local branch, I don't
>>> understand why it does generate a mail here... I just hop I don't screw
>>> up anything in master branch.
>> Happened to me too once, I don't claim to understand it either but it didn't 
>> seem to have any bad effects.  The web UI doesn't show any changes the usual 
>> way either, just "Simple merge", just as it did for me as well.
> 
> But "git log" is a mess, and cherry-picking isn't easy.
> 
> What are you guys using? What's your development workflow? There shouldn't be
> any merges in master.
> 
> So log messages like:
> 
> Merge branch 'master' of
> git+ssh://scop-guest@git.debian.org/git/bash-completion/bash-completion
> 
> should'nt really exist, sorry :)
> 
>>> Also, when merging changes from my own branches into master branch,
> 
> Guillaume, first of all, why do you make local branches? :)
Well, because someone told me that was the proper way to work with git :)

I usually work in my local branch, alterning various instance of 
"implement wonderful new feature", "oops", "fix stupid typo", "next time 
i'll test before commiting" hacks. Once ready, I switch to master 
branch, update it, then merge my own changes, and push them upstream.

>>> how can I merge multiples commits into single ones, so as to ditch invalid
>>> intermediate steps ?
> 
> My suggestion is different from what Ville proposes, and cleaner, I believe.
> 
> The trick should be using "-n" in git-cherry-pick. Example:
> 
> mybranch $ [hack] && git commit
> [aaaaaaa] My log
> mybranch $ [hack] && git commit
> [bbbbbbb] My log 2
> master $ git cherry-pick -n aaaaaaa
> master $ git cherry-pick -n bbbbbbb
> master $ git commit
> 
> I never tried this, but should work :P
> 
>> I don't know, but the way I do it is that I clean up my commits locally
>> before pushing them using git commit --amend.  For example:
>>
>> # hack bash_completion
>> git add bash_completion
>> git commit
>>
>> # hack bash_completion more, related to the previous commit
>> git add bash_completion
>> git commit --amend # then edit the commit message if appropriate
>>
>> The result of the above is a clean single local commit.
> 
> Right.
Reading http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html, 
it seems rebase is the correct way to handle this, to reorder/merge patches.

However, I didn't had strictly equivalent files affected by my commits 
here, I couldn't do it.
-- 
BOFH excuse #66:

bit bucket overflow