On Sat, Feb 14, 2009 at 01:35:03PM -0500, Jay Soffian wrote:
> On Sat, Feb 14, 2009 at 12:54 PM, Jeff King <peff@xxxxxxxx> wrote:
> >> + if (opt_a)
> >> + printf("%s/HEAD set to %s\n", argv[0], head_name);
> >
> > This was a surprise based on reading the commit message, but I think it
> > is a sensible enhancement.
>
> It seemed that when doing something "--automatically" it might be nice
> to tell the user what we just did, but I'm confused why this was a
> surprise.
I just meant that the commit message did not mention changes in this
area, and it is largely orthogonal to the rest of the patch (you could
just as easily apply this hunk without the rest of your patch, and it
would have the same value). Thus I was surprised.
But I do think it is a good change.
> > cat > test/expect <<EOF
> > refs/remotes/origin/master
> > EOF
> >
> > test_expect_success 'set-head --auto' '
> > (cd test &&
> > git remote set-head --auto origin &&
> > git symbolic-ref refs/remotes/origin/HEAD > output &&
> > test_cmp expect output)
> > '
>
> Right.
I suspect Junio can just fix this up during application if he agrees.
<random process musing>
Which made me think of something else, with all of this talk about
reviewers that has been going on. Junio is actually in a little bit of a
special position with small changes (like style issues) to say "I'll
apply this, but tweak these changes". But the rest of us are stuck
saying "I would change this one line" to the list; then either:
- the original submitter re-rolls the patch, which takes their time
and everyone else's time to look at the new patch, see that it is
trivially changed, etc
or
- Junio has to read the followup comments, then go back and find the
spot in the original patch to mark it up.
Which means that there is a transaction cost to little comments due to
the extra communication. And that cost can dwarf the actual time for the
change.
I don't know if there is a better method, or better tool support. I
guess reviewers could act like the maintainer, tweaking patches and then
publishing the result, which Junio would then pull. Or instead of
publishing the result, publishing an interdiff along with comments. But
basically putting the comments into a form that can be communicated and
applied more easily, which cuts down on the communication costs.
I don't know. Just thinking out loud.
-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
