Re: [PATCH] technical doc: add a design doc for the evolve command

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 18, 2018, 23:20 UTC
Message-ID: <xmqq1s7iezw9.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAPL8ZismWQ7CCZXZJAqtu7v2CD0SyN5kncgXnXb7sL9mmqwhcQ@mail.gmail.com>

Stefan Xenos <sxenos@google.com> writes:

>> I don't think this counts as a typical modification and is probably hard to detect automatically.
>
> Clever use of commands! (side: wouldn't it just be easier to just use
> git commit --amend, though?)

When an original commit is mostly an early part of a feature, mixed with a small but an urgent bugfix, it is not unusual to start your work from "reset HEAD^" (or "reset --soft HEAD^") and recreate a commit that has the main part of the change from the original, leaving the remainder in the working tree to be worked into another bugfix commit, most likely to be on a new branch forked from an earlier point in the history, i.e.

	git reset HEAD^
	git add -p
	git commit -c @{1}
	git checkout -m -b a-small-bugfix-split-out master
	edit
	git commit -a

I agree with both of you that we want to have a way to mark that the first commit we made by partially committing what was in the original came from the original one, and also that the second one has contents from the same original one.

It is unclear, without human involvement, if we can mechanically infer that anything that used to be built on top of the original commit would want to be rebuilt on top of the first half of the split commit (i.e. the early part of the feature with the bugfix separated out) but not on the other half (i.e. the bugfix alone).