2014-02-26 18:19 GMT+01:00 Hadriel Kaplan <[email protected]>: > > On Feb 26, 2014, at 3:51 AM, Joerg Mayer <[email protected]> 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 > ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
