On Fri, Jan 31, 2014 at 12:44 PM, Guy Harris <[email protected]> wrote: > > On Jan 31, 2014, at 2:22 AM, Roland Knall <[email protected]> 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 <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
