On 2009.11.26 15:11:27 -0800, Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > > On Thu, Nov 26, 2009 at 9:57 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> I actually have a bigger question, though. Does it even make sense to > >> allow pathspecs to format-patch? We sure are currently loose and take > >> them, but I doubt it is by design. > > > > Not everyone has clean branches only with pertinent patches. > > > > I stumbled upon this trying to re-create (cleanly) a "branch" that was > > constantly merged into another "master" branch that had a lot more > > stuff. Maybe there was a smarter way to do that with 'git rebase', but > > that doesn't mean format-patch -- <path> shouldn't work. > > > >> The patch itself looks good and is a candidate 'maint' material, if the > >> answer to the above question is a convincing "yes, because ...". > > > > Yeah, I also think this should go into 'maint'. > > Hmm, I have not seen a clear "yes, because..." yet. > > For one thing, Documentation/git-format-patch.txt does not even hint that > you can give pathspecs. builtin_format_patch_usage[] doesn't, either. As > I wrote the initial version of format-patch I can say with some authority > that use with pathspecs were never meant to be supported---if it works, it > works by accident, giving long enough rope to users to potentially cause > themselves harm. > > I am inclined to think that we shouldn't encourage use of pathspecs (just > like we never encouraged use of options like --name-only that never makes > sense in the context of the command) but I am undecided if we also should > forbid the use of pathspecs (just like we did for --name-only recently). A year ago, there was someone who had done a subtree merge and had commits that changed the subtree in the "supertree" branch. He wanted to generate patches to send them to upstream, and ended up using format-patch with --relative and pathspecs. http://thread.gmane.org/gmane.comp.version-control.git/101742 I guess this could be done by some "git rebase -s subtree ..." invocation though, to first get commits that sit directly on the subtree branch, and then you could turn them into patches as usual... Hmm.. Björn -- 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