On Tue, Oct 13, 2015 at 1:07 PM, Jacob Keller <jacob.kel...@gmail.com> wrote: > On Tue, Oct 13, 2015 at 6:29 AM, Philip Oakley <philipoak...@iee.org> 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. -- 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
