On Wed, Feb 26, 2014 at 12:19:58PM -0500, Hadriel Kaplan wrote: > > On Feb 26, 2014, at 3:51 AM, Joerg Mayer <jma...@loplof.de> 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 <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
