Hi Eric, On Fri, 13 Apr 2018, Eric Sunshine wrote: > On Fri, Apr 13, 2018 at 7:11 AM, Johannes Schindelin > <johannes.schindelin@xxxxxx> 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@xxxxxx> > > --- > > 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
