On Fri, Jan 31, 2014 at 2:22 PM, Guy Harris <g...@alum.mit.edu> wrote: > > On Jan 31, 2014, at 10:26 AM, Evan Huus <eapa...@gmail.com> wrote: > >> On Fri, Jan 31, 2014 at 12:44 PM, Guy Harris <g...@alum.mit.edu> wrote: >>> >>> On Jan 31, 2014, at 2:22 AM, Roland Knall <rkn...@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" > > ...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".
Whoops, yes, it's been a while since I've tried that. >>> 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. I use git-review which adds a "git review" command that does the right thing with respect to gerrit. https://github.com/openstack-infra/git-review > 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. I can't think of any cases where git would stage anything itself? I'm not sure what you mean here, I thought the original point was about the need to stage things with "git add" before committing them? >> 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. It only takes me a few minutes to build wireshark from scratch, but it's still orders of magnitude faster to compile a half-dozen files and relink everything. >> 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.) To each his/her own I guess. For me tabbed browsing is the equivalent of folder nesting - it lets me group semi-related items (open web pages) in a single sub-level, turning my window manager into a tree instead of a flat list. Yes, this may say bad things about my window manager, but that's why I tab. If all the window managers in the world implemented application grouping properly I'd probably stop using tabs :) For local branches I don't think of them as "in the same space" so much. There's not much difference conceptually between "cd wireshark/mybranch/" and "cd wireshark/ && git checkout mybranch". You're still navigating the same number of layers, just the command to do so is different. > 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.... Not really, sadly, this is a shortcoming that bugs me sometimes. It can be worked around using the stash, just like #1. ___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe
