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

Re: [RFC PATCH 0/5] Add option to autostage changes when continuing a rebase

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 26, 2017, 22:12 UTC
Message-ID
<xmqq60eeq24l.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<xmqqa83qq2uf.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 13 quoted lines
> Hmph, this is interesting.
>
> "git rebase" does take "--rerere-autoupdate" option from the command
> line, and propagates it to a later invocation of "rebase --continue"
> by storing the value to $state_dir/allow_rerere_autoupdate file and
> reading the value from it.  $allow_rerere_autoupdate shell variable
> is used to hold the setting.  
>
> I'd expect that this variable to be used in invocations of "git am"
> in git-rebase--am.sh; but that does not seem to be the case.  I
> wonder if this was once working but over time we broke the feature
> without anybody noticing it, or if the support was added but not
> completed and the feature was a no-op from the beginning?

At least in v1.7.0 when doing "rebase -m", the rerere-autoupdate was plumbed correctly through to the invocation of "git merge" that is done inside git-rebase.sh. I do not see the same option passed down to the invocation of "git am", so perhaps nobody cared back then about rerere during "git rebase" that does not use "git am" backend, even though "git am" itself were capable of talking the option.

In any case, if you corrected the existing "git rebase" and its backend so that "--rerere-autoupdate" works as advertised, I think you are already 80% there without adding a yet another option, as I suspect that the most of the need for avoiding "git add" during a "git rebase" session is during a conflict resolution, and allowing "rerere" to automatically update the index with auto-resolution will leave _only_ changes to the paths the end user actually needs to take a look and manually fix still not in the index. And from the workflow point of view, encouraging them to "git add" their manual resolution after they are satisified with their changes by not doing "git add" blindly for all changes, like your --autostage" does, is probably a good thing.

Previous: Junio C HamanoNext: Phillip Wood
Message 9 of 19 in “Add option to autostage changes when continuing a rebase”
  1. 0/5 Add option to autostage changes when continuing a rebasePhillip Wood, Jul 26, 2017
  2. 1/5 rebase --continue: add --autostage to stage unstaged changesPhillip Wood, Jul 26, 2017
  3. 3/5 Unify rebase amend message when HEAD has changedPhillip Wood, Jul 26, 2017
  4. 4/5 Add tests for rebase --continue --autostagePhillip Wood, Jul 26, 2017
  5. 5/5 Add rebase.continue.autostage config settingPhillip Wood, Jul 26, 2017
  6. 2/5 rebase -i: improve --continue --autostagePhillip Wood, Jul 26, 2017
  7. Junio C HamanoJul 26, 2017
  8. Junio C HamanoJul 26, 2017
  9. Junio C HamanoJul 26, 2017
  10. Phillip WoodJul 27, 2017
  11. Phillip WoodJul 27, 2017
  12. Junio C HamanoJul 27, 2017
  13. Phillip WoodAug 21, 2017
  14. Junio C HamanoAug 21, 2017
  15. Phillip WoodAug 22, 2017
  16. Junio C HamanoAug 22, 2017
  17. Phillip WoodAug 24, 2017
  18. Junio C HamanoAug 24, 2017
  19. Phillip WoodAug 25, 2017

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.