Re: Access to CVS

[Alex Ogier <alex.ogier@xxxxxxxxx>]

For pull requests that originate outside of patches, a convenient work flow
is to have the committer merge with 'git merge --squash' as a matter of
course. This way allows all of the advantages of distributed version
control while still keeping mainline history a linear sequence of clean
patches you can bisect to.

Best,
Alex Ogier
On Dec 6, 2012 4:06 PM, "Aaron Schrab" <aaron@xxxxxxxxxx> 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?
>
> 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.
>
> If submissions start being sent more in the form of pull requests rather
> than patches sent to the list, the changes could be merged using `git merge
> --no-ff --edit` (the --edit option is the default in recent versions of
> git, so wouldn't always be necessary) to create a new commit with its own
> commit message where the sequence number could be included.  This would
> mean that somebody who uses `git bisect` to try to determine where
> something was introduced would likely find the original commit, and would
> need to look forward a bit in the history to find the relevant sequence
> number; but that doesn't seem to be a huge burden to me.
>
> 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.  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.
>