From: "Mike Rappazzo" <rappazzo@xxxxxxxxx>
On Tue, Oct 13, 2015 at 1:07 PM, Jacob Keller <jacob.keller@xxxxxxxxx>
wrote:
On Tue, Oct 13, 2015 at 6:29 AM, Philip Oakley <philipoakley@xxxxxxx>
wrote:
My tuppence is that the only sha1's that could/would be rewritten would
be
those for the commits within the rebase. During rebasing it is expected
that
the user is re-adjusting things for later upstream consumption, with
social
controls and understandings with colleagues.
Agreed here. There would be no need to change any sha1s that didn't
change during the rebase. This limits the scope. Alright.
Thus the only sha1 numbers that could be used are those that are within
the
(possibly implied) instruction sheet (which will list the current sha1s
that
will be converted by rebase to new sha1's).
Correct, you would be able to limit the number of sha1s to search for.
However, (see below), any reasonable reference to a sha1 should be
relatively stable.
It should be clear that the sha1's are always backward references
(because
of the impossibility of including a forward reference to an as yet
un-created future commit's sha1).
The key question (for me) is whether short sha1s are accepted, or if
they
must be full 40 char sha1's (perhaps an option). There are already
options
for making sure that short refs are not ambiguous.
It sound to me like a sensible small project for those that have such a
workflow. I'm not sure if it should work with a patch based flow when
submitting upstream - I'm a little fuzzy on how would the upstream
maintainer know which sha1 referred to which patch.
My issue: the only sha1s in commit messages are *generally* things
which will NOT be changed in general. Supporting a work flow that
wants to change these is definitely crazy.
Essentially: I don't see a reason that you would be rebasing a commit
and needing to change any references in it. You can reference a commit
which isn't changing, but here's the possible situations I see:
a) you are rebasing a commit which references in the message a commit
that is not being changed (it is ancient)
In this case, nothing needs to be done.
b) you are rebasing a commit which references another commit in the same
rebase
I see no valid reason to reference a sha1 in this case. If you're
referencing as a "fixes", then you are being silly since you can just
squash the fix into the original commit and thus prevent introduction
of bug at all.
What other reason? If you are referencing such as "thix extends
implementation from sha1" then your commit message is probably poorly
formatted. I don't see a reason to support this flow.
c) you are rebasing a commit which is referencing a commit that has
already been changed. (?)
I think (maybe) this is your interesting case, but here are some caveats.
Let's say you are fixing some old commit such as "Fixes: <sha1,
summary, date>" or something.
If you do a "git pull --rebase", your commit might be updated to play
ontop of more new work, but the sha1 should still be valid, *unless*
the remote history did some rewind, at which point I don't think any
algorithm will work, see the issues above.
It may be something worth doing in git-filter-branch, but then you're
looking at losing the two assumptions above making it really hard to
get right.
Regards,
Jake
It seems reasonable that this could be added as a feature of
interactive rebase. The todo list could be automatically adjusted to
"reword" for those commits which are referring to other commits within
the same rebase. As each commit is re-written, a mapping could be
kept of old sha1 -> new sha1. Then when one of the reworded commits
is being applied, the old sha1 -> new sha1 mapping could be used to
add a line to the $COMMIT_MSG.
--
The extra fun begins if the commit message is of a one-line pretty quoted
style, where more of the quote needs changing...
e.g.
[alias]
quote = log -1 --pretty='tformat:%h (%s, %ad)' --date=short
log1 = log -1 --pretty=\"format:%ad %h (%an): %s\" --date=short
Jake was concerned about the 'crazy' workflow, however almost all workflows
are crazy at a distance.
The rebase is required if the workflow's allowed base point moves forward
faster than one can complete the (likely long) patch series, so the series
is rebased and then an acceptable series can be merged without
modifications.
Git has the former issue i.e. master and next can move forward faster than a
long series takes to be reviewed, but does not have the latter because Junio
adds his signature to each commit, and uses the patch submission flow.
IIUC (as an alternate example), in G4W one can submit a (long) pull request
with internal back references that would be merged directly, so the sha1's
could be updated as Francois-Xavier originally asked. I have a series that's
been bumping along for a long while that needs regular rebasing, though
doesn't have sha1 back references, so I can see that the need does happen. I
can see that others may have a workflow that would work well with the sha1
auto-update.
--
Philip
--
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