Junio, thanks for the response. I am finally getting around to
following up.
On Wed, 2008-01-02 at 14:12 -0800, Junio C Hamano wrote:
> > 1. How to properly represent the history of an individual branch and
> > update it when the trunk (or the branch on which it depends) changes.
> > Right now, Wayne updates the branch by rebasing; unfortunately, if the
> > trunk changes in such a way that one of the intermediate commits no
> > longer makes sense, it is impossible to update the branch while
> > preserving a record that the intermediate commit once existed.
>
> I take this to mean a situation like this:
>
> * There is a series of patch X Y Z that implements some nicety
> not present in the mainline yet. This set applies to older
> codebase at point A.
>
> * Newer codebase B does things differently from codebase A and
> patch X is no longer needed --- IOW, what X achieves on top
> of A has already been incorporated somewhere between A and B.
> Applying Y and Z suffices to obtain that nice feature on top
> of B.
Actually, I was thinking of a change to the mainline that causes a
conflict with the patch series. For example, my repository of git was
at point A when I made the first draft X of my "gitweb: snapshot
cleanups & support for offering multiple formats" change. Then I
updated my repository and got commit B, "gitweb.perl - Optionally send
archives as .zip files", among others. When I rebased X on top of the
new master C, there was a conflict, which I resolved to produce X':
X X'
/ /
---A---...---B---...---C
But now, with refs only to C and X', I have lost the information that
the previous incarnation of X' was X.
Essentially, my objection to rebasing is that I want to keep a history
for the patch series containing all of the patched versions that I have
released (here X and X'), especially when they differ in interesting
ways (i.e., conflict resolutions), and this history should be a
first-class object that others can pull from me via the git remote
system.
I only want to use a separate patch management tool if it is integrated
with git. I have some familiarity with StGIT, and I assume guilt is
similar. StGIT uses rebasing and keeps an additional "patch changelog"
viewable by "stg log" which might seem to be what I want. The trouble
is that this changelog behaves more like a reflog than an orderly
history, and "stg refresh" does not support storing a user-entered
message describing *the change to the patch* in the patch changelog.
One option I am considering is to use StGIT and track some subset of the
StGIT area itself (.git/patches) in git.
The other approach is to maintain the feature patches/branches by
merging instead of rebasing. This has two significant advantages: patch
history is naturally kept and the full power of git's distributed merge
is available. However, it also has two significant disadvantages: the
complaint by Linus about "useless merges" mentioned in the git-rerere
manpage applies, and it's impossible to fully revert a merge (the
ancestry remains and will cause trouble if the merge is redone later).
Matt
-
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
