Re: [PATCH] git-rebase.txt: update note about directory rename detection and am

On Fri, Dec 7, 2018 at 9:51 AM Johannes Sixt wrote: > > From: Elijah Newren > > In commit 6aba117d5cf7 ("am: avoid directory rename detection when > calling recursive merge machinery", 2018-08-29), the git-rebase manpage > probably should have also been

[PATCH] git-rebase.txt: update note about directory rename detection and am

From: Elijah Newren In commit 6aba117d5cf7 ("am: avoid directory rename detection when calling recursive merge machinery", 2018-08-29), the git-rebase manpage probably should have also been updated to note the stronger incompatibility between git-am and directory rename detectio

Re: [PATCH] config.txt: correct the note about uploadpack.packObjectsHook

Filter is added in [2], it's > added in between the two paragraphs. This makes the "this is non-repo > level config" note incorrectly apply to allowFilter instead of > packObjectsHook. Move allowFilter paragraph down to fix this. Nice catch, and the patch looks obviously correct. Thanks. -Peff

[PATCH] config.txt: correct the note about uploadpack.packObjectsHook

-repo level config" note incorrectly apply to allowFilter instead of packObjectsHook. Move allowFilter paragraph down to fix this. [1] 20b20a22f8 (upload-pack: provide a hook for running pack-objects - 2016-05-18) [2] 10ac85c785 (upload-pack: add object filtering for partial clone -

Re: [PATCH 2/2] git-config.txt: fix 'see: above' note

Hi Taylor, On Wed, 19 Sep 2018 at 19:21, Taylor Blau wrote: > I could take or leave 2/2, since I usually write ", (see: above)", but > I'm not sure if that's grammatically correct or not. Well, I sure ain't no grammar expert too... This is not a patch I feel strongly about, so I'll be happy to

Re: [PATCH 2/2] git-config.txt: fix 'see: above' note

Hi Martin, On Wed, Sep 19, 2018 at 06:38:19PM +0200, Martin Ågren wrote: > Rather than saying "(see: above)", drop the colon. Also drop the comma > before this note. > > Signed-off-by: Martin Ågren Thanks for both of these. I should have at least taken care of 1/2 myself,

[PATCH 2/2] git-config.txt: fix 'see: above' note

Rather than saying "(see: above)", drop the colon. Also drop the comma before this note. Signed-off-by: Martin Ågren --- Documentation/git-config.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-config.txt b/Documentation/git-config

[PATCH v2 2/2] rerere: add note about files with existing conflict markers

-rerere.txt +++ b/Documentation/git-rerere.txt @@ -211,6 +211,12 @@ would conflict the same way as the test merge you resolved earlier. 'git rerere' will be run by 'git rebase' to help you resolve this conflict. +[NOTE] 'git rerere' relies on the conflict markers in the file to +detect the conflict

[PATCH 09/24] unpack-trees: add a note about path invalidation

Signed-off-by: Nguyễn Thái Ngọc Duy --- unpack-trees.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/unpack-trees.c b/unpack-trees.c index f9efee0836..c07a6cd646 100644 --- a/unpack-trees.c +++ b/unpack-trees.c @@ -1552,6 +1552,17 @@ static int verify_uptodate_sparse(const

[PATCH 1/2] doc hash-function-transition: note the lack of a changelog

have been worthy of including in this changelog (but weren't). Instead of amending it to include these, just note that future changes will be noted in the log. Signed-off-by: Ævar Arnfjörð Bjarmason --- Documentation/technical/hash-function-transition.txt | 6 ++ 1 file changed, 6 insertion

Re: [PATCH 03/20] blame doc: explicitly note how --abbrev=40 gives 39 chars

he > abbreviated object name, use +1 digits. Note that 1 column > is used for a caret to mark the boundary commit. This is outside the scope of this patch, but is the above 7+1 still current or do we need updating it for the (not so) recent change to auto-scale the default abbrevi

[PATCH 03/20] blame doc: explicitly note how --abbrev=40 gives 39 chars

mal digits as the abbreviated object name, use +1 digits. Note that 1 column is used for a caret to mark the boundary commit. ++ +Because of this UI design, the only way to get the full SHA-1 of the +boundary commit is to use the `--porcelain` format. With `--abbrev=40` +only 39 characters of the boun

[PATCH v4 02/23] unpack-trees: add a note about path invalidation

Signed-off-by: Nguyễn Thái Ngọc Duy --- unpack-trees.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/unpack-trees.c b/unpack-trees.c index 3a85a02a77..5d06aa9c98 100644 --- a/unpack-trees.c +++ b/unpack-trees.c @@ -1545,6 +1545,17 @@ static int verify_uptodate_sparse(const

[PATCH v3 02/20] unpack-trees: add a note about path invalidation

Signed-off-by: Nguyễn Thái Ngọc Duy --- unpack-trees.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/unpack-trees.c b/unpack-trees.c index 3a85a02a77..5d06aa9c98 100644 --- a/unpack-trees.c +++ b/unpack-trees.c @@ -1545,6 +1545,17 @@ static int verify_uptodate_sparse(const

[PATCH v2 2/5] unpack-trees: add a note about path invalidation

Signed-off-by: Nguyễn Thái Ngọc Duy --- unpack-trees.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/unpack-trees.c b/unpack-trees.c index 3a85a02a77..5d06aa9c98 100644 --- a/unpack-trees.c +++ b/unpack-trees.c @@ -1545,6 +1545,17 @@ static int verify_uptodate_sparse(const

[PATCH 2/6] unpack-trees: add a note about path invalidation

Signed-off-by: Nguyễn Thái Ngọc Duy --- unpack-trees.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/unpack-trees.c b/unpack-trees.c index 3a85a02a77..5d06aa9c98 100644 --- a/unpack-trees.c +++ b/unpack-trees.c @@ -1545,6 +1545,17 @@ static int verify_uptodate_sparse(const

Re: [PATCH] RelNotes: remove duplicate release note

Elijah Newren writes: > In the 2.18 cycle, directory rename detection was merged, then reverted, > then reworked in such a way to fix another prominent bug in addition to > the original problem causing it to be reverted. When the reworked series > was merged, we ended up with two nearly

Re: [PATCH v2 2/2] note git-secur...@googlegroups.com in more places

On 05/30, brian m. carlson wrote: > On Wed, May 30, 2018 at 09:52:55PM +0100, Thomas Gummerer wrote: > > Add a mention of the security mailing list to the README, and to > > Documentation/SubmittingPatches.. 2caa7b8d27 ("git manpage: note > > git-secur...@googlegroups

[PATCH] RelNotes: remove duplicate release note

In the 2.18 cycle, directory rename detection was merged, then reverted, then reworked in such a way to fix another prominent bug in addition to the original problem causing it to be reverted. When the reworked series was merged, we ended up with two nearly duplicate release notes. Remove the

Re: [PATCH v2 2/2] note git-secur...@googlegroups.com in more places

On Wed, May 30, 2018 at 09:52:55PM +0100, Thomas Gummerer wrote: > Add a mention of the security mailing list to the README, and to > Documentation/SubmittingPatches.. 2caa7b8d27 ("git manpage: note > git-secur...@googlegroups.com", 2018-03-08) already added i

[PATCH v2 2/2] note git-secur...@googlegroups.com in more places

Add a mention of the security mailing list to the README, and to Documentation/SubmittingPatches.. 2caa7b8d27 ("git manpage: note git-secur...@googlegroups.com", 2018-03-08) already added it to the man page, but for developers either the README, or the documentation on how to

Re: [PATCH] README: note git-secur...@googlegroups.com

Thomas Gummerer wrote: > Add a mention of the security mailing list to the README. > 2caa7b8d27 ("git manpage: note git-secur...@googlegroups.com", > 2018-03-08) already added it to the man page, but I suspect that for > many developers, such as myself, the README would be t

[PATCH] README: note git-secur...@googlegroups.com

Add a mention of the security mailing list to the README. 2caa7b8d27 ("git manpage: note git-secur...@googlegroups.com", 2018-03-08) already added it to the man page, but I suspect that for many developers, such as myself, the README would be the first place to go looking for it. Us

[PATCH v3 12/15] show-branch: note about its object flags usage

This is another candidate for commit-slab. Keep Junio's observation in code so we can search it later on when somebody wants to improve the code. --- builtin/show-branch.c | 5 + object.h | 1 + 2 files changed, 6 insertions(+) diff --git a/builtin/show-branch.c

[PATCH v3 6/7] doc: add note about shell quoting to revision.txt

16d07 100644 --- a/Documentation/revisions.txt +++ b/Documentation/revisions.txt @@ -7,6 +7,10 @@ syntax. Here are various ways to spell object names. The ones listed near the end of this list name trees and blobs contained in a commit. +NOTE: This document shows the "raw" syntax as seen by git. Th

Re: [PATCH v2 6/6] doc: add note about shell quoting to revision.txt

Am 27.04.2018 um 19:36 schrieb Eric Sunshine: > On Fri, Apr 27, 2018 at 1:04 PM, Andreas Heiduk wrote: >> Signed-off-by: Andreas Heiduk >> Reviewed-by: Junio C Hamano >> --- >> diff --git a/Documentation/revisions.txt

Re: [PATCH v2 6/6] doc: add note about shell quoting to revision.txt

On Fri, Apr 27, 2018 at 1:04 PM, Andreas Heiduk wrote: > Signed-off-by: Andreas Heiduk > Reviewed-by: Junio C Hamano > --- > diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt > @@ -186,6 +190,8 @@ existing tag

[PATCH v2 6/6] doc: add note about shell quoting to revision.txt

40a90 100644 --- a/Documentation/revisions.txt +++ b/Documentation/revisions.txt @@ -7,6 +7,10 @@ syntax. Here are various ways to spell object names. The ones listed near the end of this list name trees and blobs contained in a commit. +NOTE: This document shows the "raw" syntax as seen by git. Th

Re: [PATCH 6/6] doc: add note about shell quoting to revision.txt

dex dfcc49c72c..c1d3a40a90 100644 > --- a/Documentation/revisions.txt > +++ b/Documentation/revisions.txt > @@ -7,6 +7,10 @@ syntax. Here are various ways to spell object names. The > ones listed near the end of this list name trees and > blobs contained in a commit. > > +NOT

[PATCH 6/6] doc: add note about shell quoting to revision.txt

tation/revisions.txt @@ -7,6 +7,10 @@ syntax. Here are various ways to spell object names. The ones listed near the end of this list name trees and blobs contained in a commit. +NOTE: This document shows the "raw" syntax as seen by git. The shell +and other UIs might require additional qu

Re: [PATCH] git manpage: note git-secur...@googlegroups.com

Ævar Arnfjörð Bjarmason writes: > Add a mention of the security mailing list to the "Reporting Bugs" > section. There's a mention of this list at > https://git-scm.com/community but none in git.git itself. This is quite a sensible thing to do. > > The copy is pasted from the

[PATCH] git manpage: note git-secur...@googlegroups.com

Add a mention of the security mailing list to the "Reporting Bugs" section. There's a mention of this list at https://git-scm.com/community but none in git.git itself. The copy is pasted from the git-scm.com website. Let's use the same wording in both places. Signed-off-by: Ævar Arnfjörð

[PATCH/RFC v3 05/12] pack-objects: note about in_pack_header_size

d char in_pack_header_size; /* note: spare bits available! */ unsigned type:TYPE_BITS; unsigned in_pack_type:TYPE_BITS; /* could be delta */ unsigned preferred_base:1; /* -- 2.16.2.873.g32ff258c87

[PATCH/RFC v2 5/9] pack-objects: note about in_pack_header_size

d char in_pack_header_size; /* note: spare bits available! */ unsigned type:TYPE_BITS; unsigned in_pack_type:TYPE_BITS; /* could be delta */ unsigned preferred_base:1; /* -- 2.16.1.435.g8f24da2e1a

[PATCH 05/11] pack-objects: note about in_pack_header_size

d char in_pack_header_size; /* note: spare bits available! */ unsigned type:TYPE_BITS; unsigned in_pack_type:TYPE_BITS; /* could be delta */ unsigned preferred_base:1; /* -- 2.16.1.435.g8f24da2e1a

[PATCH 10/11] t/README: add a note about don't saving stderr of compound commands

needing a Bash version supporting BASH_XTRACEFD, remove the now outdated caution note about non-Bash shells from the description of the '-x' option. Signed-off-by: SZEDER Gábor <szeder@gmail.com> --- t/README | 20 +--- 1 file changed, 17 insertions(+), 3 deletions(-)

Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

On Fri, Feb 09 2018, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >>> Will queue with the above typofix, together with the other one. I >>> am not sure if we want to say "Before 2.17", though. >> >> I'm just keeping in mind the user who later on upgrades git

Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

Ævar Arnfjörð Bjarmason writes: >> Will queue with the above typofix, together with the other one. I >> am not sure if we want to say "Before 2.17", though. > > I'm just keeping in mind the user who later on upgrades git from say > 2.14 to 2.18 or something, and is able to

Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

On Fri, Feb 09 2018, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> +Before 2.17, the untracked cache had a bug where replacing a directory >> +with a symlink to another directory could cause it to incorrectly show >> +files tracked by git as untracked. See

Re: [PATCH 0/2] update-index doc: note new caveats in 2.17

On Fri, Feb 09 2018, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> When users upgrade to 2.17 they're going to have git yelling at them >> (as my users did) on existing checkouts, with no indication whatsoever >> that it's due to the UC or how to fix it. > >

Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

Ævar Arnfjörð Bjarmason writes: > +Before 2.17, the untracked cache had a bug where replacing a directory > +with a symlink to another directory could cause it to incorrectly show > +files tracked by git as untracked. See the "status: add a failing test > +showing a

Re: [PATCH 0/2] update-index doc: note new caveats in 2.17

Ævar Arnfjörð Bjarmason writes: > When users upgrade to 2.17 they're going to have git yelling at them > (as my users did) on existing checkouts, with no indication whatsoever > that it's due to the UC or how to fix it. Wait. Are you saying that the new warning is "warning"

[PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

Document the bug tested for in my "status: add a failing test showing a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir invalidation in untracked code". Since this is very likely something others will encounter in the future on older versions, and it's not obvious how to fix

[PATCH 0/2] update-index doc: note new caveats in 2.17

and new similar ones when a newer iteration of the > feature introduces, no? Fair enough. I just wanted to make sure it had been seen. It wasn't obvious whether it had just been missed since there was no follow-up there or note in WC. We were disagreeing to the extent that some of this shou

[PATCH 2/2] update-index doc: note the caveat with "could not open..."

Note the caveat where 2.17 is stricter about index validation potentially causing "could not open directory" warnings when git is upgraded. See the preceding "dir.c: stop ignoring opendir() error in open_cached_dir()" change. This caused some mayhem when I upgra

[PATCH 4/5] update-index doc: note a fixed bug in the untracked cache

From: Ævar Arnfjörð Bjarmason Document the bug tested for in my "status: add a failing test showing a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir invalidation in untracked code". Since this is very likely something others will encounter in the future on

NOTE

-- Greetings, Can you handle a transaction that involves the transfer of fund valued 15 million Euros into a foreign account. I will give you the full detailed information as soon as I hear from you. Send me the followings if you are willing and ready to work with me. 1)Full Names (2)Occupation

[PATCH v2 4/5] update-index doc: note a fixed bug in the untracked cache

Document the bug tested for in my "status: add a failing test showing a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir invalidation in untracked code". Since this is very likely something others will encounter in the future on older versions, and it's not obvious how to fix

Re: [PATCH 3/1] update-index doc: note a fixed bug in the untracked cache

Ævar Arnfjörð Bjarmason writes: > Document the bug tested for in my "status: add a failing test showing > a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir > invalidation in untracked code". > > Since this is very likely something others will encounter in

[PATCH 3/1] update-index doc: note a fixed bug in the untracked cache

Document the bug tested for in my "status: add a failing test showing a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir invalidation in untracked code". Since this is very likely something others will encounter in the future on older versions, and it's not obvious how to fix

A note from the maintainer

uot;master" and "maint" are never rewound, and "next" usually will not be either. After a feature release is made from "master", however, "next" will be rebuilt from the tip of "master" using the topics that didn't make the cut in the feature release.

Re: [PATCH 3/3] Documentation: revisions: add note about 3dots usages as continuation indications

otation 'r1\...r2' is called symmetric difference > of 'r1' and 'r2' and is defined as > 'r1 r2 --not $(git merge-base --all r1 r2)'. > @@ -285,6 +285,15 @@ is a shorthand for 'HEAD..origin' and asks "What did the > origin do since > I forked from them?" Note t

[PATCH 3/3] Documentation: revisions: add note about 3dots usages as continuation indications

5,6 +285,15 @@ is a shorthand for 'HEAD..origin' and asks "What did the origin do since I forked from them?" Note that '..' would mean 'HEAD..HEAD' which is an empty range that is both reachable and unreachable from HEAD. +However, there are instances where '...' is *not* +equivalent to

Re: A note from the maintainer

or HTML/plain) mails being quietly dropped, and it caused more than just minor frustration. Maybe mention this in your maintainer's note, to help stave off such problems? Ciao, Dscho

A note from the maintainer

t;pu") and is used by the maintainer for his daily work. The two branches "master" and "maint" are never rewound, and "next" usually will not be either. After a feature release is made from "master", however, "next" will be rebuilt from the tip o

A note from the maintainer

t;pu") and is used by the maintainer for his daily work. The two branches "master" and "maint" are never rewound, and "next" usually will not be either. After a feature release is made from "master", however, "next" will be rebuilt from the tip o

NOTE

BCEAO BANK TOGO has agreed to wire USD$ 7,500.000.00,get in touch with me by my private email immediately: (myemailcham...@gmail.com)for more details

A note from the maintainer

t;pu") and is used by the maintainer for his daily work. The two branches "master" and "maint" are never rewound, and "next" usually will not be either. After a feature release is made from "master", however, "next" will be rebuilt from the tip o

A note from the maintainer

t;pu") and is used by the maintainer for his daily work. The two branches "master" and "maint" are never rewound, and "next" usually will not be either. After a feature release is made from "master", however, "next" will be rebuilt from the tip o

[PATCH v6 10/11] run-command: add note about forking and threading

and didn't get around to releasing it before the fork. This leaves the lock in a locked state in the resulting process with no hope of it ever being released. Add a note describing this potential pitfall before the call to 'fork()' so people working in this section of the code know to only use Async

[PATCH v5 10/11] run-command: add note about forking and threading

and didn't get around to releasing it before the fork. This leaves the lock in a locked state in the resulting process with no hope of it ever being released. Add a note describing this potential pitfall before the call to 'fork()' so people working in this section of the code know to only use Async

[PATCH v4 09/10] run-command: add note about forking and threading

and didn't get around to releasing it before the fork. This leaves the lock in a locked state in the resulting process with no hope of it ever being released. Add a note describing this potential pitfall before the call to 'fork()' so people working in this section of the code know to only use Async

[PATCH v3 09/10] run-command: add note about forking and threading

and didn't get around to releasing it before the fork. This leaves the lock in a locked state in the resulting process with no hope of it ever being released. Add a note describing this potential pitfall before the call to 'fork()' so people working in this section of the code know to only use Async

[PATCH v2 6/6] run-command: add note about forking and threading

and didn't get around to releasing it before the fork. This leaves the lock in a locked state in the resulting process with no hope of it ever being released. Add a note describing this potential pitfall before the call to 'fork()' so people working in this section of the code know to only use Async

Re: [PATCH 5/5] run-command: add note about forking and threading

Brandon Williams wrote: > On 04/11, Eric Wong wrote: > > On the other hand, I believe we should make run-command > > vfork-compatible (and Brandon's series is a big (but incomplete) > > step in the (IMHO) right direction); as anything which is > > vfork-safe would also be safe

Re: [PATCH 5/5] run-command: add note about forking and threading

On 04/11, Eric Wong wrote: > Jonathan Nieder wrote: > > Why can't git use e.g. posix_spawn to avoid this? > > posix_spawn does not support chdir, and it seems we run non-git > commands so no using "git -C" for those. This is actually the biggest reason why I didn't go down

Re: [PATCH 5/5] run-command: add note about forking and threading

Eric Wong wrote: > Jonathan Nieder wrote: >> Why can't git use e.g. posix_spawn to avoid this? > > posix_spawn does not support chdir, and it seems we run non-git > commands so no using "git -C" for those. On the other hand, a number of the non-git commands we run are in a

Re: [PATCH 5/5] run-command: add note about forking and threading

Jonathan Nieder <jrnie...@gmail.com> wrote: > Hi, > > Brandon Williams wrote: > > > --- a/run-command.c > > +++ b/run-command.c > > @@ -458,6 +458,14 @@ int start_command(struct child_process *cmd) > > argv_array_pushv(, cmd->argv

Re: [PATCH 5/5] run-command: add note about forking and threading

Hi, Brandon Williams wrote: > --- a/run-command.c > +++ b/run-command.c > @@ -458,6 +458,14 @@ int start_command(struct child_process *cmd) > argv_array_pushv(, cmd->argv); > } > > + /* > + * NOTE: In order to prevent deadlocking

[PATCH 5/5] run-command: add note about forking and threading

mand.c +++ b/run-command.c @@ -458,6 +458,14 @@ int start_command(struct child_process *cmd) argv_array_pushv(, cmd->argv); } + /* + * NOTE: In order to prevent deadlocking when using threads special +* care should be taken with the function calls made i

[PATCH v7 28/28] refs.h: add a note about sorting order of for_each_ref_*

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.h | 4 ++-- t/t1405-main-ref-store.sh | 6 ++ t/t1406-submodule-ref-store.sh | 6 ++ 3 files changed, 14 insertions(+), 2 deletions(-) diff --git a/refs.h b/refs.h index 1a07f9d86f..49e97d7d5f

A note from the maintainer

t;pu") and is used by the maintainer for his daily work. The two branches "master" and "maint" are never rewound, and "next" usually will not be either. After a feature release is made from "master", however, "next" will be rebuilt from the tip o

A note from the maintainer

t;pu") and is used by the maintainer for his daily work. The two branches "master" and "maint" are never rewound, and "next" usually will not be either. After a feature release is made from "master", however, "next" will be rebuilt from the tip o

[PATCH v6 27/27] refs.h: add a note about sorting order of for_each_ref_*

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.h | 4 ++-- t/t1405-main-ref-store.sh | 6 ++ t/t1406-submodule-ref-store.sh | 6 ++ 3 files changed, 14 insertions(+), 2 deletions(-) diff --git a/refs.h b/refs.h index 1a07f9d86f..49e97d7d5f

A note from the maintainer

hat branch contains all topics that are in "next" and a bit more (but not all of "pu") and is used by the maintainer for his daily work. The two branches "master" and "maint" are never rewound, and "next" usually will not be either. After a feature rel

NOTE

I am Mr.Bong Phang, Togo (West Africa) I want to seek your partnership and mutual understanding on a favorable transaction £ 12.5 million, which will benefit both of us. Greetings, Barrister Bong Phang

Re: [PATCH] doc: add note about ignoring --no-create-reflog

Jeff King writes: > On Wed, Feb 01, 2017 at 03:27:09PM -0800, Junio C Hamano wrote: > >> I had the same trouble wording. Another thing I noticed was that I >> deliberately left it vague what "default" this does not override, >> because it appears to me that those who do not set

Re: [PATCH] doc: add note about ignoring --no-create-reflog

is checking is_bare_repository() at runtime. I still think it is OK to mention, as the description of core.logallrefupdates is where we document the behavior and the defaults. So even with "I do not have it set", that is still the key to find more information. I do not care that st

Re: [PATCH] doc: add note about ignoring --no-create-reflog

Jeff King writes: > Should this perhaps say "currently" or "this may change in the future", > so that people (including those who might want to fix it later) know > that it's a limitation and not intentional? Good point. > I'd also probably say it a little shorter, like: > >

Re: [PATCH] doc: add note about ignoring --no-create-reflog

> The negated form `--no-create-reflog` only overrides an earlier > `--create-reflog`, but currently does not negate the setting of > `core.logallrefupdates`. Even better than Junio's version. I especially like that it mentions where the default setting comes from.

Re: [PATCH] doc: add note about ignoring --no-create-reflog

to create a reflog caused by the setting of >> core.logallrefupdates. This corner case is quite important. Glad you thought about it! > -- >8 -- > From: Cornelius Weig <cornelius.w...@tngtech.com> > Date: Wed, 1 Feb 2017 23:07:27 +0100 > Subject: [PATCH] doc: add note about ignoring '

Re: [PATCH] doc: add note about ignoring --no-create-reflog

; based sha1 expressions such as "@\{yesterday}". > Note that in non-bare repositories, reflogs are usually > enabled by default by the `core.logallrefupdates` config option. > + The negated form `--no-create-reflog` does not override the > + def

Re: [PATCH] doc: add note about ignoring --no-create-reflog

them all into one, how about this as an amend? -- >8 -- From: Cornelius Weig <cornelius.w...@tngtech.com> Date: Wed, 1 Feb 2017 23:07:27 +0100 Subject: [PATCH] doc: add note about ignoring '--no-create-reflog' The commands git-branch and git-tag accept the '--create-reflog

Re: [PATCH] doc: add note about ignoring --no-create-reflog

not override the configured (or unconfigured) default. > On the other hand, the negated form `--no-create-reflog` is accepted as > a valid option but has no effect. This silent noop may puzzle users. True, very true. > To communicate that this behavior is intentional, add a short note in >

Re: [PATCH] doc: add note about ignoring --no-create-reflog

hose can go in a separate section, but they're probably more likely to be read when supplied next to the actual option. > With such an update to the log message, I think the patch looks > good. > [...] > > @@ -91,6 +91,7 @@ OPTIONS > > based sha1 expressions such as "@\{yest

[PATCH] doc: add note about ignoring --no-create-reflog

nicate that this behavior is intentional, add a short note in the manuals for git-branch and git-tag. Signed-off-by: Cornelius Weig <cornelius.w...@tngtech.com> --- Notes: In a previous discussion (<xmqqbmunrwbf@gitster.mtv.corp.google.com>) it was found that git-branch and git-tag acc

A note from the maintainer

re currently in flight. Sometimes, an idea that looked promising turns out to be not so good and the topic can be dropped from "pu" in such a case. The output of the above "git log" talks about a "jch" branch, which is an early part of the "pu" branch; tha

Re: [PATCH] Release note spelling and phrasing fixups.

Marc Branchaud writes: > Signed-off-by: Marc Branchaud > --- > > Mostly just missing words and what I feel are clarifications. > > The biggest change is to the "git add -N" item. Not 100% sure > I got it right. > > M. > - * When new

[PATCH] Release note spelling and phrasing fixups.

Signed-off-by: Marc Branchaud --- Mostly just missing words and what I feel are clarifications. The biggest change is to the "git add -N" item. Not 100% sure I got it right. M. Documentation/RelNotes/2.11.0.txt | 145

A note from the maintainer

re currently in flight. Sometimes, an idea that looked promising turns out to be not so good and the topic can be dropped from "pu" in such a case. The output of the above "git log" talks about a "jch" branch, which is an early part of the "pu" branch; that branc

Re: A note from the maintainer

Jakub Narębski writes: > W dniu 03.09.2016 o 04:17, Junio C Hamano pisze: > >> Please remember to always state >> >> - what you wanted to achieve; >> >> - what you did (the version of git and the command sequence to reproduce >>the behavior); > > I wonder if it be worth

Re: A note from the maintainer

W dniu 03.09.2016 o 04:17, Junio C Hamano pisze: > Please remember to always state > > - what you wanted to achieve; > > - what you did (the version of git and the command sequence to reproduce >the behavior); I wonder if it be worth adding to not use aliases (or expand them). I have

A note from the maintainer

topics on this branch aren't usually complete, well tested, or well documented and they often need further work. When a topic that was in "pu" proves to be in a testable shape, it is merged to "next". You can run "git log --first-parent master..pu" to see what to

Re: A note from the maintainer

Philip Oakley wrote: > From: "Eric Wong" > > > >Yes, I was somewhat careful to check for proper mboxes from gmane; > >I just missed entire ranges :x > > > > There were a number of messages that were listed by gmane as being in the > various Git for Windows

Re: A note from the maintainer

From: "Eric Wong" Yes, I was somewhat careful to check for proper mboxes from gmane; I just missed entire ranges :x There were a number of messages that were listed by gmane as being in the various Git for Windows lists such as msysgit, especially when the messages went to

Re: A note from the maintainer

On Sun, Aug 14, 2016 at 02:12:34AM +, Eric Wong wrote: > Eric Wong wrote: > > Thanks, should all be imported. > > Oops, missed one which was missing X-Mailing-List (causing > it to not get imported) and had "X-No-Archive: yes" set; > which meant I couldn't get it from gmane

Re: A note from the maintainer

On Sun, Aug 14, 2016 at 01:27:06AM +, Eric Wong wrote: > What's also interesting about the thread you highlighed is the > extra '<>' when you started that thread; and I have a bug where > I strip off an extra '>' which needs to be fixed... Oh, that's interesting. It's not in the message that

Re: A note from the maintainer

Eric Wong wrote: > Thanks, should all be imported. Oops, missed one which was missing X-Mailing-List (causing it to not get imported) and had "X-No-Archive: yes" set; which meant I couldn't get it from gmane this year. Hmm... XNAY defeats the point of public-inbox (and probably

Re: A note from the maintainer

Jeff King wrote: > I collected the message-ids from my archive. Interestingly, I had a > dozen or so that did not have message-ids at all. I think most of them > are from patches that put the "From " line in the body, like this one: > >

Re: A note from the maintainer

On Sat, Aug 13, 2016 at 09:04:32AM +, Eric Wong wrote: > > Is there an easy way to get _just_ the list of message-ids you are > > storing (I know I can download the whole archive, but it's big)? > > XHDR (or HDR) over NNTP should do it (that's how I checked > against gmane): >

  1   2   3   >