* [PATCH] git-subtree: ignore git-subtree executable
From: Michael Schubert @ 2012-12-22 14:45 UTC (permalink / raw)
To: git
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
---
contrib/subtree/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/subtree/.gitignore b/contrib/subtree/.gitignore
index 7e77c9d..91360a3 100644
--- a/contrib/subtree/.gitignore
+++ b/contrib/subtree/.gitignore
@@ -1,4 +1,5 @@
*~
+git-subtree
git-subtree.xml
git-subtree.1
mainline
--
1.8.1.rc2.333.g912e06f.dirty
^ permalink raw reply related
* [PATCH] git-subtree: fix typo in manpage
From: Michael Schubert @ 2012-12-22 14:46 UTC (permalink / raw)
To: git
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
---
contrib/subtree/git-subtree.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
index 0c44fda..c5bce41 100644
--- a/contrib/subtree/git-subtree.txt
+++ b/contrib/subtree/git-subtree.txt
@@ -93,7 +93,7 @@ pull::
repository.
push::
- Does a 'split' (see above) using the <prefix> supplied
+ Does a 'split' (see below) using the <prefix> supplied
and then does a 'git push' to push the result to the
repository and refspec. This can be used to push your
subtree to different branches of the remote repository.
--
1.8.1.rc2.333.g912e06f.dirty
^ permalink raw reply related
* Re: Change in cvsps maintainership, abd a --fast-export option
From: Andreas Schwab @ 2012-12-22 16:25 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: esr, Heiko Voigt, Michael Haggerty, git
In-Reply-To: <CALWbr2zZFq_9qa+pTx3nYn+KFv61LrSMcNM4N1Xs5cmnr8teXg@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> I guess 'w' means write
No, 'w' mean gitweb.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Michael J Gruber @ 2012-12-22 16:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Yann Dirson, Andreas Schwab, Christian Couder,
git list, Jeff King
In-Reply-To: <7vzk171gvh.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 21.12.2012 17:58:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> While replace refs are much more general than grafts, it seems the two
>> main uses are:
>>
>> - grafts (change the recorded parents for a commit)
>> - svn cleanup (convert tagging commits into tag objects)
>>
>> The latter one being quite a special case already.
>>
>> The script below has helped me move from grafts to replace objects.
>> While not being super clean, something like it may be fit for contrib.
>>
>> I think we ought to help John Doe get along with parents, while we can
>> safely leave most more advanced operations to people who know how to
>> edit a raw object file. Putting that facility into "git-commit" seems to
>> be too encouraging, though - people would use replace when they should
>> use amend or rebase-i. I'd prefer a special git-replace mode (be it
>> "--graft" or "--graft-commit") which does just what my script does. We
>> could add things like "--commit-tag" later, a full blown
>> "object-factory" seems like overkill.
>>
>> Michael
>>
>> --->%---
>>
>> #!/bin/sh
>>
>> die () {
>> echo "$@"
>> rm -f "$commitfile"
>> exit 1
>> }
>>
>> warn () {
>> echo "$@"
>> }
>>
>> test $# -gt 0 || die "Usage: $0 <commit> [<parent>]*"
>>
>> for commit
>> do
>> git rev-parse --verify -q "$commit" >/dev/null || die "Cannot parse
>> $commit."
>> test x$(git cat-file -t $commit) == "xcommit" || die "$commit is no
>> commit."
>
> s/==/=/ or you have to say #!/bin/bash on the first line, I think.
> Appears multiple times throughout this script.
>
>
>> done
>>
>> commit="$1"
>> shift
>>
>> commitfile=$(mktemp)
>>
>> git cat-file commit "$commit" | while read a b
>> do
>> if test "$a" != "parent"
>> then
>> echo $a $b
>
> You are losing information on non-header lines by reading without
> "-r" in the above, and also multi-line headers (e.g. mergetag),
> aren't you?
>
Oh yes, it has bashisms and imperfections. It's not a submitted patch,
not even RFC. It's meant to show the git-replace mode that many users
could benefit from: works for commits only and replaces the parent list,
but takes any rev arguments as the new parents, rather than forcing the
user to specify a full sha1.
>> fi
>> if test "$a" == "tree"
>> then
>> for parent
>> do
>> echo "parent $(git rev-parse $parent)"
>> done
>> fi
>> done >$commitfile
>> hash=$(git hash-object -t commit -w "$commitfile") || die "Cannot create
>> commit object."
>> git replace "$commit" $hash
>> rm -f $commitfile
^ permalink raw reply
* Re: Opera release Git-splitter, a sub-modularizing tool for Git
From: Michael J Gruber @ 2012-12-22 16:41 UTC (permalink / raw)
To: Yngve Nysaeter Pettersen; +Cc: Matthieu Moy, git
In-Reply-To: <op.wpontloxvqd7e2@damia.oslo.osa>
Yngve Nysaeter Pettersen venit, vidit, dixit 21.12.2012 21:13:
> On Fri, 21 Dec 2012 16:49:21 +0100, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>
>> "Yngve Nysaeter Pettersen" <yngve@opera.com> writes:
>>
>>> The split command will create a new repository for all files foo in a
>>> folder (path/foo) and their commit history.
>>>
>>> The replant command reverses that process, re-adding the path prefix
>>> for each file. It may be possible to extend that process into one that
>>> automatically reintegrates the new commits in the original history,
>>> but I never had time to complete that work.
>>>
>>> I did originally add the "replant" functionality into my version of
>>> the git-subtree script, but given the number of commits in the
>>> original repository, git-subtree turned out to be inefficient, due to
>>> the use of temporary files (tens of thousands of files IIRC).
>>>
>>> Those problems led to my development of git-splitter in Python
>>> (bypassing the problem of temporary files), but just including the
>>> functionality I needed, join was not one of those functions.
>>
>> That still doesn't answer the question: why did you need to write a new
>> tool instead of extending git-subtree?
>
> The primary problem with git-subtree was that I ended up with a temporary
> file directory containing 100+K files, which I tracked back to being used
> to manage the commit-to-tree mapping. On Windows, at least, that literally
> slowed down the process to a crawl.
>
>> If one doesn't use "replant", is your tool different from git-subtree?
>
> No, it is not different. However, my tool will use RAM, not diskspace to
> manage information.
That is some valuable input. It can help improve git-subtree for Windows
users, or replace it by something else.
Michael
^ permalink raw reply
* [PATCH 0/2] Mailmap in log improvements
From: Antoine Pelisse @ 2012-12-22 16:58 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
The goal of these patches are to:
- allow the use of mailmap when looking for commits
authored/committed by a mapped name/email.
- add an option so that --use-mailmap option can be used
automatically.
Tests are included.
This series is based on ap/log-mailmap.
Antoine Pelisse (2):
log: grep author/committer using mailmap
log: add log.mailmap configuration option
Documentation/config.txt | 4 ++++
builtin/log.c | 8 ++++++-
revision.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++
t/t4203-mailmap.sh | 42 ++++++++++++++++++++++++++++++++++++
4 files changed, 106 insertions(+), 1 deletion(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 2/2] log: add log.mailmap configuration option
From: Antoine Pelisse @ 2012-12-22 16:58 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1356195512-4846-1-git-send-email-apelisse@gmail.com>
This patch provides a new configuration option 'log.mailmap' to
automatically use the --use-mailmap option from git-show, git-log and
git-whatchanged commands.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
I'm wondering if it would be needed to add a no-use-mailmap option to
log command so that it can cancel this configuration option.
Documentation/config.txt | 4 ++++
builtin/log.c | 8 +++++++-
t/t4203-mailmap.sh | 24 ++++++++++++++++++++++++
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bf8f911..226362a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1509,6 +1509,10 @@ log.showroot::
Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
normally hide the root commit will now show it. True by default.
+log.mailmap::
+ If true, makes linkgit:git-log[1], linkgit:git-show[1], and
+ linkgit:git-whatchanged[1] assume `--use-mailmap`.
+
mailmap.file::
The location of an augmenting mailmap file. The default
mailmap, located in the root of the repository, is loaded
diff --git a/builtin/log.c b/builtin/log.c
index d2bd8ce..f6936ff 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -31,6 +31,7 @@ static int default_abbrev_commit;
static int default_show_root = 1;
static int decoration_style;
static int decoration_given;
+static int use_mailmap;
static const char *fmt_patch_subject_prefix = "PATCH";
static const char *fmt_pretty;
@@ -138,7 +139,7 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix,
if (source)
rev->show_source = 1;
- if (mailmap) {
+ if (mailmap || use_mailmap) {
rev->mailmap = xcalloc(1, sizeof(struct string_list));
read_mailmap(rev->mailmap, NULL);
}
@@ -358,6 +359,11 @@ static int git_log_config(const char *var, const char *value, void *cb)
}
if (!prefixcmp(var, "color.decorate."))
return parse_decorate_color_config(var, 15, value);
+ if (!strcmp(var, "log.mailmap")) {
+ use_mailmap = git_config_bool(var, value);
+ return 0;
+ }
+
if (grep_config(var, value, cb) < 0)
return -1;
return git_diff_ui_config(var, value, cb);
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index e16187f..7d4d31c 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -255,6 +255,21 @@ test_expect_success 'Log output with --use-mailmap' '
'
cat >expect <<\EOF
+Author: CTO <cto@company.xx>
+Author: Santa Claus <santa.claus@northpole.xx>
+Author: Santa Claus <santa.claus@northpole.xx>
+Author: Other Author <other@author.xx>
+Author: Other Author <other@author.xx>
+Author: Some Dude <some@dude.xx>
+Author: A U Thor <author@example.com>
+EOF
+
+test_expect_success 'Log output with log.mailmap' '
+ git -c log.mailmap=True log | grep Author >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<\EOF
Author: Santa Claus <santa.claus@northpole.xx>
Author: Santa Claus <santa.claus@northpole.xx>
EOF
@@ -263,6 +278,15 @@ test_expect_success 'Grep author with --use-mailmap' '
git log --use-mailmap --author Santa | grep Author >actual &&
test_cmp expect actual
'
+cat >expect <<\EOF
+Author: Santa Claus <santa.claus@northpole.xx>
+Author: Santa Claus <santa.claus@northpole.xx>
+EOF
+
+test_expect_success 'Grep author with log.mailmap' '
+ git -c log.mailmap=True log --author Santa | grep Author >actual &&
+ test_cmp expect actual
+'
>expect
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] log: grep author/committer using mailmap
From: Antoine Pelisse @ 2012-12-22 16:58 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1356195512-4846-1-git-send-email-apelisse@gmail.com>
Currently mailmap can be used to display log authors and committers
but there no way to use mailmap to find commits with mapped values.
This commit allows those commands to work:
git log --use-mailmap --author mapped_name_or_email
git log --use-mailmap --committer mapped_name_or_email
Of course it only works if the --use-mailmap option is used.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
I probably missed something but I didn't find the connection with
commit 2d10c55. Let me know if I went the wrong direction.
revision.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++++
t/t4203-mailmap.sh | 18 ++++++++++++++++++
2 files changed, 71 insertions(+)
diff --git a/revision.c b/revision.c
index 95d21e6..fb9fd41 100644
--- a/revision.c
+++ b/revision.c
@@ -13,6 +13,7 @@
#include "decorate.h"
#include "log-tree.h"
#include "string-list.h"
+#include "mailmap.h"
volatile show_early_output_fn_t show_early_output;
@@ -2219,6 +2220,50 @@ static int rewrite_parents(struct rev_info *revs, struct commit *commit)
return 0;
}
+static int commit_rewrite_authors(struct strbuf *buf, const char *what, struct string_list *mailmap)
+{
+ char *author, *endp;
+ size_t len;
+ struct strbuf name = STRBUF_INIT;
+ struct strbuf mail = STRBUF_INIT;
+ struct ident_split ident;
+
+ author = strstr(buf->buf, what);
+ if (!author)
+ goto error;
+
+ author += strlen(what);
+ endp = strstr(author, "\n");
+ if (!endp)
+ goto error;
+
+ len = endp - author;
+
+ if (split_ident_line(&ident, author, len)) {
+ error:
+ strbuf_release(&name);
+ strbuf_release(&mail);
+
+ return 1;
+ }
+
+ strbuf_add(&name, ident.name_begin, ident.name_end - ident.name_begin);
+ strbuf_add(&mail, ident.mail_begin, ident.mail_end - ident.mail_begin);
+
+ map_user(mailmap, &mail, &name);
+
+ strbuf_addf(&name, " <%s>", mail.buf);
+
+ strbuf_splice(buf, ident.name_begin - buf->buf,
+ ident.mail_end - ident.name_begin + 1,
+ name.buf, name.len);
+
+ strbuf_release(&name);
+ strbuf_release(&mail);
+
+ return 0;
+}
+
static int commit_match(struct commit *commit, struct rev_info *opt)
{
int retval;
@@ -2237,6 +2282,14 @@ static int commit_match(struct commit *commit, struct rev_info *opt)
if (buf.len)
strbuf_addstr(&buf, commit->buffer);
+ if (opt->mailmap) {
+ if (!buf.len)
+ strbuf_addstr(&buf, commit->buffer);
+
+ commit_rewrite_authors(&buf, "\nauthor ", opt->mailmap);
+ commit_rewrite_authors(&buf, "\ncommitter ", opt->mailmap);
+ }
+
/* Append "fake" message parts as needed */
if (opt->show_notes) {
if (!buf.len)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index db043dc..e16187f 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -248,11 +248,29 @@ Author: Other Author <other@author.xx>
Author: Some Dude <some@dude.xx>
Author: A U Thor <author@example.com>
EOF
+
test_expect_success 'Log output with --use-mailmap' '
git log --use-mailmap | grep Author >actual &&
test_cmp expect actual
'
+cat >expect <<\EOF
+Author: Santa Claus <santa.claus@northpole.xx>
+Author: Santa Claus <santa.claus@northpole.xx>
+EOF
+
+test_expect_success 'Grep author with --use-mailmap' '
+ git log --use-mailmap --author Santa | grep Author >actual &&
+ test_cmp expect actual
+'
+
+>expect
+
+test_expect_success 'Only grep replaced author with --use-mailmap' '
+ git log --use-mailmap --author "<cto@coompany.xx>" >actual &&
+ test_cmp expect actual
+'
+
# git blame
cat >expect <<\EOF
^OBJI (A U Thor DATE 1) one
--
1.7.9.5
^ permalink raw reply related
* cvsps, parsecvs, svn2git and the CVS exporter mess
From: Eric S. Raymond @ 2012-12-22 17:36 UTC (permalink / raw)
To: Yann Dirson, Michael Haggerty, Heiko Voigt, Antoine Pelisse,
Bart Massey, Keith Packard, David Mansfield, git
Wanting reposurgeon to be able to read CVS repositories has landed me
in the middle of a mess. This note explains my thinking, what I
intend to do to fix the mess, and how others can help if they are
motivated. I have copied all the individuals who I know have an
interest in the problem, and the git list because what I'm planning is
going to be significant for them.
My requirement is not complicated to describe. For use as a
reposurgeon front end I need a tool that is basically a
cvs-fast-export, runnable in either a CVS repository or a checkout
(either will do, both is not required) and emitting a fast-import
stream.
There are three competing tools that might fit this bill.
* One is Michael Haggerty's cvs2git. I had bad experiences with the
cvs2svn code it's derived from in the past, but Michael believes those
problems have been fixed and I will accept that - at least until I can
test for myself. Its documented interface is not quite good enough
yet; as the documentation says, "The data that should be fed to git
fast-import are written to two files, which have to be loaded into git
fast-import manually."
* Another is the cvsps code formerly maintained by David Mansfield and
used by git-cvsimport; he passed the maintainer's baton to me, and I
have shipped a 3.0 with a working --fast-export option.
* A third is parsecvs, which Keith Packard and Bart Massey handed off
to me a week before David invited me to take over cvsps. While
parsecvs does not yet have a --fast-export option, I anticipate no
great difficulty in adding one.
It is pure accident that I now maintain two of these. Initially I
was interested in parsecvs, but it failed to build for me. By the
time Bart Massey sent me a fix patch, I had already been handed
cvsps, added --fast-export, and shipped 3.0.
Having three different tools for this job seems to me duplicative and
pointless; two of them should probably be let die an honorable death.
I don't actually care which of the three survives - and, in
particular, if I determine that cvs2git is doing the best job of the
three I am quite willing to declare end-of-life for cvsps and
parsecvs. It's not like I don't have plenty of other projects to work
on.
Therefore, I think my main focus needs to be developing a really
effective test suite to triage these tools with and applying it to all
three. I have already made a solid start on this; see
tests/cvstest.py and tests/basic.tst in the cvsps-3.0 distribution for
my test framework.
I presently know of three test suites other than mine. One was built
by Heiko to test cvsps, another lives in the git t/ directory, and the
third is cvs2git's. I haven't looked at cv2git's yet, but the others
are not in their present form suited to where I am taking cvsps and
parsecvs. Heiko's relies on the default human-readable cvsps format,
which I consider obsolete and uninteresting. The git tests are
dependent on details of porcelain behavior. I think it would be
better to test import-stream output.
Here is what I propose. Let's build a common test suite that cvs2git,
git-cvsimport, cvsps, and parsecvs can all use, apply it rigorously,
and let the best tool win. (This would mean, among other things, that
git can stop carrying things that are essentially cvsps tests in its
tree.)
The two people I most need to sign off on this are, I guess, Michael
Haggerty and either Junio Hamano or whoever specifically owns
git-cvsimport and its tests. Whichever way this comes out, the back
end of git-cvsimport is going to need some work - I don't plan to put
any further effort into the output format it's presently using.
If we can agree on this, I'll start a public repo, and contribute my
Python framework - it's more capable than any of the shell harnesses
out there because it can easily drive interleaved operations on multiple
checkout directories.
Anybody who is still interested in this problem should contribute
tests. Heiko Voigt, I'd particularly like you in on this. David
Mansfield, if you can spare the few minutes required to write
generators for the "funky" and "invalid" tag cases, that would be
really helpful. Michael Haggerty, your piece would be moving the
cvs2git tests to the new framework.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
The kind of charity you can force out of people nourishes about as much as
the kind of love you can buy --- and spreads even nastier diseases.
^ permalink raw reply
* Re: Right way to import a repo
From: Michael J Gruber @ 2012-12-22 17:57 UTC (permalink / raw)
To: Florian Lindner; +Cc: git
In-Reply-To: <1530104.jO5zzzN8PS@horus>
Florian Lindner venit, vidit, dixit 21.12.2012 17:11:
> Hello,
>
> I have two repositories. tools and flof. I want to merge flof into tools (and
> flof will be deleted after that) while keeping history intact. Of course I've
> googled that and found a number of different solution which all seem to be
> pretty komplex, so I just tried it myself. It seems to work.... are there any
> problems with my approach?
>
> ~/software/tools.test (git)-[master] % git remote add fl ~/flof
>
> ~/software/tools.test (git)-[master] % git fetch fl
> warning: no common commits
> remote: Counting objects: 475, done.
> remote: Compressing objects: 100% (460/460), done.
> remote: Total 475 (delta 251), reused 0 (delta 0)
> Receiving objects: 100% (475/475), 190.40 KiB, done.
> Resolving deltas: 100% (251/251), done.
> From /home/florian/flof
> * [new branch] master -> fl/master
> * [new branch] v2-rewrite -> fl/v2-rewrite
>
Two disjoint histories, nothing wrong with that.
> /software/tools.test (git)-[master] % git checkout -b import fl/master
> Branch import set up to track remote branch master from fl.
> Switched to a new branch 'import'
>
> Doing some mkdir und git mv for reorganisation.
Here avoid possible problems from both projects using the same root (in
the filesystem/tree sense).
> ~/software/tools.test/flof (git)-[import] % git commit -m "Reorganize flof."
> [import a00ab54] Reorganize flof.
> 152 files changed, 0 insertions(+), 0 deletions(-)
> rename {doc => flof/doc}/common.rst (100%)
> rename {doc => flof/doc}/conf.py (100%)
> [...]
>
> ~/software/tools.test/flof (git)-[import] % git checkout master
> Switched to branch 'master'
>
> ~/software/tools.test (git)-[master] % git merge import
> Auto-merging .gitignore
> CONFLICT (add/add): Merge conflict in .gitignore
> Automatic merge failed; fix conflicts and then commit the result.
>
> Resolving the conflict.
>
> ~/software/tools.test (git)-[master|merge] % git add .gitignore
>
> ~/software/tools.test (git)-[master|merge] % git commit -m "Merged flof."
> [master b8c85be] Merged flof.
>
> ~/software/tools.test (git)-[master] % git remote rm fl
>
> Are thery any problems with this procedure? The history seems to intact. I'm
> quite unsure since still being a git beginner.
It works in the sense that git follows the renames (moves) you had to do
prior to the merge.
Other tools like git-subtree do that history implanting in one step, by
putting the added project into a subtree (rewriting the history). That
way you don't have reorg commits in the history.
Michael
^ permalink raw reply
* Re: Pushing symbolic references to remote repositories?
From: Junio C Hamano @ 2012-12-22 18:27 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Dun Peal, Shawn Pearce, Git ML
In-Reply-To: <m2ehiiv3nb.fsf@linux-m68k.org>
Andreas Schwab <schwab@linux-m68k.org> writes:
> This is not limited to HEAD, any ref may want to be set up as a symref
> at a remote repo. For example, I want to set up a symref master ->
> trunk at a repository I have no shell access to.
That is exactly the "hosting side does not give you an easy way so
pushing seems to be one plausible but not necessarily has to be the
only way" case, so it is already covered in the discussion.
^ permalink raw reply
* [PATCH] Sort howto documents in howto-index.txt
From: Thomas Ackermann @ 2012-12-22 18:34 UTC (permalink / raw)
To: th.acker, git
Howto documents in howto-index.txt were listed in a rather
random order. So better sort them.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index d7417b8..ff8ad9a 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -348,7 +348,7 @@ $(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
$(QUIET_GEN)$(RM) $@+ $@ && \
- '$(SHELL_PATH_SQ)' ./howto-index.sh $(wildcard howto/*.txt) >$@+ && \
+ '$(SHELL_PATH_SQ)' ./howto-index.sh $(sort $(wildcard howto/*.txt)) >$@+ && \
mv $@+ $@
$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* Re: [PATCH 3/3] Makefile: use -Wdeclaration-after-statement if supported
From: Junio C Hamano @ 2012-12-22 18:39 UTC (permalink / raw)
To: Adam Spiers; +Cc: git list
In-Reply-To: <CAOkDyE_+3n8PS_6vs-HG6v5A4SirBPVVCdgeUPOPpwaNpkk9Uw@mail.gmail.com>
Adam Spiers <git@adamspiers.org> writes:
> Fair enough, but let's not allow perfect to become the enemy of good.
That is why I would prefer a solution without any false positive
while allowing false negatives, i.e. not force everybody to use
these flags without giving a way to turn them off.
You could perhaps sell us a solution like this:
* Put these more strict options to CC_FLAGS_PEDANTIC (you may later
want to come up with LD_FLAGS_PEDANTIC and friends to make other
comands also more strict).
* Introduce PEDANTIC variable that turns XX_FLAGS_PEDANTIC
variables to less strict when set to 0 and more strict when set
to 1, similar to the way the variable V makes "make V=0" and
"make V=1" behave slightly differently.
Then we could introduce PEDANTIC=0 as default first to have people
try it out, with an expectation that later we can flip the default
to 'on' when the feature matures.
^ permalink raw reply
* Re: problem with BOINC repository and CR/LF
From: Dmitry Potapov @ 2012-12-22 18:54 UTC (permalink / raw)
To: Toralf Förster
Cc: Jeff King, Torsten Bögershausen, Andrew Ardill,
git@vger.kernel.org
In-Reply-To: <50D5A81B.1000306@gmx.de>
On Sat, Dec 22, 2012 at 4:31 PM, Toralf Förster <toralf.foerster@gmx.de> wrote:
>
> /me still wonders whether this race condition is a feature or an issue
> in GIT - b/c it means that 2 different people cloning the same
> repository get different results.
The problem is that Git assumes that conversion from git to the worktree
and back produces the same result. Unfortunately, this assumption is not
enforced anywhere and when it is broken by editing .gitattributes, it may
be difficult to notice that immediately unless you do that trick with
removing the index and "git reset". Perhaps, it would be better if
git considered that timestamps on all files changed if .gitattributes
is changed, so it would check all files for consistence, then anyone
who edits .gitattributes will be forced to fix the file ending to be
consistent.
Anyway, when this underlying assumption is broken, it is easy to get
that race, because git checks only those files for modification that
have its timestamp equal or newer than the index. (The equal timestamp
are inspected for modification, because the timestamp resolution can
be 1 second on some systems.) When you check out some version, some
of files are going to have an older timestamp than the index (and thus
they are not inspected for modification) but those that have the same
timestamp as the index are inspected for modification.
Dmitry
^ permalink raw reply
* Re: problem with BOINC repository and CR/LF
From: Junio C Hamano @ 2012-12-22 19:17 UTC (permalink / raw)
To: Toralf Förster
Cc: Jeff King, Torsten Bögershausen, Andrew Ardill,
git@vger.kernel.org
In-Reply-To: <50D5A81B.1000306@gmx.de>
Toralf Förster <toralf.foerster@gmx.de> writes:
> On 12/18/2012 05:41 PM, Jeff King wrote:
>> I could reproduce it, too, on Linux.
>>
>> The reason it does not always happen is that git will not re-examine the
>> file content unless the timestamp on the file is older than what's in
>> the index. So it is a race condition for git to see whether the file is
>> stat-dirty.
>
> /me still wonders whether this race condition is a feature or an issue
> in GIT - b/c it means that 2 different people cloning the same
> repository get different results.
The primary point of Peff's demonstration was to show that you told
your repository to lie to Git, I think. It promised that the
contents in the repository was with certain line endings when they
are not. At that point Git can do whatever happens when it trusts
its behaviour on that broken promise.
When the timestamp is set one way, Git happened to be extra careful
for other reasons---Git is not in the business of suspecting that
the user lied and double checking by wasting cycles [*1*]---and that
extra check that does not have anything to do with the end-of-line
conversion found that it was lied and noticed differences.
That is neither a feature nor a bug.
[Footnote]
*1* This extra carefulness is to handle the case where *filesystems*
lie to Git. The user cannot do anything to make the filesystem not
to lie, so we try to be extra careful and examine the contents even
when the stat information (incorrectly) says that the file is not
modified. Also luckily this happens only to minority of the paths
(i.e. you do "git add" and then replace the file with different
contents of the same length within the same timestamp granularity,
or something like that), so we can afford to.
^ permalink raw reply
* Hold your fire, please
From: Junio C Hamano @ 2012-12-22 19:22 UTC (permalink / raw)
To: git
Primarily in order to force me concentrate on the releng for the
upcoming release, and also to encourage contributors to focus on
finding and fixing any last minute regressions (rather than
distracting others by showing publicly scratching their itches), I
won't be queuing any patch that is not a regression fix, at least
for the next few days. I may not even review them.
Thanks.
And have a nice holiday if you are in areas where it is a holiday
season ;-)
^ permalink raw reply
* Re: [PATCH] Sort howto documents in howto-index.txt
From: Junio C Hamano @ 2012-12-22 19:40 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git
In-Reply-To: <1870890640.302608.1356201267202.JavaMail.ngmail@webmail13.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
> Howto documents in howto-index.txt were listed in a rather
> random order. So better sort them.
>
> Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
> ---
I think $(wildcard) used to sort but in recent GNU make it no longer
does, so this is probably a good change.
Do we need to explicitly sort the api-index as well? $(API_DOCS) is
fed to the script that reads filenames one at a time in the given
order, but I do not see anybody asking for a sorted list while
producing that list. The result looks to be sorted in my build
farm with GNU make 3.82, but that could be by accident.
> Documentation/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index d7417b8..ff8ad9a 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -348,7 +348,7 @@ $(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
>
> howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
> $(QUIET_GEN)$(RM) $@+ $@ && \
> - '$(SHELL_PATH_SQ)' ./howto-index.sh $(wildcard howto/*.txt) >$@+ && \
> + '$(SHELL_PATH_SQ)' ./howto-index.sh $(sort $(wildcard howto/*.txt)) >$@+ && \
> mv $@+ $@
>
> $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
^ permalink raw reply
* Aw: Re: [PATCH] Sort howto documents in howto-index.txt
From: Thomas Ackermann @ 2012-12-22 19:54 UTC (permalink / raw)
To: gitster, th.acker; +Cc: git
In-Reply-To: <7v8v8pri3w.fsf@alter.siamese.dyndns.org>
>
> I think $(wildcard) used to sort but in recent GNU make it no longer
> does, so this is probably a good change.
>
> Do we need to explicitly sort the api-index as well? $(API_DOCS) is
> fed to the script that reads filenames one at a time in the given
> order, but I do not see anybody asking for a sorted list while
> producing that list. The result looks to be sorted in my build
> farm with GNU make 3.82, but that could be by accident.
>
$(API_DOCS) is not fed to api-index.sh; it's only in the dependencies.
api-index.sh uses "ls api-*.txt" internally which produces a correct sorting.
Unifying api-index.sh and howto-index.sh is on my todo list ...
---
Thomas
^ permalink raw reply
* Re: [PATCH v2] mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
From: David Aguilar @ 2012-12-22 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeremy Morton, git
In-Reply-To: <7v4njf2xrk.fsf@alter.siamese.dyndns.org>
On Fri, Dec 21, 2012 at 8:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
> David Aguilar <davvid@gmail.com> writes:
>
>> Use $TMPDIR when creating the /dev/null placeholder for p4merge.
>> This keeps it out of the current directory.
>
> The usual $REMOTE "this is theirs" and $LOCAL "this is ours" are
> still created in the current directory, no? It is unclear why this
> "this side does not exist" case wants to be outside of the current
> directory in the first place.
I'll take this as a hint that I should improve the commit message.
As you alluded to in your earlier email, we are in feature freeze
so I will be holding off on sending it until things have settled.
I don't believe there is a strong reason why the file should be in one
place vs. another, and the explanation is different depending on who
is driving the scriptlet.
When difftool drives then $LOCAL and $REMOTE may point to
temporary files created by the GIT_EXTERNAL_DIFF machinery.
For that use case, this commit makes things consistent with
those location of paths.
When mergetool drives it creates $LOCAL and $REMOTE in
the current directory. They contain the different stages
of the index and can be helpful to the user when resolving merges.
The temporary /dev/null placeholder is a workaround for p4merge
and from the user's point of view this file is never interesting, so
writing it into the worktree is distracting to the user.
I could also say that it makes it consistent because "/dev" is
also not in the current directory, but that's a stretch ;-)
> In other words, "This keeps it out of the current directory" only
> explains what this patch changes, without explaining why it is a
> good thing to do in the first place.
I'll try and write up a replacement patch but I'll hold off
on sending it out until after things have settled down.
FWIW I'm seeing a "Bus Error" when doing "git update-index --refresh"
in a repository with large files on a 32bit machine. I'm not sure if
that counts as a regression since the same error occurs in 1.7.10.4
(debian testing).
I'll start another thread on this topic in case anyone is interested.
>> +create_empty_file () {
>> + empty_file="${TMPDIR:-/tmp}/git-difftool-p4merge-empty-file.$$"
>> + >"$empty_file"
>> +
>> + printf "$empty_file"
>> +}
>
> Assuming that it makes sense to create only the "this side doe not
> exist, and here is a placeholder empty file" in $TMPDIR, I think
> this is probably sufficient.
Yup. I mulled over whether or not to embed "LOCAL" and "REMOTE"
in the name but eventually decided that it was not worth the effort.
It makes the code much simpler when they share the placeholder
since we no longer need to track them separately.
--
David
^ permalink raw reply
* Re: Missing Refs after Garbage Collection
From: Dmitry Potapov @ 2012-12-22 22:26 UTC (permalink / raw)
To: Earl Gresh; +Cc: git
In-Reply-To: <C0A16EC8-D05A-41D0-BF2A-34BF3B1B839E@codeaurora.org>
Hi,
On Sat, Dec 22, 2012 at 5:41 AM, Earl Gresh <egresh@codeaurora.org> wrote:
>
> Is anyone familiar with git gc deleting valid references? I'm running
> git version 1.7.8. Have there been any patches in later git releases
> that might address this issue ( if it is a git problem )?
I have not seen any relevant changes in git. I have looked at the code,
and what git-gc is running "git pack-refs --all --prune", which is very
careful in packing and fsyncing the new file with all packed references
before deleting anything. Only those references that were packed can be
deleted. Also, it does not matter whether a reference is valid or not,
or whether it is stored in refs/changes or in some other place, like
refs/heads. So if references were really lost as you described, I think
other people would notice that by now.
The only plausible explanation that comes to my mind now is that file
creation using O_EXCL is not atomic on your system, then the lock did
not work and one process could overwrite packed references created by
another.
Dmitry
^ permalink raw reply
* Push Windows to Linux Repository Problem
From: Dennis Putnam @ 2012-12-23 0:30 UTC (permalink / raw)
To: git@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
I think I have my Linux central repository set up correctly. I can pull
and push from/to the repository on the Linux host itself. My problem is
trying to push commits to that repository from windows. I keep getting
"fatal: Could not read from remote repository." When I run 'ls' commands
using plink from the command line it works fine with the same
credentials. Clearly there is an issue with git on Windows and using SSH
to access the remote repository. I'm stuck as to how to debug this. Can
anyone point me in the right direction? TIA
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: Missing Refs after Garbage Collection
From: Jeff King @ 2012-12-23 1:04 UTC (permalink / raw)
To: Earl Gresh; +Cc: git
In-Reply-To: <C0A16EC8-D05A-41D0-BF2A-34BF3B1B839E@codeaurora.org>
On Fri, Dec 21, 2012 at 05:41:43PM -0800, Earl Gresh wrote:
> I have observed that after running GC, one particular git repository
> ended up with some missing refs in the refs/changes/* namespace the
> Gerrit uses for storing patch sets. The refs were valid and should not
> have been pruned. Concerned about loosing data, GC is still enabled
> but ref packing is turned off. Now the number of refs has grown to the
> point that it's causing performance problems when cloning the project.
>
> Is anyone familiar with git gc deleting valid references? I'm running
> git version 1.7.8. Have there been any patches in later git releases
> that might address this issue ( if it is a git problem )?
I have never seen deletion, but I did recently find a race condition
with ref packing that caused rewinds, where:
1. Two processes simultaneously repack the refs.
2. At least one process is using an "old" version of the pack-refs
file. That is, it cached the packed refs list earlier in the
process and is now rewriting it based on that cached notion.
3. The first process takes the lock, packs refs, drops the
lock, and then deletes the loose versions. The simultaneous packer
then takes the lock, overwrites the packed-refs file with a stale
copy from its memory, and then releases the lock. We're left with
the stale copy in pack-refs, and deleted loose refs.
In my case, it looked like a rewind, because the stale, memory-cached
refs had the old version. But if you have a ref which was not previously
packed, it would appear to have been deleted.
The tricky thing about triggering this race is that step (2) needs a
process which has previously read and cached the packed-refs, and then
decided to pack the refs. The "git pack-refs" command does not do this,
because it starts, packs the ref, and exists. But processes which delete
a ref need to rewrite the packed-refs file (omitting the deleted ref),
and depending on the process, may have previously read and cached the
packed refs file. The obvious candidate is "receive-pack".
So this may be your culprit if:
1. This is a repo people are pushing into via C git.
2. You simultaneously run "git pack-refs" (or "git gc") while people
may be pushing.
You mentioned Gerrit, so I wonder if people are actually pushing via C
git (I thought it used JGit entirely). Or perhaps JGit has the same bug.
My fix (which is not yet released in any git version) is here:
http://article.gmane.org/gmane.comp.version-control.git/211956
-Peff
^ permalink raw reply
* Re: Pushing symbolic references to remote repositories?
From: Sitaram Chamarty @ 2012-12-23 1:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Schwab, Dun Peal, Shawn Pearce, Git ML
In-Reply-To: <7vy5gqq6w8.fsf@alter.siamese.dyndns.org>
On Sat, Dec 22, 2012 at 11:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> This is not limited to HEAD, any ref may want to be set up as a symref
>> at a remote repo. For example, I want to set up a symref master ->
>> trunk at a repository I have no shell access to.
>
> That is exactly the "hosting side does not give you an easy way so
> pushing seems to be one plausible but not necessarily has to be the
> only way" case, so it is already covered in the discussion.
Just a minor FYI (and at the risk of tooting my own horn) but if the
hosting side is gitolite, you can.set it up so that any user with
write permissions to the repo can run 'git symbolic-ref' with
arbitrary arguments even though he does not get a shell.
The "-m <reason>" has some constraints because gitolite does not allow
a lot of characters in arguments to remote commands but that's mostly
useless unless you have core.logAllRefUpdates set anyway.
^ permalink raw reply
* Re: [PATCH v2] mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
From: David Aguilar @ 2012-12-23 1:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeremy Morton, git
In-Reply-To: <CAJDDKr54XBtU4J-A8T9LwXAPL6E8M2_0kaTxH_-LZCAR0fwN+g@mail.gmail.com>
On Sat, Dec 22, 2012 at 1:56 PM, David Aguilar <davvid@gmail.com> wrote:
> FWIW I'm seeing a "Bus Error" when doing "git update-index --refresh"
> in a repository with large files on a 32bit machine. I'm not sure if
> that counts as a regression since the same error occurs in 1.7.10.4
> (debian testing).
>
> I'll start another thread on this topic in case anyone is interested.
Nevermind. The machine is an old salvaged laptop and its disk
probably has some bad blocks.
I wasn't able to copy the bad repo since 'cp' kept failing to
copy the index file. I/O errors.. After deleting the borked
index the problems went away, so I'll chalk this up to
failing hardware. Sorry for the false alarm.
--
David
^ permalink raw reply
* [ANNOUNCE] Git v1.8.1-rc3
From: Junio C Hamano @ 2012-12-23 2:53 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git v1.8.1-rc3 is now available for testing
at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
c0ad509fb6a91babc43cf790405dbd95c68c986f git-1.8.1.rc3.tar.gz
8396960d1e4384a861f98cdd29e2b2693152f7c9 git-htmldocs-1.8.1.rc3.tar.gz
f73c52e016ddecac6ee0e6a5852b763e13e444a9 git-manpages-1.8.1.rc3.tar.gz
Note that the toolchain used to preformat the latter two tarballs
has been updated (I am using AsciiDoc 8.6.8 now), which hopefully
have fixed the malformatted pages Gentoo folks noticed in some pages
that use ``pretty quotes''.
The following public repositories all have a copy of the v1.8.1-rc3
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
(not) url = https://github.com/gitster/git
Git v1.8.1 Release Notes (draft)
========================
Backward compatibility notes
----------------------------
In the next major release (not *this* one), we will change the
behavior of the "git push" command.
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). We will use the "simple" semantics that pushes the
current branch to the branch with the same name, only when the current
branch is set to integrate with that remote branch. There is a user
preference configuration variable "push.default" to change this, and
"git push" will warn about the upcoming change until you set this
variable in this release.
"git branch --set-upstream" is deprecated and may be removed in a
relatively distant future. "git branch [-u|--set-upstream-to]" has
been introduced with a saner order of arguments to replace it.
Updates since v1.8.0
--------------------
UI, Workflows & Features
* Command-line completion scripts for tcsh and zsh have been added.
* A new remote-helper interface for Mercurial has been added to
contrib/remote-helpers.
* We used to have a workaround for a bug in ancient "less" that
causes it to exit without any output when the terminal is resized.
The bug has been fixed in "less" version 406 (June 2007), and the
workaround has been removed in this release.
* Some documentation pages that used to ship only in the plain text
format are now formatted in HTML as well.
v * "git-prompt" scriptlet (in contrib/completion) can be told to paint
pieces of the hints in the prompt string in colors.
* A new configuration variable "diff.context" can be used to
give the default number of context lines in the patch output, to
override the hardcoded default of 3 lines.
* When "git checkout" checks out a branch, it tells the user how far
behind (or ahead) the new branch is relative to the remote tracking
branch it builds upon. The message now also advises how to sync
them up by pushing or pulling. This can be disabled with the
advice.statusHints configuration variable.
* "git config --get" used to diagnose presence of multiple
definitions of the same variable in the same configuration file as
an error, but it now applies the "last one wins" rule used by the
internal configuration logic. Strictly speaking, this may be an
API regression but it is expected that nobody will notice it in
practice.
* "git log -p -S<string>" now looks for the <string> after applying
the textconv filter (if defined); earlier it inspected the contents
of the blobs without filtering.
* "git format-patch" learned the "--notes=<ref>" option to give
notes for the commit after the three-dash lines in its output.
* "git log --grep=<pcre>" learned to honor the "grep.patterntype"
configuration set to "perl".
* "git replace -d <object>" now interprets <object> as an extended
SHA-1 (e.g. HEAD~4 is allowed), instead of only accepting full hex
object name.
* "git rm $submodule" used to punt on removing a submodule working
tree to avoid losing the repository embedded in it. Because
recent git uses a mechanism to separate the submodule repository
from the submodule working tree, "git rm" learned to detect this
case and removes the submodule working tree when it is safe to do so.
* "git send-email" used to prompt for the sender address, even when
the committer identity is well specified (e.g. via user.name and
user.email configuration variables). The command no longer gives
this prompt when not necessary.
* "git send-email" did not allow non-address garbage strings to
appear after addresses on Cc: lines in the patch files (and when
told to pick them up to find more recipients), e.g.
Cc: Stable Kernel <stable@k.org> # for v3.2 and up
The command now strips " # for v3.2 and up" part before adding the
remainder of this line to the list of recipients.
* "git submodule add" learned to add a new submodule at the same
path as the path where an unrelated submodule was bound to in an
existing revision via the "--name" option.
* "git submodule sync" learned the "--recursive" option.
* "diff.submodule" configuration variable can be used to give custom
default value to the "git diff --submodule" option.
* "git symbolic-ref" learned the "-d $symref" option to delete the
named symbolic ref, which is more intuitive way to spell it than
"update-ref -d --no-deref $symref".
Foreign Interface
* "git cvsimport" can be told to record timezones (other than GMT)
per-author via its author info file.
* The remote helper interface to interact with subversion
repositories (one of the GSoC 2012 projects) has been merged.
* The documentation for git(1) was pointing at a page at an external
site for the list of authors that no longer existed. The link has
been updated to point at an alternative site.
Performance, Internal Implementation, etc.
* Compilation on Cygwin with newer header files are supported now.
* A couple of low-level implementation updates on MinGW.
* The logic to generate the initial advertisement from "upload-pack"
(i.e. what is invoked by "git fetch" on the other side of the
connection) to list what refs are available in the repository has
been optimized.
* The logic to find set of attributes that match a given path has
been optimized.
* Use preloadindex in "git diff-index" and "git update-index", which
has a nice speedup on systems with slow stat calls (and even on
Linux).
Also contains minor documentation updates and code clean-ups.
Fixes since v1.8.0
------------------
Unless otherwise noted, all the fixes since v1.8.0 in the maintenance
track are contained in this release (see release notes to them for
details).
* The configuration parser had an unnecessary hardcoded limit on
variable names that was not checked consistently.
* The "say" function in the test scaffolding incorrectly allowed
"echo" to interpret "\a" as if it were a C-string asking for a
BEL output.
* "git mergetool" feeds /dev/null as a common ancestor when dealing
with an add/add conflict, but p4merge backend cannot handle
it. Work it around by passing a temporary empty file.
* "git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally.
* "git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
* A symbolic ref refs/heads/SYM was not correctly removed with "git
branch -d SYM"; the command removed the ref pointed by SYM
instead.
* Update "remote tracking branch" in the documentation to
"remote-tracking branch".
* "git pull --rebase" run while the HEAD is detached tried to find
the upstream branch of the detached HEAD (which by definition
does not exist) and emitted unnecessary error messages.
* The refs/replace hierarchy was not mentioned in the
repository-layout docs.
* Various rfc2047 quoting issues around a non-ASCII name on the
From: line in the output from format-patch have been corrected.
* Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptor to wait on and the http
transport ended up sleeping for minutes in select(2) system call.
A workaround has been added for this.
* For a fetch refspec (or the result of applying wildcard on one),
we always want the RHS to map to something inside "refs/"
hierarchy, but the logic to check it was not exactly right.
(merge 5c08c1f jc/maint-fetch-tighten-refname-check later to maint).
* "git diff -G<pattern>" did not honor textconv filter when looking
for changes.
* Some HTTP servers ask for auth only during the actual packing phase
(not in ls-remote phase); this is not really a recommended
configuration, but the clients used to fail to authenticate with
such servers.
(merge 2e736fd jk/maint-http-half-auth-fetch later to maint).
* "git p4" used to try expanding malformed "$keyword$" that spans
across multiple lines.
* Syntax highlighting in "gitweb" was not quite working.
* RSS feed from "gitweb" had a xss hole in its title output.
* "git config --path $key" segfaulted on "[section] key" (a boolean
"true" spelled without "=", not "[section] key = true").
* "git checkout -b foo" while on an unborn branch did not say
"Switched to a new branch 'foo'" like other cases.
* Various codepaths have workaround for a common misconfiguration to
spell "UTF-8" as "utf8", but it was not used uniformly. Most
notably, mailinfo (which is used by "git am") lacked this support.
* We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
* When "--stat-count" hides a diffstat for binary contents, the total
number of added and removed lines at the bottom was computed
incorrectly.
* When "--stat-count" hides a diffstat for unmerged paths, the total
number of affected files at the bottom of the "diff --stat" output
was computed incorrectly.
* "diff --shortstat" miscounted the total number of affected files
when there were unmerged paths.
* "update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
----------------------------------------------------------------
Changes since v1.8.1-rc2 are as follows:
Adam Spiers (2):
SubmittingPatches: add convention of prefixing commit messages
Documentation: move support for old compilers to CodingGuidelines
Chris Rorvick (2):
Documentation/git-checkout.txt: clarify usage
Documentation/git-checkout.txt: document 70c9ac2 behavior
Jeff King (5):
.mailmap: match up some obvious names/emails
.mailmap: fix broken entry for Martin Langhoff
.mailmap: normalize emails for Jeff King
.mailmap: normalize emails for Linus Torvalds
contrib: update stats/mailmap script
John Keeping (1):
Documentation: don't link to example mail addresses
Junio C Hamano (5):
fetch --tags: clarify documentation
README: it does not matter who the current maintainer is
t7004: do not create unneeded gpghome/gpg.conf when GPG is not used
Documentation: Describe "git diff <blob> <blob>" separately
Git 1.8.1-rc3
Nguyễn Thái Ngọc Duy (1):
index-format.txt: clarify what is "invalid"
Sebastian Leske (4):
git-svn: Document branches with at-sign(@).
git-svn: Recommend use of structure options.
git-svn: Expand documentation for --follow-parent
git-svn: Note about tags.
Sitaram Chamarty (1):
clarify -M without % symbol in diff-options
Stefano Lattarini (1):
README: Git is released under the GPLv2, not just "the GPL"
Thomas Ackermann (3):
Remove misleading date from api-index-skel.txt
Remove duplicate entry in ./Documentation/Makefile
Move ./technical/api-command.txt to ./howto/new-command.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox