On Jan 31, 2014, at 10:26 AM, Evan Huus <eapache@xxxxxxxxx> wrote:
> 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"
...which refuses to do the pull if there are any files differing from the checked-in versions, so, for me, the operation is actually
git stash; git pull; git stash apply
which is in ~/bin/git-update so I can just do "git update".
>> 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
(The caveat being, of course, Wireshark-specific; it's not the only project using Git with which I'm involved.
And the caveat needs to be automated in some fashion, whether it's a ~/bin/git-checkin script that does all of the above or a way to configure Git so that pulls come from the master and pushes go to Gerrit.
And the "git pull" would, of course, have to be replaced by "git stash; git pull; git stash apply", as per the above.)
>> 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).
...and as long as Git doesn't commit anything itself as a result of any of the aforementioned operations.
> 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,
Not a *huge* problem for me, personally. (Most of the disk space on my laptop is, I think, taken up by a pile of virtual machines.)
> and it is
> expensive to set up another change (since it requires copying/building
> the whole project, which is slow).
Not too painful on my machine, either.
> 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.
The other con is that it's the moral equivalent of tabbed browsing, which I, at least, *really hate*, as it keeps a bunch of unrelated things in the same space. (As per an earlier comment of mine, if Safari had an option to prevent it from even accidentally creating a tab, I would enable it in a heartbeat.)
And does that work if your work is not committed until it's time to push to the official repository? If not, it's another case of Git strongly pushing a particular workflow....
> 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.
That's exactly my workflow, so there's no reason for me to use branches.
