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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. :-)

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@xxxxxxxxxxx
      www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]