Re: Timezone with DATE_STRFTIME

On Mon, Feb 08, 2016 at 10:28:58AM -0500, Jeff King wrote: > On Mon, Feb 08, 2016 at 02:33:17PM +, John Keeping wrote: > > > I have just noticed that with DATE_STRFTIME, the timezone in the output > > is likely to be incorrect. > > > > For all other time formats, we print the string

Re: [PATCH] t9100: fix breakage when SHELL_PATH is not /bin/sh

[warning: experimenting with forwarding to and replying from gmail...] 2016-02-08 14:50 GMT+01:00 Jeff King : > On Sun, Feb 07, 2016 at 08:11:37PM +0100, Michael J Gruber wrote: > >> bcb11f1 (mingw: mark t9100's test cases with appropriate prereqs, 2016-01-27) >> replaced "/bin/sh"

Re: [PATCH] t9100: fix breakage when SHELL_PATH is not /bin/sh

On Mon, Feb 08, 2016 at 05:27:30PM +0100, Michael J Gruber wrote: > > I think this just re-breaks things on Windows. That first setup test > > used "chmod +x" (which is brought back by your patch), without having > > the POSIXPERM prerequisite. > > > > We probably do not want to mark the whole

git worktree loses path information after git reset --hard

Hi guys, I stumbled across a problem with worktrees recently; I incorrectly opened a ticket a GitHub for that and it was suggested that it might be fixed in 2.7.1 so I held off reporting it here but as it turned out it is still broken in 2.7.1 so here we go. The problem is that the paths of

Re: Timezone with DATE_STRFTIME

On Mon, Feb 08, 2016 at 10:28:58AM -0500, Jeff King wrote: > So I think the fix is probably just that we need to feed the zone > information to strftime via the "struct tm". Ugh, I forgot how horrible the strftime interface is. There is no zone information in "struct tm". It gets pulled from

Re: COPYING tabs vs whitespaces

On 4.2.2016 20:15, Junio C Hamano wrote: > Petr Stodulka writes: > >> I found that license file COPYING is different as compared with >> http://www.gnu.org/licenses/gpl-2.0.txt If I pass over with >> Linus's preamble, change is only about whitespaces - tabs >> vs. space.

Re: [PATCH v1] config: add '--sources' option to print the source of a config value

On Sun, Feb 07, 2016 at 08:44:50PM +0100, Lars Schneider wrote: > > Are there any other reasons why current_config_filename() would return > > NULL, besides command-line config? I don't think so. It looks like we > > can read config from stdin, but we use the token "" there for the > > name field

Re: [PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement

On Mon, Feb 08, 2016 at 09:59:18AM +0100, larsxschnei...@gmail.com wrote: > From: Lars Schneider > > The global Travis-CI environment variable CFLAGS did not override the > CFLAGS variable in the makefile. Pass CFLAGS as make variable to > override it properly. Makes

Re: Add Cc,Tested-by list while 'git commit'

On Sun, Feb 7, 2016 at 4:23 PM, Jagan Teki wrote: > Do we have any git config options to add Cc and Tested-by list like > Signed-off-by is fetched from git config. > > example: > > $ git commit -s > > Cc: Arjun Ani > Tested-by: Jagan Teki

[PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement

From: Lars Schneider The global Travis-CI environment variable CFLAGS did not override the CFLAGS variable in the makefile. Pass CFLAGS as make variable to override it properly. In addition to that, add '-Wdeclaration-after-statement' to make a Travis-CI build fail

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

2016-02-06 0:52 GMT+03:00 Junio C Hamano : > "brian m. carlson" writes: > >> On Fri, Feb 05, 2016 at 01:02:58PM -0800, Junio C Hamano wrote: >>> Hmph, so documenting that :@ >>> as a supported way might be an ugly-looking solution to the original

Re: [PATCH v1] config: add '--sources' option to print the source of a config value

On Sun, Feb 07, 2016 at 08:28:26PM +0100, Lars Schneider wrote: > > I think he inherited the "--sources" name from me. :) I agree it could > > be better. I think "--show-filename" is not right as there are > > non-filename cases. Just "--origin" sounds funny to me, perhaps because > > of git's

Re: [PATCH v1] config: add '--sources' option to print the source of a config value

On Sun, Feb 7, 2016 at 8:28 PM, Lars Schneider wrote: >>> However, the naming of the '--sources' option sounds a bit misleading to me. >>> It has nothing to do with source code. So maybe better name it '--origin', >>> or even more verbose '--show-origin' or

Re: [PATCH v1] config: add '--sources' option to print the source of a config value

On 2/5/2016 14:58, Jeff King wrote: Yeah, I agree it's unlikely. And the output is already ambiguous, as the first field could be a blob (though I guess the caller knows if they passed "--blob" or not). If we really wanted an unambiguous output, we could have something like "file:...",

Re: [PATCH v1] config: add '--sources' option to print the source of a config value

On Mon, Feb 08, 2016 at 12:25:58PM +0100, Sebastian Schuberth wrote: > On 2/5/2016 14:58, Jeff King wrote: > > >Yeah, I agree it's unlikely. And the output is already ambiguous, as the > >first field could be a blob (though I guess the caller knows if they > >passed "--blob" or not). If we

'Failed to create .git/index.lock'

Hi all, I have a single workspace where executing merges occasionally leads to a left-over .git/index.lock file that prevents me from adding resolved conflicted files. I'm running a sped-up integration/feature branch process, and the merges and conflict resolution are automated. But the

Re: [PATCH] Documentation/git-clean.txt: don't mention deletion of .git/modules/*

On Tue, Feb 09, 2016 at 12:47:39AM +0200, Mikko Rapeli wrote: > On Mon, Feb 08, 2016 at 05:36:50PM -0500, Matt McCutchen wrote: > > On Mon, 2016-02-08 at 14:22 -0800, Junio C Hamano wrote: > > > Matt McCutchen writes: > > > > > > > I found no evidence of such behavior in

Re: Bug report: 'git commit --dry-run' corner case: returns error ("nothing to commit") when all conflicts resolved to HEAD

Ovidiu Gheorghioiu wrote: > Hi git guys, > > The bug is fairly simple: if we have a conflicted merge, AND all the > conflicts have been resolved to the version in HEAD, the commit > --dry-run error code says nothing to commit. As expected, git commit > goes through. > > The

Re: [PATCH v4 06/15] submodule--helper: die on config error when cloning module

On Tue, Feb 02, 2016 at 01:45:50PM -0500, Eric Sunshine wrote: > On Tue, Feb 2, 2016 at 6:51 AM, Patrick Steinhardt wrote: > > When setting the 'core.worktree' option for a newly cloned > > submodule we ignore the return value of `git_config_set_in_file`. > > As this leaves the

Re: Timezone with DATE_STRFTIME

On Mon, Feb 08, 2016 at 02:33:17PM +, John Keeping wrote: > I have just noticed that with DATE_STRFTIME, the timezone in the output > is likely to be incorrect. > > For all other time formats, we print the string ourselves and use the > correct timezone from the input, but with DATE_STRFTIME

Re: git show doesn't work on file names with square brackets

On Mon, Feb 08, 2016 at 09:15:52AM -0500, Jeff King wrote: > I wonder if we could fix this pretty simply, though, by skipping the > "does it have a wildcard" check when we see a colon in the path. That is > a good indication that we are using one of git's special rev syntaxes > (either

Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir

On Sun, Feb 07, 2016 at 08:04:38PM -0500, Matt McCutchen wrote: > > it is very much > > appreciated when reporting bugs people check if a presumed fix is > > already cooking in 'next', try it to verify if it really fixes their > > problem, and send in a "OK fix is good" / "No that does not fix my

Re: [PATCH v4 02/15] branch: die on error in setting up tracking branch

On Mon, Feb 08, 2016 at 02:42:32PM +0100, Patrick Steinhardt wrote: > On Tue, Feb 02, 2016 at 12:49:26PM -0800, Junio C Hamano wrote: > > Patrick Steinhardt writes: > > > > > The setup_tracking function calls install_branch_config, which > > > may fail writing the configuration due

man git-config inconsistency (*.fsckObjects)

https://www.kernel.org/pub/software/scm/git/docs/git-config.html The git-config(1) man page entries for "fetch.fsckObjects" and "receive.fsckObjects" both end with the lines Defaults to false. If not set, the value of transfer.fsckObjects is used instead. These two

Re: [PATCH v4 02/15] branch: die on error in setting up tracking branch

On Tue, Feb 02, 2016 at 12:49:26PM -0800, Junio C Hamano wrote: > Patrick Steinhardt writes: > > > The setup_tracking function calls install_branch_config, which > > may fail writing the configuration due to a locked configuration > > file or other error conditions. setup_tracking

Re: git show doesn't work on file names with square brackets

On Mon, Feb 08, 2016 at 12:06:44PM +0700, Duy Nguyen wrote: > On Sun, Feb 7, 2016 at 10:11 PM, Kirill Likhodedov > wrote: > > Hi Duy, > > > >> It's from 28fcc0b (pathspec: avoid the need of "--" when wildcard is > >> used - 2015-05-02) > > > > v2.5.0 is the first

Re: git show doesn't work on file names with square brackets

On Mon, Feb 08, 2016 at 09:15:52AM -0500, Jeff King wrote: > I wonder if we could fix this pretty simply, though, by skipping the > "does it have a wildcard" check when we see a colon in the path. That is > a good indication that we are using one of git's special rev syntaxes > (either

Re: man git-config inconsistency (*.fsckObjects)

On Mon, Feb 08, 2016 at 02:41:44PM +, Markus Kuhn wrote: > https://www.kernel.org/pub/software/scm/git/docs/git-config.html > > The git-config(1) man page entries for "fetch.fsckObjects" and > "receive.fsckObjects" both end with the lines > >Defaults to false. If not set, the

Re: [PATCH] t9100: fix breakage when SHELL_PATH is not /bin/sh

On Sun, Feb 07, 2016 at 08:11:37PM +0100, Michael J Gruber wrote: > bcb11f1 (mingw: mark t9100's test cases with appropriate prereqs, 2016-01-27) > replaced "/bin/sh" in exec.sh by the shell specified in SHELL_PATH, but > that breaks the subtest which checks for a specific checksum of a tree >

Timezone with DATE_STRFTIME

I have just noticed that with DATE_STRFTIME, the timezone in the output is likely to be incorrect. For all other time formats, we print the string ourselves and use the correct timezone from the input, but with DATE_STRFTIME strftime(3) will always use the system timezone. -- To unsubscribe from

[PATCH 2/2] git-svn: apply "svn.pathnameencoding" before URL encoding

The conversion from "svn.pathnameencoding" to UTF-8 should be applied first, and then URL encoding should be applied on the resulting UTF-8 path. The reversed order of these transforms (used before this fix) makes non-UTF-8 URL which causes error from Subversion such as "Filesystem has no item:

[PATCH 1/2] git-svn: enable "svn.pathnameencoding" on dcommit

Without the initialization of $self->{pathnameencoding}, conversion in repo_path() is always skipped as $self->{pathnameencoding} is undefined even if "svn.pathnameencoding" is configured. The lack of conversion results in mysterious failure of dcommit (e.g. "Malformed XML") which happen only

[PATCH 0/2] enable "svn.pathnameencoding" on dcommit

These are small fixes to problems I encountered using git-svn with svn.pathnameencoding configuration (cp932 in my case). The problems happen only when sending changes on non-ASCII paths. I'm sorry not coming with test scripts, but I couldn't figure out how to write tests to reproduce problems

[PATCH] Use GIT_SHA1_RAWSZ as array size instead magic number 20

Signed-off-by: Brilliantov Kirill Vladimirovich --- builtin/apply.c | 4 ++-- builtin/blame.c | 2 +- builtin/cat-file.c | 8 builtin/checkout.c | 18 +- builtin/commit-tree.c | 6 +++--- builtin/commit.c|

Re: COPYING tabs vs whitespaces

Petr Stodulka writes: > On 4.2.2016 20:15, Junio C Hamano wrote: >> Petr Stodulka writes: >> >>> I found that license file COPYING is different as compared with >>> http://www.gnu.org/licenses/gpl-2.0.txt If I pass over with >>> Linus's preamble,

Re: [PATCH v3 1/7] t0027: Add tests for get_stream_filter()

tbo...@web.de writes: > From: Torsten Bögershausen > Subject: Re: [PATCH v3 1/7] t0027: Add tests for get_stream_filter() s/: Add/: add/ (no need to resend this) > When a filter is configured, a different code-path is used in convert.c > and entry.c via get_stream_filter(), but

Re: [RFC] On the --depth argument when fetching with submodules

On Sun, Feb 7, 2016 at 5:32 AM, Lars Schneider wrote: > > On 06 Feb 2016, at 01:05, Junio C Hamano wrote: > >> Stefan Beller writes: >> >>> Currently when cloning a project, including submodules, the --depth argument >>> is passed

Re: [PATCH v3 5/7] convert: auto_crlf=false and no attributes set: same as binary

tbo...@web.de writes: > From: Torsten Bögershausen > > When core.autocrlf is set to false, and no attributes are set, the file > is treated as binary. This, and also on the title, I know by "binary" you mean "no conversion is attempted", and it is the word used in the code around

Re: Merging branches with smudge filter

Leonardo writes: > Hi, everybody. I'm new to git and I'd like to keep track of some codes > we have here in our company. They have some sensitive information I > would like to keep private. After some googling, I found some > solutions that encrypt/decrypt the files using

Re: Merging branches with smudge filter

Hi. I understand what you mean, but if that's the case, I don't get how every file was merged successfully despite the encryption, except two of them. I thought the smudge filter was supposed to be applied to every blob before any git operation, thus exposing the clean source code. Well, in the

Re: man git-config inconsistency (*.fsckObjects)

On Mon, Feb 8, 2016 at 10:08 AM, Jeff King wrote: > On Mon, Feb 08, 2016 at 02:41:44PM +, Markus Kuhn wrote: >> Suggested rephrasing: >> >>If not set, the value of transfer.fsckObjects is used >>instead, which defaults to false. > > Yeah, I agree your

Re: man git-config inconsistency (*.fsckObjects)

On Mon, Feb 08, 2016 at 01:00:50PM -0500, Eric Sunshine wrote: > On Mon, Feb 8, 2016 at 10:08 AM, Jeff King wrote: > > On Mon, Feb 08, 2016 at 02:41:44PM +, Markus Kuhn wrote: > >> Suggested rephrasing: > >> > >>If not set, the value of transfer.fsckObjects is used

Re: [PATCH] Avoid interpreting too-long parameter as file name

Nguyễn Thái Ngọc Duy writes: > Even if it is easier to write HEAD~2000, it is legal to write > HEAD^^^... (repeats "^" 2000 times in total). However, such a string is > too long to be a legal filename (and on Windows, by default even much, > much shorter strings are still

Re: [PATCH v2 00/25] More flexibility in making shallow clones

Nguyễn Thái Ngọc Duy writes: > This series brings three new options to shallow clone/fetch, to let > you specify cut point by time, or by excluding some refs, or to let > you extend shallow boundary by commits. > > The series is now complete. Changes since v1 [1] > > -

Re: [PATCH v2 17/25] clone: define shallow clone boundary based on time with --shallow-since

Nguyễn Thái Ngọc Duy writes: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- It is kind of surprising that 16 & 17 can be so simple and does not have to update the way the cut-off points at the client side are computed or recorded. We must have done

Re: [PATCH v2 20/25] upload-pack: support define shallow boundary by excluding revisions

Eric Sunshine writes: >> @@ -746,6 +757,13 @@ static void receive_needs(void) >> struct object *o = want_obj.objects[i].item; >> argv_array_push(, oid_to_hex(>oid)); >> } >> + if

Re: [PATCH] t9100: fix breakage when SHELL_PATH is not /bin/sh

Hi Peff, On Mon, 8 Feb 2016, Jeff King wrote: > On Mon, Feb 08, 2016 at 08:31:54PM +0100, Johannes Schindelin wrote: > > > On Mon, 8 Feb 2016, Jeff King wrote: > > > > > Assuming your patch works on Windows > > > > If it re-introduces that chmod +x, it won't. > > > > Please note that my

Re: [RFC] On the --depth argument when fetching with submodules

Stefan Beller writes: > ... Instead of the branch, you can just pass > a sha1 to git fetch and it sometimes works (if the server permits fetching > arbitrary or hidden sha1s. Though Jonathan noted this check may be in > the client only and the server trusts the client on not

Re: [PATCH v2 03/25] transport-helper.c: do not send null option to remote helper

Duy Nguyen writes: > On Fri, Feb 5, 2016 at 6:22 AM, Junio C Hamano wrote: >> Nguyễn Thái Ngọc Duy writes: >> >>> Signed-off-by: Nguyễn Thái Ngọc Duy >>> --- >> >> This is even more strange. Are the current callers

Re: [PATCH v2 19/25] refs: add expand_ref()

Nguyễn Thái Ngọc Duy writes: > This is basically dwim_ref() without @{} support. To be used on the > server side where we want to expand abbreviated to full ref names and > nothing else. It is unclear why we want to have such an expansion on the server, though. That is

Re: [RFC] On the --depth argument when fetching with submodules

Hi, Stefan Beller wrote: > 1) You work on the superproject and don't care about the submodules. > In this case you want the superproject non-shallow and the submodules > may be just fine with depth 1. (Think of libraries pulled in via Git instead > of via the build system) > > 2) The

Re: git show doesn't work on file names with square brackets

On Mon, Feb 08, 2016 at 03:20:43PM -0500, Jeff King wrote: > On Mon, Feb 08, 2016 at 02:52:30PM -0500, Jeff King wrote: > > > Here is my patch again, with that part removed, and the tests fixed up. > > Though on reflection, I do think it would be better if we could simply > > expand the wildcard

Re: [PATCH v2 14/25] shallow.c: implement a generic shallow boundary finder based on rev-list

Nguyễn Thái Ngọc Duy writes: > Instead of a custom commit walker like get_shallow_commits(), this new > function uses rev-list to mark NOT_SHALLOW to all reachable commits, > except borders. The definition of reachable is to be defined by the > protocol later. This makes it

Re: [PATCH v2 15/25] upload-pack: add deepen-since to cut shallow repos based on time

Nguyễn Thái Ngọc Duy writes: > This should allow the user to say "create a shallow clone containing the > work from last year" (once the client side is fixed up, of course). > > In theory deepen-since and deepen (aka --depth) can be used together to > draw the shallow

Re: [PATCH v2 18/25] t5500, t5539: tests for shallow depth since a specific date

Nguyễn Thái Ngọc Duy writes: > + cd shallow-since && > + GIT_COMMITTER_DATE="1 +0700" git commit --allow-empty -m one && > + GIT_COMMITTER_DATE="2 +0700" git commit --allow-empty -m two && > + GIT_COMMITTER_DATE="3 +0700" git commit

Re: [PATCH] t9100: fix breakage when SHELL_PATH is not /bin/sh

Hi, On Mon, 8 Feb 2016, Jeff King wrote: > Assuming your patch works on Windows If it re-introduces that chmod +x, it won't. Please note that my *original* patch actually only guarded the chmod +x, but Junio suggested switching to write_script and since it passed the test suite here, I though

Re: [PATCH] t9100: fix breakage when SHELL_PATH is not /bin/sh

On Mon, Feb 08, 2016 at 08:31:54PM +0100, Johannes Schindelin wrote: > On Mon, 8 Feb 2016, Jeff King wrote: > > > Assuming your patch works on Windows > > If it re-introduces that chmod +x, it won't. > > Please note that my *original* patch actually only guarded the chmod +x, > but Junio

Re: git show doesn't work on file names with square brackets

Jeff King writes: > The patch for that might look like this. I like it for its relative > simplicity, though it does make the rules even harder to explain to a > user... True. To be bluntly honest, I do not see the current "string containing wildcard characters are taken as

Re: [PATCH] t9100: fix breakage when SHELL_PATH is not /bin/sh

Jeff King writes: > I'm confused why it matters. write_script() unconditionally calls "chmod > +x", doesn't it? Yeah, that was exactly my thought, too. Sorry for not noticing that this depended the "interpreter" exactly be /bin/sh, though (it is not even executed). > I just

Re: [PATCH v9] ident: add user.useConfigOnly boolean for when ident shouldn't be guessed

Thanks. -- 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: git show doesn't work on file names with square brackets

On Mon, Feb 08, 2016 at 02:52:30PM -0500, Jeff King wrote: > Here is my patch again, with that part removed, and the tests fixed up. > Though on reflection, I do think it would be better if we could simply > expand the wildcard globs to say "does this match anything in the file > system". That

Re: git worktree loses path information after git reset --hard

Daniel Egger writes: > I stumbled across a problem with worktrees recently; I incorrectly > opened a ticket a GitHub for that and it was suggested that it > might be fixed in 2.7.1 so I held off reporting it here but as it > turned out it is still broken in 2.7.1 so here

Re: [PATCH] t9100: fix breakage when SHELL_PATH is not /bin/sh

On Mon, Feb 08, 2016 at 11:43:19AM -0800, Junio C Hamano wrote: > > But then what is write_script buying us? > > The correct way to write a script for a specific interpreter is to > give a second parameter to write_script, i.e. > > write_script exec.sh /bin/sh > and the answer

Re: [PATCH] t9100: fix breakage when SHELL_PATH is not /bin/sh

Johannes Schindelin writes: > write_script is a semantically unambiguous way to specify what we *want*. > And it would allow us to handle chmod specifically for Windows *in one > place only*. Correct. write_script, for the intended target of the helper, is a way to

Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir

Jeff King writes: > FWIW, as the person who wrote that section, I think that is a good > addition. We do have a link to Simon Tatham's bug-reporting guide, but > this is a good place to put project-specific advice. > > In addition to "try it on next" you may want to also mention

Re: [PATCH] Documentation/git-clean.txt: don't mention deletion of .git/modules/*

On Mon, Feb 08, 2016 at 05:36:50PM -0500, Matt McCutchen wrote: > On Mon, 2016-02-08 at 14:22 -0800, Junio C Hamano wrote: > > Matt McCutchen writes: > > > > > I found no evidence of such behavior in the source code. > > > > > > Signed-off-by: Matt McCutchen

Re: [PATCH 0/2] enable "svn.pathnameencoding" on dcommit

Kazutoshi Satoda wrote: > I'm sorry not coming with test scripts, but I couldn't figure out how to > write tests to reproduce problems happen only with non-UTF-8 paths while > the tests seems to be run on UTF-8 locale. Thank you. I will try to work on some tests

Re: COPYING tabs vs whitespaces

On 8.2.2016 18:28, Junio C Hamano wrote: > Petr Stodulka writes: > >> On 4.2.2016 20:15, Junio C Hamano wrote: >>> Petr Stodulka writes: >>> I found that license file COPYING is different as compared with

[PATCH] rerere: replace strcpy with xsnprintf

This shouldn't overflow, as we are copying a sha1 hex into a 41-byte buffer. But it does not hurt to use a bound-checking function, which protects us and makes auditing for overflows easier. Signed-off-by: Jeff King --- These strcpy calls go away in jc/rerere-multi, so I was

Re: git show doesn't work on file names with square brackets

Jeff King writes: > But having looked at this, I can't help but wonder if the rule should > not be "does the file exist" in the first place, but "is the file in the > index". This dwimmery is about commands like "log" that are reading > existing commits. I cannot think of a case

Re: [PATCH] Documentation/git-clean.txt: don't mention deletion of .git/modules/*

On Mon, 2016-02-08 at 14:22 -0800, Junio C Hamano wrote: > Matt McCutchen writes: > > > I found no evidence of such behavior in the source code. > > > > Signed-off-by: Matt McCutchen > > --- > > That was added last year at bcd57cb9

Re: [PATCH] Documentation/git-clean.txt: don't mention deletion of .git/modules/*

Matt McCutchen writes: > I found no evidence of such behavior in the source code. > > Signed-off-by: Matt McCutchen > --- That was added last year at bcd57cb9 (Documentation/git-clean.txt: document that -f may need to be given twice, 2015-02-26).

[PATCH] test-path-utils: use xsnprintf in favor of strcpy

This strcpy will never overflow because it's copying from baked-in test data. But we would prefer to avoid strcpy entirely, as it makes it harder to audit for real security bugs. Signed-off-by: Jeff King --- Repost of <20160114202608.ga8...@sigill.intra.peff.net> from a few weeks

Re: [PATCH] test-path-utils: use xsnprintf in favor of strcpy

Jeff King writes: > This strcpy will never overflow because it's copying from > baked-in test data. But we would prefer to avoid strcpy > entirely, as it makes it harder to audit for real security > bugs. > > Signed-off-by: Jeff King > --- > Repost of

Re: [PATCH] test-path-utils: use xsnprintf in favor of strcpy

On Mon, Feb 08, 2016 at 11:07:26PM +, Eric Wong wrote: > Jeff King wrote: > > Repost of <20160114202608.ga8...@sigill.intra.peff.net> from a few weeks > > ago (sorry, gmane is down so I can't generate a link). > > I prefer we use links derived from Message-IDs anyways. This

Re: [PATCH] Documentation/git-clean.txt: don't mention deletion of .git/modules/*

Matt McCutchen writes: > On Mon, 2016-02-08 at 14:22 -0800, Junio C Hamano wrote: >> Matt McCutchen writes: >> >> > I found no evidence of such behavior in the source code. >> > >> > Signed-off-by: Matt McCutchen >> >

A different bug in git-filter-branch (v2.7.0)

Hi Jeff, unfortunately, `--tree-filter true` doesn't solve the problem with the repo at my work: not all old blobs are replaced with the new ones. I've made a test repository to demonstrate it; it's a huge one (115M), but I couldn't make it much smaller, because the bug fails to reproduce if the

Re: [PATCH] rerere: replace strcpy with xsnprintf

Jeff King writes: > This shouldn't overflow, as we are copying a sha1 hex into a > 41-byte buffer. But it does not hurt to use a bound-checking > function, which protects us and makes auditing for overflows > easier. > > Signed-off-by: Jeff King > --- > These

Re: [PATCH] test-path-utils: use xsnprintf in favor of strcpy

Jeff King wrote: > Repost of <20160114202608.ga8...@sigill.intra.peff.net> from a few weeks > ago (sorry, gmane is down so I can't generate a link). I prefer we use links derived from Message-IDs anyways. This prevents reliance on gmane article numbers being a central point of