Can I remove multiple stashed states at a time?

I want to remove multiple stashed states at a time. But "git stash drop " removes only one stashed state at a time and "git stash clear" remove all. Can I do that?

[PATCH 3/3] branch: forbid refs/heads/HEAD

strbuf_check_branch_ref() is the central place where many codepaths see if a proposed name is suitable for the name of a branch. It was designed to allow us to get stricter than the check_refname_format() check used for refnames in general, and we already use it to reject a branch whose name

[PATCH 0/3] a small branch API clean-up

This started as a little clean-up for a NEEDSWORK comment in branch.h, but it ended up adding a rather useful safety feature. Junio C Hamano (3): branch: streamline "attr_only" handling in validate_new_branchname() branch: split validate_new_branchname() into two branch: forbid

[PATCH 1/3] branch: streamline "attr_only" handling in validate_new_branchname()

The function takes a parameter "attr_only" (which is a name that is hard to reason about, which will be corrected soon) and skips some checks when it is set. Reorganize the conditionals to make it move obvious that some checks are never made when this parameter is set. Signed-off-by: Junio C

[PATCH 2/3] branch: split validate_new_branchname() into two

Checking if a proposed name is appropriate for a branch is strictly a subset of checking if we want to allow creating or updating a branch with such a name. The mysterious sounding 'attr_only' parameter to validate_new_branchname() is used to switch the function between these two roles. Instead,

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

Jeff King writes: > OK. For the record, I'm not against scrapping this whole thing and > trying to rollback to your "plumbing never looks at color.ui" proposal. > It's quite late in the -rc cycle to do that, but there's nothing that > says we can't bump the release date if that's

Re: [PATCH v5 0/4] Improve abbreviation disambiguation

Derrick Stolee writes: > On 10/12/2017 8:02 AM, Derrick Stolee wrote: >> Changes since previous version: >> >> * Make 'pos' unsigned in get_hex_char_from_oid() >> >> * Check response from open_pack_index() >> >> * Small typos in commit messages >> >> Thanks, >> Stolee >> > I

[PATCH v1 1/1] completion: add remaining flags to checkout

In the commits 1d0fa898 (checkout: add --ignore-other-wortrees, 2015-01-03), 1fc458d9 (builtin/checkout: add --recurse-submodules switch, 2017-03-14), 870ebdb9 (checkout: add --progress option, 2015-11-01), 08d595dc (checkout: add --ignore-skip-worktree-bits in sparse checkout mode, 2013-04-13),

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

On Thu, Oct 12, 2017 at 11:10:06AM +0900, Junio C Hamano wrote: > From: Jeff King > > An earlier patch downgraded "always" that comes via the ui.color > configuration variable to "auto", in order to work around an > unfortunate regression to "git add -i". > > That "fix" however

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

On Thu, Oct 12, 2017 at 03:58:18PM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > > We need to be able to answer "why does '-c color.ui=always' work > > only from the command line?", but I doubt we want to actively > > encourage the use of it, though, so I dunno. >

Re: Is git am supposed to decode MIME?

On 10/04/2017 11:25 AM, Jeff King wrote: On Wed, Oct 04, 2017 at 10:44:31AM +0200, Florian Weimer wrote: The git am documentation talks about “mailboxes”. I suppose these contain messages in Internet Mail syntax. Is git am supposed to decode MIME? I'm asking because I have a message whose

Re: git repack leaks disk space on ENOSPC

On Wed, Oct 11, 2017 at 08:17:03PM -0700, Jonathan Nieder wrote: > I can imagine this behavior of retaining tmp_pack being useful for > debugging in some circumstances, but I agree with you that it is > certainly not a good default. > > Chasing this down, I find: > >

Re: git repack leaks disk space on ENOSPC

On Thu, Oct 12, 2017 at 11:34:39AM +0200, Andreas Krey wrote: > > Does using create_tempfile there seem like a good path forward to you? > > Would you be interested in working on it (either writing a patch with > > such a fix or a test in t/ to make sure it keeps working)? > > I will look into

Re: [PATCH v5 0/4] Improve abbreviation disambiguation

On Thu, Oct 12, 2017 at 09:21:15PM +0900, Junio C Hamano wrote: > Derrick Stolee writes: > > > On 10/12/2017 8:02 AM, Derrick Stolee wrote: > >> Changes since previous version: > >> > >> * Make 'pos' unsigned in get_hex_char_from_oid() > >> > >> * Check response from

Re: [RFC] column: show auto columns when pager is active

On Wed, Oct 11, 2017 at 06:54:04AM +0200, Kevin Daudt wrote: > > > Yeah, I didn't think of that with respect to the pager. This is a > > > regression in v2.14.2, I think. > > > > Yes. > > Though 2.14.2 enabled the pager by default, even before that when > someone would've enabled the pager

Re: [PATCH 07/18] sha1_file: support lazily fetching missing objects

On Fri, Sep 29, 2017 at 10:11 PM, Jonathan Tan wrote: > diff --git a/sha1_file.c b/sha1_file.c > index b4a67bb83..77aa0ffdf 100644 > --- a/sha1_file.c > +++ b/sha1_file.c > @@ -29,6 +29,7 @@ > #include "mergesort.h" > #include "quote.h" > #include "packfile.h" >

Re: Enhancement request: git-push: Allow (configurable) default push-option

Thank you for your coments and explanation. Just one thing: > - After parse_options() returns to cmd_push(), see if push_options >is empty. If it is, you did not get any command line option, so >override it with what you collected in the "from-config" string >list. Otherwise, do

Re: [PATCH 2/2] color: discourage use of ui.color=always

On Thu, Oct 12, 2017 at 11:10:07AM +0900, Junio C Hamano wrote: > Warn when we read such a configuration from a file, and nudge the > users to spell them 'auto' instead. Hmm. On the one hand, it is nice to make people aware that their config isn't doing what they might think. On the other hand,

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

On Thu, Oct 12, 2017 at 09:06:49AM -0400, Jeff King wrote: > > -- >8 -- > > From: Jonathan Nieder > > Subject: color: document that "git -c color.*=always" is a bit special > > Date: Wed, 11 Oct 2017 21:47:24 -0700 > > This looks reasonable to me to ship in v2.15. I assume

Re: [PATCH 07/18] sha1_file: support lazily fetching missing objects

On Thu, Oct 12, 2017 at 4:42 PM, Christian Couder wrote: > > Instead of adding labels and gotos, I would suggest adding a new > function like the following does on top of your changes: Sorry for the usual Gmail related problems. You can find the patch and a further

Re: [RFC PATCH 2/4] change submodule push test to use proper repository setup

On 10/11, Josh Triplett wrote: > On Tue, Oct 10, 2017 at 11:39:21AM -0700, Stefan Beller wrote: > > On Tue, Oct 10, 2017 at 6:03 AM, Heiko Voigt wrote: > > > but in the long run my goal > > > for submodules is and always was: Make them behave as close to files as > > >

Re: Enhancement request: git-push: Allow (configurable) default push-option

Subject: [PATCH] Added support for new configuration parameter push.pushOption builtin/push.c: add push.pushOption config Currently push options need to be given explicitly, via the command line as "git push --push-option". The UX of Git would be enhanced if push options could be configured

Re: [PATCH v1 1/1] completion: add remaining flags to checkout

Am 12.10.2017 um 14:20 schrieb Thomas Braun: In the commits 1d0fa898 (checkout: add --ignore-other-wortrees, 2015-01-03), 1fc458d9 (builtin/checkout: add --recurse-submodules switch, 2017-03-14), 870ebdb9 (checkout: add --progress option, 2015-11-01), 08d595dc (checkout: add

Re: Enhancement request: git-push: Allow (configurable) default push-option

On Thu, Oct 12, 2017 at 9:32 AM, Marius Paliga wrote: > Subject: [PATCH] Added support for new configuration parameter push.pushOption > > builtin/push.c: add push.pushOption config > > Currently push options need to be given explicitly, via > the command line as "git

Re: No log --no-decorate completion?

To be fair, other --no* options complete, it's just --no-decorate, --no-walk, --no-abbrev-commit, --no-expand-tabs, --no-patch, --no-indent-heuristic, and --no-textconv that's missing. For example: $ git log --no --no-color --no-max-parents --no-min-parents --no-prefix --not

(Some?) control codes not escaped when using `git add -p`

Hello list, Running git 2.7.4, I’ve run into an issue where control codes that would normally be escaped when using `git diff` are not similarly escaped when using `git add -p`. As a concrete example, I have a text file including the following "text": :map ^[[H :map ^[[5~ ^B "page up :map

[PATCH v3] pull: pass --signoff/--no-signoff to "git merge"

merge can take --signoff, but without pull passing --signoff down, it is inconvenient, so let's pass it through. The order of options in merge-options.txt is mostly alphabetical by long option since 7c85d274 (Documentation/merge-options.txt: order options in alphabetical groups, 2009-10-22). The

Re: (Some?) control codes not escaped when using `git add -p`

On Thu, Oct 12, 2017 at 12:59:06PM -0500, Mahmoud Al-Qudsi wrote: > Hello list, > > Running git 2.7.4, I’ve run into an issue where control codes that would > normally be escaped when using `git diff` are not similarly escaped when using > `git add -p`. > > As a concrete example, I have a text

Re: [PATCH v2 2/3] for-each-ref: let upstream/push optionally remote ref name

Hi Junio, On Wed, 11 Oct 2017, Junio C Hamano wrote: > Junio C Hamano writes: > > > Johannes Schindelin writes: > > > >> Subject: Re: [PATCH v2 2/3] for-each-ref: let upstream/push optionally > >> remote ref name > > > > No verb?

Out of memory with diff.colormoved enabled

Hi, git version 2.15.0.rc0 (from debian sid package) There is an infinite loop when colormoved is used with --ignore-space-change: git init seq 20 > test git add test sed -i 's/9/42/' test git -c diff.colormoved diff --ignore-space-change -- test - Orgad

Re: Out of memory with diff.colormoved enabled

On Thu, Oct 12, 2017 at 10:53:23PM +0300, Orgad Shaneh wrote: > There is an infinite loop when colormoved is used with --ignore-space-change: > > git init > seq 20 > test > git add test > sed -i 's/9/42/' test > git -c diff.colormoved diff --ignore-space-change -- test Thanks for an easy

undefined reference to `pcre_jit_exec'

Hi Everyone, I have a script to build Git on some old platforms to ease testing. Old platforms include CentOS 5. The script is available at https://github.com/noloader/Build-Scripts/blob/master/build-ssh.sh. It looks like something got knocked loose recently. I'm seeing several of these when

Re: undefined reference to `pcre_jit_exec'

On Thu, Oct 12, 2017 at 04:06:11PM -0400, Jeffrey Walton wrote: > I have a script to build Git on some old platforms to ease testing. > Old platforms include CentOS 5. The script is available at > https://github.com/noloader/Build-Scripts/blob/master/build-ssh.sh. > > It looks like something got

Re: [PATCH v2 1/5] Teach status options around showing ignored files

On 10/11/2017 10:49 PM, Junio C Hamano wrote: Jameson Miller writes: This change teaches the status command more options to control which ignored files are reported independently of the which untracked files are reported by allowing the `--ignored` option to take

Re: [PATCH v2 5/5] Add tests around status handling of ignored arguments

On 10/12/2017 12:06 AM, Junio C Hamano wrote: Jameson Miller writes: Add tests for status handling of '--ignored=matching` and `--untracked-files=normal`. Signed-off-by: Jameson Miller --- Hmph, having some tests in 3/5, changes in 4/5

Re: [PATCH v2 0/5] Teach Status options around showing ignored files

On 10/11/2017 10:33 PM, Junio C Hamano wrote: Jameson Miller writes: Changes in v2: Addressed review comments from the original series: * Made fixes / simplifications suggested for documentation * Removed test_tick from test scripts * Merged 2 commits (as

Re: [PATCH v1 1/1] completion: add remaining flags to checkout

Am 12.10.2017 um 18:50 schrieb Johannes Sixt: Am 12.10.2017 um 14:20 schrieb Thomas Braun: +    --force --ignore-skip-worktree-bits --ignore-other-worktrees Destructive and dangerous options are typically not offered by command completion. You should omit all three in the line above,

Re: undefined reference to `pcre_jit_exec'

On Thu, Oct 12, 2017 at 4:10 PM, Jeff King wrote: > On Thu, Oct 12, 2017 at 04:06:11PM -0400, Jeffrey Walton wrote: > >> I have a script to build Git on some old platforms to ease testing. >> Old platforms include CentOS 5. The script is available at >>

Re: undefined reference to `pcre_jit_exec'

On Thu, Oct 12, 2017 at 04:34:38PM -0400, Jeffrey Walton wrote: > > It looks like autoconf turns on USE_LIBPCRE1, but isn't smart enough to > > test NO_LIBPCRE1_JIT. > > If Git wants Jit, then I am inclined to configure PCRE to provide it. It does make things faster. OTOH, we lived for many

Re: [PATCH v2 2/5] Update documentation for new directory and status logic

On 10/11/2017 10:55 PM, Junio C Hamano wrote: Jameson Miller writes: Signed-off-by: Jameson Miller --- Documentation/git-status.txt | 21 +- Documentation/technical/api-directory-listing.txt | 27

Re: undefined reference to `pcre_jit_exec'

On Thu, Oct 12, 2017 at 4:38 PM, Jeff King wrote: > On Thu, Oct 12, 2017 at 04:34:38PM -0400, Jeffrey Walton wrote: > >> > It looks like autoconf turns on USE_LIBPCRE1, but isn't smart enough to >> > test NO_LIBPCRE1_JIT. >> >> If Git wants Jit, then I am inclined to configure PCRE

Re: undefined reference to `pcre_jit_exec'

On Thu, Oct 12 2017, Jeff King jotted: > On Thu, Oct 12, 2017 at 04:34:38PM -0400, Jeffrey Walton wrote: > >> > It looks like autoconf turns on USE_LIBPCRE1, but isn't smart enough to >> > test NO_LIBPCRE1_JIT. >> >> If Git wants Jit, then I am inclined to configure PCRE to provide it. > > It

My Dear friend,

My Dear, I got your message but i don;t blame you but Note is a pleasure to meet you as a friend and God's sent person i can use to reach the needed poor children around your location and now i have considered you as the person I can use to reach the needed children around your Location since

Re: Out of memory with diff.colormoved enabled

On Thu, Oct 12, 2017 at 1:05 PM, Jeff King wrote: > On Thu, Oct 12, 2017 at 10:53:23PM +0300, Orgad Shaneh wrote: > >> There is an infinite loop when colormoved is used with --ignore-space-change: >> >> git init >> seq 20 > test >> git add test >> sed -i 's/9/42/' test >> git -c

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.2(2)

Hi Steve, On Mon, 9 Oct 2017, Steve Hoelzer wrote: > On Thu, Oct 5, 2017 at 3:22 PM, Lars Schneider > wrote: > > > >> On 05 Oct 2017, at 22:02, Johannes Schindelin > >> wrote: > >> > >> Dear Git users, > >> > >> It is my pleasure to

[ANNOUNCE] Git for Windows 2.14.2(3)

Dear Git users, It is my pleasure to announce that Git for Windows 2.14.2(3) is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.14.2(2) (October 5th 2017) New Features * Comes with Git LFS v2.3.3. Bug Fixes * Re-enabled some SSHv1 ciphers

Re: is there a truly compelling rationale for .git/info/exclude?

Hi Robert, [who I had to cull from the To:/Cc: headers, as my mailer consistently told me that there is no valid DNS record to route mail to rpj...@crashcourse.ca, which *is* weird.] On Fri, 6 Oct 2017, Robert P. J. Day wrote: > On Fri, 6 Oct 2017, Junio C Hamano wrote: > > > Don't waste time

[PATCH] diff.c: increment buffer pointer in all code path

The added test would hang up Git due to an infinite loop. The function `next_byte()` doesn't make any forward progress in the buffer with `--ignore-space-change`. Fix this by only returning early when there was actual white space to be covered, fall back to the default case at the end of the

Re: is there a truly compelling rationale for .git/info/exclude?

On Fri, Oct 13, 2017 at 01:18:00AM +0200, Johannes Schindelin wrote: > [who I had to cull from the To:/Cc: headers, as my mailer consistently > told me that there is no valid DNS record to route mail to > rpj...@crashcourse.ca, which *is* weird.] You are not the only one to mention this, so I

Re: [PATCH 2/2] color: discourage use of ui.color=always

Jeff King writes: > On Thu, Oct 12, 2017 at 11:10:07AM +0900, Junio C Hamano wrote: > >> Warn when we read such a configuration from a file, and nudge the >> users to spell them 'auto' instead. > > Hmm. On the one hand, it is nice to make people aware that their config > isn't

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

Jeff King writes: > ... Also > as an aside, I think this patch means that: > > git -c color.ui=always add -p > > is broken (as would a hypothetical "git --default-color=always add -p"). > That's sufficiently insane that I'm not sure we should care about it. Do you mean that

Re: [PATCH] diff.c: increment buffer pointer in all code path

On Thu, Oct 12, 2017 at 04:33:22PM -0700, Stefan Beller wrote: > Peff, feel free to take ownership here. I merely made it to a patch. I think compared to my original, it makes sense to actually wrap the whole thing with a check for the whitespace. You can do it just in the

Re: [PATCH] diff.c: increment buffer pointer in all code path

On Thu, Oct 12, 2017 at 08:18:37PM -0400, Jeff King wrote: > Fix this by entering the conditional only when we actually > see whitespace. We can apply this also to the > IGNORE_WHITESPACE change. That code path isn't buggy > (because it falls through to returning the next > non-whitespace byte),

Re: [PATCH v2] Documentation/git-config.txt: reword missleading sentence

second.pa...@gmail.com writes: > From: PAYRE NATHAN p1508475 Should I assume that the name/address on the last Signed-off-by: we see below is what you want to be known as? As a part of school work, I'd imagine that Matthieu wants your work to be associated with

Re: [PATCH] diff.c: increment buffer pointer in all code path

On Thu, Oct 12, 2017 at 5:20 PM, Jeff King wrote: > On Thu, Oct 12, 2017 at 08:18:37PM -0400, Jeff King wrote: > >> Fix this by entering the conditional only when we actually >> see whitespace. We can apply this also to the >> IGNORE_WHITESPACE change. That code path isn't buggy >>

Re: [PATCH v2 2/3] for-each-ref: let upstream/push optionally remote ref name

Johannes Schindelin writes: >> (The funny "squash!" followed by a complete version of the >> rewritten commit message is what I do until I -- or anybody else >> -- comes up with a patch to implement support for "reword!".) I have wished for something like that for a

Re: Enhancement request: git-push: Allow (configurable) default push-option

Marius Paliga writes: > Thank you for your coments and explanation. > > Just one thing: > >> - After parse_options() returns to cmd_push(), see if push_options >>is empty. If it is, you did not get any command line option, so >>override it with what you

Re: [PATCH v2 2/5] Update documentation for new directory and status logic

Jameson Miller writes: >>> +If this is set, files and directories that explicity match an ignore >>> +pattern are reported. Implicity ignored directories (directories that >>> +do not match an ignore pattern, but whose contents are all ignored) >>> +are not reported,

Re: [PATCH v2 5/5] Add tests around status handling of ignored arguments

Jameson Miller writes: >> Hmph, having some tests in 3/5, changes in 4/5 and even more tests >> in 5/5 makes me as a reader a bit confused, as the description for >> these two test patches does not make it clear how they are related >> and how they are different. Is

Re: Enhancement request: git-push: Allow (configurable) default push-option

Stefan Beller writes: > Junio, > do we have variables that behave similarly to this? If you scan Documentation/config.txt, you'll find http.extraHeader as an example' but I do not recall offhand if that was the original that introduced the convention, or it merely followed

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

On Fri, Oct 13, 2017 at 09:09:09AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > ... Also > > as an aside, I think this patch means that: > > > > git -c color.ui=always add -p > > > > is broken (as would a hypothetical "git --default-color=always add -p"). > > That's

Re: [PATCH v3] pull: pass --signoff/--no-signoff to "git merge"

"W. Trevor King" writes: > diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt > index 4df6431c34..0ada8c856b 100644 > --- a/Documentation/git-merge.txt > +++ b/Documentation/git-merge.txt > @@ -64,14 +64,6 @@ OPTIONS > --- >

[PATCH v2] pull: pass --signoff/--no-signoff to "git merge"

e379fdf3 (merge: refuse to create too cool a merge by default, 2016-03-18) gave a reason for *not* passing options from pull to merge: ...because such a "two project merge" would be done after fetching the other project into some location in the working tree of an existing project and

Re: git repack leaks disk space on ENOSPC

On Wed, 11 Oct 2017 20:17:03 +, Jonathan Nieder wrote: > Hi Andreas, > > Andreas Krey wrote: > > > I observed (again) an annoying behavior of 'git repack': > > Do you have context for this 'again'? E.g. was this discussed > previously on-list? I think I posted about it, but no discussion.

Re: [PATCH v2 00/24] object_id part 10

"brian m. carlson" writes: > In the course of that, I'll rebase on top of master so that Junio can > avoid as much conflict resolution as possible. I actually do not mind either way, but by rebasing on top of a more recent codebase you can lose a large part of

Re: [PATCH v2 00/24] object_id part 10

On Wed, Oct 11, 2017 at 12:05:50PM +0200, Michael Haggerty wrote: > On 10/09/2017 03:11 AM, brian m. carlson wrote: > > This is the tenth in a series of patches to convert from unsigned char > > [20] to struct object_id. This series mostly involves changes to the > > refs code. After these

[PATCH v2] Documentation/git-config.txt: reword missleading sentence

From: PAYRE NATHAN p1508475 Change the word "bla" to "section.variable", "bla" is a placeholder for a variable name and it wasn't clear for everyone. This change clarify it. Change the appearance of 'git config section.variable {tilde}/' to `git config

Re: [PATCH v2] pull: pass --signoff/--no-signoff to "git merge"

On Thu, Oct 12, 2017 at 01:46:39AM -0700, W. Trevor King wrote: > The order of options in merge-options.txt isn't clear to me, but > I've put --signoff between --log and --stat as somewhat alphabetized > and having an "add to the commit message" function like --log. The order of options in

Re: [PATCH 1/1] git-stash.txt: correct "git stash" behavior with no arguments

小川恭史 writes: > As you point, > > git stash > > without any argument is equivalent to both of > > git stash save > git stash push > > . The original sentence is correct. OK. Note that I was merely reacting to "Correct it." in your justification for the

Re: [PATCH v2 04/24] refs: convert update_ref and refs_update_ref to use struct object_id

On Wed, Oct 11, 2017 at 08:33:46AM +0200, Michael Haggerty wrote: > On 10/09/2017 03:11 AM, brian m. carlson wrote: > > diff --git a/refs.c b/refs.c > > index 0a5b68d6fb..51942df7b3 100644 > > --- a/refs.c > > +++ b/refs.c > > [...] > > @@ -1003,12 +995,12 @@ int refs_update_ref(struct ref_store

Bug or feature: format-patch breaks long subject lines

Hello list, git format-patch breaks (or better: word-wraps) long subject lines. This is on Windows 7 with $ git --version git version 2.14.2.windows.2 Reproduce with (some output omitted): -- $ git init

[PATCH] Documentation/merge-options.txt: Add -S/--gpg-sign

Pull has supported these since ea230d8 (pull: add the --gpg-sign option, 2014-02-10). Insert in long-option alphabetical order following 7c85d274 (Documentation/merge-options.txt: order options in alphabetical groups, 2009-10-22). Signed-off-by: W. Trevor King --- This patch

Re: v2.15.0-rc1 test failure

On Thu, Oct 12, 2017 at 01:27:57AM +0100, Ramsay Jones wrote: > On 11/10/17 23:34, Adam Dinwoodie wrote: > [snip] > > Hi Ramsay, > > > > I assume, given you're emailing me, that this is a Cygwin failure? > > Yes, sorry, I should have made that clear. > > > t0021.15 has PERL as a requirement,

Re: [PATCH v2] pull: pass --signoff/--no-signoff to "git merge"

"W. Trevor King" writes: > e379fdf3 (merge: refuse to create too cool a merge by default, > 2016-03-18) gave a reason for *not* passing options from pull to > merge: > > ...because such a "two project merge" would be done after fetching > the other project into some

Re: Bug or feature: format-patch breaks long subject lines

writes: > Is this the expected behaviour? Yes, it is expected. Your are seeing the header folding in play. "mailinfo" (hence "am") will grok it just fine, I think.

[PATCH v5 3/4] sha1_name: parse less while finding common prefix

Create get_hex_char_from_oid() to parse oids one hex character at a time. This prevents unnecessary copying of hex characters in extend_abbrev_len() when finding the length of a common prefix. Signed-off-by: Derrick Stolee --- sha1_name.c | 14 -- 1 file

[PATCH v5 1/4] p4211-line-log.sh: add log --online --raw --parents perf test

Add a new perf test for testing the performance of log while computing OID abbreviations. Using --oneline --raw and --parents options maximizes the number of OIDs to abbreviate while still spending some time computing diffs. Signed-off-by: Derrick Stolee ---

[PATCH v5 2/4] sha1_name: unroll len loop in find_unique_abbrev_r

Unroll the while loop inside find_unique_abbrev_r to avoid iterating through all loose objects and packfiles multiple times when the short name is longer than the predicted length. Instead, inspect each object that collides with the estimated abbreviation to find the longest common prefix. The

[PATCH v5 4/4] sha1_name: minimize OID comparisons during disambiguation

Minimize OID comparisons during disambiguation of packfile OIDs. Teach git to use binary search with the full OID to find the object's position (or insertion position, if not present) in the pack-index. The object before and immediately after (or the one at the insertion position) give the

RE: Kontaktieren Sie meine E-Mail (wang.jian...@yandex.com)

Ich beabsichtige, Ihnen einen Teil meines Vermögens als freiwillige finanzielle Spende an Sie zu geben. Reagieren Sie auf partake.contact meine E-Mail (wang.jian...@yandex.com) Wang Jianlin Wanda Gruppe

[PATCH v5 0/4] Improve abbreviation disambiguation

Changes since previous version: * Make 'pos' unsigned in get_hex_char_from_oid() * Check response from open_pack_index() * Small typos in commit messages Thanks, Stolee --- When displaying object ids, we frequently want to see an abbreviation for easier typing. That abbreviation must be

Re: [PATCH] pull: pass --signoff/--no-signoff to "git merge"

Junio C Hamano writes: > get_signoff () { > git cat-file commit "$1" | sed -n -e '/^Signed-off-by: /p' > } > > Some may say "cat-file can fail, and having it on the LHS of a pipe > hides its failure", advocating for something like: > >

Re: [PATCH] Documentation/merge-options.txt: Add -S/--gpg-sign

On Thu, Oct 12, 2017 at 12:44:59PM +0200, Kevin Daudt wrote: > On Thu, Oct 12, 2017 at 02:02:17AM -0700, W. Trevor King wrote: > > Pull has supported these since ea230d8 (pull: add the --gpg-sign > > option, 2014-02-10). Insert in long-option alphabetical order > > following 7c85d274

Re: git repack leaks disk space on ENOSPC

On Thu, Oct 12, 2017 at 11:34:39AM +0200, Andreas Krey wrote: > On Wed, 11 Oct 2017 20:17:03 +, Jonathan Nieder wrote: > > Does using create_tempfile there seem like a good path forward to you? > > Would you be interested in working on it (either writing a patch with > > such a fix or a test

Re: [RFC] deprecate git stash save?

Junio C Hamano writes: > Thomas Gummerer writes: > >> git stash push is the newer interface for creating a stash. While we >> are still keeping git stash save around for the time being, it's better >> to point new users of git stash to the more modern

Re: [PATCH v2 00/24] object_id part 10

On Thu, Oct 12, 2017 at 06:58:49PM +0900, Junio C Hamano wrote: > "brian m. carlson" writes: > > > In the course of that, I'll rebase on top of master so that Junio can > > avoid as much conflict resolution as possible. > > I actually do not mind either way, but by

Re: [PATCH] Documentation/merge-options.txt: Add -S/--gpg-sign

On Thu, Oct 12, 2017 at 02:02:17AM -0700, W. Trevor King wrote: > Pull has supported these since ea230d8 (pull: add the --gpg-sign > option, 2014-02-10). Insert in long-option alphabetical order > following 7c85d274 (Documentation/merge-options.txt: order options in > alphabetical groups,

Re: [PATCH] Documentation/merge-options.txt: Add -S/--gpg-sign

Kevin Daudt writes: >> > --S[]:: >> > ---gpg-sign[=]:: >> >> Shouldn't the options self be removed here too, not just the >> explanation? > > You can ignore this, it was just my mail client that colored the diff > wrong, confusing me. > >> > - GPG-sign the resulting merge

Re: [PATCH] Documentation/merge-options.txt: Add -S/--gpg-sign

Makes sense. Will queue.

Re: Branch switching with submodules where the submodule replaces a folder aborts unexpectedly

> Stefan Beller hat am 9. Oktober 2017 um 23:59 > geschrieben: > > > On Mon, Oct 9, 2017 at 2:29 PM, Thomas Braun > wrote: > > Hi, > > > > I'm currently in the progress of pulling some subprojects in a git > > repository of mine into

Re: [PATCH v5 0/4] Improve abbreviation disambiguation

On 10/12/2017 8:02 AM, Derrick Stolee wrote: Changes since previous version: * Make 'pos' unsigned in get_hex_char_from_oid() * Check response from open_pack_index() * Small typos in commit messages Thanks, Stolee I forgot to mention that I rebased on master this morning to be sure this

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

Jonathan Nieder writes: > Junio C Hamano wrote: >> Jonathan Nieder writes: > >>> Should we document this special case treatment of color.* in -c >>> somewhere? E.g. >> >> Perhaps, although I'd save that until we actually add the new option >> to "git"

Re: [PATCH] pull: pass --signoff/--no-signoff to "git merge"

On Thu, Oct 12, 2017 at 02:42:30PM +0900, Junio C Hamano wrote: > "W. Trevor King" writes: > > On Thu, Oct 12, 2017 at 10:17:51AM +0900, Junio C Hamano wrote: > >> "W. Trevor King" writes: > >> > >> > Following 09c2cb87 (pull: pass --allow-unrelated-histories

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

Junio C Hamano writes: > We need to be able to answer "why does '-c color.ui=always' work > only from the command line?", but I doubt we want to actively > encourage the use of it, though, so I dunno. For today's pushout, I've queued this as [PATCH 3/2] Thanks.. -- >8 --

Re: [PATCH] doc: emphasize stash "--keep-index" stashes staged content

On Wed, 11 Oct 2017, Jonathan Nieder wrote: > Hi, > > Robert P. J. Day wrote: > > > It's not immediately obvious from the man page that the "--keep-index" > > option still adds the staged content to the stash, so make that > > abundantly clear. > > > > Signed-off-by: Robert P. J. Day