git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 01/11] builtin rebase: support --onto

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Aug 24, 2018, 16:21 UTC
Message-ID
<nycvar.QRO.7.76.6.1808241813420.73@tvgsbejvaqbjf.bet>
In-Reply-To
<xmqq600kheb7.fsf@gitster-ct.c.googlers.com>
Hi Junio,
On Wed, 8 Aug 2018, Junio C Hamano wrote:
Show 7 quoted lines
> Pratik Karki <predatoramigo@gmail.com> writes:
> 
> > The `--onto` option is important, as it allows to rebase a range of
> > commits onto a different base commit (which gave the command its odd
> > name: "rebase").
> 
> Is there anything unimportant?  A rhetorical question, of course.

You might think it is a rhetorical question, but obviously it is not, as your reaction testifies.

But certainly there are more important options and less important options! The most important options are those that are frequently used.

Show 9 quoted lines
> The quite casual and natural use of "to rebase" as a verb in the
> first sentence contradicts with what the parenthetical "its odd
> name" comment says.  Perhaps drop everything after "(which..."?
> 
> i.e.
> 
> 	The `--onto` option allows to rebase a range of commits onto
> 	a different base commit.  Port the support for the option to
> 	the C re-implementation.
I'd rather keep it.

Remember, a story is easier to read than a dull academic treatise. I want to have a little bit of a personal touch when I stumble over these commit messages again. And I know I will.

Show 5 quoted lines
> > This commit introduces options parsing so that different options can
> > be added in future commits.
> 
> We usually do not say "This commit does X", or (worse) "I do X in
> this commit".
Oh, don't we now? ;-)

(This *was* a rhetorical question, as *I* use this tense all the time, and unless you have quietly rewritten my commit messages without my knowledge nor consent, the Git commit history is full of these instances.)

> Instead, order the codebase to be like so, e.g.  "Support command line
> options by adding a call to parse_options(); later commits will add more
> options by building on top." or something like that.

To be quite frank with you, I hoped for a review that would focus a teeny tiny bit on the correctness of the code.

If you want to continue to nit-pick the commit messages, that's fine, of course, but do understand that I am not really prepared to change a whole lot there, unless you point out outright errors or false statements. Those naturally need fixing.

Also, please note that I will now *definitely* focus on bug fixes, as I am really eager to get those speed improvements into Git for Windows v2.19.0.

And I don't know whether I have said this publicly yet: I will send the next iterations of Pratik's patch series. He is busy with exams (GSoC really caters for US schedules, students who are in countries with very different university schedules are a bit out of luck here), and I really want these patches.

Ciao, Dscho

Previous: Junio C HamanoNext: Pratik Karki
Message 4 of 42 in “A minimal builtin rebase”
  1. Pratik KarkiAug 8, 2018
  2. 01/11 builtin rebase: support --ontoPratik Karki, Aug 8, 2018
  3. Junio C HamanoAug 8, 2018
  4. Johannes SchindelinAug 24, 2018
  5. 02/11 builtin rebase: support `git rebase --onto A...B`Pratik Karki, Aug 8, 2018
  6. Junio C HamanoAug 8, 2018
  7. Johannes SchindelinAug 26, 2018
  8. 03/11 builtin rebase: handle the pre-rebase hook (and add --no-verify)Pratik Karki, Aug 8, 2018
  9. Junio C HamanoAug 8, 2018
  10. Johannes SchindelinAug 27, 2018
  11. 04/11 builtin rebase: support --quietPratik Karki, Aug 8, 2018
  12. Stefan BellerAug 8, 2018
  13. Junio C HamanoAug 8, 2018
  14. Johannes SchindelinAug 27, 2018
  15. 05/11 builtin rebase: support the `verbose` and `diffstat` optionsPratik Karki, Aug 8, 2018
  16. 06/11 builtin rebase: require a clean worktreePratik Karki, Aug 8, 2018
  17. 07/11 builtin rebase: try to fast forward when possiblePratik Karki, Aug 8, 2018
  18. 08/11 builtin rebase: support --force-rebasePratik Karki, Aug 8, 2018
  19. Stefan BellerAug 8, 2018
  20. Johannes SchindelinAug 24, 2018
  21. 09/11 builtin rebase: start a new rebase only if none is in progressPratik Karki, Aug 8, 2018
  22. Stefan BellerAug 8, 2018
  23. Johannes SchindelinAug 24, 2018
  24. 10/11 builtin rebase: only store fully-qualified refs in `options.head_name`Pratik Karki, Aug 8, 2018
  25. 11/11 builtin rebase: support `git rebase <upstream> <switch-to>`Pratik Karki, Aug 8, 2018
  26. Duy NguyenAug 8, 2018
  27. Johannes SchindelinAug 8, 2018
  28. 00/11 A minimal builtin rebaseJohannes Schindelin via GitGitGadget, Sep 4, 2018
  29. 01/11 builtin rebase: support --ontoPratik Karki via GitGitGadget, Sep 4, 2018
  30. 02/11 builtin rebase: support `git rebase --onto A...B`Pratik Karki via GitGitGadget, Sep 4, 2018
  31. 03/11 builtin rebase: handle the pre-rebase hook and --no-verifyPratik Karki via GitGitGadget, Sep 4, 2018
  32. 04/11 builtin rebase: support --quietPratik Karki via GitGitGadget, Sep 4, 2018
  33. 05/11 builtin rebase: support the `verbose` and `diffstat` optionsPratik Karki via GitGitGadget, Sep 4, 2018
  34. 06/11 builtin rebase: require a clean worktreePratik Karki via GitGitGadget, Sep 4, 2018
  35. 07/11 builtin rebase: try to fast forward when possiblePratik Karki via GitGitGadget, Sep 4, 2018
  36. 08/11 builtin rebase: support --force-rebasePratik Karki via GitGitGadget, Sep 4, 2018
  37. 09/11 builtin rebase: start a new rebase only if none is in progressPratik Karki via GitGitGadget, Sep 4, 2018
  38. 10/11 builtin rebase: only store fully-qualified refs in `options.head_name`Pratik Karki via GitGitGadget, Sep 4, 2018
  39. SZEDER GáborSep 8, 2018
  40. Junio C HamanoSep 10, 2018
  41. SZEDER GáborSep 10, 2018
  42. 11/11 builtin rebase: support `git rebase <upstream> <switch-to>`Pratik Karki via GitGitGadget, Sep 4, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.