Re: [PATCH v10 5/5] help: respect new common command grouping

On Thu, May 21, 2015 at 9:13 AM, Sébastien Guimmara wrote: > 'git help' shows common commands in alphabetical order: > [...] > without any indication of how commands relate to high-level > concepts or each other. Revise the output to explain their relationship > with the typical Git workflow: > [.

Re: [PATCH v10 1/5] command-list: prepare machinery for upcoming "common groups" section

On Thu, May 21, 2015 at 9:55 AM, Sébastien Guimmara wrote: > On 05/21/2015 03:48 PM, Eric Sunshine wrote: >> On Thu, May 21, 2015 at 9:13 AM, Sébastien Guimmara >> wrote: >>> The ultimate goal is for "git help" to classify common commands by >>> group. Toward this end, a subsequent patch will add

Re: [PATCH v10 1/5] command-list: prepare machinery for upcoming "common groups" section

On 05/21/2015 03:48 PM, Eric Sunshine wrote: On Thu, May 21, 2015 at 9:13 AM, Sébastien Guimmara wrote: From: Eric Sunshine The ultimate goal is for "git help" to classify common commands by group. Toward this end, a subsequent patch will add a new "common groups" section to command-list.tx

Re: Troubleshoot clone issue to NFS.

On Thu, May 21, 2015 at 3:13 PM, wrote: [...] > So the questions are: > > 1) Should I expect a clone to NFS to be that much slower? > 2) Is there anything I could do to speed it up (I've tried --bare as that is > what the repositories will be when stored on NFS and there wasn't really a > dif

Re: [PATCH v10 1/5] command-list: prepare machinery for upcoming "common groups" section

On Thu, May 21, 2015 at 9:13 AM, Sébastien Guimmara wrote: > From: Eric Sunshine > > The ultimate goal is for "git help" to classify common commands by > group. Toward this end, a subsequent patch will add a new "common > groups" section to command-list.txt preceding the actual command list. > As

Troubleshoot clone issue to NFS.

In setting up some new git servers I was trying to test the performance of some NFS mounted volumes and when compared to local disk (although this is a vitualized server so not truly local) cloning to NFS was taking a long time. Here are some timings: ~ $ time bin/git clone https://github.com/g

RE: recovering from "unordered stage entries in index" error

> This message can be improved to show what entries have this problem. Yes, that would definitely be a start. :) > But then I don't see any way to recover the index manually. ls-files > will die too. Perhaps we should be gentle in this case: show warnings Actually, ls-files succ

[PATCH v10 5/5] help: respect new common command grouping

'git help' shows common commands in alphabetical order: The most commonly used git commands are: addAdd file contents to the index bisect Find by binary search the change that introduced a bug branch List, create, or delete branches checkout Checkout a branch or paths

[PATCH v10 2/5] command-list.txt: add the common groups block

The ultimate goal is for "git help" to display common commands in groups rather than alphabetically. As a first step, define the groups in a new block, and then assign a group to each common command. Add a block at the beginning of command-list.txt: init start a working area (see also

[PATCH v10 4/5] command-list.txt: drop the "common" tag

command-list.sh, retired in the previous patch, was the only consumer of the "common" tag, so drop this now-unnecessary attribute. before: git-add mainporcelaincommon worktree after: git-add mainporcelainworktree Helped-by: Eric Sunshine Signed-off-by:

[PATCH v10 0/5] group common commands by theme

Same as v9 [1], with: * command-list.txt: reduce verbosity by squashing the two header lines into one: ### command list (do not change this line) * include a missing update to new-command.txt. [1] http://thread.gmane.org/gmane.comp.version-control.git/269496 Eric Sunshine (2): command

[PATCH v10 1/5] command-list: prepare machinery for upcoming "common groups" section

From: Eric Sunshine The ultimate goal is for "git help" to classify common commands by group. Toward this end, a subsequent patch will add a new "common groups" section to command-list.txt preceding the actual command list. As preparation, teach existing command-list.txt parsing machinery, which

[PATCH v10 3/5] generate-cmdlist: parse common group commands

From: Eric Sunshine Parse the group block to create the array of group descriptions: static char *common_cmd_groups[] = { N_("starting a working area"), N_("working on the current change"), N_("working with others"), N_("examining the history and state"), N_("growing, marking

Re: [PATCH] submodule documentation: Reorder introductory paragraphs

On Wed, May 20, 2015 at 04:11:57PM -0700, Stefan Beller wrote: > It's better to start the man page with a description of what submodules > actually are instead of saying what they are not. > > Reorder the paragraphs such that > the first short paragraph introduces the submodule concept, > the seco

Re: Diffing submodule does not yield complete logs for merge commits

On Tue, May 19, 2015 at 02:29:55PM -0500, Robert Dailey wrote: > On Tue, May 19, 2015 at 5:44 AM, Heiko Voigt wrote: > > On Mon, May 18, 2015 at 10:06:32AM -0500, Robert Dailey wrote: > >> Unfortunately I find it unintuitive and counter productive to perform > >> inline patches or do anything on a

Issue when merging a subtree whose a file has been removed

Hi all, I want to use subtrees in one of my projects and I use method desribed here https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging I`m facing issues when merging subtree in my subproject in case some files have been removed from the subtree. I`m running git 1.9.1 on Kubuntu 14.04

[PATCH v3] pull: handle --log=

On Mon, May 18, 2015 at 10:53 PM, Johannes Schindelin wrote: > On 2015-05-18 15:39, Paul Tan wrote: >> diff --git a/t/t5524-pull-msg.sh b/t/t5524-pull-msg.sh >> index 8cccecc..eebb8c9 100755 >> --- a/t/t5524-pull-msg.sh >> +++ b/t/t5524-pull-msg.sh >> @@ -17,6 +17,9 @@ test_expect_success setup '

Re: [PATCH 10/14] pull: set reflog message

On Tue, May 19, 2015 at 5:53 AM, Junio C Hamano wrote: > Yeah, either that, or "insert separator only before adding to > something else" pattern, i.e. > > for (i = 0; i < argc; i++) { > if (i) > addch(&msg, ' '); > addstr(&msg, argv[i

Re: [PATCH v6 2/2] mergetools: add winmerge as a builtin tool

Hi Junio, On 2015-05-20 23:00, Junio C Hamano wrote: > Sebastian Schuberth writes: > >> On Wed, May 20, 2015 at 10:13 PM, Junio C Hamano wrote: >> >>> David Aguilar writes: >>> + for directory in $(env | grep -Ei '^PROGRAM(FILES(\(X86\))?|W6432)=' | + cut -d '='

Re: recovering from "unordered stage entries in index" error

On Tue, May 19, 2015 at 8:48 PM, McHenry, Matt wrote: > > > I've just upgraded my git from 2.0.5 to 2.3.6, and I'm now unable to > run 'git svn fetch' in one of my repositories: > > $ git svn fetch > fatal: unordered stage entries in index This message can be improved to show what entrie

Re: [PATCH 06/14] pull: support pull.ff config

Hi, On Tue, May 19, 2015 at 3:02 AM, Johannes Schindelin wrote: > Hi Paul, > > On 2015-05-18 17:06, Paul Tan wrote: > >> diff --git a/builtin/pull.c b/builtin/pull.c >> index 8982fdf..b305a47 100644 >> --- a/builtin/pull.c >> +++ b/builtin/pull.c >> @@ -209,6 +209,28 @@ static void argv_push_forc

Re: [PATCH 02/14] pull: pass verbosity, --progress flags to fetch and merge

Hi, On Tue, May 19, 2015 at 1:41 AM, Johannes Schindelin wrote: > On 2015-05-18 17:05, Paul Tan wrote: >> diff --git a/builtin/pull.c b/builtin/pull.c >> index 0b771b9..a4d9c92 100644 >> --- a/builtin/pull.c >> +++ b/builtin/pull.c >> @@ -11,16 +11,64 @@ >> #include "argv-array.h" >> #include "

Re: [PATCH v4 6/8] t5520: test --rebase failure on unborn branch with index

Hi, On Tue, May 19, 2015 at 2:00 AM, Stefan Beller wrote: > On Mon, May 18, 2015 at 6:32 AM, Paul Tan wrote: >> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh >> index f991439..4d649a5 100755 >> --- a/t/t5520-pull.sh >> +++ b/t/t5520-pull.sh >> @@ -413,6 +413,21 @@ test_expect_success 'pull --re

Re: [PATCH 2/4] ref-filter: add ref-filter API

Karthik Nayak writes: > +static int match_name_as_path(const char **pattern, const char *refname) I would have appreciated a short docstring. The full doc would probably be as long as the code, but a few examples of what matches and what doesn't can help the reader. > +static struct ref_filter_

Re: [PATCH 2/2] pull: use git-rev-parse --parseopt for option parsing

Hi, On Mon, May 18, 2015 at 10:43 PM, Johannes Schindelin wrote: > On 2015-05-18 15:54, Paul Tan wrote: > >> diff --git a/git-pull.sh b/git-pull.sh >> index 633c385..67f825c 100755 >> --- a/git-pull.sh >> +++ b/git-pull.sh >> @@ -4,13 +4,53 @@ >> # >> # Fetch one or more remote refs and merge i

Re: [PATCH 1/2] pull: handle git-fetch's options as well

Hi, On Mon, May 18, 2015 at 10:37 PM, Johannes Schindelin wrote: > On 2015-05-18 15:30, Paul Tan wrote: >> t5520: failing test for pull --all with no configured upstream >> t5521: test pull --all --dry-run does not make any changes >> >> error_on_no_merge_candidates() does not consider the case w

Re: [PATCH 1/2] pull: handle git-fetch's options as well

Hi, On Mon, May 18, 2015 at 10:37 PM, Johannes Schindelin wrote: > On 2015-05-18 15:30, Paul Tan wrote: >> t5520: failing test for pull --all with no configured upstream >> t5521: test pull --all --dry-run does not make any changes >> >> error_on_no_merge_candidates() does not consider the case w

Re: [PATCH v4 3/8] t5520: test for failure if index has unresolved entries

Hi, On Mon, May 18, 2015 at 11:13 PM, Johannes Schindelin wrote: > Hi Paul, > > On 2015-05-18 15:32, Paul Tan wrote: > >> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh >> index 4a2c0a1..3bc0594 100755 >> --- a/t/t5520-pull.sh >> +++ b/t/t5520-pull.sh >> @@ -164,6 +164,26 @@ test_expect_success '

Re: [PUB]corrupt repos does not return error with `git fsck`

Faheem Mitha writes: > I was going by the answer (by CodeWizard) in > http://stackoverflow.com/q/30348615/350713 OK, so the hash you got comes from a superproject which references it. My guess is that the superproject did a private commit in a submodule, added this submodule to the superproject,

Re: [PATCH v4 8/8] t5520: check reflog action in fast-forward merge

Hi, On Mon, May 18, 2015 at 11:20 PM, Johannes Schindelin wrote: > Hi Paul, > > On 2015-05-18 15:32, Paul Tan wrote: > >> @@ -95,7 +94,11 @@ test_expect_success 'test . as a remote' ' >> git checkout copy && >> test "$(cat file)" = file && >> git pull && >> - test "$(cat fil

[PATCH] doc: fix inconsistent spelling of "packfile"

Fix remaining instances where "pack-file" is used instead of "packfile". Signed-off-by: Patrick Steinhardt --- This patch now also fixes instances where we refer to EBNF-style command line parameters, as discussed by Junio and Peff. Documentation/git-index-pack.txt | 10 +- Doc

Re: identical hashes on two branches, but holes in git log

On Tue, May 19, 2015 at 03:12:31PM -0700, Junio C Hamano wrote: > Philippe De Muyter writes: > > > On Tue, May 19, 2015 at 09:01:10AM -0700, Junio C Hamano wrote: > >> Philippe De Muyter writes: > >> > >> > Trying to understand, I have eventually done "git log" on my branch and > >> > on v3.15

Re: identical hashes on two branches, but holes in git log

On Wed, May 20, 2015 at 12:18:15PM -0400, Jeff King wrote: > On Wed, May 20, 2015 at 04:12:38PM +0200, Philippe De Muyter wrote: > > > After reading the man page of 'git log', should --topo-order not be the > > default log order ? > > The problem with --topo-order is that it has to traverse all o

<    1   2