[PATCH] t/perf: use $MODERN_GIT for all repo-copying steps

On Fri, Mar 03, 2017 at 01:45:12AM -0500, Jeff King wrote: > I repeated the tests over fbd4a703 given in the commit message of > ee9a7002fc and confirmed that it behaves the same with your fixed > version of the test. I did have to tweak a few other things to get the > test to run against such an

Re: [PATCH v2 8/9] read_early_config(): really discover .git/

On Fri, Mar 03, 2017 at 03:04:32AM +0100, Johannes Schindelin wrote: > Earlier, we punted and simply assumed that we are in the top-level > directory of the project, and that there is no .git file but a .git/ > directory so that we can read directly from .git/config. > > However, that is not

[PATCH] t/perf: export variable used in other blocks

In p0001, a variable was created in a test_expect_success block to be used in later test_perf blocks, but was not exported. This caused the variable to not appear in those blocks (this can be verified by writing 'test -n "$commit"' in those blocks), resulting in a slightly different invocation

Re: [PATCH v7 3/3] config: add conditional include

On Wed, Mar 01, 2017 at 09:47:40AM -0800, Junio C Hamano wrote: > > @@ -185,6 +271,12 @@ int git_config_include(const char *var, const char > > *value, void *data) > > > > if (!strcmp(var, "include.path")) > > ret = handle_path_include(value, inc); > > + > > + if

Re: [PATCH] t/perf: export variable used in other blocks

On Thu, Mar 02, 2017 at 11:50:41AM -0800, Jonathan Tan wrote: > In p0001, a variable was created in a test_expect_success block to be > used in later test_perf blocks, but was not exported. This caused the > variable to not appear in those blocks (this can be verified by writing > 'test -n

Re: [PATCH v7 0/3] Conditional config include

On Wed, Mar 01, 2017 at 06:26:28PM +0700, Nguyễn Thái Ngọc Duy wrote: > I don't have a good answer for Jeff's PS about includeIf ugliness. I > agree that includeif is ugly but includeIf looks a bit better. I don't > see a better option (if only "include" does not start or end with a > vowel...).

Re: [PATCH v2 7/9] read_early_config(): avoid .git/config hack when unneeded

On Fri, Mar 03, 2017 at 03:04:28AM +0100, Johannes Schindelin wrote: > So far, we only look whether the startup_info claims to have seen a > git_dir. > > However, do_git_config_sequence() (and consequently the > git_config_with_options() call used by read_early_config() asks the > have_git_dir()

Re: [PATCH v2 6/9] read_early_config(): special-case builtins that create a repository

On Fri, Mar 03, 2017 at 03:04:24AM +0100, Johannes Schindelin wrote: > When the command we are about to execute wants to create a repository > (i.e. the command is `init` or `clone`), we *must not* look for a > repository config. Hmm. I'm not sure if this one is worth the hackery here. Yes, it

Re: log -S/-G (aka pickaxe) searches binary files by default

On Thu, Mar 02, 2017 at 05:36:17PM -0800, Junio C Hamano wrote: > On Thu, Mar 2, 2017 at 4:52 PM, Thomas Braun > wrote: > > > > I happen to have quite large binary files in my repos. > > > > Today I realized that a line like > > git log -G a > > searches also

Re: [PATCH v2 0/9] Fix the early config

On Fri, Mar 03, 2017 at 03:03:56AM +0100, Johannes Schindelin wrote: > These patches are an attempt to make Git's startup sequence a bit less > surprising. > > The idea here is to discover the .git/ directory gently (i.e. without > changing the current working directory, or global variables),

Re: [PATCH v2 9/9] Test read_early_config()

On Fri, Mar 03, 2017 at 03:04:36AM +0100, Johannes Schindelin wrote: > So far, we had no explicit tests of that function. Makes sense. The pager tests fixed in an earlier commit were effectively checking those, but I don't mind making it explicit. -Peff

Re: [PATCH v2 2/9] setup_git_directory(): use is_dir_sep() helper

On Fri, Mar 03, 2017 at 03:04:07AM +0100, Johannes Schindelin wrote: > It is okay in practice to test for forward slashes in the output of > getcwd(), because we go out of our way to convert backslashes to forward > slashes in getcwd()'s output on Windows. > > Still, the correct way to test for

Re: [PATCH v2 3/9] setup_git_directory(): avoid changing global state during discovery

On Fri, Mar 03, 2017 at 03:04:11AM +0100, Johannes Schindelin wrote: > For historical reasons, Git searches for the .git/ directory (or the > .git file) by changing the working directory successively to the parent > directory of the current directory, until either anything was found or > until a

Business proposal

-- Dear Friend, I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please, let me know if this email is valid Kind regards Adrien Saif Attorney to Qatif Group of Companies.

Re: [PATCH v2 1/9] t7006: replace dubious test

On Fri, Mar 03, 2017 at 03:04:02AM +0100, Johannes Schindelin wrote: > The intention of that test case, however, was to verify that the > setup_git_directory() function has not run, because it changes global > state such as the current working directory. > > To keep that spirit, but fix the

Re: SHA1 collisions found

On Thu, Mar 2, 2017 at 5:50 PM, Mike Hommey wrote: > > What if the "object version" is a hash of the content (as opposed to > header + content like the normal git hash)? It doesn't actually matter for that attack. The concept of the attack is actually fairly simple: generate

Re: log -S/-G (aka pickaxe) searches binary files by default

On Thu, Mar 2, 2017 at 4:52 PM, Thomas Braun wrote: > > I happen to have quite large binary files in my repos. > > Today I realized that a line like > git log -G a > searches also files found to be binary (or explicitly marked as binary). > > Is that on purpose?

Business proposal

-- Dear Friend, I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please, let me know if this email is valid Kind regards Adrien Saif Attorney to Qatif Group of Companies.

Re: [PATCH v1] Travis: also test on 32-bit Linux

Hi Junio, On Thu, 2 Mar 2017, Junio C Hamano wrote: > Another question is which v3 people mean in the discussion, when you > and Dscho work on improvements at the same time and each post the > "next" version marked as "v3", and they comment on one of them? But then, Lars & I communicate in a

[PATCH v2 9/9] Test read_early_config()

So far, we had no explicit tests of that function. Signed-off-by: Johannes Schindelin --- t/helper/test-config.c | 15 +++ t/t1309-early-config.sh | 50 + 2 files changed, 65 insertions(+) create mode

[PATCH v2 8/9] read_early_config(): really discover .git/

Earlier, we punted and simply assumed that we are in the top-level directory of the project, and that there is no .git file but a .git/ directory so that we can read directly from .git/config. However, that is not necessarily true. We may be in a subdirectory. Or .git may be a gitfile. Or the

[PATCH v2 0/9] Fix the early config

These patches are an attempt to make Git's startup sequence a bit less surprising. The idea here is to discover the .git/ directory gently (i.e. without changing the current working directory, or global variables), and to use it to read the .git/config file early, before we actually called

[PATCH v2 1/9] t7006: replace dubious test

The idea of the test case "git -p - core.pager is not used from subdirectory" was to verify that the setup_git_directory() function had not been called just to obtain the core.pager setting. However, we are about to fix the early config machinery so that it *does* work, without messing up the

[PATCH v2 6/9] read_early_config(): special-case builtins that create a repository

When the command we are about to execute wants to create a repository (i.e. the command is `init` or `clone`), we *must not* look for a repository config. Signed-off-by: Johannes Schindelin --- cache.h | 2 +- config.c | 3 ++- git.c| 3 +++ 3 files changed, 6

[PATCH v2 7/9] read_early_config(): avoid .git/config hack when unneeded

So far, we only look whether the startup_info claims to have seen a git_dir. However, do_git_config_sequence() (and consequently the git_config_with_options() call used by read_early_config() asks the have_git_dir() function whether we have a .git/ directory, which in turn also looks at git_dir

[PATCH v2 2/9] setup_git_directory(): use is_dir_sep() helper

It is okay in practice to test for forward slashes in the output of getcwd(), because we go out of our way to convert backslashes to forward slashes in getcwd()'s output on Windows. Still, the correct way to test for a dir separator is by using the helper function we introduced for that very

[PATCH v2 4/9] Export the discover_git_directory() function

The function we introduced earlier needs to return both the path to the .git/ directory as well as the "cd-up" path to allow setup_git_directory() to retain its previous behavior as if it changed the current working directory on its quest for the .git/ directory. Let's rename it and export a

[PATCH v2 5/9] Make read_early_config() reusable

The pager configuration needs to be read early, possibly before discovering any .git/ directory. Let's not hide this function in pager.c, but make it available to other callers. Signed-off-by: Johannes Schindelin --- cache.h | 1 + config.c | 31

[PATCH v2 3/9] setup_git_directory(): avoid changing global state during discovery

For historical reasons, Git searches for the .git/ directory (or the .git file) by changing the working directory successively to the parent directory of the current directory, until either anything was found or until a ceiling or a mount point is hit. Further global state may be changed,

Re: SHA1 collisions found

On Thu, Mar 02, 2017 at 02:27:15PM -0800, Linus Torvalds wrote: > On Thu, Mar 2, 2017 at 1:54 PM, Joey Hess wrote: > > > > There's a surprising result of combining iterated hash functions, that > > the combination is no more difficult to attack than the strongest hash > >

Re: SHA1 collisions found

On Thu, Mar 2, 2017 at 12:43 PM, Junio C Hamano wrote: > > My reaction heavily depends on how that "object version" thing > works. > > Would "object version" be like a truncated SHA-1 over the same data > but with different IV or something, i.e. something that guarantees >

log -S/-G (aka pickaxe) searches binary files by default

Hi, I happen to have quite large binary files in my repos. Today I realized that a line like git log -G a searches also files found to be binary (or explicitly marked as binary). Is that on purpose? The documentation of "-G" states "Look for differences whose patch text contains added/removed

Re: SHA1 collisions found

On 02/26, Jeff King wrote: > On Sun, Feb 26, 2017 at 01:13:59AM +, Jason Cooper wrote: > > > On Fri, Feb 24, 2017 at 10:10:01PM -0800, Junio C Hamano wrote: > > > I was thinking we would need mixed mode support for smoother > > > transition, but it now seems to me that the approach to

Re: SHA1 collisions found

Linus Torvalds wrote: > So you'd have to be able to attack both the full SHA1, _and_ whatever > other different good hash to 128 bits. There's a surprising result of combining iterated hash functions, that the combination is no more difficult to attack than the strongest hash function used.

[PATCH] line-log.c: prevent crash during union of too many ranges

The existing implementation of range_set_union does not correctly reallocate memory, leading to a heap overflow when it attempts to union more than 24 separate line ranges. For struct range_set *out to grow correctly it must have out->nr set to the current size of the buffer when it is passed to

Re: [PATCH 3/4] filter-branch: fix --prune-empty on parentless commits

On Thu, Mar 2, 2017 at 11:36 AM, Junio C Hamano wrote: > "Devin J. Pohly" writes: > >> I think your point is interesting too, though. If a commit is also >> TREESAME to its parent(s?) in the _pre-filtered_ branch, it seems >> reasonable that someone might

Re: SHA1 collisions found

On Thu, Mar 2, 2017 at 1:54 PM, Joey Hess wrote: > > There's a surprising result of combining iterated hash functions, that > the combination is no more difficult to attack than the strongest hash > function used. Duh. I should actually have known that. I started reading the

Re: [PATCH 3/4] filter-branch: fix --prune-empty on parentless commits

"Devin J. Pohly" writes: > On Thu, Mar 02, 2017 at 11:36:18AM -0800, Junio C Hamano wrote: >> "Devin J. Pohly" writes: >> >> > I think your point is interesting too, though. If a commit is also >> > TREESAME to its parent(s?) in the _pre-filtered_ branch,

Re: [PATCH 0/5] A series of performance enhancements in the memihash and name-cache area

Jeff Hostetler writes: > Sorry, $DAYJOB got in the way (again). > > This is still on my short-list of things to take care of. > I should have something for you next week. That's perfectly OK. I just wanted a newer articule in my newsreader I can bookmark so that

Re: [PATCH 3/4] filter-branch: fix --prune-empty on parentless commits

On Thu, Mar 02, 2017 at 11:36:18AM -0800, Junio C Hamano wrote: > "Devin J. Pohly" writes: > > > I think your point is interesting too, though. If a commit is also > > TREESAME to its parent(s?) in the _pre-filtered_ branch, it seems > > reasonable that someone might want to

Re: [PATCH v3] Documentation: Improve description for core.quotePath

This is now a single-patch, which makes sense, too. Let's merge it to 'next'. Thanks.

RE: [PATCH 0/5] A series of performance enhancements in the memihash and name-cache area

Sorry, $DAYJOB got in the way (again). This is still on my short-list of things to take care of. I should have something for you next week. Thanks again, Jeff -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Thursday, March 2, 2017 4:12 PM To: Jeff Hostetler

Re: [PATCH 0/5] A series of performance enhancements in the memihash and name-cache area

Jeff Hostetler writes: > On 2/14/2017 5:03 PM, Jeff King wrote: >> On Tue, Feb 14, 2017 at 12:31:46PM +0100, Johannes Schindelin wrote: >> >>> On Windows, calls to memihash() and maintaining the istate.name_hash and >>> istate.dir_hash HashMaps take significant time on

Re: SHA1 collisions found

Linus Torvalds writes: > Anyway, I do have a suggestion for what the "object version" would be, > but I'm not even going to mention it, because I want people to first > think about the _concept_ and not the implementation. > > So: What do you think about the

Re: Transition plan for git to move to a new hash function

brian m. carlson writes ("Re: Transition plan for git to move to a new hash function"): > On Mon, Feb 27, 2017 at 01:00:01PM +, Ian Jackson wrote: > > Objects of one hash may refer to objects named by a different hash > > function to their own. Preference rules arrange that normally, new > >

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 4:39 PM, Linus Torvalds wrote: > > Honestly, I think that a primary goal for a new hash implementation > absolutely needs to be to minimize mixing. > > Not for security issues, but because of combinatorics. You want to > have a model that

Re: git status --> Out of memory, realloc failed

Am 01.03.2017 um 21:12 schrieb Carsten Fuchs: Hi René, Am 01.03.2017 um 11:02 schrieb René Scharfe: I use Git at a web hosting service, where my user account has a memory limit of 768 MB: (uiserver):p7715773:~$ uname -a Linux infongp-de15 3.14.0-ui16322-uiabi1-infong-amd64 #1 SMP Debian

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

On Thursday 02 March 2017 at 10:33:59 -0800, Junio C Hamano wrote: > Mike Crowe writes: > > > All the solutions presented so far do cause a small change in behaviour > > when using git diff --quiet: they may now cause warning messages like: > > > > warning: CRLF will be

Re: [PATCH 5/5] ls-files: fix bug when recuring with relative pathspec

On 02/28, Junio C Hamano wrote: > Brandon Williams writes: > > > Fix a bug which causes a child process for a submodule to error out when a > > relative pathspec with a ".." is provided in the superproject. > > > > While at it, correctly construct the super-prefix to be used

Re: [PATCH 3/4] filter-branch: fix --prune-empty on parentless commits

"Devin J. Pohly" writes: > I think your point is interesting too, though. If a commit is also > TREESAME to its parent(s?) in the _pre-filtered_ branch, it seems > reasonable that someone might want to leave it in the filtered branch as > an empty commit while pruning

Re: [PATCH] Put sha1dc on a diet

On Thu, Mar 2, 2017 at 10:37 AM, Jeff Hostetler wrote: >> >> Now, if your _file_ index is 300-400MB (and I do think we check the >> SHA fingerprint on that even on just reading it - verify_hdr() in >> do_read_index()), then that's going to be a somewhat noticeable hit on

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

On 2017-03-02 15:20, Mike Crowe wrote: > ll the solutions presented so far do cause a small change in behaviour > when using git diff --quiet: they may now cause warning messages like: > > warning: CRLF will be replaced by LF in crlf.txt. > The file will have its original line endings in your

Re: [PATCH 1/3] revision: unify {tree,blob}_objects in rev_info

Jeff King writes: > On Tue, Feb 28, 2017 at 01:42:44PM -0800, Junio C Hamano wrote: > >> Jonathan Tan writes: >> >> > It could be argued that in the future, Git might need to distinguish >> > tree_objects from blob_objects - in particular, a user might

[PATCH v2] diff: do not short-cut CHECK_SIZE_ONLY check in diff_populate_filespec()

Callers of diff_populate_filespec() can choose to ask only for the size of the blob without grabbing the blob data, and the function, after running lstat() when the filespec points at a working tree file, returns by copying the value in size field of the stat structure into the size field of the

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

On Thu, Mar 02, 2017 at 09:52:21AM -0800, Junio C Hamano wrote: > >> + * and is_binary check being that we want to avoid > >> + * opening the file and inspecting the contents, this > >> + * is probably fine. > >> + */ > >>if ((flags &

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

Jeff King writes: >> diff --git a/diff.c b/diff.c >> index 8c78fce49d..dc51dceb44 100644 >> --- a/diff.c >> +++ b/diff.c >> @@ -2792,8 +2792,25 @@ int diff_populate_filespec(struct diff_filespec *s, >> unsigned int flags) >> s->should_free = 1; >>

[PATCH v3] Documentation: Improve description for core.quotePath

Linking the description for pathname quoting to the configuration variable "core.quotePath" removes inconstistent and incomplete sections while also giving two hints how to deal with it: Either with "-c core.quotePath=false" or with "-z". Signed-off-by: Andreas Heiduk ---

Re: [PATCH v1] Travis: also test on 32-bit Linux

Lars Schneider writes: >> On 02 Mar 2017, at 12:24, Johannes Schindelin >> wrote: >> >> Hi Lars, >> >> On Thu, 2 Mar 2017, Lars Schneider wrote: >> >>> The patch looks good to me in general but I want to propose the following >>>

Re: [PATCH] Put sha1dc on a diet

On 3/2/2017 11:35 AM, Linus Torvalds wrote: On Thu, Mar 2, 2017 at 6:45 AM, Johannes Schindelin wrote: It would probably make sense to switch the index integrity check away from SHA-1 because we really only care about detecting bit flips there, and we have no need

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

Mike Crowe writes: > All the solutions presented so far do cause a small change in behaviour > when using git diff --quiet: they may now cause warning messages like: > > warning: CRLF will be replaced by LF in crlf.txt. > The file will have its original line endings in your

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

On 2017-03-01 22:25, Mike Crowe wrote: > On Wednesday 01 March 2017 at 18:04:44 +0100, tbo...@web.de wrote: >> From: Junio C Hamano >> >> git diff --quiet may take a short-cut to see if a file is changed >> in the working tree: >> Whenever the file size differs from what is

Re: [PATCH 3/5] grep: fix bug when recuring with relative pathspec

On 02/28, Junio C Hamano wrote: > Brandon Williams writes: > > > /* Add super prefix */ > > + quote_path_relative(name, opt->prefix, ); > > Hmph, do you want a quoted version here, not just relative_path()? > > Perhaps add a test with an "unusual" byte (e.g. a

Re: [PATCH] mingw: use OpenSSL's SHA-1 routines

Johannes Sixt writes: > Am 24.02.2017 um 22:54 schrieb Junio C Hamano: >> Johannes Sixt writes: >>> I'll use the patch for daily work for a while to see whether it hurts. >> >> Please ping this thread again when you have something to add. For >> now, I'll demote

Re: [PATCH] Put sha1dc on a diet

On Thu, Mar 2, 2017 at 6:45 AM, Johannes Schindelin wrote: > > It would probably make sense to switch the index integrity check away from > SHA-1 because we really only care about detecting bit flips there, and we > have no need for the computational overhead of using

Re: [PATCH] Put sha1dc on a diet

Hi Duy, On Thu, 2 Mar 2017, Duy Nguyen wrote: > On Thu, Mar 2, 2017 at 6:19 AM, Jeff King wrote: > > You have to remember that some of the Git for Windows users are doing > > horrific things like using repositories with 450MB .git/index files, > > and the speed to compute the

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Thu, Mar 2, 2017 at 3:22 PM, Johannes Schindelin wrote: > >> >> +set -e >> > >> > Is this really necessary? I really like to avoid `set -e`, in >> > particular when we do pretty much everything in && chains anyway. >> >> Agreed, not really necessary here as we just

Re: Rebase sequencer changes prevent exec commands from modifying the todo file?

Hi Stephen, On Wed, 1 Mar 2017, Stephen Hicks wrote: > I have a preferred rebase workflow wherein I generate my own TODO file > with 'exec' lines that further modify the TODO file. I recently noticed > that these changes weren't sticking: they seemed to persist until the > end of the exec'd

git status reports file modified when only line-endings have changed (was git diff --quiet exits with 1 on clean tree with CRLF conversions)

On Tuesday 28 February 2017 at 19:06:44 +0100, Torsten Bögershausen wrote: > My understanding is that git diff --quiet should be quiet, when > git add will not do anything (but the file is "touched". > The touched means that Git will detect e.g a new mtime or inode > or file size when doing

Re: [PATCH v1] Travis: also test on 32-bit Linux

On 02/03/17 11:24, Johannes Schindelin wrote: > Hi Lars, > > On Thu, 2 Mar 2017, Lars Schneider wrote: > [snip] >> One thing that still bugs me: In the Linux32 environment prove adds the >> CPU times to every test run: ( 0.02 usr 0.00 sys + 0.00 cusr 0.00 >> csys ... Has anyone an idea why

Business proposal

Dear Friend, I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please, let me know if this email is valid Kind regards Adrien Saif Attorney to Qatif Group of Companies

Kannst du mir antworten

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

On Wednesday 01 March 2017 at 13:54:26 -0800, Junio C Hamano wrote: > Now I thought about it through a bit more thoroughly, I think this > is the right approach, so here is my (tenative) final version. > > I seem to be getty really rusty---after all the codepaths involved > are practically all my

Re: [PATCH v1] Travis: also test on 32-bit Linux

Hi Lars, On Thu, 2 Mar 2017, Lars Schneider wrote: > > On 02 Mar 2017, at 12:24, Johannes Schindelin > > wrote: > > > > On Thu, 2 Mar 2017, Lars Schneider wrote: > > > >> The patch looks good to me in general but I want to propose the > >> following changes: > >

Re: [PATCH] Put sha1dc on a diet

Hi Linus, On Wed, 1 Mar 2017, Linus Torvalds wrote: > On Wed, Mar 1, 2017 at 2:51 PM, Johannes Schindelin > wrote: > > > > But I think bigger than just developers on Windows OS. There are many > > developers out there working on large repositories (yes, much larger >

Re: [PATCH v1] Travis: also test on 32-bit Linux

> On 02 Mar 2017, at 12:24, Johannes Schindelin > wrote: > > Hi Lars, > > On Thu, 2 Mar 2017, Lars Schneider wrote: > >> The patch looks good to me in general but I want to propose the following >> changes: > > I know you are using your script to generate this

Re: [PATCH] Put sha1dc on a diet

Hi Peff, On Wed, 1 Mar 2017, Jeff King wrote: > I do think that could argue for turning on the collision detection only > during object-write operations, which is where it matters. It would be > really trivial to flip the "check collisions" bit on sha1dc. But I > suspect you could go faster

Re: BUG Report: v12.0.0 "git difftool -d" fails with "fatal: cannot create directory at '': No such file or directory"

Hi Mark, On Thu, 2 Mar 2017, Mark Phillips wrote: > I am building git from source using gcc 4.8.5 on 64 bit linux. > > I am sorry the log info is not very helpful, please tell me how to get > more information about what is going wrong and I will collect the info > for you! Well, you could

Re: [PATCH] README: create HTTP/HTTPS links from URLs in Markdown

On Wed, Mar 01, 2017 at 10:22:04PM +, Eric Wong wrote: > Markdown supports automatic links by surrounding URLs with > angle brackets, as documented in > One of the joys of markdown is that there are so many variants. A lot of

Re: [PATCH v5 07/24] files-backend: add and use files_refname_path()

On Wed, Mar 1, 2017 at 12:41 AM, Michael Haggerty wrote: > On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote: >> Keep repo-related path handling in one place. This will make it easier >> to add submodule/multiworktree support later. >> >> This automatically adds the "if

Re: [PATCH v5 08/24] files-backend: remove the use of git_path()

On Wed, Mar 1, 2017 at 12:50 AM, Michael Haggerty wrote: >> @@ -995,7 +998,11 @@ static struct ref_store *files_ref_store_create(const >> char *submodule) >> return ref_store; >> } >> >> - refs->packed_refs_path = git_pathdup("packed-refs"); >> +

Re: [PATCH v5 05/24] files-backend: move "logs/" out of TMP_RENAMED_LOG

On Wed, Mar 1, 2017 at 12:19 AM, Michael Haggerty wrote: >> @@ -2513,7 +2513,7 @@ static int files_delete_refs(struct ref_store >> *ref_store, >> * IOW, to avoid cross device rename errors, the temporary renamed log must >> * live into logs/refs. >> */ >> -#define

Re: [PATCH v5 24/24] t1406: new tests for submodule ref store

On Thu, Mar 2, 2017 at 3:16 PM, Michael Haggerty wrote: > The for-each-ref iteration is defined to be sorted by refname, but it's > true that the for-each-reflog order is undefined. Thanks. I'm going to add a few lines about this near for_each_ref and for_each_reflog()

Re: [PATCH v5 04/24] files-backend: convert git_path() to strbuf_git_path()

On Wed, Mar 1, 2017 at 12:06 AM, Michael Haggerty wrote: >> @@ -2681,13 +2709,19 @@ static int files_rename_ref(struct ref_store >> *ref_store, >> log_all_ref_updates = flag; >> >> rollbacklog: >> - if (logmoved && rename(git_path("logs/%s", newrefname), >>

Re: [PATCH v1] Travis: also test on 32-bit Linux

Hi Lars, On Thu, 2 Mar 2017, Lars Schneider wrote: > The patch looks good to me in general but I want to propose the following > changes: I know you are using your script to generate this mail, but I would have liked to see v2 in the subject ;-) > (1) Move all the docker magic into a dedicated

Re: git status --> Out of memory, realloc failed

On Thu, Mar 2, 2017 at 3:12 AM, Carsten Fuchs wrote: >>> The repository is tracking about 19000 files which together take 260 MB. >>> The git server version is 2.7.4.1.g5468f9e (Bitbucket) >> >> >> Is your repository publicly accessible? > > > Unfortunately, no. There are

BUG Report: v12.0.0 "git difftool -d" fails with "fatal: cannot create directory at '': No such file or directory"

I am building git from source using gcc 4.8.5 on 64 bit linux. I am sorry the log info is not very helpful, please tell me how to get more information about what is going wrong and I will collect the info for you! V2.12.0 Broken log == Export GIT_TRACE=1 git difftool -d HEAD~

[PATCH v1] Travis: also test on 32-bit Linux

From: Johannes Schindelin When Git v2.9.1 was released, it had a bug that showed only on Windows and on 32-bit systems: our assumption that `unsigned long` can hold 64-bit values turned out to be wrong. This could have been caught earlier if we had a Continuous

[PATCH] add--interactive: fix missing file prompt for patch mode with "-i"

When invoked as "git add -i", each menu interactive menu option prompts the user to select a list of files. This includes the "patch" option, which gets the list before starting the hunk-selection loop. As "git add -p", it behaves differently, and jumps straight to the hunk selection loop. Since

[PATCH v2 8/8] checkout: restrict @-expansions when finding branch

When we parse "git checkout $NAME", we try to interpret $NAME as a local branch-name. If it is, then we point HEAD to that branch. Otherwise, we detach the HEAD at whatever commit $NAME points to. We do the interpretation by calling strbuf_branchname(), and then blindly sticking "refs/heads/" on

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

On Wed, Mar 01, 2017 at 01:54:26PM -0800, Junio C Hamano wrote: > -- >8 -- > Subject: [PATCH] diff: do not short-cut CHECK_SIZE_ONLY check in > diff_populate_filespec() Thanks, this is well-explained, and the new comments in the code really help. I wondered if we should be checking

Re: [PATCH v2] fixing corner-cases with interpret_branch_name()

On Thu, Mar 2, 2017 at 12:21 AM, Jeff King wrote: > This is a re-roll of the series from: > > > http://public-inbox.org/git/20170228120633.zkwfqms57fk7d...@sigill.intra.peff.net/ > > Thanks Junio and Jake for reviewing the original. This is mostly the > same, but: > > - it

Re: [PATCH] README: create HTTP/HTTPS links from URLs in Markdown

Jeff King wrote: > On Thu, Mar 02, 2017 at 07:34:21AM +, Eric Wong wrote: > > Jeff King wrote: > > > On Wed, Mar 01, 2017 at 10:22:04PM +, Eric Wong wrote: > > > > > > > Markdown supports automatic links by surrounding URLs with > > > > angle brackets, as

[PATCH v2 7/8] strbuf_check_ref_format(): expand only local branches

This function asks strbuf_branchname() to expand any @-marks in the branchname, and then we blindly stick refs/heads/ in front of the result. This is obviously nonsense if the expansion is "HEAD" or a ref in refs/remotes/. The most obvious end-user effect is that creating or renaming a branch

[PATCH v2 4/8] interpret_branch_name: allow callers to restrict expansions

The interpret_branch_name() function converts names like @{-1} and @{upstream} into branch names. The expanded ref names are not fully qualified, and may be outside of the refs/heads/ namespace (e.g., "@" expands to "HEAD", and "@{upstream}" is likely to be in "refs/remotes/"). This is OK for

[PATCH v2 5/8] t3204: test git-branch @-expansion corner cases

git-branch feeds the branch names from the command line to strbuf_branchname(), but we do not yet tell that function which kinds of expansions should be allowed. Let's create a set of tests that cover both the allowed and disallowed cases. That shows off some breakages where we currently create

[PATCH v2 6/8] branch: restrict @-expansions when deleting

We use strbuf_branchname() to expand the branch name from the command line, so you can delete the branch given by @{-1}, for example. However, we allow other nonsense like "@", and we do not respect our "-r" flag (so we may end up deleting an oddly-named local ref instead of a remote one). We

[PATCH v2 2/8] strbuf_branchname: drop return value

The return value from strbuf_branchname() is confusing and useless: it's 0 if the whole name was consumed by an @-mark, but otherwise is the length of the original name we fed. No callers actually look at the return value, so let's just get rid of it. Signed-off-by: Jeff King ---

[PATCH v2 3/8] strbuf_branchname: add docstring

This function and its companion, strbuf_check_branch_ref(), did not have their purpose or semantics explained. Let's do so. Signed-off-by: Jeff King --- strbuf.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/strbuf.h b/strbuf.h index 47df0500d..6b51b2604

[PATCH v2 1/8] interpret_branch_name: move docstring to header file

We generally put docstrings with function declarations, because it's the callers who need to know how the function works. Let's do so for interpret_branch_name(). Signed-off-by: Jeff King --- cache.h | 21 + sha1_name.c | 21 - 2 files

[PATCH v2] fixing corner-cases with interpret_branch_name()

This is a re-roll of the series from: http://public-inbox.org/git/20170228120633.zkwfqms57fk7d...@sigill.intra.peff.net/ Thanks Junio and Jake for reviewing the original. This is mostly the same, but: - it fixes the case where "branch -r @{-1}" mistakes a local branch for a remote (and

  1   2   >