Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > When you have grafts that pretend that a given commit has different > parents than the ones recorded in the commit object, it is dangerous > to let 'git repack' remove those hidden parents, as you can easily > remove the graft and end up with a broken repository. > > So let's play it safe and keep those parent objects and everything > that is reachable by them. > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > --- > > Maybe we should not even bother documenting this option? Why isn't it "--[no-]grafts-replace-parents"? "--grafts-replace-parents=no" tempts users to say =never or =false, and also suggests we might add settings with other semantics later, but I do not think of any offhand. As far as I can tell, what the updated code does when this option is in effect is not "do not replace parents", but is "use both real parents and grafted parents", which is the right thing to do (if we said "use only the true parents", then parents reachable only through grafts will be lost after repacking, which is not what we want). It would probably make more sense to call it "--keep-real-parents" or something. Do we want to cull duplicated parents? I do not think it matters in this particular context of checking the reachability, but I am just double checking if you thought about the issue. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html