Re: [PATCH/RFC] updating examples/git-merge (plus a builtin/merge fix)
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Aug 17, 2010, 08:10 UTC
- Message-ID
- <20100817081033.GB28476@burratino>
- In-Reply-To
- <AANLkTikf-do4nyQO=W93BxKxDekQJpExLtop__tz1n8o@mail.gmail.com>
Ævar Arnfjörð Bjarmason wrote:
> On Tue, Aug 17, 2010 at 06:51, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 5 quoted lines
>> Patches 8-10 expose functionality used by merge when handling octopus >> merges. > > You mean 9-10, 8 looks good. I don't have the familiarity to comment > on 9-10.
I would be especially interested in feedback on the interface from those two. ;-)
Is merge-base the right command to learn --independent?
Is --independent the right name for "reduced parent list"?
Is merge-base --octopus generally useful at all, or should we change the API for custom octopus strategies (maybe at the same time as teaching them to declare NO_TRIVIAL and NO_FAST_FORWARD preferences) to leave the list of merge bases out?
>> Patches 12 and later are ports of various patches to builtin/merge.c. >> I did the bare minimum to make tests pass. :) > > Those also look good to my untrained eye.
Thanks for looking them over.
> How do you run the tests against git-merge.sh? Is there some make > target to use it instead of git-merge.c, or do you manually move it in > place?
Ah, yes, I should have made that information more prominent.
To test: remove cmd_merge from the builtins list in git.c, build git, and then run:
cp contrib/examples/git-merge.sh . make SCRIPT_SH=git-merge.sh git-merge cd t && make
> If it's the latter a switch somewhere to run the test suite against > these .sh alternatives might compliment this series nicely.
Yes, that sounds like an good idea. Of course most of the retired scripts are bitrotted by now.