[Development] gerrit : using branches

André Somers andre at familiesomers.nl
Wed Mar 30 20:35:41 CEST 2016

Op 30/03/2016 om 19:09 schreef René J.V. Bertin:
> 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 why I have a cheat sheet hanging next to my desk. In case of 
doubt, look at that. Most of the fancy stuff you never or hardly ever 
need anyway. Then Google is your friend.
>> 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.
Git reflog is your friend here. It can get you out of a tight spot in 
case of need.


More information about the Development mailing list