Re: [PATCH] Deprecate support for .git/info/grafts

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Eric,

On Fri, 13 Apr 2018, Eric Sunshine wrote:

> On Fri, Apr 13, 2018 at 7:11 AM, Johannes Schindelin
> <johannes.schindelin@gmx.de> wrote:
> > The grafts feature was a convenient way to "stich together" ancient
> > history to the fresh start of linux.git.
> > [...]
> > The much younger feature implemented as `git replace` set out to remedy
> > those limitations and dangerous bugs.
> >
> > Seeing as `git replace` is pretty mature by now, it is time to deprecate
> > support for the graft file, and to retire it eventually.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  advice.c                  | 2 ++
> >  advice.h                  | 1 +
> >  commit.c                  | 9 +++++++++
> >  t/t6001-rev-list-graft.sh | 9 +++++++++
> >  4 files changed, 21 insertions(+)
> 
> Perhaps, as part of this deprecation, the example in
> Documentation/git-filter-branch.txt should be updated to suggest
> git-replace instead of .git/info/grafts.

Good point!

> Maybe, also, Documentation/shallow.txt should talk about replace-refs
> rather than .git/info/grafts.

Sure. Internally, of course, "shallow" is still handled very much like the
graft file. In that sense, it is probably a good thing to keep referring
to the graft file in technical/shallow *in addition* to replace refs.

The reason why the graft file should be deprecated does not apply to
the shallow file at all, either: the entire set of problems with grafts
comes from the fact that you can *replace* the parents *with other
parents*. That allows for pushing corrupt history to public repositories
IIRC. The same problems do not arise with the shallow feature, where you
can *cut* history, but not replace it.

There is a notable difference between shallow commits and replace refs
which I did not think about earlier (it actually only came up in testing):
we currently disallow completely to replace merge commits when they
contain mergetags, i.e. entries in the commit header that record the hash
of the *tag* that was merged (if any). That includes the case where you
want to replace the commit with a root commit, as would be needed for
shallow commits.

However, there are more reasons not to conflate the shallow commits with
replaced commits: by nature, the "shallow" attribute is a lot more
volatile than the "replaced" one, as we want to keep it easy to deepen the
history (or to "unshallow" it).

Ciao,
Dscho