Re: [PATCH 1/3] Documentation/stash: remove mention of git reset --hard

On 01/25, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > On Sat, Jan 21, 2017 at 08:08:02PM +0000, Thomas Gummerer wrote: > > > >> diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt > >> index 2e9cef06e6..0ad5

[PATCH 3/3] stash: support filename argument

files. Add an optional filename argument to git stash push, which allows for stashing a single (or multiple) files. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- Documentation/git-stash.txt | 8 git-stash.sh| 42 ++-

[PATCH 1/3] Documentation/stash: remove mention of git reset --hard

Don't mention git reset --hard in the documentation for git stash save. It's an implementation detail that doesn't matter to the end user and thus shouldn't be exposed to them. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- Documentation/git-stash.txt | 5 +++-- 1 file chan

[PATCH 0/3] stash: support filename argument

]: https://public-inbox.org/git/20170115142542.11999-1-t.gumme...@gmail.com/T/ Thomas Gummerer (3): Documentation/stash: remove mention of git reset --hard stash: introduce push verb stash: support filename argument Documentation/git-stash.txt | 13 - git-stash.sh| 123

[PATCH 2/3] stash: introduce push verb

filename argument to stash single files. Using that as a positional argument is much more consistent with the rest of git, than using the positional argument for the message. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- git-stash.sh

Re: [RFC] stash: support filename argument

On 01/15, Junio C Hamano wrote: > Thomas Gummerer <t.gumme...@gmail.com> writes: > > > While working on a repository, it's often helpful to stash the changes > > of a single or multiple files, and leave others alone. Unfortunately > > git currently offers no

Re: feature request: allow to stash changed files

On 01/15, KES wrote: > http://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git#comment32451416_3040833 > > Sometimes poople are forced to save stash for changed files. But there is no > such option ( You may just be lucky. I've been

[RFC] stash: support filename argument

files. Add a --file option to git stash save, which allows for stashing a single file. Specifying the --file argument multiple times allows stashing more than one file at a time. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- Marked as RFC and without documentation updates to

Re: [PATCH tg/add-chmod+x-fix 2/2] t3700-add: protect one --chmod=+x test with POSIXPERM

On 09/21, Junio C Hamano wrote: > Johannes Sixt writes: > > > But I came to a different conclusion as I said in a message that > > crossed yours. I hope Thomas can pick up the baton again. Sorry for not getting back earlier, my git time is quite limited unfortunately. > Yeah,

Re: [PATCH tg/add-chmod+x-fix 2/2] t3700-add: protect one --chmod=+x test with POSIXPERM

Hi Johannes, On 09/20, Johannes Sixt wrote: > A recently introduced test checks the result of 'git status' after > setting the executable bit on a file. This check does not yield the > expected result when the filesystem does not support the executable bit > (and core.filemode is false). Skip the

Re: [PATCH tg/add-chmod+x-fix 1/2] t3700-add: create subdirectory gently

Hi Johannes, On 09/20, Johannes Sixt wrote: > The subdirectory 'sub' is created early in the test file. Later, a test > case removes it during its clean-up actions. However, this test case is > protected by POSIXPERM. Consequently, 'sub' remains when the POSIXPERM > prerequisite is not satisfied.

Re: [PATCH v4 3/4] read-cache: introduce chmod_index_entry

On 09/14, Junio C Hamano wrote: > I've queued this trivial SQUASH??? on top, which I think should be > squashed into 3/4. Yeah, I missed this. The SQUASH??? definitely makes sense, would be great if you could just squash that in. > Thanks. Thanks the reviews and helping me getting the series

[PATCH v4 3/4] read-cache: introduce chmod_index_entry

As there are chmod options for both add and update-index, introduce a new chmod_index_entry function to do the work. Use it in update-index, while it will be used in add in the next patch. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/update-index.

[PATCH v4 2/4] update-index: add test for chmod flags

, which takes an int, but had a char passed in. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/update-index.c| 2 +- t/t2107-update-index-basic.sh | 13 + 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/builtin/update-index.c b/builtin/

[PATCH v4 4/4] add: modify already added files when --chmod is given

, regardless of the status of the file, make sure the option behaves the same way in git add. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/add.c | 47 --- builtin/checkout.c | 2 +- builtin/commit.c | 2 +- cache.h

[PATCH v4 0/4] git add --chmod: always change the file

be + or -, and changes the mode based on that, instead of using the 0777 or 0666 mode that was passed in from the outside. [4/4]: Adapted to the different behaviour of chmod_index_entry and added tests as suggested by Junio. Thomas Gummerer (4): add: document the chmod option

[PATCH v4 1/4] add: document the chmod option

The git add --chmod option was introduced in 4e55ed3 ("add: add --chmod=+x / --chmod=-x options", 2016-05-31), but was never documented. Document the feature. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- Documentation/git-add.txt | 7 ++- 1 file changed, 6

[PATCH v3 4/4] add: modify already added files when --chmod is given

, regardless of the status of the file, make sure the option behaves the same way in git add. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/add.c | 36 +--- builtin/checkout.c | 2 +- builtin/commit.c | 2 +- cache.h

[PATCH v3 2/4] update-index: use the same structure for chmod as add

While the chmod options for update-index and the add have the same functionality, they are using different ways to parse and handle the option internally. Unify these modes in order to make further refactoring simpler. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/

[PATCH v3 3/4] read-cache: introduce chmod_index_entry

As there are chmod options for both add and update-index, introduce a new chmod_index_entry function to do the work. Use it in update-index, while it will be used in add in the next patch. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/update-index.c | 8 +--- c

[PATCH v3 1/4] add: document the chmod option

The git add --chmod option was introduced in 4e55ed3 ("add: add --chmod=+x / --chmod=-x options", 2016-05-31), but was never documented. Document the feature. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- Documentation/git-add.txt | 7 ++- 1 file changed, 6

[PATCH v3 0/4] git add --chmod: always change the file

is useful, when we can keep the behaviour with multiple arguments in update-index the same. Thomas Gummerer (4): add: document the chmod option update-index: use the same structure for chmod as add read-cache: introduce chmod_index_entry add: modify already added files when --chmod is given

Re: [PATCH v2 2/4] update-index: use the same structure for chmod as add

On 09/11, Junio C Hamano wrote: > Thomas Gummerer <t.gumme...@gmail.com> writes: > > > @@ -955,10 +941,8 @@ int cmd_update_index(int argc, const char **argv, > > const char *prefix) > > PARSE_OPT_NOARG | /* disallow --cacheinfo= form */ > >

Re: Bug: git-add .* errors out

Hi, On 09/12, Pranit Bauva wrote: > Hey everyone, > > One of my friend was trying to add files using the command `git add > .*` and got an error that "fatal: ..: '..' is outside repository" > which did seem a little obvious to me. But then I tried to reproduce > it in my machine with `git add

[PATCH v2 3/4] read-cache: introduce chmod_index_entry

As there are chmod options for both add and update-index, introduce a new chmod_index_entry function to do the work. Use it in update-index, while it will be used in add in the next patch. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/update-index.c | 8 +--- c

[PATCH v2 4/4] add: modify already added files when --chmod is given

, regardless of the status of the file, make sure the option behaves the same way in git add. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/add.c | 36 +--- builtin/checkout.c | 2 +- builtin/commit.c | 2 +- cache.h

[PATCH v2 2/4] update-index: use the same structure for chmod as add

While the chmod options for update-index and the add have the same functionality, they are using different ways to parse and handle the option internally. Unify these modes in order to make further refactoring simpler. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/

[PATCH v2 0/4] git add --chmod: always change the file

Changes since v1: Added missing x in the documentation. The changes since v1 are only minor, but as it's been a week, this is as much a ping as a fixup of my error :) Thomas Gummerer (4): add: document the chmod option update-index: use the same structure for chmod as add read-cache

[PATCH v2 1/4] add: document the chmod option

The git add --chmod option was introduced in 4e55ed3 ("add: add --chmod=+x / --chmod=-x options", 2016-05-31), but was never documented. Document the feature. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- Documentation/git-add.txt | 7 ++- 1 file changed, 6

Re: [PATCH 1/4] add: document the chmod option

Hi Johannes, On 09/05, Johannes Schindelin wrote: > Hi Thomas, > > On Sun, 4 Sep 2016, Thomas Gummerer wrote: > > > +--chmod=(+|-):: > > There is an "x" missing ;-) Ugh, thanks for catching. I'll wait a few days for more comments and address it in a re-roll. > Ciao, > Dscho

[PATCH 1/4] add: document the chmod option

The git add --chmod option was introduced in 4e55ed3 ("add: add --chmod=+x / --chmod=-x options", 2016-05-31), but was never documented. Document the feature. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- Documentation/git-add.txt | 7 ++- 1 file changed, 6

[PATCH 0/4] git add --chmod: always change the file

Thanks to Peff and Junio for your inputs on the best way to solve this problem. The patch series is made up as follows: [1/4]: Documentation for the chmod option [2,3/4]: Small refactoring to simplify the final step [4/4]: The actual change that introduces the new behaviour. Thomas Gummerer (4

[PATCH 2/4] update-index: use the same structure for chmod as add

While the chmod options for update-index and the add have the same functionality, they are using different ways to parse and handle the option internally. Unify these modes in order to make further refactoring simpler. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/

[PATCH 3/4] read-cache: introduce chmod_index_entry

As there are chmod options for both add and update-index, introduce a new chmod_index_entry function to do the work. Use it in update-index, while it will be used in add in the next patch. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/update-index.c | 8 +--- c

[PATCH 4/4] add: modify already added files when --chmod is given

, regardless of the status of the file, make sure the option behaves the same way in git add. Reported-by: Jan Keromnes <j...@linux.com> Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/add.c | 36 +--- builtin/checkout.c | 2 +- buil

Re: `make profile-install` fails in 2.9.3

[+cc Edward Thomson, Ingo Brückl] Hi, On 09/01, Jan Keromnes wrote: [.. snip the parts others are more qualified to answer ..] > > Related problem: `t3700-add.sh` currently fails in 2.9.3. I can > provide more debug information if you don't already know this problem. I noticed this problem as

[PATCH v2] blame: fix segfault on untracked files

h.org> Helped-by: Junio C Hamano <gits...@pobox.com> Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- > The point of this fix is not that we show the exact error message, > but we fail in a controlled manner. I think > > test_expect_suc

Re: Crash when using git blame on untracked file

uld lexicographically be sorted as the last file in the repository, -cache_name_pos - 1 is outside of the length of the active_cache array, causing git blame to segfault. Guard against that, and die() normally to restore the old behaviour. Reported-by: Simon Ruderich <si...@ruderich.org> Signe

Re: [PATCH 1/2] Do not output whitespace on blank lines

On 05/29, Dave Nicolson wrote: > --- The commit message should describe why you think this is a good change. Without the commit message I don't see how this is a improvement. It is also missing your Sign-off (see Documentation/SubmittingPatches section 5). The test changes you sent in Patch

Re: [PATCH/RFC/GSoC 01/17] perf: introduce performance tests for git-rebase

On 03/18, Johannes Schindelin wrote: > Hi Thomas, > > On Fri, 18 Mar 2016, Thomas Gummerer wrote: > > > On 03/16, Johannes Schindelin wrote: > > > Hrm. rebase -f just makes the reset an implicit part of the rebase, so it > > > seems we cannot perf *just* th

Re: [GSoC] Introduction and Project Discussion

Hi, On 03/19, Chirayu Desai wrote: > Hi, > > I am a first year computer engineering student from India, studying at > the Silver Oak College of Engineering and Technology, > I had already put part of this in "[PATCH/GSoC] pull: implement > --[no-]autostash for usage when rebasing", but at that

Re: [PATCH/RFC/GSoC 01/17] perf: introduce performance tests for git-rebase

On 03/16, Johannes Schindelin wrote: > Hi Paul, > > On Wed, 16 Mar 2016, Paul Tan wrote: > > > On Wed, Mar 16, 2016 at 3:58 PM, Johannes Schindelin > > wrote: > > > > > > On Sat, 12 Mar 2016, Paul Tan wrote: > > > > > >> diff --git

Re: GSoC 2016 Microproject

On 03/01, Sidhant Sharma wrote: > > > If you use PARSE_OPT_HIDDEN, I think you don't need to specify a message. > > Otherwise, the documentation only has value if it contains more than just > > the option name, but that is the hard part if you're not familiar with the > > code. The best place

Re: Some strange behavior of git

[Please keep everyone cc'd in the conversation, especially the mailing list. I added it back for now. Also please don't top post on the list] On 02/25, Olga Pshenichnikova wrote: > No, it isn't empty, but I found the problem. > Problem was that I handled subdirectories structure in exclude file:

Re: Some strange behavior of git

On 02/25, Olga Pshenichnikova wrote: > Hello, > we use git in our project. > What can be cause for further confusing behavior? > > git@ip5server:~$ git status > On branch master > Untracked files: > (use "git add ..." to include in what will be committed) > >

Re: GSoC 2016: applications open, deadline = Fri, 19/2

On 02/18, Lars Schneider wrote: > > On 17 Feb 2016, at 19:58, Matthieu Moy wrote: > > > Lars Schneider writes: > > > >> Coincidentally I started working on similar thing already (1) and I have > >> lots of ideas around it. > > > > I guess

Re: GSoC 2016: applications open, deadline = Fri, 19/2

On 02/10, Matthieu Moy wrote: > Work on the application itself, and on the list of ideas. One potential idea: Make destructive git commands more safe for the user. Some commands (e.g. git reset --hard, git clean -f, etc.) can potentially destroy some of the users work. Store the information

Re: [PATCH 4/4] remote: use remote_is_configured() for add and rename

On 02/17, Johannes Schindelin wrote: > Hi Peff & Thomas, > > On Mon, 15 Feb 2016, Jeff King wrote: > > This original is quite confusing. I thought at first that there was > > perhaps something going on with allowing repeated re-configuration of > > the same remote, as long as some parameters

[PATCH v3 3/4] remote: actually check if remote exits

ror if we try to rename a remote. Use the remote_is_configured() function to check whether the remote actually exists, and die with a more sensible error message ("No such remote: $remotename") instead if it doesn't. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/remo

[PATCH v3 2/4] remote: simplify remote_is_configured()

of struct remote instead, which indicates where the remote comes from. It will be set to some value if the remote is configured in any file in the repository, but is initialized to 0 if the remote is only created in make_remote(). Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- b

[PATCH v3 4/4] remote: use remote_is_configured() for add and rename

foo with the configuration for foo as above silently succeeds, even though foo already exists, modifying its configuration. With this patch it fails with "remote foo already exists". Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/remote.c | 7 ++- t/t5505-remot

[PATCH v3 0/4] git remote improvements

test_when_finished git remote rm foo && - test_when_finished git remote rm bar && + test_config remote.foo.vcs bar && + test_config remote.bar.vcs bar && echo "fatal: remote bar already exists." >expect && te

[PATCH v3 1/4] remote: use parse_config_key

by the aformentioned commit, but can be replaced by calls to parse_config_key(), to simplify the code and clarify the intentions. Do that. Helped-by: Jeff King <p...@peff.net> Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- remote.c | 69 ++-

Re: [PATCH v2 4/4] remote: use remote_is_configured() for add and rename

On 02/15, Jeff King wrote: > On Mon, Feb 15, 2016 at 05:52:14PM -0500, Eric Sunshine wrote: > > > > diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh > > > @@ -157,6 +157,24 @@ test_expect_success 'rename errors out early when > > > deleting non-existent branch' > > > +test_expect_success 'add

Re: [PATCH v2 1/4] remote: use parse_config_key

On 02/15, Jeff King wrote: > On Mon, Feb 15, 2016 at 11:39:41PM +0100, Thomas Gummerer wrote: > > > - if (!starts_with(key, "remote.")) > > + if (parse_config_key(key, "remote", , , ) < 0) > > return 0; > > - nam

[PATCH v2 1/4] remote: use parse_config_key

by the aformentioned commit, but can be replaced by calls to parse_config_key(), to simplify the code and clarify the intentions. Do that. Helped-by: Jeff King <p...@peff.net> Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- remote.c | 71 ++-

[PATCH v2 3/4] remote: actually check if remote exits

ror if we try to rename a remote. Use the remote_is_configured() function to check whether the remote actually exists, and die with a more sensible error message ("No such remote: $remotename") instead if it doesn't. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/remo

[PATCH v2 4/4] remote: use remote_is_configured() for add and rename

foo with the configuration for foo as above silently succeeds, even though foo already exists, modifying its configuration. With this patch it fails with "remote foo already exists". Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/remote.c | 7 ++- t/t5505-

[PATCH v2 2/4] remote: simplify remote_is_configured()

of struct remote instead, which indicates where the remote comes from. It will be set to some value if the remote is configured in any file in the repository, but is initialized to 0 if the remote is only created in make_remote(). Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- b

[PATCH v2 0/4] git remote improvements

_string((const char **)>http_proxy_authmethod, key, value); - } else if (!strcmp(subkey, ".vcs")) { + } else if (!strcmp(subkey, "vcs")) { return git_config_string(>foreign_vcs, key, value); }

Re: [PATCH 4/4] remote: use remote_is_configured() for add and rename

On 02/15, Jeff King wrote: > On Mon, Feb 15, 2016 at 06:42:30PM +0100, Thomas Gummerer wrote: > > > Both remote add and remote rename use a slightly different hand-rolled > > check if the remote exits. The hand-rolled check may have some subtle > > cases in which it m

Re: [PATCH 2/4] remote: simplify remote_is_configured()

On 02/15, Jeff King wrote: > On Mon, Feb 15, 2016 at 06:42:28PM +0100, Thomas Gummerer wrote: > > > The remote_is_configured() function allows checking whether a remote > > exists or not. The function however only works if remote_get() wasn't > > called before calling i

Re: [PATCH 1/4] remote: use skip_prefix

On 02/15, Jeff King wrote: > On Mon, Feb 15, 2016 at 06:42:27PM +0100, Thomas Gummerer wrote: > > > 95b567c7 ("use skip_prefix to avoid repeating strings") transformed > > calls using starts_with() and then skipping the length of the prefix to > > skip_prefix() c

[PATCH 1/4] remote: use skip_prefix

ouched by the commit mentioned above, but can benefit from the same treatment to avoid magic numbers. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- remote.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/remote.c b/remote.c index 02e698a..4b5b576 100644 ---

[PATCH 3/4] remote: actually check if remote exits

ror if we try to rename a remote. Use the remote_is_configured() function to check whether the remote actually exists, and die with a more sensible error message ("No such remote: $remotename") instead if it doesn't. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/remo

[PATCH 4/4] remote: use remote_is_configured() for add and rename

foo with the configuration for foo as above silently succeeds, even though foo already exists, modifying its configuration. With this patch it fails with "remote foo already exists". Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/remote.c | 7 ++- t/t5505-

[PATCH 2/4] remote: simplify remote_is_configured()

of struct remote instead, which indicates where the remote comes from. It will be set to some value if the remote is configured in any file in the repository, but is initialized to 0 if the remote is only created in make_remote(). Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- b

[PATCH 0/4] git remote improvements

) add an option not to die in the transport function, and let the caller of get_remote_ref_states handle the error i.e. show the error and keep going with the next remote. (3) anything I might be missing? Thomas Gummerer (4): remote: use skip_prefix remote: simplify remote_is_configured

Re: [PATCH] Implement https public key pinning

On 02/12, Christoph Egger wrote: > Daniel Stenberg writes: > > On Thu, 11 Feb 2016, Christoph Egger wrote: > >> +#if LIBCURL_VERSION_NUM >= 0x074400 > > > > That should probably be 0x072c00 ... > > This is, of course, right. > > I used 7.44 / 0x072c00 as base because it has robust

Re: [PATCH 2/2] stash: use "stash--helper"

On 01/28, Stefan Beller wrote: > On Thu, Jan 28, 2016 at 12:36 PM, Matthias Asshauer wrote: > > From: Matthias Aßhauer > > > > Use the new "git stash--helper" builtin. It should be faster than the old > > shell code and is a first step to move > > more shell

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

On 01/24, Junio C Hamano wrote: > Junio C Hamano writes: > > > Sorry, but I am confused by all of the above. > > > > We write the thing out with write_entry(), possibly applying smudge > > filters and eol conversion to the "git" representation to create the > > "working tree"

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

On 01/25, Junio C Hamano wrote: > Thomas Gummerer <t.gumme...@gmail.com> writes: > > > On 01/24, Junio C Hamano wrote: > >> To put it differently, if a blob stored at path has CRLF line > >> endings and .gitattributes is changed after the fact to say that i

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

disk first, and strip the CE_UPTODATE flag in that case. Because the flag is not set, the cache entry will go through the racy check when writing the index the first time, and smudged if appropriate. This fixes the flaky test as well as the underlying problem. Signed-off-by: Thomas Gummerer <t.gumme

[PATCH] t7063: fix breakage with split index

When running the test suite with GIT_TEST_SPLIT_INDEX set, tests 17-18 in t7063 fail. Unset GIT_TEST_SPLIT_INDEX at the beginning of the test, in order to fix it. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- Hi, This breakage is both in the current master and next. I'm not entirely

Re: [PATCH/RFC v3 0/4] Improving performance of git clean

On 04/18, Erik Elfström wrote: * Still have issues in the performance tests, see comments from Thomas Gummerer on v2 I've looked at the modern style tests again, and I don't the code churn is worth it just for using them for the performance tests. If anyone wants to take a look at the code

Re: [PATCH v2 2/3] p7300: add performance tests for clean

On 04/12, erik elfström wrote: On Sat, Apr 11, 2015 at 7:59 PM, Thomas Gummerer t.gumme...@gmail.com wrote: On 04/11, Erik Elfström wrote: Signed-off-by: Erik Elfström erik.elfst...@gmail.com --- t/perf/p7300-clean.sh | 37 + 1 file changed, 37

Re: [PATCH v2 2/3] p7300: add performance tests for clean

On 04/11, Erik Elfström wrote: Signed-off-by: Erik Elfström erik.elfst...@gmail.com --- t/perf/p7300-clean.sh | 37 + 1 file changed, 37 insertions(+) create mode 100755 t/perf/p7300-clean.sh diff --git a/t/perf/p7300-clean.sh b/t/perf/p7300-clean.sh

Re: [PATCH] read-cache: tighten checks for do_read_index

On 03/24, Junio C Hamano wrote: Thomas Gummerer t.gumme...@gmail.com writes: 03f15a7 read-cache: fix reading of split index moved the checks for the correct order of index entries out of do_read_index. This loosens the checks more than necessary. Re-introduce the checks for the order

[PATCH] t1501: fix test with split index

t1501-worktree.sh does not copy the shared index in the relative $GIT_WORK_TREE and git subprocesses test, which makes the test fail when GIT_TEST_SPLIT_INDEX is set. Copy the shared index as well in order to fix this. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- This applies on top

Re: [PATCH 2/2] read-cache: fix reading of split index

On 03/24, Duy Nguyen wrote: On Sat, Mar 21, 2015 at 4:43 AM, Thomas Gummerer t.gumme...@gmail.com wrote: The split index extension uses ewah bitmaps to mark index entries as deleted, instead of removing them from the index directly. This can result in an on-disk index, in which entries

[PATCH v2] t1501: fix test with split index

t1501-worktree.sh does not copy the shared index in the relative $GIT_WORK_TREE and git subprocesses test, which makes the test fail when GIT_TEST_SPLIT_INDEX is set. Copy the shared index as well in order to fix this. Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: Thomas Gummerer

[PATCH] read-cache: tighten checks for do_read_index

for the caller instead, if we have multiple stage-0 entries and let the caller decide if we need to error out. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- This is a patch on top of my previous patch, as that one has already been merged to next. cache.h | 2 +- read

[PATCH] t1700: make test pass with index-v4

The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when run with index v4. Fix it. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- t/t1700-split-index.sh | 15 --- 1 file changed, 12 insertions(+), 3

[PATCH v2] t1700: make test pass with index-v4

The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when the test suite is run with TEST_GIT_INDEX_VERSION=4. Fix it. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- An updated patch to mention when run

Re: [PATCH] t1700: make test pass with index-v4

On 03/20, Junio C Hamano wrote: Thomas Gummerer t.gumme...@gmail.com writes: The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when run with index v4. Fix it. I am more interested to see how you managed to use index

Re: [PATCH v2] t1700: make test pass with index-v4

On 03/20, Junio C Hamano wrote: Thomas Gummerer t.gumme...@gmail.com writes: The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when the test suite is run with TEST_GIT_INDEX_VERSION=4. Fix it. Signed-off-by: Thomas

[PATCH 0/2] fix test suite with split index

. With the patch I previously sent, the test suite now passes with split-index enabled for both index v3 and v4. Thomas Gummerer (2): test-lib: allow using split index in the test suite read-cache: fix reading of split index Makefile | 6 ++ read-cache.c | 42

[PATCH 2/2] read-cache: fix reading of split index

index or after the split index bases are successfully merged instead. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- read-cache.c | 42 +++--- 1 file changed, 23 insertions(+), 19 deletions(-) diff --git a/read-cache.c b/read-cache.c index 8d71860

[PATCH 1/2] test-lib: allow using split index in the test suite

Allow adding a TEST_GIT_TEST_SPLIT_INDEX variable to config.mak to run the test suite with split index enabled. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- Makefile | 6 ++ t/test-lib.sh | 6 ++ 2 files changed, 12 insertions(+) diff --git a/Makefile b/Makefile index

Re: [PATCH 1/2] test-lib: allow using split index in the test suite

On 03/20, Junio C Hamano wrote: Thomas Gummerer t.gumme...@gmail.com writes: Allow adding a TEST_GIT_TEST_SPLIT_INDEX variable to config.mak to run the test suite with split index enabled. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- Hmm, it is not wrong per-se, but would

Re: [PATCH] refs.c: get_ref_cache: use a bucket hash

Hi, On 03/16, Andreas Krey wrote: get_ref_cache used a linear list, which obviously is O(n^2). Use a fixed bucket hash which just takes a factor of 10 (~ 317^2) out of the n^2 - which is enough. Signed-off-by: Andreas Krey a.k...@gmx.de --- This brings 'git clean -ndx' times down from

Re: [PATCH] send-email: Much readable error output

Hi, Alexander Kuleshov kuleshovm...@gmail.com writes: Signed-off-by: 0xAX kuleshovm...@gmail.com Please use your full name for the sign-off. --- git-send-email.perl | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/git-send-email.perl b/git-send-email.perl

Re: [PATCH v2 0/3] Easier access to index-v4

Junio C Hamano gits...@pobox.com writes: Junio C Hamano gits...@pobox.com writes: Thomas Gummerer t.gumme...@gmail.com writes: previous round was at $gmane/242198. Since then I've squashed the fixes suggested by Junio, added a test showing what should happen if an index file is present

[PATCH v2 0/3] Easier access to index-v4

. Thomas Gummerer (3): introduce GIT_INDEX_VERSION environment variable test-lib: allow setting the index format version read-cache: add index.version config variable Documentation/config.txt | 4 ++ Documentation/git.txt | 5 +++ Makefile

[PATCH v2 3/3] read-cache: add index.version config variable

Add a config variable that allows setting the default index version when initializing a new index file. Similar to the GIT_INDEX_VERSION environment variable this only affects new index files. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- Documentation/config.txt | 4 read

[PATCH v2 2/3] test-lib: allow setting the index format version

version under which t2104 is run to 3. This test only tests functionality specific to version 2 and 3 of the index file and would fail if the test suite is run with any other version. Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- Makefile

[PATCH v2 1/3] introduce GIT_INDEX_VERSION environment variable

. Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- Documentation/git.txt | 5 + read-cache.c | 21 - t/t1600-index.sh | 49 + 3 files changed, 74 insertions(+), 1

Re: [PATCH 1/3] introduce GIT_INDEX_VERSION environment variable

Junio C Hamano gits...@pobox.com writes: Thomas Gummerer t.gumme...@gmail.com writes: diff --git a/Documentation/git.txt b/Documentation/git.txt index aec3726..bc9eeea 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -712,6 +712,11 @@ Git so take care if using Cogito etc

Re: [PATCH 0/3] Wider exposure for index-v4

Duy Nguyen pclo...@gmail.com writes: On Sun, Feb 16, 2014 at 2:23 AM, Thomas Gummerer t.gumme...@gmail.com wrote: Hi, since index-v5 didn't seem to generate enough interest to be merged, I I thought there were some comments last time that you were going to address and resubmit? Yes

[PATCH 0/3] Wider exposure for index-v4

the environment or the config variables are set. I'm not sure about the precedence in patch 3, right now the environment variable has precedence, but it should be easy to give the config option precedence over that. Thomas Gummerer (3): introduce GIT_INDEX_VERSION environment variable test-lib: allow

<    1   2   3   4   5   6   7   8   9   >