Re: Working with zip files

On Tue, Aug 16, 2016 at 2:14 PM, Nikolaus Rath wrote: > On Aug 16 2016, David Lang wrote: >> On Tue, 16 Aug 2016, Nikolaus Rath wrote: >> >>> I would like to store Simulink models in a Git >>> repository. Unfortunately, the file format is binary. But luckily,

Re: git-mergetool reverse file ordering

On Mon, Aug 15, 2016 at 09:19:35PM +0100, Luis Gutierrez wrote: > > Thoughts? Would you be interested in helping work up a patch > > for this idea? At a minimum we should also write a test case in > > t/t7610-mergetool.sh to verify that it works as advertised. > > > Why not reuse the

Re: Draft of Git Rev News edition 18

On Tue, Aug 16, 2016 at 09:27:04PM +, Eric Wong wrote: > Josh Triplett wrote: > > On Tue, Aug 16, 2016 at 09:30:27AM +, Eric Wong wrote: > > > Jakub Narębski wrote: > > > > It's a great pity that https://public-inbox.org/ is just > > > > directory

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 05:15:51PM -0400, Jeff King wrote: > On Tue, Aug 16, 2016 at 02:11:41PM -0700, Josh Triplett wrote: > > > > For HTTPS, I'd just as soon use HTTP-level features. > > > > ALPN, used carefully, could potentially allow eliminating one round-trip > > compared to HTTPS, and

Re: [PATCH] Prefer "long" key format output when verifying pgp signatures

Linus Torvalds writes: > From: Linus Torvalds > Date: Tue, 16 Aug 2016 13:10:24 -0700 > Subject: [PATCH] Prefer "long" key format output when verifying pgp signatures > > Yes, gpg2 already uses the long format by default, but most >

Re: [PATCH v1 1/3] doc: commit: --fixup/--squash can take a commit revision

From: "Philip Oakley" From: "Junio C Hamano" "Philip Oakley" writes: I think the use of "commit" in an angle-bracket-pair in the label for the section, i.e. "--fixup=", has been considered to be clear enough to tell that you

Re: [PATCH v6 3/3] diff: add SUBMODULE_DIFF format to display submodule diff

Jacob Keller writes: > Thoughts on that? Or should we just limit ourselves to only some > options get propagated to the submodule? I think you have to be selective either way. You do not want pathspecs used to limit the top-level paths propagated down when you run a

Re: storing cover letter of a patch series?

From: "Duy Nguyen" On Tue, Aug 16, 2016 at 12:26 PM, Jacob Keller wrote: They can just add "squash! cover! " commits for that ;-) Though more likely the advanced workflow would be used... We'll need both (more than one) options. Or even better,

Re: Draft of Git Rev News edition 18

Josh Triplett wrote: > On Tue, Aug 16, 2016 at 09:30:27AM +, Eric Wong wrote: > > Jakub Narębski wrote: > > > It's a great pity that https://public-inbox.org/ is just > > > directory index, not a true home page. > > > > +Cc m...@public-inbox.org > >

Re: [PATCH v6 3/3] diff: add SUBMODULE_DIFF format to display submodule diff

On Tue, Aug 16, 2016 at 2:14 PM, Junio C Hamano wrote: > Jacob Keller writes: > + + if (dirty_submodule & DIRTY_SUBMODULE_MODIFIED) { + /* + * If the submodule has modified contents we want to diff +

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 02:11:41PM -0700, Josh Triplett wrote: > > For HTTPS, I'd just as soon use HTTP-level features. > > ALPN, used carefully, could potentially allow eliminating one round-trip > compared to HTTPS, and could also allow full-duplex communication. I'd love to have a real

Re: Working with zip files

On Aug 16 2016, David Lang wrote: > On Tue, 16 Aug 2016, Nikolaus Rath wrote: > >> I would like to store Simulink models in a Git >> repository. Unfortunately, the file format is binary. But luckily, the >> binary format happens to be a zipfile containing nicely formatted XML >>

Re: [PATCH v6 3/3] diff: add SUBMODULE_DIFF format to display submodule diff

Jacob Keller writes: >>> + >>> + if (dirty_submodule & DIRTY_SUBMODULE_MODIFIED) { >>> + /* >>> + * If the submodule has modified contents we want to diff >>> + * against the work tree, so don't add a second parameter. >>> +

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 04:54:27PM -0400, Jeff King wrote: > On Tue, Aug 16, 2016 at 01:31:50PM -0700, Josh Triplett wrote: > > > > You can dig up the discussion on the list under the name "protocol v2", > > > but basically yes, that approach has been considered. It's a little > > > gross just

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

Am 16.08.2016 um 10:42 schrieb Johannes Schindelin: That only leaves the conclusion that some of our pathspec code tries to be helpful and takes a backslash for a directory separator. Very true. The code that does this is in prefix_filename():

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Eric Wong wrote: > Currently for web users, I suggest: > > curl $URL >tmpXXX > > # open tmp and tag+copy to patchesXXX using MUA of choice: > # (also seems to be what Jeff describes): > mutt -f tmpXXX > > git am patches I should add this

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 01:31:50PM -0700, Josh Triplett wrote: > > You can dig up the discussion on the list under the name "protocol v2", > > but basically yes, that approach has been considered. It's a little > > gross just because it leaves other protocols behind http (and it is not > >

Re: [PATCH 1/3] diff-highlight: add some tests.

Lars Schneider writes: >> On 30 Jul 2016, at 17:11, Brian Henderson wrote: >> >> --- >> contrib/diff-highlight/Makefile | 5 ++ >> contrib/diff-highlight/t/Makefile| 19 +++ >>

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Junio C Hamano wrote: > Stefan Beller writes: > > * Should the public-inbox offer another link to patches 1-n, without > > the cover letter? Or should it add instructions: > > > > If this is a patch series you can apply it locally as: > >

Re: [PATCH v6 2/3] graph: add support for --line-prefix on all graph-aware output

On Tue, Aug 16, 2016 at 11:22 AM, Junio C Hamano wrote: > Jacob Keller writes: > >> To make this work, we have to fix a few bugs in the graph API that force >> graph_show_commit_msg to be used only when you have a valid graph. >> Additionally, we

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 11:50:11AM -0700, Stefan Beller wrote: > On Tue, Aug 16, 2016 at 11:28 AM, Jeff King wrote: > > On Tue, Aug 16, 2016 at 10:34:44AM -0700, Josh Triplett wrote: > > > >> > Sadly you cannot use a capability to fix that, because all of this > >> > happens before

[PATCH] Prefer "long" key format output when verifying pgp signatures

From: Linus Torvalds Date: Tue, 16 Aug 2016 13:10:24 -0700 Subject: [PATCH] Prefer "long" key format output when verifying pgp signatures Yes, gpg2 already uses the long format by default, but most distributions seem to still have "gpg" be the older 1.x version

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 02:28:52PM -0400, Jeff King wrote: > On Tue, Aug 16, 2016 at 10:34:44AM -0700, Josh Triplett wrote: > > > > Sadly you cannot use a capability to fix that, because all of this > > > happens before the client agrees to any capabilities (you can find > > > discussion of a

Re: [PATCH v2] rev-parse: respect core.hooksPath in --git-path

Remi Galan Alfonso writes: > Johannes Schindelin writes: >> Hi Rémi, >> >> On Tue, 16 Aug 2016, Remi Galan Alfonso wrote: >> >> > Johannes Schindelin writes: >> > > diff --git

Re: [PATCH v6 3/3] diff: add SUBMODULE_DIFF format to display submodule diff

On Tue, Aug 16, 2016 at 11:48 AM, Junio C Hamano wrote: > Jacob Keller writes: > >> diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt >> index d5a5b17d5088..f5d693afad6c 100644 >> --- a/Documentation/diff-config.txt >> +++

Re: Working with zip files

Jakub Narębski writes: > There is also `textconv` filter that can be used instead; it might > be 'unzip -c' (extract files to stdout, with filenames), or 'unzip -p' > (same, without filenames). That assumes that the in-repository data is zipped binary blob; the result won't

Re: Working with zip files

W dniu 16.08.2016 o 18:58, Junio C Hamano pisze: > David Lang writes: > >> you should be able to use clean/smudge to have git store the files >> uncompressed, which will help a lot. You can find rezip clean/smudge filter (originally intended for OpenDocument Format (ODF), that is

Re: [PATCH v3] help: make option --help open man pages only for Git commands

Ralf Thielow writes: > 2016-08-16 19:27 GMT+02:00 Junio C Hamano : >> Ralf Thielow writes: >>> + >>> + if (swapped) >>> + return help_unknown_cmd(cmd); >> >> I am guilty of suggesting "swapped"; even if we are

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 10:34:44AM -0700, Josh Triplett wrote: > > Sadly you cannot use a capability to fix that, because all of this > > happens before the client agrees to any capabilities (you can find > > discussion of a "v2" protocol on the list which solves this, but it's > > sort of

Re: [PATCH v6 3/3] diff: add SUBMODULE_DIFF format to display submodule diff

Jacob Keller writes: > diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt > index d5a5b17d5088..f5d693afad6c 100644 > --- a/Documentation/diff-config.txt > +++ b/Documentation/diff-config.txt > @@ -123,7 +123,8 @@ diff.suppressBlankEmpty:: >

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 11:28 AM, Jeff King wrote: > On Tue, Aug 16, 2016 at 10:34:44AM -0700, Josh Triplett wrote: > >> > Sadly you cannot use a capability to fix that, because all of this >> > happens before the client agrees to any capabilities (you can find >> > discussion of a

Re: [PATCH v6 2/3] graph: add support for --line-prefix on all graph-aware output

Jacob Keller writes: > To make this work, we have to fix a few bugs in the graph API that force > graph_show_commit_msg to be used only when you have a valid graph. > Additionally, we extend the default_diff_output_prefix handler to work > even when no graph is enabled.

Re: [PATCH v6 1/3] diff.c: remove output_prefix_length field

On Tue, Aug 16, 2016 at 11:03 AM, Junio C Hamano wrote: > Jacob Keller writes: > >> From: Junio C Hamano > > Thanks. I had quite a many typoes in this one. > > > No need to resend; I had it with the above fix in 'pu' for a few >

Re: [PATCH v6 1/3] diff.c: remove output_prefix_length field

Jacob Keller writes: > From: Junio C Hamano Thanks. I had quite a many typoes in this one. > "diff/log --stat" has a logic that determines the display columns > available for the diffstat part of the output and apportions it for > pathnames and

Re: [PATCH v3] help: make option --help open man pages only for Git commands

2016-08-16 19:27 GMT+02:00 Junio C Hamano : > Ralf Thielow writes: >> + >> + if (swapped) >> + return help_unknown_cmd(cmd); > > I am guilty of suggesting "swapped"; even if we are going to mark > this as OPT_HIDDEN, I think we should be

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Jeff King writes: > For my workflow, it is not about "initial skip", but rather just "skip > emails that don't have patches in them at all". OK. That is different from "the subject line says 0/N so let's skip". If we can safely determine that there is no patch in a message,

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Stefan Beller writes: > In your work flow, how do you respect the cover letter? > e.g. in 3787e3c16ced: > > Merge branch 'ew/http-backend-batch-headers' > > The http-backend (the server-side component of smart-http > transport) used to trickle the HTTP header one

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 12:31:45PM -0400, Jeff King wrote: > On Tue, Aug 16, 2016 at 09:18:39AM -0700, Josh Triplett wrote: > > > Commit 5e7dcad771cb873e278a0571b46910d7c32e2f6c in September 2013 added > > support to upload-pack to show the symbolic target of non-HEAD symbolic > > refs. However,

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On Tue, Aug 16, 2016 at 10:10 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> So as a discussion starter: >> * Should git am skip a patch 00/XX automatically ? > > No. My preference is to add "--initial-skip=", though. > > When I receive a patch

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On Tue, Aug 16, 2016 at 10:10:42AM -0700, Junio C Hamano wrote: > Stefan Beller writes: > > > So as a discussion starter: > > * Should git am skip a patch 00/XX automatically ? > > No. My preference is to add "--initial-skip=", though. > > When I receive a patch series to

Re: [PATCH v3] help: make option --help open man pages only for Git commands

Ralf Thielow writes: > builtin/help.c | 30 +++--- > git.c | 15 ++- > t/t0012-help.sh | 15 +++ > 3 files changed, 52 insertions(+), 8 deletions(-) > create mode 100755 t/t0012-help.sh > > diff --git

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Stefan Beller writes: > So as a discussion starter: > * Should git am skip a patch 00/XX automatically ? No. My preference is to add "--initial-skip=", though. When I receive a patch series to reroll another series, I somehow know and verify that earlier N patches have not

Re: Working with zip files

David Lang writes: > you should be able to use clean/smudge to have git store the files > uncompressed, which will help a lot. > > I think there's a way to tell it to do a xml aware diff/patch, but I > don't remember how. I do not know about "patch" (in the sense of "git apply"),

Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

> BTW in light of the discussion we are having elsewhere I just need to > point out that it was *dramatically* faster for me to edit run-command.c, > find "hooks/" and adjust the code manually than it would have been to save > the diff and apply it. > > That's because I do not have advanced

Re: Working with zip files

On Tue, 16 Aug 2016, Nikolaus Rath wrote: On Aug 16 2016, David Lang wrote: On Tue, 16 Aug 2016, Nikolaus Rath wrote: I would like to store Simulink models in a Git repository. Unfortunately, the file format is binary. But luckily, the binary format happens to be a zipfile

Re: Working with zip files

On Aug 16 2016, David Lang wrote: > On Tue, 16 Aug 2016, Nikolaus Rath wrote: > >> I would like to store Simulink models in a Git >> repository. Unfortunately, the file format is binary. But luckily, the >> binary format happens to be a zipfile containing nicely formatted XML >>

Re: [PATCH v3] help: make option --help open man pages only for Git commands

2016-08-16 18:33 GMT+02:00 John Keeping : > On Tue, Aug 16, 2016 at 06:20:30PM +0200, Ralf Thielow wrote: >> static struct option builtin_help_options[] = { >> + OPT_BOOL('s', "swapped", , "mark as being called by >> --help"), > > OPT_HIDDEN_BOOL maybe? > Yeah >_<

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 09:18:39AM -0700, Josh Triplett wrote: > Commit 5e7dcad771cb873e278a0571b46910d7c32e2f6c in September 2013 added > support to upload-pack to show the symbolic target of non-HEAD symbolic > refs. However, commit d007dbf7d6d647dbcf0f357545f43f36dec46f3b in > November 2013

Re: [PATCH v3] help: make option --help open man pages only for Git commands

On Tue, Aug 16, 2016 at 06:20:30PM +0200, Ralf Thielow wrote: > If option --help is passed to a Git command, we try to open > the man page of that command. However, we do it even for commands > we don't know. Make sure it is a Git command by using "help_unknown_cmd" > which is even able to

Re: Working with zip files

On Tue, 16 Aug 2016, Nikolaus Rath wrote: I would like to store Simulink models in a Git repository. Unfortunately, the file format is binary. But luckily, the binary format happens to be a zipfile containing nicely formatted XML files. Is there a way to teach Git to take advantage of this

Working with zip files

Hello, I would like to store Simulink models in a Git repository. Unfortunately, the file format is binary. But luckily, the binary format happens to be a zipfile containing nicely formatted XML files. Is there a way to teach Git to take advantage of this when storing, diff-ing and merging these

[PATCH v3] help: make option --help open man pages only for Git commands

If option --help is passed to a Git command, we try to open the man page of that command. However, we do it even for commands we don't know. Make sure it is a Git command by using "help_unknown_cmd" which is even able to assume a command if the user made a typo. This breaks "git --help" while

Re: [PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Tue, Aug 16, 2016 at 04:27:10PM +0200, Christian Couder wrote: > >> +while read unpacklimit filesize filename > >> +do > >> [...] > >> +done <<\EOF > >> +1 1024 one-k-file > >> +10 2048 two-k-file > >> +EOF > > > > Is there any reason to use different filenames and sizes for the two > > runs?

upload-pack/ls-remote: showing non-HEAD symbolic refs?

Commit 5e7dcad771cb873e278a0571b46910d7c32e2f6c in September 2013 added support to upload-pack to show the symbolic target of non-HEAD symbolic refs. However, commit d007dbf7d6d647dbcf0f357545f43f36dec46f3b in November 2013 reverted that, because it used a capability to transmit the information,

Re: [PATCH v2] rev-parse: respect core.hooksPath in --git-path

Johannes Schindelin writes: > Hi Rémi, > > On Tue, 16 Aug 2016, Remi Galan Alfonso wrote: > > > Johannes Schindelin writes: > > > diff --git a/t/t1350-config-hooks-path.sh b/t/t1350-config-hooks-path.sh > > > index 5e3fb3a..f1f9aee 100755

Re: Credential helpers processing order

On Tue, Aug 16, 2016 at 05:13:55PM +0200, Dmitry Neverov wrote: > I wonder why credential helpers are called in the order: system, > global, local, command-line and not in the reverse order? This make it > impossible to provide a custom helper and disable default ones via > command-line

Re: [PATCH v2] rev-parse: respect core.hooksPath in --git-path

Hi Rémi, On Tue, 16 Aug 2016, Remi Galan Alfonso wrote: > Johannes Schindelin writes: > > diff --git a/t/t1350-config-hooks-path.sh b/t/t1350-config-hooks-path.sh > > index 5e3fb3a..f1f9aee 100755 > > --- a/t/t1350-config-hooks-path.sh > > +++

Re: Credential helpers processing order

On Tue, Aug 16, 2016 at 8:13 AM, Dmitry Neverov wrote: > Hi, > > I wonder why credential helpers are called in the order: system, > global, local, command-line and not in the reverse order? This make it > impossible to provide a custom helper and disable default ones via

Re: storing cover letter of a patch series?

On Mon, Aug 15, 2016 at 11:45 PM, Duy Nguyen wrote: > On Tue, Aug 16, 2016 at 12:26 PM, Jacob Keller wrote: They can just add "squash! cover! " commits for that ;-) Though more likely the advanced workflow would be used... We'll need

Re: [PATCH] squash! diff: add --diff-line-prefix option for passing in a prefix

Hi Junio, On Mon, 15 Aug 2016, Junio C Hamano wrote: > Obviously (1) is a lot of impact with little gain, and as Jacob > already offered to do, I think (2) is a lot more sensible solution > and it also is more in line with your "If it isn't broken, do not > fix it", I would say. Yep, that makes

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

On Tue, Aug 16, 2016 at 05:37:35PM +0200, Johannes Schindelin wrote: > > Hrm. I am not sure I agree. At GitHub, for instance, we turn on > > core.protectNTFS for all repositories because we do want to be a vector > > for attacks. > > I trust you meant "do *not* want to be a vector for

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

Hi Peff, On Tue, 16 Aug 2016, Jeff King wrote: > On Tue, Aug 16, 2016 at 03:10:46PM +0200, Johannes Schindelin wrote: > > > > I am not convinced this mechanism needs to be built into git. > > > Because it happens to be about filenames, git at least has a hope of > > > making sense of the

Credential helpers processing order

Hi, I wonder why credential helpers are called in the order: system, global, local, command-line and not in the reverse order? This make it impossible to provide a custom helper and disable default ones via command-line parameter. My use-case is to clone a repository in a non-interactive

[PATCH v3] t/Makefile: ensure that paths are valid on platforms we care

Some pathnames that are okay on ext4 and on HFS+ cannot be checked out on Windows. Tests that want to see operations on such paths on filesystems that support them must do so behind appropriate test prerequisites, and must not include them in the source tree (instead they should create them when

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

Hi Junio, On Tue, 16 Aug 2016, Junio C Hamano wrote: > Junio C Hamano writes: > > > The trick to catch non-ascii depends on core.quotepath set to true > > (which is the default). You would need to run ls-files with an > > explicit "-c core.quotepath=false" to be safe. > >

Re: [PATCH v2] rev-parse: respect core.hooksPath in --git-path

Hi Johannes, Johannes Schindelin writes: > diff --git a/t/t1350-config-hooks-path.sh b/t/t1350-config-hooks-path.sh > index 5e3fb3a..f1f9aee 100755 > --- a/t/t1350-config-hooks-path.sh > +++ b/t/t1350-config-hooks-path.sh > @@ -34,4 +34,10 @@ test_expect_success

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

On Tue, Aug 16, 2016 at 03:10:46PM +0200, Johannes Schindelin wrote: > > I am not convinced this mechanism needs to be built into git. Because it > > happens to be about filenames, git at least has a hope of making sense > > of the various project rules. > > Both of you gentle people may recall

Re: [PATCH 0/3] limit the size of the packs we receive

On Tue, Aug 16, 2016 at 04:44:01PM +0200, Christian Couder wrote: >> [sizes and signedness of off_t] > I can add something along your explanations in the commit message if > it is prefered. I think it's probably OK without it. -Peff -- To unsubscribe from this list: send the line "unsubscribe

Re: [RFC/PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Tue, Aug 16, 2016 at 10:25:44AM +0200, Christian Couder wrote: > >> > Those are patches I plan to share upstream but just haven't gotten > >> > around to yet. > > I would be happy to help if I can on these patches too! Thanks. I'll try to extract the quarantine patches, though I have a few

Re: [PATCH 0/3] limit the size of the packs we receive

On Tue, Aug 16, 2016 at 3:11 PM, Jeff King wrote: > On Tue, Aug 16, 2016 at 10:16:58AM +0200, Christian Couder wrote: > >> - changed strtoul() to strtoumax() in the first 2 patches, as >> suggested by Peff, >> >> - changed git_config_ulong() to git_config_int64() and used

Re: [PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Tue, Aug 16, 2016 at 3:16 PM, Jeff King wrote: > On Tue, Aug 16, 2016 at 10:17:01AM +0200, Christian Couder wrote: >> >> Cleaning up what has already been written to disk is a >> related problem that is not addressed by this patch. >> >> The problem is that git-gc can clean up

Re: [PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Tue, Aug 16, 2016 at 10:17:01AM +0200, Christian Couder wrote: > From: Jeff King > > Receive-pack feeds its input to either index-pack or > unpack-objects, which will happily accept as many bytes as > a sender is willing to provide. Let's allow an arbitrary > cutoff point

[PATCH v2] rev-parse: respect core.hooksPath in --git-path

The idea of the --git-path option is not only to avoid having to prefix paths with the output of --git-dir all the time, but also to respect overrides for specific common paths inside the .git directory (e.g. `git rev-parse --git-path objects` will report the value of the environment variable

Re: [PATCH 0/3] limit the size of the packs we receive

On Tue, Aug 16, 2016 at 10:16:58AM +0200, Christian Couder wrote: > Changes from previous RFC version > ~ > > - added documentation to all the 3 patches, Good idea. > - changed strtoul() to strtoumax() in the first 2 patches, as > suggested by Peff, > >

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

Hi Peff & Junio, On Mon, 15 Aug 2016, Jeff King wrote: > On Mon, Aug 15, 2016 at 09:57:52AM -0700, Junio C Hamano wrote: > > > I wonder if we already have a good mechanism to allow a project and > > its participants (say, "me") to declare "in this project, pathnames > > must conform to this

Re: [PATCH] rev-parse: respect core.hooksPath in --git-path

On Tue, Aug 16, 2016 at 02:42:34PM +0200, Johannes Schindelin wrote: > > I think you can squash in: > > > > diff --git a/run-command.c b/run-command.c > [...] > > Good point. > > BTW in light of the discussion we are having elsewhere I just need to > point out that it was *dramatically* faster

Re: [PATCH] rev-parse: respect core.hooksPath in --git-path

Hi Peff, On Mon, 15 Aug 2016, Jeff King wrote: > On Mon, Aug 15, 2016 at 02:43:18PM +0200, Johannes Schindelin wrote: > > > The idea of the --git-path option is not only to avoid having to > > prefix paths with the output of --git-dir all the time, but also to > > respect overrides for specific

Re: Minor bug: git config ignores empty sections

On Tue, Aug 16, 2016 at 12:06:56AM -0400, Eli Barzilay wrote: > So it sounds like removing an empty header is problematic in most cases, > but adding a new variable to an existing empty header should not be...? I think it's less problematic, though there are still some funny cases. Like:

Re: Draft of Git Rev News edition 18

On Mon, Aug 15, 2016 at 8:08 PM, Jakub Narębski wrote: > W dniu 14.08.2016 o 23:10, Philip Oakley pisze: >> From: "Christian Couder" >>> >>> A draft of a new Git Rev News edition is available here: >>> >>> >>>

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

Junio C Hamano writes: > The trick to catch non-ascii depends on core.quotepath set to true > (which is the default). You would need to run ls-files with an > explicit "-c core.quotepath=false" to be safe. > ... > The invocation of "git -c core.quotepath=false ls-files" needs

Re: [PATCH v2] help: make option --help open man pages only for Git commands

On Mon, Aug 15, 2016 at 09:40:54PM +0100, Philip Oakley wrote: > From: "Junio C Hamano" > > "Philip Oakley" writes: > > > >> I'm still not sure this is enough. One of the problems back when I > >> introduced the --guides option (65f9835 (builtin/help.c:

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

Johannes Schindelin writes: >> > > By the way, doesn't ls-files take pathspec glob, saving one extra >> > > process to run grep? >> >> I specifically did not do that, sorry for omitting the rationale from the >> commit message. The reason why I have that grep is so

Re: Draft of Git Rev News edition 18

On Tue, Aug 16, 2016 at 09:30:27AM +, Eric Wong wrote: > Jakub Narębski wrote: > > It's a great pity that https://public-inbox.org/ is just > > directory index, not a true home page. > > +Cc m...@public-inbox.org > > I'm not sure one could do better while staying true to

Re: Draft of Git Rev News edition 18

Jakub Narębski wrote: > It's a great pity that https://public-inbox.org/ is just > directory index, not a true home page. +Cc m...@public-inbox.org I'm not sure one could do better while staying true to the minimalist nature of plain-text email. In the spirit of

Re: [StGit PATCH] contrib/vim: Fix filetype detection in VIM >=7.4

On 15 July 2016 at 19:58, Zane Bitter wrote: > The command "setfiletype" will not override an existing filetype. This was > never a problem for me previously, but since upgrading from VIM 7.3 to 7.4 > the filetype for StGit's files is explicitly set to "text", preventing the >

[PATCH v2] t/Makefile: make sure that paths can be checked out on platforms we care

Some pathnames that are okay on ext4 and on HFS+ cannot be checked out on Windows. Tests that want to see operations on such paths on filesystems that support them must do so behind appropriate test prerequisites, and must not include them in the source tree (instead they should create them when

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

Hi Junio, On Tue, 16 Aug 2016, Johannes Schindelin wrote: > On Mon, 15 Aug 2016, Junio C Hamano wrote: > > > Junio C Hamano writes: > > > > >> +test-lint-filenames: > > >> +@illegal="$$(git ls-files | grep '["*:<>?\\|]')"; \ > > > > > > This pattern must exclude

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

Hi Junio, On Mon, 15 Aug 2016, Junio C Hamano wrote: > Junio C Hamano writes: > > >> +test-lint-filenames: > >> + @illegal="$$(git ls-files | grep '["*:<>?\\|]')"; \ > > > > This pattern must exclude questionables on either NTFS or HFS+; it > > is ironic that it is not even

Re: [RFC/PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Tue, Aug 16, 2016 at 3:03 AM, Jeff King wrote: > On Mon, Aug 15, 2016 at 03:48:55PM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> > The simple fix is to call register_tempfile() in open_pack_file(), and >> > just have index-pack clean up the file on

Re: git cherry-pick conflict error message is deceptive when cherry-picking multiple commits

Hi Stephen, Stephen Morton writes: > +if (multiple_commits) > + advise(_("after resolving the conflicts, > mark the corrected paths with 'git add ' or 'git rm '\n" > +"then

[PATCH 2/3] unpack-objects: add --max-input-size= option

When receiving a pack-file, it can be useful to abort the `git unpack-objects`, if the pack-file is too big. Signed-off-by: Christian Couder --- Documentation/git-unpack-objects.txt | 3 +++ builtin/unpack-objects.c | 7 +++ 2 files changed, 10

[PATCH 3/3] receive-pack: allow a maximum input size to be specified

From: Jeff King Receive-pack feeds its input to either index-pack or unpack-objects, which will happily accept as many bytes as a sender is willing to provide. Let's allow an arbitrary cutoff point where we will stop writing bytes to disk. Cleaning up what has already been

[PATCH 0/3] limit the size of the packs we receive

Goal In https://public-inbox.org/git/20150612182045.GA23698%40peff.net/, Peff sent a patch that is used by GitHub to abort `git receive-pack` when the size of the pack we receive is bigger than a configured limit. GitLab is interested in using the same approach and in standardizing the

[PATCH 1/3] index-pack: add --max-input-size= option

From: Jeff King When receiving a pack-file, it can be useful to abort the `git index-pack`, if the pack-file is too big. Signed-off-by: Jeff King Signed-off-by: Christian Couder --- Documentation/git-index-pack.txt | 2 ++

Re: storing cover letter of a patch series?

On Tue, Aug 16, 2016 at 12:26 PM, Jacob Keller wrote: >>> They can just add "squash! cover! " commits for that ;-) Though more >>> likely the advanced workflow would be used... We'll need both (more than >>> one) options. >> >> Or even better, "git commit --reword $SHA1"