Re: [Wireshark-dev] Quick start instructions for Gerrit
Thanks for the information, it is very useful. I am a bit confused though. Am I understanding correctly that every open review must be rebased after one is landed in master? This is order of n^2 rebases to land n revisions, which really doesn't scale. What am I missing? Thanks, Evan On 2013-09-18, at 8:52 PM, Marc Petit-Huguenin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Thess quick start instructions assume that you know about git, that you > already have an ssh key pair configured and that ssh and git are installed on > your computer. Note that the email configured in git must match the email > that you used in the Gerrit configuration. > > First step is to clone the Wireshark repository, which need to be done only > one time: > > - - Start by creating a new account in Gerrit by going to the > http://test.code.wireshark.org/review/ page, and clicking of the Register > link, on the top right. > > - - Here the simplest is to use an existing Google or Yahoo ID. Just follow > the > instructions until you are back on the test.code.wireshark.org site. > > - - On the page, choose a username and save it. Copy the content of your ssh > public key (~/.ssh/id_rsa.pub) and add it, then click continue. You are done > for now with the web interface. > > - - Go to your command line and enter the following command (replacing > by the user name you entered in the web page): > > git clone > ssh://@test.code.wireshark.org:29418/wireshark-review-sandbox > > - - After it is done (it will take a minute of so), install the change-id hook > with the following commands: > > cd wireshark-review-sandbox > scp -p -P 29418 @test.code.wireshark.org:hooks/commit-msg > .git/hooks/ > > - - Finally install a shortcut to push patchsets: > > git config --add remote.origin.push HEAD:refs/for/master > > > After this, you can prepare your first patchset. One of the essential rule is > that you *never*, *ever* work in the master branch. This branch must be > considered read-only. So to create a patchset, you need first to create a > topic branch. I personally always name a topic branch so it ends with the > name of the branch onto which the patchset will be merged, so in this case, > - -master: > > git checkout -b first-patchset-master > > This will create a new branch (from the tip of the master branch) and switch > to it (you can list your branches with "git branch") > > Now you can do all your modifications. When you are done, you need to commit > them. The simplest is this command: > > git commit -a > > Note that git will ask you for a commit message, which is as important as the > modified code itself. The usage if to have a title of no more than 50 > characters, an empty line, then an explanation on the commit itself. > > After the modifications are committed you can review the commit with "git log > - -p". Note that a field name "Change-ID" was automatically added. This is > the > magic that will glue multiple revisions of the same patchset, do not modify > it. If everything looks fine, you can push it with the following command: > > git push > > And that's it, congratulations, your first patchset is ready for review, and > you can see it on the website, by clicking on My|Changes. > > Obviously some patchsets will probably be merged in the master branch before > your patchset is reviewed and merged, so you will need to rebase it. First to > need to switch back to the master branch and to pull all the new > modifications: > > git checkout master > git pull > > If you followed the rule above (never work on the master branch), there should > not be any conflicts when running the "git pull" command. The next step is to > rebase your patchset: > > git rebase master first-patchset-master > > There may be conflicts at this time. Resolve them, do a "git add" of the > modified files and then finish the rebase with the following command with the > following command: > > git rebase --continue > > (you may have to do that multiple times) > > It may be a good time to do the modifications that were requested by your > reviewers: apply then then amend the existing commit (do not add a new > commit, you want a clean history, not a catalog of your mistakes): > > git commit --amend -a > > Then push again your patchset: > > git push > > The new patchset will appear on the web page in parallel to the previous > patchset, where it can be reviewed again and eventually merged into master. > > After your patchset is merged into master, do a pull and a rebase again of > your (now useless) branch. If everything went well, you should be able to > safely delete the topic branch with this command (the branch will not be > deleted if it was not completely merged): > > git checkout master > git branch -d first-patchset-master > > Enjoy! > > - -- > Marc Petit-Huguenin > Email: m...@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/i
Re: [Wireshark-dev] Quick start instructions for Gerrit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/19/2013 07:02 AM, Evan Huus wrote: > Thanks for the information, it is very useful. I am a bit confused though. > Am I understanding correctly that every open review must be rebased after > one is landed in master? This is order of n^2 rebases to land n revisions, > which really doesn't scale. What am I missing? Theoretically yes, but in real world no. First, you do not rebase after each review is merged but periodically, keeping in mind that the longer you wait, the more conflicts you may have to resolve. On the other hand rebasing too often means that if you upload a new patchset each time, this will make things confusing for the reviewers (who will have to redo their review each time) Also, the rebase can also be done directly on Gerrit, for example before a patchset is submitted to the master branch. If there is a conflict, the submitter will ask the author of the patch to rebase and resubmit. So I think that the most efficient model is to do this for each topic branch: 1. Before starting a work session, rebase your branch. Then do the modifications requested by the reviewers, amend your patchset and push it. 2. If the submitter asked you to rebase, rebase, resolve the conflicts and push the patchset. This minimize the number of patchsets submitted for review, at the expense of slowing down from time to time the patchset cycle when a last rebase/resolve conflict is needed before the merge in master. Personally I like to start my day of work with a pull and a round of rebase in all my topic branches, as I keep forgetting to rebase my branches when I had to fix something following a review. > > Thanks, Evan > > On 2013-09-18, at 8:52 PM, Marc Petit-Huguenin > wrote: > > Thess quick start instructions assume that you know about git, that you > already have an ssh key pair configured and that ssh and git are installed > on your computer. Note that the email configured in git must match the > email that you used in the Gerrit configuration. > > First step is to clone the Wireshark repository, which need to be done only > one time: > > - Start by creating a new account in Gerrit by going to the > http://test.code.wireshark.org/review/ page, and clicking of the Register > link, on the top right. > > - Here the simplest is to use an existing Google or Yahoo ID. Just follow > the instructions until you are back on the test.code.wireshark.org site. > > - On the page, choose a username and save it. Copy the content of your ssh > public key (~/.ssh/id_rsa.pub) and add it, then click continue. You are > done for now with the web interface. > > - Go to your command line and enter the following command (replacing > by the user name you entered in the web page): > > git clone > ssh://@test.code.wireshark.org:29418/wireshark-review-sandbox > > - After it is done (it will take a minute of so), install the change-id > hook with the following commands: > > cd wireshark-review-sandbox scp -p -P 29418 > @test.code.wireshark.org:hooks/commit-msg .git/hooks/ > > - Finally install a shortcut to push patchsets: > > git config --add remote.origin.push HEAD:refs/for/master > > > After this, you can prepare your first patchset. One of the essential > rule is that you *never*, *ever* work in the master branch. This branch > must be considered read-only. So to create a patchset, you need first to > create a topic branch. I personally always name a topic branch so it ends > with the name of the branch onto which the patchset will be merged, so in > this case, -master: > > git checkout -b first-patchset-master > > This will create a new branch (from the tip of the master branch) and > switch to it (you can list your branches with "git branch") > > Now you can do all your modifications. When you are done, you need to > commit them. The simplest is this command: > > git commit -a > > Note that git will ask you for a commit message, which is as important as > the modified code itself. The usage if to have a title of no more than 50 > characters, an empty line, then an explanation on the commit itself. > > After the modifications are committed you can review the commit with "git > log -p". Note that a field name "Change-ID" was automatically added. > This is the magic that will glue multiple revisions of the same patchset, > do not modify it. If everything looks fine, you can push it with the > following command: > > git push > > And that's it, congratulations, your first patchset is ready for review, > and you can see it on the website, by clicking on My|Changes. > > Obviously some patchsets will probably be merged in the master branch > before your patchset is reviewed and merged, so you will need to rebase it. > First to need to switch back to the master branch and to pull all the new > modifications: > > git checkout master git pull > > If you followed the rule above (never work on the master branch), there > s
Re: [Wireshark-dev] Quick start instructions for Gerrit
Thanks for the How To :-) On Thu, Sep 19, 2013 at 2:52 AM, Marc Petit-Huguenin < m...@petit-huguenin.org> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Thess quick start instructions assume that you know about git, that you > already have an ssh key pair configured and that ssh and git are installed > on > your computer. Note that the email configured in git must match the email > that you used in the Gerrit configuration. > > First step is to clone the Wireshark repository, which need to be done only > one time: > > - - Start by creating a new account in Gerrit by going to the > http://test.code.wireshark.org/review/ page, and clicking of the Register > link, on the top right. > > - - Here the simplest is to use an existing Google or Yahoo ID. Just > follow the > instructions until you are back on the test.code.wireshark.org site. > > - - On the page, choose a username and save it. Copy the content of your > ssh > public key (~/.ssh/id_rsa.pub) and add it, then click continue. You are > done > for now with the web interface. > > - - Go to your command line and enter the following command (replacing > by the user name you entered in the web page): > > git clone ssh://@ > test.code.wireshark.org:29418/wireshark-review-sandbox > > - - After it is done (it will take a minute of so), install the change-id > hook > with the following commands: > > cd wireshark-review-sandbox > scp -p -P 29418 @test.code.wireshark.org:hooks/commit-msg > .git/hooks/ > > - - Finally install a shortcut to push patchsets: > > git config --add remote.origin.push HEAD:refs/for/master > > > After this, you can prepare your first patchset. One of the essential > rule is > that you *never*, *ever* work in the master branch. This branch must be > considered read-only. So to create a patchset, you need first to create a > topic branch. I personally always name a topic branch so it ends with the > name of the branch onto which the patchset will be merged, so in this case, > - -master: > > git checkout -b first-patchset-master > > This will create a new branch (from the tip of the master branch) and > switch > to it (you can list your branches with "git branch") > > Now you can do all your modifications. When you are done, you need to > commit > them. The simplest is this command: > > git commit -a > > Note that git will ask you for a commit message, which is as important as > the > modified code itself. The usage if to have a title of no more than 50 > characters, an empty line, then an explanation on the commit itself. > > After the modifications are committed you can review the commit with "git > log > - -p". Note that a field name "Change-ID" was automatically added. This > is the > magic that will glue multiple revisions of the same patchset, do not modify > it. If everything looks fine, you can push it with the following command: > > git push > > And that's it, congratulations, your first patchset is ready for review, > and > you can see it on the website, by clicking on My|Changes. > > Obviously some patchsets will probably be merged in the master branch > before > your patchset is reviewed and merged, so you will need to rebase it. > First to > need to switch back to the master branch and to pull all the new > modifications: > > git checkout master > git pull > > If you followed the rule above (never work on the master branch), there > should > not be any conflicts when running the "git pull" command. The next step > is to > rebase your patchset: > > git rebase master first-patchset-master > > There may be conflicts at this time. Resolve them, do a "git add" of the > modified files and then finish the rebase with the following command with > the > following command: > > git rebase --continue > > (you may have to do that multiple times) > > It may be a good time to do the modifications that were requested by your > reviewers: apply then then amend the existing commit (do not add a new > commit, you want a clean history, not a catalog of your mistakes): > > git commit --amend -a > > Then push again your patchset: > > git push > > The new patchset will appear on the web page in parallel to the previous > patchset, where it can be reviewed again and eventually merged into master. > > After your patchset is merged into master, do a pull and a rebase again of > your (now useless) branch. If everything went well, you should be able to > safely delete the topic branch with this command (the branch will not be > deleted if it was not completely merged): > > git checkout master > git branch -d first-patchset-master > > Enjoy! > > - -- > Marc Petit-Huguenin > Email: m...@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.14 (GNU/Linux) > > iQIcBAEBCAAGBQJSOkqwAAoJECnERZXWan7Esd8P/RR5ePQhNcXZyMbj3A0iSlhl > iyDI3nu+qTb7MTUbpL3BUD5KI+k6BeCUFfN6kimx8YNIGe/mmU6gJKMqMjvA3RZs > 3L2v2FFFzMnCeeJQbRrGv
[Wireshark-dev] Multiple commits per topic branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 It is possible to have more than one commit per topic branch. If it is the case, git push will create one patchset per commit in the Gerrit server, with a dependency between successive commits. In most case, this is not a good idea to have multiple commits per branch, because of the dependencies created: The first commit has to be merged before the second can be merged, and so on, so if there is no relationship between your modifications, it is better to create a separate topic branch for each of them, so they can be reviewed and merged independently (at the cost of additional rebase). On the other hand, reviewers generally dislike having to review patchsets that are too big (the smaller a patchset, the more likely you will find someone to review it), so splitting a commit is a good idea in those cases. One specific case where it is very useful to have two commits in the branch is to not mix source formatting with code modifications. As an example of what could be done after a reviewer complains about the size of a patchset, I split the patchset http://test.code.wireshark.org/review/#/c/6/ in 2, and pushed again the branch, creating an additional patchset http://test.code.wireshark.org/review/#/c/13/. To make things a little bit easier for reviewers, you can link all the patchsets together by using a topic. In that case I used the following command to push the branch, creating the topic "reload-patchsets": git push ssh://@test.code.wireshark.org:29418/wireshark-review-sandbox HEAD:refs/for/master%topic=reload-patchsets This way you can click on the topic, and see all the related patchsets. To prevent name clashing, some sort of naming scheme for the topics should be created (/ ?) - -- Marc Petit-Huguenin Email: m...@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSOzaUAAoJECnERZXWan7EDNgP+gOS8nkU0Q2FAs8TeGWTA0dI ngT3uHCTrAnt8795xEYOO1QeGDWFY4XKLe5Y4MMM+rK3ccrpe0j0BGnSFv1Uy+3e XdMVnTtddYAzJZjYueMSRzg7ncg/9HCbGNXn9dJ4SsR7qFaNtBonkMdBPypttO/p Cgc53EGrnFFc47M8QFUNakr15XBwG9WBnlQCw8IUNfWAoXM59qvLqV0neazWJ5JY MBzRpAEvMjcyYRcQK8FXvJJFBWko6IYqfvtXFHneEUQTYeVRvPnrPDpwfZkyl/6E KNZ/UjhEXn+eQds/pz+7cxEaP/p7HGpwwsnNDahiFS/BSFWgBoJX14hdJ6baLE89 qhYsQ5mUy49d4Umb7bNxBzLtWHXjVjip9Gb8+/Zm+86mGVbRQx9zJZzfX9w5Yrzd hrv8Vqygb0Uy6+O5Z9eyNXajZwlgun7Hh/1VaBKxgwegsuJq/z2h1qI7HuJOHasJ qzmR9fPqQUyUq5aFMtWRq6nc8M7xGa5dzPuihP0qVX3EoVlWiyQUd5WU+8jH888k mQHBdI12JNj6UdigIebN3ubKpDlF42sySP2HJO02c1F71C9DparIEHA4oUM3zr99 JKQQUchsXKMsgiWr5YKEIsKEqhPZ2rM7HIT8mWxTvNqLgn1QJTaOK+tYyiIvb0Gr pJZ0+4oSDObTHr7c2q3/ =MXcJ -END PGP SIGNATURE- ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Tool Ownership and Licensing
On Wed, Sep 18, 2013 at 02:34:26PM -0700, Guy Harris wrote: > > On Sep 13, 2013, at 11:45 AM, Evan Huus wrote: > > > We have the following tools in our source tree without appropriate > > license headers, > > There's also tools/make-dissector-reg.py, which was written by Gilbert > Ramirez: > > r2873 | gram | 2001-01-10 23:21:35 -0800 (Wed, 10 Jan 2001) | 8 lines > > Add a python script which has the same functionality as the shell > script 'make-reg-dotc'. It is used only in the Win32 build because the > make-reg-dotc shell script is *so* sloow on Win32, due to the > multiple processes (grep, grep, sed) launched multiple times for each > source file. By putting all the text-mangling logic into a single Python > script, only one process is launched, and the source files are read > only once. It's *a lot* faster... seconds instead of minutes. If I understand things for windows builds correctly, we require python for windows builds as well nowadays. If that's correct we should get rid of the shell script. Ciao Jörg -- Joerg Mayer 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 Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Tool Ownership and Licensing
On 09/18/13 17:38, Guy Harris wrote:
On Sep 17, 2013, at 10:12 PM, Gilbert Ramirez wrote:
I admit to authoring pkt-from-core.py, but I doubt it actually still works.
Nevertheless, I have updated the license in the file.
I don't remember the others, though.
[...]
doc/dfilter2pod.pl
Gilbert Ramirez
r2171 | gram | 2000-07-28 09:30:28 -0700 (Fri, 28 Jul 2000) | 4 lines
Don't create dfilter2pod from dfilter2pod.in just for @PERL_PATH@; it's
a waste of time. Instead, set $(PERL) to @PERL_PATH@ in the Makefile and
call dfilter2pod.pl via $(PERL) $(src_dir)/dfilter2pod.pl
In this revision doc/dfilter2pod.pl was created from doc/dfilter2pod.in
(which was actually deleted in the subsequent r2172).
Looking at *that* file's revision history shows that it was created in r372:
Revision 372 - (view) (download) - [select for diffs]
Added Tue Jul 20 08:02:24 1999 UTC (14 years, 2 months ago) by guy
File length: 2591 byte(s)
Don't depend on Perl being in "/usr/bin/perl"; find it, and generate a
"dfilter2pod" with the path of Perl in its "#!" line.
In this revision doc/dfilter2.pod.in was created from doc/dfilter2pod .
Looking at *that* file's revision history shows that it was created in r364:
Revision 364 - (view) (download) - [select for diffs]
Added Thu Jul 15 15:33:52 1999 UTC (14 years, 2 months ago) by gram
File length: 2591 byte(s)
Modified the proto_register_field_array usage again. Thanks to Guy's
suggestion, this new method using a static array should use less memory
and be faster. It also has a nice side-effect of making the source-code
more readble, IMHO.
Changed the print routines to look for protocol proto_data instead of
looking at the text label as they did before, hoping that the data hex
dump field item starts with "Data (".
Added the -G keyword to ethereal to make it dump a glossary of display
filter keywords to stdout and exit. This data is then formatted with
the doc/dfilter2pod perl program to pod format, which is combined
with doc/ethereal.pod.template to create doc/ethereal.pod, from which
the ethereal manpage is created. This way we can keep the manpage up-to-date
with a list of fields that can be filtered on.
So, despite the convoluted history, the script still appears to have
been created by Gilbert.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Tool Ownership and Licensing - log history of renamed files
On 09/19/13 16:09, Evan Huus wrote:
On 2013-09-19, at 3:41 PM, Jeff Morriss wrote:
On 09/18/13 17:38, Guy Harris wrote:
On Sep 17, 2013, at 10:12 PM, Gilbert Ramirez wrote:
I admit to authoring pkt-from-core.py, but I doubt it actually still works.
Nevertheless, I have updated the license in the file.
I don't remember the others, though.
[...]
doc/dfilter2pod.pl
Gilbert Ramirez
r2171 | gram | 2000-07-28 09:30:28 -0700 (Fri, 28 Jul 2000) | 4 lines
Don't create dfilter2pod from dfilter2pod.in just for @PERL_PATH@; it's
a waste of time. Instead, set $(PERL) to @PERL_PATH@ in the Makefile and
call dfilter2pod.pl via $(PERL) $(src_dir)/dfilter2pod.pl
In this revision doc/dfilter2pod.pl was created from doc/dfilter2pod.in (which
was actually deleted in the subsequent r2172).
Looking at *that* file's revision history shows that it was created in r372:
Revision 372 - (view) (download) - [select for diffs]
Added Tue Jul 20 08:02:24 1999 UTC (14 years, 2 months ago) by guy
File length: 2591 byte(s)
Don't depend on Perl being in "/usr/bin/perl"; find it, and generate a
"dfilter2pod" with the path of Perl in its "#!" line.
In this revision doc/dfilter2.pod.in was created from doc/dfilter2pod .
Looking at *that* file's revision history shows that it was created in r364:
Revision 364 - (view) (download) - [select for diffs]
Added Thu Jul 15 15:33:52 1999 UTC (14 years, 2 months ago) by gram
File length: 2591 byte(s)
Modified the proto_register_field_array usage again. Thanks to Guy's
suggestion, this new method using a static array should use less memory
and be faster. It also has a nice side-effect of making the source-code
more readble, IMHO.
Changed the print routines to look for protocol proto_data instead of
looking at the text label as they did before, hoping that the data hex
dump field item starts with "Data (".
Added the -G keyword to ethereal to make it dump a glossary of display
filter keywords to stdout and exit. This data is then formatted with
the doc/dfilter2pod perl program to pod format, which is combined
with doc/ethereal.pod.template to create doc/ethereal.pod, from which
the ethereal manpage is created. This way we can keep the manpage up-to-date
with a list of fields that can be filtered on.
So, despite the convoluted history, the script still appears to have been
created by Gilbert.
Tangentially, you may be able to use git log --follow to generate this complete
history for you if I understand the way it works correctly (without doing it in
chunks and manually following renames).
If I read the SVN help correctly, SVN's log automatically is supposed to
follow copies. And, in fact, it does:
r52138 | morriss | 2013-09-18 10:23:14 -0400 (Wed, 18 Sep 2013) | 1 line
Rename PCAP files to .pcap; set mime-type appropriately. Should these files be
in the test/captures directory?
r52136 | gram | 2013-09-18 01:07:46 -0400 (Wed, 18 Sep 2013) | 8 lines
Update dfilter-test.py to use a much more modern test harness,
the "unittest" module that comes with Python. Specifically, this
takes advantage of a couple of features in the "unittest" in
Python 2.7. The tests are all the same as before, but much
better managed.
This is in preparation for some work on the display filter code.
But dfilter2pod was renamed in CVS and I guess the CVS->SVN conversion
didn't/couldn't convert the add+delete to copy+delete.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Shell scripts for building *register*.c files
On Sep 19, 2013, at 12:18 PM, Joerg Mayer wrote: > If I understand things for windows builds correctly, we require python for > windows builds as well nowadays. If that's correct we should get rid of the > shell script. For UN*X builds from SVN, you need Python (to build the Netware NCP dissector), so the shell script isn't necessary. For UN*X builds from a source tarball, the tarball contains the results of at least some of the Python scripts (the NCP dissector *AND* the *register*.c files), so: if you're just building from the source in the tarball, I'm not sure you need Python; if you're modifying the source, I'd put you in the same category as people building from SVN, and require you to have Python. So I'd be inclined to get rid of the shell scripts unless somebody can offer a good reason to keep them. The configure script should not require Python; my inclination would be to have a "sorry, no Python, install it" script and, if the configure script doesn't find Python, have it set PYTHON to that script, so if you never need to run Python, the build Just Works, and if you *do* need to run Python, the build prints the error message from the script and fails, so you at least get told to install Python. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Tool Ownership and Licensing
On 2013-09-19, at 3:41 PM, Jeff Morriss wrote:
> On 09/18/13 17:38, Guy Harris wrote:
>>
>> On Sep 17, 2013, at 10:12 PM, Gilbert Ramirez wrote:
>>
>>> I admit to authoring pkt-from-core.py, but I doubt it actually still works.
>>> Nevertheless, I have updated the license in the file.
>>>
>>> I don't remember the others, though.
> [...]
>>> doc/dfilter2pod.pl
>>>
>>> Gilbert Ramirez
>>
>>
>>r2171 | gram | 2000-07-28 09:30:28 -0700 (Fri, 28 Jul 2000) | 4 lines
>>
>>Don't create dfilter2pod from dfilter2pod.in just for @PERL_PATH@; it's
>>a waste of time. Instead, set $(PERL) to @PERL_PATH@ in the Makefile and
>>call dfilter2pod.pl via $(PERL) $(src_dir)/dfilter2pod.pl
>
> In this revision doc/dfilter2pod.pl was created from doc/dfilter2pod.in
> (which was actually deleted in the subsequent r2172).
>
> Looking at *that* file's revision history shows that it was created in r372:
>
>> Revision 372 - (view) (download) - [select for diffs]
>> Added Tue Jul 20 08:02:24 1999 UTC (14 years, 2 months ago) by guy
>> File length: 2591 byte(s)
>>
>> Don't depend on Perl being in "/usr/bin/perl"; find it, and generate a
>> "dfilter2pod" with the path of Perl in its "#!" line.
>
> In this revision doc/dfilter2.pod.in was created from doc/dfilter2pod .
>
> Looking at *that* file's revision history shows that it was created in r364:
>
>> Revision 364 - (view) (download) - [select for diffs]
>> Added Thu Jul 15 15:33:52 1999 UTC (14 years, 2 months ago) by gram
>> File length: 2591 byte(s)
>>
>> Modified the proto_register_field_array usage again. Thanks to Guy's
>> suggestion, this new method using a static array should use less memory
>> and be faster. It also has a nice side-effect of making the source-code
>> more readble, IMHO.
>>
>> Changed the print routines to look for protocol proto_data instead of
>> looking at the text label as they did before, hoping that the data hex
>> dump field item starts with "Data (".
>>
>> Added the -G keyword to ethereal to make it dump a glossary of display
>> filter keywords to stdout and exit. This data is then formatted with
>> the doc/dfilter2pod perl program to pod format, which is combined
>> with doc/ethereal.pod.template to create doc/ethereal.pod, from which
>> the ethereal manpage is created. This way we can keep the manpage up-to-date
>> with a list of fields that can be filtered on.
>
> So, despite the convoluted history, the script still appears to have been
> created by Gilbert.
>
Tangentially, you may be able to use git log --follow to generate this complete
history for you if I understand the way it works correctly (without doing it in
chunks and manually following renames).
> ___
> Sent via:Wireshark-dev mailing list
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Multiple commits per topic branch
Thanks for this information... (i search this information about "topic branch" this afternoon...) On Thu, Sep 19, 2013 at 7:38 PM, Marc Petit-Huguenin < m...@petit-huguenin.org> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > It is possible to have more than one commit per topic branch. If it is the > case, git push will create one patchset per commit in the Gerrit server, > with > a dependency between successive commits. > > In most case, this is not a good idea to have multiple commits per branch, > because of the dependencies created: The first commit has to be merged > before > the second can be merged, and so on, so if there is no relationship between > your modifications, it is better to create a separate topic branch for > each of > them, so they can be reviewed and merged independently (at the cost of > additional rebase). > > On the other hand, reviewers generally dislike having to review patchsets > that > are too big (the smaller a patchset, the more likely you will find someone > to > review it), so splitting a commit is a good idea in those cases. One > specific > case where it is very useful to have two commits in the branch is to not > mix > source formatting with code modifications. > > As an example of what could be done after a reviewer complains about the > size > of a patchset, I split the patchset > http://test.code.wireshark.org/review/#/c/6/ in 2, and pushed again the > branch, creating an additional patchset > http://test.code.wireshark.org/review/#/c/13/. > > To make things a little bit easier for reviewers, you can link all the > patchsets together by using a topic. In that case I used the following > command to push the branch, creating the topic "reload-patchsets": > > git push > ssh://@test.code.wireshark.org:29418/wireshark-review-sandbox > HEAD:refs/for/master%topic=reload-patchsets > > This way you can click on the topic, and see all the related patchsets. > > To prevent name clashing, some sort of naming scheme for the topics should > be > created (/ ?) > > - -- > Marc Petit-Huguenin > Email: m...@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.14 (GNU/Linux) > > iQIcBAEBCAAGBQJSOzaUAAoJECnERZXWan7EDNgP+gOS8nkU0Q2FAs8TeGWTA0dI > ngT3uHCTrAnt8795xEYOO1QeGDWFY4XKLe5Y4MMM+rK3ccrpe0j0BGnSFv1Uy+3e > XdMVnTtddYAzJZjYueMSRzg7ncg/9HCbGNXn9dJ4SsR7qFaNtBonkMdBPypttO/p > Cgc53EGrnFFc47M8QFUNakr15XBwG9WBnlQCw8IUNfWAoXM59qvLqV0neazWJ5JY > MBzRpAEvMjcyYRcQK8FXvJJFBWko6IYqfvtXFHneEUQTYeVRvPnrPDpwfZkyl/6E > KNZ/UjhEXn+eQds/pz+7cxEaP/p7HGpwwsnNDahiFS/BSFWgBoJX14hdJ6baLE89 > qhYsQ5mUy49d4Umb7bNxBzLtWHXjVjip9Gb8+/Zm+86mGVbRQx9zJZzfX9w5Yrzd > hrv8Vqygb0Uy6+O5Z9eyNXajZwlgun7Hh/1VaBKxgwegsuJq/z2h1qI7HuJOHasJ > qzmR9fPqQUyUq5aFMtWRq6nc8M7xGa5dzPuihP0qVX3EoVlWiyQUd5WU+8jH888k > mQHBdI12JNj6UdigIebN3ubKpDlF42sySP2HJO02c1F71C9DparIEHA4oUM3zr99 > JKQQUchsXKMsgiWr5YKEIsKEqhPZ2rM7HIT8mWxTvNqLgn1QJTaOK+tYyiIvb0Gr > pJZ0+4oSDObTHr7c2q3/ > =MXcJ > -END PGP SIGNATURE- > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Gerrit sandbox available for testing
On 9/18/13 11:57 PM, Dirk Jagdmann wrote: >> A few months ago we discussed migrating from SVN to Git + Gerrit. I >> managed to get Gerrit[1] sandbox up and running at >> >> http://test.code.wireshark.org/review/ > > will this Git be kept in sync with SVN trunk? Or will it be just a snapshot > for > the time we're testing this system? It's just a snapshot. Gerrit seems to assume that it has complete control over its hosted repositories. It has a replication plugin for automatically pushing to external repositories but I haven't found any documentation on automatically pulling changes in. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Gently migrating to Git + Gerrit
On Aug 8, 2013, at 11:21 AM, Evan Huus wrote: > Similarly on Mac, it would be nice if the macosx-setup.sh script could > as much as possible be replaced with a set of homebrew packages (or > some other equivalent). On OS X and Windows, it would be nice if people doing Wireshark development were not required to install a third-party package manager, but I might be willing to put up with it. (On OS X and Windows, it would be unacceptable, as far as I'm concerned, to require people to install a third-party package manager in order to *use* Wireshark, so presumably we'll still be *bundling* third-party packages ourselves in the distributed versions. In addition, on OS X, whatever third-party packages we use should be built against the SDK for the earliest release we're targeting, rather than built against whatever version of the OS happens to be running on the build machine; once we switch away from using X11 on OS X, many of the "you said this was for 10.6 and later but it crashes on my 10.6.x machine, saying that the libraries are too old" will go away, as a lot of that is due to an unfortunate combination of the libtool rules for library versioning, the way those rules are implemented on OS X, and OS X's library versioning scheme, but I still don't want to see that particular problem pop up again.) ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
