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

Re: [PATCH] rebase -i: introduce the 'test' command

From
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Date
Dec 3, 2018, 17:27 UTC
Message-ID
<20181203172743.kq5zfbfnvjadeikj@ltop.local>
In-Reply-To
<20181201200209.GC29120@sigill.intra.peff.net>
On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote:
Show 30 quoted lines
> On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
> 
> > > > Would it not make more sense to add a command-line option (and a config
> > > > setting) to re-schedule failed `exec` commands? Like so:
> > > 
> > > Your proposition would do in most cases, however it is not possible to
> > > make a distinction between reschedulable and non-reschedulable commands.
> > 
> > True. But I don't think that's so terrible.
> > 
> > What I think is something to avoid is two commands that do something very,
> > very similar, but with two very, very different names.
> > 
> > In reality, I think that it would even make sense to change the default to
> > reschedule failed `exec` commands. Which is why I suggested to also add a
> > config option.
> 
> I sometimes add "x false" to the top of the todo list to stop and create
> new commits before the first one. That would be awkward if I could never
> get past that line. However, I think elsewhere a "pause" line has been
> discussed, which would serve the same purpose.
> 
> I wonder how often this kind of "yes, I know it fails, but keep going
> anyway" situation would come up. And what the interface is like for
> getting past it. E.g., what if you fixed a bunch of stuff but your tests
> still fail? You may not want to abandon the changes you've made, but you
> need to "rebase --continue" to move forward. I encounter this often when
> the correct fix is actually in an earlier commit than the one that
> yields the test failure. You can't rewind an interactive rebase, so I
> complete and restart it, adding an "e"dit at the earlier commit.

In this sort of situation, I often whish to be able to do nested rebases. Even more because it happen relatively often that I forget that I'm working in a rebase and not on the head, and then it's quite natural to me to type things like 'git rebase -i @^^^' while already rebasing. But I suppose this has already been discussed.

-- Luc
Previous: Jeff KingNext: Johannes Schindelin
Message 14 of 21 in “rebase -i: introduce the 'test' command”
  1. rebase -i: introduce the 'test' commandPaul Morelle, Nov 28, 2018
  2. Johannes SchindelinNov 28, 2018
  3. Paul MorelleNov 28, 2018
  4. Johannes SchindelinNov 29, 2018
  5. Johannes SchindelinNov 29, 2018
  6. Jeff KingDec 1, 2018
  7. Eric SunshineDec 2, 2018
  8. Jeff KingDec 2, 2018
  9. Ævar Arnfjörð BjarmasonDec 11, 2018
  10. Jeff KingDec 11, 2018
  11. Johannes SchindelinDec 2, 2018
  12. Phillip WoodDec 3, 2018
  13. Jeff KingDec 3, 2018
  14. Luc Van OostenryckDec 3, 2018
  15. Johannes SchindelinDec 3, 2018
  16. Luc Van OostenryckDec 3, 2018
  17. Jeff KingDec 3, 2018
  18. Johannes SchindelinDec 4, 2018
  19. Duy NguyenDec 3, 2018
  20. Johannes SchindelinDec 3, 2018
  21. Jeff KingDec 3, 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.