Re: [PATCH] hashmap: adjust documentation to reflect reality

On Sat, Dec 2, 2017 at 9:35 PM, Junio C Hamano wrote: > Jeff King writes: > >> My second suggestion (which I'm on the fence about) is: would it better >> to just say "see t/helper/test-hashmap.c for a representative example?" I think that may be better in the

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

> On 04 Dec 2017, at 18:26, Jeff King wrote: > > On Sun, Dec 03, 2017 at 05:39:10PM +0100, Lars Schneider wrote: > > + fprintf(stderr, _("hint: Waiting for your editor > input...")); I found "waiting for editor input" to be a funny way of

Re: [PATCH v4 7/9] sequencer: load commit related config

Phillip Wood writes: > --- a/builtin/rebase--helper.c > +++ b/builtin/rebase--helper.c > @@ -9,6 +9,17 @@ static const char * const builtin_rebase_helper_usage[] = { > NULL > }; > > +static int git_rebase_helper_config(const char *k, const char *v, void *cb) >

Re: [PATCH v3] diff: support anchoring line(s)

On Thu, Nov 30, 2017 at 3:26 PM, Jonathan Tan wrote: > On Thu, 30 Nov 2017 01:36:37 +0100 (CET) > Johannes Schindelin wrote: > >> Hi Jonathan, >> >> On Tue, 28 Nov 2017, Jonathan Tan wrote: >> >> > @@ -4607,7 +4627,14 @@ int

Re: git-clone ignores submodule.recurse configuration

On Fri, Dec 1, 2017 at 1:47 PM, Brandon Williams wrote: > On 12/01, Ralf Thielow wrote: >> Today I played around a bit with git submodules and noticed >> that the very handy configuration "submodule.recurse" is not >> working for the git-clone command. The rationale here is

gitattributes not read for diff-tree anymore in 2.15?

Hi, I've bisected a failure in our test suite to this commit: commit 557a5998df19faf8641acfc5b6b1c3c2ba64dca9 (HEAD, refs/bisect/bad) Author: Brandon Williams Date: Thu Aug 3 11:20:00 2017 -0700 submodule: remove gitmodules_config Now that the

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

> On 04 Dec 2017, at 18:32, Jeff King wrote: > > On Sun, Dec 03, 2017 at 01:47:04PM +0100, Lars Schneider wrote: > >> I am on the fence here. I like consistency but I don't want to >> bother Git users. >> >> @Peff: Do you lean into either direction? Could you imagine that >>

Re: [PATCH v2 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

Kaartic Sivaraam writes: >> Stepping back a bit, the mild suspicion above says >> >> $ git checkout HEAD^0 >> ... do things ... >> $ git checkout -b temp >> ... do more things ... >> $ git checkout -B @{-1} >> >> that creates a new branch whose

Re: [PATCH v4 9/9] t3512/t3513: remove KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT=1

On Fri, Nov 24, 2017 at 3:07 AM, Phillip Wood wrote: > From: Phillip Wood > > Now that the sequencer creates commits without forking 'git commit' it > does not see an empty commit in these tests which fixes the known > breakage. Note that

Re: submodules and merging (Was: Re: [PATCH 02/30] merge-recursive: Fix logic ordering issue)

On Sat, Nov 25, 2017 at 9:59 PM, Jacob Keller wrote: > On Sat, Nov 25, 2017 at 2:37 PM, Elijah Newren wrote: >> On Wed, Nov 15, 2017 at 9:13 AM, Jacob Keller wrote: >>> On Tue, Nov 14, 2017 at 10:13 AM, Stefan Beller

Re: [PATCH v2] Makefile: replace perl/Makefile.PL with simple make rules

Ævar Arnfjörð Bjarmason writes: > On Mon, Dec 4, 2017 at 5:22 PM, Junio C Hamano wrote: >> I did this immediately after applying; please double check. >> >> Thanks. > > Thanks. Looks good to me. I'll incorporate that info future > submissions if there's more

[PATCH v1] progress: print progress output for all operations taking longer than 2s

From: Lars Schneider In 180a9f2 we implemented a progress API which suppresses the progress output if the progress has reached a specified percentage threshold within a given time frame. In 8aade10 we simplified the API and set the threshold to 0% and the time frame to

Re: [PATCH v1] progress: print progress output for all operations taking longer than 2s

On Mon, Dec 04, 2017 at 09:36:47PM +0100, lars.schnei...@autodesk.com wrote: > From: Lars Schneider > > In 180a9f2 we implemented a progress API which suppresses the progress > output if the progress has reached a specified percentage threshold > within a given time

Re: [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit

Robert Abel writes: > __git_eread is used to read a single line of a given file (if it exists) > into a variable without the EOL. All six current users of __git_eread > use it that way and don't expect multi-line content. Changing $@ to $2 does not change whether this is

Re: [PATCH v2] Makefile: replace perl/Makefile.PL with simple make rules

On Mon, Dec 4, 2017 at 5:22 PM, Junio C Hamano wrote: > I did this immediately after applying; please double check. > > Thanks. Thanks. Looks good to me. I'll incorporate that info future submissions if there's more stuff to fix, but for now if you could queue it like that

Re: [PATCH v2] Makefile: replace perl/Makefile.PL with simple make rules

Junio C Hamano writes: > Well the thing is that I cannot queue this and Dan's at the same > time, while both of these topics are expected to be in flux. For > today's pushout, I tentatively kicked out Dan's relative path series > and queued this one to see how well it works with the rest of the

Re: submodules and merging (Was: Re: [PATCH 02/30] merge-recursive: Fix logic ordering issue)

On Mon, Dec 4, 2017 at 11:33 AM, Stefan Beller wrote: > On Sat, Nov 25, 2017 at 9:59 PM, Jacob Keller wrote: >> On Sat, Nov 25, 2017 at 2:37 PM, Elijah Newren wrote: >>> On Wed, Nov 15, 2017 at 9:13 AM, Jacob Keller

[PATCH 1/2] progress: set default delay threshold to 100%, not 0%

Commit 8aade107dd (progress: simplify "delayed" progress API, 2017-08-19) dropped the parameter by which callers could say "show my progress only if I haven't passed M% progress after N seconds". The intent was to just show nothing for 2 seconds, and then always progress after that. But we

Re: [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit

Hi Junio, On 04 Dec 2017 18:58, Junio C Hamano wrote: > Robert Abel writes: >> __git_eread is used to read a single line of a given file (if it exists) >> into a variable without the EOL. All six current users of __git_eread >> use it that way and don't expect multi-line

Re: gitattributes not read for diff-tree anymore in 2.15?

On 12/04, Ben Boeckel wrote: > Hi, > > I've bisected a failure in our test suite to this commit: > > commit 557a5998df19faf8641acfc5b6b1c3c2ba64dca9 (HEAD, refs/bisect/bad) > Author: Brandon Williams > Date: Thu Aug 3 11:20:00 2017 -0700 > > submodule:

[PATCH v2] pathspec: only match across submodule boundaries when requested

Commit 74ed43711fd (grep: enable recurse-submodules to work on objects, 2016-12-16) taught 'tree_entry_interesting()' to be able to match across submodule boundaries in the presence of wildcards. This is done by performing literal matching up to the first wildcard and then punting to the

Re: [PATCH v1] progress: print progress output for all operations taking longer than 2s

lars.schnei...@autodesk.com writes: > In 180a9f2 we implemented a progress API which suppresses the progress > output if the progress has reached a specified percentage threshold > within a given time frame. In 8aade10 we simplified the API and set the > threshold to 0% and the time frame to 2

What's cooking in git.git (Dec 2017, #01; Mon, 4)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes

[PATCH 0/2] fix v2.15 progress regression

On Mon, Dec 04, 2017 at 01:38:41PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > So the minimal fix is actually: > > > > diff --git a/progress.c b/progress.c > > index 289678d43d..b774cb1cd1 100644 > > --- a/progress.c > > +++ b/progress.c > > @@ -229,7 +229,7 @@ static

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

On Mon, Dec 4, 2017 at 1:46 PM, Junio C Hamano wrote: > * en/rename-directory-detection (2017-11-21) 33 commits > Rename detection logic in "diff" family that is used in "merge" has > learned to guess when all of x/a, x/b and x/c have moved to z/a, > z/b and z/c, it is

[PATCH v3 1/2] git-prompt: make __git_eread intended use explicit

__git_eread is used to read a single line of a given file (if it exists) into a single variable without the EOL. All six current users of __git_eread use it that way and don't expect multi-line content. Therefore, this patch removes the unused capability to split file conents into tokens by

[PATCH v3 2/2] git-prompt: fix reading files with windows line endings

If any of the files read by __git_eread have \r\n line endings, read will only strip \n, leaving \r. This results in an ugly prompt, where instead of user@pc MINGW64 /path/to/repo (BARE:master) the last parenthesis is printed over the beginning of the prompt like )ser@pc MINGW64

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

Jeff King writes: > On Sun, Dec 03, 2017 at 01:47:04PM +0100, Lars Schneider wrote: > >> I am on the fence here. I like consistency but I don't want to >> bother Git users. >> >> @Peff: Do you lean into either direction? Could you imagine that >> novice/regular users are

submodule modify/delete wrong message

When merging with a submodule modify/delete conflict (i.e. I've deleted the submodule, and I'm merging in a branch that modified it), git lies about what it is doing: "CONFLICT (modify/delete): submodule deleted in HEAD and modified in submodules. Version submodules of submodule left in tree at

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

> On 04 Dec 2017, at 22:42, Jeff King wrote: > > On Mon, Dec 04, 2017 at 10:31:15PM +0100, Lars Schneider wrote: > I would like to add "for your input" or "for you" to convey that Git is not waiting for the machine but for the user. "hint: Launched

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

On Mon, Dec 04, 2017 at 10:54:40PM +0100, Lars Schneider wrote: > > Better, IMHO, though I still think literally saying: > > > > hint: Waiting for your editor to exit... > > > > is the most accurate, which I think makes it clear that you must _exit_ > > your editor, not just save and close the

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

On Mon, 04 Dec 2017 13:46:43 -0800 Junio C Hamano wrote: > * jt/diff-anchored-patience (2017-11-28) 1 commit > - diff: support anchoring line(s) > > "git diff" learned a variant of the "--patience" algorithm, to > which the user can specify which 'unique' line to be used

[PATCH 2/2] progress: drop delay-threshold code

From: Lars Schneider Since 180a9f2268 (provide a facility for "delayed" progress reporting, 2007-04-20), the progress code has allowed callers to skip showing progress if they have reached a percentage-threshold of the total work before the delay period passes. But

Re: [PATCH] pathspec: only match across submodule boundaries when requested

On 11/29, Johannes Schindelin wrote: > Hi Brandon, > > On Tue, 28 Nov 2017, Brandon Williams wrote: > > > Commit 74ed43711fd (grep: enable recurse-submodules to work on > > objects, 2016-12-16) taught 'tree_entry_interesting()' to be able to > > match across submodule boundaries in the presence

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

On 12/4/2017 4:46 PM, Junio C Hamano wrote: * cc/object-filtering-typofix (2017-12-04) 1 commit - list-objects-filter-options: fix 'keword' typo in comment (this branch uses jh/object-filtering; is tangled with jh/fsck-promisors and jh/partial-clone.) Typofix for a topic already in

Re: [PATCH 0/2] fix v2.15 progress regression

Jeff King writes: > Here's what I think we should do: fix the bug in the minimal way, and > then drop the useless code. It's worth doing in two steps, because we > may decide to resurrect the feature later, and it would then just be a > straight revert of the second commit. Yup.

[WIP 07/15] connect: convert get_remote_heads to use struct packet_reader

In order to allow for better control flow when protocol_v2 is introduced convert 'get_remote_heads()' to use 'struct packet_reader' to read packet lines. This enables a client to be able to peek the first line of a server's response (without consuming it) in order to determine the protocol

[WIP 08/15] connect: discover protocol version outside of get_remote_heads

In order to prepare for the addition of protocol_v2 push the protocol version discovery outside of 'get_remote_heads()'. This will allow for keeping the logic for processing the reference advertisement for protocol_v1 and protocol_v0 separate from the logic for protocol_v2. Signed-off-by:

[WIP 03/15] pkt-line: add delim packet support

One of the design goals of protocol-v2 is to improve the semantics of flush packets. Currently in protocol-v1, flush packets are used both to indicate a break in a list of packet lines as well as an indication that one side has finished speaking. This makes it particularly difficult to implement

[WIP 01/15] pkt-line: introduce packet_read_with_status

The current pkt-line API encodes the status of a pkt-line read in the length of the read content. An error is indicated with '-1', a flush with '0' (which can be confusing since a return value of '0' can also indicate an empty pkt-line), and a positive integer for the length of the read content

[WIP 04/15] upload-pack: convert to a builtin

In order to allow for code sharing with the server-side of fetch in protocol-v2 convert upload-pack to be a builtin. Signed-off-by: Brandon Williams --- Makefile | 3 ++- builtin.h | 1 + git.c | 1 + upload-pack.c | 2 +- 4 files changed, 5 insertions(+), 2

[WIP 02/15] pkt-line: introduce struct packet_reader

Sometimes it is advantageous to be able to peek the next packet line without consuming it (e.g. to be able to determine the protocol version a server is speaking). In order to do that introduce 'struct packet_reader' which is an abstraction around the normal packet reading logic. This enables a

[WIP 11/15] serve: introduce git-serve

Introduce git-serve, the base server for protocol version 2. When connecting to a server supporting protocol version 2, the server will send a list all of its capabilities and then wait for the client to send a command request. Some capabilities advertised are 'commands' which the client can

[WIP 13/15] connect: request remote refs using v2

Teach the client to be able to request a remote's refs using protocol v2. This is done by having a client issue a 'ls-refs' request to a v2 server. Signed-off-by: Brandon Williams --- connect.c | 85 +- remote.h

[WIP 00/15] protocol version 2

A while back I sent out a rough outline for what a protocol version 2 would look like at https://public-inbox.org/git/20171020171839.4188-1-bmw...@google.com/. After hacking at both the server and client code I've managed to get some patches for protocol version 2 which implement listing refs and

Re: [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit

Robert Abel writes: > Hi Junio, > > On 04 Dec 2017 18:58, Junio C Hamano wrote: >> Robert Abel writes: >>> __git_eread is used to read a single line of a given file (if it exists) >>> into a variable without the EOL. All six current users of __git_eread

Re: [PATCH v1] progress: print progress output for all operations taking longer than 2s

Jeff King writes: > So the minimal fix is actually: > > diff --git a/progress.c b/progress.c > index 289678d43d..b774cb1cd1 100644 > --- a/progress.c > +++ b/progress.c > @@ -229,7 +229,7 @@ static struct progress *start_progress_delay(const char > *title, unsigned total, > >

Re: [PATCH v6 4/7] checkout: describe_detached_head: remove ellipsis after committish

We do not want an ellipsis displayed following an (abbreviated) SHA-1 value. The days when this was necessary to indicate the truncation to lower-level Git commands and/or the user are bygone. However, to ease the transition, the ellipsis will still be printed if the user sets the environment

[WIP 05/15] upload-pack: factor out processing lines

Factor out the logic for processing shallow, deepen, deepen_since, and deepen_not lines into their own functions to simplify the 'receive_needs()' function in addition to making it easier to reuse some of this logic when implementing protocol_v2. Signed-off-by: Brandon Williams

[WIP 10/15] protocol: introduce enum protocol_version value protocol_v2

Introduce protocol_v2, a new value for 'enum protocol_version'. Subsequent patches will fill in the implementation of protocol_v2. Signed-off-by: Brandon Williams --- builtin/fetch-pack.c | 3 +++ builtin/receive-pack.c | 3 +++ builtin/send-pack.c| 3 +++ connect.c

[WIP 14/15] upload_pack: introduce fetch server command

Introduce the 'fetch' server command. Signed-off-by: Brandon Williams --- serve.c | 2 + upload-pack.c | 223 ++ upload-pack.h | 9 +++ 3 files changed, 234 insertions(+) create mode 100644 upload-pack.h diff

[WIP 12/15] ls-refs: introduce ls-refs server command

Introduce the ls-refs server command. In protocol v2, the ls-refs command is used to request the ref advertisement from the server. Since it is a command which can be requested (as opposed to manditory in v1), a clinet can sent a number of parameters in its request to limit the ref advertisement

[WIP 09/15] transport: store protocol version

Once protocol_v2 is introduced requesting a fetch or a push will need to be handled differently depending on the protocol version. Store the protocol version the serving is speaking in 'struct git_transport_data' and use it to determine what to do in the case of a fetch or a push. Signed-off-by:

[WIP 06/15] transport: use get_refs_via_connect to get refs

Remove code duplication and use the existing 'get_refs_via_connect()' function to retrieve a remote's heads in 'fetch_refs_via_pack()' and 'git_transport_push()'. Signed-off-by: Brandon Williams --- transport.c | 18 -- 1 file changed, 4 insertions(+), 14

[WIP 15/15] fetch-pack: perform a fetch using v2

When communicating with a v2 server, perform a fetch by requesting the 'fetch' command. Signed-off-by: Brandon Williams --- builtin/fetch-pack.c | 2 +- fetch-pack.c | 237 - fetch-pack.h | 4 +-

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

On Mon, Dec 04, 2017 at 10:31:15PM +0100, Lars Schneider wrote: > >> I would like to add "for your input" or "for you" to convey > >> that Git is not waiting for the machine but for the user. > >> > >>"hint: Launched editor. Waiting for your input..." > >> > >> Would that work for you? > >

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

Jonathan Tan writes: > On Mon, 04 Dec 2017 13:46:43 -0800 > Junio C Hamano wrote: > >> * jt/diff-anchored-patience (2017-11-28) 1 commit >> - diff: support anchoring line(s) >> >> "git diff" learned a variant of the "--patience" algorithm, to >>

Re: [PATCH v2 6/9] rebase -i: update functions to use a flags parameter

Hi Johannes, On 04/12/17 10:46 AM, Johannes Schindelin wrote: > Hi Liam, > > On Sun, 3 Dec 2017, Liam Beguin wrote: > >> diff --git a/sequencer.h b/sequencer.h >> index 4e444e3bf1c4..3bb6b0658192 100644 >> --- a/sequencer.h >> +++ b/sequencer.h >> @@ -45,10 +45,12 @@ int

Re: [PATCH v2 4/9] rebase -i: refactor transform_todo_ids

Hi Junio, On 04/12/17 11:09 AM, Junio C Hamano wrote: > Johannes Schindelin writes: > >> On Sun, 3 Dec 2017, Liam Beguin wrote: >> >>> The transform_todo_ids function is a little hard to read. Lets try >>> to make it easier by using more of the strbuf API. Also,

Re: [PATCH v2 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

On Tuesday 05 December 2017 12:14 AM, Junio C Hamano wrote: Kaartic Sivaraam writes: Stepping back a bit, the mild suspicion above says $ git checkout HEAD^0 ... do things ... $ git checkout -b temp ... do more things ... $ git checkout -B

Re: [PATCH v2 4/9] rebase -i: refactor transform_todo_ids

Hi Johannes, On 04/12/17 09:42 AM, Johannes Schindelin wrote: > Hi Liam, > > On Sun, 3 Dec 2017, Liam Beguin wrote: > >> The transform_todo_ids function is a little hard to read. Lets try >> to make it easier by using more of the strbuf API. Also, since we'll >> soon be adding command

Re: [PATCH 1/4] Makefile: don't error out under DC_SHA1_EXTERNAL if DC_SHA1_SUBMODULE=auto

On Tue, Nov 28, 2017 at 09:32:11PM +, Ævar Arnfjörð Bjarmason wrote: > Fix a logic error in the initial introduction of DC_SHA1_EXTERNAL. If > git.git has a sha1collisiondetection submodule checked out the logic > to set DC_SHA1_SUBMODULE=auto would interact badly with the check for > whether

Re: [PATCH 2/4] sha1dc_git.h: re-arrange an ifdef chain for a subsequent change

On Tue, Nov 28, 2017 at 09:32:12PM +, Ævar Arnfjörð Bjarmason wrote: > A subsequent change will change the semantics of DC_SHA1_SUBMODULE in > a way that would require moving these checks around, so start by > moving them around without any functional changes. OK. This flips the priority,

Re: [PATCH 4/4] sha1dc: remove in favor of using sha1collisiondetection as a submodule

On Tue, Nov 28, 2017 at 09:32:14PM +, Ævar Arnfjörð Bjarmason wrote: > As an aside: Now where was that .gitdiffsort or whatever it was called > which would enable us to show sha1dc_git.h before nuking the contents > of sha1dc? :) diff.orderFile, I think. > It also occurs to me that it would

Re: [PATCH 3/4] Makefile: use the sha1collisiondetection submodule by default

On Tue, Nov 28, 2017 at 09:32:13PM +, Ævar Arnfjörð Bjarmason wrote: > Change the build process so that instead of needing to supply > DC_SHA1_SUBMODULE=YesPlease to use the sha1collisiondetection > submodule instead of the copy of the same code shipped in the sha1dc > directory, it uses the

Re: [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit

Hi Junio, On 05 Dec 2017 01:27, Junio C Hamano wrote: > I know all of the above, but I think you misunderstood the point I > wanted to raise, so let me try again. The thing is, none of what > you just wrote changes the fact that lack of callers that want to do > "multi-line" is IRRELEVANT. I

Re: [PATCH v2] sha1_file: use strbuf_add() instead of strbuf_addf()

On 12/4/2017 11:56 AM, Jeff King wrote: When you put your cover letter first, you need to use "scissors" like: -- >8 -- to separate it from the commit message. Using three-dashes means "git am" will include your cover letter as the commit message, and omit your real commit message entirely.

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

On Mon, Dec 04, 2017 at 07:18:55AM +, Florian Manschwetus wrote: > I could provide a bash script I used in between to make this working > with IIS, without fixing http-backend binary, maybe this helps to > understand how this cases might be handled. I think it would be pretty easy to handle

Re: RFC: Native clean/smudge filter for UTF-16 files

On Sun, Dec 03, 2017 at 07:48:01PM +0100, Lars Schneider wrote: > > - if core.convertEncoding is true, then for any file with an > > encoding=foo attribute, internally run iconv(foo, utf8) in > > convert_to_git(), and likewise iconv(utf8, foo) in > > convert_to_working_tree. > > > > - I'm

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

On Sat, Dec 02, 2017 at 09:15:49AM +0530, Kaartic Sivaraam wrote: > > Or given that the goal is really just making it clear that we've spawned > > an editor, something like "starting editor %s..." would work. > > There was already discussion related to the "continuous tense" used in the >

Re: [PATCH v2 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

On Sat, 2017-12-02 at 17:52 -0800, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > > I have a mild suspicion that "git checkout -B @{-1}" would want to > > > error out instead of creating a valid new branch whose name is > > > 40-hex that happen to be the name

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

On Sun, Dec 03, 2017 at 05:39:10PM +0100, Lars Schneider wrote: > >>> + fprintf(stderr, _("hint: Waiting for your editor > >>> input...")); > >> I found "waiting for editor input" to be a funny way of saying this. I > >> input to the editor, the editor does not input to

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

On Sat, Dec 02, 2017 at 09:15:29PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I tried to think of ways this "show a message and then delete it" could > > go wrong. It should work OK with editors that just do curses-like > > things, taking over the terminal and then

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

On Sun, Dec 03, 2017 at 01:47:04PM +0100, Lars Schneider wrote: > I am on the fence here. I like consistency but I don't want to > bother Git users. > > @Peff: Do you lean into either direction? Could you imagine that > novice/regular users are bothered? (I don't expect experts to be > bothered

[PATCH] Documentation/git-clone: improve description for submodule recursing

There have been a few complaints on the mailing list that git-clone doesn't respect the `submodule.recurse` setting, which every other command (that potentially knows how to deal with submodules) respects. In case of clone this is not beneficial to respect as the user may not want to obtain all

Re: Bug in git-completion.bash in __git_heads() function

Hi, >This is the first time I am sending a bug report here, so if I have > not met the criteria please let me know. >I found that at: > https://github.com/git/git/blob/master/contrib/completion/git-completion.bash#L371, > the usage of refname:strip=2 generates error: > > fatal: unknown

git-completion.bash: Show list of local branches instead of refs for git checkout

Hello, I am using git-completion.bash and when I try to checkout a branch by typing git checkout on the prompt, I get the following: FETCH_HEAD FETCH ORIG_FETCH Will it not be more useful if the list of local branches is populated? If it seems like a good idea I will be willing to submit a

Bug in git-completion.bash in __git_heads() function

Hello, This is the first time I am sending a bug report here, so if I have not met the criteria please let me know. I found that at: https://github.com/git/git/blob/master/contrib/completion/git-completion.bash#L371, the usage of refname:strip=2 generates error: fatal: unknown refname:

Re: git-completion.bash: Show list of local branches instead of refs for git checkout

Hi, > I am using git-completion.bash and when I try to checkout a branch > by typing git checkout on the prompt, I get the following: > > FETCH_HEAD FETCH ORIG_FETCH What is "ORIG_FETCH"? This string was never present in Git's source code. > Will it not be more useful if the list of local

[PATCH v2 1/4] git-compat-util: introduce skip_to_optional_val()

From: Christian Couder We often accept both a "--key" option and a "--key=" option. These options currently are parsed using something like: if (!strcmp(arg, "--key")) { /* do something */ } else if (skip_prefix(arg, "--key=", )) { /* do something

[PATCH v2 3/4] diff: use skip_to_optional_val()

From: Christian Couder Let's simplify diff option parsing using skip_to_optional_val(). Signed-off-by: Christian Couder --- diff.c | 29 ++--- 1 file changed, 10 insertions(+), 19 deletions(-) diff --git a/diff.c

[PATCH v2 4/4] diff: use skip_to_optional_val_default()

Let's simplify diff option parsing using skip_to_optional_val_default(). Signed-off-by: Christian Couder --- diff.c | 20 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/diff.c b/diff.c index 83509f0658..d234b4f0cb 100644 --- a/diff.c

[PATCH v2 2/4] index-pack: use skip_to_optional_val()

From: Christian Couder Let's simplify index-pack option parsing using skip_to_optional_val(). Signed-off-by: Christian Couder --- builtin/index-pack.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git

Re: Git stash (or git rev-parse) doesn't inherit the '--work-tree' parameter

On November 29, 2017 11:02:10 PM PST, marc PINHEDE wrote: >Hello guys, > >I don't know if this is a normal behavior, so I'll just explain it >here. > >* Behavior: > >from a directory OUTSIDE my git repo, I can run this command >successfully: >$ git

Urgent Message

Dear Western Union Customer, You have been awarded with the sum of $250,000 USD by our office, as one of our customers who use Western Union in their daily business transaction. This award was been selected through the internet, where your e-mail address was indicated and notified. Please

Re: [RFE] Inverted sparseness

From: "Randall S. Becker" :December 03, 2017 11:44 PM On December 3, 2017 6:14 PM, Philip Oakley wrote a nugget of wisdom: From: "Randall S. Becker" Sent: Friday, December 01, 2017 6:31 PM On December 1, 2017 1:19 PM, Jeff Hostetler wrote: On 12/1/2017 12:21 PM,

Re: [PATCH v2 4/4] diff: use skip_to_optional_val_default()

Christian Couder writes: > - } else if (!strcmp(arg, "--submodule")) > - options->submodule_format = DIFF_SUBMODULE_LOG; > - else if (skip_prefix(arg, "--submodule=", )) > + } else if (skip_to_optional_val_default(arg, "--submodule", , >

Re: [PATCH 1/3] git-compat-util: introduce skip_to_opt_val()

Christian Couder writes: > In the few cases where do_something() accepts NULL and does something > different with it, the former can be changed to: > > if (skip_to_optional_val(arg, "--key", , NULL) /* the last > argument is the default value */ >

Re: [PATCH] send-email: extract email-parsing code into a subroutine

Nathan PAYRE writes: > I've tested your code, and after few changes it's works perfectly! > The code looks better now. > Thanks a lot for your review. Thanks, both of you. Could you send in the final version later so that I can pick it up? I agree with Matthieu's

Re: [PATCH v2 1/4] git-compat-util: introduce skip_to_optional_val()

Christian Couder writes: > From: Christian Couder > > We often accept both a "--key" option and a "--key=" option. > > These options currently are parsed using something like: > > if (!strcmp(arg, "--key")) { > /* do something */ > }

Re: [PATCH v2] git-gui: Prevent double UTF-8 conversion

Hi Łukasz, On Sat, 2 Dec 2017, Łukasz Stelmach wrote: > Convert author's name from the UTF-8 (or any other) encoding in > load_last_commit function the same way commit message is converted. > > Amending commits in git-gui without such conversion breaks UTF-8 > strings. For example,

Re: [PATCH v2 4/9] rebase -i: refactor transform_todo_ids

Hi Liam, On Sun, 3 Dec 2017, Liam Beguin wrote: > The transform_todo_ids function is a little hard to read. Lets try > to make it easier by using more of the strbuf API. Also, since we'll > soon be adding command abbreviations, let's rename the function so > it's name reflects that change. I am

Re: [PATCH v2 2/2] git-prompt: fix reading files with windows line endings

Hi Robert, 1/2 looks very good. On Sat, 2 Dec 2017, Robert Abel wrote: > If any of the files read by __git_eread have \r\n line endings, read > will only strip \n, leaving \r. This results in an ugly prompt, where > instead of > > user@pc MINGW64 /path/to/repo (BARE:master) > > the last

[PATCH v2] sha1_file: use strbuf_add() instead of strbuf_addf()

Thanks for the feedback on v1. This version fixes the cruft_cb bug and streamlines the strlen(). I would include an inter-diff but it was the same size as the patch. Thanks, -Stolee --- Replace use of strbuf_addf() with strbuf_add() when enumerating loose objects in

Re: [PATCH v2 3/4] diff: use skip_to_optional_val()

Christian Couder writes: > @@ -4540,13 +4535,13 @@ int diff_opt_parse(struct diff_options *options, > return stat_opt(options, av); > > /* renames options */ > - else if (starts_with(arg, "-B") || starts_with(arg, > "--break-rewrites=") || >

Re: [PATCH v2 6/9] rebase -i: update functions to use a flags parameter

Hi Liam, On Mon, 4 Dec 2017, Johannes Schindelin wrote: > On Sun, 3 Dec 2017, Liam Beguin wrote: > > > diff --git a/sequencer.h b/sequencer.h > > index 4e444e3bf1c4..3bb6b0658192 100644 > > --- a/sequencer.h > > +++ b/sequencer.h > > @@ -45,10 +45,12 @@ int sequencer_continue(struct replay_opts

Re: [PATCH v2 4/9] rebase -i: refactor transform_todo_ids

Johannes Schindelin writes: > On Sun, 3 Dec 2017, Liam Beguin wrote: > >> The transform_todo_ids function is a little hard to read. Lets try >> to make it easier by using more of the strbuf API. Also, since we'll >> soon be adding command abbreviations, let's rename

Re: [PATCH v2 6/9] rebase -i: update functions to use a flags parameter

Hi Liam, On Sun, 3 Dec 2017, Liam Beguin wrote: > diff --git a/sequencer.h b/sequencer.h > index 4e444e3bf1c4..3bb6b0658192 100644 > --- a/sequencer.h > +++ b/sequencer.h > @@ -45,10 +45,12 @@ int sequencer_continue(struct replay_opts *opts); > int sequencer_rollback(struct replay_opts *opts);

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

Hi Liam, On Sun, 3 Dec 2017, Liam Beguin wrote: > This series will add the 'rebase.abbreviateCommands' configuration > option to allow `git rebase -i` to default to the single-letter command > names when generating the todo list. > > Using single-letter command names can present two benefits.

Re: How hard would it be to implement sparse fetching/pulling?

On 12/2/2017 11:30 AM, Philip Oakley wrote: From: "Jeff Hostetler" Sent: Friday, December 01, 2017 2:30 PM On 11/30/2017 8:51 PM, Vitaly Arbuzov wrote: I think it would be great if we high level agree on desired user experience, so let me put a few possible use cases

  1   2   >