On Thu, Jun 22, 2023 at 12:13 PM Toon Claes <toon@xxxxxxxxx> wrote: > > > Christian Couder <christian.couder@xxxxxxxxx> writes: > > > diff --git a/Documentation/git-replay.txt b/Documentation/git-replay.txt > > index 439b2f92e7..6fcaa44ef2 100644 > > --- a/Documentation/git-replay.txt > > +++ b/Documentation/git-replay.txt > > @@ -9,7 +9,7 @@ git-replay - Replay commits on a different base, without touching working tree > > SYNOPSIS > > -------- > > [verse] > > -'git replay' (--onto <newbase> | --advance <branch>) <revision-range>... > > +'git replay' ([--contained] --onto <newbase> | --advance <branch>) > > <revision-range>... > > I'm not sure we need this, or at least not right now. > I've been testing with a repo having: > > * a13d9c4 (another-feature) yet another commit > * c7afc2e (HEAD -> feature) third commit > * e95cecc second commit > * f141e77 first commit > | * 7bb62ac (main) later commit > | * 506cb0a another commit > |/ > * e7acac6 initial commit > > I tried both commands: > > $ git replay --onto main main..feature main..another-feature > $ git replay --onto main --contained main..another-feature > > and they both give the same result (especially with the commit following > up this one). What is the upside of having this --contained option? This is expected. The thing is that: $ git replay --onto main main..another-feature will only output something to update 'another-feature' while: $ git replay --onto main --contained main..another-feature will output something to update 'another-feature' and also something to update 'feature'. So when you use --contained you don't need to first find the other branches like 'feature' that point to commits between 'main' and 'another-feature', as --contained will find them for you. > Maybe it's better to defer this patch to a separate series. I am not sure why you are proposing this. It's true that there are other means to achieve the same thing as --contained, but that doesn't mean that it cannot be useful already. If there were things that needed to be more polished in this feature, then maybe leaving it for a separate series later might allow this series to graduate while --contained is polished, but I don't think we are in this case. > And another question, in git-rebase(1) a similar option is called > --update-refs. Would you consider reusing that name here is a good idea > for consistency? `git replay` outputs commands that can be passed to `git update-ref --stdin`, but for now it doesn't run that command itself. So no refs are actually updated. If we ever add an option for git replay to also update the refs, it would have a name probably quite similar to --update-refs so it would be unfortunate if --update-refs is already used for something else. --contained also tells about the fact that the branches affected by the option are "contained" in the revision range that is passed, which is nice. In short I think it's just unfortunate that git rebase already uses --update-refs for the "contained" branches, as it would be likely to confuse people if we would use it here for that.
