Re: [PATCH v2 9/9] read_loose_refs(): read refs using resolve_ref_recursively()

On 02/10/2017 08:22 PM, Junio C Hamano wrote: > Michael Haggerty writes: >> [...] > > OK, but one thing puzzles me... > >> @@ -1390,27 +1390,6 @@ static struct ref_store *main_ref_store; >> static struct hashmap submodule_ref_stores; >> >> /* >> - * Return the

Re: Git status performance on PS (command prompt)

On Sun, Feb 12, 2017 at 5:46 PM, brian m. carlson wrote: > On Sun, Feb 12, 2017 at 04:53:47PM +0100, Mark Gaiser wrote: [...] >> I did a bit of profiling in git to figure out where this slowdown comes from. >> Callgrind tells me that "read_directory_recursive"

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On 02/10/2017 11:10 AM, Johannes Schindelin wrote: Hi Arif, On Wed, 24 Aug 2016, Johannes Schindelin wrote: I recently adapted an old script I had to apply an entire patch series given the GMane link to its cover letter:

Re: [PATCH v2 0/9] Store submodules in a hash, not a linked list

On Fri, 2017-02-10 at 12:16 +0100, Michael Haggerty wrote: > This is v2 of the patch series, considerably reorganized but not that > different codewise. Thanks to Stefan, Junio, and Peff for their > feedback about v1 [1]. I think I have addressed all of your comments. LGTM.

Incorrect pipe for git log graph when using --name-status option

The `git log` command with `graph` and pretty format works correctly as expected. $ git log --graph --pretty=format:'%h' -2 * 714a14e * 87dce5f However, with `--name-status` option added, there is a pipe incorrectly placed after the commit hash (example below). $ git log --graph

Re: [PATCH 0/5] Store submodules in a hash, not a linked list

On Thu, Feb 09, 2017 at 07:40:33PM -0500, Jeff King wrote: > On Thu, Feb 09, 2017 at 10:23:35PM +0100, Michael Haggerty wrote: > > > >> So push the submodule attribute down to the `files_ref_store` class > > >> (but continue to let the `ref_store`s be looked up by submodule). > > > > > > I'm not

[PATCH] completion: teach to complete git-subtree

From: Cornelius Weig Git-subtree is a contrib-command without completion, making it cumbersome to use. Teach bash completion to complete the subcommands of subtree (add, merge, pull, push, split) and options thereof. For subcommands supporting it (add, push, pull)

Re: [PATCH] fetch: print an error when declining to request an unadvertised object

Matt McCutchen writes: > What do you think? Do you not care about having a more specific error, > in which case I can copy the code from builtin/fetch-pack.c to > fetch_refs_via_pack? Or shall I add code to filter_refs to set a flag > and add code to

Re: [git-gui] Amending doesn't preserve timestamp

On 12/02/2017 22:40, Juraj wrote: > Hi Igor, > > I forgot to write the version I'm using. It's on Ubuntu 16.04, git-gui > package version 1:2.7.4-0ubuntu1 (--version: git-gui version 0.20.0), > git version 2.7.4, tcl and tk 8.6.0+9. Perhaps it got fixed in a newer > version, in that case, my bad

Re: What's cooking in git.git (Feb 2017, #03; Fri, 10)

Am 12.02.2017 um 19:32 schrieb Vegard Nossum: I said I would resubmit the patches with more config options and more command-line arguments (to avoid potentially breaking backwards compatibility), but IIRC the response seemed to be "preceding blank line heuristic is good enough" and "why bother",

Re: [PATCH v4 0/7] stash: support pathspec argument

On 02/12, Thomas Gummerer wrote: > Thanks Peff and Junio for the review of the last round. > Sorry it seems like I messed up the In-Reply-To header. Previous rounds were at: v1: http://public-inbox.org/git/20170121200804.19009-1-t.gumme...@gmail.com/ v2:

[PATCH v4 3/7] stash: add test for the create command line arguments

Currently there is no test showing the expected behaviour of git stash create's command line arguments. Add a test for that to show the current expected behaviour and to make sure future refactorings don't break those expectations. Signed-off-by: Thomas Gummerer ---

[PATCH v4 4/7] stash: introduce new format create

git stash create currently supports a positional argument for adding a message. This is not quite in line with how git commands usually take comments (using a -m flag). Add a new syntax for adding a message to git stash create using a -m flag. This is with the goal of deprecating the old style

[PATCH v4 5/7] stash: teach 'push' (and 'create') to honor pathspec

While working on a repository, it's often helpful to stash the changes of a single or multiple files, and leave others alone. Unfortunately git currently offers no such option. git stash -p can be used to work around this, but it's often impractical when there are a lot of changes over multiple

[PATCH v4 6/7] stash: use stash_push for no verb form

Now that we have stash_push, which accepts pathspec arguments, use it instead of stash_save in git stash without any additional verbs. This does introduce a small regression. Previously we allowed git stash -- -message, with a hyphen in front of the message. However git stash -- message without

[PATCH v4 7/7] stash: allow pathspecs in the no verb form

Now that stash_push is used in the no verb form of stash, allow specifying the command line for this form as well. Always use -- to disambiguate pathspecs from other non-option arguments. Signed-off-by: Thomas Gummerer --- git-stash.sh | 1 + t/t3903-stash.sh | 15

[PATCH v4 0/7] stash: support pathspec argument

Thanks Peff and Junio for the review of the last round. Changes since v3: - Instead of using ${1-...} to check for missing arguments and dying show the usage for stash instead, being more consistent with how the rest of stash behaves - Let push_stash handle the --help argument from

[PATCH v4 2/7] stash: introduce push verb

Introduce a new git stash push verb in addition to git stash save. The push verb is used to transition from the current command line arguments to a more conventional way, in which the message is given as an argument to the -m option. This allows us to have pathspecs at the end of the command

[PATCH v4 1/7] Documentation/stash: remove mention of git reset --hard

Don't mention git reset --hard in the documentation for git stash save. It's an implementation detail that doesn't matter to the end user and thus shouldn't be exposed to them. In addition it's not quite true for git stash -p, and will not be true when a filename argument to limit the stash to a

Re: [git-gui] Amending doesn't preserve timestamp

Hi Igor, I forgot to write the version I'm using. It's on Ubuntu 16.04, git-gui package version 1:2.7.4-0ubuntu1 (--version: git-gui version 0.20.0), git version 2.7.4, tcl and tk 8.6.0+9. Perhaps it got fixed in a newer version, in that case, my bad for not checking before posting. Thanks,

Re: [git-gui] Amending doesn't preserve timestamp

On 12/02/2017 21:50, Juraj wrote: > I've just noticed that amending a commit from git-gui uses the time of > amending as the new timestamp of the commit, whereas git commit > --amend preserves the original timestamp. Maybe the two should work > the same, whatever it is decided to be the standard

Re: [PATCH] fetch: print an error when declining to request an unadvertised object

On Fri, 2017-02-10 at 10:36 -0800, Junio C Hamano wrote: > > > There is this piece of code near the end of builtin/fetch-pack.c: > > [...] > > that happens before the command shows the list of fetched refs, and > this code is prepared to inspect what happend to the requests it (in > response to

[git-gui] Amending doesn't preserve timestamp

I've just noticed that amending a commit from git-gui uses the time of amending as the new timestamp of the commit, whereas git commit --amend preserves the original timestamp. Maybe the two should work the same, whatever it is decided to be the standard behavior. Juraj

Re: [PATCH v3 0/5] stash: support pathspec argument

[+cc Matthieu Moy as author of a patch mentioned below] On 02/06, Jeff King wrote: > On Sun, Feb 05, 2017 at 08:26:37PM +, Thomas Gummerer wrote: > > > Thanks Junio for the review in the previous round. > > > > Changes since v2: > > > > - $IFS should now be supported by using "$@"

Re: [PATCH 1/2 v3] revision.c: args starting with "-" might be a revision

Siddharth Kannan writes: > This "changing the order" gave me the idea to change the flow. I tried to > implement the above steps without touching the function handle_revision_opt. > By > inserting the handle_revision_arg call just before calling >

[PATCH 1/3] handle_revision_opt(): do not update argv[left++] with an unknown arg

In future steps, we will make it possible for a rev or a revision range (i.e. what is understood by handle_revision_arg() helper) to begin with a dash. The setup_revisions() function however currently considers anything that begins with a dash to be: - an option it itself understands and

[PATCH 3/3] setup_revisions(): allow a rev that begins with a dash

Now all the preparatory pieces are in place, it is a matter of handling a truly unknown option _after_ handle_revision_arg() decides that arg is not a rev. Signed-off-by: Junio C Hamano --- We _could_ do without a new variable maybe_opt and instead check if arg begins

[PATCH 0/3] prepare for a rev/range that begins with a dash

It turns out that telling handle_revision_opt() not to molest argv[left++] does not have heavy fallout. Junio C Hamano (3): handle_revision_opt(): do not update argv[left++] with an unknown arg setup_revisions(): swap if/else bodies to make the next step more readable setup_revisions():

[PATCH 2/3] setup_revisions(): swap if/else bodies to make the next step more readable

Swap the condition and bodies of an "if (A) do_A else do_B" in setup_revisions() to "if (!A) do_B else do A", to make the change in the the next step easier to read. No behaviour change is intended in this step. Signed-off-by: Junio C Hamano --- revision.c | 7 +++ 1

Re: What's cooking in git.git (Feb 2017, #03; Fri, 10)

On 11/02/2017 04:12, Junio C Hamano wrote: René Scharfe writes: Am 10.02.2017 um 23:24 schrieb Junio C Hamano: * vn/xdiff-func-context (2017-01-15) 1 commit - xdiff -W: relax end-of-file function detection "git diff -W" has been taught to handle the case where a new

Re: Git status performance on PS (command prompt)

On Sun, Feb 12, 2017 at 04:53:47PM +0100, Mark Gaiser wrote: > Hi, > > I'm using ZSH with some fancy prompt. In that prompt is also a quick > git status overview (some symbols indicating if the branch is up to > date, if there are changes, etc.. > > The commands that are being executed to fetch

Confusing git messages when disk is full.

Hello, I would like to report what I consider a bug in git, I hope I'm doing it the right way. I was trying to run `git pull` in my repository and got the following error: "git pull Your configuration specifies to merge with the ref 'refs/heads/master' from the remote, but no such ref was

Git status performance on PS (command prompt)

Hi, I'm using ZSH with some fancy prompt. In that prompt is also a quick git status overview (some symbols indicating if the branch is up to date, if there are changes, etc.. The commands that are being executed to fetch the information: For the file status: git status --porcelain For the

Re: [PATCH 1/2 v3] revision.c: args starting with "-" might be a revision

On Sat, Feb 11, 2017 at 01:08:09PM -0800, Junio C Hamano wrote: > Siddharth Kannan writes: > > > Um, I am sorry, but I feel that decrementing left, and incrementing it > > again is > > also confusing. > > Yes, but it is no more confusing than your original

Bug in 'git describe' if I have two tags on the same commit.

I didn't get back the latest tag by 'git describe --tags --always' if I have two tags on the same commit. // repository ppa:git-core/ppa (master)⚡ % cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" (master)⚡ % git

Re: [PATCH 2/2 v3] sha1_name: teach get_sha1_1 "-" shorthand for "@{-1}"

Hey Matthieu, On Sun, Feb 12, 2017 at 10:48:56AM +0100, Matthieu Moy wrote: > Siddharth Kannan writes: > > > sha1_name.c | 5 > > t/t4214-log-shorthand.sh | 73 > > > > 2 files changed, 78

Re: [PATCH 2/2 v3] sha1_name: teach get_sha1_1 "-" shorthand for "@{-1}"

Siddharth Kannan writes: > sha1_name.c | 5 > t/t4214-log-shorthand.sh | 73 > > 2 files changed, 78 insertions(+) > create mode 100755 t/t4214-log-shorthand.sh > > diff --git a/sha1_name.c