Re: Using '--help' for aliases

You could also just make the alias a bash function that does git help checkout when you pass the --help flag to the alias.

Re: Small issue with "add untracked" option of 'git add -i'

On Mon, 2017-06-12 at 10:59 -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > After prompting to get the list of desired files, if the user chose > > nothing, the message is shown.  "No untracked files chosen." is > > probably what the code wants to say, I would

Re: [PATCH/FINAL] status: contextually notify user about an initial commit

On Wed, 2017-06-21 at 19:10 -0700, Junio C Hamano wrote: > You can check by downloading what you sent out (I showed you how in > the other thread). > > It seems that there are funny non-breaking spaces in the additional > text below "---" but before the diffstat, but they are not part of > patch

[PATCH/FINAL] Documentation/git-submodule: cleanup

The "add" section for 'git-submodule' is redundant in its description and the short synopsis line. Fix it. Remove the redundant mentioning of the 'repository' argument being mandatory. The text is hard to read because of back-references, so remove those. Replace the word "humanish" by

Re: [PATCH/FINAL] status: contextually notify user about an initial commit

Kaartic Sivaraam writes: > The existing message, "Initial commit", makes sense for the commit template > notifying users that it's their initial commit, but is confusing when > merely checking the status of a fresh repository (or orphan branch) > without having

Re: [PATCH v5 0/8] Improvements to sha1_file

Jonathan Tan writes: > After some more thought, I think I came up with a better solution - > allow sha1_object_info_extended() to take a NULL struct object_info > pointer,... That is an excellent way to tell the machinery "I care about NO details of the object" ;-)

[PATCH v5 5/8] sha1_file: refactor read_object

read_object() and sha1_object_info_extended() both implement mechanisms such as object replacement, retrying the packed store after failing to find the object in the packed store then the loose store, and being able to mark a packed object as bad and then retrying the whole process. Consolidating

[PATCH v5 7/8] sha1_file: do not access pack if unneeded

Currently, regardless of the contents of the "struct object_info" passed to sha1_object_info_extended(), that function always accesses the packfile whenever it returns information about a packed object, since it needs to populate "u.packed". Add the ability to pass NULL, and use NULL-ness of the

[PATCH v5 6/8] sha1_file: improve sha1_object_info_extended

Improve sha1_object_info_extended() by supporting additional flags. This allows has_sha1_file_with_flags() to be modified to use sha1_object_info_extended() in a subsequent patch. Signed-off-by: Jonathan Tan --- cache.h | 4 sha1_file.c | 43

[PATCH v5 4/8] sha1_file: move delta base cache code up

In a subsequent patch, packed_object_info() will be modified to use the delta base cache, so move the relevant code to before packed_object_info(). Signed-off-by: Jonathan Tan --- sha1_file.c | 220 ++-- 1 file

[PATCH v5 3/8] sha1_file: rename LOOKUP_REPLACE_OBJECT

The LOOKUP_REPLACE_OBJECT flag controls whether the lookup_replace_object() function is invoked by sha1_object_info_extended(), read_sha1_file_extended(), and lookup_replace_object_extended(), but it is not immediately clear which functions accept that flag. Therefore restrict this flag to only

[PATCH v5 8/8] sha1_file: refactor has_sha1_file_with_flags

has_sha1_file_with_flags() implements many mechanisms in common with sha1_object_info_extended(). Make has_sha1_file_with_flags() a convenience function for sha1_object_info_extended() instead. Signed-off-by: Jonathan Tan --- builtin/fetch.c | 10 ++

[PATCH v5 2/8] sha1_file: rename LOOKUP_UNKNOWN_OBJECT

The LOOKUP_UNKNOWN_OBJECT flag was introduced in commit 46f0344 ("sha1_file: support reading from a loose object of unknown type", 2015-05-03) in order to support a feature in cat-file subsequently introduced in commit 39e4ae3 ("cat-file: teach cat-file a '--allow-unknown-type' option",

[PATCH v5 1/8] sha1_file: teach packed_object_info about typename

In commit 46f0344 ("sha1_file: support reading from a loose object of unknown type", 2015-05-06), "struct object_info" gained a "typename" field that could represent a type name from a loose object file, whether valid or invalid, as opposed to the existing "typep" which could only represent valid

[PATCH v5 0/8] Improvements to sha1_file

Thanks, Junio. A reply to your comment on patch 7: > ... this "if" statement feels like a maintenance nightmare. The > intent of the guard, I think, is "when the call wants absolutely > nothing but whence", but the implementation of the guard will not > stay true to the intent whenever somebody

Re: Truncating HEAD reflog on branch move

Kyle Meyer writes: > Eh, sorry about that. I haven't dug very deeply, but it seems like the > entry is still in .git/logs/HEAD, while "git reflog" is only showing > they latest entry. s/entry is still/missing entries are still/

Re: [PATCH v3 19/20] repository: enable initialization of submodules

On 06/21, Jonathan Tan wrote: > On Tue, 20 Jun 2017 12:19:50 -0700 > Brandon Williams wrote: > > > Introduce 'repo_submodule_init()' which performs initialization of a > > 'struct repository' as a submodule of another 'struct repository'. > > > > The resulting submodule can

Re: Truncating HEAD reflog on branch move

Junio C Hamano writes: > "brian m. carlson" writes: > >> I get the following on 2.11.0: >> >> 2cbfbd5 HEAD@{0}: >> 2cbfbd5 HEAD@{1}: checkout: moving from cPanel to master >> eaf8db2 HEAD@{2}: checkout: moving from master to cPanel >> 2cbfbd5

Re: [PATCH v3 15/20] repository: add index_state to struct repo

On Wed, Jun 21, 2017 at 3:54 PM, Brandon Williams wrote: > On 06/21, Jonathan Tan wrote: >> On Tue, 20 Jun 2017 12:19:46 -0700 >> Brandon Williams wrote: >> >> > +int repo_read_index(struct repository *repo) >> > +{ >> > + if (!repo->index) >> > +

Re: [PATCH v3 19/20] repository: enable initialization of submodules

On Tue, 20 Jun 2017 12:19:50 -0700 Brandon Williams wrote: > Introduce 'repo_submodule_init()' which performs initialization of a > 'struct repository' as a submodule of another 'struct repository'. > > The resulting submodule can be in one of three states: > > 1. The

Re: [PATCH v3 15/20] repository: add index_state to struct repo

On 06/21, Jonathan Tan wrote: > On Tue, 20 Jun 2017 12:19:46 -0700 > Brandon Williams wrote: > > > +int repo_read_index(struct repository *repo) > > +{ > > + if (!repo->index) > > + repo->index = xcalloc(1, sizeof(struct index_state)); > > sizeof(*repo->index)?

Re: [PATCH v3 15/20] repository: add index_state to struct repo

On Tue, 20 Jun 2017 12:19:46 -0700 Brandon Williams wrote: > +int repo_read_index(struct repository *repo) > +{ > + if (!repo->index) > + repo->index = xcalloc(1, sizeof(struct index_state)); sizeof(*repo->index)? [snip] > + /* Repository's in-memory

Re: [PATCH v3 20/20] ls-files: use repository object

On Tue, 20 Jun 2017 12:19:51 -0700 Brandon Williams wrote: > -static void show_ce_entry(const struct index_state *istate, > - const char *tag, const struct cache_entry *ce) > +static void show_ce(struct repository *repo, struct dir_struct *dir, > +

Re: [showing-off RFC/PATCH 26/26] diff.c: have a "machine parseable" move coloring

On Wed, Jun 21, 2017 at 2:55 PM, Junio C Hamano wrote: > Brandon Williams writes: > >> On 06/19, Stefan Beller wrote: >>> Ævar asked for it, this is how you would do it. >>> (plus documentation, tests, CLI knobs, options) >>> >>> Signed-off-by: Stefan Beller

Re: Monitoring a repository for changes

Eric Wong wrote: > And, yes, email does seem redundant, and > modern header sizes (with DKIM, etc) are gigantic; but > connection lifetime and concurrency is manageable to the server > even if not instantaneous. I should add that any email notification message should be

Re: [PATCHv2 (resend)] Tweak help auto-correct phrasing.

Marc Branchaud writes: > When auto-correct is enabled, an invalid git command prints a warning and > a continuation message, which differs depending on whether or not > help.autoCorrect is positive or negative. > > With help.autoCorrect = 15: > >WARNING: You called a

Re: Monitoring a repository for changes

Ævar Arnfjörð Bjarmason wrote: > On Wed, Jun 21 2017, Eric Wong jotted: > > I've long wanted to do something better to allow others to keep > > public-inbox mirrors up-to-date. Having only 64-128 bytes of > > overhead per userspace per-connection should be totally doable > >

Re: [PATCH 17/26] diff.c: convert show_stats to use emit_diff_symbol

>> case DIFF_SYMBOL_SUBMODULE_PIPETHROUGH: >> emit_line(o, "", "", line, len); >> break; >> + case DIFF_SYMBOL_STATS_SUMMARY_NO_FILES: >> + fprintf(o->file, " 0 files changed\n"); > > Why is this one a fprintf call instead of an emit_line call?

Re: Monitoring a repository for changes

On Wed, Jun 21 2017, Eric Wong jotted: > Ævar Arnfjörð Bjarmason wrote: >> On Wed, Jun 21 2017, Tim Hutt jotted: >> >> > Hi, >> > >> > Currently if you want to monitor a repository for changes there are >> > three options: >> > >> > * Polling - run a script to check for

Re: [showing-off RFC/PATCH 26/26] diff.c: have a "machine parseable" move coloring

Brandon Williams writes: > On 06/19, Stefan Beller wrote: >> Ævar asked for it, this is how you would do it. >> (plus documentation, tests, CLI knobs, options) >> >> Signed-off-by: Stefan Beller >> --- >> diff.c | 15 +++ >> diff.h | 2 ++ >>

Re: [PATCH 04/26] diff.c: introduce emit_diff_symbol

On 06/21, Junio C Hamano wrote: > Brandon Williams writes: > > > I don't think this is strictly enforced. If you look at grep.h:197 the > > enum 'grep_source_type' has a trailing comma. > > OK, so we now know that at least since e1327023 ("grep: refactor the > concept of

Re: [PATCH 04/26] diff.c: introduce emit_diff_symbol

Brandon Williams writes: > I don't think this is strictly enforced. If you look at grep.h:197 the > enum 'grep_source_type' has a trailing comma. OK, so we now know that at least since e1327023 ("grep: refactor the concept of "grep source" into an object", 2012-02-02) we

Re: [PATCH 04/26] diff.c: introduce emit_diff_symbol

On Wed, Jun 21, 2017 at 2:43 PM, Junio C Hamano wrote: > Stefan Beller writes: > I looked through out code base and for enums this is actually strictly enforced, so I guess I have to play by the rules here as I do not want to be the first

Re: [showing-off RFC/PATCH 26/26] diff.c: have a "machine parseable" move coloring

On 06/19, Stefan Beller wrote: > Ævar asked for it, this is how you would do it. > (plus documentation, tests, CLI knobs, options) > > Signed-off-by: Stefan Beller > --- > diff.c | 15 +++ > diff.h | 2 ++ > 2 files changed, 13 insertions(+), 4 deletions(-) > >

Re: Truncating HEAD reflog on branch move

"brian m. carlson" writes: > I get the following on 2.11.0: > > 2cbfbd5 HEAD@{0}: > 2cbfbd5 HEAD@{1}: checkout: moving from cPanel to master > eaf8db2 HEAD@{2}: checkout: moving from master to cPanel > 2cbfbd5 HEAD@{3}: clone: from >

Re: [PATCH 04/26] diff.c: introduce emit_diff_symbol

On 06/21, Stefan Beller wrote: > On Wed, Jun 21, 2017 at 12:36 PM, Junio C Hamano wrote: > > Stefan Beller writes: > > > >> Signed-off-by: Stefan Beller > >> --- > >> diff.c | 22 +++--- > >> 1 file changed, 19

Re: [PATCH 04/26] diff.c: introduce emit_diff_symbol

Stefan Beller writes: >>> I looked through out code base and for enums this is >>> actually strictly enforced, so I guess I have to play >>> by the rules here as I do not want to be the first >>> to deviate from an upheld standard. >> >> You sound like you are trying to find

Truncating HEAD reflog on branch move

In Git 2.11.0, using git branch -m caused an empty entry to be logged to the reflog, but it preserved the previous history of the default (HEAD) reflog. In Git 2.13.1 (and in next and pu), we write a valid entry into the reflog, but truncate it. So for the following commands: git clone

Re: [PATCH v2] die(): stop hiding errors due to overzealous recursion guard

On Wed, Jun 21 2017, Morten Welinder jotted: > If threading is the issue, how do you get meaningful results from > reading and updating > "dying" with no use of atomic types or locks? Other than winning the > implied race, of > course. Threading isn't the issue. The issue is that we have an

Re: [PATCH 17/26] diff.c: convert show_stats to use emit_diff_symbol

On 06/19, Stefan Beller wrote: > We call print_stat_summary from builtin/apply, so we still > need the version with a file pointer, so introduce > print_stat_summary_0 that uses emit_string machinery and > keep print_stat_summary with the same arguments around. > > Signed-off-by: Stefan Beller

Re: [PATCH v2] die(): stop hiding errors due to overzealous recursion guard

Ævar Arnfjörð Bjarmason writes: > So let's just set the recursion limit to a number higher than the > number of threads we're ever likely to spawn. Now we won't lose > errors, and if we have a recursing die handler we'll still die within > microseconds. > > There are race

Re: [PATCH v3 04/20] repository: introduce the repository object

>> I guess we can still refactor later, it's just one >> thing to thing about when introducing an API >> that will likely be used a lot down the road. > > I'm not sure what we want right now, hence why I left it a little more > vague. At this point in time all the relevant callers I can think of

Re: [PATCH v3 04/20] repository: introduce the repository object

On 06/20, Stefan Beller wrote: > On Tue, Jun 20, 2017 at 12:19 PM, Brandon Williams wrote: > > Introduce the repository object 'struct repository' which can be used to > > hold all state pertaining to a git repository. > > > > Some of the benefits of object-ifying a repository

Re: [PATCH 04/26] diff.c: introduce emit_diff_symbol

On Wed, Jun 21, 2017 at 2:13 PM, Junio C Hamano wrote: > Stefan Beller writes: > +enum diff_symbol { + DIFF_SYMBOL_SEPARATOR, >>> >>> Drop the last comma from enum? >> >> I looked through out code base and for enums this is >> actually

Re: [PATCH v2] die(): stop hiding errors due to overzealous recursion guard

If threading is the issue, how do you get meaningful results from reading and updating "dying" with no use of atomic types or locks? Other than winning the implied race, of course. M. On Wed, Jun 21, 2017 at 4:47 PM, Ævar Arnfjörð Bjarmason wrote: > Change the recursion

Re: [PATCH v3 10/20] path: convert do_git_path to take a 'struct repository'

On 06/20, Jonathan Tan wrote: > On Tue, 20 Jun 2017 12:19:41 -0700 > Brandon Williams wrote: > > > +static void do_git_path(const struct repository *repo, > > + const struct worktree *wt, struct strbuf *buf, > > const char *fmt, va_list

Re: Monitoring a repository for changes

Hi, Tim Hutt wrote: > Currently if you want to monitor a repository for changes there are > three options: > > * Polling - run a script to check for updates every 60 seconds. > * Server side hooks > * Web hooks (on Github, Bitbucket etc.) > > Unfortunately for many (most?) cases server-side

Re: [PATCH 04/26] diff.c: introduce emit_diff_symbol

Stefan Beller writes: >>> >>> +enum diff_symbol { >>> + DIFF_SYMBOL_SEPARATOR, >> >> Drop the last comma from enum? > > I looked through out code base and for enums this is > actually strictly enforced, so I guess I have to play > by the rules here as I do not want to be

Re: [PATCH 2/2] add--interactive: quote commentChar regex

Thanks for the quick reaction and fix! On 21/06/17 21:28, Jeff King wrote: > If your chosen comment character is a regex metacharacter, > then that will behave in a confusing manner ("$", for > instance, would only eliminate blank lines, not actual > comment lines). So things would get worse

Re: [PATCH v2] die(): stop hiding errors due to overzealous recursion guard

On Wed, Jun 21, 2017 at 1:47 PM, Ævar Arnfjörð Bjarmason wrote: > Change the recursion limit for the default die routine from a *very* > low 1 to 1024. This ensures that infinite recursions are broken, but > doesn't lose the meaningful error messages under threaded execution >

[PATCH v2] die(): stop hiding errors due to overzealous recursion guard

Change the recursion limit for the default die routine from a *very* low 1 to 1024. This ensures that infinite recursions are broken, but doesn't lose the meaningful error messages under threaded execution where threads concurrently start to die. The intent of the existing code, as explained in

Re: [PATCH 13/26] diff.c: emit_diff_symbol learns about DIFF_SYMBOL_BINARY_FILES

On Wed, Jun 21, 2017 at 1:13 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Signed-off-by: Stefan Beller >> --- >> diff.c | 21 - >> 1 file changed, 16 insertions(+), 5 deletions(-) >> >> diff --git a/diff.c

Re: [PATCH 04/26] diff.c: introduce emit_diff_symbol

Stefan Beller writes: > This will be painful though as the next ~20 patches > add more symbols mostly at the end. > , maybe I need > to restructure that such that the last symbol stays the same > throughout the series. Thanks for that thought. Yes, this mostly-no-op one

Re: [PATCH 24/26] diff.c: add dimming to moved line detection

Stefan Beller writes: > Any lines inside a moved block of code are not interesting. Boundaries > of blocks are only interesting if they are next to another block of moved > code. > > Signed-off-by: Stefan Beller > --- > color.h| 2 +

Re: [PATCH 16/26] diff.c: convert emit_binary_diff_body to use emit_diff_symbol

Stefan Beller writes: > Signed-off-by: Stefan Beller > --- > diff.c | 66 > +- > 1 file changed, 49 insertions(+), 17 deletions(-) > > diff --git a/diff.c b/diff.c > index

Re: [PATCH 13/26] diff.c: emit_diff_symbol learns about DIFF_SYMBOL_BINARY_FILES

Stefan Beller writes: > Signed-off-by: Stefan Beller > --- > diff.c | 21 - > 1 file changed, 16 insertions(+), 5 deletions(-) > > diff --git a/diff.c b/diff.c > index 95f11ea86f..e56962b844 100644 > --- a/diff.c > +++ b/diff.c > @@

Re: [PATCH 11/26] diff.c: emit_diff_symbol learns DIFF_SYMBOL_FILEPAIR

Jonathan Tan writes: > On Mon, 19 Jun 2017 19:48:01 -0700 > Stefan Beller wrote: > >> @@ -676,6 +677,14 @@ static void emit_diff_symbol(struct diff_options *o, >> enum diff_symbol s, >> } >> emit_line(o, context, reset,

Re: [PATCH 08/26] diff.c: migrate emit_line_checked to use emit_diff_symbol

Stefan Beller writes: > static void emit_add_line(const char *reset, > struct emit_callback *ecbdata, > const char *line, int len) > { > - emit_line_checked(reset, ecbdata, line, len, > -

Re: Monitoring a repository for changes

On Wed, Jun 21, 2017 at 12:44 PM, Jeff King wrote: > > Yeah. The naive way to implement this would be to have the client > connect and receive the ref advertisement. And then when it's a noop > (nothing to fetch), instead of saying "I want these objects", say > "Please pause until

Re: Monitoring a repository for changes

Ævar Arnfjörð Bjarmason wrote: > On Wed, Jun 21 2017, Tim Hutt jotted: > > > Hi, > > > > Currently if you want to monitor a repository for changes there are > > three options: > > > > * Polling - run a script to check for updates every 60 seconds. > > * Server side hooks > > *

Re: [PATCH 04/26] diff.c: introduce emit_diff_symbol

On Wed, Jun 21, 2017 at 12:36 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Signed-off-by: Stefan Beller >> --- >> diff.c | 22 +++--- >> 1 file changed, 19 insertions(+), 3 deletions(-) >> >> diff --git

Re: Monitoring a repository for changes

On Wed, Jun 21, 2017 at 05:04:12PM +0200, Ævar Arnfjörð Bjarmason wrote: > > In terms of implementation, the HTTP transport could use Server-Sent > > Events, and the SSH transport can pretty much do whatever so that > > should be easy. > > In case you didn't know, any of the non-trivially sized

Re: [PATCH 04/26] diff.c: introduce emit_diff_symbol

Stefan Beller writes: > Signed-off-by: Stefan Beller > --- > diff.c | 22 +++--- > 1 file changed, 19 insertions(+), 3 deletions(-) > > diff --git a/diff.c b/diff.c > index 2f9722b382..89466018e5 100644 > --- a/diff.c > +++ b/diff.c > @@

Re: [PATCH] docs: update 64-bit core.packedGitLimit default

On Wed, Jun 21, 2017 at 12:22:08PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Of course, the best alternative is retaining access to the packs, which > > is what typically happens now on 64-bit systems (it's just that the > > packedGitLimit was set pointlessly low).

[PATCH 2/2] add--interactive: quote commentChar regex

Since c9d961647 (i18n: add--interactive: mark edit_hunk_manually message for translation, 2016-12-14), when the user asks to edit a hunk manually, we respect core.commentChar in generating the edit instructions. However, when we then strip out comment lines, we use a simple regex like:

[PATCH 1/2] add--interactive: handle EOF in prompt_yesno

The prompt_yesno function loops indefinitely waiting for a "y" or "n" response. But it doesn't handle EOF, meaning that we can end up in an infinite loop of reading EOF from stdin. One way to simulate that is with: echo e | GIT_EDITOR='echo corrupt >' git add -p Let's break out of the loop and

[PATCH 0/2] Re: git add -p does not work with custom comment char currently

On Wed, Jun 21, 2017 at 02:20:21PM -0400, Jeff King wrote: > I can reproduce easily here with the script below. It looks like a > regression in c9d961647 (i18n: add--interactive: mark edit_hunk_manually > message for translation, 2016-12-14), which is in v2.12.0. It taught the > script to write

Re: [PATCH] docs: update 64-bit core.packedGitLimit default

Jeff King writes: > Of course, the best alternative is retaining access to the packs, which > is what typically happens now on 64-bit systems (it's just that the > packedGitLimit was set pointlessly low). I'm not sure if you're asking > in general, or as a last-ditch effort for

Re: [PATCHv3] submodules: overhaul documentation

Stefan Beller writes: > +DESCRIPTION > +--- > + > +A submodule is another Git repository tracked inside a repository. > +The tracked repository has its own history, which does not > +interfere with the history of the current repository. As a naive reader, I have/got

Re: Using '--help' for aliases

On Wed, 2017-06-21 at 14:55 -0400, Jeff King wrote: > It could do that. I think we even discussed it at one point, > but I > didn't dig up the thread. However, you have the problem that running > "man checkout" is likely to clobber the mention of the alias. So the > question is whether it is more

Re: Using '--help' for aliases

On Thu, Jun 22, 2017 at 12:11:29AM +0530, Kaartic Sivaraam wrote: > I am yet another user of 'git alias' (who wouldn't ?). It has become so > natural to me to use the aliased version that at some point of time I > tried the following, > > > $ git co --help > > `git co' is aliased to `checkout' >

Re: [PATCH] docs: update 64-bit core.packedGitLimit default

On Wed, Jun 21, 2017 at 11:38:54AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > So the other direction, instead of avoiding the memory limit in (4), is > > to stop closing "small" packs in (2). But I don't think that's a good > > idea. Even with the code after David's

Re: [PATCH v3 11/20] path: construct correct path to a worktree's index

Jonathan Nieder writes: > Brandon Williams wrote: > >> So your suggestion is to completely avoid doing any location when asking >> for a worktree_git_path, I guess those code paths which request those >> paths should be aware enough that if they need something in commondir to

Re: [PATCH/FINAL] status: contextually notify user about an initial commit

Kaartic Sivaraam writes: > On Wed, 2017-06-21 at 16:52 +0200, Ævar Arnfjörð Bjarmason wrote: >> No, this is a bug in your patch, the test suite should pass under >> poison. >> >> The issue is that you changed the test code I gave you (to also add >> more >>

Re: Does 'git config' accept the '--remove' option?

On Wed, 2017-06-21 at 11:34 -0700, Junio C Hamano wrote: > Neither, I would say.  I think that you would get exactly the same > behaviour from  > > $ git config --remo test > $ git config --remove-sec test > > These are merely "unique prefix can be abbreviated in option names" > kicking

Using '--help' for aliases

Hello all, I am yet another user of 'git alias' (who wouldn't ?). It has become so natural to me to use the aliased version that at some point of time I tried the following, > $ git co --help > `git co' is aliased to `checkout' That made me wonder. Git is able to inform the user that 'co' is

Re: [PATCH] docs: update 64-bit core.packedGitLimit default

Jeff King writes: > So the other direction, instead of avoiding the memory limit in (4), is > to stop closing "small" packs in (2). But I don't think that's a good > idea. Even with the code after David's patch, you can still trigger the > problem by running out of file

Re: Does 'git config' accept the '--remove' option?

Kaartic Sivaraam writes: > I recently noticed that when I run 'git config' with the '--remove > ' I get a warning that section doesn't exist. > When I scrolled through the man page of git-config I could see any > mention about the '--remove' option. I only see

Re: git add -p does not work with custom comment char currently

On Wed, Jun 21, 2017 at 06:31:34PM +0200, Christian Rösch wrote: > [core] > commentchar = $ > > as far as I can see with 2.13.0 and 2.13.1.516.g05ec6e1 (built from > source) if I do > > $ git add -p > > and edit the hunk manually the comment char is not parsed correctly: > > Stage this

Re: [PATCH v4 0/8] Improvements to sha1_file

Jonathan Tan writes: > Thanks, Peff and Junio for your comments. Here's an updated version and > ... > Jonathan Tan (8): > sha1_file: teach packed_object_info about typename > sha1_file: rename LOOKUP_UNKNOWN_OBJECT > sha1_file: rename LOOKUP_REPLACE_OBJECT >

Re: [PATCH] status tests: fix a minor indenting issue

On Wed, 2017-06-21 at 09:34 -0700, Junio C Hamano wrote: > Your patch is heavily whitespace damaged, line-wrapped and > full of (nbsp??) bytes as can be seen by downloading from > > http://public-inbox.org/git/%3c1498048305.1746.6.ca...@gmail.com%3E/r > aw > > I'll hand-tweak to make it apply,

[PATCH/FINAL] status: contextually notify user about an initial commit

The existing message, "Initial commit", makes sense for the commit template notifying users that it's their initial commit, but is confusing when merely checking the status of a fresh repository (or orphan branch) without having any commits yet. Change the output of "status" to say "No commits

Re: [PATCH v4 7/8] sha1_file: do not access pack if unneeded

Jonathan Tan writes: > Add an option to struct object_info to suppress population of additional > information about a packed object if unneeded. This allows an > optimization in which sha1_object_info_extended() does not even need to > access the pack if no information

Does 'git config' accept the '--remove' option?

Hello all, I recently noticed that when I run 'git config' with the '--remove ' I get a warning that section doesn't exist. When I scrolled through the man page of git-config I could see any mention about the '--remove' option. I only see that there is a ' --remove-section' option. Sample

Re: [PATCH] docs: update 64-bit core.packedGitLimit default

On Wed, Jun 21, 2017 at 09:25:09AM -0700, Stefan Beller wrote: > > -Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms. > > +Default is 256 MiB on 32 bit platforms and 32 TiB (effectively > > +unlimited) on 64 bit platforms. > > nit: I would have not written "effectively

Re: [PATCH v4 5/8] sha1_file: refactor read_object

Jonathan Tan writes: > @@ -2914,6 +2912,7 @@ static int sha1_loose_object_info(const unsigned char > *sha1, > git_zstream stream; > char hdr[32]; > struct strbuf hdrbuf = STRBUF_INIT; > + unsigned long size_scratch; > > if

Re: [PATCH v3 11/20] path: construct correct path to a worktree's index

Brandon Williams wrote: > So your suggestion is to completely avoid doing any location when asking > for a worktree_git_path, I guess those code paths which request those > paths should be aware enough that if they need something in commondir to > use git_common_path instead. My only worry is

Re: [PATCH/FINAL] status: contextually notify user about an initial commit

On Wed, 2017-06-21 at 16:52 +0200, Ævar Arnfjörð Bjarmason wrote: > No, this is a bug in your patch, the test suite should pass under > poison. > > The issue is that you changed the test code I gave you (to also add > more > tests, yay) along the way to do: > > test_must_fail test_i18ngrep

Re: [PATCH/FINALRFC] Documentation/git-submodule: cleanup

On Wed, 2017-06-21 at 09:11 -0700, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > Helped-by: Stefan Beller > > Signed-off-by: Kaartic Sivaraam > > --- > >  In case no other changes are required then

[PATCHv3] submodules: overhaul documentation

This patch aims to detangle (a) the usage of `git-submodule` from (b) the concept of submodules and (c) how the actual implementation looks like, such as where they are configured and (d) what the best practices are. To do so, move the conceptual parts of the 'git-submodule' man page to a new man

Re: [PATCH v4 2/8] sha1_file: rename LOOKUP_UNKNOWN_OBJECT

On Wed, 21 Jun 2017 10:22:38 -0700 Junio C Hamano wrote: > Jonathan Tan writes: > > > The LOOKUP_UNKNOWN_OBJECT flag was introduced in commit 46f0344 > > ("sha1_file: support reading from a loose object of unknown type", > > 2015-05-03) in order to

Re: [PATCH v4 3/8] sha1_file: rename LOOKUP_REPLACE_OBJECT

Jonathan Tan writes: > The LOOKUP_REPLACE_OBJECT flag controls whether the > lookup_replace_object() function is invoked by > sha1_object_info_extended(), read_sha1_file_extended(), and > lookup_replace_object_extended(), but it is not immediately clear which >

Re: [PATCHv2] submodules: overhaul documentation

On Tue, Jun 20, 2017 at 8:45 PM, Jonathan Tan wrote: > Thanks, this looks like a good explanation. Some more nits, but > overall I feel like I understand this and have learned something from > it. > > On Tue, Jun 20, 2017 at 3:56 PM, Stefan Beller

Re: [PATCH v4 2/8] sha1_file: rename LOOKUP_UNKNOWN_OBJECT

Jonathan Tan writes: > The LOOKUP_UNKNOWN_OBJECT flag was introduced in commit 46f0344 > ("sha1_file: support reading from a loose object of unknown type", > 2015-05-03) in order to support a feature in cat-file subsequently > introduced in commit 39e4ae3 ("cat-file:

git add -p does not work with custom comment char currently

Hi, my ~/.gitconfig contains [core] commentchar = $ as far as I can see with 2.13.0 and 2.13.1.516.g05ec6e1 (built from source) if I do $ git add -p and edit the hunk manually the comment char is not parsed correctly: Stage this hunk [y,n,q,a,d,/,s,e,?]? e warning: recount: unexpected

Re: [PATCH v3 11/20] path: construct correct path to a worktree's index

On 06/20, Jonathan Nieder wrote: > Hi again, > > Brandon Williams wrote: > > > When working with worktrees the git directory is split into two part, > > the per-worktree gitdir and a commondir which contains things which are > > shared among all worktrees (like the object store). With this

Re: [PATCH] status tests: fix a minor indenting issue

Kaartic Sivaraam writes: > Change the indentation from "\t " to "\t". This indenting issue was > introduced when the test was added in commit > 1d2f393ac9 ("status/commit: show staged submodules regardless of > ignore config", 2014-04-05). > > Helped-by: Ævar

Re: [PATCH/FINALRFC] Documentation/git-submodule: cleanup

Kaartic Sivaraam writes: > Helped-by: Stefan Beller > Signed-off-by: Kaartic Sivaraam > --- >  In case no other changes are required then this is the final version > of the patch. > > >  

Re: Why 10k remotes? Was: Re: [RFC/PATCH 0/5] remote: eliminate remote->{fetch,push}_refspec and lazy parsing of refspecs

On Wed, Jun 21, 2017 at 02:21:19AM +0200, SZEDER Gábor wrote: > Such an all-forks-in-one repo allows me to run e.g. 'git log --all > -p master.. relevant.c' and then search its output for changes in > interesting functions (thankfully function names are included in > hunk headers; alas

Re: [PATCH] docs: update 64-bit core.packedGitLimit default

On Wed, Jun 21, 2017 at 6:51 AM, Jeff King wrote: > On Thu, Apr 20, 2017 at 05:02:55PM -0400, Jeff King wrote: > >> > git-compat-util.h | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> >> This probably needs an update to the core.packedGitLimit section of >>

  1   2   >