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é _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development