[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?
Cheers,
René
More information about the Development
mailing list