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 to disclose
> the
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 is bad and people should
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 the lack of prot
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
> >> introduce comp
It would help especially when the commit message was written badly.
Or it might be possible to customize just like "git log --format"?
Thanks
> 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 form
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: .: git-sh-i18n: n
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
> rebase.instructi
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 no
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 change in the API w
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.
,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 assumption would
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
>
> This also affects
Æ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 probably only neede
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 of open-coding
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
16 matches
Mail list logo
