On Tue, Mar 29, 2011 at 11:00:00AM -0600, Jim Cromie wrote:
> If the pseudo-header can be added into the commit message,
> it is trivial to use.
>
> I see the merit of a skip-cache as working after-the-fact
> on already published/shared patch-sets, but Im unsure how the
> skip-cache can be shared currently.
If you use git-notes as I did in the example of my first response, then
you will end up with a ref "refs/notes/skip". You can push it to
wherever:
git push origin refs/notes/skip
and then everybody else can configure their repos to fetch it:
git config --add remote.origin.fetch \
+refs/notes/skip:refs/notes/origin/skip
I think they would still have to manually merge it into their own skip
cache with "git notes merge". I'm not sure. The notes-merging code is
very new (v1.7.4, I believe), and I think we are still figuring out what
workflows make sense around it (which is why it is still manual).
> > I think that is a saner approach, and further say it would be much saner
> > to make that token something like
> >
> > Â ÂBroken: does not build
>
> My only concern here is the negative connotation of Broken.
> At least in my 1/2 change scenario, thats known to be incomplete,
> its kinda pejorative. But it certainly gets the job done.
>
> Skip: make rc 125
> Skip: 125
> Skip: gcc error: no such field: foo
> Skip: api change only, users must follow
>
> Skip: has less pejorative, and closer name-association linkage
> to the bisect skip command that it
Yeah, I think a more neutral name makes sense, since there are many
reasons to skip (and in fact, broken builds are among the least
interesting to mark, since those are easy to detect at bisection time).
> > And then teach the script you give to "bisect run" to grep for that
> > "^Broken: " pattern to answer with exit 125 (cannot test), and you are
> > done.
> >
>
> With this, nothing needs to be added.
> The only advantage to bisect looking for the pseudo-header is that
> a convention is supported, such that it might get used.
If you do use this, I would love to hear a report on how it works 6
months in. If it's useful, then it might make more sense to clean up
rough edges with better tool support. Or maybe it works perfectly
without tool support, or maybe it turns out to be a flawed idea. :)
-Peff
--
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