From: "Michael Haggerty" <mhag...@alum.mit.edu>
Sent: Tuesday, November 25, 2014 12:28 AM
On 11/21/2014 07:00 PM, Junio C Hamano wrote:
Michael Haggerty <mhag...@alum.mit.edu> writes:
I don't think that those iterations changed anything substantial
that
overlaps with my version, but TBH it's such a pain in the ass
working
with patches in email that I don't think I'll go to the effort of
checking for sure unless somebody shows interest in actually using
my
version.
Sorry for being grumpy today :-(
[..]
Let me list the aspects of our mailing list workflow that I find
cumbersome as a contributor and reviewer:
* Submitting patches to the mailing list is an ordeal of configuring
format-patch and send-email and getting everything just right, using
instructions that depend on the local environment. We saw that hardly
any GSoC applicants were able to get it right on their first attempt.
Submitting a patch series should be as simple as "git push".
* Once patches are submitted, there is no assurance that you (Junio)
will apply them to your tree at the same point that the submitter
developed and tested them.
* The branch name that you choose for a patch series is not easily
derivable from the patches as they appeared in the mailing list.
Trying
to figure out whether/where the patches exist in your tree is a
largely
manual task. The reverse mapping, from in-tree commit to the email
where
it was proposed, is even more difficult to infer.
* Your tree has no indication of which version of a patch series (v1,
v2, etc) is currently applied.
The previous three points combine to make it awkward to get patches
into
my local repository to review or test. There are two alternatives,
both
cumbersome and imprecise:
* I do "git fetch gitster", then try to figure out whether the branch
I'm interested in is present, what its name is, and whether the
version
in your tree is the latest version, then "git checkout xy/foobar".
I had a thought about the issue of version labeling and of keeping the
old patch series hanging about during development that I felt was worth
recording.
My thought was that while the cover letter and series version number are
currently stripped out from the start of the series, they could be added
back as a supplemental commit at the end of the series (an --allow-empty
commit). This could contain all of the patch subject lines and their
post '---' notes as appropriate.
Thus the series branch would appear to have an extra commit (compared to
the current process) after the original tip's possible merge into say
pu.
When subsequent series are sent to the list, the new supplemental commit
would be a 'merge', with its second parent being the old series, thus
the old series is not lost until the branch is deleted, and the existing
merge pattern is retained.
Clearly if this would need some additional coding as it's not suitable
as a manual process, but it could be just as automatic as the current
process while providing that little bit of additional visibility.
Below, I've tried to set out how the commit graph might look (oldest to
the left). Hopefully my MUA won't ruin it.
The first patch series branches at A, and is merged at D, with the
supplemental commit labeled with v1z.
When the new series arrives, and pu is rewound, we have the new series
applied from G (which in reality may not be linked directly from A), and
merged back at K. However the new v2z supplemental commit is now the
po/patches
branch head, and is also a merge back to v1z.
patch series 1 (cover letter z)
- A - B - C - D - E - F <- pu
\ /
v1a-v1b--v1z <-po/patches
patch series 2
- A - G - H - I - J - K <- pu (note re-wound)
| \ / (merge D lost)
\ v2a-v2b-v2c--v2z <-po/patches
\ /
v1a-v1b--v1z - - -.
The key idea here is to use the existing branching model, but then to
add the cover letter and other details at the end, rather than the
beginning as might have been expected from the email transmit sequence.
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
