Wireshark mailing list archives
Re: Quick start instructions for Gerrit
From: Evan Huus <eapache () gmail com>
Date: Fri, 31 Jan 2014 13:26:49 -0500
On Fri, Jan 31, 2014 at 12:44 PM, Guy Harris <guy () alum mit edu> wrote:
On Jan 31, 2014, at 2:22 AM, Roland Knall <rknall () gmail com> wrote:But one clarification. You do not check-out a project with git. This is a misconception. You clone the complete repository of wireshark into a local copy.Unfortunately, yes, that's what happens, imposing a requirement to push changes after they're committed, and adding an extra step to my workflow with no obvious benefit either to me or to the project. I have, occasionally, been tempted to see whether I could do my own set of porcelain that allows me to completely ignore the "you have your own separate repository" stuff, with a more CVS/SVN-like model, where 1) there's an "update" operation that grabs from the master changes made since the last time a checkout or update was done, attempts to merge them into the files you have modified, and keeps track of the ones where there was a merge conflict;
"git pull"
2) there's a "commit" operation that sends your changes to the master;
"git pull && git commit -a && git push" with the caveat that the push should be to gerrit, not straight to master
3) changes are either committed to the master or they're not - there's no notion of adding a file that's already in the repository to a change set, and the "diff" operation shows the difference between all your changes and the master.
As long as you use "git commit -a" this is basically already true (with the exception adding new files or removing old files from the repo). --- Since this has turned into kind of a meta-discussion on workflow management, I will take a stab at explaining the trade-offs involved and why git works the way it does. It's optimized for a specific workflow, and while that means it might not be quite as efficient for other workflows, it still seems to provide the best "average" workflow. Note of course that the specific workflow git is optimized for is Linus's kernel work. Two of the driving requirements in the original design were: - ability to do as much work as possible offline (eg on a laptop on a plane) - ability to manage many relatively small changes on top of a large project without exploding disk usage or build time The ability to work offline is an obvious motivator for the commit/push distinction. It massively simplifies offline development, at a small constant cost for users who have to type "git commit && git push" instead of just "git commit". A shell alias removes most of that extra cost anyways. The ability to manage many small changes is a motivator for the branching design, though this is perhaps less obvious. Consider a situation where you may have several changes under development/review at once, on a large project like the kernel (or Wireshark, for that matter). In SVN you would probably just have a separate working dir for each. Pros are extremely fast switching between environments (just a 'cd' and you're done). Cons are disk space usage, and it is expensive to set up another change (since it requires copying/building the whole project, which is slow). The other option is to keep all changes in one working directory and let users switch between them. Pros are much-reduced disk space, and near-instantaneous creation/deletion of branches. The con is that it takes slightly longer to switch branches since doing so requires a partial rebuild. However when the branches are closely related the rebuild cost is usually a tiny fraction of the cost to rebuild the whole project. Regarding "never work in master" this is just organizational. If you have five changes on the go, you could put four of them in branches and one in master, but it's just simpler to put all of them in branches and not have to remember which one is "special". If you only ever work on one change at a time in a given working directory, and you always push that change before starting another one, then there's no reason to use branches. Hope this helps, Evan ___________________________________________________________________________ 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-request () wireshark org?subject=unsubscribe
Current thread:
- Re: Quick start instructions for Gerrit Guy Harris (Jan 30)
- Re: Quick start instructions for Gerrit Michal Labedzki (Jan 30)
- Re: Quick start instructions for Gerrit Roland Knall (Jan 31)
- Re: Quick start instructions for Gerrit Guy Harris (Jan 31)
- Re: Quick start instructions for Gerrit Guy Harris (Jan 31)
- Re: Quick start instructions for Gerrit Roland Knall (Jan 31)
- Re: Quick start instructions for Gerrit Guy Harris (Jan 31)
- Re: Quick start instructions for Gerrit Roland Knall (Jan 31)
- Re: Quick start instructions for Gerrit Roland Knall (Jan 31)
- Re: Quick start instructions for Gerrit Guy Harris (Jan 31)
- Re: Quick start instructions for Gerrit Evan Huus (Jan 31)
- Re: Quick start instructions for Gerrit Guy Harris (Jan 31)
- Re: Quick start instructions for Gerrit Evan Huus (Jan 31)
- Re: Quick start instructions for Gerrit Graham Bloice (Jan 31)
- Re: Quick start instructions for Gerrit Evan Huus (Jan 31)
- Re: Quick start instructions for Gerrit Roland Knall (Jan 31)
- Re: Quick start instructions for Gerrit Michal Labedzki (Jan 30)