mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Igor Djordjevic <>
To: Chris Nerwert <>
Cc:, Johannes Sixt <>,
	Nikolay Shustov <>,
	Johannes Schneider <>,
	Patrik Gornicz <>,
	Martin Waitz <>,
	Shawn Pearce <>, Sam Vilain <>,
	Jakub Narebski <>
Subject: Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)
Date: Mon, 4 Dec 2017 00:01:30 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Chris,

On 30/11/2017 23:40, Chris Nerwert wrote:
> I'm actually doing the described workflow quite often with git rebase
> when working on a topic. Given the following structure:
>   ---o               (master)
>       \
>        o---A---B---C (topic)
> When I want to make changes to commit A one option is to make them
> directly on topic, then do "git commit --fixup A", and then eventual
> interactive rebase onto master will clean them up:
>   ---o                     (master)
>       \
>        o---A---B---C---f!A (topic)
> However, sometimes this breaks when changes in B or C conflict
> somehow with A (which may happen quite a lot during development of a
> topic), so the rebase will not apply cleanly. So sometimes I make a
> temporary branch from A, commit the fixup there:
>   ---o               (master)
>       \
>        o---A---B---C (topic)
>             \
>              f!A     (temp)
> and then use "git rebase --onto temp A topic" to move the topic back
> on track:
>   ---o                     (master)
>       \
>        o---A---f!A         (temp)
>                   \
>                    B'---C' (topic)
> after which the final cleanup rebase is much easier to do.
> Obviously, all the branch switching and rebasing does take its tall
> on file modifications.

From use case you described (and which I often experience myself), it 
seems plain "git commit --onto A" would be of help here, committing 
fixup onto A directly, without a need to switch to it (branch or 
not), a case I`m discussing with Hannes in that other sub-thread[1] of 
this e-mail, too.

But from there, your flow takes a different direction, using rebase, 
while this whole thread started around some merge-like functionality.

I can imagine a user interface doing what you (and I) would like, 
something like:

(1) git commit --onto A --rebase

..., where your changes would first be committed onto commit A, and 
then commits from A (excluded) to HEAD (included) rebased onto this 
new commit.

BUT, as far as it seems to me, rebase currently touches working tree 
for each operation (am I wrong here?), so once the rebase sequence is 
initiated, it would internally still need to checkout to your new 
fixup commit (on top of A), and then proceed applying changes and 
changing working tree with each commit being rebased, overall failing 
to address your main concern - needless (untouched) file 
modifications, even in case of no conflicts.

I find this scenario quite interesting as well, but I`m afraid it may 
currently be out of scope of what I`m trying to accomplish with "git 
commit --onto[-parent]", for the most part because it looks like it 
would need "index only rebase" first (not touching working tree, that 

If we had that, it would/should be pretty easy to add it into the mix 
with "git commit --onto" here, ending up with something as imagined 
in command line (1) above :) I`ll make a note of it, thanks.

Any further help appreciated, of course :)

Regards, Buga


      reply	other threads:[~2017-12-03 23:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-26 22:35 [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes) Igor Djordjevic
2017-11-26 22:36 ` [SCRIPT/RFC 1/3] Igor Djordjevic
2017-11-26 22:36 ` [SCRIPT/RFC 2/3] git-merge-one-file--cached Igor Djordjevic
2017-11-26 22:45 ` [SCRIPT/RFC 3/3] Igor Djordjevic
2017-11-27 21:54 ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes) Johannes Sixt
2017-11-28  1:15   ` Igor Djordjevic
2017-11-29 19:11     ` Johannes Sixt
2017-11-29 23:10       ` Igor Djordjevic
2017-12-01 17:23         ` Johannes Sixt
2017-12-04  2:33           ` Igor Djordjevic
2017-12-06 18:34             ` Johannes Sixt
2017-12-06 18:40               ` Junio C Hamano
2017-12-08  0:15                 ` Igor Djordjevic
2017-12-08 16:24                   ` Junio C Hamano
2017-12-08 23:54                     ` Igor Djordjevic
2017-12-09  2:18                       ` Alexei Lozovsky
2017-12-09  3:03                         ` Igor Djordjevic
2017-12-09 19:00                           ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking " Phillip Wood
2017-12-09 19:01                           ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, noworking " Phillip Wood
2017-12-10  1:20                             ` Igor Djordjevic
2017-12-10 12:22                               ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking " Phillip Wood
2017-12-10 23:17                                 ` Igor Djordjevic
2017-12-11  1:13                                   ` Alexei Lozovsky
2017-12-11  1:00                                 ` Alexei Lozovsky
2017-11-30 22:40 ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working " Chris Nerwert
2017-12-03 23:01   ` Igor Djordjevic [this message]

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).