Re: [StGIT PATCH] Test "stg rebase" after "stg commit"
- From
Yann Dirson <ydirson@altern.org>
- Date
- Jun 2, 2007, 19:04 UTC
- Message-ID
- <20070602190429.GA6992@nan92-1-81-57-214-146.fbx.proxad.net>
- In-Reply-To
- <20070506142233.GA20017@diana.vm.bytemark.co.uk>
On Sun, May 06, 2007 at 04:22:33PM +0200, Karl Hasselström wrote:
Show 23 quoted lines
> On 2007-05-06 15:39:09 +0200, Yann Dirson wrote: > > > 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. :-)
Indeed, gitk calls git-rev-list with those arguments, so the check can be easily rewritten :)
Best regards,
-- Yann