Re: [RFC PATCH v2] builtin/worktree: enhance worktree removal

On Mon, Nov 27, 2017 at 11:04 PM, Junio C Hamano wrote: > Eric Sunshine writes: >> I had envisioned a simple 'goto remove_control_info' rather than extra >> nesting or refactoring, but that's a minor point. > > Yes, use of goto is also a good way to

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

Junio C Hamano writes: > Jeff King writes: > >> without having "wish" on the build machine. If everybody is happy with >> the BYPASS mechanism you added to address that, then I'm perfectly fine >> with it. > > OK. The topic was queued on 'pu' yesterday; lets

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

Jeff King writes: > ... "if we need advice.*, that is a good sign that the > feature is mis-designed". > > Let me elaborate a bit on the latter. > > My gut feeling is that this is absolutely the wrong place to put a > message like this > The right place for this message, IMHO,

Re: [PATCH] repository: fix a sparse 'using integer as NULL pointer' warning

Ramsay Jones writes: > Hi Junio, > > I don't recall Brian doing a re-roll of the 'bc/hash-algo' branch[1], but > now that it has been merged into the 'next' branch, sparse is barking on > that branch too. This patch (slightly different to the last one) applies > on

Re: [RFC PATCH v2] builtin/worktree: enhance worktree removal

Eric Sunshine writes: > With this approach, validate_worktree() will print an error message > saying that the worktree directory is missing before the control info > is actually removed. Kaartic's original patch silenced the message > (and _all_ error messages from

Re: [RFC PATCH v2] builtin/worktree: enhance worktree removal

On Mon, Nov 27, 2017 at 10:02 PM, Junio C Hamano wrote: > I actually wonder if this "early check and return" is making the > code unmaintainable. What if we instead did it with just the > codeflow restructuring, perhaps like so? > > if (!validate_worktree(wt, 0)) { >

Re: [PATCH v3 4/4] exec_cmd: RUNTIME_PREFIX on some POSIX systems

Dan Jacques writes: >> In Git for Windows, we have an almost identical patch: >> >> https://github.com/git-for-windows/git/commit/bdd739bb2b0b >> >> We just guard the call to system_path() behind a test whether podir is >> already absolute, but these days, system_path() does

Re: [PATCH v3 4/4] exec_cmd: RUNTIME_PREFIX on some POSIX systems

> In Git for Windows, we have an almost identical patch: > > https://github.com/git-for-windows/git/commit/bdd739bb2b0b > > We just guard the call to system_path() behind a test whether podir is > already absolute, but these days, system_path() does that itself. > > I am too little of a Perl

Re: [RFC PATCH v2] builtin/worktree: enhance worktree removal

Kaartic Sivaraam writes: > diff --git a/builtin/worktree.c b/builtin/worktree.c > index b5afba164..6eab91889 100644 > --- a/builtin/worktree.c > +++ b/builtin/worktree.c > @@ -605,6 +605,23 @@ static int move_worktree(int ac, const char **av, const > char *prefix) >

[PATCH] repository: fix a sparse 'using integer as NULL pointer' warning

Commit 78a6766802 ("Integrate hash algorithm support with repo setup", 2017-11-12) added a 'const struct git_hash_algo *hash_algo' field to the repository structure, without modifying the initializer of the 'the_repo' variable. This does not actually introduce a bug, since the '0' initializer for

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

Kaartic Sivaraam writes: > When the N-th previous thing checked out sytax is used with > '--branch' option of check-ref-format the results might not > always be a valid branch name I wonder if you want to rephrase this, because 40-hex object name is syntactically a

Re: [PATCH v2 1/2] Doc/checkout: checking out using @{-N} can lead to detached state

Kaartic Sivaraam writes: > any branch (see below for details). > + > -As a special case, the `"@{-N}"` syntax for the N-th last branch/commit > -checks out branches (instead of detaching). You may also specify > -`-` which is synonymous with `"@{-1}"`. > +You

Re: [PATCH v2 3/3] rebase: rebasing can also be done when HEAD is detached

Kaartic Sivaraam writes: > + if test "$branch_or_commit" = "HEAD" && > + !(git symbolic-ref -q HEAD) Did you need a subshell here? Now with a proper test with "symbolic-ref -q HEAD", I wonder if you'd need to check if the original

Re: [PATCH v2 0/3] rebase: give precise error message

Kaartic Sivaraam writes: > 1. "git rebase " does nothing Not limited to "rebase", you do not muck with remote-tracking branch in your local repository, so it would be a bug if the above updated where the remote-tracking branch points at. The form of "git rebase"

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

mwnx writes: > On Mon, Nov 27, 2017 at 10:46:23AM +0900, Junio C Hamano wrote: >> By the way, Documentation/SubmittingPatches has this in "(5) Certify >> your work" section: >> >> Also notice that a real name is used in the Signed-off-by: line. Please >> don't hide your

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

Hi Johannes, As long as this PR is included in next Git for Windows release, I won't suffer from slow git fetch. https://github.com/git-for-windows/git/pull/1372 But I sent you 2 PRs to follow right way. https://github.com/git-for-windows/git/pull/1379

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

Jonathan Tan writes: > - else if (!strcmp(arg, "--patience")) > + else if (!strcmp(arg, "--patience")) { > + int i; > options->xdl_opts = DIFF_WITH_ALG(options, PATIENCE_DIFF); > - else if (!strcmp(arg, "--histogram")) > +

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

Hi Johannes, On 27/11/2017 22:54, Johannes Sixt wrote: > > I my opinion, putting the focus on integration merge commits and the > desire to automate the re-merge step brings in a LOT of complexity in > the implementation for a very specific use-case that does not > necessarily help other cases.

Re: [PATCH v3] git-send-email: honor $PATH for sendmail binary

Florian Klink writes: > This extends git-send-email to also consider sendmail binaries in $PATH > after checking the (fixed) list of /usr/sbin and /usr/lib, and before > falling back to localhost. > > Signed-off-by: Florian Klink > --- Thanks for an update.

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

On Mon, Nov 27, 2017 at 3:39 PM, Junio C Hamano wrote: > Elijah Newren writes: > >>> As a fix, this sorely wants something new in t/ directory. >> >> Well, then perhaps I was wrong to submit it independent of my >> directory rename series. As noted in the

[PATCH v3] git-send-email: honor $PATH for sendmail binary

This extends git-send-email to also consider sendmail binaries in $PATH after checking the (fixed) list of /usr/sbin and /usr/lib, and before falling back to localhost. Signed-off-by: Florian Klink --- Documentation/git-send-email.txt | 6 +++--- git-send-email.perl

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

Hi Junio, On Tue, 28 Nov 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > My current plan is to release a new Git for Windows version on Wednesday, > > to allow for a new cURL version to be bundled. > > Is this an updated 2.15.0 or are you planning

Re: [PATCH] git-send-email: honor $PATH

Support to detect sendmail binaries in windows' PATH seems a bit more complex. The separator is different, and PATHEXT would need to be considered too. I'm not even sure if having a sendmail binary in PATH on windows is something usual or if defaulting to smtp to localhost (what we currently do)

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

Johannes Schindelin writes: > My current plan is to release a new Git for Windows version on Wednesday, > to allow for a new cURL version to be bundled. Is this an updated 2.15.0 or are you planning to package 2.15.1? I am asking because you earlier asked me to hold

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

Johannes Schindelin writes: > could I ask for a favor? I'd like the oneline to start with > > rebase -i -x: ... > > (this would help future me to realize what this commit touches already > from the concise graph output I favor). Excellent. >> Recent work on

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

Johannes Schindelin writes: >> As the name of a public function, it does not feel that this hints >> it strongly enough that it is from and a part of sequencer.c API. > > How about a "yes, and" instead? As in: > > To further improve this patch, let's use the name >

Re: [PATCH v3 4/4] exec_cmd: RUNTIME_PREFIX on some POSIX systems

Hi Dan, On Mon, 27 Nov 2017, Dan Jacques wrote: > diff --git a/gettext.c b/gettext.c > index db727ea02..6b64d5c2e 100644 > --- a/gettext.c > +++ b/gettext.c > @@ -2,7 +2,8 @@ > * Copyright (c) 2010 Ævar Arnfjörð Bjarmason > */ > > -#include "git-compat-util.h" > +#include "cache.h" >

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

Jeff King writes: > without having "wish" on the build machine. If everybody is happy with > the BYPASS mechanism you added to address that, then I'm perfectly fine > with it. OK. The topic was queued on 'pu' yesterday; lets move it forward after waiting for a few more days to

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

Elijah Newren writes: >> As a fix, this sorely wants something new in t/ directory. > > Well, then perhaps I was wrong to submit it independent of my > directory rename series. As noted in the (very lengthy) extended > commit message explanation, the assumption the previous

Re: [PATCHv5 7/7] builtin/describe.c: describe a blob

Stefan Beller writes: >> I was reacting to your "fixed". So will we see a rerolled series or >> not? > > I was not planning on rerolling it. OK. Then I do not have to worry about this one and drop it perhaps. One less topic on 'pu' is always good, if it is not active.

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

On Mon, Nov 27, 2017 at 10:46:23AM +0900, Junio C Hamano wrote: > By the way, Documentation/SubmittingPatches has this in "(5) Certify > your work" section: > > Also notice that a real name is used in the Signed-off-by: line. Please > don't hide your real name. I did read that document,

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

lars.schnei...@autodesk.com writes: > diff to v2: > - shortened and localized the "waiting" message > - detect "emacsclient" and suppress "waiting" message Thanks for moving this forward. > + static const char *close_notice = NULL; Because this thing is "static", the

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

Hi Liam, On Sun, 26 Nov 2017, Liam Beguin wrote: > 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. Makes sense. As to the diff: > diff --git

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

On Tue, Nov 28, 2017 at 12:04:45AM +0100, Johannes Schindelin wrote: > > +rebase.abbreviateCommands:: > > + If set to true, `git rebase` will use abbreviated command names in the > > + todo list resulting in something like this: > > + > > +--- > > + p

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

On Mon, Nov 27, 2017 at 08:09:32PM +, brian m. carlson wrote: > > Show a message in the original terminal and get rid of it when the > > editor returns. > [...] > > Sorry for coming to the topic so late, but it occurred to me that we > might want to conditionalize this on an advice.* flag.

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

Hi Liam, On Sun, 26 Nov 2017, Liam Beguin wrote: > diff --git a/Documentation/rebase-config.txt b/Documentation/rebase-config.txt > index 30ae08cb5a4b..0820b60f6e12 100644 > --- a/Documentation/rebase-config.txt > +++ b/Documentation/rebase-config.txt > @@ -30,3 +30,22 @@

Re: git status always modifies index?

On Mon, Nov 27, 2017 at 12:57:31PM -0800, Jonathan Nieder wrote: > > 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 > >

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

Hi Liam, could I ask for a favor? I'd like the oneline to start with rebase -i -x: ... (this would help future me to realize what this commit touches already from the concise graph output I favor). On Sun, 26 Nov 2017, Liam Beguin wrote: > Recent work on `git-rebase--interactive` aim

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

Am 26.11.2017 um 23:35 schrieb Igor Djordjevic: Approach discussed here could have a few more useful applications, but one seems to be standing out the most - in case where multiple topic branches are temporarily merged for integration testing, it could be very useful to be able to post "hotfix"

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

Hi Junio, On Mon, 27 Nov 2017, Junio C Hamano wrote: > 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

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

Hi Liam, On Sun, 26 Nov 2017, Liam Beguin wrote: > Use "todo list" instead of "instruction list" or "todo-list" to > reduce further confusion regarding the name of this script. Makes sense, Johannes

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

Hi Liam, On Sun, 26 Nov 2017, Liam Beguin wrote: > 3 files changed, 34 insertions(+), 48 deletions(-) Very nice! Johannes

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

Hi, On Mon, 27 Nov 2017, Takuto Ikuta wrote: > 2017-11-27 13:53 GMT+09:00 Junio C Hamano : > > Jeff King writes: > > > >>> The 5-patch series that contains the same change as this one is > >>> cooking and will hopefully be in the released version before the end

Re: Problem installing Git

On 11/25/2017 5:16 PM, Johannes Schindelin wrote: Hi Igor, On Thu, 23 Nov 2017, Igor Djordjevic 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. On 23/11/2017 19:51, Phil Martel wrote: I'm

Re: git status always modifies index?

Hi, Jeff King wrote: > 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

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

On 11/27, Junio C Hamano wrote: > 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

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

On 11/27, Junio C Hamano wrote: > 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

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

Hi Kaartic, On Mon, 27 Nov 2017, Kaartic Sivaraam wrote: > On Monday 27 November 2017 11:37 AM, Junio C Hamano wrote: > > Jeff King writes: > > > +using `git --no-optional-locks status` (see linkgit:git[1] for details). > > It strikes me just now that `--no-side-effects` might

Re: git status always modifies index?

Hi Junio, On Mon, 27 Nov 2017, Junio C Hamano wrote: > 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. > > >

Re: git status always modifies index?

Hi, Johannes Schindelin wrote: > On Mon, 27 Nov 2017, Jeff King wrote: >> [...] IMHO it argues for GfW trying to land patches upstream first, and >> then having them trickle in as you merge upstream releases. > > You know that I tried that, and you know why I do not do that anymore: it > simply

Re: git status always modifies index?

Hi Peff, On Mon, 27 Nov 2017, Jeff King wrote: > [...] IMHO it argues for GfW trying to land patches upstream first, and > then having them trickle in as you merge upstream releases. You know that I tried that, and you know why I do not do that anymore: it simply takes too long, and the review

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

On Mon, Nov 27, 2017 at 02:47:16PM +0100, lars.schnei...@autodesk.com wrote: > From: Junio C Hamano > > When a graphical GIT_EDITOR is spawned by a Git command that opens > and waits for user input (e.g. "git rebase -i"), then the editor window > might be obscured by other

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

> On 27 Nov 2017, at 19:36, Eric Sunshine wrote: > > On Mon, Nov 27, 2017 at 8:47 AM, wrote: >> When a graphical GIT_EDITOR is spawned by a Git command that opens >> and waits for user input (e.g. "git rebase -i"), then the editor window

[PATCH v2] diff: support anchoring line(s)

Teach diff a new algorithm, one that attempts to prevent user-specified lines from appearing as a deletion or addition in the end result. The end user can use this by specifying "--anchored=" one or more times when using Git commands like "diff" and "show". Signed-off-by: Jonathan Tan

Re: [PATCH v5 4/6] list-objects: filter objects in traverse_commit_list

On 11/22/2017 5:56 PM, Stefan Beller wrote: On Tue, Nov 21, 2017 at 12:58 PM, Jeff Hostetler wrote: + assert(arg); + assert(!unset); I count 16 asserts in this patch. Is that really needed? Either omit them or use BUG if we want to rely on user bug

Re: [PATCHv5 7/7] builtin/describe.c: describe a blob

On Thu, Nov 23, 2017 at 11:18 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> On Tue, Nov 21, 2017 at 11:55 PM, Junio C Hamano wrote: >>> Stefan Beller writes: >>> ... fixed. ... fixed the

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

On Mon, Nov 27, 2017 at 8:47 AM, wrote: > When a graphical GIT_EDITOR is spawned by a Git command that opens > and waits for user input (e.g. "git rebase -i"), then the editor window > might be obscured by other windows. The user may be left staring at the > original

Re: [PATCH] xdiff/xpatience: support anchoring line(s)

On Thu, 23 Nov 2017 11:47:02 +0900 Junio C Hamano wrote: > Thinking about this a bit more, I do like the basic idea of the UI > even better. What we could do is to sell this to the end users as a > new kind of diff algorithm choice (i.e. myers, patience, ... will > gain a new

[RFC PATCH v2] builtin/worktree: enhance worktree removal

"git worktree remove" removes both the named worktree directory and the administrative information for it after checking that there is no local modifications that would be lost (which is a handy safety measure). However, due to a possible oversight, it aborts with an error if the worktree

Re: git checkout's stderr v stdout usage

Great succession! I appreciates you and good to see such a positive responses. You can change your ip address of 192.168.l.254 login and password details at anytime. Thank you!! -- Sent from: http://git.661346.n2.nabble.com/

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

When the N-th previous thing checked out sytax is used with '--branch' option of check-ref-format the results might not always be a valid branch name as @{-N} is used to refer to the N-th last checked out "thing" which might be any commit (sometimes a branch). The documentation thus does a wrong

[PATCH v2 1/2] Doc/checkout: checking out using @{-N} can lead to detached state

@{-N} is a syntax for the N-th last "checkout" and not the N-th last "branch". Therefore, in some cases using `git checkout @{-$N}` DOES lead to a "detached HEAD" state. This can also be ensured by the commit message of 75d6e552a (Documentation: @{-N} can refer to a commit, 2014-01-19) which

[PATCH v2 2/3] rebase: distinguish user input by quoting it

Signed-off-by: Kaartic Sivaraam --- git-rebase.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-rebase.sh b/git-rebase.sh index a675cf691..3f8d99e99 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -477,7 +477,7 @@ then

[PATCH v2 3/3] rebase: rebasing can also be done when HEAD is detached

Attempting to rebase when the HEAD is detached and is already up to date with upstream (so there's nothing to do), the following message is shown Current branch HEAD is up to date. which is clearly wrong as HEAD is not a branch. Handle the special case of HEAD correctly to give a more

[PATCH v2 0/3] rebase: give precise error message

Junio C Hamano writes: > Perhaps time to learn "git symbolic-ref HEAD" and use it instead of > depending on the name? Good point. Helped remove the assumption that there's no branch named HEAD. (and indirectly led to 2 additional patches and the 3 questions found below ;-)

[PATCH v2 1/3] rebase: use a more appropriate variable name

The variable name "branch_name" used to indicate the parameter in "git rebase " is misleading as it seems to indicate that it holds only a "branch name" although at times it might actually hold any valid (branch/commit). So, use a more suitable name for that variable. Signed-off-by: Kaartic

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

On Monday 27 November 2017 07:17 PM, lars.schnei...@autodesk.com wrote: Show a message in the original terminal and get rid of it when the editor returns. "... except in the case when an error occurs." could be included if needed. + static const char *close_notice = NULL; +

[PATCH v3 1/4] Makefile: generate Perl header from template file

Currently, the generated Perl script headers are emitted by commands in the Makefile. This mechanism restricts options to introduce alternative header content, needed by Perl runtime prefix support, and obscures the origin of the Perl script header. Change the Makefile to generate a header by

[PATCH v3 4/4] exec_cmd: RUNTIME_PREFIX on some POSIX systems

Enable Git to resolve its own binary location using a variety of OS-specific and generic methods, including: - procfs via "/proc/self/exe" (Linux) - _NSGetExecutablePath (Darwin) - KERN_PROC_PATHNAME sysctl on BSDs. - argv0, if absolute (all, including Windows). This is used to enable

[PATCH v3 2/4] Makefile: add support for "perllibdir"

Add the "perllibdir" Makefile variable, which allows the customization of the Perl library installation path. The Perl library installation path is currently left entirely to the Perl Makefile implementation, either MakeMaker (default) or a fixed path when NO_PERL_MAKEMAKER is enabled. This patch

[PATCH v3 3/4] Makefile: add Perl runtime prefix support

Add a new Makefile flag, RUNTIME_PREFIX_PERL, which, when enabled, configures Perl scripts to locate the Git installation's Perl support libraries by resolving against the script's path, rather than hard-coding that path at build-time. Enabling RUNTIME_PREFIX_PERL overrides the system-specific

[PATCH v3 0/4] RUNTIME_PREFIX relocatable Git

Previous threads: v1: https://public-inbox.org/git/20171116170523.28696-1-...@google.com/ v2: https://public-inbox.org/git/20171119173141.4896-1-...@google.com/ After working with avarab@, I isolated the Perl changes into a separate set of patches and adapted the code to be more correct and

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

[Removed cc's that just bounce] On Sun, Nov 26, 2017 at 7:40 PM, Junio C Hamano wrote: > 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

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

On Sun, Nov 26, 2017 at 09:57:14PM +0100, Christian Couder wrote: > > As much as I hate autoconf, > > is it the right advice for somebody who doesn't want to look at the > > Makefile knobs to do: > > > > autoconf > > ./configure > > make > > > > ? > > I don't think so. I think it is just

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

On Mon, Nov 27, 2017 at 09:24:47AM +0100, Christian Couder 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 think any part of my patch

[PATCH v3] launch_editor(): indicate that Git waits for user input

From: Junio C Hamano When a graphical GIT_EDITOR is spawned by a Git command that opens and waits for user input (e.g. "git rebase -i"), then the editor window might be obscured by other windows. The user may be left staring at the original Git terminal window without even

Re: git-p4: cloning with a change number does not import all files

> On 25 Nov 2017, at 21:35, Patrick Rouleau wrote: > > Hi, > > I created a git repository with these commands: > git p4 clone //perforce/path@123456 repo > cd repo > git p4 rebase > > Some files created before the change 123456 do not exist in git > history. I do see

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

On Monday 27 November 2017 11:37 AM, Junio C Hamano wrote: Jeff King writes: +using `git --no-optional-locks status` (see linkgit:git[1] for details). It strikes me just now that `--no-side-effects` might have been a better name for the option (of course, iff this avoid all

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

> Spotted yet another. This function in a header file, that is included by many source files, must be made "static inline" (which I already did as without the fix I couldn't get 'pu' to compile). Thanks, missed that, seems my compiler inlined all calls and I didn't notice the problem. On 27

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

Jeff King writes: > I think that's the rub, though. We hit this code path by default, so > it's _not_ a sign that the builder cares about gitk. OK. >> Whether the builder wants to run the result on the same box is a >> separate and irrelevant matter. Once built and installed, a

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

On Mon, Nov 27, 2017 at 5:35 AM, Jeff King wrote: > 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... >>