Re: A design for subrepositories
Lauri Alanko l...@iki.fi wrote: I'm going to get a bit religious here: anything longer than a screenful shouldn't be written in shell ... Whence cometh this religion? I've heard of a modularity principle wherein no one function, in any language, ought to be longer than a page, but what's special about shell that warrants such a further restriction? BTW, to adherents of the mentioned religion, this: http://www.freebsd.org/cgi/cvsweb.cgi/ports/ports-mgmt/portmaster/files/Attic/portmaster.sh.in?rev=2.32;content-type=text/plain -- at just under 3600 lines -- is likely one of the greater heresies around :) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-jump: ignore (custom) prefix in diff mode
Mischa POSLAWSKY g...@shiar.nl wrote: ... I would argue against diff options creating non-standard patches. Seems to me it might depend on what one means by non-standard. I can envision cases in which increasing the number of context lines would result in the patch being more robust WRT applying correctly to a recipient's version that might be a bit different than the one against which it was created. OTOH one most likely does not want to create a patch with -b unless the apply tool also supports such and there is a way to communicate to the apply tool that -b was used in creating the patch. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
