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

[Welbourne Edward]

In response to:
>>> 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).

I offered:
>> 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.

René J. V. Bertin follows up with:
> Actually, it only does that after you committed your changes.

Indeed - most git actions presume a clean state.  You can, however, git
stash before such an operation, to save uncommitted local changes, and
git stash pop after to restore them.  So the above would become

$ git stash
$ git pull -r
$ git stash pop

> More often than not I don't because I need to be able to maintain
> patchfiles that apply against head or else a known commit (e.g. one
> that corresponds to a release). And I prefer to do that without having
> to remember to specify the 2 commit hashes to be compared explicitly.

When I have some patch I routinely need to apply, I commit it on a topic
branch (which gives the change a name and discourages git from garbage
collecting it) and then cherry-pick it onto whatever HEAD needs it (or a
temp branch off such a HEAD, or a detached HEAD, as appropriate).  I can
sporadically rebase the topic branch up whatever branch it's based on,
to move it past anything that introduces a conflict with it (resolving
that once).

> Now I suppose I could maintain and commit my changes in a personal topic branch
> if
> - one can sync such a branch w.r.t. (rebase on) a specific commit from the
> original branch (i.e. not just against head)

Yes, you can do that: you just need to know the specific commit's sha1,
then (with $patch as the patch-branch, $base as the original branch and
the specific sha1 as $specific):

$ git checkout $patch
$ git rebase --onto $specific $base

This takes every commit in $patch that's not in $base and replays it
starting from $specific, moving the $patch branch name to point at the
result.  (Of course, if you want to leave the $patch name where it is,
you can git checkout -b tmp $patch and use tmp in place of $patch, then
git branch -D tmp when you're done with it.)

> - if there's a convenience command to obtain a complete diff of the topic
> branch's head against the current state of some other branch.

Well, that'd just be: git diff $topic $other for the diff between two
tips of branches.  However, ...

> With "complete diff" I mean something like `git diff --no-ext-diff head -- .`
> though it may be that I only need those extra options to get newly added (but
> not committed) or deleted files included in the diff.

you seem to mean you want the diff between some $topic and the current
state of your work tree (rather than the last commit of the branch it's
on); that's just git diff $topic (with whatever other options you may
like, to taste).  If what you want is the diff between what you've
currently staged (with git add) and $topic, then throw in a --cached
option.

For three-way diffs between two commits and their most recent common
ancestor, you can use git diff $topic...$other, if you're comfortable
reading three-way diffs,

	Eddy.