From: Ingo Molnar <mingo@elte.hu>
To: git@vger.kernel.org
Subject: [minor usability suggestion] git rebase <upstream> --onto <newbase> ?
Date: Fri, 7 Nov 2008 10:20:35 +0100 [thread overview]
Message-ID: <20081107092035.GA1339@elte.hu> (raw)
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 reply other threads:[~2008-11-07 9:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-07 9:20 Ingo Molnar [this message]
2008-11-07 18:23 ` [minor usability suggestion] git rebase <upstream> --onto <newbase> ? Junio C Hamano
2008-11-07 20:10 ` Daniel Barkalow
2008-11-07 21:06 ` Junio C Hamano
2008-11-08 11:49 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081107092035.GA1339@elte.hu \
--to=mingo@elte.hu \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox