On Fri, Jan 31, 2014 at 12:44 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> On Jan 31, 2014, at 2:22 AM, Roland Knall <rknall@xxxxxxxxx> 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
