Re: Access to CVS

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

Aaron Schrab wrote:
> At 19:50 +0000 05 Dec 2012, Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx> wrote:
>>Apart from sorting out the patch level and the mailing list links, it
>
> I'm still unclear about what is expected in regards to handling of the mailing
> list links.  Why is it necessary to handle those differently for git than is
> currently done with CVS, just mention the sequence number in the commit
> message?

Obviously, you don't *have* to change anything about that.

However the path of a patch currently looks like this: You hack up the
patch. Then you send it to the mailing list. You wait for the mail to
arrive at the mailing list. Then you pick up the X-Seq: header number
from the mail that returns from the mailing list software. Now you add
an entry to ChangeLog that mentions the X-Seq: number, the files that
were changed in the patch; plus the first line of the actual commit
message. (If you're just the committer and not the author of the patch
you also mention the original author's name.)

That's not very convenient. I don't mind the mail going through the
mailing list. That's good for review and stuff like that. But it would
be pretty neat, if I could save a mail from my MUA somewhere and run
"git am foo.patch" on it. If that would extract the X-Seq: number from
the mail and put it in front of the first line of the commit message,
then that would require no manual intervention at all. (Well, that and
an automatically generated ChangeLog instead of a manually updated one.)

I'd need to take a look at git-am to see whether there is a hook that
would let us do something like that.

Another way would be to put the number into notes. However there would
be potential for that to be forgotten.

> For patches that are sent to the mailing list and then added to the official
> repository the sequence number would obviously be known before the commit is
> done, so the commit message could be edited to include it at that
> time.

Indeed.

> If submissions start being sent more in the form of pull requests rather than
> patches sent to the list [...]

How about not doing that? :)

It's not like it is hard to produce series of a larger number patches
with "git format-patch". And even sending them is trivial with "git
send-email".

That way, the way we handle contributions doesn't change a whole lot.
Everything would still pass the mailing list. Pretty much like git
development itself works. And if it scales for them, it will scale for
us - just judging by the sheer amount of patches they receive.

> This has the advantage that these links would be in the commit message no
> matter if the commit was done before or after the conversion.

ACK. Also, that would mean that both the SHA1 number as well as the
X-Seq: number would be listed in a ChangeLog generated by [1]. :-)

So that would mean that you could quickly do lookups of the individual
change in git history as well as the mailing list archive.

> Since there
> isn't really a standard format for these messages, it would be difficult to
> automatically convert the existing ones and it would be a tedious (and
> error-prone) process to do that manually.  It also doesn't require that people
> need to know anything about git notes which are still somewhat of an obscure
> area of git.

ACK to the obscurity of git-notes. IIRC there were issues with some git
tools and notes to, like they where lost when someone did a rebase? But
maybe that's fixed by now... Still, you have a point.


Regards, Frank

[1] http://ft.bewatermyfriend.org/comp/genchangelog.html

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925