Wireshark-dev: Re: [Wireshark-dev] Sample command line workflow with git and gerrit
On Wed, Feb 26, 2014 at 12:19:58PM -0500, Hadriel Kaplan wrote:
>
> 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
> >
> > ?
>
> 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.
Oh, now I understand. Yes, that hit me during my first two changes as well ;-)
I worked on master (which is considered bad practice at least in Gerrit but often
also in git) and then I did more than one (unrelated) commit (which is also frowned
upon from a Gerrit point of view). But after doing that I understood what Guy
wrote about the need to rebase which I had not understood by just reading the
mail exchanges at the time.
> >> - using the pre-commit hook to catch whitespace errors
> >
> > Would it make sense to move the pre-commit hook from gerrit to tools/ ?
>
> 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.
Oops, I mixed up commit.msg and pre-commit - my fault. Thanks for pointing that out!
> >> - squashing commits into one commit to be gerrit'ed
> >
> > ?
>
> This one would take a while to explain. If there were an appropriate wiki page, I'd have put something about that into it. :)
OK, then go ahead and do it - I don't insist on doing the first development in
git :-)
> > 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?
OK, looks like I didn't manage to get my idea across: Do the first stage of
the document in git, the put it into wiki - but I have to admit that this
probably isn't a working idea so doing it directly in wiki looks to be the
right way.
> 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)
Thanks!
Jörg
--
Joerg Mayer <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
