This may have been discussed before, but I could not find it. If so, I
apologize for the noise and hope somebody is working on the issue.
Based on my observation, rebase is the single most interesting and
misunderstood feature in git compared with other VCS. Once I
discovered rebase -i, I can't stop using it, because I'd like to keep
my history clean for readability and maintenance purpose. The downside
is that once you publish your branch, further rebasing could cause a
lot of pain for people who have already rebased and merged this
branch, as rebasing/merging against the branch by them would cause a
lot conflicts that have to be resolved manually due to some loss of
common history (one or more SHA1s were rewritten).
Of these lost SHA1s, the last SHA1 of the last rebase is most
interesting, as it's usually the parent of other people's rebase or
merge. The same applies to a series of patches that are being modified
over time. If we preserve a
<last_sha1_of_the_last_rebase_or_original_head> record, say in reflog,
for every rebase, we can have more intelligent merges of rebased
histories with much less conflicts (specifically, squashing,
reordering and comment editing will result zero conflicts for
downstream users). We probably need to extend git protocol to send
along these rebase records. We can even modify format-patch to
generate these rebase records for each rebase of a branch. We also
need to modify gc code to reserve these records in reflog (along with
stashes as discussed in another thread). I think this approach can be
made backward compatible.
One obvious problem of this approach is that people can branch in the
middle of a patch series after they rebased/merged it, which means
they'll have to resolve conflicts manually even with this approach. I
argue that this is a rare case and that the above approach works for
most common cases.
In summary, the proposal tries to solve the rebase problems by
preserving and propagating rebase history and let the merge algorithm
take advantage of the information.
What do you guys think?
Disclaimer: I don't know much about git internal yet. My understanding
of git is only at conceptual level (commit DAG and reflog)
__Luke
--
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
