Re: [PATCH v4 4/4] worktree: make add dwim

On 11/26, Junio C Hamano wrote: > Thomas Gummerer writes: > > > Of course that assumes that it's used directly, not in scripts, and > > that users will actually read the output of the command when they > > invoke it. Maybe these are not safe assumptions to make though, and

Re: [PATCH v5 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

On Sun, Nov 26, 2017 at 12:46:12PM +0900, Junio C Hamano wrote: > Max Kirillov writes: > > +ssize_t git_env_ssize_t(const char *k, ssize_t val) > > +{ > > + const char *v = getenv(k); > > + if (v && !git_parse_ssize_t(v, )) > > + die("failed to parse %s", k); > > +

Re: [PATCH v5 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

Max Kirillov writes: > I'm afraid I did not get the reasonsing and not fully the > desired change. Is this http-backend code change (compared > to the last patch) what you mean? Exactly. The fact that the parsed string happens to come from CONTENT_LENGTH environment variable

Re: Clone repository computer A to remote B doenst work

Thanks you very much: I have QNAP NAS, Finally I have installed QGit (from forum QNAP because you can't find in app center) from here: https://forum.qnap.com/viewtopic.php?f=320=109649 I used SSH for create a bare repository in the server side. Once it was created i went to the local machine and i

Re: git status always modifies index?

Junio C Hamano writes: > Jeff King writes: > >> What I was trying to get at is that naming it "status --no-lock-index" >> would not be the same thing (even though with the current implementation >> it would behave the same). IOW, can we improve the

FUND DONATION US$25MILLION

US$25 Million Has Been Granted To You As A Donation Visit www.bbc.co.uk/news/uk-england- 19254228 For Details Send Us Your Name, Home Address And Phone Numbers, text us at ( adrian.payment2...@yahoo.com ) For More Information. Best Regard: Mr. Adrian and Gillian Bayford FUND DONATION

Re: [PATCH] Makefile: check that tcl/tk is installed

On 26/11/17 14:00, Christian Couder wrote: > On Sun, Nov 26, 2017 at 4:53 AM, Junio C Hamano wrote: >> Christian Couder writes: >> >>> On Mon, Nov 20, 2017 at 6:15 PM, Christian Couder >>> wrote: By default

[PATCH v2 1/1] convert: tighten the safe autocrlf handling

From: Torsten Bögershausen When a text file had been commited with CRLF and the file is commited again, the CRLF are kept if .gitattributs has "text=auto". This is done by analyzing the content of the blob stored in the index: If a '\r' is found, Git assumes that the blob was

Re: [PATCH] Makefile: check that tcl/tk is installed

On Sun, Nov 26, 2017 at 4:53 AM, Junio C Hamano wrote: > Christian Couder writes: > >> On Mon, Nov 20, 2017 at 6:15 PM, Christian Couder >> wrote: >>> By default running `make install` in the root directory of the >>>

Re: [PATCH] Makefile: check that tcl/tk is installed

On Sun, Nov 26, 2017 at 6:43 PM, Ramsay Jones wrote: > > > On 26/11/17 14:00, Christian Couder wrote: >> On Sun, Nov 26, 2017 at 4:53 AM, Junio C Hamano wrote: >>> Christian Couder writes: >>> On Mon, Nov 20, 2017

Re: Problem installing Git

Hi Johannes, On 25/11/2017 23:16, Johannes Schindelin wrote: > > > [ +Cc: Git for Windows mailing list ] > > I have no idea why it claimed that that group does not exist, the > email address looks correct to me. I suspected the culprit was me not being a member of the group, where the group

[PATCH v6 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

v6: Do not implement generic git_env_ssize_t(), instead export git_parse_ssize_t() from config.c and hardcode the rest. Florian Manschwetus (1): http-backend: respect CONTENT_LENGTH as specified by rfc3875 Max Kirillov (1): t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases

[PATCH v6 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

From: Florian Manschwetus From: Florian Manschwetus Date: Wed, 30 Mar 2016 10:54:21 +0200 http-backend reads whole input until EOF. However, the RFC 3875 specifies that a script must read only as many bytes as specified by

[PATCH v6 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases

Add tests for cases: * CONTENT_LENGTH is set, script's stdin has more data. (Failure would make it read GIT_HTTP_MAX_REQUEST_BUFFER bytes from /dev/zero and fail. It does not seem to cause any performance issues with the default value of GIT_HTTP_MAX_REQUEST_BUFFER.) * CONTENT_LENGTH is

Re: [PATCH v6 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

On Sun, Nov 26, 2017 at 2:38 PM, Max Kirillov wrote: > [...] > Make http-backend read only CONTENT_LENGTH bytes, if it's defined, rather than > the whole input until EOF. If the variable is not defined, keep older behavior > of reading until EOF because it is used to support

Ich werde auf Ihre Antwort warten

Schönen Tag, Ich bin Herr Yuehan Pan, Direktor der Bank of China Ich suche einen Manager / Investitionspartner, der mit mir für ein gegenseitiges Geschäftsunternehmen arbeiten wird. Bitte kontaktieren Sie mich in meiner privaten E-Mail für weitere Details. E-Mail (yuehanpa...@gmail.com) Ich

[SCRIPT/RFC 1/3] setup.sh

On 26/11/2017 23:35, Igor Djordjevic wrote: > > This is what we end up with once "master" and topic branches are > merged in merge commit M1 inside temporary "test" branch for further > integration testing: > > (2)o---o---A (topicA) > / \ > / M1

[SCRIPT/RFC 2/3] git-merge-one-file--cached

Original "git-merge-one-file" script is slightly tweaked here into "git-merge-one-file--cached"[*1*] to allow (still trivial) _index-only_ three-way file merge, not touching files inside working tree. Proof of concept, not thoroughly tested, original content left in, commented out. Feel free

[PATCH v5 0/6] make git worktree add dwim more

The previous rounds can be found at https://public-inbox.org/git/20171112134305.3949-1-t.gumme...@gmail.com/, https://public-inbox.org/git/20171118181103.28354-1-t.gumme...@gmail.com/, https://public-inbox.org/git/20171118224706.13810-1-t.gumme...@gmail.com/ and

[PATCH 2/2] trace: improve performance while category is disabled

From: Gennady Kupava - Do the check if the trace key is enabled sooner in call chain. - Move just enough code from trace.c into trace.h header so all code necessary to determine that trace is disabled could be inlined to calling functions. Signed-off-by: Gennady

[PATCH 1/2] trace: remove trace key normalization

From: Gennady Kupava Trace key normalization is not used, not strictly necessary, complicates the code and would negatively affect compilation speed if moved to header. New trace_default_key key or existing separate marco could be used instead of passing NULL as a key.

[PATCH v1 1/2] t/README: remove mention of adding copyright notices

We generally no longer include copyright notices in new test scripts. However t/README still mentions it as something to include at the top of every new script. Remove that mention as it's outdated. Signed-off-by: Thomas Gummerer --- I read through some parts of t/README,

[PATCH v1 2/2] t/README: document test_cmp_rev

test_cmp_rev is a useful function that's used in quite a few test scripts. It is however not documented in t/README. Document it. Signed-off-by: Thomas Gummerer --- t/README | 5 + 1 file changed, 5 insertions(+) diff --git a/t/README b/t/README index

Re: [PATCH] Makefile: check that tcl/tk is installed

On Sun, Nov 26, 2017 at 8:15 PM, Jeff King wrote: > On Tue, Nov 21, 2017 at 12:58:17AM +0100, Christian Couder wrote: > >> > Can you say more about where this comes up? >> >> The original discussion is: >> >>

Re: [PATCH v6 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases

On Sun, Nov 26, 2017 at 2:38 PM, Max Kirillov wrote: > Add tests for cases: > > * CONTENT_LENGTH is set, script's stdin has more data. > (Failure would make it read GIT_HTTP_MAX_REQUEST_BUFFER bytes from /dev/zero > and fail. It does not seem to cause any performance issues

[SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Hi to all, Here`s my humble attempt on (once more) scratching a use case which seems to be desired occasionally through the years, obviously not enough to be actually implemented yet, but might be worth some more attention... :) For the reference, some past mentions of (more or less) similar

[SCRIPT/RFC 3/3] git-commit--onto-parent.sh

Finally, "git-commit--onto-parent.sh"[*1*] shows an initial script version for you to examine, test out and hopefully comment on :) Especially interesting part might be index-only three-way file merge, through usage of "git-merge-one-file--cached" script. Of course, this still only works for

Re: git status always modifies index?

On Sat, Nov 25, 2017 at 10:55:25PM +0100, Johannes Schindelin wrote: > > Right, I went a little off track of your original point. > > > > What I was trying to get at is that naming it "status --no-lock-index" > > would not be the same thing (even though with the current implementation > > it

Re: [PATCH v5 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

On Sun, Nov 26, 2017 at 06:38:06PM +0900, Junio C Hamano wrote: > Max Kirillov writes: >> +static ssize_t env_content_length() > > We need s/length()/length(void)/; though. thanks, fixed it

Re: [PATCH] Makefile: check that tcl/tk is installed

On Tue, Nov 21, 2017 at 12:58:17AM +0100, Christian Couder wrote: > > Can you say more about where this comes up? > > The original discussion is: > > https://public-inbox.org/git/b6b12040-100f-5965-6dfd-344c84ddd...@teddy.ch/ > > and here are discussions related to version 1 of this patch: >

Re: git status always modifies index?

On Sun, Nov 26, 2017 at 12:32:13PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > What I was trying to get at is that naming it "status --no-lock-index" > > would not be the same thing (even though with the current implementation > > it would behave the same). IOW, can we

[PATCH v5 2/6] worktree: add can be created from any commit-ish

Currently 'git worktree add' is documented to take an optional argument, which is checked out in the new worktree. However it is more generally possible to use a commit-ish as the optional argument, and check that out into the new worktree. Document that this is a possibility, as new users of

[PATCH v5 1/6] checkout: factor out functions to new lib file

Factor the functions out, so they can be re-used from other places. In particular these functions will be re-used in builtin/worktree.c to make git worktree add dwim more. While there add some docs to the function. Signed-off-by: Thomas Gummerer --- Makefile |

[PATCH v5 3/6] worktree: add --[no-]track option to the add subcommand

Currently 'git worktree add' sets up tracking branches if '' is a remote tracking branch, and doesn't set them up otherwise, as is the default for 'git branch'. This may or may not be what the user wants. Allow overriding this behaviour with a --[no-]track flag that gets passed through to 'git

[PATCH v5 6/6] add worktree.guessRemote config option

Some users might want to have the --guess-remote option introduced in the previous commit on by default, so they don't have to type it out every time they create a new worktree. Add a config option worktree.guessRemote that allows users to configure the default behaviour for themselves.

[PATCH v5 4/6] worktree: make add dwim

Currently 'git worktree add ', errors out when 'branch' is not a local branch. It has no additional dwim'ing features that one might expect. Make it behave more like 'git checkout ' when the branch doesn't exist locally, but a remote tracking branch uniquely matches the desired branch name,

[PATCH v5 5/6] worktree: add --guess-remote flag to add subcommand

Currently 'git worktree add ' creates a new branch named after the basename of the , that matches the HEAD of whichever worktree we were on when calling "git worktree add ". It's sometimes useful to have 'git worktree add behave more like the dwim machinery in 'git checkout ', i.e. check if the

Hello...

FROM: ANDREW LAWSON. Dear Sir, My name is Mr. Andrew Lawson. I work as a procurement assistant. I got your contact details during my search for a reliable and neutral company or individual to partner with in the area of investment. I need your assistance to manage an investment fund in a

Re: git status always modifies index?

Hi Peff, On Sun, 26 Nov 2017, Jeff King wrote: > On Sat, Nov 25, 2017 at 10:55:25PM +0100, Johannes Schindelin wrote: > > > > Right, I went a little off track of your original point. > > > > > > What I was trying to get at is that naming it "status --no-lock-index" > > > would not be the same

Re: [PATCH v6 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases

On Sun, Nov 26, 2017 at 05:18:55PM -0500, Eric Sunshine wrote: > On Sun, Nov 26, 2017 at 2:38 PM, Max Kirillov wrote: >> +int cmd_main(int argc, const char **argv) >> +{ >> + if (argc == 2 && strcmp(argv[1], "(size_t)(-20)") == 0) >> + printf("%zu",

Re: [PATCH v6 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases

Max Kirillov writes: > Add tests for cases: > > * CONTENT_LENGTH is set, script's stdin has more data. > (Failure would make it read GIT_HTTP_MAX_REQUEST_BUFFER bytes from /dev/zero > and fail. It does not seem to cause any performance issues with the default > value of

Re: git status always modifies index?

Jeff King writes: > I'm not sure I agree. Lockless writes are actually fine for the original > use case of --no-optional-locks (which is a process for the same user > that just happens to run in the background). The phrase "lockless write" scares me---it sounds as if you

Re: [PATCH] Makefile: check that tcl/tk is installed

Jeff King writes: > ... > I think your patch does say "consider setting NO_TCLTK" in that case, > which is an improvement. But it might be nicer still if it Just Worked > (either because we don't do tcl/tk by default, or because we respect > NO_GETTEXT in the gitk/git-gui

Re: Problem with environment of hook execution when git is run with --work-tree / --git-dir

Michael Sloan writes: > So what's the problem with this choice of environment variables? > Well, the problem is that if PWD is changed during the execution of > the script, then GIT_WORK_TREE and GIT_DIR will no longer work > properly. For example, if the pre-commit hook is >

Re: [PATCH 2/2] trace: improve performance while category is disabled

gennady.kup...@gmail.com writes: > From: Gennady Kupava > > - Do the check if the trace key is enabled sooner in call chain. > - Move just enough code from trace.c into trace.h header so all code > necessary to determine that trace is disabled could be inlined to >

Re: [PATCH 2/2] trace: improve performance while category is disabled

Junio C Hamano writes: > gennady.kup...@gmail.com writes: > >> From: Gennady Kupava >> >> - Do the check if the trace key is enabled sooner in call chain. >> - Move just enough code from trace.c into trace.h header so all code >> necessary to

Re: [PATCH] pretty: fix buffer over-read with %> and %

mwnx writes: > diff --git a/pretty.c b/pretty.c > index 2f6b0ae6c..4c70bad45 100644 > --- a/pretty.c > +++ b/pretty.c > @@ -1021,7 +1021,7 @@ static size_t parse_padding_placeholder(struct strbuf > *sb, > const char *end = start + strcspn(start, ",)"); >

Re: Problem with environment of hook execution when git is run with --work-tree / --git-dir

On Sun, Nov 26, 2017 at 5:16 PM, Junio C Hamano wrote: > Michael Sloan writes: > >> So what's the problem with this choice of environment variables? >> Well, the problem is that if PWD is changed during the execution of >> the script, then GIT_WORK_TREE and

Re: [PATCH] grep: Add option --max-line-len

[second try, now with text format] Thanks a lot for the reviews. Replying to both. If I send a follow up, I'll fix the commit description and the help string, remove the shorthand -M, write a more sensible test. 2017-11-23 14:24 GMT-05:00 Eric Sunshine : >> diff --git

Re: [PATCH] grep: Add option --max-line-len

Marc-Antoine Ruel writes: > [second try, now with text format] > > Thanks a lot for the reviews. Replying to both. > > If I send a follow up, I'll fix the commit description and the help > string, remove the shorthand -M, write a more sensible test. > > ... > > Thanks for

Re: [PATCH 2/2] trace: improve performance while category is disabled

Junio C Hamano writes: > Just in case others notice style and whitespace issues, I've applied > the following to fix them, so there is no need to reroll only to fix > these. > ... > -inline int trace_pass_fl(struct trace_key *key) { > +inline int trace_pass_fl(struct trace_key

Re: [PATCH] merge-recursive: ignore_case shouldn't reject intentional removals

Elijah Newren writes: > In commit ae352c7f3 (merge-recursive.c: fix case-changing merge bug, > 2014-05-01), it was observed that removing files could be problematic on > case insensitive file systems, because we could end up removing files > that differed in case only rather

Re: [PATCH v6 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

To recap (other than the typofix in the proposed log message), here is what I would have as SQUASH??? on top of (or interspersed with) v6. Thanks. diff --git a/http-backend.c b/http-backend.c index 69570d16e7..2268d65731 100644 --- a/http-backend.c +++ b/http-backend.c @@ -324,10 +324,9 @@

Re: [PATCH] Use OBJECT_INFO_QUICK to speedup git fetch-pack

On Mon, Nov 27, 2017 at 01:35:35PM +0900, Junio C Hamano wrote: > Takuto Ikuta writes: > > > diff --git a/fetch-pack.c b/fetch-pack.c > > index 008b25d3db087..0184584e80599 100644 > > --- a/fetch-pack.c > > +++ b/fetch-pack.c > > @@ -716,7 +716,7 @@ static int

[PATCH] Use OBJECT_INFO_QUICK to speedup git fetch-pack

Do not call prepare_packed_git for every refs. In fetch-pack, git list ups entries in .git/objects/pack directory for each refs. Such behavior makes git fetch-pack slow for the repository having the large number of refs, especially for windows. For chromium repository, having more than 30

Re: [PATCH] Use OBJECT_INFO_QUICK to speedup git fetch-pack

Takuto Ikuta writes: > diff --git a/fetch-pack.c b/fetch-pack.c > index 008b25d3db087..0184584e80599 100644 > --- a/fetch-pack.c > +++ b/fetch-pack.c > @@ -716,7 +716,7 @@ static int everything_local(struct fetch_pack_args *args, > for (ref = *refs; ref; ref = ref->next)

Re: [PATCH] Makefile: check that tcl/tk is installed

On Mon, Nov 27, 2017 at 01:31:13PM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > > Perhaps the "else" part of the above should become a bit more > > careful, something along the lines of... > > > > else > > MSGFMT ?= msgfmt > > - ifneq

Re: [PATCH] Makefile: check that tcl/tk is installed

Junio C Hamano writes: > Perhaps the "else" part of the above should become a bit more > careful, something along the lines of... > > else > MSGFMT ?= msgfmt > - ifneq ($(shell $(MSGFMT) --tcl -l C -d . /dev/null 2>/dev/null; > echo $$?),0) > -

Re: git status always modifies index?

On Sun, Nov 26, 2017 at 06:35:56PM +0900, Junio C Hamano wrote: > Having a large picture option like "--read-only" instead of ending > up with dozens of "we implemented a knob to tweak only this little > piece, and here is an option to trigger it" would help users in the > long run, but we

Re: [PATCH 3/5] rebase -i: add exec commands via the rebase--helper

Liam Beguin writes: > diff --git a/sequencer.c b/sequencer.c > index fa94ed652d2c..810b7850748e 100644 > --- a/sequencer.c > +++ b/sequencer.c > @@ -2492,6 +2492,52 @@ int sequencer_make_script(int keep_empty, FILE *out, > return 0; > } > > +int

Re: [PATCH 0/5] rebase -i: add config to abbreviate command names

Liam Beguin writes: > Liam Beguin (5): > Documentation: move rebase.* configs to new file > Documentation: use preferred name for the 'todo list' script > rebase -i: add exec commands via the rebase--helper > rebase -i: learn to abbreviate command names > t3404:

Re: [PATCH] Makefile: check that tcl/tk is installed

Jeff King wrote: Yeah, this side-steps the "other half" of the issue that Christian's patch addresses, which seems like the more controversial part (I don't have a strong opinion myself, though). I don't either. The general motivation there, as far as I understand, is that it's undesirable

Re: [PATCH 5/5] t3404: add test case for abbreviated commands

Liam Beguin writes: > Make sure the todo list ends up using single-letter command > abbreviations when the rebase.abbreviateCommands is enabled. > This configuration options should not change anything else. > > Signed-off-by: Liam Beguin > --- >

Re: git status always modifies index?

Jeff King writes: > Again, maybe the bit above explains my viewpoint a bit more. I'm > certainly sympathetic to the pain of upstreaming. > > I do disagree with the "no good reason" for this particular patch. > > Certainly you should feel free to present your hunches. I'd expect

Re: [PATCH] git-status.txt: mention --no-optional-locks

Jeff King writes: > On Mon, Nov 27, 2017 at 12:24:43AM -0500, Jeff King wrote: > >> > If people have to ask on the mailing list even after reading the man >> > pages, that's a strong indicator that we could do better. >> >> Sure. That's why I suggested improving the documentation

[PATCH] git-status.txt: mention --no-optional-locks

On Mon, Nov 27, 2017 at 12:24:43AM -0500, Jeff King wrote: > > If people have to ask on the mailing list even after reading the man > > pages, that's a strong indicator that we could do better. > > Sure. That's why I suggested improving the documentation in my last > email. But in all the

Re: [PATCH v5 5/6] worktree: add --guess-remote flag to add subcommand

Thomas Gummerer writes: > Currently 'git worktree add ' creates a new branch named after the > basename of the , that matches the HEAD of whichever worktree we > were on when calling "git worktree add ". > > It's sometimes useful to have 'git worktree add behave more like

Re: [PATCH v5 6/6] add worktree.guessRemote config option

Thomas Gummerer writes: > +worktree.guessRemote:: > + With `add`, if no branch argument, and neither of `-b` nor > + `-B` nor `--detach` are given, the command defaults to > + creating a new branch from HEAD. If `worktree.guessRemote` is > + set to true,

Re: [PATCH] Use OBJECT_INFO_QUICK to speedup git fetch-pack

Jeff King writes: >> cf. >> https://public-inbox.org/git/20171120202920.7ppcwmzkxifyw...@sigill.intra.peff.net/ > > It's funny that we'd get two patches so close together. AFAIK the > slowness here has been with us for years, and I just happened to > investigate it recently. > >>

[PATCH 5/5] t3404: add test case for abbreviated commands

Make sure the todo list ends up using single-letter command abbreviations when the rebase.abbreviateCommands is enabled. This configuration options should not change anything else. Signed-off-by: Liam Beguin --- t/t3404-rebase-interactive.sh | 32

[PATCH 1/5] Documentation: move rebase.* configs to new file

Move all rebase.* configuration variables to a separate file in order to remove duplicates, and include it in config.txt and git-rebase.txt. The new descriptions are mostly taken from config.txt as they are more verbose. Signed-off-by: Liam Beguin ---

Re: [PATCH] Use OBJECT_INFO_QUICK to speedup git fetch-pack

On Mon, Nov 27, 2017 at 01:53:34PM +0900, Junio C Hamano wrote: > > I'd be curious if the 5th patch there provides an additional speedup for > > Takuto's case. > > Indeed, it is a very good point. > > IIUC, the 5th one is about fetching tons of refs that you have never > seen, right? If a

Re: [PATCH 4/5] rebase -i: learn to abbreviate command names

Liam Beguin writes: > if (command == MAKE_SCRIPT && argc > 1) > - return !!sequencer_make_script(keep_empty, stdout, argc, argv); > + return !!sequencer_make_script(keep_empty, abbreviate_commands, > +

Re: git status always modifies index?

On Mon, Nov 27, 2017 at 09:47:20AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > I'm not sure I agree. Lockless writes are actually fine for the original > > use case of --no-optional-locks (which is a process for the same user > > that just happens to run in the

[PATCH 3/5] rebase -i: add exec commands via the rebase--helper

Recent work on `git-rebase--interactive` aim to convert shell code to C. Even if this is most likely not a big performance enhacement, let's convert it too since a comming change to abbreviate command names requires it to be updated. Signed-off-by: Liam Beguin ---

[PATCH 4/5] rebase -i: learn to abbreviate command names

`git rebase -i` already know how to interpret single-letter command names. Teach it to generate the todo list with these same abbreviated names. Based-on-patch-by: Johannes Schindelin Signed-off-by: Liam Beguin ---

[PATCH 0/5] rebase -i: add config to abbreviate command names

Hi everyone, This series is a respin of something [1] I sent a few months ago. This time, instead of shell, It's based on top of the C implementation of the interactive rebase. I've also tried to address the comments that were left in the last thread. This series will add the

[PATCH 2/5] Documentation: use preferred name for the 'todo list' script

Use "todo list" instead of "instruction list" or "todo-list" to reduce further confusion regarding the name of this script. Signed-off-by: Liam Beguin --- Documentation/rebase-config.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: git status always modifies index?

Jeff King writes: > I actually consider "--no-optional-locks" to be such an aspirational > feature. I didn't go digging for other cases (though I'm fairly certain > that "diff" has one), but hoped to leave it for further bug reports ("I > used the option, ran command X, and saw

Re: [PATCH] Use OBJECT_INFO_QUICK to speedup git fetch-pack

2017-11-27 13:53 GMT+09:00 Junio C Hamano : > Jeff King writes: > >>> cf. >>> https://public-inbox.org/git/20171120202920.7ppcwmzkxifyw...@sigill.intra.peff.net/ >> >> It's funny that we'd get two patches so close together. AFAIK the >> slowness here has been

Re: git status always modifies index?

On Mon, Nov 27, 2017 at 01:56:41PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > I actually consider "--no-optional-locks" to be such an aspirational > > feature. I didn't go digging for other cases (though I'm fairly certain > > that "diff" has one), but hoped to leave

Re: git status always modifies index?

On Sun, Nov 26, 2017 at 10:55:01PM +0100, Johannes Schindelin wrote: > > I remain unconvinced that we have actually uncovered a serious problem. > > You did not. A colleague of mine did. And it was a problem in Git for > Windows only, caused by the changes necessitated by yours (which even used