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

[minor usability suggestion] git rebase <upstream> --onto <newbase> ?

From
IMIngo Molnar <mingo@elte.hu>
Date
Nov 7, 2008, 09:20 UTC
Message-ID
<20081107092035.GA1339@elte.hu>

I use git rebase rarely, but i just had one of those exceptions where it's OK to use it: wanted to zap an unsafe commit [685aebb below] from a short-lifetime topic branch. With that i had this small usability incident:

 earth4:~/tip> tc
 tip/core/urgent 82d4e6e: xen: make sure stray alias mappings are gone
 earth4:~/tip> git rebase 685aebb --onto linus
 Current branch core/urgent is up to date.
 earth4:~/tip> glll
 82d4e6e: xen: make sure stray alias mappings are gone before pinning
 f6ab176: vmap: cope with vm_unmap_aliases before vmalloc_init()
 685aebb: kernel/cpu.c: section mismatch warning fix
 earth4:~/tip> git rebase --onto linus 685aebb
 First, rewinding head to replay your work on top of it...
 Applying: vmap: cope with vm_unmap_aliases before vmalloc_init()
 Applying: xen: make sure stray alias mappings are gone before pinning
 earth4:~/tip> glll
 d05fdf3: xen: make sure stray alias mappings are gone before pinning
 9b46333: vmap: cope with vm_unmap_aliases before vmalloc_init()
 earth4:~/tip> tc
 tip/core/urgent d05fdf3: xen: make sure stray alias mappings are gone 
 earth4:~/tip> git version
 git version 1.6.0.2.GIT

What i tried to achieve was to zap a single commit that was applied first, and preserve the other two commits - without having to go via the longer "git rebase -i" path.

It took me some time to figure out that while the principle i applied was correct, the first rebase command didnt work because i mistakenly flipped around the "--onto <newbase> <upstream>" arguments to "<upstream> --onto <newbase>".

Unless the reverse order is meaningful and important, it might make sense to flip it back implicitly and thus accept that order as well transparently.

For example "git log" is exemplary in this area as it accepts just about any permutation of parameters thrown at it, and i love that aspect of Git commands in general, it's a really nice property.

Or at least we should print some sort of warning/error? The "Current branch core/urgent is up to date." message definitely did not help me in noticing my mistake.

	Ingo
Next: Junio C Hamano
Message 1 of 5 in “[minor usability suggestion] git rebase <upstream> --onto <newbase> ?”
  1. Ingo MolnarNov 7, 2008
  2. Junio C HamanoNov 7, 2008
  3. Daniel BarkalowNov 7, 2008
  4. Junio C HamanoNov 7, 2008
  5. Ingo MolnarNov 8, 2008

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.