[Development] gerrit : using branches (was: pointers to use it cleverly/efficiently?)

Welbourne Edward edward.welbourne at theqtcompany.com
Wed Mar 30 17:51:49 CEST 2016

> Thanks for such a lengthy and detailed overview - I hope you had that
> sitting around somewhere! :)

heh - I touch-type at speed and have all of that in my head.
I learned git under demanding circumstances, so learned it thorouhgly.

> It also illustrates very nicely why I'll keep thinking that it'd be so
> much easier if Qt had a review system to which you can upload the
> (possibly pruned) results of `git diff` (and download it again if
> needed).

I met such a review tool once.
It was actually horribly frustrating.
I'd much sooner be using critic [0].

[0] https://github.com/jensl/critic

> I've learned along the way that I tend to be too sloppy and
> absent-minded to be trusted with series of commands you showed,
> esp. if they have names that aren't necessarily very clear about what
> they do.

I'm afraid git was designed by people who take command-line arcana for
granted.  It's a mighty powerful tool, but you do have to invest time
and brain-space in it.

> What works well for me e.g. before doing a commit is what I think of
> as manual rebasing: I remove my patches one way or another, git-pull,
> and then reapply the patch(es).

That's pretty much exactly what

$ git pull -r

(a.k.a. --rebase) will do for you, automagically.  It might not play
ideally with merges in all cases, but I'm guessing you don't have a
surfeit of those.

Generally, rebase is just a way to replay a succession of changes
starting from a different upstream.

> A repo like qtbase is a bit big to
> mess up locally and then just check out again on a regular basis.

Yes.  Doing the git submodule update --init --recursive after the git
clone can be a bit time-consuming, even from a local bare repo
(i.e. without the network traffic of fetching from Gerrit).

> I don't know what exactly went wrong with my 1st attempt to use
> branches (I did do a checkout and verified that I was on my branch),

OK.  Then my guess at what went wrong missed.
Hard to diagnose from what you described, though.

> but now that I know how to create topic branches and switch between
> them, "rewinding" to a clean state should be as simple as deleting the
> branch (presuming that can be done without merging it).

Well, simply checking out the branch you want to be on will get you back
to it, without having to delete any useful state.  If you're on a topic
branch, off dev say, and want to get up date with recent changes to dev,
it's as simple as:

$ git checkout dev
$ git pull
$ git checkout topic-branch
$ git rebase dev

and you're done, using just easy commands.  The first two commands are
what gets your dev up to date, the other two bring your topic-branch up
to date with it.  You can even shorten that to:

$ git fetch gerrit
$ git rebase gerrit/dev

if you don't mind your local dev staying out of date until next time
you're using it (which may even be an advantage, in some cases).  If
you have local changes you aren't yet ready to commit, you can wrap
commands like those above in

$ git stash
$ git stash pop

to save and restore the mess,


More information about the Development mailing list