Jeff King [off-list ref] 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.
Junio C Hamano venit, vidit, dixit 13.03.2011 08:33:
Jeff King [off-list ref] writes:
quoted
[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.
quoted
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...
On Sat, Mar 12, 2011 at 11:33:52PM -0800, Junio C Hamano wrote:
quoted
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.
I don't necessarily care about different iterations of the patch on my
end. Usually when I discard an old version I don't go back to it, and in
the rare case that I do, it is simple enough to pull it from the reflog
or from the mailing list.
What I mean is lining up what I have locally (and what I send) with what
ends up in your repository. Which can have arbitrary changes from the
original. I don't think there is a general solution. In theory you could
take a single patch of mine, split it into two, then mark up each half.
I know you have the sense not to do this, but there are simpler cases
that still cause problems.
For example, in my recent trace-sifter series, you took some squashes
from other people on the early bits, and those impacted the text of
later bits. So there was no way for patch-id to link up the patches.
Rebasing at least faces me with the conflicts over the rewrite, and I
can manually check each conflict and say "OK, it looks like he took my
patch, but this part had to be rewritten". And then I can either accept
your rewrite (by resolving in favor of you), or I can rework my patch to
do what I think should be done on top of yours, and then submit my new
one on top.
I could also use Jay's suggested "loose patch id", and link things up by
commit author and message. Unless you do something drastic like
splitting a patch in two (or merging two patches into one), then I can
create the correlation. But it makes me a little nervous, because the
content of your version may not be the same as mine. And probably I
should be reviewing it before throwing away my version in favor of
yours.
-Peff