Re: [PATCH v2] gitcli: tweak "man gitcli" for clarity

On Wed, 22 Nov 2017, Jeff King wrote: > On Tue, Nov 21, 2017 at 10:45:52PM +0100, Kevin Daudt wrote: > > > > - * Without disambiguating `--`, Git makes a reasonable guess, but errors > > > - out and asking you to disambiguate when ambiguous. E.g. if you have a > > > + * Without a

In einer kurzen Einführung

In einer kurzen Einführung, Ich bin ein Rechtsanwalt Vladimir Volf, aus Czech Republic, lebe zurzeit in London, ich habe dir eine E-Mail über deine verstorbene Familienangehörige verspätet. Ich habe keine Antwort von dir erhalten. Die verstorbene Person ist eine Bürgerin deines Landes mit dem

Re: Unify annotated and non-annotated tags

On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano wrote: > Igor Djordjevic writes: > >> If you would like to mimic output of "git show-ref", repeating >> commits for each tag pointing to it and showing full tag name as >> well, you could do something

Re: [PATCH v3 00/33] Add directory rename detection to git

On Wed, Nov 22, 2017 at 11:24 AM, Stefan Beller wrote: > On Tue, Nov 21, 2017 at 5:12 PM, Elijah Newren wrote: >> On Tue, Nov 21, 2017 at 4:42 PM, Stefan Beller wrote: >>> On Tue, Nov 21, 2017 at 12:00 AM, Elijah Newren

Re: [PATCH 1/5] p5550: factor our nonsense-pack creation

On Thu, Nov 23, 2017 at 11:41:25AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > Right, I came to the same conclusion (we may even have discussed this on > > the list, I don't remember). The current "todo" format says that only > > the command and sha1 matter, and we'd

Re: [PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO

On Thu, Nov 23, 2017 at 10:38:07AM +0900, Junio C Hamano wrote: > > FWIW I think we've done fine at using assert so far. But if I > > understand correctly, the point of this series is to stop having to > > worry about it. > > I recalled that there was at least one, and "log -Sassert" piped to >

Re: [PATCH] defer expensive load_ref_decorations until needed

On Thu, Nov 23, 2017 at 11:19:42AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > And lazy-load wouldn't help you there for a normal: > > > > git log > > > > But what's interesting in your command is the pretty-format. Even though > > decoration is turned on, your

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

Junio C Hamano writes: > What do we do when > > git diff --histogram --patience > > is given? Do we warn? If we don't, perhaps it may not be too bad > if > > git diff --histogram --patience-anchor=foo > git diff --patience-anchor=foo --histogram > > did not get

Re: [PATCH 1/5] p5550: factor our nonsense-pack creation

Jeff King writes: > Right, I came to the same conclusion (we may even have discussed this on > the list, I don't remember). The current "todo" format says that only > the command and sha1 matter, and we'd be changing that. Maybe that's not > so bad if the user has to enable the

Re: [PATCH 5/5] sha1_file: don't re-scan pack directory for null sha1

Jeff King writes: > So there are four cases we care about for this call in fetch: > > 1. We fed a real sha1 and got a commit (or peeled to one). > > 2. We fed a real sha1 which resolved to a non-commit, and we got NULL. > > 3. We fed a real sha1 and the object was missing or

Re: [PATCH v2] gitcli: tweak "man gitcli" for clarity

Jeff King writes: > I read the rest of the thread, and I think the question here is not > about Git's behavior, but about parsing this sentence. > > Without a "--" Git can sometimes do what you want. Or it may error out, > if what you asked for is ambiguous. And that sentence is

Re: [PATCH] defer expensive load_ref_decorations until needed

Jeff King writes: > And lazy-load wouldn't help you there for a normal: > > git log > > But what's interesting in your command is the pretty-format. Even though > decoration is turned on, your format doesn't show any. So we never > actually ask "is this commit decorated" and the

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

Junio C Hamano writes: > Jonathan Tan writes: > >> One thing that might help is to warn if --anchor is used without >> --patience, but I couldn't find a good place to put that warning. Let me >> know if you know of a good place. > > How about

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

Jonathan Tan writes: > One thing that might help is to warn if --anchor is used without > --patience, but I couldn't find a good place to put that warning. Let me > know if you know of a good place. How about dropping --anchor option and do it as "--patience="?

Re: [PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO

Jonathan Nieder writes: > FWIW I think we've done fine at using assert so far. But if I > understand correctly, the point of this series is to stop having to > worry about it. I recalled that there was at least one, and "log -Sassert" piped to "less" that looks for "/^[

[ANNOUNCE] Bug tracker for Git

Hi, As discussed at [1], I've occasionally wanted to have a place to keep track of bugs I'm working on in Git. Some kind people on the Chromium project helped me set an issue tracker up, so now we have one. https://crbug.com/git Feel free to file bugs, feature requests, and leftover bits

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

On Wed, Nov 22, 2017 at 3:41 PM, Jonathan Tan wrote: > Teach the patience diff to attempt preventing user-specified lines from > appearing as a deletion or addition in the end result. The end user can > use this by specifying "--anchor=" one or more times when using >

Re: [PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO

On Wed, Nov 22, 2017 at 04:08:39PM -0800, Jonathan Nieder wrote: > > For the record, I'm totally fine with banning assert() in favor of a > > custom equivalent. I just don't think we've seen any real problems with > > assert in our codebase so far. > > It sounds like we basically agree, then. :)

Re: [PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO

Jeff King wrote: > On Wed, Nov 22, 2017 at 03:45:32PM -0800, Jonathan Nieder wrote: >> It lets you build with NDEBUG. > > But why do you want to build with NDEBUG if nothing uses assert()? ;) No idea, but some distros (not Debian) have done it before and I don't want to be burned again. > I'm

Re: [PATCH v2] gitcli: tweak "man gitcli" for clarity

On Tue, Nov 21, 2017 at 10:45:52PM +0100, Kevin Daudt wrote: > > - * Without disambiguating `--`, Git makes a reasonable guess, but errors > > - out and asking you to disambiguate when ambiguous. E.g. if you have a > > + * Without a disambiguating `--`, Git makes a reasonable guess, but can >

Re: [PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO

On Wed, Nov 22, 2017 at 03:45:32PM -0800, Jonathan Nieder wrote: > Jeff King wrote: > > > Yes. I'd be fine having a single-argument BUG_ON() like that. But then, > > I'm not sure what it's buying us over assert(). > > It lets you build with NDEBUG. But why do you want to build with NDEBUG if

Re: [PATCH 1/3] Documentation/CodingGuidelines: explain why assert is bad

Stefan Beller wrote: > On Wed, Nov 22, 2017 at 2:59 PM, Jonathan Nieder wrote: >> In a certain ideal world, the preference would be reversed: you'd want >> to use assert() wherever you can and require the compiler to check >> that all assert()s are verifiable at compile time.

Re: [PATCH] defer expensive load_ref_decorations until needed

On Wed, Nov 22, 2017 at 03:21:06PM -0800, Phil Hord wrote: > Hm. I think I was confused. > > I wrote v1 of this patch a few months ago. Clearly I was wrong about > rev-parse being afflicted. We have a script that was suffering and it > uses both "git log --format=%h" and "git rev-parse" to get

Re: [PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO

Jeff King wrote: > Yes. I'd be fine having a single-argument BUG_ON() like that. But then, > I'm not sure what it's buying us over assert(). It lets you build with NDEBUG. It also goes through our own die() handler, which means that e.g. the error message gets propagated over remote transports.

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

Teach the patience diff to attempt preventing user-specified lines from appearing as a deletion or addition in the end result. The end user can use this by specifying "--anchor=" one or more times when using Git commands like "diff" and "show". Signed-off-by: Jonathan Tan

Re: [PATCH v3 5/5] Testing: provide tests requiring them with ellipses after SHA-1 values

From: "Junio C Hamano" "Philip Oakley" writes: From: "Junio C Hamano" Ann T Ropea writes: *1* We are being overly generous in t4013-diff-various.sh because we do not want to destroy/take apart the

Re: [PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO

On Wed, Nov 22, 2017 at 03:28:14PM -0800, Jonathan Nieder wrote: > > I do like human readable messages. But sometimes such a message just > > makes the code harder to read (and to write). E.g., is there any real > > value in: > > > > BUG_ON(!foo, "called bar() with a foo!"); > > > > over: > > >

Re: [PATCH 2/3] git-compat: introduce BUG_ON(condition, fmt, ...) macro

On Wed, Nov 22, 2017 at 03:02:39PM -0800, Jonathan Nieder wrote: > > --- a/git-compat-util.h > > +++ b/git-compat-util.h > > @@ -1092,9 +1092,13 @@ static inline int regexec_buf(const regex_t *preg, > > const char *buf, size_t size, > > __attribute__((format (printf, 3, 4))) NORETURN > > void

Re: [PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO

Hi, Jeff King wrote: > On Wed, Nov 22, 2017 at 02:38:24PM -0800, Stefan Beller wrote: >> On reviewing [1] I wondered why there are so many asserts and wondered >> if these asserts could have been prevented by a better functionality around >> bug reporting in our code. >> >> Introduce a BUG_ON

Re: [PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO

On Wed, Nov 22, 2017 at 02:38:24PM -0800, Stefan Beller wrote: > On reviewing [1] I wondered why there are so many asserts and wondered > if these asserts could have been prevented by a better functionality around > bug reporting in our code. > > Introduce a BUG_ON macro, which is superior to

Re: [PATCH] defer expensive load_ref_decorations until needed

On Wed, Nov 22, 2017 at 1:27 PM, Jeff King wrote: > On Tue, Nov 21, 2017 at 03:43:36PM -0800, Phil Hord wrote: > >> With many thousands of references, a simple `git rev-parse HEAD` may take >> more than a second to return because it first loads all the refs into >> memory even

Re: [PATCH 1/3] Documentation/CodingGuidelines: explain why assert is bad

On Wed, Nov 22, 2017 at 2:59 PM, Jonathan Nieder wrote: > In a certain ideal world, the preference would be reversed: you'd want > to use assert() wherever you can and require the compiler to check > that all assert()s are verifiable at compile time. A check that a > static

Re: [PATCH 2/3] git-compat: introduce BUG_ON(condition, fmt, ...) macro

Hi, Stefan Beller wrote: > --- a/git-compat-util.h > +++ b/git-compat-util.h > @@ -1092,9 +1092,13 @@ static inline int regexec_buf(const regex_t *preg, > const char *buf, size_t size, > __attribute__((format (printf, 3, 4))) NORETURN > void BUG_fl(const char *file, int line, const char *fmt,

Re: [PATCH 1/3] Documentation/CodingGuidelines: explain why assert is bad

Hi, Stefan Beller wrote: > --- a/Documentation/CodingGuidelines > +++ b/Documentation/CodingGuidelines > @@ -386,6 +386,9 @@ For C programs: > - Use Git's gettext wrappers to make the user interface > translatable. See "Marking strings for translation" in po/README. > > + - Prefer the

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

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 reports when these conditions trigger, as assert is

[PATCH 3/3] contrib/coccinelle: convert all conditional bugs to bug_on

Add a coccinelle patch that detects a conditional BUG and converts it to BUG_ON. Also apply that semantic patch. Signed-off-by: Stefan Beller --- builtin/merge.c | 3 +-- contrib/coccinelle/bug_on.cocci | 8 environment.c | 22

[PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO

On reviewing [1] I wondered why there are so many asserts and wondered if these asserts could have been prevented by a better functionality around bug reporting in our code. Introduce a BUG_ON macro, which is superior to assert() by * being always there, even when compiled with NDEBUG and *

[PATCH 2/3] git-compat: introduce BUG_ON(condition, fmt, ...) macro

A lot of BUG() invocations are in the form of if (condition) BUG() so moving the condition into the same line as the macro will result in more readable code. The conversion to use this MACRO will happen in a later patch. This macro in name and spirit is borrowed from linux, which

[PATCH 1/3] Documentation/CodingGuidelines: explain why assert is bad

Signed-off-by: Stefan Beller --- Documentation/CodingGuidelines | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index c4cb5ff0d4..4f8791895b 100644 --- a/Documentation/CodingGuidelines +++

Re: [PATCH 1/5] p5550: factor our nonsense-pack creation

On Tue, Nov 21, 2017 at 04:32:42PM -0800, Stefan Beller wrote: > > Heh, yes. I even fixed it once, but I have the funny habit of noticing > > such typos while reading the "todo" list of "rebase -i" and fixing them > > there. Which of course has no impact whatsoever on the commit. :-/ > > That

Re: [PATCH 5/5] sha1_file: don't re-scan pack directory for null sha1

On Wed, Nov 22, 2017 at 10:42:30AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > I'm not sure what the right behavior is, but I'm pretty sure that's not > > it. Probably one of: > > > > - skip updating the ref when we see the breakage > > > > - ditto, but terminate

[PATCH v4 0/4] make git worktree add dwim more

The previous rounds were 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/ and https://public-inbox.org/git/20171118224706.13810-1-t.gumme...@gmail.com/. Thanks Eric for the review of the previous

[PATCH v4 2/4] 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 v4 1/4] 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 v4 3/4] 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 v4 4/4] worktree: make add dwim

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 ". Make 'git worktree add behave more like the dwim machinery in 'git checkout ', i.e. check if the new branch name uniquely

Re: git status always modifies index?

On Wed, Nov 22, 2017 at 01:56:35PM -0800, Jonathan Nieder wrote: > Jeff King wrote: > > On Wed, Nov 22, 2017 at 12:27:20PM -0800, Jonathan Nieder wrote: > > >> That said, I wonder if this use case is an illustration that a name > >> like --no-lock-index (as was used in Git for Windows when this

Re: [PATCH v2] Teach stash to parse -m/--message like commit does

On Wed, Nov 22, 2017 at 01:20:30PM -0800, Phil Hord wrote: > `git stash push -m foo` uses "foo" as the message for the stash. But > `git stash push -m"foo"` does not parse successfully. Similarly > `git stash push --message="My stash message"` also fails. The stash > documentation doesn't

Re: git status always modifies index?

Jeff King wrote: > On Wed, Nov 22, 2017 at 12:27:20PM -0800, Jonathan Nieder wrote: >> That said, I wonder if this use case is an illustration that a name >> like --no-lock-index (as was used in Git for Windows when this feature >> first appeared) or --no-refresh-on-disk-index (sorry, I am

Re: [PATCH v5 00/10] Partial clone part 2: fsck and promisors

On Wed, Nov 22, 2017 at 10:00 AM, Jonathan Tan wrote: > On Wed, 22 Nov 2017 14:25:13 +0900 > Junio C Hamano wrote: > >> Thanks, will replace/queue all three series. I am getting a feeling >> that the first one is already ready for 'next', while the

Re: Bisect marking new commits incorrectly

On Wed, Nov 22, 2017 at 05:01:29PM +, Adam Dinwoodie wrote: > > So if you test a commit that git bisect asks you to test, and it > > appears that this commit is "new", then you can just discard the > > previous "new" commit because it will give you less information than > > the new "new" one.

[PATCH v2 2/2] stash-store: add failing test for same-ref

stash-store cannot create a new stash with the same ref as stash@{0}. No error is returned even though no new stash log is created. Add a failing test to track. Signed-off-by: Phil Hord --- t/t3903-stash.sh | 11 +++ 1 file changed, 11 insertions(+) diff --git

Re: [PATCH] defer expensive load_ref_decorations until needed

On Tue, Nov 21, 2017 at 03:43:36PM -0800, Phil Hord wrote: > With many thousands of references, a simple `git rev-parse HEAD` may take > more than a second to return because it first loads all the refs into > memory even though it will never use them. The overall goal of lazy-loading seems

[PATCH v2] Teach stash to parse -m/--message like commit does

`git stash push -m foo` uses "foo" as the message for the stash. But `git stash push -m"foo"` does not parse successfully. Similarly `git stash push --message="My stash message"` also fails. The stash documentation doesn't suggest this syntax should work, but gitcli does and my fingers have

Re: git status always modifies index?

On Wed, Nov 22, 2017 at 12:27:20PM -0800, Jonathan Nieder wrote: > Nathan Neulinger wrote[1]: > > > I just got an answer to my stackoverflow question on this, > > apparently it's already implemented: > > > >

RE: Beneficiary

Good Day my name is Mrs Alice Walton I have a Present Package for you contact me Via:alicewaltso...@gmail.com

Re: [PATCH] fix french translation

Thanks! Bye Le mer 22 nov 2017 à 21:17, Jean-Noël AVILA a écrit : On Wednesday, 22 November 2017 18:24:40 CET Louis Bettens wrote: Signed-off-by: Louis Bettens --- po/fr.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: git status always modifies index?

Hi, Nathan Neulinger wrote[1]: > I just got an answer to my stackoverflow question on this, > apparently it's already implemented: > > https://stackoverflow.com/questions/47436939/how-to-run-git-status-without-modifying-git-index-such-as-in-a-prompt-command > > There is a "--no-optional-locks"

Re: [PATCH 1/2] test-lib: add LIBPCRE1 & LIBPCRE2 prerequisites

Hi, Ævar Arnfjörð Bjarmason wrote: > Add LIBPCRE1 and LIBPCRE2 prerequisites which are true when git is > compiled with USE_LIBPCRE1=YesPlease or USE_LIBPCRE2=YesPlease, > respectively. > > The syntax of PCRE1 and PCRE2 isn't the same in all cases (see > pcresyntax(3) and pcre2syntax(3)). If

Re: [PATCH] fix french translation

On Wednesday, 22 November 2017 18:24:40 CET Louis Bettens wrote: > Signed-off-by: Louis Bettens > --- > po/fr.po | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/po/fr.po b/po/fr.po > index 4deae3318..a12a2ae37 100644 > --- a/po/fr.po > +++ b/po/fr.po

Re: [PATCH v5 5/6] rev-list: add list-objects filtering support

Hi, Jeff Hostetler wrote: > Teach rev-list to use the filtering provided by the > traverse_commit_list_filtered() interface to omit > unwanted objects from the result. > > Object filtering is only allowed when one of the "--objects*" > options are used. micronit: the line widths seem to be

Re: [PATCH v3 3/3] worktree: make add dwim

On 11/22, Junio C Hamano wrote: > Thomas Gummerer writes: > > > I didn't consider that, I think you are right, and the flag should > > apply in that case as well. I think at that point we may as well pass > > this flag through to the 'git branch' call, and let users set up

Re: [PATCH v3 00/33] Add directory rename detection to git

On Tue, Nov 21, 2017 at 5:12 PM, Elijah Newren wrote: > On Tue, Nov 21, 2017 at 4:42 PM, Stefan Beller wrote: >> On Tue, Nov 21, 2017 at 12:00 AM, Elijah Newren wrote: >>> This patchset introduces directory rename detection to

Re: Documentation of post-receive hook

On Wed, 2017-11-22 at 10:14 +0900, Junio C Hamano wrote: > Your suggesting to mention that particular message hints at me that > you feel that the users may not necessarily understand that push did > not result in any update of references on the other side when they > see it.  If the message was

Re: [PATCH v3 25/33] merge-recursive: check for file level conflicts then get new name

On Tue, Nov 21, 2017 at 12:00 AM, Elijah Newren wrote: > Before trying to apply directory renames to paths within the given > directories, we want to make sure that there aren't conflicts at the > file level either. If there aren't any, then get the new name from > any

Re: [PATCH v3 22/33] merge-recursive: check for directory level conflicts

> + /* We can assume it's not rename/rename(1to1) because > +* that was case (1), already checked above. So we > +* know that head_ent->new_dir and merge_ent->new_dir > +* are different strings. > +

Re: [PATCH v3 11/33] directory rename detection: testcases exploring possibly suboptimal merges

> +# Note: Both x and y got renamed and it'd be nice to detect both, and we do > +# better with directory rename detection than git did previously, but the > +# simple rule from section 5 prevents me from handling this as optimally as > +# we potentially could. ...previously... > +# Testcase 8e,

Re: [PATCH 2/2] grep: fix segfault under -P + PCRE2 + (*NO_JIT)

On Wed, Nov 22, 2017 at 8:36 AM, Ævar Arnfjörð Bjarmason wrote: > Fix a bug in the compilation of PCRE2 patterns under JIT (the most > common runtime configuration), any pattern with a (*NO_JIT) verb would > segfault. This bug dates back to my 94da9193a6 ("grep: add support for

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

On Wed, Nov 22, 2017 at 12:09 PM, Kaartic Sivaraam wrote: > On Wednesday 22 November 2017 03:07 AM, Eric Sunshine wrote: >> [1]: Excerpt from: >> https://public-inbox.org/git/capig+cttrv2c7jlu1dr4+n8xo+7yq+deiwlda835wbgd6fh...@mail.gmail.com/ >> >> Other information

Re: [PATCH][l10n-fr] list translated to prune in command

Hi, Louis Bettens wrote: > "$ git worktree" when in a french locale shows an incorrect usage > summary. This comes down to this trivial issue in the i18n. Good catch. This comes from v2.7.0-rc3~4^2~7^2~2^2 (l10n: fr v2.7.0 round 1 (2477t), 2015-12-18). For next time, you can send these three

Re: [PATCH v5 00/10] Partial clone part 2: fsck and promisors

On Wed, 22 Nov 2017 14:25:13 +0900 Junio C Hamano wrote: > Jeff Hostetler writes: > > > From: Jeff Hostetler > > > > This is V5 of part 2 of partial clone. This assumes V5 of part 1 > > is already present. V5 includes minor

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

On Wednesday 22 November 2017 10:25 PM, Lars Schneider wrote: On 20 Nov 2017, at 01:11, Junio C Hamano wrote: Kaartic Sivaraam writes: It might be a good thing to keep the notice but I think it would be better to have that error message in a

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

Kaartic: Regarding the actual patch, rather than silencing validate_worktree() (which seems an unfortunate thing to do), isn't it possible simply to do a quick test to see if the worktree directory exists before calling validate_worktree()? If it doesn't exist, then just skip down to the part of

Re: [PATCH v2 4/4] builtin/branch: strip refs/heads/ using skip_prefix

On Wednesday 22 November 2017 07:39 AM, Junio C Hamano wrote: Eric Sunshine writes: On Tue, Nov 21, 2017 at 2:12 PM, Kaartic Sivaraam wrote: On Wednesday 22 November 2017 12:08 AM, Eric Sunshine wrote: The original code unconditionally

Re: [PATCH] defer expensive load_ref_decorations until needed

On Tue, Nov 21, 2017, Junio C Hamano wrote: > Junio C Hamano writes: > > I am not sure if "maybe_" is a good name here, though. If anything, > you are making the semantics of "load_ref_decorations()" to "maybe" > (but I do not suggest renaming that one). >

Re: [PATCH] fix french translation

Also it seems this is the only .po that has this particular quirk: $ grep -c "worktree prune" po/*.po po/bg.po:2 po/ca.po:2 po/de.po:2 po/es.po:2 po/fr.po:3 # outlier po/is.po:0 po/it.po:0 po/ko.po:2 po/pt_PT.po:2 po/ru.po:2 po/sv.po:2 po/vi.po:2 po/zh_CN.po:2 zero lines -> translation

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

On Wed, Nov 22, 2017 at 11:53 AM, Lars Schneider wrote: >> On 17 Nov 2017, at 20:41, Eric Sunshine wrote: >> * emacsclient already prints its own message ("Waiting for Emacs...", >> which runs together with Git's message). Perhaps treat

[PATCH] fix french translation

Signed-off-by: Louis Bettens --- po/fr.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/po/fr.po b/po/fr.po index 4deae3318..a12a2ae37 100644 --- a/po/fr.po +++ b/po/fr.po @@ -14331,7 +14331,7 @@ msgstr "git worktree add [] []" #:

[PATCH][l10n-fr] list translated to prune in command

"$ git worktree" when in a french locale shows an incorrect usage summary. This comes down to this trivial issue in the i18n.

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

On Wednesday 22 November 2017 09:25 AM, Junio C Hamano wrote: Eric Sunshine writes: So, Kaatic's patch is intended to address that oversight (though I haven't examined the implementation closely; I was just trying to understand the reason for the patch). OK, so the

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

On Wednesday 22 November 2017 03:07 AM, Eric Sunshine wrote: On Tue, Nov 21, 2017 at 10:09 AM, Kaartic Sivaraam wrote: The new feature to 'remove' worktree was handy to remove specific worktrees. It didn't cover one particular case of removal. Specifically, if there

Re: Bisect marking new commits incorrectly

On Wednesday 22 November 2017 at 05:21 pm +0100, Christian Couder wrote: > On Wed, Nov 22, 2017 at 3:39 PM, Adam Dinwoodie wrote: > > In trying to do a bisect on the Git repository, I seem to have come > > across surprising behavior where the order in which `git bisect`

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

On Tue, Nov 21, 2017 at 11:55 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> ... >> fixed. >> ... >> fixed the text... >> ... >> I am not fully convinced all descriptions are in recent history, but I >> tend to agree that most are, so probably the

Re: [PATCH v3 0/4] Hash abstraction

On Tue, Nov 21, 2017 at 11:50 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> "brian m. carlson" writes: >> >>> This is a series proposing a basic abstraction for hash functions. >>> >>> The full description of the

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

> On 20 Nov 2017, at 01:11, Junio C Hamano wrote: > > Kaartic Sivaraam writes: > However, it's not clear how much benefit you gain from stashing this away in a static variable. Premature optimization? >>> >>> The variable being

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

> On 17 Nov 2017, at 20:41, Eric Sunshine wrote: > > On Fri, Nov 17, 2017 at 8:51 AM, wrote: > >> + char *term = getenv("TERM"); >> + >> + if (term && strcmp(term, "dumb")) >> +

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

> On 17 Nov 2017, at 19:40, Junio C Hamano wrote: > > lars.schnei...@autodesk.com writes: > >> Junio posted the original version of this patch [1] as response to my RFC >> [2]. >> I took Junio's patch and slightly changed the commit message as well as the >> message printed

Re: [ANNOUNCE] Git Rev News edition 33

> On 22 Nov 2017, at 15:00, Christian Couder wrote: > > Hi everyone, > > The 33rd edition of Git Rev News is now published: > > https://git.github.io/rev_news/2017/11/22/edition-33/ > > Thanks a lot to all the contributors and helpers! > > Enjoy, > Christian,

Re: doc: prefer 'stash push' over 'stash save'

You probably already noticed this was my fault for filtering the patch through Gmail's GUI. I did also push a replacement which hopefully does apply. On Tue, Nov 21, 2017 at 8:39 PM, Junio C Hamano wrote: > Jonathan Nieder writes: > >> Phil Hord wrote: >>

Re: git status always modifies index?

Ah, my bad. I missed this patch... Good luck! -Santiago. signature.asc Description: PGP signature

Re: Bisect marking new commits incorrectly

On Wed, Nov 22, 2017 at 3:39 PM, Adam Dinwoodie wrote: > In trying to do a bisect on the Git repository, I seem to have come > across surprising behavior where the order in which `git bisect` appears > to forget that previous commits were marked as new. Yeah, the algorithm

Re: git status always modifies index?

I just got an answer to my stackoverflow question on this, apparently it's already implemented: https://stackoverflow.com/questions/47436939/how-to-run-git-status-without-modifying-git-index-such-as-in-a-prompt-command There is a "--no-optional-locks" command in 2.15 that looks like it does

Re: git status always modifies index?

On Wed, Nov 22, 2017 at 09:37:09AM -0600, Nathan Neulinger wrote: > What I'm meaning is - why does it need to write the index back out to disk? > > From looking at the code in builtin/commit.c it looks like it takes a lock > on the index, collects the status, and then unconditionally rewrites the

Re: [PATCH v2] doc: Add missing "-n" (dry-run) option to reflog man page

"Robert P. J. Day" writes: > i don't believe "git reflog" supports "-v", only "--verbose", or am > i misreading the source? Ah, then at least you are being (locally) consistent. Sorry for a remembo. As to (global) consistency, in the oldest time we tried to list every

RE: [PATCH 1/2] Documentation about triangular workflow

Daniel Bensoussan writes: >> +TRIANGULAR WORKFLOW >> +--- >> + >> +Introduction >> + >> + >> +In some projects, contributors cannot push directly to the project but >> +have to suggest their commits to the maintainer (e.g. pull

Re: [PATCH 1/1] doc: Mention info/attributes in gitrepository-layout

Steffen Prohaska writes: > Signed-off-by: Steffen Prohaska > --- > Documentation/gitrepository-layout.txt | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/gitrepository-layout.txt > b/Documentation/gitrepository-layout.txt > index

Re: git status always modifies index?

What I'm meaning is - why does it need to write the index back out to disk? From looking at the code in builtin/commit.c it looks like it takes a lock on the index, collects the status, and then unconditionally rewrites the index file. I'm proposing that the update_index_if_able call not

Re: git status always modifies index?

Hi Nathan. Do you mean git-status writing an index file? What would you suggest for git-status to compute which files have changed without modifying an index-file? Or are you suggesting git-status to fail if the index file doesn't belong to the user-id who invoked the command... Thanks,

git status always modifies index?

Current code appears to always attempt an index refresh, which results in file permission changes if you run a 'git status' as a privileged account. Would be nice if there were an option available to ask git status to NOT update the index. Even better would be if it was smart about the

RE: [PATCH 1/2] Documentation about triangular workflow

>On 17 November 2017 at 17:07, Daniel Bensoussan > wrote: >> +- If the maintainer accepts the changes, he merges them into the >> + **UPSTREAM** repository. >Personally, I would prefer "they" and "their" over "he" and "his". I'm >not sure how universal this

  1   2   >