Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > However, that rewriting strategy is also a useful building block in > other tasks. For example, if you want to split out a subset of files > from your history, you would typically call > > git filter-branch -- <refs> -- <files> > > But this fails for all refs that do not point directly to a commit > that affects <files>, because their referenced commit will not be > rewritten and the ref remains untouched. > > The code was already there for the --subdirectory-filter case, so just > introduce an option that enables it independently. > > Signed-off-by: Thomas Rast <trast@xxxxxxxxxxxxxxx> > Signed-off-by: Johannes Sixt <j6t@xxxxxxxx> Up to this point, nothing mentions the name of the new option. Please write your log for a person who needs to write the release notes by looking at "git shortlog" output ;-) I am wondering if this even needs an option to trigger. Shouldn't you want this behaviour always when you give any pathspec? What are the sane reasons to leave the rewritten ref to point at the old commit, essentially making the rewritten history unreachable? -- 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