Re: [StGIT PATCH] Test "stg rebase" after "stg commit"

From: Karl Hasselström <kha@treskal.com>
Date: May 6, 2007, 14:22 UTC
Message-ID: <20070506142233.GA20017@diana.vm.bytemark.co.uk>
In-Reply-To: <20070506133909.GG19253@nan92-1-81-57-214-146.fbx.proxad.net>

On 2007-05-06 15:39:09 +0200, Yann Dirson wrote:

Show 7 quoted lines

> Well, this case clearly falls in the category of "actions outside
> stgit that make it possible to rebase without a loss". But then it
> is also clear that the action of tagging makes the committed patch
> reachable, and thus the rebase loss-less.
>
> The safety check could be possibly be rewritten as "check if current
> base is reachable without using any refs from current series".

Yes, I like that idea _much_ better. That's what we _should_ be testing for, given that the objective is to keep all commits reachable.

So, how can we do that? gitk displays, when you view a commit, the heads through which that commit is reachable. How does it compute that? Hmm, it seems like this type of construct works for selecting only those commits that are only reachable through a given ref:

  gitk origin/pu --not $(git show-ref | grep -v refs/remotes/origin/pu| cut -f 1 -d ' ')

Of course, one could use git log instead of gitk if it turns out to be too hard to write an x-windows parser for stgit. :-)

However, I'm not sure even this is necessary; reflogs are enabled by default nowadays. But if it's cheap enough, we might as well.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle