* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Jeff King @ 2013-02-01 19:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <7vr4kzamt7.fsf@alter.siamese.dyndns.org>
On Fri, Feb 01, 2013 at 10:52:52AM -0800, Junio C Hamano wrote:
> > 4. Replace the rename "gitfoo" above with a "see git-foo..." pointer.
> > Users of "git help foo" would not ever see this, but people who
> > have trained their fingers to type "man gitfoo" would, along with
> > anybody following an outdated HTML link.
> >
> > 5. Update internal references to "linkgit:gitfoo" to point to
> > "git-foo".
> >
> > Hmm. That really does not seem so bad. The biggest downside is the
> > people who have to see the redirect made in step 4.
>
> Yeah, I see that a show-stopper in the whole sequence.
>
> This is one of the "if we had perfect knowledge we would have
> designed it this way, and we could still migrate our current system
> to that ideal, but it is dubious the difference between the current
> system and the ideal will outweigh the cost of migration" moment,
> isn't it?
Yeah, perhaps. I did the patch series just to see what the effort would
be like. But at this point I am fine if we drop it (it sounded like
Jonathan was in favor of this direction, so maybe he wants to make a
final argument).
-Peff
^ permalink raw reply
* Re: [PATCH] rebase --preserve-merges keeps empty merge commits
From: Martin von Zweigbergk @ 2013-02-01 19:15 UTC (permalink / raw)
To: Phil Hord; +Cc: git, phil.hord, Neil Horman, Junio C Hamano
In-Reply-To: <1358023561-26773-1-git-send-email-hordp@cisco.com>
I'm working on a re-roll of
http://thread.gmane.org/gmane.comp.version-control.git/205796
and finally got around to including test cases for what you fixed in
this patch. I want to make sure I'm testing what you fixed here. See
questions below.
On Sat, Jan 12, 2013 at 12:46 PM, Phil Hord <hordp@cisco.com> wrote:
> Since 90e1818f9a (git-rebase: add keep_empty flag, 2012-04-20)
> 'git rebase --preserve-merges' fails to preserve empty merge commits
> unless --keep-empty is also specified. Merge commits should be
> preserved in order to preserve the structure of the rebased graph,
> even if the merge commit does not introduce changes to the parent.
>
> Teach rebase not to drop merge commits only because they are empty.
Consider a history like
# a---b---c
# \ \
# d---l
# \
# e
# \
# C
where 'l' is tree-same with 'd' and 'C' introduces the same change as 'c'.
My test case runs 'git rebase -p e l' and expects the result to look like
# a---b---c
# \ \
# d \
# \ \
# e---l
> A special case which is not handled by this change is for a merge commit
> whose parents are now the same commit because all the previous different
> parents have been dropped as a result of this rebase or some previous
> operation.
And for this case, the test case runs 'git rebase -p C l'. Is that
what you meant here?
Before your patch, git would just say "Nothing to do" and after your
patch, we get
# a---b---c
# \ \
# d \
# \ \
# e \
# \ \
# C---l
As you say, your patch doesn't try to handle this case, but at least
the new behavior seems better. I think we would ideally want the
recreated 'l' to have only 'C' as parent in this case. Does that make
sense?
Martin
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
From: Jonathan Nieder @ 2013-02-01 19:20 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201082650.GA25783@sigill.intra.peff.net>
Jeff King wrote:
> We keep a list of the various files that end up as man1,
> man5, etc. Let's break these single-line lists into sorted
> multi-line lists, which makes diffs that touch them much
> easier to read.
Independentally of the rest of the series, I think this is a good
cleanup.
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt
> -MAN1_TXT= \
> - $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
> - $(wildcard git-*.txt)) \
> - gitk.txt gitweb.txt git.txt
> +MAN1_TXT += git.txt
> +MAN1_TXT += gitk.txt
> +MAN1_TXT += gitweb.txt
> +
If the user happens to have MAN[157]_TXT set in the environment, this
would be affected by that. How about:
# Guard against environment variables
MAN1_TXT =
MAN5_TXT =
MAN7_TXT =
MAN1_TXT += ...
...
?
With that change,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/2] docs: convert "concept" manpages to git-*
From: Jonathan Nieder @ 2013-02-01 19:25 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201082744.GB25783@sigill.intra.peff.net>
Jeff King wrote:
> Let's just call everything git-*, which is simpler. This
> patch renames the documentation files, updates the Makefile
> to find them, and updates internal linkgit references to the
> pages. It updates builtin/help.c so that users of "git help
> foo" will not even notice the difference.
>
> Users of external html links, or users who have trained
> their fingers to type "man gitfoo" will notice the missing
> pages. This patch does not install a "this page has moved"
> placeholder, but that can easily be done on top.
Thanks for writing this.
I think this one should wait until someone (perhaps me) takes care of
the redirects. Ideally in addition to simple "this place has moved"
HTML placeholders and manpages using the .so macro, a makefile target
to generate redirect directives for your apache configuration might
make sense.
In the meantime, having "man gitrepository-layout" is not the worst
wart in the world.
Cheers,
Jonathan
^ permalink raw reply
* Re: [PATCH 5/6] Add a description for 'gitfile' to glossary
From: Junio C Hamano @ 2013-02-01 19:26 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git, davvid, Lars Hjemli, Jens Lehmann
In-Reply-To: <7v4nhvc1vv.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thomas Ackermann <th.acker@arcor.de> writes:
>
>> Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
>> ---
>> Documentation/glossary-content.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
>> index 7c15bc0..ddf2f66 100644
>> --- a/Documentation/glossary-content.txt
>> +++ b/Documentation/glossary-content.txt
>> @@ -149,6 +149,9 @@ to point at the new commit.
>> [[def_git_archive]]Git archive::
>> Synonym for <<def_repository,repository>> (for arch people).
>>
>> +[[def_gitfile]]gitfile::
>> + A `.git` file which points to a `$GIT_DIR` (used for Git submodules).
>> +
>
> It is more like 'used by' ;-) People are free to write their
> Porcelain system that uses this mechanism.
The series merged at e2e2def (Merge branch 'lh/git-file', 2008-05-05)
added a mention of this to repository-layout and the readers can see
how it is interpreted by Git, but I doubt that anything explains why
you may want to use it in the documentation.
How about saying something like this here in the glossary:
A plain file `.git` at the root of a working tree that
points at the directory that is the real repository.
And then as a separate patch, in gitrepository-layout.txt (eek---see
the other thread), we can do something like this:
Documentation/gitrepository-layout.txt | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
index 9f62886..473c6a0 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -12,12 +12,24 @@ $GIT_DIR/*
DESCRIPTION
-----------
-You may find these things in your git repository (`.git`
-directory for a repository associated with your working tree, or
-`<project>.git` directory for a public 'bare' repository. It is
-also possible to have a working tree where `.git` is a plain
-ASCII file containing `gitdir: <path>`, i.e. the path to the
-real git repository).
+A Git repository comes in two different flavours:
+
+ * a `.git` directory at the root of the working tree;
+
+ * a `<project>.git` directory that is a 'bare' repository
+ (i.e. without its own working tree), that is typically used for
+ exchanging histories with others by pushing into it and fetching
+ from it.
+
+*Note*: Also you can have a plain text file `.git` at the root of
+your working tree, containing `gitdir: <path>` to point at the real
+directory that has the repository. This mechanism is often used for
+a working tree of a submodule checkout, to allow you in the
+containing superproject to `git checkout` a branch that does not
+have the submodule. The `checkout` has to remove the entire
+submodule working tree, without losing the submodule repository.
+
+These things may exist in a Git repository.
objects::
Object store associated with this repository. Usually
^ permalink raw reply related
* [PATCH] mergetools: Enable tortoisemerge to handle filenames with
From: Sven Strickroth @ 2013-02-01 19:33 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, David Aguilar, Sebastian Schuberth, Jeff King
In-Reply-To: <7vzjzuwm7s.fsf@alter.siamese.dyndns.org>
spaces with TortoiseGitMerge
TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
with spaces in them by using -option "$FILE" (not -option:"$FILE",
which does not work for such paths) syntax. Both do not have a fully
posix compatible cli parameter parser, however, TortoiseGitMerge was
modified in order to handle filenames with spaces correctly. The
"-key value" form was choosen because this way no escaping for
quotes within quotes is necessary; see
https://github.com/msysgit/msysgit/issues/57
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Reported-by: Sebastian Schuberth <sschuberth@gmail.com>
---
mergetools/tortoisemerge | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/mergetools/tortoisemerge b/mergetools/tortoisemerge
index 8476afa..3b89f1c 100644
--- a/mergetools/tortoisemerge
+++ b/mergetools/tortoisemerge
@@ -6,9 +6,17 @@ merge_cmd () {
if $base_present
then
touch "$BACKUP"
- "$merge_tool_path" \
- -base:"$BASE" -mine:"$LOCAL" \
- -theirs:"$REMOTE" -merged:"$MERGED"
+ basename="$(basename "$merge_tool_path" .exe)"
+ if test "$basename" = "tortoisegitmerge"
+ then
+ "$merge_tool_path" \
+ -base "$BASE" -mine "$LOCAL" \
+ -theirs "$REMOTE" -merged "$MERGED"
+ else
+ "$merge_tool_path" \
+ -base:"$BASE" -mine:"$LOCAL" \
+ -theirs:"$REMOTE" -merged:"$MERGED"
+ fi
check_unchanged
else
echo "$merge_tool_path cannot be used without a base" 1>&2
--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply related
* Re: [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
From: Junio C Hamano @ 2013-02-01 19:38 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jeff King, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201192010.GA12368@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> --- a/Documentation/Makefile
>> +++ b/Documentation/Makefile
>> @@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt
>> -MAN1_TXT= \
>> - $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
>> - $(wildcard git-*.txt)) \
>> - gitk.txt gitweb.txt git.txt
>> +MAN1_TXT += git.txt
>> +MAN1_TXT += gitk.txt
>> +MAN1_TXT += gitweb.txt
>> +
>
> If the user happens to have MAN[157]_TXT set in the environment, this
> would be affected by that. How about:
>
> # Guard against environment variables
> MAN1_TXT =
> MAN5_TXT =
> MAN7_TXT =
>
> MAN1_TXT += ...
> ...
>
> With that change,
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Sounds sensible. Let's go in that direction.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
From: Jeff King @ 2013-02-01 19:38 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201192010.GA12368@google.com>
On Fri, Feb 01, 2013 at 11:20:10AM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > We keep a list of the various files that end up as man1,
> > man5, etc. Let's break these single-line lists into sorted
> > multi-line lists, which makes diffs that touch them much
> > easier to read.
>
> Independentally of the rest of the series, I think this is a good
> cleanup.
Yeah, I'd agree.
> > --- a/Documentation/Makefile
> > +++ b/Documentation/Makefile
> > @@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt
> > -MAN1_TXT= \
> > - $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
> > - $(wildcard git-*.txt)) \
> > - gitk.txt gitweb.txt git.txt
> > +MAN1_TXT += git.txt
> > +MAN1_TXT += gitk.txt
> > +MAN1_TXT += gitweb.txt
> > +
>
> If the user happens to have MAN[157]_TXT set in the environment, this
> would be affected by that. How about:
>
> # Guard against environment variables
> MAN1_TXT =
> MAN5_TXT =
> MAN7_TXT =
>
> MAN1_TXT += ...
> ...
>
> ?
Sure, not that likely, but no reason not to be careful. I notice the
rest of the file uses the:
FOO = first
FOO += second
...
pattern, though I prefer the style you showed myself.
Junio, do you want to apply the patch below? I guess it conflicts with
John's gitremote-helper.txt tweak, though.
-- >8 --
Subject: [PATCH] Documentation/Makefile: clean up MAN*_TXT lists
We keep a list of the various files that end up as man1,
man5, etc. Let's break these single-line lists into sorted
multi-line lists, which makes diffs that touch them much
easier to read.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/Makefile | 33 ++++++++++++++++++++++++---------
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 971977b..8e7939f 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt
-MAN1_TXT= \
- $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
- $(wildcard git-*.txt)) \
- gitk.txt gitweb.txt git.txt
-MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
- gitrepository-layout.txt gitweb.conf.txt
-MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
- gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
- gitdiffcore.txt gitnamespaces.txt gitrevisions.txt gitworkflows.txt
+MAN1_TXT += $(filter-out \
+ $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
+ $(wildcard git-*.txt))
+MAN1_TXT += git.txt
+MAN1_TXT += gitk.txt
+MAN1_TXT += gitweb.txt
+
+MAN5_TXT += gitattributes.txt
+MAN5_TXT += githooks.txt
+MAN5_TXT += gitignore.txt
+MAN5_TXT += gitmodules.txt
+MAN5_TXT += gitrepository-layout.txt
+MAN5_TXT += gitweb.conf.txt
+
+MAN7_TXT += gitcli.txt
+MAN7_TXT += gitcore-tutorial.txt
MAN7_TXT += gitcredentials.txt
+MAN7_TXT += gitcvs-migration.txt
+MAN7_TXT += gitdiffcore.txt
+MAN7_TXT += gitglossary.txt
+MAN7_TXT += gitnamespaces.txt
+MAN7_TXT += gitrevisions.txt
+MAN7_TXT += gittutorial-2.txt
+MAN7_TXT += gittutorial.txt
+MAN7_TXT += gitworkflows.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
--
1.8.1.2.11.g1a2f572
^ permalink raw reply related
* Re: [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
From: Jeff King @ 2013-02-01 19:41 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201193851.GA24588@sigill.intra.peff.net>
On Fri, Feb 01, 2013 at 02:38:51PM -0500, Jeff King wrote:
> Junio, do you want to apply the patch below? I guess it conflicts with
> John's gitremote-helper.txt tweak, though.
Argh, it would help if I actually ran "git commit", and/or looked at
what I was sending out. Here it is with the actual change.
-- >8 --
Subject: [PATCH] Documentation/Makefile: clean up MAN*_TXT lists
We keep a list of the various files that end up as man1,
man5, etc. Let's break these single-line lists into sorted
multi-line lists, which makes diffs that touch them much
easier to read.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/Makefile | 38 +++++++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 971977b..5d22e0e 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,13 +1,33 @@ MAN7_TXT += gitcredentials.txt
-MAN1_TXT= \
- $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
- $(wildcard git-*.txt)) \
- gitk.txt gitweb.txt git.txt
-MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
- gitrepository-layout.txt gitweb.conf.txt
-MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
- gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
- gitdiffcore.txt gitnamespaces.txt gitrevisions.txt gitworkflows.txt
+# Guard against environment variables
+MAN1_TXT =
+MAN5_TXT =
+MAN7_TXT =
+
+MAN1_TXT += $(filter-out \
+ $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
+ $(wildcard git-*.txt))
+MAN1_TXT += git.txt
+MAN1_TXT += gitk.txt
+MAN1_TXT += gitweb.txt
+
+MAN5_TXT += gitattributes.txt
+MAN5_TXT += githooks.txt
+MAN5_TXT += gitignore.txt
+MAN5_TXT += gitmodules.txt
+MAN5_TXT += gitrepository-layout.txt
+MAN5_TXT += gitweb.conf.txt
+
+MAN7_TXT += gitcli.txt
+MAN7_TXT += gitcore-tutorial.txt
MAN7_TXT += gitcredentials.txt
+MAN7_TXT += gitcvs-migration.txt
+MAN7_TXT += gitdiffcore.txt
+MAN7_TXT += gitglossary.txt
+MAN7_TXT += gitnamespaces.txt
+MAN7_TXT += gitrevisions.txt
+MAN7_TXT += gittutorial-2.txt
+MAN7_TXT += gittutorial.txt
+MAN7_TXT += gitworkflows.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
--
1.8.1.2.11.g1a2f572
^ permalink raw reply related
* Re: [PATCH 2/6] fixup! fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
From: Jonathan Nieder @ 2013-02-01 19:43 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: gitster, git, davvid, Fredrik Gustafsson, Jens Lehmann
In-Reply-To: <242116275.1090080.1359742076320.JavaMail.ngmail@webmail18.arcor-online.net>
Hi,
Thomas Ackermann wrote:
> Found by Junio:
> Change git-dir to $GIT_DIR and git-file to gitfile.
>
> Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
> ---
> Documentation/git-rev-parse.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
> index c743469..14386ed 100644
> --- a/Documentation/git-rev-parse.txt
> +++ b/Documentation/git-rev-parse.txt
> @@ -187,9 +187,9 @@ print a message to stderr and exit with nonzero status.
> Flags and parameters to be parsed.
>
> --resolve-git-dir <path>::
> - Check if <path> is a valid git-dir or a git-file pointing to a valid
> - git-dir. If <path> is a valid git-dir the resolved path to git-dir will
> - be printed.
> + Check if <path> is a valid `$GIT_DIR` or a gitfile pointing to a valid
> + `$GIT_DIR`. If <path> is a valid `$GIT_DIR` the resolved path to `$GIT_DIR`
> + will be printed.
Hm, I don't find the old or the new version very easy to understand. Perhaps the
idea is something like this?
Check if <path> is a valid git repository (.git or <project>.git
directory) or "gitdir:" file. If <path> is a "gitdir:" file
then the resolved path to the corresponding real git repository
will be printed.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH 5/6] Add a description for 'gitfile' to glossary
From: Jonathan Nieder @ 2013-02-01 19:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Ackermann, git, davvid, Lars Hjemli, Jens Lehmann,
Fredrik Gustafsson
In-Reply-To: <7vlib7al90.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> How about saying something like this here in the glossary:
>
> A plain file `.git` at the root of a working tree that
> points at the directory that is the real repository.
>
> And then as a separate patch, in gitrepository-layout.txt (eek---see
> the other thread), we can do something like this:
>
> Documentation/gitrepository-layout.txt | 24 ++++++++++++++++++------
> 1 file changed, 18 insertions(+), 6 deletions(-)
Looks correct and very readable. Thanks.
Jonathan
(patch left unsnipped for reference)
> diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
> index 9f62886..473c6a0 100644
> --- a/Documentation/gitrepository-layout.txt
> +++ b/Documentation/gitrepository-layout.txt
> @@ -12,12 +12,24 @@ $GIT_DIR/*
> DESCRIPTION
> -----------
>
> -You may find these things in your git repository (`.git`
> -directory for a repository associated with your working tree, or
> -`<project>.git` directory for a public 'bare' repository. It is
> -also possible to have a working tree where `.git` is a plain
> -ASCII file containing `gitdir: <path>`, i.e. the path to the
> -real git repository).
> +A Git repository comes in two different flavours:
> +
> + * a `.git` directory at the root of the working tree;
> +
> + * a `<project>.git` directory that is a 'bare' repository
> + (i.e. without its own working tree), that is typically used for
> + exchanging histories with others by pushing into it and fetching
> + from it.
> +
> +*Note*: Also you can have a plain text file `.git` at the root of
> +your working tree, containing `gitdir: <path>` to point at the real
> +directory that has the repository. This mechanism is often used for
> +a working tree of a submodule checkout, to allow you in the
> +containing superproject to `git checkout` a branch that does not
> +have the submodule. The `checkout` has to remove the entire
> +submodule working tree, without losing the submodule repository.
> +
> +These things may exist in a Git repository.
>
> objects::
> Object store associated with this repository. Usually
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
From: Jonathan Nieder @ 2013-02-01 19:51 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: gitster, git, davvid
In-Reply-To: <549641245.1090170.1359742373184.JavaMail.ngmail@webmail18.arcor-online.net>
Thomas Ackermann wrote:
> --- a/Documentation/git.txt
> +++ b/Documentation/git.txt
> @@ -23,7 +23,7 @@ and full access to internals.
>
> See linkgit:gittutorial[7] to get started, then see
> link:everyday.html[Everyday Git] for a useful minimum set of
> -commands. The link:user-manual.html[Git User's Manual] has a more
> +commands. The link:user-manual.html[The Git User's Manual] has a more
> in-depth introduction.
In the rendered version, this looks like:
The The Git User's Manual[1] has a more in-depth introduction.
Presumably the first "The" should be dropped from either the link or
the surrounding text.
[...]
> --- a/Documentation/gitcore-tutorial.txt
> +++ b/Documentation/gitcore-tutorial.txt
> @@ -17,7 +17,7 @@ work with a Git repository.
>
> If you just need to use Git as a revision control system you may prefer
> to start with "A Tutorial Introduction to Git" (linkgit:gittutorial[7]) or
> -link:user-manual.html[the Git User Manual].
> +link:user-manual.html[The Git User's Manual].
This comes out as
... you may prefer to start with "A Tutorial Instruction to Git"
(gittutorial(7)) or The Git User's Manual[1].
The capital 'T' in "The" looks a bit strange, but a lowercase 't' in
the corresponding footnote would also look strange. We can't have
everything, I guess.
A possible fix would be to drop the "The" from the link. The way you
have it here also seems fine.
[...]
> --- a/Documentation/gittutorial-2.txt
> +++ b/Documentation/gittutorial-2.txt
> @@ -406,7 +406,7 @@ pages for any of the git commands; one good place to start would be
> with the commands mentioned in link:everyday.html[Everyday Git]. You
> should be able to find any unknown jargon in linkgit:gitglossary[7].
>
> -The link:user-manual.html[Git User's Manual] provides a more
> +The link:user-manual.html[The Git User's Manual] provides a more
> comprehensive introduction to Git.
Doubled 'The'.
[...]
> --- a/Documentation/gittutorial.txt
> +++ b/Documentation/gittutorial.txt
> @@ -656,7 +656,7 @@ digressions that may be interesting at this point are:
> * linkgit:gitworkflows[7]: Gives an overview of recommended
> workflows.
>
> - * link:everyday.html[Everyday Git with 20 Commands Or So]
> + * link:everyday.html[Everyday Git]
Isn't the old title more informative?
Thanks and hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with
From: Sebastian Schuberth @ 2013-02-01 20:07 UTC (permalink / raw)
To: Sven Strickroth; +Cc: git, Junio C Hamano, David Aguilar, Jeff King
In-Reply-To: <510C1872.3090304@tu-clausthal.de>
On Fri, Feb 1, 2013 at 8:33 PM, Sven Strickroth
<sven.strickroth@tu-clausthal.de> wrote:
> TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
> with spaces in them by using -option "$FILE" (not -option:"$FILE",
> which does not work for such paths) syntax. Both do not have a fully
> posix compatible cli parameter parser, however, TortoiseGitMerge was
> modified in order to handle filenames with spaces correctly. The
> "-key value" form was choosen because this way no escaping for
> quotes within quotes is necessary; see
> https://github.com/msysgit/msysgit/issues/57
The commit message still does not mention MSYS path mangling at all,
which probably is why the reasoning of this patch was not yet fully
understood. I'd recommend something like the following:
mergetools: Teach tortoisemerge about TortoiseGitMerge
TortoiseGitMerge is an improved version of TortoiseMerge specifically
for use with Git on Windows. Due to MSYS path mangling [1], the ":"
after the "base" etc. arguments to TortoiseMerge caused to whole
argument instead of just the file name to be quoted in case of file
names with spaces. So TortoiseMerge was passed
"-base:new file.txt"
instead of
-base:"new file.txt"
(including the quotes). To work around this, TortoiseGitMerge does not
require the ":" after the arguments anymore which fixes handling file
names with spaces.
[1] http://www.mingw.org/wiki/Posix_path_conversion
--
Sebastian Schuberth
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with
From: Junio C Hamano @ 2013-02-01 20:15 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: Sven Strickroth, git, David Aguilar, Jeff King
In-Reply-To: <CAHGBnuNpHtfnD6D+sji6e1yp2x6iLxjAbawwO6USF2iWW17nuQ@mail.gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> The commit message still does not mention MSYS path mangling at all,
> which probably is why the reasoning of this patch was not yet fully
> understood.
Ahh, you are very right. I didn't realize that was what this funny
"with colon, with SP" business was about.
> I'd recommend something like the following:
>
> mergetools: Teach tortoisemerge about TortoiseGitMerge
>
> TortoiseGitMerge is an improved version of TortoiseMerge specifically
> for use with Git on Windows. Due to MSYS path mangling [1], the ":"
> after the "base" etc. arguments to TortoiseMerge caused to whole
> argument instead of just the file name to be quoted in case of file
> names with spaces. So TortoiseMerge was passed
>
> "-base:new file.txt"
>
> instead of
>
> -base:"new file.txt"
>
> (including the quotes). To work around this, TortoiseGitMerge does not
> require the ":" after the arguments anymore which fixes handling file
> names with spaces.
>
> [1] http://www.mingw.org/wiki/Posix_path_conversion
Sven?
^ permalink raw reply
* Re: [PATCH 2/6] fixup! fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
From: Junio C Hamano @ 2013-02-01 20:16 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Thomas Ackermann, git, davvid, Fredrik Gustafsson, Jens Lehmann
In-Reply-To: <20130201194308.GC12368@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
>> index c743469..14386ed 100644
>> --- a/Documentation/git-rev-parse.txt
>> +++ b/Documentation/git-rev-parse.txt
>> @@ -187,9 +187,9 @@ print a message to stderr and exit with nonzero status.
>> Flags and parameters to be parsed.
>>
>> --resolve-git-dir <path>::
>> - Check if <path> is a valid git-dir or a git-file pointing to a valid
>> - git-dir. If <path> is a valid git-dir the resolved path to git-dir will
>> - be printed.
>> + Check if <path> is a valid `$GIT_DIR` or a gitfile pointing to a valid
>> + `$GIT_DIR`. If <path> is a valid `$GIT_DIR` the resolved path to `$GIT_DIR`
>> + will be printed.
>
> Hm, I don't find the old or the new version very easy to understand. Perhaps the
> idea is something like this?
>
> Check if <path> is a valid git repository (.git or <project>.git
> directory) or "gitdir:" file. If <path> is a "gitdir:" file
> then the resolved path to the corresponding real git repository
> will be printed.
Yeah, sounds much better.
^ permalink raw reply
* Re: [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
From: Junio C Hamano @ 2013-02-01 20:17 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Thomas Ackermann, git, davvid
In-Reply-To: <20130201195140.GE12368@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Thomas Ackermann wrote:
>
>> --- a/Documentation/git.txt
>> +++ b/Documentation/git.txt
>> @@ -23,7 +23,7 @@ and full access to internals.
>>
>> See linkgit:gittutorial[7] to get started, then see
>> link:everyday.html[Everyday Git] for a useful minimum set of
>> -commands. The link:user-manual.html[Git User's Manual] has a more
>> +commands. The link:user-manual.html[The Git User's Manual] has a more
>> in-depth introduction.
>
> In the rendered version, this looks like:
>
> The The Git User's Manual[1] has a more in-depth introduction.
>
> Presumably the first "The" should be dropped from either the link or
> the surrounding text.
>...
Thanks for a review; I'll drop this from today's integration cycle.
^ permalink raw reply
* Aw: Re: [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
From: Thomas Ackermann @ 2013-02-01 20:25 UTC (permalink / raw)
To: jrnieder, th.acker; +Cc: gitster, git, davvid
In-Reply-To: <20130201195140.GE12368@google.com>
>
> Presumably the first "The" should be dropped from either the link or
> the surrounding text.
>
> Doubled 'The'.
>
You are right. I missed that; sorry.
>
> Isn't the old title more informative?
>
Yes; but every other link just uses the shorter version "Everyday Git".
---
Thomas
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with
From: Sven Strickroth @ 2013-02-01 20:10 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git, Junio C Hamano, David Aguilar, Jeff King
In-Reply-To: <CAHGBnuNpHtfnD6D+sji6e1yp2x6iLxjAbawwO6USF2iWW17nuQ@mail.gmail.com>
Am 01.02.2013 21:07 schrieb Sebastian Schuberth:
> mergetools: Teach tortoisemerge about TortoiseGitMerge
This subject doesn't make any sense if we don't combine the two patches.
--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with
From: Sven Strickroth @ 2013-02-01 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sebastian Schuberth, git, David Aguilar, Jeff King
In-Reply-To: <7va9rnaiz4.fsf@alter.siamese.dyndns.org>
Am 01.02.2013 21:15 schrieb Junio C Hamano:
>> TortoiseGitMerge is an improved version of TortoiseMerge specifically
>> for use with Git on Windows. Due to MSYS path mangling [1], the ":"
>> after the "base" etc. arguments to TortoiseMerge caused to whole
>> argument instead of just the file name to be quoted in case of file
>> names with spaces. So TortoiseMerge was passed
>>
>> "-base:new file.txt"
>>
>> instead of
>>
>> -base:"new file.txt"
>>
>> (including the quotes). To work around this, TortoiseGitMerge does not
>> require the ":" after the arguments anymore which fixes handling file
>> names with spaces.
>>
>> [1] http://www.mingw.org/wiki/Posix_path_conversion
>
> Sven?
I just mailed a new patch. Thanks to Sebastian for pointing this out!
@Junio: Feel free to optimize the commit message.
--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply
* Re: [PATH/RFC] Revert "compat: add strtok_r()"
From: Jonathan Nieder @ 2013-02-01 20:49 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, David Michael Barr
In-Reply-To: <1359714786-1912-1-git-send-email-kusmabite@gmail.com>
Hi Erik,
Erik Faye-Lund wrote:
> This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc.
>
> commit 28c5d9e ("vcs-svn: drop string_pool") previously removed
> the only call-site for strtok_r. So let's get rid of the compat
> implementation as well.
Yes, good idea. Sorry I didn't take care of this at the time.
> Conflicts:
> Makefile
> config.mak.in
> configure.ac
Since the conflicts were straightforward, I'd drop this or replace it
with a quick description of any surprising choices made in resolving
them.
Thanks. With the fixup from your reply squashed in,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with spaces with TortoiseGitMerge
From: Sven Strickroth @ 2013-02-01 20:16 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git, Junio C Hamano, David Aguilar, Jeff King
In-Reply-To: <CAHGBnuNpHtfnD6D+sji6e1yp2x6iLxjAbawwO6USF2iWW17nuQ@mail.gmail.com>
TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
with spaces in them by using -option "$FILE" (not -option:"$FILE",
which does not work for such paths) syntax.
This change was necessary because of MSYS path mangling [1], the ":"
after the "base" etc. arguments to TortoiseMerge caused to whole
argument instead of just the file name to be quoted in case of file
names with spaces. So TortoiseMerge was passed
"-base:new file.txt"
instead of
-base:"new file.txt"
(including the quotes). To work around this, TortoiseGitMerge does not
require the ":" after the arguments anymore which fixes handling file
names with spaces [2] (as written above).
[1] http://www.mingw.org/wiki/Posix_path_conversion
[2] https://github.com/msysgit/msysgit/issues/57
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Reported-by: Sebastian Schuberth <sschuberth@gmail.com>
---
mergetools/tortoisemerge | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/mergetools/tortoisemerge b/mergetools/tortoisemerge
index 8476afa..3b89f1c 100644
--- a/mergetools/tortoisemerge
+++ b/mergetools/tortoisemerge
@@ -6,9 +6,17 @@ merge_cmd () {
if $base_present
then
touch "$BACKUP"
- "$merge_tool_path" \
- -base:"$BASE" -mine:"$LOCAL" \
- -theirs:"$REMOTE" -merged:"$MERGED"
+ basename="$(basename "$merge_tool_path" .exe)"
+ if test "$basename" = "tortoisegitmerge"
+ then
+ "$merge_tool_path" \
+ -base "$BASE" -mine "$LOCAL" \
+ -theirs "$REMOTE" -merged "$MERGED"
+ else
+ "$merge_tool_path" \
+ -base:"$BASE" -mine:"$LOCAL" \
+ -theirs:"$REMOTE" -merged:"$MERGED"
+ fi
check_unchanged
else
echo "$merge_tool_path cannot be used without a base" 1>&2
--
1.8.1.msysgit.1
^ permalink raw reply related
* Re: [PATCH] rebase --preserve-merges keeps empty merge commits
From: Phil Hord @ 2013-02-01 21:05 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, phil.hord, Neil Horman, Junio C Hamano
In-Reply-To: <CANiSa6gM1gpj0A6PC0qNVSaWvVrOBnSnjn2uKR9-cHSLAZ2OVA@mail.gmail.com>
Martin von Zweigbergk wrote:
> I'm working on a re-roll of
> http://thread.gmane.org/gmane.comp.version-control.git/205796
>
> and finally got around to including test cases for what you fixed in
> this patch. I want to make sure I'm testing what you fixed here. See
> questions below.
Thanks for that. I should have done this myself.
> On Sat, Jan 12, 2013 at 12:46 PM, Phil Hord <hordp@cisco.com> wrote:
>> Since 90e1818f9a (git-rebase: add keep_empty flag, 2012-04-20)
>> 'git rebase --preserve-merges' fails to preserve empty merge commits
>> unless --keep-empty is also specified. Merge commits should be
>> preserved in order to preserve the structure of the rebased graph,
>> even if the merge commit does not introduce changes to the parent.
>>
>> Teach rebase not to drop merge commits only because they are empty.
> Consider a history like
>
> # a---b---c
> # \ \
> # d---l
> # \
> # e
> # \
> # C
>
> where 'l' is tree-same with 'd' and 'C' introduces the same change as 'c'.
>
> My test case runs 'git rebase -p e l' and expects the result to look like
>
> # a---b---c
> # \ \
> # d \
> # \ \
> # e---l
>
This is probably right, but it is not exactly the case that caused my itch.
I think my branch looked like this:
# a---b---c
# \
# d---f
# \ \
# e---g
# \
# l
where g is tree-same with f. That is, e merged with f, but all of e's
changes were dropped in the merge.
So when I ran 'git rebase -p c l', I expected to end up with this:
# a---b---c
# \
# d---f
# \ \
# e---g
# \
# l
But instead, I got an error because git-rebase--interactive.sh decided
that g was empty, so it dropped it by commenting it out of the todo
list:
pick d
pick e
pick f
#pick g
pick l
At the end of this attempt, I got some odd error about a cherry-pick
have incorrect parameters or somesuch. I bisected the problem to a
commit that clued me in to one of my commits being silently dropped.
And that is specifically what I fixed.
This happened only because 'is_empty_commit' checks for tree-sameness
with the first parent; it does not consider whether there are multiple
parents. Perhaps it should.
>> A special case which is not handled by this change is for a merge commit
>> whose parents are now the same commit because all the previous different
>> parents have been dropped as a result of this rebase or some previous
>> operation.
> And for this case, the test case runs 'git rebase -p C l'. Is that
> what you meant here?
>
> Before your patch, git would just say "Nothing to do"
Huh. That is worse than I thought.
> and after your
> patch, we get
>
> # a---b---c
> # \ \
> # d \
> # \ \
> # e \
> # \ \
> # C---l
>
> As you say, your patch doesn't try to handle this case, but at least
> the new behavior seems better. I think we would ideally want the
> recreated 'l' to have only 'C' as parent in this case. Does that make
> sense?
This is not what I meant, but it is a very interesting corner case. I
am not sure I have a solid opinion on what the result should be here.
I feel like it should look the same as you show here, since neither
'c' nor 'C' is a candidate for collapsing during this rebase. But I may
be missing some subtlety here.
Here is the corner case I was thinking of. I did not test this to see
if this will happen, but I conceived that it might. Suppose you have
this tree where
# a---b---c
# \
# d---g---l
# \ /
# C
where 'C' introduced the same changes as 'c'.
When I execute 'git rebase -p l c', I expect that I will end up with
this:
# a---b---c---d---
# \ \
# ---g---l
That is, 'C' gets skipped because it introduces the same changes already
seen in 'c'. So 'g' now has two parents: 'd' and 'C^'. But 'C^' is 'd',
so 'g' now has two parents, both of whom are 'd'.
I think it should collapse to this instead:
# a---b---c---d---g---l
I don't think this occurs because of my patch, and I am not sure it
occurs at all. It is something that I considered when I was thinking of
failure scenarios for my patch.
I expect it also may happen if 'C' is an already-empty commit, or if
it is made empty after conflict resolution involving the user. I
mentioned it because I thought my patch _could_ address this if my
is_merge_commit test would also consider whether the parents are
distinct from each other or not.
I hope this is clear, but please let me know if I made it too confusing.
Phil
^ permalink raw reply
* What's cooking in git.git (Feb 2013, #01; Fri, 1)
From: Junio C Hamano @ 2013-02-01 22:09 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 sometime in the middle of this month.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* as/test-cleanup (2013-01-24) 1 commit
(merged to 'next' on 2013-01-28 at cc1147d)
+ t7102 (reset): don't hardcode SHA-1 in expected outputs
* bc/git-p4-for-python-2.4 (2013-01-30) 3 commits
(merged to 'next' on 2013-01-31 at 1096db1)
+ INSTALL: git-p4 does not support Python 3
(merged to 'next' on 2013-01-30 at 5d81ed2)
+ git-p4.py: support Python 2.4
+ git-p4.py: support Python 2.5
With small updates to remove dependency on newer features of
Python, keep git-p4 usable with older Python.
* jc/do-not-let-random-file-interfere-with-completion-tests (2013-01-24) 1 commit
(merged to 'next' on 2013-01-28 at df27f53)
+ t9902: protect test from stray build artifacts
Scripts to test bash completion was inherently flaky as it was
affected by whatever random things the user may have on $PATH.
* jc/no-git-config-in-clone (2013-01-11) 1 commit
(merged to 'next' on 2013-01-15 at feeffe1)
+ clone: do not export and unexport GIT_CONFIG
We stopped paying attention to $GIT_CONFIG environment that points
at a single configuration file from any command other than "git config"
quite a while ago, but "git clone" internally set, exported, and
then unexported the variable during its operation unnecessarily.
* jk/cvsimport-does-not-work-with-cvsps3 (2013-01-24) 1 commit
(merged to 'next' on 2013-01-28 at fef4eb2)
+ git-cvsimport.txt: cvsps-2 is deprecated
Warn people that other tools are more recommendable over
cvsimport+cvsps2 combo when doing a one-shot import, and cvsimport
will not work with cvsps3.
* jk/gc-auto-after-fetch (2013-01-26) 1 commit
(merged to 'next' on 2013-01-30 at 472d07b)
+ Merge branch 'jk/maint-gc-auto-after-fetch' into jk/gc-auto-after-fetch
(this branch uses jk/maint-gc-auto-after-fetch.)
This is to resolve merge conflicts early for the same topic to
recent codebase.
* jk/maint-gc-auto-after-fetch (2013-01-26) 2 commits
+ fetch-pack: avoid repeatedly re-scanning pack directory
+ fetch: run gc --auto after fetching
(this branch is used by jk/gc-auto-after-fetch.)
Help "fetch only" repositories that do not trigger "gc --auto"
often enough.
* jn/do-not-drop-username-when-reading-from-etc-mailname (2013-01-25) 1 commit
(merged to 'next' on 2013-01-28 at e0a8222)
+ ident: do not drop username when reading from /etc/mailname
We used to stuff "user@" and then append what we read from
/etc/mailname to come up with a default e-mail ident, but a bug
lost the "user@" part. This is to fix it.
* nd/edit-branch-desc-while-detached (2013-01-30) 1 commit
(merged to 'next' on 2013-01-30 at 69307d6)
+ branch: no detached HEAD check when editing another branch's description
(this branch is used by nd/branch-error-cases.)
Attempt to "branch --edit-description" an existing branch, while
being on a detached HEAD, errored out.
* nd/fetch-depth-is-broken (2013-01-11) 3 commits
(merged to 'next' on 2013-01-15 at 70a5ca7)
+ fetch: elaborate --depth action
+ upload-pack: fix off-by-one depth calculation in shallow clone
+ fetch: add --unshallow for turning shallow repo into complete one
"git fetch --depth" was broken in at least three ways. The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.
--------------------------------------------------
[New Topics]
* ft/transport-report-segv (2013-01-31) 1 commit
- push: fix segfault when HEAD points nowhere
A failure to push due to non-ff while on an unborn branch
dereferenced a NULL pointer while showing an error message.
Will merge to 'next'.
* sb/gpg-i18n (2013-01-31) 1 commit
- gpg: allow translation of more error messages
Will merge to 'next'.
* sb/gpg-plug-fd-leak (2013-01-31) 1 commit
- gpg: close stderr once finished with it in verify_signed_buffer()
Will merge to 'next'.
* sb/run-command-fd-error-reporting (2013-01-31) 1 commit
- run-command: be more informative about what failed
Will merge to 'next' after spelling stdout, etc. out.
* jk/remote-helpers-doc (2013-01-31) 2 commits
- [SQUASH] simplify maintenance of redirection pages
- Rename {git- => git}remote-helpers.txt
"git help remote-helpers" did not work; 'remote-helpers' is not
a subcommand name but a concept, so its documentation should have
been in gitremote-helpers, not git-remote-helpers.
Will merge to 'next' after squashing the fix in.
* sp/smart-http-content-type-check (2013-01-31) 1 commit
- Verify Content-Type from smart HTTP servers
The smart HTTP clients forgot to verify the content-type that comes
back from the server side to make sure that the request is being
handled properly.
Will merge to 'next'.
* jc/mention-tracking-for-pull-default (2013-01-31) 1 commit
- doc: mention tracking for pull.default
We stopped mentioning `tracking` is a deprecated but supported
synonym for `upstream` in pull.default even though we have no
intention of removing the support for it.
This is my "don't list it to catch readers' eyes, but make sure it
can be found if the reader looks for it" version; I'm not married
to the layout and am willing to take a replacement patch.
* jc/fake-ancestor-with-non-blobs (2013-01-31) 3 commits
- apply: diagnose incomplete submodule object name better
- apply: simplify build_fake_ancestor()
- git-am: record full index line in the patch used while rebasing
Rebasing the history of superproject with change in the submodule
has been broken since v1.7.12.
Will merge to 'next'.
* jk/doc-makefile-cleanup (2013-02-01) 1 commit
- Documentation/Makefile: clean up MAN*_TXT lists
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* dg/subtree-fixes (2013-01-08) 7 commits
- contrib/subtree: mkdir the manual directory if needed
- contrib/subtree: honor $(DESTDIR)
- contrib/subtree: fix synopsis and command help
- contrib/subtree: better error handling for "add"
- contrib/subtree: add --unannotate option
- contrib/subtree: use %B for split Subject/Body
- t7900: remove test number comments
contrib/subtree updates; there are a few more from T. Zheng that
were posted separately, with an overlap.
Expecting a reroll.
* mp/diff-algo-config (2013-01-16) 3 commits
- diff: Introduce --diff-algorithm command line option
- config: Introduce diff.algorithm variable
- git-completion.bash: Autocomplete --minimal and --histogram for git-diff
Add diff.algorithm configuration so that the user does not type
"diff --histogram".
Looking better; may want tests to protect it from future breakages,
but otherwise it looks ready for 'next'.
Expecting a follow-up to add tests.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* jl/submodule-deinit (2012-12-04) 1 commit
- submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Expecting a reroll.
$gmane/212884
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
- Teach git-completion about git p4
Comment from Pete will need to be addressed ($gmane/206172).
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Stalled mostly due to lack of responses.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
* nd/parse-pathspec (2013-01-11) 20 commits
. Convert more init_pathspec() to parse_pathspec()
. Convert add_files_to_cache to take struct pathspec
. Convert {read,fill}_directory to take struct pathspec
. Convert refresh_index to take struct pathspec
. Convert report_path_error to take struct pathspec
. checkout: convert read_tree_some to take struct pathspec
. Convert unmerge_cache to take struct pathspec
. Convert read_cache_preload() to take struct pathspec
. add: convert to use parse_pathspec
. archive: convert to use parse_pathspec
. ls-files: convert to use parse_pathspec
. rm: convert to use parse_pathspec
. checkout: convert to use parse_pathspec
. rerere: convert to use parse_pathspec
. status: convert to use parse_pathspec
. commit: convert to use parse_pathspec
. clean: convert to use parse_pathspec
. Export parse_pathspec() and convert some get_pathspec() calls
. Add parse_pathspec() that converts cmdline args to struct pathspec
. pathspec: save the non-wildcard length part
Uses the parsed pathspec structure in more places where we used to
use the raw "array of strings" pathspec.
Ejected from 'pu' for now; will take a look at the rerolled one
later ($gmane/213340).
--------------------------------------------------
[Cooking]
* ab/gitweb-use-same-scheme (2013-01-28) 1 commit
- gitweb: refer to picon/gravatar images over the same scheme
Avoid mixed contents on a page coming via http and https when
gitweb is hosted on a https server.
Will merge to 'next'.
* jk/python-styles (2013-01-30) 1 commit
- CodingGuidelines: add Python coding guidelines
Will merge to 'next'.
* mn/send-email-authinfo (2013-01-29) 1 commit
- git-send-email: add ~/.authinfo parsing
Expecting a reroll.
$gmane/215004, $gmane/215024.
* mp/complete-paths (2013-01-11) 1 commit
(merged to 'next' on 2013-01-30 at 70e4f1a)
+ git-completion.bash: add support for path completion
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
This is logically the right thing to do, and we would really love
to see people who have been involved in completion code to review
and comment on the implementation.
Will cook in 'next' to see if anybody screams.
* jk/read-commit-buffer-data-after-free (2013-01-26) 3 commits
(merged to 'next' on 2013-01-30 at c6d7e16)
+ logmsg_reencode: lazily load missing commit buffers
+ logmsg_reencode: never return NULL
+ commit: drop useless xstrdup of commit message
Clarify the ownership rule for commit->buffer field, which some
callers incorrectly accessed without making sure it is populated.
Will merge to 'master'.
* pw/git-p4-on-cygwin (2013-01-26) 21 commits
(merged to 'next' on 2013-01-30 at 958ae3a)
+ git p4: introduce gitConfigBool
+ git p4: avoid shell when calling git config
+ git p4: avoid shell when invoking git config --get-all
+ git p4: avoid shell when invoking git rev-list
+ git p4: avoid shell when mapping users
+ git p4: disable read-only attribute before deleting
+ git p4 test: use test_chmod for cygwin
+ git p4: cygwin p4 client does not mark read-only
+ git p4 test: avoid wildcard * in windows
+ git p4 test: use LineEnd unix in windows tests too
+ git p4 test: newline handling
+ git p4: scrub crlf for utf16 files on windows
+ git p4: remove unreachable windows \r\n conversion code
+ git p4 test: translate windows paths for cygwin
+ git p4 test: start p4d inside its db dir
+ git p4 test: use client_view in t9806
+ git p4 test: avoid loop in client_view
+ git p4 test: use client_view to build the initial client
+ git p4: generate better error message for bad depot path
+ git p4: remove unused imports
+ git p4: temp branch name should use / even on windows
Improve "git p4" on Cygwin.
Will merge to 'master'.
* ss/mergetools-tortoise (2013-02-01) 2 commits
- mergetools: teach tortoisemerge to handle filenames with SP correctly
- mergetools: support TortoiseGitMerge
Update mergetools to work better with newer merge helper tortoise ships.
Will merge to 'next'.
* da/mergetool-docs (2013-01-30) 7 commits
- doc: generate a list of valid merge tools
- mergetool--lib: list user configured tools in '--tool-help'
- fixup! doc: generate a list of valid merge tools
- fixup! mergetool--lib: add functions for finding available tools
- mergetool--lib: add functions for finding available tools
- mergetool--lib: improve the help text in guess_merge_tool()
- mergetool--lib: simplify command expressions
(this branch uses jk/mergetool.)
Build on top of the clean-up done by jk/mergetool and automatically
generate the list of mergetool and difftool backends the build
supports to be included in the documentation.
Will merge to 'next', after squashing the fixup! commits from John
Keeping.
* nd/branch-error-cases (2013-01-31) 6 commits
- branch: let branch filters imply --list
- docs: clarify git-branch --list behavior
- branch: mark more strings for translation
- Merge branch 'nd/edit-branch-desc-while-detached' into HEAD
- branch: give a more helpful message on redundant arguments
- branch: reject -D/-d without branch name
Fix various error messages and conditions in "git branch", e.g. we
advertised "branch -d/-D" to remove one or more branches but actually
implemented removal of zero or more branches---request to remove no
branches was not rejected.
Will merge to 'next'.
* jc/push-reject-reasons (2013-01-24) 4 commits
(merged to 'next' on 2013-01-28 at b60be93)
+ push: finishing touches to explain REJECT_ALREADY_EXISTS better
+ push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
+ push: further simplify the logic to assign rejection reason
+ push: further clean up fields of "struct ref"
Improve error and advice messages given locally when "git push"
refuses when it cannot compute fast-forwardness by separating these
cases from the normal "not a fast-forward; merge first and push
again" case.
Will merge to 'master'.
* jk/mergetool (2013-01-28) 8 commits
- mergetools: simplify how we handle "vim" and "defaults"
- mergetool--lib: don't call "exit" in setup_tool
- mergetool--lib: improve show_tool_help() output
- mergetools/vim: remove redundant diff command
- git-difftool: use git-mergetool--lib for "--tool-help"
- git-mergetool: don't hardcode 'mergetool' in show_tool_help
- git-mergetool: remove redundant assignment
- git-mergetool: move show_tool_help to mergetool--lib
(this branch is used by da/mergetool-docs.)
Cleans up mergetool/difftool combo.
This is looking ready for 'next'.
* mm/add-u-A-sans-pathspec (2013-01-28) 1 commit
(merged to 'next' on 2013-01-28 at fe762a6)
+ add: warn when -u or -A is used without pathspec
Forbid "git add -u" and "git add -A" without pathspec run from a
subdirectory, to train people to type "." (or ":/") to make the
choice of default does not matter.
Will merge to 'master'.
* jc/hidden-refs (2013-01-30) 8 commits
- WIP: receive.allowupdatestohidden
- fetch: fetch objects by their exact SHA-1 object names
- upload-pack: optionally allow fetching from the tips of hidden refs
- fetch: use struct ref to represent refs to be fetched
- parse_fetch_refspec(): clarify the codeflow a bit
- upload/receive-pack: allow hiding ref hierarchies
- upload-pack: simplify request validation
- upload-pack: share more code
Allow the server side to unclutter the refs/ namespace it shows to
the client. Optionally allow requests for histories leading to the
tips of hidden refs by updated clients.
* ta/doc-no-small-caps (2013-02-01) 6 commits
- Documentation: StGit is the right spelling, not StGIT
- Documentation: describe the "repository" in repository-layout
- Documentation: add a description for 'gitfile' to glossary
- Documentation: do not use undefined terms git-dir and git-file
- Documentation: the name of the system is 'Git', not 'git'
- Documentation: avoid poor-man's small caps GIT
Update documentation to change "GIT" which was a poor-man's small
caps to "Git" which was the intended spelling. Also change "git"
spelled in all-lowercase to "Git" when it refers to the system as
the whole or the concept it embodies, as opposed to the command the
end users would type.
Will merge to 'next'.
* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
(merged to 'next' on 2013-01-30 at b639b47)
+ simplify-merges: drop merge from irrelevant side branch
The --simplify-merges logic did not cull irrelevant parents from a
merge that is otherwise not interesting with respect to the paths
we are following.
This touches a fairly core part of the revision traversal
infrastructure; even though I think this change is correct, please
report immediately if you find any unintended side effect.
Will merge to 'next'.
* jk/remote-helpers-in-python-3 (2013-01-30) 10 commits
(merged to 'next' on 2013-01-31 at 5a948aa)
+ git_remote_helpers: remove GIT-PYTHON-VERSION upon "clean"
(merged to 'next' on 2013-01-28 at d898471)
+ git-remote-testpy: fix path hashing on Python 3
(merged to 'next' on 2013-01-25 at acf9419)
+ git-remote-testpy: call print as a function
+ git-remote-testpy: don't do unbuffered text I/O
+ git-remote-testpy: hash bytes explicitly
+ svn-fe: allow svnrdump_sim.py to run with Python 3
+ git_remote_helpers: use 2to3 if building with Python 3
+ git_remote_helpers: force rebuild if python version changes
+ git_remote_helpers: fix input when running under Python 3
+ git_remote_helpers: allow building with Python 3
Prepare remote-helper test written in Python to be run with Python3.
Will merge to 'master'.
* jk/config-parsing-cleanup (2013-01-23) 8 commits
(merged to 'next' on 2013-01-28 at 9bc9411)
+ reflog: use parse_config_key in config callback
+ help: use parse_config_key for man config
+ submodule: simplify memory handling in config parsing
+ submodule: use parse_config_key when parsing config
+ userdiff: drop parse_driver function
+ convert some config callbacks to parse_config_key
+ archive-tar: use parse_config_key when parsing config
+ config: add helper function for parsing key names
Configuration parsing for tar.* configuration variables were
broken. Introduce a new config-keyname parser API to make the
callers much less error prone.
Will merge to 'master'.
* jc/custom-comment-char (2013-01-16) 1 commit
(merged to 'next' on 2013-01-25 at 91d8a5d)
+ Allow custom "comment char"
An illustration to show codepaths that need to be touched to change
the hint lines in the edited text to begin with something other
than '#'.
This is half my work and half by Ralf Thielow. There may still be
leftover '#' lurking around, though. My "git grep" says C code
should be already fine, but git-rebase--interactive.sh could be
converted (it should not matter, as the file is not really a
free-form text).
Will merge to 'master'.
* jc/push-2.0-default-to-simple (2013-01-16) 14 commits
(merged to 'next' on 2013-01-16 at 23f5df2)
+ t5570: do not assume the "matching" push is the default
+ t5551: do not assume the "matching" push is the default
+ t5550: do not assume the "matching" push is the default
(merged to 'next' on 2013-01-09 at 74c3498)
+ doc: push.default is no longer "matching"
+ push: switch default from "matching" to "simple"
+ t9401: do not assume the "matching" push is the default
+ t9400: do not assume the "matching" push is the default
+ t7406: do not assume the "matching" push is the default
+ t5531: do not assume the "matching" push is the default
+ t5519: do not assume the "matching" push is the default
+ t5517: do not assume the "matching" push is the default
+ t5516: do not assume the "matching" push is the default
+ t5505: do not assume the "matching" push is the default
+ t5404: do not assume the "matching" push is the default
Will cook in 'next' until Git 2.0 ;-).
* bc/append-signed-off-by (2013-01-27) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- commit, cherry-pick -s: remove broken support for multiline rfc2822 fields
- sequencer.c: rework search for start of footer to improve clarity
Waiting for the final round of reroll before merging to 'next'.
After that we will go incremental.
--------------------------------------------------
[Discarded]
* jk/update-install-for-p4 (2013-01-20) 1 commit
. INSTALL: git-p4 doesn't support Python 3
Made obsolete by bc/git-p4-for-python-2.4 topic.
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Junio C Hamano @ 2013-02-01 22:15 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201190007.GB22919@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Feb 01, 2013 at 10:52:52AM -0800, Junio C Hamano wrote:
>
>> > 4. Replace the rename "gitfoo" above with a "see git-foo..." pointer.
>> > Users of "git help foo" would not ever see this, but people who
>> > have trained their fingers to type "man gitfoo" would, along with
>> > anybody following an outdated HTML link.
>> >
>> > 5. Update internal references to "linkgit:gitfoo" to point to
>> > "git-foo".
>> >
>> > Hmm. That really does not seem so bad. The biggest downside is the
>> > people who have to see the redirect made in step 4.
>>
>> Yeah, I see that a show-stopper in the whole sequence.
>>
>> This is one of the "if we had perfect knowledge we would have
>> designed it this way, and we could still migrate our current system
>> to that ideal, but it is dubious the difference between the current
>> system and the ideal will outweigh the cost of migration" moment,
>> isn't it?
>
> Yeah, perhaps. I did the patch series just to see what the effort would
> be like. But at this point I am fine if we drop it (it sounded like
> Jonathan was in favor of this direction, so maybe he wants to make a
> final argument).
OK.
^ permalink raw reply
* Re: Re: Re: Re: Segmentation fault with latest git (070c57df)
From: Jonathan Nieder @ 2013-02-01 22:38 UTC (permalink / raw)
To: Jongman Heo; +Cc: Jeff King, Junio C Hamano, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <27376267.797831359716377823.JavaMail.weblogic@epml01>
Jongman Heo wrote:
>> But it doesn't stimulate any prerequisites in make, which is weird.
>> What's in builtin/.depend/fetch.o.d?
[...]
> please see below~.
>
> $ cat builtin/.depend/fetch.o.d
> fetch.o: builtin/fetch.c cache.h git-compat-util.h compat/bswap.h \
That's the problem. See the following thread:
http://thread.gmane.org/gmane.comp.version-control.git/185625/focus=185680
Currently when COMPUTE_HEADER_DEPENDENCIES=auto git tests for
dependency generation support by checking the output and exit status
from the following command:
$(CC) $(ALL_CFLAGS) -c -MF /dev/null -MMD -MP \
-x c /dev/null -o /dev/null 2>&1
Perhaps this can be improved? Even something as simple as a ccache
version test could presumably help a lot.
Hope that helps,
Jonathan
^ 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