Junio C Hamano venit, vidit, dixit 13.03.2011 08:33:
> Jeff King <peff@xxxxxxxx> writes:
>
>> [1] I have mixed feelings about the aggressive rebasing. Our 'master' is
>> pretty stable, so I don't feel the need to build off the last tagged
>> release.
>
> In a very busy project (like the kernel), it would make sense to build off
> of the last tagged release when your interaction with the upstream is
> primarily based on patch exchange. But I think that is primarily because
> the maintainer and the reviewer do not have to ask "where does this apply
> to? It does not apply to my tree; please resend" if you did so. Because
> our "master" does not move so fast, sending a complete patch series based
> on any commit that was once at the tip of "master" works similarly well,
> especially because "am -3" works well in such an environment if "master"
> is never rewound.
>
> But if your interaction with the upstream is merge based, I think it is
> preferrable to base your fork point as if you are the person at the
> upstream. There is no "where does this apply to" at that point, and you
> have a larger responsibility and say in the final shape of the history.
>
> Namely (I know you know this, and I am writing this primarily for other
> people on the list):
>
> - an fix would be appropriate to be made on top of the oldest maintenance
> track that contains the commit that introduced a bug (or even directly
> on the buggy commit itself), as long as merging up from maint-O to
> maint-N (O < N) to master is simple enough;
>
> - For enhancement patches that do not deserve to be backported to
> maintenance branches, "master" is a good place to start.
>
> For this topic, you could have said that this is a documentation bug fix
> and started the topic at the tip of maint, given that this is a fairly
> low-risk change, and that we haven't added any new file between maint and
> master that requires an evil merge to fix up. Or you can say that this is
> very minor and not worth fixing in maintenance track to fork from master.
>
>> Git-cherry sort of does this, but patch-ids miss a lot of cases: patches
>> tweaked in transit, patches applied on a different commit, or even
>> patches taken partially or split up. So I rebase frequently, and as
>> patches get picked up in master, the branches dwindle to empty.
>> Suggestions welcome if anybody else has figured out something clever.
>
> A solution to string different iterations of the same patch together,
> perhaps using notes as the storage media, that makes it easier to view the
> changes between different iterations? I think Shawn does something like
> that in Gerrit code review.
>
> When I rebase, I tend to keep the base stable (in other words, I don't use
> "rebase" in order to change the base, but to rewrite individual patches),
> too keep comparison between iterations simpler, but I haven't found a
> satisfactory solution for such a comparison for changes near the tip of
> longer series.
>
In a way it's comforting to know that even long-time contributors like
Jeff haven't found a good workflow for git.git patch lifetime management
yet. But there's progress, such as "commit --notes". I'm also fiddling
with refname notes (so you could store the cover-letter as a note to the
branch name) and have working code I'll send soon.
As far as keeping track of patch versions (without topgit) goes I've
been thinking about "mergy rebase". Before it sits around any longer,
I'll include a rough concept below.
And sorry for thread hijacking - it wasn't me :)
Michael
Say, you start developping a patch series on a branch "topic":
*--A1--B1--C1=topic
Then you rewrite/fixup your series:
*--A2--B2--C2=topic
The previous versions are lost (in the reflog).
With a mergy rebase, a rewrite/fixup would produce:
*--A1--B1--C1
\ \ \ \
---A2--B2--C2=topic
That is, "log --first-parent topic" would always walk the current
version of the topic branch, but the previous one is still accessible:
*--A1--B1--C1
\ \ \ \
---A2--B2--C2
\ \ \ \
---A3--B3--C3
\ \ \ \
---A4--B4--C4=topic
"log --second-parent C4" will give you the history of the patch C
through the different versions of ypur patch series.
(And yes, I have a WIP for --second-parent.)
Downside is that all those merges are evil, of course. But do not be
afraid...
--
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