Re: [PATCH 0/3] rebase -r: support octopus merges
Johannes Sixt writes: > Am 12.07.2018 um 18:26 schrieb Junio C Hamano: >> Johannes Schindelin writes: >>> A much more meaningful measure would be: how many octopus merge commits >>> have been pushed to GitHub in the past two weeks. I don't think I have the >>> technical means to answer that question, though. >> >> It does not mean that misusing a feature is a good thing and should >> be encouraged if many misguided people do so. > > Just recently I had to rebuild the version of git-gui that comes with > Git 2.18.0 before it was released: > > https://github.com/j6t/git-gui-ng/commit/f07ae1d7f07b036d78a3d4706e6cb4102e623fb3 > > I think that an octopus merge is the right tool for the task. Am I > misguided? It could be used and it is the right tool are two different things, I would think.
Re: [PATCH 0/3] rebase -r: support octopus merges
Am 12.07.2018 um 18:26 schrieb Junio C Hamano: Johannes Schindelin writes: A much more meaningful measure would be: how many octopus merge commits have been pushed to GitHub in the past two weeks. I don't think I have the technical means to answer that question, though. It does not mean that misusing a feature is a good thing and should be encouraged if many misguided people do so. Just recently I had to rebuild the version of git-gui that comes with Git 2.18.0 before it was released: https://github.com/j6t/git-gui-ng/commit/f07ae1d7f07b036d78a3d4706e6cb4102e623fb3 I think that an octopus merge is the right tool for the task. Am I misguided? -- Hannes
Re: [PATCH 0/3] rebase -r: support octopus merges
Johannes Schindelin writes: > Git is used in *so many* different scenarios, and both in terms of > commits/day as well as overall repository size *and* development speed, That misses another important factor, though. How well the project uses the tool, iow, how canonical should its way of using the tool be considered and encouraged to be imitated by others. > A much more meaningful measure would be: how many octopus merge commits > have been pushed to GitHub in the past two weeks. I don't think I have the > technical means to answer that question, though. It does not mean that misusing a feature is a good thing and should be encouraged if many misguided people do so.
Re: [PATCH 0/3] rebase -r: support octopus merges
Hi Stefan, On Wed, 11 Jul 2018, Stefan Beller wrote: > On Wed, Jul 11, 2018 at 10:35 AM Junio C Hamano wrote: > > To be honest, I am not sure if there still are people who use > > octopus > > The latest merge with more than 2 parents in linux.git is df958569dbaa > (Merge branches 'acpi-tables' and 'acpica', 2018-07-05), although > looking through the log of octopusses I get the impression that mostly > Rafael J. Wysocki is really keen on these. > :-) IMO core Git contributors seriously need to forget about using the Linux kernel repository as the gold standard when looking how Git is used. Git is used in *so many* different scenarios, and both in terms of commits/day as well as overall repository size *and* development speed, Linux is not even in the "smack down the middle" category. Compared to what is being done with Git on a daily basis, the Linux kernel repository (and project structure) is relatively small. A much more meaningful measure would be: how many octopus merge commits have been pushed to GitHub in the past two weeks. I don't think I have the technical means to answer that question, though. In any case, the Git project is run in such a way that even having a feature used even by just single user whose name happens to be Andrew Morton declares that feature off-limits for deprecation. When applying this context to `--rebase-merges` and Octopus merges, even a single user would be sufficient for us to support that feature. And I am sure that there are more than just a dozen users of this feature. Ciao, Dscho
Re: [PATCH 0/3] rebase -r: support octopus merges
Hi Junio, On Wed, 11 Jul 2018, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > writes: > > > The `--rebase-merges` option of `git rebase` generates todo lists that > > include the merge commits that are to be rebased. > > > > To keep things simpler to review, I decided to support only regular, > > 2-parent merge commits first. > > > > With this patch series, support is extended to cover also octopus > > merges. > > ;-) > > To be honest, I am not sure if there still are people who use octopus > (even though I freely admit that I am guilty of inventing the term and > the mechanism), given its downsides, primary one of which is that it > makes bisection less efficient. > > Nevertheless, this *is* the right thing to do from feature completeness > point of view. Thanks for following it through. --preserve-merges supports octopus merges, IIRC. And as I want to deprecate --preserve-merges, --rebase-merges *has* to support octopus merges, whether you or I would ever use them or not. Ciao, Dscho
Re: [PATCH 0/3] rebase -r: support octopus merges
On Wed, Jul 11, 2018 at 10:35 AM Junio C Hamano wrote: > To be honest, I am not sure if there still are people who use > octopus The latest merge with more than 2 parents in linux.git is df958569dbaa (Merge branches 'acpi-tables' and 'acpica', 2018-07-05), although looking through the log of octopusses I get the impression that mostly Rafael J. Wysocki is really keen on these. :-)
Re: [PATCH 0/3] rebase -r: support octopus merges
"Johannes Schindelin via GitGitGadget" writes: > The `--rebase-merges` option of `git rebase` generates todo lists that > include the merge commits that are to be rebased. > > To keep things simpler to review, I decided to support only regular, 2-parent > merge commits first. > > With this patch series, support is extended to cover also octopus merges. ;-) To be honest, I am not sure if there still are people who use octopus (even though I freely admit that I am guilty of inventing the term and the mechanism), given its downsides, primary one of which is that it makes bisection less efficient. Nevertheless, this *is* the right thing to do from feature completeness point of view. Thanks for following it through. > > Johannes Schindelin (3): > merge: allow reading the merge commit message from a file > rebase --rebase-merges: add support for octopus merges > rebase --rebase-merges: adjust man page for octopus support > > Documentation/git-merge.txt | 10 ++- > Documentation/git-rebase.txt | 7 +- > builtin/merge.c | 32 +++ > sequencer.c | 168 ++- > t/t3430-rebase-merges.sh | 34 +++ > 5 files changed, 204 insertions(+), 47 deletions(-) > > > base-commit: e3331758f12da22f4103eec7efe1b5304a9be5e9 > Published-As: > https://github.com/gitgitgadget/git/releases/tags/pr-8%2Fdscho%2Fsequencer-and-octopus-merges-v1 > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git > pr-8/dscho/sequencer-and-octopus-merges-v1 > Pull-Request: https://github.com/gitgitgadget/git/pull/8
[PATCH 0/3] rebase -r: support octopus merges
The `--rebase-merges` option of `git rebase` generates todo lists that include the merge commits that are to be rebased. To keep things simpler to review, I decided to support only regular, 2-parent merge commits first. With this patch series, support is extended to cover also octopus merges. Johannes Schindelin (3): merge: allow reading the merge commit message from a file rebase --rebase-merges: add support for octopus merges rebase --rebase-merges: adjust man page for octopus support Documentation/git-merge.txt | 10 ++- Documentation/git-rebase.txt | 7 +- builtin/merge.c | 32 +++ sequencer.c | 168 ++- t/t3430-rebase-merges.sh | 34 +++ 5 files changed, 204 insertions(+), 47 deletions(-) base-commit: e3331758f12da22f4103eec7efe1b5304a9be5e9 Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-8%2Fdscho%2Fsequencer-and-octopus-merges-v1 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-8/dscho/sequencer-and-octopus-merges-v1 Pull-Request: https://github.com/gitgitgadget/git/pull/8 -- gitgitgadget
