Re: [PATCH] git-sh-setup: Restore sourcability from outside scripts

On Sun, 30 Oct 2016, Ævar Arnfjörð Bjarmason wrote: > This did break in v2.10.0, and it's taken a couple of months to notice > this, so clearly it's not very widely used, which says something about > the cost-benefit of maintaining this for external users. For the record, in case this affects the

Re: [PATCH] commit: simplify building parents list

René Scharfe writes: > Push pptr down into the FROM_MERGE branch of the if/else statement, > where it's actually used, and call commit_list_append() for appending > elements instead of playing tricks with commit_list_insert(). Call > copy_commit_list() in the amend branch instead

Re: [PATCH] git-sh-setup: Restore sourcability from outside scripts

Ævar Arnfjörð Bjarmason writes: (commenting out of order) > It's probably worthwhile to split off git-sh-setup into git-sh-setup & > git-sh-setup-internal along with a documentation fix. A lot of what > it's doing (e.g. git_broken_path_fix(), and adding a die() function) > is

Re: [PATCH] git-sh-setup: Restore sourcability from outside scripts

Anders Kaseorg writes: > v2.10.0-rc0~45^2~2 “i18n: git-sh-setup.sh: mark strings for > translation” broke outside scripts such as guilt that source > git-sh-setup as described in the documentation: > > $ . "$(git --exec-path)/git-sh-setup" > sh: 6: .: git-sh-i18n: not found > >

Re: [PATCH] git-sh-setup: Restore sourcability from outside scripts

,On Sun, Oct 30, 2016 at 10:12 PM, Jeff King wrote: > On Sun, Oct 30, 2016 at 08:09:21PM -, Philip Oakley wrote: > >> > It is documented (Documentation/git-sh-setup.txt), and this is not the >> > internal Documentation/technical section of the documentation, so my >> > default

Re: [PATCH] git-sh-setup: Restore sourcability from outside scripts

On Sun, Oct 30, 2016 at 08:09:21PM -, Philip Oakley wrote: > > It is documented (Documentation/git-sh-setup.txt), and this is not the > > internal Documentation/technical section of the documentation, so my > > default assumption would be that everything shown there is intended as > > public.

Re: [PATCH] git-sh-setup: Restore sourcability from outside scripts

From: "Anders Kaseorg" On Sun, 30 Oct 2016, Ævar Arnfjörð Bjarmason wrote: This seems like a reasonable fix for this issue. However as far as I can tell git-sh-setup was never meant to be used by outside scripts that didn't ship as part of git itself. If that's the case any

Re: [PATCH] git-sh-setup: Restore sourcability from outside scripts

On Sun, 30 Oct 2016, Ævar Arnfjörð Bjarmason wrote: > This seems like a reasonable fix for this issue. However as far as I > can tell git-sh-setup was never meant to be used by outside scripts > that didn't ship as part of git itself. > > If that's the case any change in the API which AFAICT is

[PATCH] doc: fix missing "::" in config list

On Sun, Oct 30, 2016 at 07:21:41PM +0200, Alexei Lozovsky wrote: > > It would help especially when the commit message was written badly. > > > > Or it might be possible to customize just like "git log --format"? > > It is possible to change the format globally via config option >

Re: [PATCH] git-sh-setup: Restore sourcability from outside scripts

On Sun, Oct 30, 2016 at 3:10 AM, Anders Kaseorg wrote: > v2.10.0-rc0~45^2~2 “i18n: git-sh-setup.sh: mark strings for > translation” broke outside scripts such as guilt that source > git-sh-setup as described in the documentation: > > $ . "$(git --exec-path)/git-sh-setup" > sh: 6:

Re: [git rebase -i] show time and author besides commit hash and message?

> It would help especially when the commit message was written badly. > > Or it might be possible to customize just like "git log --format"? It is possible to change the format globally via config option rebase.instructionFormat: $ git config rebase.instructionFormat "%an (%ad): %s" The

[git rebase -i] show time and author besides commit hash and message?

It would help especially when the commit message was written badly. Or it might be possible to customize just like "git log --format"? Thanks

Re: Expanding Includes in .gitignore

On Fri, Oct 28, 2016 at 10:32:07PM +1300, Aaron Pelly wrote: > On 28/10/16 15:54, Junio C Hamano wrote: > > Jeff King writes: > > > >> However, as I said elsewhere, I'm not convinced this feature is all that > >> helpful for in-repository .gitignore files, and I think it does >

Re: Fetch/push lets a malicious server steal the targets of "have" lines

Jon Loeliger writes: > Is there an existing protocol provision, or an extension to > the protocol that would allow a distrustful client to say to > the server, "Really, you have Y2? Prove it." There is not, but I do not think it would be an effective solution. The issue is not

Re: Fetch/push lets a malicious server steal the targets of "have" lines

Matt McCutchen writes: > On Fri, 2016-10-28 at 22:31 -0700, Junio C Hamano wrote: >> Not sending to the list, where mails from Gmail/phone is known to get >> rejected. > > [I guess I can go ahead and quote this to the list.] > >> No. I'm saying that the scenario you gave

Re: Fetch/push lets a malicious server steal the targets of "have" lines

Jeff King writes: > ... It is not thinking about what secret things are hitting the > master that you are pushing, no matter how they got there. > > I agree there is a potential workflow (that you have laid out) where > such lying can cause an innocent-looking sequence of events