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

René J.V. Bertin rjvbertin at gmail.com
Wed Mar 30 19:09:42 CEST 2016

On Wednesday March 30 2016 15:51:49 Welbourne Edward wrote:

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

I am a regular user of KDE's Reviewboard. It's undoubtedly not ideal, but I find it more than powerful enough.

> 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.

I have no problem with the fact that it's a commandline tool. I've been living on command lines since the TRS80 ...
Git's sub commands are a problem though, somehow. It's got a lot of commands that do a whole bunch of things that aren't necessarily clear, and that appear to have been named by people who speak a different kind of English.

> 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.

I know, but as a matter of fact I do get merges and conflicts or otherwise not cleanly applying patches a little too often, which tend to leave my working copy in a state from which I know I haven't been able to recuperate a few times too many.

> > 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

And I was only speaking about qtbase.git. 

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

Oh, don't worry about that, I now know I should simply use "checkout -b" and only manhandle `git branch` when I want to delete a branch.

> 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

provided the rebase doesn't go awry (and the "parent" branch hasn't disappeared from the remote, like the 5.6.0 branch I was using). Either way, deleting `topic-branch` and creating it anew will be much less of a hassle than recreating the whole working copy.

But I suspect that even if you delete such a branch, it will be kept in the history because git never throws out anything completely?


More information about the Development mailing list