Wireshark-dev: Re: [Wireshark-dev] Sample command line workflow with git and gerrit
2014-02-26 18:19 GMT+01:00 Hadriel Kaplan <hadriel.kaplan@xxxxxxxxxx>:
>
> On Feb 26, 2014, at 3:51 AM, Joerg Mayer <jmayer@xxxxxxxxx> wrote:
>
>> On Tue, Feb 25, 2014 at 08:39:37PM -0500, Hadriel Kaplan wrote:
>>
>>> - avoiding merging local branches because a merge commit won't have the change-id and can't/shouldn't be sent up to gerrit
Pushing merge commits for review is usually blocked in Gerrit
configurations, thus it is better to getting used to rebasing.
>>
>> ?
>
> I believe that if you have two local branches, or even a local master and one branch off of it with changes in the other branch, and you do 'git merge ...' to merge from master to the other branch, git will auto-create a commit message about that merge event. But that merge commit message doesn't get hooked by the commit-msg change-id hook, apparently. (which is not a bad thing, just noting it) So now you have a commit message in your git log without a change-id. When you next try to push your branch's changes to gerrit, gerrit will refuse your push because one of the commits being pushed is that merge commit message, which doesn't have a change-id.
>
> That blocked me for a long time, because I couldn't figure out why gerrit was rejecting my push. I tried to see what my machine was pushing, but of course it's over SSH, and the "verbose" option for 'git push' isn't *actually* verbose at all. It took me forever to figure out the merge commit itself didn't have the change-id, was getting pushed, and thus getting rejected. (although that's mostly because it was late at night and I was being an idiot)
>
> Needless to say I now never merge from my local master to my local branches - I only rebase. That's better for wireshark anyway, because the gerrit changes are cherry-picked not merged themselves. So it's not like the history matters, and it would complicate things if everyone's local merges were visible.
>
>
>>> - using the pre-commit hook to catch whitespace errors
>>
>> Would it make sense to move the pre-commit hook from gerrit to tools/ ?
No. It is part of Gerrit.
>
> I'm not sure if we mean the same hook... I wasn't talking about the gerrit pre-commit - I mean the one in your local git repo, under .git/hooks/ called 'pre-commit.sample'. You just remove the '.sample' suffix from the file name, make sure it's executable, and voilà, git refuses to commit if you have whitespace errors.
>
>
>>> - squashing commits into one commit to be gerrit'ed
http://git-scm.com/book/ch6-4.html
>>
>> ?
>
> This one would take a while to explain. If there were an appropriate wiki page, I'd have put something about that into it. :)
>
>
>> How about the following:
>> - Decide on a list of workflows to document.
>> - Create a single tutorials document in git that contains command line
>> stuff only (see below)
>> - Have everyone work on that single document and fill it with these examples
>> (each example should cover the complete workflow).
>
> I'm fine with whatever... though I really think workflow-type things shouldn't be tracked in releases. Will we backport future workflow doc changes into all previous release branches too?
Yes, this makes no sense. The work-flow should be changed
independently from the product it is used for.
We really should not put every good-to-have thing in the source base.
Cheers,
Balint
>
> As an aside: at my day job we don't use git, but we have similar problems with source-controlled things that have a different lifecycle than individual releases, but which the individual release needs to compile with. For example MIBs/OIDs, or home-grown tools used during building/compilation. We don't want to keep back-porting/merging them allover, so we put them in their own projects, and have our main code project/branch point to those other projects. That way one change in the tools project, for example, is seen/used by all code branches. But that's way overkill for this one workflow doc. (it might make sense for enterprise numbers in wireshark, however)
>
> -hadriel
>
