Re: [PATCH v2] commit,shallow: unparse commits if grafts changed

[Jonathan Tan <jonathantanmy@google.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Are we going to have the same issue with tags, c.f. parse_tag() and
> there being no unparse_tag()?
> 
> (I don't know offhand, just asking)
> 
> I have some semi-related (test) changes locally where we do have blind
> spots in tag v.s. commit parsing semi-related to this, i.e. in the whole
> "unparsed" stage.
> 
> So I wonder what happens with a tag that's pointing to a shallow object
> that's parsed, but its underlying commit becomes un-parsed.
> 
> Or maybe that's impossible, I'm not too familiar with "shallow"...

As Stolee said, grafts (and shallow) are only on commits.

[1] https://lore.kernel.org/git/394c054e-e1d2-41a5-a655-2ad3cb7219e0@github.com/

> Nit: Can this be
> e.g. s/repo-with-unreachable-upstream-shallow/repo/. The overly long
> repo name makes this much harder to follow. Compare this one which would
> clean up after itself too:
> 
> 	test_when_finished "rm -rf repo" && 
> 	git init repo &&
> 	git -C repo submodule add ../a-submodule a-submodule &&
> 	git -C repo commit -m "added submodule" &&
> 
> 	SHALLOW=$(cat shallow/.git/shallow) &&
> 	git -C repo fetch --update-shallow ../shallow/.git "$SHALLOW":refs/heads/a-shallow
> 
> (I didn't check if that test really works, i.e. do we have a "repo"
> already, but you get the idea...

Yes I can do that. I'll see if there are any more comments and send out
a new version after the weekend.