Re: [PATCH 30/30] subtree: be stricter about validating flags

From: Danny Lin <danny0838@gmail.com>
To: Luke Shumaker <lukeshu@lukeshu.com>
Cc: "git develop" <git@vger.kernel.org>,
	"Avery Pennarun" <apenwarr@gmail.com>,
	"Charles Bailey" <cbailey32@bloomberg.net>,
	"David A . Greene" <greened@obbligato.org>,
	"David Aguilar" <davvid@gmail.com>,
	"Jakub Suder" <jakub.suder@gmail.com>,
	"James Denholm" <nod.helm@gmail.com>, "Jeff King" <peff@peff.net>,
	"Jonathan Nieder" <jrnieder@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Roger L Strain" <roger.strain@swri.org>,
	"Techlive Zheng" <techlivezheng@gmail.com>,
	"Luke Shumaker" <lukeshu@datawire.io>,
	"Eric Sunshine" <sunshine@sunshineco.com>
Subject: Re: [PATCH 30/30] subtree: be stricter about validating flags
Date: Sun, 25 Apr 2021 10:55:17 +0800	[thread overview]
Message-ID: <CAMbsUu7PQ+Ni-fhGa3Fbc3YTODETYaPYGLPW9jqGgo=TcdPaAA@mail.gmail.com> (raw)
In-Reply-To: <20210423194230.1388945-31-lukeshu@lukeshu.com>

>
> From: Luke Shumaker <lukeshu@datawire.io>
>
> Don't silently ignore a flag that's invalid for a given subcommand.  The
> user expected it to do something; we should tell the user that they are
> mistaken, instead of surprising the user.
>
> It could be argued that this change might break existing users.  I'd
> argue that those existing users are already broken, and they just don't
> know it.  Let them know that they're broken.
>
> Signed-off-by: Luke Shumaker <lukeshu@datawire.io>
> ......

Thank you for the recent works, Luke.

I'd like to know if you are aware or working on the issue that branches
before "git subtree add --squash" are pushed via "git subtree push",
which has been reported by me at Tue, 16 Jul 2019 02:30:44 +0800, as I
haven't seen an obvious fix about it in the recent patches in a quick
glance.

Below is the original report (with a slight modification):

-----------------------------------------------------------------------

Say we have a repository with "master" and "sub" branches like below:

    A---B---C---D---E---F  master
               /
          X---Y

    X---Y  sub

where commits A and B include changes in subdirectory "sub", commit C
removes subdirectory "sub", commit D is generated by "git subtree add
-P sub Y", and commits E and F also include changes in subdirectory
"sub".

We'd get this if we run "git subtree push -P sub . sub" on master at F:

    X---Y---E'--F'  sub (after push)

On the other hand, if we have simliar trees except that commit D is
generated by "git subtree add --squash -P sub Y":

    A---B---C---D---E---F  master
               /
              Y'

    X---Y  sub

We'd expect to get this after we run "git subtree push -P sub . sub" on
master at F:

    X---Y---E'--F'  sub (after push, expected)

But actually we get this (in Git 2.22.0):

    A---B---C---D'--E'--F'  sub (after push, actual)
               /
          X---Y

This seems to be a side effect of 2.7.0 -> 2.7.1 in which a change is
made to include merged branches in "git subtree push", but mistakenly
causes branches before "git subtree add --squash" be included.

This bug is especially obvious if we simply run `git subtree push`
after a `git subtree add --squash`:

If master is at commit D, which is generated by
`git subtree add --squash -P sub Y`:

    A---B---C---D  master
               /
              Y'

    X---Y  sub

After running `git subtree push -P sub . sub`, we get:

    A---B---C---D'  sub (after push, actual)
               /
          X---Y

While the sub branch should not change at all!

This bug, seemingly introduced by 933cfeb90b5d03b4096db6d60494a6eedea25d03
critically makes --squash approach for `git subtree` almost unusable.