Re: [PATCH 3/3] t/t7106-reset-unborn-branch.sh: Add PERL prerequisite

[Junio C Hamano]

Jonathan Nieder  writes:

> Kacper Kornet wrote:
>
>> Signed-off-by: Kacper Kornet 
>
> Thanks.
>
> Reviewed-by: Jonathan Nieder 
>
> Here's a style cleanup on top.
>
> -- >8 --
> Subject: reset test: modernize style
>
> Avoid command substitution and pipes to ensure that the exit status
> from each git command is tested (and in particular that any segfaults
> are caught).

Makes sense.

The change to the one that feeds 'y' to "reset -p" may be a bit too
pedantic, as we are not in the business of testing "echo y", though.

> Maintain the test setup (no commits, one file named "a", another named
> "b") even after the last test, to make it easier to rearrange tests or
> add new tests after the last in the future.
>
> Signed-off-by: Jonathan Nieder 
> ---
>  t/t7106-reset-unborn-branch.sh | 31 ---
>  1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/t/t7106-reset-unborn-branch.sh b/t/t7106-reset-unborn-branch.sh
> index 499cd88c..af00ab4d 100755
> --- a/t/t7106-reset-unborn-branch.sh
> +++ b/t/t7106-reset-unborn-branch.sh
> @@ -11,7 +11,10 @@ test_expect_success 'setup' '
>  test_expect_success 'reset' '
>   git add a b &&
>   git reset &&
> - test "$(git ls-files)" = ""
> +
> + >expect &&
> + git ls-files >actual &&
> + test_cmp expect actual
>  '
>  
>  test_expect_success 'reset HEAD' '
> @@ -24,28 +27,42 @@ test_expect_success 'reset $file' '
>   rm .git/index &&
>   git add a b &&
>   git reset a &&
> - test "$(git ls-files)" = "b"
> +
> + echo b >expect &&
> + git ls-files >actual &&
> + test_cmp expect actual
>  '
>  
>  test_expect_success PERL 'reset -p' '
>   rm .git/index &&
>   git add a &&
> - echo y | git reset -p &&
> - test "$(git ls-files)" = ""
> + echo y >yes &&
> + git reset -p  +
> + >expect &&
> + git ls-files >actual &&
> + test_cmp expect actual
>  '
>  
>  test_expect_success 'reset --soft is a no-op' '
>   rm .git/index &&
>   git add a &&
> - git reset --soft
> - test "$(git ls-files)" = "a"
> + git reset --soft &&
> +
> + echo a >expect &&
> + git ls-files >actual &&
> + test_cmp expect actual
>  '
>  
>  test_expect_success 'reset --hard' '
>   rm .git/index &&
>   git add a &&
> + test_when_finished "echo a >a" &&
>   git reset --hard &&
> - test "$(git ls-files)" = "" &&
> +
> + >expect &&
> + git ls-files >actual &&
> + test_cmp expect actual &&
>   test_path_is_missing a
>  '
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Make test "using invalid commit with -C" more strict

[Jonathan Nieder]

Junio C Hamano wrote:
>> Kacper Kornet wrote:

>>> In the test 'using invalid commit with -C' git-commit would have failed
>>> even if the -C option  had been given the correct commit, as there was
>>> nothing to commit.
[...]
> Also it would be much simpler to say "git commit --allow-empty".

Sounds good. ;-)

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Make test "using invalid commit with -C" more strict

[Junio C Hamano]

Jonathan Nieder  writes:

> Kacper Kornet wrote:
>
>> In the test 'using invalid commit with -C' git-commit would have failed
>> even if the -C option  had been given the correct commit, as there was
>> nothing to commit.
>
> Good catch.
>
> [...]
>> --- a/t/t7501-commit.sh
>> +++ b/t/t7501-commit.sh
>> @@ -53,7 +53,10 @@ test_expect_success PERL 'can use paths with 
>> --interactive' '
>>  '
>>  
>>  test_expect_success 'using invalid commit with -C' '
>> -test_must_fail git commit -C bogus
>> +echo bong >file &&
>> +git add file &&
>> +test_must_fail git commit -C bogus &&
>> +git reset
>
> I guess to be pedantic this should say
>
>   echo bong >file &&
>   git add file &&
>   test_when_finished "git reset --hard" &&
>   test_must_fail git commit -C bogus
>
> to avoid interfering with later tests even when this one fails and
> the && prevents the 'git reset' from being executed.

Makes sense.

Also it would be much simpler to say "git commit --allow-empty".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] t3404: rebase -i: demonstrate short SHA-1 collision

[Jonathan Nieder]

Eric Sunshine wrote:

> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -1037,4 +1037,28 @@ test_expect_success 'rebase -i with --strategy and -X' 
> '
>   test $(cat file1) = Z
>  '
>  
> +test_expect_success 'short SHA-1 setup' '
> + test_when_finished "git checkout master" &&
> + git checkout --orphan collide &&
> + git rm -rf . &&
> + (
> + unset test_tick &&
> + test_commit collide1 collide &&
> + test_commit --notick collide2 collide &&
> + test_commit --notick collide3 collide
> + )

Style: would be clearer indented:

(
unset test_tick &&
test_commit ...
)

> +test_expect_failure 'short SHA-1 collide' '
> + test_when_finished "reset_rebase && git checkout master" &&
> + git checkout collide &&
> + (
> + unset test_tick &&

Likewise.

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] write_index: optionally allow broken null sha1s

[Jonathan Nieder]

Hi,

Jeff King wrote:

> ---
> I was tempted to not involve filter-branch in this commit at all, and
> instead require the user to manually invoke
>
>   GIT_ALLOW_NULL_SHA1=1 git filter-branch ...
>
> to perform such a filter.  That would be slightly safer, but requires
> some specialized knowledge from the user (and advice on using
> filter-branch to remove such entries already exists on places like
> stackoverflow, and this patch makes it Just Work on recent versions of
> git).

The above few paragraphs explained the most mysterious part of the
patch to me.  I think they would be fine to include in the commit
message.

[...]
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1817,8 +1817,17 @@ int write_index(struct index_state *istate, int newfd)
>   continue;
>   if (!ce_uptodate(ce) && is_racy_timestamp(istate, ce))
>   ce_smudge_racily_clean_entry(ce);
> - if (is_null_sha1(ce->sha1))
> - return error("cache entry has null sha1: %s", ce->name);
> + if (is_null_sha1(ce->sha1)) {
> + static const char msg[] = "cache entry has null sha1: 
> %s";
> + static int allow = -1;
> +
> + if (allow < 0)
> + allow = git_env_bool("GIT_ALLOW_NULL_SHA1", 0);
> + if (allow)
> + warning(msg, ce->name);
> + else
> + return error(msg, ce->name);
> + }

Makes sense.

[...]
> --- /dev/null
> +++ b/t/t7009-filter-branch-null-sha1.sh
> @@ -0,0 +1,54 @@
> +#!/bin/sh
> +
> +test_description='filter-branch removal of trees with null sha1'
> +. ./test-lib.sh
> +
> +test_expect_success 'create base commits' '
> + test_commit one &&
> + test_commit two &&
> + test_commit three
> +'
> +
> +test_expect_success 'create a commit with a bogus null sha1 in the tree' '
> + test_tick &&
> + tree=$(
> + {
> + git ls-tree HEAD &&
> + printf "16 commit $_z40\\tbroken"
> + } | git mktree
> + ) &&

To avoid pipes involving git commands, since they can losing the exit
status (and hence information about whether git crashed):

{
git ls-tree HEAD &&
echo "16 commit $_z40   broken"
} >listing &&
echo "add broken entry" >msg &&

tree=$(git mktree http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dir: test_one_path: fix inconsistent behavior due to missing '/'

[Jonathan Nieder]

Eric Sunshine wrote:

> Although undocumented, directory_exists_in_index_icase(dirname,len)
> unconditionally assumes the presence of a '/' at dirname[len] (despite
> being past the end-of-string). Callers are expected to respect
[...]
>Fix this problem.

So, does this fix the problem by changing
directory_exists_in_index_icase() to be more liberal in what it
accepts, or callers to be more conservative in what they pass in?

Please forgive my laziness.  I ask in order to save future readers the
time of digging into the code.

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation/fast-import: clarify summary for `feature` command

[Jonathan Nieder]

Matthieu Moy wrote:

> In most cases, "feature " does not just require that the feature
> exists, but also changes the behavior to enable it.

For what it's worth,

Reviewed-by: Jonathan Nieder 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] t3404: preserve test_tick state across short SHA-1 collision test

[Jonathan Nieder]

Hi,

Eric Sunshine wrote:

> The short SHA-1 collision test requires carefully crafted commits in
> order to ensure a collision at rebase time.

Yeah, this breaks the usual rule that tests should be independent
of hashing function.  But it's the best we can do, I think.

[...]
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -994,17 +994,23 @@ test_expect_success 'short SHA-1 setup' '
>   test_when_finished "git checkout master" &&
>   git checkout --orphan collide &&
>   git rm -rf . &&
> + (
>   unset test_tick &&
>   test_commit collide1 collide &&
>   test_commit --notick collide2 collide &&
>   test_commit --notick "collide3 115158b5" collide collide3 collide3
> + )

Would be clearer if the code in a subshell were indented:

(
unset test_tick &&
test_commit ...
)

[...]
>  test_expect_success 'short SHA-1 collide' '
>   test_when_finished "reset_rebase && git checkout master" &&
>   git checkout collide &&
> + (
> + unset test_tick &&
> + test_tick &&
>   FAKE_COMMIT_MESSAGE="collide2 815200e" \
>   FAKE_LINES="reword 1 2" git rebase -i HEAD~2
> + )

Likewise.

Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] Fix path prefixing in grep_object

[Jeff King]

On Sat, Aug 24, 2013 at 10:41:42PM -0700, Jonathan Nieder wrote:

> Jeff King wrote:
> 
> > So we are necessarily reconstructing based on what we know of the
> > syntax. And I think that your rule is OK, because we know that refnames
> > cannot contain a colon.
> 
> What happens with expressions like HEAD^{/test:}?

Ugh, right. Names are more than just refnames.

So I think the only way to do this robustly is to ask get_sha1 to
remember more about what happened. We might even be able to get away
without teaching get_sha1_with_context anything else; it already records
the path, so we should be able to just check whether that is non-empty.

But we use an object_array to store the list of objects, and it has no
room for such a bit. So we'd probably want to refactor that, too.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] Fix path prefixing in grep_object

[Jonathan Nieder]

Jeff King wrote:

> So we are necessarily reconstructing based on what we know of the
> syntax. And I think that your rule is OK, because we know that refnames
> cannot contain a colon.

What happens with expressions like HEAD^{/test:}?

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/13] Use "git merge" instead of "git pull ."

[Martin von Zweigbergk]

On Sat, Aug 24, 2013 at 9:19 PM, Jonathan Nieder  wrote:
> Thomas Ackermann wrote:
>> --- a/Documentation/user-manual.txt
>> +++ b/Documentation/user-manual.txt
>> @@ -1784,17 +1784,6 @@ repository that you pulled from.
>>  <>; instead, your branch will just be
>>  updated to point to the latest commit from the upstream branch.)
>>
>> -The `git pull` command can also be given `.` as the "remote" repository,
>> -in which case it just merges in a branch from the current repository; so
>> -the commands
>> -
>> --
>> -$ git pull . branch
>> -$ git merge branch
>> --
>> -
>> -are roughly equivalent.  The former is actually very commonly used.
>> -
>
> I wonder if it would make sense to say they simply *are* equivalent.
> I.e., what differences are there between those two commands, and could
> "git pull" be tweaked to eliminate them?

One difference is that "git pull" can be configured to rebase.

> [...]
>> @@ -2259,7 +2248,7 @@ When you are happy with the state of this change, you 
>> can pull it into the
>>  "test" branch in preparation to make it public:

I realize that "pull" here is not necessarily about the command, but
perhaps it would still make sense to change it?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] Fix path prefixing in grep_object

[Junio C Hamano]

Jonathan Nieder  writes:

> I think Phil meant that when "git grep" is asked to search within
> "HEAD:some/path", filenames tacked on at the end should be appended
> with a '/' separator instead of the usual ':' (e.g.,
> "HEAD:some/path/inner/path.c", not "HEAD:some/path:inner/path.c").

Ah, OK.

I am not sure if we have a proper hint in the revision parser
machinery, but it may not be too hard to teach rev-cmdline interface
to keep that kind of information (i.e. "This tree object name is a
result of parsing ':path' syntax").

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/13] Remove obscure reference from "Examples"

[Jonathan Nieder]

Thomas Ackermann wrote:

> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -2131,8 +2131,6 @@ He uses two public branches:
>  
>   - A "test" tree into which patches are initially placed so that they
> can get some exposure when integrated with other ongoing development.
> -   This tree is available to Andrew for pulling into -mm whenever he
> -   wants.

This drops useful information (namely, that Tony was publishing
history for two people to consume).  Perhaps it should spell out "the
bleeding-edge -mm tree"?

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/13] Improve section "Merge multiple trees"

[Jonathan Nieder]

Thomas Ackermann wrote:

> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -3992,16 +3992,16 @@ Merging multiple trees
>  
>  Git helps you do a three-way merge, which you can expand to n-way by
>  repeating the merge procedure arbitrary times until you finally
> -"commit" the state.
> +commit the state.

The above sentence is unclear to me both before and after this change.

Git helps me do a three-way merge, but I'm on my own if I want to
expand to n-way?  Those times I repeat it are arbitrary times, not
arbitrarily many times?  Using "git merge" I make commits, but I
do not finally commit to the result until the (n-1)st?  And what is
this state I am committing?

Maybe the intent is

Git can help you perform a three-way merge, which can in turn be
used for a many-way merge by repeating the merge procedure several
times.  The usual situation is that you only do one three-way merge
(reconciling two lines of history) and commit the result, but if
you like to, you can merge several branches in one go.

To perform a three-way merge, you start with the two commits you
want to merge, find their closest common parent (a third commit),
and compare the trees corresponding to these three commits.

To get the "base" for the merge, look up the common parent of two
commits:

$ git merge-base  

This prints the name of a commit they are both based on.
...

[...]
> -To get the "base" for the merge, you first look up the common parent
> +To get the base for the merge, you first look up the common parent

Merge base hasn't been defined, so this is using quotes to point out
that it is defining a new, unfamiliar term.

[...]
> -now look up the "tree" objects of those commits, which you can easily
> -do with (for example)
> +now look up the tree objects of those commits, which you can easily
> +do with

Yes.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] commit: search author pattern against mailmap

[Junio C Hamano]

Jeff King  writes:

> On Sat, Aug 24, 2013 at 04:07:47PM +0200, Antoine Pelisse wrote:
>
>> @@ -945,13 +947,16 @@ static const char *find_author_by_nickname(const char 
>> *name)
>>  av[++ac] = buf.buf;
>>  av[++ac] = NULL;
>>  setup_revisions(ac, av, &revs, NULL);
>> +revs.mailmap = &mailmap;
>> +read_mailmap(revs.mailmap, NULL);
>> +
>>  prepare_revision_walk(&revs);
>>  commit = get_revision(&revs);
>>  if (commit) {
>>  struct pretty_print_context ctx = {0};
>>  ctx.date_mode = DATE_NORMAL;
>>  strbuf_release(&buf);
>> -format_commit_message(commit, "%an <%ae>", &buf, &ctx);
>> +format_commit_message(commit, "%aN <%aE>", &buf, &ctx);
>>  return strbuf_detach(&buf, NULL);
>>  }
>>  die(_("No existing author found with '%s'"), name);
>
> Do we need to clear_mailmap before returning to avoid a leak?

Good question. What I queued yesterday seems to have a call to
clear_mailmap(&mailmap) before that return.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/13] Improve description in "How to merge"

[Jonathan Nieder]

Thomas Ackermann wrote:

> Describe the conflict resolution in terms of the
> commands the user is supposed to use.
[...]
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1251,10 +1251,8 @@ Automatic merge failed; fix conflicts and then commit 
> the result.
>  -
>  
>  Conflict markers are left in the problematic files, and after
> -you resolve the conflicts manually, you can update the index
> -with the contents and run Git commit, as you normally would when
> -creating a new file.

Hm.  It's been too long since I was a novice, since I find the above
clear already.

To make the text clearer, I think it would be best to *add* an example
instead of replacing it by one.

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/13] Simplify "How to make a commit"

[Jonathan Nieder]

Thomas Ackermann wrote:

> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1080,19 +1080,14 @@ produce no output at that point.
>  
>  Modifying the index is easy:
>  
> -To update the index with the new contents of a modified file, use
> +To add the contents of a new file to the index or update the index 
> +with the new contents of a modified file, use

That's a mouthful.  I'd say

To update the index with the contents of a new or modified file, use

[...]
> -To add the contents of a new file to the index, use
> -
> --
> -$ git add path/to/file
> --
> -

\o/

> -To remove a file from the index and from the working tree,
> +To remove a file from the index and from the working tree, use
>  
>  -
>  $ git rm path/to/file

In git 2.0, (plain "rm" followed by) "git add" should work for this,
too.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/13] Fix some typos

[Jonathan Nieder]

Thomas Ackermann wrote:

> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -219,7 +219,7 @@ of development leading to that point.
>  
>  The best way to see how this works is using the linkgit:gitk[1]
>  command; running gitk now on a Git repository and looking for merge
> -commits will help understand how the Git organizes history.
> +commits will help understand how Git organizes history.

Heh.  Sure.

[...]
> @@ -793,7 +793,7 @@ e05db0fd4f31dde7005f075a84f96b360d05984b
>  -
>  
>  Or you could recall that the `...` operator selects all commits
> -contained reachable from either one reference or the other but not
> +reachable from either one reference or the other but not
>  both; so

Yes.  Here one of the references is the nickname of a remote and not a
branch, so "reachable from" reads better than "contained in" would.

> @@ -820,7 +820,7 @@ You could just visually inspect the commits since 
> e05db0fd:
>  $ gitk e05db0fd..
>  -
>  
> -Or you can use linkgit:git-name-rev[1], which will give the commit a
> +or you can use linkgit:git-name-rev[1], which will give the commit a

I think this reads better with a capital 'O'.  (The pedant in me
likes it, too, since a colon ends a sentence.)

The lowercase 'but' later in this section should perhaps also be
capitalized, since it also starts an independent thought.

But that may sometimes help you guess which tags come after the
given commit.

The sentence "So, you can run something like ... then search for a
line that looks like ..." is a sequence of incomplete thoughts.  It
could be paraphrased a little to scan better:

So, if you run something like "git show-branch e05db0fd
v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2"

$ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2
! [e05db...

then a line like

+ ++ [e05db0fd] Fix warnings in ...

shows that e05db0fd is reachable from itself, from v1.5.0-rc1,
and from v1.5.0-rc2, and not from v1.5.0-rc0.

[...]
> @@ -3525,7 +3525,7 @@ with Git 1.5.2 can look up the submodule commits in the 
> repository and
>  manually check them out; earlier versions won't recognize the submodules at
>  all.
>  
> -To see how submodule support works, create (for example) four example
> +To see how submodule support works, create four example

I'd keep the joke.

[...]
> @@ -3897,7 +3897,7 @@ fact that such a commit brings together ("merges") two 
> or more
>  previous states represented by other commits.
>  
>  In other words, while a "tree" represents a particular directory state
> -of a working directory, a "commit" represents that state in "time",
> +of a working directory, a "commit" represents that state in time,
>  and explains how we got there.

It's not really about time but about (hypothetical, possibly branched)
history, but I think your change makes it about as clear as it can be.

Thanks, and hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] Fix path prefixing in grep_object

[Jeff King]

On Sat, Aug 24, 2013 at 09:35:58PM -0400, Phil Hord wrote:

> When the pathspec given to grep includes a tree name, the full
> name of matched files is assembled using colon as a separator.
> If the pathspec includes a tree name, it should use a slash
> instead.
> 
> Check if the pathspec already names a tree and ref (including
> a colon) and use a slash if so.

Makes sense.

> I'm not sure about the detection I used here.  It works, but it is
> not terribly robust.  Is there a better way to handle this?  Maybe
> something like 'prefix_pathspec(name,"");'.

I think the information you want has been thrown away by the time we get
to grep_object. Only get_sha1 knows whether the name was really a direct
tree reference or if it had to traverse paths.

So we are necessarily reconstructing based on what we know of the
syntax. And I think that your rule is OK, because we know that refnames
cannot contain a colon. So even though pathnames can, we do not have to
care; we only want to know "is there a path in the name", and if we have
at least one colon, the answer is yes.

>  builtin/grep.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

A test would be nice. Both to make sure we do not re-break it, and because
it helps demonstrate the problem very easily (it took me a minute to
figure out what was going on from your description).

> diff --git a/builtin/grep.c b/builtin/grep.c
> index 03bc442..d0deae4 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -480,8 +480,9 @@ static int grep_object(struct grep_opt *opt, const struct 
> pathspec *pathspec,
>   len = name ? strlen(name) : 0;
>   strbuf_init(&base, PATH_MAX + len + 1);
>   if (len) {
> + int has_colon = !!strchr(name,':');
>   strbuf_add(&base, name, len);
> - strbuf_addch(&base, ':');
> + strbuf_addch(&base, has_colon?'/':':');

Please use whitespace with your ternary operator. The '/':':' made me
think I was reading Perl for a minute. :)

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/24] Index-v5

[Duy Nguyen]

On Sun, Aug 25, 2013 at 10:07 AM, Junio C Hamano  wrote:
> Duy Nguyen  writes:
>
>> On Mon, Aug 19, 2013 at 2:41 AM, Thomas Gummerer  
>> wrote:
>>
>> I'm done reviewing this version (I neglected the extension writing
>> patches because after spending hours on the main write patch I don't
>> want to look at them anymore :p). Now that rc period is over, with a
>> partial write proof-of-concept, I think it's enough to call Junio's
>> attention on the series, see if we have any chance of merging it. The
>> partial write POC is needed to make sure we don't overlook anything,
>> just support update-index is enough.
>
> I've been following the review comment threads after looking at the
> patches myself when they were posted. I was hoping to see some API
> improvement over the current "we (have to) have everything available
> in-core in a flat array" model, which gives a lot of convenience and
> IO overhead at the same time, that would make me say "yes, this
> operation, that we need to do very often, will certainly be helped
> by this new API, and in order to support that style of API better,
> the current file format is inadequate and we do need to go to the
> proposed tree like on-disk format" for at least one, but
> unfortunately I haven't found any (yet).

Thomas is in the best position to answer this, but I'll give it a try.
In my opinon, v2-4 works well for moderate-sized worktrees, v5 aims to
make the index scale better. One way to make it scale is not to read
the whole index up when you only need a portion of the index.
read_index_filtered() enables this. We could implement
read_index_filtered() on v2 too, but because v2 lacks proper data
structure to support it, we need to scan through all on-disk entries.
"git diff" and "git status" with pathspec may benefit from this (and
for large worktrees, people better use pathspec than whole-tree
"status"). The flat (but not full) array model seems best fit because
we still need to support v2. Another v5 improvement is fast "git add
-u/git commit -a" when partial write is implemented. I don't think
such a patch is posted. There may be API addition to aid v5 code but
it should not be big API change.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] Fix path prefixing in grep_object

[Jonathan Nieder]

Junio C Hamano wrote:
> Phil Hord  writes:
>> On Sat, Aug 24, 2013 at 9:35 PM, Phil Hord  wrote:

>>> When the pathspec given to grep includes a tree name, the full
>>> name of matched files is assembled using colon as a separator.
>>> If the pathspec includes a tree name, it should use a slash
>>> instead.
[...]
>>   If the tree name includes an object name, as in
>>   HEAD:some/path, it should use a slash instead.
>
> What problem are you trying to solve?  It should use HEAD:some/path,
> not HEAD/some/path.

I think Phil meant that when "git grep" is asked to search within
"HEAD:some/path", filenames tacked on at the end should be appended
with a '/' separator instead of the usual ':' (e.g.,
"HEAD:some/path/inner/path.c", not "HEAD:some/path:inner/path.c").
Otherwise I cannot copy and paste "git grep" output and get something
suitable for passing to "git show".

I don't think we have a standard name for the tree:path syntax.  I've
always just called it tree:path syntax. :)

Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/13] Use "git merge" instead of "git pull ."

[Jonathan Nieder]

Thomas Ackermann wrote:
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1784,17 +1784,6 @@ repository that you pulled from.
>  <>; instead, your branch will just be
>  updated to point to the latest commit from the upstream branch.)
>  
> -The `git pull` command can also be given `.` as the "remote" repository,
> -in which case it just merges in a branch from the current repository; so
> -the commands
> -
> --
> -$ git pull . branch
> -$ git merge branch
> --
> -
> -are roughly equivalent.  The former is actually very commonly used.
> -

I wonder if it would make sense to say they simply *are* equivalent.
I.e., what differences are there between those two commands, and could
"git pull" be tweaked to eliminate them?

I agree that the historical "The former is actually very commonly
used" ought to go.  It wouldn't too relevant for someone learning to
use git even if it were still true. ;-)

[...]
> @@ -2259,7 +2248,7 @@ When you are happy with the state of this change, you 
> can pull it into the
>  "test" branch in preparation to make it public:
>  
>  -
> -$ git checkout test && git pull . speed-up-spinlocks
> +$ git checkout test && git merge speed-up-spinlocks
>  -

Yes.

Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/13] Use current output for "git repack"

[Jonathan Nieder]

Thomas Ackermann wrote:

> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -3203,14 +3203,11 @@ To put the loose objects into a pack, just run git 
> repack:
>  
>  
>  $ git repack
[...]
> -Total 6020, written 6020 (delta 4070), reused 0 (delta 0)
> -Pack pack-3e54ad29d5b2e05838c75df582c65257b8d08e1c created.
> +Total 6020 (delta 4070), reused 0 (delta 0)

Sure.  I wonder if there should be some text to replace the output
that mentions the pack being created, though.  E.g.:

>  
>  
>  You can then run

Total 6020 (delta 4070), reused 0 (delta 0)


This creates a single "pack file" in .git/objects/pack/ containing
all currently unpacked objects.  You can then run
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] commit: search author pattern against mailmap

[Jeff King]

On Sat, Aug 24, 2013 at 04:07:47PM +0200, Antoine Pelisse wrote:

> @@ -945,13 +947,16 @@ static const char *find_author_by_nickname(const char 
> *name)
>   av[++ac] = buf.buf;
>   av[++ac] = NULL;
>   setup_revisions(ac, av, &revs, NULL);
> + revs.mailmap = &mailmap;
> + read_mailmap(revs.mailmap, NULL);
> +
>   prepare_revision_walk(&revs);
>   commit = get_revision(&revs);
>   if (commit) {
>   struct pretty_print_context ctx = {0};
>   ctx.date_mode = DATE_NORMAL;
>   strbuf_release(&buf);
> - format_commit_message(commit, "%an <%ae>", &buf, &ctx);
> + format_commit_message(commit, "%aN <%aE>", &buf, &ctx);
>   return strbuf_detach(&buf, NULL);
>   }
>   die(_("No existing author found with '%s'"), name);

Do we need to clear_mailmap before returning to avoid a leak?

I suspect we may be leaking pending commits from the revision walker,
too, but I'm not sure we have an easy "clear everything" function there.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/13] "git prune" is safe now

[Junio C Hamano]

Thomas Ackermann  writes:

> According to the man-pages of "git prune" and "git fsck",
> both are safe nowadays.

Safe does not have much to do with the latter.  "git fsck" has
always been safe in that it would not alter the object store, and if
you run it while you are actively creating (or pruning for that
matter) objects, it _will_ get confused.

For that matter, running "prune", even though we designed it to be
safe from concurrent accesses, deliberately on a non-quiescent
repository is not a good idea, either.  It may be a good idea to
weaken the phrasing used to discourage it, but discouraging itself
is not a bad idea.

> Signed-off-by: Thomas Ackermann 
> ---
>  Documentation/user-manual.txt | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 08d8c91..29945d9 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -3283,17 +3283,7 @@ state, you can just prune all unreachable objects:
>  $ git prune
>  
>  
> -and they'll be gone. But you should only run `git prune` on a quiescent
> -repository--it's kind of like doing a filesystem fsck recovery: you
> -don't want to do that while the filesystem is mounted.
> -
> -(The same is true of `git fsck` itself, btw, but since
> -`git fsck` never actually *changes* the repository, it just reports
> -on what it found, `git fsck` itself is never 'dangerous' to run.
> -Running it while somebody is actually changing the repository can cause
> -confusing and scary messages, but it won't actually do anything bad. In
> -contrast, running `git prune` while somebody is actively changing the
> -repository is a *BAD* idea).
> +and they'll be gone. 
>  
>  [[recovering-from-repository-corruption]]
>  Recovering from repository corruption
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 12/13] Remove irrelevant reference from "Tying it all together"

[Junio C Hamano]

Thomas Ackermann  writes:

> Sorry Jon, but this might not be of any help to new Git users ;)
>
> Signed-off-by: Thomas Ackermann 

Yeah, I think this is long overdue.  The drawing was taken from an
e-mail posted in a discussion, and the credit should have been given
in the commit log message, not in-text.


> ---
>  Documentation/user-manual.txt | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 0d3f04e..08d8c91 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -3908,8 +3908,7 @@ save the note about that state, in practice we tend to 
> just write the
>  result to the file pointed at by `.git/HEAD`, so that we can always see
>  what the last committed state was.
>  
> -Here is an ASCII art by Jon Loeliger that illustrates how
> -various pieces fit together.
> +Here is a picture that illustrates how various pieces fit together:
>  
>  
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/13] Remove obscure reference from "Examples"

[Junio C Hamano]

Thomas Ackermann  writes:

> Signed-off-by: Thomas Ackermann 
> ---
>  Documentation/user-manual.txt | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index aa6bfab..0d3f04e 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -2131,8 +2131,6 @@ He uses two public branches:
>  
>   - A "test" tree into which patches are initially placed so that they
> can get some exposure when integrated with other ongoing development.
> -   This tree is available to Andrew for pulling into -mm whenever he
> -   wants.
>  
>   - A "release" tree into which tested patches are moved for final sanity
> checking, and as a vehicle to send them upstream to Linus (by sending

Hmm What part is obscure and why does this need to be removed?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] git-remote-mediawiki: reset private ref after non-dumb push

[Junio C Hamano]

Matthieu Moy  writes:

> How would I do that? The update to the remote namespace is done by Git,
> not by the remote-helper.
>
> OK, I'm now convinced that my solution is the right one. The
> alternatives are far more complex and I still fail to see the benefits.

Sounds like a plan, even though it smells like the "update is done
by Git" that does not have any way to opt-out may be the real design
mistake and your "solution" is a work-around to that.

Would it be a possibility to make it tunable, perhaps by introducing
a capability on the remote-interface side that allows you to tell it
not to mess with the remote namespace?  If we were doing this from
scratch, I would suspect that we would have made the capability work
the other way around (Git does not do the update by default, but
helpers c an ask Git to do so).

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] Use current "detached HEAD" message

[Jonathan Nieder]

Thomas Ackermann wrote:

> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -312,10 +312,17 @@ referenced by a tag:
>  
>   
>   $ git checkout v2.6.17
> - Note: moving to "v2.6.17" which isn't a local branch
> - If you want to create a new branch from this checkout, you may do so
> - (now or later) by using -b with the checkout command again. Example:
> -   git checkout -b 
> + Note: checking out 'v2.6.17'.
> +
> + You are in 'detached HEAD' state. You can look around, make experimental
> + changes and commit them, and you can discard any commits you make in 
> this
> + state without impacting any branches by performing another checkout.
> +
> + If you want to create a new branch to retain commits you create, you may
> + do so (now or later) by using -b with the checkout command again. 
> Example:
> +
> +   git checkout -b new_branch_name
> +
>   HEAD is now at 427abfa... Linux v2.6.17

I wonder if this longer wall of text (added in 13be3e31, 2010-01-29)
is too aggressive.

It is the only piece of advice that I explicitly disable in
~/.gitconfig, so I haven't looked at it again for a while.  Since
then, the usual stream of questions about how to recover from people
who accidentally detached HEAD has still been showing up in #git, so I
don't think the message succeeded in its purpose.

That might be partly because it is too long to digest at a glance.

When I see this message, what I actually take in is

  $ git checkout v1.7.3
 Hmm, capital --->Note: checking out 'v1.7.3'.
 heading before
 lowercaseYou are in 'detached HEAD' state. You ...
 sentence.
... checkout.

  If you want ...
  do so (now or later) by using -b    Example:

git ...

  HEAD is ...
 Phew, I can >$
 type commands
 again.

Whereas I think the message is just meant to convey the following:

  $ git checkout v2.6.17
  note: checking out a tag for inspection and discardable experiments on top

  To create a new branch to save your changes:

git checkout -b my-branch-based-on-v2.6.17

  HEAD is now at 427abfa... Linux v2.6.17
  $

>  
>  
> @@ -326,7 +333,7 @@ and git branch shows that you are no longer on a branch:
>  $ cat .git/HEAD
>  427abfa28afedffadfca9dd8b067eb6d36bac53f
>  $ git branch
> -* (no branch)
> +* (detached from v2.6.17)

grep "no branch" Documentation/user-manual.txt

finds two other instances of that message, which this branch doesn't
touch.  One is about a bisection, where (no branch) is pretty close
to the actual message ('(no branch, bisect started on master)').
The other is about submodules.  Here's a patch for potential squashing
in that corrects it.

Thanks,
Jonathan

diff --git i/Documentation/user-manual.txt w/Documentation/user-manual.txt
index 3e226190..b76219ee 100644
--- i/Documentation/user-manual.txt
+++ w/Documentation/user-manual.txt
@@ -3647,7 +3647,7 @@ working on a branch.
 
 -
 $ git branch
-* (no branch)
+* (detached from d266b98)
   master
 -
 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] Fix path prefixing in grep_object

[Junio C Hamano]

Phil Hord  writes:

> On Sat, Aug 24, 2013 at 9:35 PM, Phil Hord  wrote:
>>
>> When the pathspec given to grep includes a tree name, the full
>> name of matched files is assembled using colon as a separator.
>> If the pathspec includes a tree name, it should use a slash
>> instead.
>>
>> Check if the pathspec already names a tree and ref (including
>> a colon) and use a slash if so.
>
> I think I used lots of wrong terminology there.  What do I call these
> things?
>
> HEAD:path is a tree.

It is one way to name a tree object, yes (another obvious way is to
spell it out, e.g. 3610ac62).

> HEAD is a commit name.

It is one way to name the commit object, yes, but I am guessing that
you are interested in these in the context of resolving HEAD:path.
If that is the case, then "commit"-ness is not something you are
interested in---any tree-ish would do (e.g. v1.8.4, maint^{tree}).

> Maybe like this?
>
>   When a tree is given to grep, the full name of matched files
>   is assembled using colon as a separator.
>
>   If the tree name includes an object name, as in
>   HEAD:some/path, it should use a slash instead.

What problem are you trying to solve?  It should use HEAD:some/path,
not HEAD/some/path.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/13] Remove unnecessary historical note from "Object storage format"

[Junio C Hamano]

Thomas Ackermann  writes:

> Signed-off-by: Thomas Ackermann 
> ---
>  Documentation/user-manual.txt | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index f713f26..aa6bfab 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -4132,8 +4132,6 @@ about the data in the object.  It's worth noting that 
> the SHA-1 hash
>  that is used to name the object is the hash of the original data
>  plus this header, so `sha1sum` 'file' does not match the object name
>  for 'file'.
> -(Historical note: in the dawn of the age of Git the hash
> -was the SHA-1 of the 'compressed' object.)

As we no longer are able to read such a historical object, I think
it is OK to drop the historical note in this particular case.

Thanks.

>  
>  As a result, the general consistency of an object can always be tested
>  independently of the contents or the type of the object: all objects can
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/13] Improve section "Manipulating branches"

[Junio C Hamano]

Thomas Ackermann  writes:

> Add some missing punctuation.
> Simplify description of "git branch -d/-D".
> ...
>  `git branch -d `::
> - delete the branch ``; if the branch you are deleting
> - points to a commit which is not reachable from the current
> - branch, this command will fail with a warning.
> + delete the branch ``; if the branch is not fully
> + merged in its upstream branch, this command will fail with a warning.

But is this correct?  I somehow thought that we check with the
current or the upstream.

>  `git branch -D `::
> - even if the branch points to a commit not reachable
> - from the current branch, you may know that that commit
> - is still reachable from some other branch or tag.  In that
> - case it is safe to use this command to force Git to delete
> - the branch.
> + delete the branch `` irrespective of its merged status.

This is an OK change.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/13] Improve description in "How to merge"

[Junio C Hamano]

Thomas Ackermann  writes:

> Describe the conflict resolution in terms of the
> commands the user is supposed to use.
>
> Signed-off-by: Thomas Ackermann 
> ---
>  Documentation/user-manual.txt | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index ccbddc7..0656191 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1251,10 +1251,8 @@ Automatic merge failed; fix conflicts and then commit 
> the result.
>  -
>  
>  Conflict markers are left in the problematic files, and after
> -you resolve the conflicts manually, you can update the index
> -with the contents and run Git commit, as you normally would when
> -creating a new file.
> -
> +you have resolved the conflicts manually, you can `git add` the
> +new contents and do a `git commit` in the end.

This is a slight documentation regression, as there are cases your
conflict resolution is a removal of the file, isn't it?

>  If you examine the resulting commit using gitk, you will see that it
>  has two parents, one pointing to the top of the current branch, and
>  one to the top of the other branch.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/13] Simplify "How to make a commit"

[Junio C Hamano]

Thomas Ackermann  writes:

> Combine the two cases for "git add" into one.
> Add verb "use" to "git rm" case.
>
> Signed-off-by: Thomas Ackermann 
> ---
>  Documentation/user-manual.txt | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 8a1a441..ca78333 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1080,19 +1080,14 @@ produce no output at that point.
>  
>  Modifying the index is easy:
>  
> -To update the index with the new contents of a modified file, use
> +To add the contents of a new file to the index or update the index 
> +with the new contents of a modified file, use
>  
>  -
>  $ git add path/to/file
>  -
>  
> -To add the contents of a new file to the index, use
> -
> --
> -$ git add path/to/file
> --

OK.

> -To remove a file from the index and from the working tree,
> +To remove a file from the index and from the working tree, use
>  
>  -
>  $ git rm path/to/file
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/13] Use "git merge" instead of "git pull ."

[Junio C Hamano]

Thomas Ackermann  writes:

> "git pull ." works, but "git merge" is the recommended
> way for new users to do things. (The old description 
> also should have read "The former is actually *not* very
> commonly used".)

I think it is probably a good idea to replace "pull ." in the two
later hunks with "merge", but the flow of the explanation reads
better if you did not touch the first hunk at all.  The section
introduced how fully-spelled "git pull origin master" works, how its
parameters can be omitted in a common case of integrating with the
branch at a remote repository you usually integrate with, and then
the hunk that you touched transitions to the local use, hinting that
your local repository is not all that special.  It is very commonly
used among people who grok that fact, and of course it still works
because we do want to support that usage ;-).

On the other hand, these later two hunks are not about explaining
"pull"; using "git merge" in the examples is more appropriate.

> Signed-off-by: Thomas Ackermann 
> ---
>  Documentation/user-manual.txt | 15 ++-
>  1 file changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index b450980..8a1a441 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1784,17 +1784,6 @@ repository that you pulled from.
>  <>; instead, your branch will just be
>  updated to point to the latest commit from the upstream branch.)
>  
> -The `git pull` command can also be given `.` as the "remote" repository,
> -in which case it just merges in a branch from the current repository; so
> -the commands
> -
> --
> -$ git pull . branch
> -$ git merge branch
> --
> -
> -are roughly equivalent.  The former is actually very commonly used.
> -
>  [[submitting-patches]]
>  Submitting patches to a project
>  ---
> @@ -2259,7 +2248,7 @@ When you are happy with the state of this change, you 
> can pull it into the
>  "test" branch in preparation to make it public:
>  
>  -
> -$ git checkout test && git pull . speed-up-spinlocks
> +$ git checkout test && git merge speed-up-spinlocks
>  -
>  
>  It is unlikely that you would have any conflicts here ... but you might if 
> you
> @@ -2271,7 +2260,7 @@ see the value of keeping each patch (or patch series) 
> in its own branch.  It
>  means that the patches can be moved into the `release` tree in any order.
>  
>  -
> -$ git checkout release && git pull . speed-up-spinlocks
> +$ git checkout release && git merge speed-up-spinlocks
>  -
>  
>  After a while, you will have a number of branches, and despite the
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/13] Call it "Git User Manual" and remove reference to very old Git version

[Junio C Hamano]

Thomas Ackermann  writes:

> Signed-off-by: Thomas Ackermann 
> ---
>  Documentation/user-manual.txt | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index fe723e4..103ec9a 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1,6 +1,5 @@
> -Git User's Manual (for version 1.5.3 or newer)
> -__
> -
> +Git User Manual
> +___
>  
>  Git is a fast distributed revision control system.

Yeah, it is about time.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/24] Index-v5

[Junio C Hamano]

Duy Nguyen  writes:

> On Mon, Aug 19, 2013 at 2:41 AM, Thomas Gummerer  wrote:
>
> I'm done reviewing this version (I neglected the extension writing
> patches because after spending hours on the main write patch I don't
> want to look at them anymore :p). Now that rc period is over, with a
> partial write proof-of-concept, I think it's enough to call Junio's
> attention on the series, see if we have any chance of merging it. The
> partial write POC is needed to make sure we don't overlook anything,
> just support update-index is enough.

I've been following the review comment threads after looking at the
patches myself when they were posted. I was hoping to see some API
improvement over the current "we (have to) have everything available
in-core in a flat array" model, which gives a lot of convenience and
IO overhead at the same time, that would make me say "yes, this
operation, that we need to do very often, will certainly be helped
by this new API, and in order to support that style of API better,
the current file format is inadequate and we do need to go to the
proposed tree like on-disk format" for at least one, but
unfortunately I haven't found any (yet).

So...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/13] Call it "Git User Manual" and remove reference to very old Git version

[Jonathan Nieder]

Thomas Ackermann wrote:

> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1,6 +1,5 @@
> -Git User's Manual (for version 1.5.3 or newer)
> +Git User Manual

"User" versus "User's": why?  But I don't care much about this.

Dropping the reference to 1.5.3 is very welcome, since it should help
people to update the manual without fearing that new sections will
fail for people with ancient copies of git.  For what it's worth,
Reviewed-by: Jonathan Nieder 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] git-p4: Ask "p4" to interpret View setting

[Pete Wyckoff]

p...@padd.com wrote on Thu, 15 Aug 2013 21:24 -0400:
> ksaitoh...@gmail.com wrote on Wed, 14 Aug 2013 09:59 +0900:
> > > My only concern is in the commit message, about performance.  A
> > > change that has lots of files in it will cause many roundtrips to
> > > p4d to do "p4 where" on each.  When the files don't have much
> > > edited content, this new approach will make the import take twice
> > > as long, I'll guess.  Do you have a big repository where you
> > > could test that?
> > 
> > I measured performance of "git p4 clone  --use-client-spec" with a
> > repository it has 1925 files, 50MB.
> >   Original:8.05s user 32.02s system 15% cpu 4:25.34 total
> >   Apply patch:9.02s user 53.19s system 14% cpu 6:56.41 total
> > 
> > It is acceptable in my situation, but looks quite slow...
> > 
> > Then I implemented one batch query version
> >7.92s user 33.03s system 15% cpu 4:25.59 total
> > 
> > It is same as original
> > 
> > My additional patch is below.
> > I investigate call graph (attached rough sketch) and
> > implement batch query in "commit()" and "splitFilesIntoBranches()".
> > In addition, modified "map_in_client" to just search cache value.
> > 
> > Could you accept?
> 
> This looks good.  I've started my own performance testing
> on a few-hundred-thousand file repo to confirm your findings.
> 
> If it seems to work out, we can clean up the patch.  Otherwise
> maybe need to think about having both implementations and use
> the by-hand one for "...".  I don't like that approach.  Let's
> hope it's not needed.

I tried with a few repos:

Small repo, single-commit clone:

Current: 0m0.35s user 0m0.30s sys 0m11.52s elapsed 5.69 %CPU
No batching: 0m0.66s user 0m0.77s sys 0m34.42s elapsed 4.17 %CPU
Batching:0m0.28s user 0m0.29s sys 0m10.85s elapsed 5.27 %CPU

Big repo, single-commit clone:

Current: 6m21.38s user 1m35.36s sys 19m44.83s elapsed 40.23 %CPU
No batching: 1m53.13s user 24m34.35s sys 146m13.80s elapsed 18.09 %CPU (*)
Batching:6m22.01s user 1m44.23s sys 21m19.73s elapsed 37.99 %CPU

The "no batching" run died with an unrelated p4 timeout.

Big repo, 1000 incremental changes:

Current: 0m13.43s user 0m19.82s sys 11m12.58s elapsed 4.94 %CPU
No batching: 0m20.29s user 0m39.94s sys 38m44.69s elapsed 2.59 %CPU (*)
Batching:0m16.15s user 0m26.60s sys 13m55.69s elapsed 5.11 %CPU

The "no batching" run died at 28% of the way through.

There is probably a 20%-ish slowdown in my environment with this
approach.  But given that the timescale for these operations is
measured in the tens of minutes, I don't think a couple more matters
too much to anybody.

The attractiveness of the simplicity and increased client spec feature
coverage weighs in its favor.  Let's go ahead and inflict this on the
world and see what they think.

Do you have an updated patch?  Want to take some time to clean up and
resubmit the entire series?  The batching should be incorporated with
the last 2/2 that I sent out.

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] Fix path prefixing in grep_object

[Phil Hord]

On Sat, Aug 24, 2013 at 9:35 PM, Phil Hord  wrote:
>
> When the pathspec given to grep includes a tree name, the full
> name of matched files is assembled using colon as a separator.
> If the pathspec includes a tree name, it should use a slash
> instead.
>
> Check if the pathspec already names a tree and ref (including
> a colon) and use a slash if so.

I think I used lots of wrong terminology there.  What do I call these
things?

HEAD:path is a tree.

HEAD is a commit name.

Maybe like this?

  When a tree is given to grep, the full name of matched files
  is assembled using colon as a separator.

  If the tree name includes an object name, as in
  HEAD:some/path, it should use a slash instead.

Phil
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC/PATCH] Fix path prefixing in grep_object

[Phil Hord]

When the pathspec given to grep includes a tree name, the full
name of matched files is assembled using colon as a separator.
If the pathspec includes a tree name, it should use a slash
instead.

Check if the pathspec already names a tree and ref (including
a colon) and use a slash if so.
---

I'm not sure about the detection I used here.  It works, but it is
not terribly robust.  Is there a better way to handle this?  Maybe
something like 'prefix_pathspec(name,"");'.

 builtin/grep.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/builtin/grep.c b/builtin/grep.c
index 03bc442..d0deae4 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -480,8 +480,9 @@ static int grep_object(struct grep_opt *opt, const struct 
pathspec *pathspec,
len = name ? strlen(name) : 0;
strbuf_init(&base, PATH_MAX + len + 1);
if (len) {
+   int has_colon = !!strchr(name,':');
strbuf_add(&base, name, len);
-   strbuf_addch(&base, ':');
+   strbuf_addch(&base, has_colon?'/':':');
}
init_tree_desc(&tree, data, size);
hit = grep_tree(opt, pathspec, &tree, &base, base.len,
-- 
1.8.4.557.g34b3a2e

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] t/t7106-reset-unborn-branch.sh: Add PERL prerequisite

[Jonathan Nieder]

Kacper Kornet wrote:

> Signed-off-by: Kacper Kornet 

Thanks.

Reviewed-by: Jonathan Nieder 

Here's a style cleanup on top.

-- >8 --
Subject: reset test: modernize style

Avoid command substitution and pipes to ensure that the exit status
from each git command is tested (and in particular that any segfaults
are caught).

Maintain the test setup (no commits, one file named "a", another named
"b") even after the last test, to make it easier to rearrange tests or
add new tests after the last in the future.

Signed-off-by: Jonathan Nieder 
---
 t/t7106-reset-unborn-branch.sh | 31 ---
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/t/t7106-reset-unborn-branch.sh b/t/t7106-reset-unborn-branch.sh
index 499cd88c..af00ab4d 100755
--- a/t/t7106-reset-unborn-branch.sh
+++ b/t/t7106-reset-unborn-branch.sh
@@ -11,7 +11,10 @@ test_expect_success 'setup' '
 test_expect_success 'reset' '
git add a b &&
git reset &&
-   test "$(git ls-files)" = ""
+
+   >expect &&
+   git ls-files >actual &&
+   test_cmp expect actual
 '
 
 test_expect_success 'reset HEAD' '
@@ -24,28 +27,42 @@ test_expect_success 'reset $file' '
rm .git/index &&
git add a b &&
git reset a &&
-   test "$(git ls-files)" = "b"
+
+   echo b >expect &&
+   git ls-files >actual &&
+   test_cmp expect actual
 '
 
 test_expect_success PERL 'reset -p' '
rm .git/index &&
git add a &&
-   echo y | git reset -p &&
-   test "$(git ls-files)" = ""
+   echo y >yes &&
+   git reset -p expect &&
+   git ls-files >actual &&
+   test_cmp expect actual
 '
 
 test_expect_success 'reset --soft is a no-op' '
rm .git/index &&
git add a &&
-   git reset --soft
-   test "$(git ls-files)" = "a"
+   git reset --soft &&
+
+   echo a >expect &&
+   git ls-files >actual &&
+   test_cmp expect actual
 '
 
 test_expect_success 'reset --hard' '
rm .git/index &&
git add a &&
+   test_when_finished "echo a >a" &&
git reset --hard &&
-   test "$(git ls-files)" = "" &&
+
+   >expect &&
+   git ls-files >actual &&
+   test_cmp expect actual &&
test_path_is_missing a
 '
 
-- 
1.8.4.rc4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] t/t3701-add-interactive.sh: Add PERL prerequisite

[Jonathan Nieder]

Kacper Kornet wrote:

> --- a/t/t3701-add-interactive.sh
> +++ b/t/t3701-add-interactive.sh
> @@ -330,7 +330,7 @@ test_expect_success PERL 'split hunk "add -p (edit)"' '
>   ! grep "^+15" actual
>  '
>  
> -test_expect_success 'patch mode ignores unmerged entries' '
> +test_expect_success PERL 'patch mode ignores unmerged entries' '

Mph.  This is a symptom of f0459319 (change from skip_all=* to prereq
skip, 2010-08-13), which hurt maintainability without much upside to
balance it.

I wonder if it would be easier to do something like the following
instead.

-- >8 --
Subject: add -i test: use skip_all instead of repeated PERL prerequisite

It is too easy to forget to add the PERL prerequisite for new
"add -i" tests, especially given that many people do not test with
NO_PERL so the missing prereq is not always noticed quickly.

The test had used the skip_all mechanism since 1b19ccd2 (2009-04-03)
but switched to explicit PERL prereqs in f0459319 (2010-10-13) in hope
of helping people see how many tests were skipped, perhaps to motivate
them to tweak their platform or tests to improve test coverage.  That
didn't pan out much in practice, so let's move back to the simpler
skip_all method.

Reported-by: Kacper Kornet 
Signed-off-by: Jonathan Nieder 
---
 t/t3701-add-interactive.sh | 76 +-
 1 file changed, 41 insertions(+), 35 deletions(-)

diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index 9fab25cc..9dc91d09 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -4,18 +4,24 @@ test_description='add -i basic tests'
 . ./test-lib.sh
 . "$TEST_DIRECTORY"/lib-prereq-FILEMODE.sh
 
-test_expect_success PERL 'setup (initial)' '
+if ! test_have_prereq PERL
+then
+   skip_all='skipping add -i tests, perl not available'
+   test_done
+fi
+
+test_expect_success 'setup (initial)' '
echo content >file &&
git add file &&
echo more >>file &&
echo lines >>file
 '
-test_expect_success PERL 'status works (initial)' '
+test_expect_success 'status works (initial)' '
git add -i output &&
grep "+1/-0 *+2/-0 file" output
 '
 
-test_expect_success PERL 'setup expected' '
+test_expect_success 'setup expected' '
 cat >expected 
output &&
! grep . output
 '
 
-test_expect_success PERL 'setup (commit)' '
+test_expect_success 'setup (commit)' '
echo baseline >file &&
git add file &&
git commit -m commit &&
@@ -47,12 +53,12 @@ test_expect_success PERL 'setup (commit)' '
echo more >>file &&
echo lines >>file
 '
-test_expect_success PERL 'status works (commit)' '
+test_expect_success 'status works (commit)' '
git add -i output &&
grep "+1/-0 *+2/-0 file" output
 '
 
-test_expect_success PERL 'setup expected' '
+test_expect_success 'setup expected' '
 cat >expected 
expected  diff &&
test_cmp expected diff
 '
 
-test_expect_success PERL 'setup patch' '
+test_expect_success 'setup patch' '
 cat >patch >fake_editor.sh <<\EOF &&
 mv -f "$1" oldpatch &&
@@ -113,26 +119,26 @@ EOF
test_set_editor "$(pwd)/fake_editor.sh"
 '
 
-test_expect_success PERL 'bad edit rejected' '
+test_expect_success 'bad edit rejected' '
git reset &&
(echo e; echo n; echo d) | git add -p >output &&
grep "hunk does not apply" output
 '
 
-test_expect_success PERL 'setup patch' '
+test_expect_success 'setup patch' '
 cat >patch 
patch .gitignore &&
echo changed >file &&
@@ -177,7 +183,7 @@ test_expect_success PERL 'skip files similarly as commit 
-a

Re: [PATCH 1/3] Make test "using invalid commit with -C" more strict

[Jonathan Nieder]

Kacper Kornet wrote:

> In the test 'using invalid commit with -C' git-commit would have failed
> even if the -C option  had been given the correct commit, as there was
> nothing to commit.

Good catch.

[...]
> --- a/t/t7501-commit.sh
> +++ b/t/t7501-commit.sh
> @@ -53,7 +53,10 @@ test_expect_success PERL 'can use paths with 
> --interactive' '
>  '
>  
>  test_expect_success 'using invalid commit with -C' '
> - test_must_fail git commit -C bogus
> + echo bong >file &&
> + git add file &&
> + test_must_fail git commit -C bogus &&
> + git reset

I guess to be pedantic this should say

echo bong >file &&
git add file &&
test_when_finished "git reset --hard" &&
test_must_fail git commit -C bogus

to avoid interfering with later tests even when this one fails and
the && prevents the 'git reset' from being executed.

With or without that change,
Reviewed-by: Jonathan Nieder 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Fixes for tests run without perl

[Jonathan Nieder]

Hi,

Kacper Kornet wrote:

> This is a set of fixes for problems found while running
> test suite without perl installed.

I don't think git ever supported that.  The PERL prerequisite
was to check for systems that did not have (a suitable) perl
at runtime, but perl is still pretty heavily used in tests.

I assume you do have perl installed and that these fixes are
from testing the NO_PERL=YesPlease case, which is valuable.
Thanks for working on this.

Now on to the patches.

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/13] Modernize user-manual

[Philip Oakley]

From: "Thomas Ackermann" 

Hi,

command output has changed for some commands in the last years,
so reflect this also in the user-manual. While doing so, fix some
minor
spelling, formatting and wording issues.

Further, some references and recommendations which nowadays might
only confuse and not help new Git users where removed. Also some
explanations where rephrased to IMHO make them easier to understand
for new users.


Since 1.8.3 we have had the ability to list the main Git Guides using
the 'git help -g' option, unfortunately the User Manual is not in a man
format, so it isn't listed within the help option.

Is it worth adjusting the User Manual formatting such that it could be
displayed as a man page? (which would also require a file name change
from user-manual.txt to git-user-manual.txt). Or create a new man page
helper `git-user-manual.txt` that would provide a follow-me link to the
current user manual?

Back at $gmane/216146 Junio noted that the git(1) man page does contain
onward links to the user manual, but I believe that users should be able
to get to it directly from a git command such as 'git help user-manual'.
Easy access makes it more likely to be read, in the same way that man 
pages are checked.


Philip



The last patch removes a lengthy paragraph which states that "git
prune"
(and "git fsck") should only be used in a quiescent repository.  The
man-page for "git prune" tells nothing about this. So either the
removal should be OK or we have to duplicate the warning paragraph
in the man-page of "git prune"?

[PATCH 01/13] Call it "Git User Manual" and remove reference to very
old Git version
[PATCH 02/13] Use current "detached HEAD" message
[PATCH 03/13] Use current output for "git repack"
[PATCH 04/13] Use "git merge" instead of "git pull ."
[PATCH 05/13] Fix some typos
[PATCH 06/13] Simplify "How to make a commit"
[PATCH 07/13] Improve description in "How to merge"
[PATCH 08/13] Improve section "Manipulating branches"
[PATCH 09/13] Improve section "Merge multiple trees"
[PATCH 10/13] Remove unnecessary historical note from "Object storage
format"
[PATCH 11/13] Remove obscure reference from "Examples"
[PATCH 12/13] Remove irrelevant reference from "Tying it all together"
[PATCH 13/13] "git prune" is safe now

Signed-off-by: Thomas Ackermann 


---
Thomas


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANNOUNCE] tig-1.2.1

[Jonas Fonseca]

Hello,

Due to a bug in the handling of submodules, here is a new release of
Tig. In addition to the bug fix, this new version reduces memory usage
and startup time of the main view and shows the blob size in the tree
view.

Note to packagers: the manual and manpage documentation files now live
inside the doc/ directory and and have .asciidoc as the extension. The
SITES file has been removed as its content has been merged into README.

What is Tig?


Tig is an ncurses-based text-mode interface for git. It functions mainly
as a Git repository browser, but can also assist in staging changes for
commit at chunk level and act as a pager for output from various Git
commands.

Resources
-

 - Homepage:http://jonas.nitro.dk/tig/
 - Manual:  http://jonas.nitro.dk/tig/manual.html
 - Tarballs:http://jonas.nitro.dk/tig/releases/
 - Git URL: git://github.com/jonas/tig.git 
 - Gitweb:  http://repo.or.cz/w/tig.git
 - Q&A: http://stackoverflow.com/questions/tagged/tig

Release notes
-
Incompatibilities:

 - Move manual and man pages to doc/ directory and rename AsciiDoc files
   to have .asciidoc as the extension to make them render on GitHub.

Improvements:

 - Show blob sizes in the tree view either as bytes or using binary unit
   prefixes. Example: `set show-file-size = units`. (GH #163)
 - Reduce main view memory usage and startup time, especially when revision
   graph rendering is disabled. (GH #160)

Bug fixes:

 - Fix submodule-related setup to check for non-zero return value from
   setenv(). (GH #188)

Change summary
--
The diffstat and log summary for changes made in this release.

 .gitignore |   18 +-
 BUGS   |4 +-
 INSTALL|   92 +++--
 Makefile   |   76 ++--
 NEWS   |   62 ++-
 README |   28 +-
 SITES  |7 -
 asciidoc.conf  |   65 ---
 contrib/announcement.sh|   11 +-
 contrib/aspell.dict|   18 +-
 contrib/config.make|   16 +
 contrib/config.make-Darwin |5 +
 contrib/tig.spec.in|6 +-
 contrib/update-release-docs.sh |6 +-
 doc/asciidoc.conf  |   65 +++
 doc/manual.asciidoc|  606 +
 doc/tig.1.asciidoc |  195 
 doc/tigmanual.7.asciidoc   |   20 +
 doc/tigrc.5.asciidoc   |  757 
 manual.txt |  604 -
 tig.1.txt  |  176 
 tig.c  |  333 +++
 tigmanual.7.txt|   20 -
 tigrc.5.txt|  736 ---
 24 files changed, 2119 insertions(+), 1807 deletions(-)

Dan Church (1):
  Fix man page install

Jonas Fonseca (19):
  Move documentation to doc directory
  Rework README to include the list of online resources
  Fix submodule-related setup to properly check setenv return value
  Fix path to sysconfdir-based gitconfig in tig(1)
  Fix HTML doc installation
  Ignore *.swp files and restrict to only ignore top-level config.make
  Add work-around for building manpages with Homebrew-based xmlto
  Improve the installation instructions
  Show blob sizes in the tree view
  Ignore generated HTML files in the whole tree
  Dynamically allocate commit titles to reduce memory usage
  Postpone ref list lookup to the draw phase
  Bypass all graph calls and memory allocations when the graph is disabled
  Free graph symbols when reloading the main view
  Remove the dont_free line struct flag in favor of custom help_done
  Fix regression that skipped commits with no messages
  Simplify the install goal and rename $(PROGS) to $(EXE)
  Use capitalized Git and Tig when talking about the systems in general
  tig-1.2.1

-- 
Jonas Fonseca
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

contrib/credential/netrc/git-credential-netrc: Use of uninitialized value in string

[Antoine Pelisse]

Hello,
I've tried to use the netrc credential with git-send-email
(v1.8.4-rc2), and I've had the following log (running with -d -v):

We were given search token protocol and value smtp
We were given search token host and value smtp.gmail.com:587
We were given search token username and value apeli...@gmail.com
Searching for host = smtp.gmail.com:587
Searching for password = (any value)
Searching for path = (any value)
Searching for protocol = smtp
Searching for username = apeli...@gmail.com
Using GPG to open /home/antoine/.authinfo.gpg: [gpg --decrypt
/home/antoine/.authinfo.gpg]

You need a passphrase to unlock the secret key for
user: "Antoine Pelisse "
2048-bit RSA key, ID DE2A8792, created 2010-12-31 (main key ID A066A853)

gpg: encrypted with 2048-bit RSA key, ID DE2A8792, created 2010-12-31
  "Antoine Pelisse "
compare host [smtp.gmail.com:587] to [smtp.gmail.com:587] (entry:
password=secret, username=apeli...@gmail.com, host=smtp.gmail.com:587)
OK: any value satisfies check password
OK: any value satisfies check path
Use of uninitialized value $_[2] in printf at
/home/antoine/code/git/contrib/credential/netrc/git-credential-netrc
line 419.
compare protocol [] to [smtp] (entry: password=secret,
username=apeli...@gmail.com, host=smtp.gmail.com:587)
Use of uninitialized value in string eq at
/home/antoine/code/git/contrib/credential/netrc/git-credential-netrc
line 378.

I can fix the problem by adding a "protocol smtp" to the matching
line, but I wonder why this would be necessary ? After all, if host
smtp.gmail.com:587 matches, do we need to match the protocol ?

Cheers,
Antoine
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] commit: search author pattern against mailmap

[Antoine Pelisse]

"git commit --author=$name" sets the author to one whose name
matches the given string from existing commits, when $name is not in
the "Name " format. However, it does not honor the mailmap
to use the canonical name for the author found this way.

Fix it by telling the logic to find a matching existing author to
honor the mailmap, and use the name and email after applying the
mailmap.

Signed-off-by: Antoine Pelisse 
---
 builtin/commit.c   |  7 ++-
 t/t4203-mailmap.sh | 11 +++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 10acc53..21e0f95 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -30,6 +30,7 @@
 #include "column.h"
 #include "sequencer.h"
 #include "notes-utils.h"
+#include "mailmap.h"
 
 static const char * const builtin_commit_usage[] = {
N_("git commit [options] [--] ..."),
@@ -935,6 +936,7 @@ static const char *find_author_by_nickname(const char *name)
struct rev_info revs;
struct commit *commit;
struct strbuf buf = STRBUF_INIT;
+   struct string_list mailmap = STRING_LIST_INIT_NODUP;
const char *av[20];
int ac = 0;
 
@@ -945,13 +947,16 @@ static const char *find_author_by_nickname(const char 
*name)
av[++ac] = buf.buf;
av[++ac] = NULL;
setup_revisions(ac, av, &revs, NULL);
+   revs.mailmap = &mailmap;
+   read_mailmap(revs.mailmap, NULL);
+
prepare_revision_walk(&revs);
commit = get_revision(&revs);
if (commit) {
struct pretty_print_context ctx = {0};
ctx.date_mode = DATE_NORMAL;
strbuf_release(&buf);
-   format_commit_message(commit, "%an <%ae>", &buf, &ctx);
+   format_commit_message(commit, "%aN <%aE>", &buf, &ctx);
return strbuf_detach(&buf, NULL);
}
die(_("No existing author found with '%s'"), name);
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index baa4685..4d715f0 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -470,4 +470,15 @@ test_expect_success 'Blame output (complex mapping)' '
test_cmp expect actual.fuzz
 '
 
+cat >expect <<\EOF
+Some Dude 
+EOF
+
+test_expect_success 'commit --author honors mailmap' '
+   test_must_fail git commit --author "nick" --allow-empty -meight &&
+   git commit --author "Some Dude" --allow-empty -meight &&
+   git show --pretty=format:"%an <%ae>%n" >actual &&
+   test_cmp expect actual
+'
+
 test_done
-- 
1.8.4.rc4.2.g8483dfa

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 18/24] read-cache: write index-v5

[Duy Nguyen]

On Sat, Aug 24, 2013 at 11:07 AM, Duy Nguyen  wrote:
> On Mon, Aug 19, 2013 at 2:42 AM, Thomas Gummerer  wrote:
>> Write the index version 5 file format to disk. This version doesn't
>> write the cache-tree data and resolve-undo data to the file.
>
> I keep having things to add after sending my emails. Now that we have
> all conflicted entries in file block, the conflict data block becomes
> optional, it functions exactly (I think) like resolve-undo extension,
> which makes me think it might make sense to make conflict data block
> an extension.
>
> If we make it so, we might want to move "cr" and "ncr" fields out of
> direntries. I don't see a solution yet, but I think it's interesting
> because future extensions might want to attach stuff to direntries,
> just like "cr"/"ncr" from conflict extension. We may want to think now
> how that might be done (and conflict extension is a good exercise to
> see how it works out)

And the solution is pretty obvious: keep resolve-undo extension as
_extension_ just like in v2 (and no "cr/ncr" in direntries). The only
difference is the time resolve-undo extension is updated: in v2, new
entries are added at remove_index_entry_at(), in v5 new entries are
added when new stage entries  are detected at write_index().
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to set tab size for hunks in “git add -p”?

[Янчарук Александр]

Thanks a lot!

That solution worked for me:
env TERM=linux setterm -regtabs 4

Best regards,
Alexander Yancharuk
a...@itvault.info 
On 23.08.2013 22:19, Antoine Pelisse wrote:

On Fri, Aug 23, 2013 at 7:28 PM, Янчарук Александр  wrote:

But those settings seems does not affect on |git add -p|. How to set tab
size for hunks in *git add -p* command?

That's because "git add -p" doesn't go through less/pager.
You can certainly change the tabs size for your terminal with "tabs -4" though.



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] git-remote-mediawiki: reset private ref after non-dumb push

[Matthieu Moy]

Felipe Contreras  writes:

> On Fri, Aug 23, 2013 at 3:25 AM, Matthieu Moy
>  wrote:
>
>> This is assuming you follow the scheme
>>
>>   git -> local repo for other vcs -> remote repo for other vcs
>>
>> which itself more or less assumes that the other VCS is a decentralized
>> VCS. I understand this is a good idea for hg or bzr remote helpers, but
>> not applicable for git-remote-mediawiki.
>
> A centralized repository is a subset of decentralized workflows.

Yes, a strict subset. You can't keep a local copy of a remote repository
with a centralized VCS, so the way to write remote-helpers for DVCS does
not apply for centralized VCS.

> I don't know if a dumb push is the right thing to do here, but
> supposing it is, you can still report non-fast-forward errors:

That would be really complicated, as you would need to check whether
non-fast forward errors are serious. The check is done on pull, and the
reason the check should be disabled is dumb push.

> https://github.com/felipec/git/commit/0f7f0a223d710d29a4f1a03fc27348a8690d8a19
> https://github.com/felipec/git/commit/b67a8914bc1bb3ad23591875611165b84135aaf9

Err, don't they apply when pushing? In my case, the non-fast forward
occurs on pull.

> If it's too much hassle to find non-fast-forward situations by
> yourself, then perhaps it would make sense to update the remote
> namespace only when a certain feature has been flagged.

How would I do that? The update to the remote namespace is done by Git,
not by the remote-helper.

OK, I'm now convinced that my solution is the right one. The
alternatives are far more complex and I still fail to see the benefits.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/13] "git prune" is safe now

[Thomas Ackermann]

According to the man-pages of "git prune" and "git fsck",
both are safe nowadays.

Signed-off-by: Thomas Ackermann 
---
 Documentation/user-manual.txt | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 08d8c91..29945d9 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3283,17 +3283,7 @@ state, you can just prune all unreachable objects:
 $ git prune
 
 
-and they'll be gone. But you should only run `git prune` on a quiescent
-repository--it's kind of like doing a filesystem fsck recovery: you
-don't want to do that while the filesystem is mounted.
-
-(The same is true of `git fsck` itself, btw, but since
-`git fsck` never actually *changes* the repository, it just reports
-on what it found, `git fsck` itself is never 'dangerous' to run.
-Running it while somebody is actually changing the repository can cause
-confusing and scary messages, but it won't actually do anything bad. In
-contrast, running `git prune` while somebody is actively changing the
-repository is a *BAD* idea).
+and they'll be gone. 
 
 [[recovering-from-repository-corruption]]
 Recovering from repository corruption
-- 
1.8.3.msysgit.0


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 12/13] Remove irrelevant reference from "Tying it all together"

[Thomas Ackermann]

Sorry Jon, but this might not be of any help to new Git users ;)

Signed-off-by: Thomas Ackermann 
---
 Documentation/user-manual.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 0d3f04e..08d8c91 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3908,8 +3908,7 @@ save the note about that state, in practice we tend to 
just write the
 result to the file pointed at by `.git/HEAD`, so that we can always see
 what the last committed state was.
 
-Here is an ASCII art by Jon Loeliger that illustrates how
-various pieces fit together.
+Here is a picture that illustrates how various pieces fit together:
 
 
 
-- 
1.8.3.msysgit.0


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/13] Remove obscure reference from "Examples"

[Thomas Ackermann]

Signed-off-by: Thomas Ackermann 
---
 Documentation/user-manual.txt | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index aa6bfab..0d3f04e 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2131,8 +2131,6 @@ He uses two public branches:
 
  - A "test" tree into which patches are initially placed so that they
can get some exposure when integrated with other ongoing development.
-   This tree is available to Andrew for pulling into -mm whenever he
-   wants.
 
  - A "release" tree into which tested patches are moved for final sanity
checking, and as a vehicle to send them upstream to Linus (by sending
-- 
1.8.3.msysgit.0


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/13] Remove unnecessary historical note from "Object storage format"

[Thomas Ackermann]

Signed-off-by: Thomas Ackermann 
---
 Documentation/user-manual.txt | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index f713f26..aa6bfab 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -4132,8 +4132,6 @@ about the data in the object.  It's worth noting that the 
SHA-1 hash
 that is used to name the object is the hash of the original data
 plus this header, so `sha1sum` 'file' does not match the object name
 for 'file'.
-(Historical note: in the dawn of the age of Git the hash
-was the SHA-1 of the 'compressed' object.)
 
 As a result, the general consistency of an object can always be tested
 independently of the contents or the type of the object: all objects can
-- 
1.8.3.msysgit.0


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/13] Improve section "Merge multiple trees"

[Thomas Ackermann]

Remove unnecessary quoting.
Simplify description of three-way merge.

Signed-off-by: Thomas Ackermann 
---
 Documentation/user-manual.txt | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d5baf03..f713f26 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3992,16 +3992,16 @@ Merging multiple trees
 
 Git helps you do a three-way merge, which you can expand to n-way by
 repeating the merge procedure arbitrary times until you finally
-"commit" the state.  The normal situation is that you'd only do one
+commit the state.  The normal situation is that you'd only do one
 three-way merge (two parents), and commit it, but if you like to, you
 can do multiple parents in one go.
 
-To do a three-way merge, you need the two sets of "commit" objects
+To do a three-way merge, you need the two commit objects
 that you want to merge, use those to find the closest common parent (a
-third "commit" object), and then use those commit objects to find the
-state of the directory ("tree" object) at these points.
+third commit object: the merge base), and then use those commit objects to 
find the
+state of the directory (i.e. tree object) at these points.
 
-To get the "base" for the merge, you first look up the common parent
+To get the base for the merge, you first look up the common parent
 of two commits with
 
 -
@@ -4009,8 +4009,8 @@ $ git merge-base  
 -
 
 which will return you the commit they are both based on.  You should
-now look up the "tree" objects of those commits, which you can easily
-do with (for example)
+now look up the tree objects of those commits, which you can easily
+do with
 
 -
 $ git cat-file commit  | head -1
-- 
1.8.3.msysgit.0


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/13] Improve section "Manipulating branches"

[Thomas Ackermann]

Add some missing punctuation.
Simplify description of "git branch -d/-D".

Signed-off-by: Thomas Ackermann 
---
 Documentation/user-manual.txt | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 0656191..d5baf03 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -268,27 +268,22 @@ Creating, deleting, and modifying branches is quick and 
easy; here's
 a summary of the commands:
 
 `git branch`::
-   list all branches
+   list all branches.
 `git branch `::
create a new branch named ``, referencing the same
-   point in history as the current branch
+   point in history as the current branch.
 `git branch  `::
create a new branch named ``, referencing
``, which may be specified any way you like,
-   including using a branch name or a tag name
+   including using a branch name or a tag name.
 `git branch -d `::
-   delete the branch ``; if the branch you are deleting
-   points to a commit which is not reachable from the current
-   branch, this command will fail with a warning.
+   delete the branch ``; if the branch is not fully
+   merged in its upstream branch, this command will fail with a warning.
 `git branch -D `::
-   even if the branch points to a commit not reachable
-   from the current branch, you may know that that commit
-   is still reachable from some other branch or tag.  In that
-   case it is safe to use this command to force Git to delete
-   the branch.
+   delete the branch `` irrespective of its merged status.
 `git checkout `::
make the current branch ``, updating the working
-   directory to reflect the version referenced by ``
+   directory to reflect the version referenced by ``.
 `git checkout -b  `::
create a new branch `` referencing ``, and
check it out.
-- 
1.8.3.msysgit.0


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/13] Improve description in "How to merge"

[Thomas Ackermann]

Describe the conflict resolution in terms of the
commands the user is supposed to use.

Signed-off-by: Thomas Ackermann 
---
 Documentation/user-manual.txt | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index ccbddc7..0656191 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1251,10 +1251,8 @@ Automatic merge failed; fix conflicts and then commit 
the result.
 -
 
 Conflict markers are left in the problematic files, and after
-you resolve the conflicts manually, you can update the index
-with the contents and run Git commit, as you normally would when
-creating a new file.
-
+you have resolved the conflicts manually, you can `git add` the
+new contents and do a `git commit` in the end.
 If you examine the resulting commit using gitk, you will see that it
 has two parents, one pointing to the top of the current branch, and
 one to the top of the other branch.
-- 
1.8.3.msysgit.0


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/13] Simplify "How to make a commit"

[Thomas Ackermann]

Combine the two cases for "git add" into one.
Add verb "use" to "git rm" case.

Signed-off-by: Thomas Ackermann 
---
 Documentation/user-manual.txt | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 8a1a441..ca78333 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1080,19 +1080,14 @@ produce no output at that point.
 
 Modifying the index is easy:
 
-To update the index with the new contents of a modified file, use
+To add the contents of a new file to the index or update the index 
+with the new contents of a modified file, use
 
 -
 $ git add path/to/file
 -
 
-To add the contents of a new file to the index, use
-
--
-$ git add path/to/file
--
-
-To remove a file from the index and from the working tree,
+To remove a file from the index and from the working tree, use
 
 -
 $ git rm path/to/file
-- 
1.8.3.msysgit.0


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/13] Fix some typos

[Thomas Ackermann]

Signed-off-by: Thomas Ackermann 
---
 Documentation/user-manual.txt | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index ca78333..ccbddc7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -219,7 +219,7 @@ of development leading to that point.
 
 The best way to see how this works is using the linkgit:gitk[1]
 command; running gitk now on a Git repository and looking for merge
-commits will help understand how the Git organizes history.
+commits will help understand how Git organizes history.
 
 In the following, we say that commit X is "reachable" from commit Y
 if commit X is an ancestor of commit Y.  Equivalently, you could say
@@ -793,7 +793,7 @@ e05db0fd4f31dde7005f075a84f96b360d05984b
 -
 
 Or you could recall that the `...` operator selects all commits
-contained reachable from either one reference or the other but not
+reachable from either one reference or the other but not
 both; so
 
 -
@@ -820,7 +820,7 @@ You could just visually inspect the commits since e05db0fd:
 $ gitk e05db0fd..
 -
 
-Or you can use linkgit:git-name-rev[1], which will give the commit a
+or you can use linkgit:git-name-rev[1], which will give the commit a
 name based on any tag it finds pointing to one of the commit's
 descendants:
 
@@ -3525,7 +3525,7 @@ with Git 1.5.2 can look up the submodule commits in the 
repository and
 manually check them out; earlier versions won't recognize the submodules at
 all.
 
-To see how submodule support works, create (for example) four example
+To see how submodule support works, create four example
 repositories that can be used later as a submodule:
 
 -
@@ -3897,7 +3897,7 @@ fact that such a commit brings together ("merges") two or 
more
 previous states represented by other commits.
 
 In other words, while a "tree" represents a particular directory state
-of a working directory, a "commit" represents that state in "time",
+of a working directory, a "commit" represents that state in time,
 and explains how we got there.
 
 You create a commit object by giving it the tree that describes the
-- 
1.8.3.msysgit.0


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/13] Use "git merge" instead of "git pull ."

[Thomas Ackermann]

"git pull ." works, but "git merge" is the recommended
way for new users to do things. (The old description 
also should have read "The former is actually *not* very
commonly used".)

Signed-off-by: Thomas Ackermann 
---
 Documentation/user-manual.txt | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index b450980..8a1a441 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1784,17 +1784,6 @@ repository that you pulled from.
 <>; instead, your branch will just be
 updated to point to the latest commit from the upstream branch.)
 
-The `git pull` command can also be given `.` as the "remote" repository,
-in which case it just merges in a branch from the current repository; so
-the commands
-
--
-$ git pull . branch
-$ git merge branch
--
-
-are roughly equivalent.  The former is actually very commonly used.
-
 [[submitting-patches]]
 Submitting patches to a project
 ---
@@ -2259,7 +2248,7 @@ When you are happy with the state of this change, you can 
pull it into the
 "test" branch in preparation to make it public:
 
 -
-$ git checkout test && git pull . speed-up-spinlocks
+$ git checkout test && git merge speed-up-spinlocks
 -
 
 It is unlikely that you would have any conflicts here ... but you might if you
@@ -2271,7 +2260,7 @@ see the value of keeping each patch (or patch series) in 
its own branch.  It
 means that the patches can be moved into the `release` tree in any order.
 
 -
-$ git checkout release && git pull . speed-up-spinlocks
+$ git checkout release && git merge speed-up-spinlocks
 -
 
 After a while, you will have a number of branches, and despite the
-- 
1.8.3.msysgit.0


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/13] Use current output for "git repack"

[Thomas Ackermann]

Signed-off-by: Thomas Ackermann 
---
 Documentation/user-manual.txt | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index cb30929..b450980 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3203,14 +3203,11 @@ To put the loose objects into a pack, just run git 
repack:
 
 
 $ git repack
-Generating pack...
-Done counting 6020 objects.
-Deltifying 6020 objects.
- 100% (6020/6020) done
-Writing 6020 objects.
- 100% (6020/6020) done
-Total 6020, written 6020 (delta 4070), reused 0 (delta 0)
-Pack pack-3e54ad29d5b2e05838c75df582c65257b8d08e1c created.
+Counting objects: 6020, done.
+Delta compression using up to 4 threads.
+Compressing objects: 100% (6020/6020), done.
+Writing objects: 100% (6020/6020), done.
+Total 6020 (delta 4070), reused 0 (delta 0)
 
 
 You can then run
-- 
1.8.3.msysgit.0


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/13] Use current "detached HEAD" message

[Thomas Ackermann]

Signed-off-by: Thomas Ackermann 
---
 Documentation/user-manual.txt | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 103ec9a..cb30929 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -312,10 +312,17 @@ referenced by a tag:
 
 
 $ git checkout v2.6.17
-Note: moving to "v2.6.17" which isn't a local branch
-If you want to create a new branch from this checkout, you may do so
-(now or later) by using -b with the checkout command again. Example:
-  git checkout -b 
+Note: checking out 'v2.6.17'.
+
+You are in 'detached HEAD' state. You can look around, make experimental
+changes and commit them, and you can discard any commits you make in this
+state without impacting any branches by performing another checkout.
+
+If you want to create a new branch to retain commits you create, you may
+do so (now or later) by using -b with the checkout command again. Example:
+
+  git checkout -b new_branch_name
+
 HEAD is now at 427abfa... Linux v2.6.17
 
 
@@ -326,7 +333,7 @@ and git branch shows that you are no longer on a branch:
 $ cat .git/HEAD
 427abfa28afedffadfca9dd8b067eb6d36bac53f
 $ git branch
-* (no branch)
+* (detached from v2.6.17)
   master
 
 
-- 
1.8.3.msysgit.0


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/13] Call it "Git User Manual" and remove reference to very old Git version

[Thomas Ackermann]

Signed-off-by: Thomas Ackermann 
---
 Documentation/user-manual.txt | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index fe723e4..103ec9a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1,6 +1,5 @@
-Git User's Manual (for version 1.5.3 or newer)
-__
-
+Git User Manual
+___
 
 Git is a fast distributed revision control system.
 
-- 
1.8.3.msysgit.0


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/13] Modernize user-manual

[Thomas Ackermann]

Hi,

command output has changed for some commands in the last years,
so reflect this also in the user-manual. While doing so, fix some minor 
spelling, formatting and wording issues.

Further, some references and recommendations which nowadays might 
only confuse and not help new Git users where removed. Also some 
explanations where rephrased to IMHO make them easier to understand
for new users.

The last patch removes a lengthy paragraph which states that "git prune" 
(and "git fsck") should only be used in a quiescent repository.  The 
man-page for "git prune" tells nothing about this. So either the 
removal should be OK or we have to duplicate the warning paragraph 
in the man-page of "git prune"?

[PATCH 01/13] Call it "Git User Manual" and remove reference to very old Git 
version
[PATCH 02/13] Use current "detached HEAD" message
[PATCH 03/13] Use current output for "git repack"
[PATCH 04/13] Use "git merge" instead of "git pull ."
[PATCH 05/13] Fix some typos
[PATCH 06/13] Simplify "How to make a commit"
[PATCH 07/13] Improve description in "How to merge"
[PATCH 08/13] Improve section "Manipulating branches"
[PATCH 09/13] Improve section "Merge multiple trees"
[PATCH 10/13] Remove unnecessary historical note from "Object storage format"
[PATCH 11/13] Remove obscure reference from "Examples"
[PATCH 12/13] Remove irrelevant reference from "Tying it all together"
[PATCH 13/13] "git prune" is safe now

Signed-off-by: Thomas Ackermann 


---
Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html