Re: Quick start instructions for Gerrit

[Evan Huus <eapache () gmail com>]

On Fri, Jan 31, 2014 at 2:22 PM, Guy Harris <guy () alum mit edu> wrote:
> On Jan 31, 2014, at 10:26 AM, Evan Huus <eapache () gmail com> wrote:
>
> > 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"
>
> ...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-request () wireshark org?subject=unsubscribe