diff mbox series

Message ID 20190218184147.7563-1-newren@gmail.com
State New
Headers show
Series
  • Untitled series #81875
Related show

Commit Message

Elijah Newren Feb. 18, 2019, 6:41 p.m. UTC
Hi Ulrich,

Sorry for the late reply...

On Tue, Jan 22, 2019 at 11:04 PM Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:
> >>> Elijah Newren <newren@gmail.com> schrieb am 22.01.2019 um 22:29 in
> Nachricht
> > On Tue, Jan 22, 2019 at 1:05 PM Ulrich Windl
> > <Ulrich.Windl@rz.uni-regensburg.de> wrote:
> >>
> >> Using git version 2.16.4 on OpenSUSE Leap 15.0, it seems that "--no-commit"
> >> no
> >> longer does what it did before (AFAIR, but I mostly did --no-ff merges in
> >> SLES11):
> >>
> >> > git merge --no-commit local/f-linux-firefox
> >> Aktualisiere 520aaae..c11e3da
> >> Fast-forward
....
> > Indeed; the changes were committed before you ran "git merge"; they
> > were all part of the local/f-linux-firefox branch.
>
> Actually no: The changes were on a different local "remote" branch; otherwise
> I wouldn't need the merge, I guess

Yes, they were on a different branch, but since the commits already exist they don't need to be created again.  The current branch can just be updated from the current commit to the commit on the end of the other branch.  No merge is needed because the histories of the two branches have not diverged, so the merge short-circuits itself (doing what is sometimes called a "fast-forward merge" instead and avoiding almost all the normal merge logic).

> >> Reading
> >> https://stackoverflow.com/questions/8640887/git-merge-without-auto-commit
> it
> >> seems that without "--no-ff" this ioption is effectively ignored.
>
> Note: If you see the number of upvotes to the answer there, it seems I'm not
> the only one who got confused. ;-)

Indeed, and looking at that stackoverflow post, it makes it clear that the manpage is actually misleading.  I'll post a patch to correct it.

> Is moving commits from one branch to to another done without any new commit?
> Just updating the refs, or what? I didn't know that.

If the two branches have not diverged at all, and only one side has some commits that the other doesn't, then indeed there is no need for creating any new commits.  If the histories have diverged, then you need to create a merge commit and have a real merge.

> > If you want the branch to not get updated, then yes you'd need both
> > --no-ff and --no-commit in some cases.  But that's always been true.
> > It's possible in the past that you just didn't run into those cases.
>
> So it seems a commit is something other than I'd expected: To me anything that
> changes what "git log" outputs is a commit ;-) Or anything that chenges the
> reflog...

A commit is an object that records its parents (most commits have exactly one parent), its author, its committer, a commit message, and the tree involved.  Creating a new commit is a common reason to change the reflog and would cause git log to have more output for subsequent invocations.  Most merges will of necessity create a merge commit, to reflect that diverging histories have been merged (and such a commit will have more than one parent, one for each branch being merged).  But, as noted above, if histories haven't diverged then we don't need a new multi-parent commit; we can just short-circuit the merge logic and use the existing commits on the other branch.

> > Alternatively, we could update the documentation to point out this
> > special case under --no-commit to point out that when an ff-update
> > occurs no commit creation is involved and thus --no-commit has no
> > effect.  Would that help?
>
> Maybe (I'm unsure where the concepts are described best to check the current
> version(s)) try to explain the concepts of "commit" and "fast forward" in some
> greater detail. Maybe I was just expecting the wrong things to happen behind
> the scenes. Maybe add a statement like "fast-forwards never create a new
> commit, so --no-commit doesn't make sense when fast-forwarding."
>
> Thanks for the explanations.

Hopefully the patch below answers what you originally needed to know and prevents others from running into similar problems.

Thanks,
Elijah

-- 8< --
Subject: [PATCH] merge-options.txt: correct wording of --no-commit option

The former wording implied that --no-commit would always cause the
merge operation to abort and allow the user to make further changes
and/or provide a special commit message for the merge commit.  This
is not the case for fast-forward merges, as there is no merge commit
to create.  Without a merge commit, there is no place where it makes
sense to "stop the merge and allow the user to tweak changes"; doing
that would require a full rebase of some sort.

Modify the wording to correctly address fast-forward cases as well,
and suggest using --no-ff with --no-commit if the point is to ensure
that the merge aborts.

Reported-by: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
Signed-off-by: Elijah Newren <newren@gmail.com>
---
 Documentation/merge-options.txt | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

Comments

Ulrich Windl Feb. 19, 2019, 7:03 a.m. UTC | #1
>>> Elijah Newren <newren@gmail.com> schrieb am 18.02.2019 um 19:41 in
Nachricht
<20190218184147.7563-1-newren@gmail.com>:
> Hi Ulrich,
> 
> Sorry for the late reply...

No problem, thanks for the explanation. I'll "fast forward" directly to the
patch below and comment inline: -- Ulrich

[...]
> ‑‑ 8< ‑‑
> Subject: [PATCH] merge‑options.txt: correct wording of ‑‑no‑commit option
> 
> The former wording implied that ‑‑no‑commit would always cause the
> merge operation to abort and allow the user to make further changes

I think "abort" is not the perfect word, because the merge would rather be
"paused for commit" in my understanding; a "git merge --abort" is different,
right?

> and/or provide a special commit message for the merge commit.  This
> is not the case for fast‑forward merges, as there is no merge commit
> to create.  Without a merge commit, there is no place where it makes
> sense to "stop the merge and allow the user to tweak changes"; doing
> that would require a full rebase of some sort.

...and before trying the merge it's not always obvious whether the merge will
be fast-forward type or not. So actually the outcome of --no-commit depends on
the conents being merged, not on the command line options.

> 
> Modify the wording to correctly address fast‑forward cases as well,
> and suggest using ‑‑no‑ff with ‑‑no‑commit if the point is to ensure
> that the merge aborts.
> 
> Reported‑by: Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de>
> Signed‑off‑by: Elijah Newren <newren@gmail.com>
> ‑‑‑
>  Documentation/merge‑options.txt | 12 +++++++++‑‑‑
>  1 file changed, 9 insertions(+), 3 deletions(‑)
> 
> diff ‑‑git a/Documentation/merge‑options.txt
b/Documentation/merge‑options.txt
> index c2a263ba74..d1061b8cf7 100644
> ‑‑‑ a/Documentation/merge‑options.txt
> +++ b/Documentation/merge‑options.txt
> @@ ‑3,9 +3,15 @@
>  	Perform the merge and commit the result. This option can
>  	be used to override ‑‑no‑commit.
>  +
> ‑With ‑‑no‑commit perform the merge but pretend the merge
> ‑failed and do not autocommit, to give the user a chance to
> ‑inspect and further tweak the merge result before committing.
> +With ‑‑no‑commit perform the merge and stop just before creating
> +a merge commit, to give the user a chance to inspect and further
> +tweak the merge result before committing.
> ++
> +Note that fast‑forward updates do not need to create a merge
> +commit and therefore there is no way to stop those merges with
> +‑‑no‑commit.  Thus, if you want to ensure your branch is not
> +changed or updated by the merge command, use ‑‑no‑ff with
> +‑‑no‑commit.
>  
>  ‑‑edit::
>  ‑e::
> ‑‑ 
> 2.21.0.rc1.264.g6c9e06a32d
Ulrich Windl Feb. 20, 2019, 7:29 a.m. UTC | #2
>>> Junio C Hamano <gitster@pobox.com> schrieb am 19.02.2019 um 20:32 in
Nachricht
<xmqqk1hv1sms.fsf@gitster-ct.c.googlers.com>:
> Elijah Newren <newren@gmail.com> writes:
> 
>> +With ‑‑no‑commit perform the merge and stop just before creating
>> +a merge commit, to give the user a chance to inspect and further
>> +tweak the merge result before committing.
>> ++
>> +Note that fast‑forward updates do not need to create a merge
>> +commit and therefore there is no way to stop those merges with
>> +‑‑no‑commit.  Thus, if you want to ensure your branch is not
>> +changed or updated by the merge command, use ‑‑no‑ff with
>> +‑‑no‑commit.
> 
> While the above is an improvement (so I'll queue it on 'pu' not to
> lose sight of it), I find the use of "do not need to" above somewhat
> misleading.  It solicits a reaction "ok, we know it does not need
> to, but it could prepare to create one to allow us to further muck
> with it, no?".
> 
> IOW, a fast‑forward by definition does not create a merge by itself,
> so there is nowhere to stop during a creation of a merge.  So at
> least:
> 
> 	s/do not need to/do not/

Agree.

> 
> It also may be a good idea to consider detecting this case and be a
> bit more helpful, perhaps with end‑user experience looking like...
> 
>   $ git checkout master^0
>   $ git merge ‑‑no‑commit next
>   Updating 0d0ac3826a..ee538a81fe
>   Fast‑forward
>     ...diffstat follows here...
>   hint: merge completed without creating a commit.
>   hint: if you wanted to prepare for a manually tweaked merge,
>   hint: do "git reset ‑‑keep ORIG_HEAD" followed by
>   hint: "git merge ‑‑no‑ff ‑‑no‑commit next".
> 
> or even
> 
>   $ git checkout master^0
>   $ git merge ‑‑no‑commit next
>   warning: defaulting to ‑‑no‑ff, given a ‑‑no‑commit request
>   Automatic merge went well; stopped before committing as requested
>   hint: if you'd rather have a fast‑forward without creating a commit,
>   hint: do "git reset ‑‑keep next" now.
> 
> I do not have a strong preference among three (the third option
> being not doing anything), but if pressed, I'd say that the last one
> might be the most user‑friendly, even though it feels a bit too
> magical and trying to be smarter than its own good.
> 
> In any case, the hint for the "recovery" procedure needs to be
> carefully written.

Actually I think if the user specified "--no-commit" and the merge turns out
to be fast-forward, the user could be asked whether to continue or not (instead
of undoinf afterwards); maybe when entering a response is not possible (batch
processing) the merge should be aborted due to "--no-commit" not being possible
(well actually there would never be a commit, even without that option). The
problem is that without prior inspection of the tree you cannot know whether
the merge will be fast-forward or not: fast-forward being an optimization (taht
is enabled by default) makes life more complicated here.

Regards,
Ulrich Windl

Patch
diff mbox series

diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index c2a263ba74..d1061b8cf7 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -3,9 +3,15 @@ 
 	Perform the merge and commit the result. This option can
 	be used to override --no-commit.
 +
-With --no-commit perform the merge but pretend the merge
-failed and do not autocommit, to give the user a chance to
-inspect and further tweak the merge result before committing.
+With --no-commit perform the merge and stop just before creating
+a merge commit, to give the user a chance to inspect and further
+tweak the merge result before committing.
++
+Note that fast-forward updates do not need to create a merge
+commit and therefore there is no way to stop those merges with
+--no-commit.  Thus, if you want to ensure your branch is not
+changed or updated by the merge command, use --no-ff with
+--no-commit.
 
 --edit::
 -e::