* [PATCH v5] submodule: add 'deinit' command
From: Jens Lehmann @ 2013-02-17 20:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Phil Hord, Git Mailing List, Heiko Voigt, Michael J Gruber,
Marc Branchaud, W. Trevor King
In-Reply-To: <7vip5w6l8s.fsf@alter.siamese.dyndns.org>
With "git submodule init" the user is able to tell git he cares about one
or more submodules and wants to have it populated on the next call to "git
submodule update". But currently there is no easy way he could tell git he
does not care about a submodule anymore and wants to get rid of his local
work tree (except he knows a lot about submodule internals and removes the
"submodule.$name.url" setting from .git/config together with the work tree
himself).
Help those users by providing a 'deinit' command. This removes the whole
submodule.<name> section from .git/config either for the given
submodule(s) or for all those which have been initialized if '.' is
given. Fail if the current work tree contains modifications unless
forced. Complain when for a submodule given on the command line the url
setting can't be found in .git/config, but nonetheless don't fail.
Add tests and link the man pages of "git submodule deinit" and "git rm"
to assist the user in deciding whether removing or unregistering the
submodule is the right thing to do for him. Also add the deinit subcommand
to the completion list.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Am 13.02.2013 20:56, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Junio, this looks like a we have v5 as soon as we decide what to do
>> with the "not initialized" messages when '.' is used, right?
>
> OK. I myself do not deeply care if we end up special casing "." or
> not; I'll leave it up to you and other submodule folks.
Here we go, changes to v4 are:
- I decided to do the proposed special casing for "."; no messages
about uninitialized submodules will show up anymore (this is also
tested)
- The spelling fixes and better 'uninitialized' message Phil proposed
- Added the missing quotation for $sm_path in output strings
- "deinit" is added to the submodule completion list
- Added two missing "&&" in t7400
Documentation/git-rm.txt | 4 ++
Documentation/git-submodule.txt | 18 +++++-
contrib/completion/git-completion.bash | 2 +-
git-submodule.sh | 79 +++++++++++++++++++++++++-
t/t7400-submodule-basic.sh | 101 +++++++++++++++++++++++++++++++++
5 files changed, 201 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 92bac27..1d876c2 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree.
Ignored files are deemed expendable and won't stop a submodule's work
tree from being removed.
+If you only want to remove the local checkout of a submodule from your
+work tree without committing the removal,
+use linkgit:git-submodule[1] `deinit` instead.
+
EXAMPLES
--------
`git rm Documentation/\*.txt`::
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index a0c9df8..bc06159 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -13,6 +13,7 @@ SYNOPSIS
[--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
+'git submodule' [--quiet] deinit [-f|--force] [--] <path>...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] [--rebase]
[--reference <repository>] [--merge] [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
@@ -134,6 +135,19 @@ init::
the explicit 'init' step if you do not intend to customize
any submodule locations.
+deinit::
+ Unregister the given submodules, i.e. remove the whole
+ `submodule.$name` section from .git/config together with their work
+ tree. Further calls to `git submodule update`, `git submodule foreach`
+ and `git submodule sync` will skip any unregistered submodules until
+ they are initialized again, so use this command if you don't want to
+ have a local checkout of the submodule in your work tree anymore. If
+ you really want to remove a submodule from the repository and commit
+ that use linkgit:git-rm[1] instead.
++
+If `--force` is specified, the submodule's work tree will be removed even if
+it contains local modifications.
+
update::
Update the registered submodules, i.e. clone missing submodules and
checkout the commit specified in the index of the containing repository.
@@ -213,8 +227,10 @@ OPTIONS
-f::
--force::
- This option is only valid for add and update commands.
+ This option is only valid for add, deinit and update commands.
When running add, allow adding an otherwise ignored submodule path.
+ When running deinit the submodule work trees will be removed even if
+ they contain local changes.
When running update, throw away local changes in submodules when
switching to a different commit; and always run a checkout operation
in the submodule, even if the commit listed in the index of the
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 059ba9d..7cee9bd 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2401,7 +2401,7 @@ _git_submodule ()
{
__git_has_doubledash && return
- local subcommands="add status init update summary foreach sync"
+ local subcommands="add status init deinit update summary foreach sync"
if [ -z "$(__git_find_on_cmdline "$subcommands")" ]; then
case "$cur" in
--*)
diff --git a/git-submodule.sh b/git-submodule.sh
index 004c034..0fb6ee0 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -8,6 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
+ or: $dashless [--quiet] deinit [-f|--force] [--] <path>...
or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: $dashless [--quiet] foreach [--recursive] <command>
@@ -547,6 +548,82 @@ cmd_init()
}
#
+# Unregister submodules from .git/config and remove their work tree
+#
+# $@ = requested paths (use '.' to deinit all submodules)
+#
+cmd_deinit()
+{
+ # parse $args after "submodule ... init".
+ while test $# -ne 0
+ do
+ case "$1" in
+ -f|--force)
+ force=$1
+ ;;
+ -q|--quiet)
+ GIT_QUIET=1
+ ;;
+ --)
+ shift
+ break
+ ;;
+ -*)
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+ done
+
+ if test $# = 0
+ then
+ die "$(eval_gettext "Use '.' if you really want to deinitialize all submodules")"
+ fi
+
+ module_list "$@" |
+ while read mode sha1 stage sm_path
+ do
+ die_if_unmatched "$mode"
+ name=$(module_name "$sm_path") || exit
+ url=$(git config submodule."$name".url)
+ if test -z "$url"
+ then
+ test $# -ne 1 || test "$@" = "." ||
+ say "$(eval_gettext "Submodule '\$name' is not initialized for path '\$sm_path'")"
+ continue
+ fi
+
+ # Remove the submodule work tree (unless the user already did it)
+ if test -d "$sm_path"
+ then
+ # Protect submodules containing a .git directory
+ if test -d "$sm_path/.git"
+ then
+ echo >&2 "$(eval_gettext "Submodule work tree '\$sm_path' contains a .git directory")"
+ die "$(eval_gettext "(use 'rm -rf' if you really want to remove it including all of its history)")"
+ fi
+
+ if test -z "$force"
+ then
+ git rm -n "$sm_path" ||
+ die "$(eval_gettext "Submodule work tree '\$sm_path' contains local modifications; use '-f' to discard them")"
+ fi
+ rm -rf "$sm_path" || say "$(eval_gettext "Could not remove submodule work tree '\$sm_path'")"
+ fi
+
+ mkdir "$sm_path" || say "$(eval_gettext "Could not create empty submodule directory '\$sm_path'")"
+
+ # Remove the whole section so we have a clean state when the
+ # user later decides to init this submodule again
+ git config --remove-section submodule."$name" &&
+ say "$(eval_gettext "Submodule '\$name' (\$url) unregistered for path '\$sm_path'")"
+ done
+}
+
+#
# Update each submodule path to correct revision, using clone and checkout as needed
#
# $@ = requested paths (default to all)
@@ -1157,7 +1234,7 @@ cmd_sync()
while test $# != 0 && test -z "$command"
do
case "$1" in
- add | foreach | init | update | status | summary | sync)
+ add | foreach | init | deinit | update | status | summary | sync)
command=$1
;;
-q|--quiet)
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 2683cba..e32b62b 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -757,4 +757,105 @@ test_expect_success 'submodule add with an existing name fails unless forced' '
)
'
+test_expect_success 'set up a second submodule' '
+ git submodule add ./init2 example2 &&
+ git commit -m "submodule example2 added"
+'
+
+test_expect_success 'submodule deinit should remove the whole submodule section from .git/config' '
+ git config submodule.example.foo bar &&
+ git config submodule.example2.frotz nitfol &&
+ git submodule deinit init &&
+ test -z "$(git config submodule.example.url)" &&
+ test -z "$(git config submodule.example.foo)" &&
+ test -n "$(git config submodule.example2.url)" &&
+ test -n "$(git config submodule.example2.frotz)" &&
+ test -f example2/.git &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit . deinits all initialized submodules' '
+ git submodule update --init &&
+ git config submodule.example.foo bar &&
+ git config submodule.example2.frotz nitfol &&
+ test_must_fail git submodule deinit &&
+ git submodule deinit . &&
+ test -z "$(git config submodule.example.url)" &&
+ test -z "$(git config submodule.example.foo)" &&
+ test -z "$(git config submodule.example2.url)" &&
+ test -z "$(git config submodule.example2.frotz)" &&
+ rmdir init example2
+'
+
+test_expect_success 'submodule deinit deinits a submodule when its work tree is missing or empty' '
+ git submodule update --init &&
+ rm -rf init example2/* example2/.git &&
+ git submodule deinit init example2 &&
+ test -z "$(git config submodule.example.url)" &&
+ test -z "$(git config submodule.example2.url)" &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit fails when the submodule contains modifications unless forced' '
+ git submodule update --init &&
+ echo X >>init/s &&
+ test_must_fail git submodule deinit init &&
+ test -n "$(git config submodule.example.url)" &&
+ test -f example2/.git &&
+ git submodule deinit -f init &&
+ test -z "$(git config submodule.example.url)" &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit fails when the submodule contains untracked files unless forced' '
+ git submodule update --init &&
+ echo X >>init/untracked &&
+ test_must_fail git submodule deinit init &&
+ test -n "$(git config submodule.example.url)" &&
+ test -f example2/.git &&
+ git submodule deinit -f init &&
+ test -z "$(git config submodule.example.url)" &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit fails when the submodule HEAD does not match unless forced' '
+ git submodule update --init &&
+ (
+ cd init &&
+ git checkout HEAD^
+ ) &&
+ test_must_fail git submodule deinit init &&
+ test -n "$(git config submodule.example.url)" &&
+ test -f example2/.git &&
+ git submodule deinit -f init &&
+ test -z "$(git config submodule.example.url)" &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit complains but does not fail when used on an uninitialized submodule' '
+ git submodule update --init &&
+ git submodule deinit init >actual &&
+ test_i18ngrep "Submodule .example. (.*) unregistered for path .init" actual &&
+ git submodule deinit init >actual &&
+ test_i18ngrep "Submodule .example. is not initialized for path .init" actual &&
+ git submodule deinit . >actual &&
+ test_i18ngrep "Submodule .example2. (.*) unregistered for path .example2" actual &&
+ test_i18ngrep ! "Submodule .example. is not initialized for path .init" actual &&
+ rmdir init example2
+'
+
+test_expect_success 'submodule deinit fails when submodule has a .git directory even when forced' '
+ git submodule update --init &&
+ (
+ cd init &&
+ rm .git &&
+ cp -R ../.git/modules/example .git &&
+ GIT_WORK_TREE=. git config --unset core.worktree
+ ) &&
+ test_must_fail git submodule deinit init &&
+ test_must_fail git submodule deinit -f init &&
+ test -d init/.git &&
+ test -n "$(git config submodule.example.url)"
+'
+
test_done
--
1.8.1.2.677.ga1bd48d
^ permalink raw reply related
* Re: Git bundles for backup and cloning: the Zaphod Beeblebrox thread
From: Alain Kalker @ 2013-02-17 19:51 UTC (permalink / raw)
To: git
In-Reply-To: <kfrb11$ugv$2@ger.gmane.org>
On Sun, 17 Feb 2013 19:28:33 +0000, Alain Kalker wrote:
> From the current documentation for git-bundle(1), it may not be clear
> for users unfamilliar with Git, how to create a bundle which can be used
> for backup purposes, or, more generally, to clone to a completely new
> repository.
>
> Philip Oakley has posted a documentation patch some time ago, but Junio
> has pointed out several concerns.
> Ref: http://thread.gmane.org/gmane.comp.version-control.git/205887/
> focus=205897
>
> Here's my attempt to summarize the concerns, adding some of my own, and
> a possible solution.
>
> 1. "Missing HEAD syndrome"
> $ git bundle create <bundle> master -or-
> $ git bundle create <bundle> <branchname...>
> -or-
> $ git bundle create <bundle> --branches -then-
> $ git clone <bundle> <dir>
>
> will be unable to checkout any files due to a missing ref for HEAD.
> Though this can be fixed by going into <dir> and doing `git checkout
> <ref>`, this is not very user-friendly.
>
> 2. "Detached HEAD syndrome"
> $ git bundle create <bundle> HEAD $ git clone <bundle> <dir>
> will checkout files alright, but leaves one in a "detached HEAD" state.
>
> 3. "Exploding HEAD syndrome"
> $ git bundle create <bundle> --all will add the HEAD, but will add refs
from refs/*, including all remotes,
> which is not desirable when cloning, unless one
> sets up all the remotes
as well.
>
> Finally, my solution for backing up only the local branches of a
> repository:
$ git bundle create <bundle> --branches HEAD # for backup purposes
-or-
$ git bundle create <bundle> master HEAD # for hosting or redistribution
> but this may not be very
> easy for new users to figure out on their own unless well documented
> (perhaps a new flag?)
>
> Any comments or suggestions (including HHGTTG references!) are very
> welcome.
>
> -Alain
^ permalink raw reply
* Git bundles for backup and cloning: the Zaphod Beeblebrox thread
From: Alain Kalker @ 2013-02-17 19:28 UTC (permalink / raw)
To: git
>From the current documentation for git-bundle(1), it may not be clear for
users unfamilliar with Git, how to create a bundle which can be used for
backup purposes, or, more generally, to clone to a completely new
repository.
Philip Oakley has posted a documentation patch some time ago, but Junio
has pointed out several concerns.
Ref: http://thread.gmane.org/gmane.comp.version-control.git/205887/
focus=205897
Here's my attempt to summarize the concerns, adding some of my own, and a
possible solution.
1. "Missing HEAD syndrome"
$ git bundle create <bundle> master
-or-
$ git bundle create <bundle> <branchname...>
-or-
$ git bundle create <bundle> --branches
-then-
$ git clone <bundle> <dir>
will be unable to checkout any files due to a missing ref for HEAD.
Though this can be fixed by going into <dir> and doing `git checkout
<ref>`, this is not very user-friendly.
2. "Detached HEAD syndrome"
$ git bundle create <bundle> HEAD
$ git clone <bundle> <dir>
will checkout files alright, but leaves one in a "detached HEAD" state.
3. "Exploding HEAD syndrome"
$ git bundle create <bundle> --all
will add the HEAD, but will add refs from refs/remotes/* too, which is
not desirable when cloning, unless one sets up all the remotes (e.g. by
restoring .git/config) as well.
Finally, my solution for backing up only the local branches of a
repository:
$ git bundle create <bundle> --branches HEAD
but this may not be very easy for new users to figure out on their own
unless well documented (perhaps a new flag?)
Any comments or suggestions (including HHGTTG references!) are very
welcome.
-Alain
^ permalink raw reply
* Re: [PATCH 3/3] remote-curl: sanity check ref advertisement from server
From: Jeff King @ 2013-02-17 19:28 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130217110533.GF6759@elie.Belkin>
On Sun, Feb 17, 2013 at 03:05:34AM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > If the smart HTTP response from the server is truncated for
> > any reason, we will get an incomplete ref advertisement. If
> > we then feed this incomplete list to "fetch-pack", one of a
> > few things may happen:
> >
> > 1. If the truncation is in a packet header, fetch-pack
> > will notice the bogus line and complain.
> >
> > 2. If the truncation is inside a packet, fetch-pack will
> > keep waiting for us to send the rest of the packet,
> > which we never will.
>
> Mostly harmless since the operator could hit ^C, but still unpleasant.
Fetching is not always interactive. The deadlock I ran into (and again,
I am not sure if this fixes it or not, but it is _a_ deadlock) was on a
server farm doing a large number of "fetch && checkout && deploy"
operations. Only some of them hung, but it took a while to figure out
what was going on.
> [...]
> > This fortunately doesn't happen in the normal fetching
> > workflow, because git-fetch first uses the "list" command,
> > which feeds the refs to get_remote_heads, which does notice
> > the error. However, you can trigger it by sending a direct
> > "fetch" to the remote-curl helper.
>
> Ah. Would a test for this make sense?
A test would be great, if you can devise a way to reliably produce
truncated git output (but still valid http output). In the real-world
problem I had, I believe the truncation was caused by an intermediate
reverse proxy that hit a timeout. I simulated truncation by using netcat
to replay munged http headers and git output.
I suspect the simplest portable thing would be a static file of
truncated git output, served by apache, which would need custom
configuration to serve it with the correct content-type header. It
seemed like a lot of test infrastructure to check for a very specific
thing, so I abandoned trying to make a test.
> > + if (verify_ref_advertisement(last->buf, last->len) < 0)
> > + die("ref advertisement is invalid at %s", refs_url);
>
> Won't this error out with
>
> protocol error: bad line length character: ERR
>
> instead of the current more helpful behavior for ERR lines?
I don't think so. Don't ERR lines appear inside their own packets? We
are just verifying that our packets are syntactically correct here, and
my reading of get_remote_heads is that the ERR appears inside the
packetized data.
The one thing we do also check, though, is that we end with a flush
packet. So depending on what servers produce, it may mean we trigger
this complaint instead of passing the ERR along to fetch-pack.
Rather than doing this fake syntactic verification, I wonder if we
should simply call get_remote_heads, which does a more thorough check
(and is what we _would_ call in the list case, and what fetch-pack will
call once we pass data to it). It's slightly less efficient, in that it
starts a new thread and actually builds the linked list of refs. But it
probably isn't that big a deal (and normal operation does a "list" first
which does that _anyway_).
> Same stylistic comment about "what would it mean for the return value
> to be positive?" as in patch 2/3.
Same response. :)
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] remote-curl: verify smart-http metadata lines
From: Jeff King @ 2013-02-17 19:14 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130217104939.GE6759@elie.Belkin>
On Sun, Feb 17, 2013 at 02:49:39AM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > --- a/remote-curl.c
> > +++ b/remote-curl.c
> [...]
> > @@ -155,11 +166,13 @@ static struct discovery* discover_refs(const char *service)
> [...]
> > - strbuf_reset(&buffer);
> > - while (packet_get_line(&buffer, &last->buf, &last->len) > 0)
> > - strbuf_reset(&buffer);
> > + if (read_packets_until_flush(&last->buf, &last->len) < 0)
>
> Style nit: this made me wonder "What would it mean if
> read_packets_until_flush() > 0?" Since the convention for this
> function is "0 for success", I would personally find
>
> if (read_packets_until_flush(...))
> handle error;
>
> easier to read.
My intent was that it followed the error convention of "negative is
error, 0 is success, and positive is not used, but reserved for
future use". And I tend to think the "< 0" makes it obvious that we are
interested in error. But I don't feel that strongly, so if people would
rather see it the other way, I can live with it.
> > + die("smart-http metadata lines are invalid at %s",
> > + refs_url);
>
> Especially given that other clients would be likely to run into
> trouble in the same situation, as long as this cooks in "next" for a
> suitable amount of time to catch bad servers, it looks like a good
> idea.
Yeah, I have a slight concern that this series would break something in
another implementation, so I would like to see this cook in "next" for a
while (and would be slated for master probably not in this release, but
in the next one). But I think this change is pretty straightforward. If
an implementation is producing bogus packet lines and expecting us not
to complain, it really needs to be fixed.
-Peff
^ permalink raw reply
* git clone tag shallow
From: Thibault Kruse @ 2013-02-17 19:13 UTC (permalink / raw)
To: git
Hi all,
I notice that using git 1.8.3, I can call
git clone repo1 repo2 --branch tagname
with a tag, not a branch. Is this going to be a stable and documented feature?
cheers,
Thibault
^ permalink raw reply
* Fwd: git clone combined with --depth, --branch and --single-branch
From: Thibault Kruse @ 2013-02-17 19:10 UTC (permalink / raw)
To: git
In-Reply-To: <CAByu6UVR7k-d8PkqhHBG-A1zTCETemjhch0OA7i6_56yBV_YyQ@mail.gmail.com>
Actually, using git 1.8.3, I get:
git clone repo1 repo2 --depth 1
warning: --depth is ignored in local clones; use file:// instead.
...
So I guess the warning says it all, it helps to read it.
^ permalink raw reply
* Re: [BUG] Git clone of a bundle fails, but works (somewhat) when run with strace
From: Philip Oakley @ 2013-02-17 18:04 UTC (permalink / raw)
To: git, Alain Kalker
In-Reply-To: <kfqkak$ugv$1@ger.gmane.org>
From: "Alain Kalker" <a.c.kalker@gmail.com>
Sent: Sunday, February 17, 2013 1:01 PM
> On Fri, 15 Feb 2013 23:01:09 -0500, Jeff King wrote:
>
>> On Sat, Feb 16, 2013 at 12:03:58AM +0000, Alain Kalker wrote:
>>
>>> ---test.sh---
>>> #!/bin/sh
[...]
>>
>> but that warning makes sense. You did not create a bundle that
>> contains
>> HEAD, therefore when we clone it, we do not know what to point HEAD
>> to.
>> You probably wanted "git bundle create ../repo.bundle --all" which
>> includes both "master" and "HEAD".
>
> That explains it, thanks! Maybe this could be added as an example to
> the
> documentation for `git bundle`? People looking at `man git-bundle`
> hoping
> to use it as one possible way to make a backup of a Git repository
> might
> not realize right away that --all is the way to specify all refs, like
> with `git log`.
I had posted a documentation patch back in Setemeber last year,
http://thread.gmane.org/gmane.comp.version-control.git/205887/focus=205897,
however Junio highlighted some additional concerns that I wasn't able to
respond to at the time.
It may be worth resurrecting once the concerns have been addressed.
>
>>
>> It would be slightly more accurate to say "the remote HEAD does not
>> exist", rather than "refers to nonexistent ref". It would perhaps be
>> nicer still for "git clone" to make a guess about the correct HEAD
>> when
>> one is not present (especially in the single-branch case, it is easy
>> to
>> make the right guess).
>>
>> Patches welcome. In the meantime, you can clone with "-b master" to
>> tell
>> it explicitly, or you can "git checkout master" inside the
>> newly-cloned
>> repository.
>
> Thanks again for your help, very welcome :-)
>
> Alain
>
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2899 / Virus Database: 2639/6108 - Release Date:
> 02/16/13
>
^ permalink raw reply
* Re: git clone combined with --depth, --branch and --single-branch
From: Thibault Kruse @ 2013-02-17 17:46 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <CACsJy8C5G7yy=KDtdsE-9aYTdSEO3v=-25WKtGnLALshXnE+uQ@mail.gmail.com>
Hi Duy,
On Sun, Feb 17, 2013 at 3:32 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Feb 17, 2013 at 7:29 PM, Thibault Kruse
> <tibokruse@googlemail.com> wrote:
>> git log --pretty=format:'%h-%s %d' --graph --decorate --all
>> * 4565162-5 (foo)
>> * 20ce846-4
>> * a0615eb-3
>> * fa4131d-2
>> * f0683bd-1 (bar)
>> | * 432b5ec-m1 (HEAD, master)
>> |/
>> * 39df203-0
>>
>> git clone repo1 repo2 --depth 1
>> cd repo2
>> git log --pretty=format:'%h-%s %d' --graph --decorate --all
>> * 432b5ec-m1 (HEAD, origin/master, origin/HEAD, master)
>> * 39df203-0
>>
>> # Why are branches "foo" and "bar" missing?
>
> --depth implies --single-branch. Without explicit --branch,
> --single-branch will fetch HEAD. You need --no-single-branch to get
> foo and bar.
Agreed, sorry. I forgot that --depth implied --single-branch. Probably
because it don't like that being a default that breaks behavior to
versions that did not have the --single-branch feature.
So this example is the only one which I agree does actually what can
be expected from the documentation (with respect to branches. --depth
also does not restrict the history length, but the example does not
show it).
>> cd ..
>> git clone repo1 repo3 --depth 1 --branch foo
>> git log --pretty=format:'%h-%s %d' --graph --decorate --all
>> * 4565162-5 (HEAD, origin/foo, foo)
>> * 20ce846-4
>> * a0615eb-3
>> * fa4131d-2
>> * f0683bd-1
>> | * 432b5ec-m1 (origin/master, origin/HEAD)
>> |/
>> * 39df203-0
>>
>> # Why is --depth not having effect, and why is branch bar not there,
>> yet master is?
>
> I'm not sure, but I can't reproduce it.
Do you mean you cannot reproduce with 1.7.10.4?
So far I used ubuntu packaged versions, Here is what I got with master:
git --version
git version 1.8.1.3.619.g7b6e784
# added commit m2 and m3 to master branch in repo1 to show that
--depth is not working locally
git clone repo1 repo2 --depth 1
git log --pretty=format:'%h-%s %d' --graph --decorate --all
* 704f0c4-m3 (HEAD, origin/master, origin/HEAD, master)
* 7b90b28-m2
* 1fa92bd-m1
* 5da3517-0
So I still get the --depth not having affect locally, but I confirm
all other cases I posted work as expected with 1.8.1.3.619.g7b6e784.
Meaning --depth works from a remote repo, and --single-branch (implied
by depth) really just creates that branch locally.
I don't even know where to start looking for why --depth has no effect
for disk-local remotes.
I don't have the git command aliased, and in repo1, I get:
alias.br=branch
alias.co=checkout
alias.ci=commit
alias.di=diff
alias.st=status
alias.mt=mergetool
alias.pr=pull --rebase
alias.ri=rebase --interactive
alias.sa=stash apply
alias.c-p=cherry-pick
alias.lg=!git log --pretty=format:%h%x09%an%x09%ad%x09%s
alias.lgg=log --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'
--abbrev-commit --date=relative
alias.top=!eval cd $(pwd)/$(git rev-parse --show-cdup) && pwd
core.excludesfile=/home/kruset/.bashconfig/gitignore.global
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
Not sure whether any of the "core" properties can cause this.
^ permalink raw reply
* Re: Re: [PATCH v2 02/15] user-manual: Update for receive.denyCurrentBranch=refuse
From: W. Trevor King @ 2013-02-17 17:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
In-Reply-To: <7v4nhezpta.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]
On Thu, Feb 14, 2013 at 10:57:21AM -0800, Junio C Hamano wrote:
> So let's tone everything down and do this instead:
>
> -- >8 --
> From: "W. Trevor King" <wking@tremily.us>
> Date: Fri, 8 Feb 2013 12:04:20 -0500
> Subject: [PATCH] user-manual: Update for receive.denyCurrentBranch=refuse
>
> acd2a45 (Refuse updating the current branch in a non-bare repository
> via push, 2009-02-11) changed the default to refuse such a push, but
> it forgot to update the docs.
>
> 7d182f5 (Documentation: receive.denyCurrentBranch defaults to
> 'refuse', 2010-03-17) updated Documentation/config.txt, but forgot to
> update the user manual.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/user-manual.txt | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 85651b5..7c534dc 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1986,9 +1986,10 @@ handling this case.
>
> Note that the target of a "push" is normally a
> <<def_bare_repository,bare>> repository. You can also push to a
> -repository that has a checked-out working tree, but the working tree
> -will not be updated by the push. This may lead to unexpected results if
> -the branch you push to is the currently checked-out branch!
> +repository that has a checked-out working tree, but a push to update the
> +currently checked-out branch is denied by default to prevent confusion.
> +See the description ofthe receive.denyCurrentBranch option
> +in linkgit:git-config[1] for details.
>
> As with `git fetch`, you may also set up configuration options to
> save typing; so, for example, after
Looks good to me.
Thanks,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] read_directory: avoid invoking exclude machinery on tracked files
From: Pete Wyckoff @ 2013-02-17 15:49 UTC (permalink / raw)
To: Duy Nguyen
Cc: git, Junio C Hamano, Karsten Blees, kusmabite,
Ramkumar Ramachandra, Robert Zeh, finnag
In-Reply-To: <CACsJy8C9SGJxwnm1E2N_KyEMg5-MzDt2B+SrX7rygn8X1qq4Wg@mail.gmail.com>
pclouds@gmail.com wrote on Sun, 17 Feb 2013 11:39 +0700:
> On Sun, Feb 17, 2013 at 1:11 AM, Pete Wyckoff <pw@padd.com> wrote:
> > pclouds@gmail.com wrote on Sat, 16 Feb 2013 14:17 +0700:
> >> Finally some numbers (best of 20 runs) that shows why it's worth all
> >> the hassle:
> >>
> >> git status | webkit linux-2.6 libreoffice-core gentoo-x86
> >> -------------+----------------------------------------------
> >> before | 1.097s 0.208s 0.399s 0.539s
> >> after | 0.736s 0.159s 0.248s 0.501s
> >> nr. patterns | 89 376 19 0
> >> nr. tracked | 182k 40k 63k 101k
> >
> > Thanks for this work. I repeated some of the tests across NFS,
> > where I'd expect to see bigger differences.
>
> This is about reducing CPU processing time, not I/O time. So no bigger
> differences is expected. I/O time can be reduced with inotify, or fam
> in nfs case because inotify does not support nfs.
Numbers from the last mail were core.preloadindex=true. Here's
"time" output from average runs:
stock = 0m2.28s user 0m4.18s sys 0m11.28s elapsed 57.39 %CPU
duy = 0m1.25s user 0m4.43s sys 0m7.45s elapsed 76.41 %CPU
With this huge repo, preloadindex may be stressing directory
cache behavior on the NFS server or client. Your patch helps
both CPU and wait time by avoiding the 6000-odd open() of
non-existent .gitignore.
With core.preloadindex=false, it's a 1 sec speedup, all from CPU:
stock = 0m2.18s user 0m1.59s sys 0m7.78s elapsed 48.45 %CPU
duy = 0m1.17s user 0m1.63s sys 0m6.91s elapsed 40.59 %CPU
-- Pete
^ permalink raw reply
* Re: [PATCH 2/3] contrib/subtree/t: Added tests for .gitsubtree support
From: Paul Campbell @ 2013-02-17 15:26 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Adam Tkac, David A. Greene, Jesper L. Nielsen,
Michael Schubert, Techlive Zheng
In-Reply-To: <20130217113723.GA9882@elie.Belkin>
On Sun, Feb 17, 2013 at 11:37 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Paul Campbell wrote:
>
>> Is there was a better way to verify that the push operation succeeds
>> then grepping for a SHA1?
>
> IIRC then when a push fails, it will exit with nonzero status (so the
> usual &&-chaining would propagate the error).
>
> Alternatively, one can fetch, ls-remote, or enter the target repo and
> use history inspection tools to check that the result is as expected.
>
> Hope that helps,
> Jonathan
Thanks Jonathan.
Here's the updated version of the tests:
contrib/subtree/t/t7900-subtree.sh | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/contrib/subtree/t/t7900-subtree.sh
b/contrib/subtree/t/t7900-subtree.sh
index 80d3399..e7bb911 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -465,4 +465,37 @@ test_expect_success 'verify one file change per commit' '
))
'
+# return to mainline
+cd ../..
+
+# .gitsubtree
+test_expect_success 'added repository appears in .gitsubtree' '
+ git subtree add --prefix=copy0 sub1 &&
+ grep "^copy0 \. sub1$" .gitsubtree
+'
+
+test_expect_success 'change in subtree is pushed okay' '
+ (cd copy0 && create new_file && git commit -m"Added new_file") &&
+ git ls-tree refs/heads/sub1 >output &&
+ ! grep "new_file$" output &&
+ git subtree push --prefix=copy0 &&
+ git ls-tree refs/heads/sub1 >output &&
+ grep "new_file$" output
+'
+
+test_expect_success 'pull into subtree okay' '
+ git subtree add --prefix=copy1 sub1 &&
+ git subtree add --prefix=copy2 sub1 &&
+ (cd copy1 && create new_file_in_copy1 && git commit -m"Added
new_file_in_copy1") &&
+ git subtree push --prefix=copy1 &&
+ git subtree pull --prefix=copy2 | grep "^ create mode 100644
copy2/new_file_in_copy1$"
+'
+
+test_expect_success 'replace outdated entry in .gitsubtree' '
+ echo "copy3 . sub2" >>.gitsubtree &&
+ git subtree add --prefix=copy3 sub1 &&
+ ! grep "^copy3 . sub2$" .gitsubtree &&
+ grep "^copy3 . sub1$" .gitsubtree
+'
+
test_done
--
1.8.1.3.605.g02339dd
--
Paul [W] Campbell
^ permalink raw reply related
* Re: git clone combined with --depth, --branch and --single-branch
From: Duy Nguyen @ 2013-02-17 14:32 UTC (permalink / raw)
To: Thibault Kruse; +Cc: git
In-Reply-To: <CAByu6UWNZLrtwo+FUeq2OELoX3jo1Qng9amko36JGa5pq+y11A@mail.gmail.com>
On Sun, Feb 17, 2013 at 7:29 PM, Thibault Kruse
<tibokruse@googlemail.com> wrote:
> git log --pretty=format:'%h-%s %d' --graph --decorate --all
> * 4565162-5 (foo)
> * 20ce846-4
> * a0615eb-3
> * fa4131d-2
> * f0683bd-1 (bar)
> | * 432b5ec-m1 (HEAD, master)
> |/
> * 39df203-0
>
> git clone repo1 repo2 --depth 1
> cd repo2
> git log --pretty=format:'%h-%s %d' --graph --decorate --all
> * 432b5ec-m1 (HEAD, origin/master, origin/HEAD, master)
> * 39df203-0
>
> # Why are branches "foo" and "bar" missing?
--depth implies --single-branch. Without explicit --branch,
--single-branch will fetch HEAD. You need --no-single-branch to get
foo and bar.
> cd ..
> git clone repo1 repo3 --depth 1 --branch foo
> git log --pretty=format:'%h-%s %d' --graph --decorate --all
> * 4565162-5 (HEAD, origin/foo, foo)
> * 20ce846-4
> * a0615eb-3
> * fa4131d-2
> * f0683bd-1
> | * 432b5ec-m1 (origin/master, origin/HEAD)
> |/
> * 39df203-0
>
> # Why is --depth not having effect, and why is branch bar not there,
> yet master is?
I'm not sure, but I can't reproduce it. There's an unreleased fix in
depth calculation (682c7d2 (upload-pack: fix off-by-one depth
calculation in shallow clone - 2013-01-11) that might affect this. You
may want to try again with "master". I got this with the same command
* edbd6cb (grafted, HEAD, origin/foo, foo) 5
--
Duy
^ permalink raw reply
* Re: Anybody know a website with up-to-date git documentation?
From: Drew Northup @ 2013-02-17 13:21 UTC (permalink / raw)
To: Sitaram Chamarty
Cc: Junio C Hamano, Max Horn, John Keeping, git, Scott Chacon
In-Reply-To: <20130130230709.GA7787@sita-lt.atc.tcs.com>
On Wed, Jan 30, 2013 at 6:07 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On Wed, Jan 30, 2013 at 09:18:24AM -0800, Junio C Hamano wrote:
>> Max Horn <max@quendi.de> writes:
>> > On 30.01.2013, at 16:59, Sitaram Chamarty wrote:
>> >
>> >> I'm curious... what's wrong with 'git checkout html' from the git repo
>> >> and just browsing them using a web browser?
>> Armed with that knowledge, I think Sitaram may have something like
>> this:
>>
>> [remote "htmldocs"]
> Hmm; I don't recall ever doing that. But I just realised that
> my "html" branch is stuck at 1.7.7:
>
> $ git branch -v -v | grep html
> html 8fb66e5 [origin/html] Autogenerated HTML docs for v1.7.7-138-g7f41b6
>
> Is it possible that upto that point, the main git.git repo did
> carry this branch also?
Yes.
n1xim@atom:~/tmp/git_dev/git$ git branch -a
dn/utf16_check
* master
remotes/origin/HEAD -> origin/master
remotes/origin/html
remotes/origin/maint
remotes/origin/man
remotes/origin/master
remotes/origin/next
remotes/origin/pu
remotes/origin/todo
n1xim@atom:~/tmp/git_dev/git$ git remote show origin
* remote origin
Fetch URL: git://git.kernel.org/pub/scm/git/git.git
Push URL: git://git.kernel.org/pub/scm/git/git.git
HEAD branch: master
Remote branches:
maint tracked
master tracked
next tracked
pu tracked
refs/remotes/origin/html stale (use 'git remote prune' to remove)
refs/remotes/origin/man stale (use 'git remote prune' to remove)
todo tracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (local out of date)
n1xim@atom:~/tmp/git_dev/git$ git log refs/remotes/origin/html
commit 5723afaf3a61cef537e1f4dfa88f8faf31060ef0
Author: Junio C Hamano <junio@kernel.org>
Date: Wed Aug 31 00:49:23 2011 +0000
Autogenerated HTML docs for v1.7.7-rc0-72-g4b5ea
n1xim@atom:~/tmp/git_dev/git$ git log refs/remotes/origin/man
commit e193e4189407968b3c46992e3eac60d38424286e
Author: Junio C Hamano <junio@kernel.org>
Date: Wed Aug 31 00:49:25 2011 +0000
Autogenerated manpages for v1.7.7-rc0-72-g4b5ea
....I haven't bothered to plunge and expunge my local repo yet as I
never actually made use of those branches.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [BUG] Git clone of a bundle fails, but works (somewhat) when run with strace
From: Alain Kalker @ 2013-02-17 13:01 UTC (permalink / raw)
To: git
In-Reply-To: <20130216040109.GA31630@sigill.intra.peff.net>
On Fri, 15 Feb 2013 23:01:09 -0500, Jeff King wrote:
> On Sat, Feb 16, 2013 at 12:03:58AM +0000, Alain Kalker wrote:
>
>> ---test.sh---
>> #!/bin/sh
>>
>> make clean make || return 125 GIT=$(pwd)/git
>>
>> cd /tmp rm -rf testrepo mkdir testrepo cd testrepo $GIT init echo test
>> > test.txt $GIT add test.txt $GIT commit -m "Add test.txt"
>> $GIT bundle create ../testrepo.bundle master || return 125 cd ..
>>
>> rm -rf testrepofrombundle $GIT clone testrepo.bundle testrepofrombundle
>> || return 1 ---
>> I was unable to find a bad revision.
>> After a lot more searching I found that I had `git` aliased to `hub`, a
>> tool used to make Github actions easier.
>> Eliminating `hub` from the equation resolved most problems.
>
> Great.
>
>> The only ones remaining are the confusing error message from `git
>> bundle create` and the "missing HEAD" (you can interpret that in
>> different ways) ;-)
>
> I do not see any odd message from "bundle create" in the recipe above.
> Mine says:
>
> $ git bundle create ../repo.bundle master Counting objects: 3, done.
> Writing objects: 100% (3/3), 209 bytes, done.
> Total 3 (delta 0), reused 0 (delta 0)
>
> What you _might_ be seeing is the fact that the invocation above is
> likely to be running two different versions of git under the hood. "git
> bundle" will invoke "git rev-list", and it will use the first git in
> your PATH, even if it is not $GIT. The proper way to test an
> un-installed version of git is to use $YOUR_GIT_BUILD/bin-wrappers/git,
> which will set up environment variables sufficient to make sure all
> sub-gits are from the same version. Sometimes mixing versions can have
> weird results (e.g., the new "git bundle" expects "rev-list" to have a
> particular option, but the older version does not have it).
Thanks for the very useful tip! I will try to remember to use this for
any future testing.
> Secondly, I do get the same warning about HEAD:
>
> $ git clone repo.bundle repofrombundle Cloning into
> 'repofrombundle'...
> Receiving objects: 100% (3/3), done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> but that warning makes sense. You did not create a bundle that contains
> HEAD, therefore when we clone it, we do not know what to point HEAD to.
> You probably wanted "git bundle create ../repo.bundle --all" which
> includes both "master" and "HEAD".
That explains it, thanks! Maybe this could be added as an example to the
documentation for `git bundle`? People looking at `man git-bundle` hoping
to use it as one possible way to make a backup of a Git repository might
not realize right away that --all is the way to specify all refs, like
with `git log`.
>
> It would be slightly more accurate to say "the remote HEAD does not
> exist", rather than "refers to nonexistent ref". It would perhaps be
> nicer still for "git clone" to make a guess about the correct HEAD when
> one is not present (especially in the single-branch case, it is easy to
> make the right guess).
>
> Patches welcome. In the meantime, you can clone with "-b master" to tell
> it explicitly, or you can "git checkout master" inside the newly-cloned
> repository.
Thanks again for your help, very welcome :-)
Alain
^ permalink raw reply
* git clone combined with --depth, --branch and --single-branch
From: Thibault Kruse @ 2013-02-17 12:29 UTC (permalink / raw)
To: git
Hi all,
Using git 1.7.10.4
I find the behavior or documentation of "git clone --single-branch"
confusing. Docs currently say:
man git-clone
--single-branch
Clone only the history leading to the tip of a single
branch, either specified by the --branch option or the primary branch
remote�<80><99>s HEAD points
at. When creating a shallow clone with the --depth option,
this is the default, unless --no-single-branch is given to fetch the
histories near
the tips of all branches.
based onthis documentation, I cannot understand any of the results I
get when combining --depth and --singe-branch.
I start with this repo1 (for how to createin linux, see bottom):
git log --pretty=format:'%h-%s %d' --graph --decorate --all
* 4565162-5 (foo)
* 20ce846-4
* a0615eb-3
* fa4131d-2
* f0683bd-1 (bar)
| * 432b5ec-m1 (HEAD, master)
|/
* 39df203-0
git clone repo1 repo2 --depth 1
cd repo2
git log --pretty=format:'%h-%s %d' --graph --decorate --all
* 432b5ec-m1 (HEAD, origin/master, origin/HEAD, master)
* 39df203-0
# Why are branches "foo" and "bar" missing?
cd ..
git clone repo1 repo3 --depth 1 --branch foo
git log --pretty=format:'%h-%s %d' --graph --decorate --all
* 4565162-5 (HEAD, origin/foo, foo)
* 20ce846-4
* a0615eb-3
* fa4131d-2
* f0683bd-1
| * 432b5ec-m1 (origin/master, origin/HEAD)
|/
* 39df203-0
# Why is --depth not having effect, and why is branch bar not there,
yet master is?
cd ..
git clone repo1 repo4 --depth 1 --branch foo --single-branch
git log --pretty=format:'%h-%s %d' --graph --decorate --all
* 4565162-5 (HEAD, origin/foo, foo)
* 20ce846-4
* a0615eb-3
* fa4131d-2
* f0683bd-1
| * 432b5ec-m1 (origin/master, origin/HEAD)
|/
* 39df203-0
# Why is --depth not having effect, and why is branch master still there?
###################################
# Okay, so --depth seems to generally not work when cloning locally.
So maybe when doing so from github:
git clone https://github.com/git/git --depth 1
cd git
git log --pretty=format:'%h-%s %d' --graph --decorate --all
* 7b6e784-Update draft release notes to 1.8.2 (HEAD, origin/master,
origin/HEAD, master)
* 17e45f8-Merge branch
'wk/man-deny-current-branch-is-default-these-days' (grafted)
git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
git tag
>
# Why don't other branches appear here?
# Hm, I'll add "--branch master" to the command
git clone https://github.com/git/git git3 --depth 1 --branch master
cd git3
git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/next
remotes/origin/pu
remotes/origin/todo
git tag
> gitgui-0.10.0
> gitgui-0.10.1
> gitgui-0.10.2
> ...
# And why DO they appear here? Why do I now get all tags?
# Same result for --branch next
# okay, let's try adding --single-branch
git clone https://github.com/git/git git4 --depth 1 --branch next
--single-branch
cd git4
git branch -a
* next
remotes/origin/next
remotes/origin/pu
remotes/origin/todo
# Now I don't get master, but I still get those other branches??? And also tags?
Now I am aware that a bug was fixed in git 1.8.0:
https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.8.0.txt
* A repository created with "git clone --single" had its fetch
refspecs set up just like a clone without "--single", leading the
subsequent "git fetch" to slurp all the other branches, defeating
the whole point of specifying "only this branch".
But even considering that bug (and assuming it also affected git clone),
the results I get for 1.7.10.4 seem all weird, and not really
following the documentation.
So I am sorry I cannot phrase this as a single question, as the
results are not consistent with each other or the documentation, and
those results seem to be related.
cheers,
Thibault Kruse
How to create local repo1:
mkdir repo1
cd repo1
git init
echo 0 >> foo.txt
git add foo.txt
git commit -m 0
git co master -b bar
echo 1 >> bar.txt
git add bar.txt
git commit -m 1
git co bar -b foo
echo 2 >> foo.txt
git add foo.txt
git commit -m 2
echo 3 >> foo.txt
git add foo.txt
git commit -m 3
echo 4 >> foo.txt
git add foo.txt
git commit -m 4
echo 5 >> foo.txt
git add foo.txt
git commit -m 5
git co master
echo 1 > master.txt
git add master.txt
git commit -m m1
^ permalink raw reply
* Re: [PATCH 2/3] contrib/subtree/t: Added tests for .gitsubtree support
From: Jonathan Nieder @ 2013-02-17 11:37 UTC (permalink / raw)
To: Paul Campbell
Cc: git, Adam Tkac, David A. Greene, Jesper L. Nielsen,
Michael Schubert, Techlive Zheng
In-Reply-To: <CALeLG_nLz9Gfqcfk4EcWixRXbWC0x0GUVFDAKD20DGbkhRNWvQ@mail.gmail.com>
Paul Campbell wrote:
> Is there was a better way to verify that the push operation succeeds
> then grepping for a SHA1?
IIRC then when a push fails, it will exit with nonzero status (so the
usual &&-chaining would propagate the error).
Alternatively, one can fetch, ls-remote, or enter the target repo and
use history inspection tools to check that the result is as expected.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH 4/4] t7800: "defaults" is no longer a builtin tool name
From: Jonathan Nieder @ 2013-02-17 11:23 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git
In-Reply-To: <1360993666-81308-4-git-send-email-davvid@gmail.com>
David Aguilar wrote:
> t7800 tests that configured commands can override builtins,
> but this test was not adjusted when the "defaults" file was
> removed because the test continued to pass.
>
> Adjust the test to use the everlasting "vimdiff"
Heh. :)
> tool name
> instead of "defaults" so that it correctly tests against a tool
> that is known by mergetool--lib.
Makes sense. Thanks for a pleasant read.
Good night,
Jonathan
^ permalink raw reply
* Re: [PATCH 3/4] t7800: modernize tests
From: Jonathan Nieder @ 2013-02-17 11:21 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git
In-Reply-To: <1360993666-81308-3-git-send-email-davvid@gmail.com>
David Aguilar wrote:
> --- a/t/t7800-difftool.sh
> +++ b/t/t7800-difftool.sh
> @@ -10,29 +10,11 @@ Testing basic diff tool invocation
[...]
> -restore_test_defaults()
> -{
> - # Restores the test defaults used by several tests
> - remove_config_vars
> - unset GIT_DIFF_TOOL
> - unset GIT_DIFFTOOL_PROMPT
> - unset GIT_DIFFTOOL_NO_PROMPT
> - git config diff.tool test-tool &&
> - git config difftool.test-tool.cmd 'cat $LOCAL'
> - git config difftool.bogus-tool.cmd false
Yay. :)
[...]
> # Ensures that git-difftool ignores bogus --tool values
> test_expect_success PERL 'difftool ignores bad --tool values' '
> diff=$(git difftool --no-prompt --tool=bad-tool branch)
> test "$?" = 1 &&
> - test "$diff" = ""
> + test -z "$diff"
> '
Not about this patch: if I add more commands before that "diff",
their exit status would be ignored. Could this be made more resilient
using test_expect_code? Something like
test_expect_code 1 git diff --no-prompt --tool=bad-tool branch >actual &&
>expect &&
test_cmp expect actual
[...]
> # Specify the diff tool using $GIT_DIFF_TOOL
> test_expect_success PERL 'GIT_DIFF_TOOL variable' '
> - test_might_fail git config --unset diff.tool &&
> + difftool_test_setup &&
> + git config --unset diff.tool &&
> +
> GIT_DIFF_TOOL=test-tool &&
> export GIT_DIFF_TOOL &&
>
> diff=$(git difftool --no-prompt branch) &&
> test "$diff" = "branch" &&
> -
> - restore_test_defaults
> + sane_unset GIT_DIFF_TOOL
If this test fails, GIT_DIFF_TOOL would remain set which could take
down later tests, too. Could it be set in a subprocess (e.g., a
subshell) to avoid that?
difftool_test_setup &&
git config --unset diff.tool &&
echo branch >expect &&
GIT_DIFF_TOOL=test-tool git difftool --no-prompt branch >actual &&
test_cmp expect actual
[...]
> test_expect_success PERL 'GIT_DIFF_TOOL overrides' '
> - git config diff.tool bogus-tool &&
> - git config merge.tool bogus-tool &&
> -
> + difftool_test_setup &&
> + test_config diff.tool bogus-tool &&
> + test_config merge.tool bogus-tool &&
> GIT_DIFF_TOOL=test-tool &&
> export GIT_DIFF_TOOL &&
>
> diff=$(git difftool --no-prompt branch) &&
Likewise.
[...]
> GIT_DIFF_TOOL=bogus-tool &&
> export GIT_DIFF_TOOL &&
>
> diff=$(git difftool --no-prompt --tool=test-tool branch) &&
Likewise.
[...]
> test_expect_success PERL 'GIT_DIFFTOOL_NO_PROMPT variable' '
> + difftool_test_setup &&
> GIT_DIFFTOOL_NO_PROMPT=true &&
> export GIT_DIFFTOOL_NO_PROMPT &&
>
> diff=$(git difftool branch) &&
Likewise.
[...]
> test_expect_success PERL 'GIT_DIFFTOOL_PROMPT variable' '
> - git config difftool.prompt false &&
> + difftool_test_setup &&
> + test_config difftool.prompt false &&
> GIT_DIFFTOOL_PROMPT=true &&
> export GIT_DIFFTOOL_PROMPT &&
>
> prompt=$(echo | git difftool branch | tail -1) &&
Likewise. This one loses the exit status from 'git difftool',
which could be avoided by writing to temporary files:
echo >input &&
GIT_DIFFTOOL_PROMPT=true git difftool branch <input >output &&
prompt=$(tail -1 <output) &&
[...]
> test_expect_success PERL 'difftool last flag wins' '
> + difftool_test_setup &&
> diff=$(git difftool --prompt --no-prompt branch) &&
> test "$diff" = "branch" &&
>
> - restore_test_defaults &&
> -
> prompt=$(echo | git difftool --no-prompt --prompt branch | tail -1) &&
[...]
Likewise.
Thanks for cleaning up, and sorry I don't have anything more
substantial to offer.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH 3/3] remote-curl: sanity check ref advertisement from server
From: Jonathan Nieder @ 2013-02-17 11:05 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130216064929.GC22626@sigill.intra.peff.net>
Jeff King wrote:
> If the smart HTTP response from the server is truncated for
> any reason, we will get an incomplete ref advertisement. If
> we then feed this incomplete list to "fetch-pack", one of a
> few things may happen:
>
> 1. If the truncation is in a packet header, fetch-pack
> will notice the bogus line and complain.
>
> 2. If the truncation is inside a packet, fetch-pack will
> keep waiting for us to send the rest of the packet,
> which we never will.
Mostly harmless since the operator could hit ^C, but still unpleasant.
[...]
> This fortunately doesn't happen in the normal fetching
> workflow, because git-fetch first uses the "list" command,
> which feeds the refs to get_remote_heads, which does notice
> the error. However, you can trigger it by sending a direct
> "fetch" to the remote-curl helper.
Ah. Would a test for this make sense?
[...]
> --- a/remote-curl.c
> +++ b/remote-curl.c
[...]
> @@ -174,6 +183,9 @@ static struct discovery* discover_refs(const char *service)
> die("smart-http metadata lines are invalid at %s",
> refs_url);
>
> + if (verify_ref_advertisement(last->buf, last->len) < 0)
> + die("ref advertisement is invalid at %s", refs_url);
Won't this error out with
protocol error: bad line length character: ERR
instead of the current more helpful behavior for ERR lines?
Same stylistic comment about "what would it mean for the return value
to be positive?" as in patch 2/3.
Aside from those two details, the idea looks sane, though. Good
catch, and thanks for a pleasant read.
Good night,
Jonathan
^ permalink raw reply
* Re: [PATCH 2/3] remote-curl: verify smart-http metadata lines
From: Jonathan Nieder @ 2013-02-17 10:49 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130216064707.GB22626@sigill.intra.peff.net>
Jeff King wrote:
> --- a/remote-curl.c
> +++ b/remote-curl.c
[...]
> @@ -155,11 +166,13 @@ static struct discovery* discover_refs(const char *service)
[...]
> - strbuf_reset(&buffer);
> - while (packet_get_line(&buffer, &last->buf, &last->len) > 0)
> - strbuf_reset(&buffer);
> + if (read_packets_until_flush(&last->buf, &last->len) < 0)
Style nit: this made me wonder "What would it mean if
read_packets_until_flush() > 0?" Since the convention for this
function is "0 for success", I would personally find
if (read_packets_until_flush(...))
handle error;
easier to read.
> + die("smart-http metadata lines are invalid at %s",
> + refs_url);
Especially given that other clients would be likely to run into
trouble in the same situation, as long as this cooks in "next" for a
suitable amount of time to catch bad servers, it looks like a good
idea.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH 1/3] pkt-line: teach packet_get_line a no-op mode
From: Jonathan Nieder @ 2013-02-17 10:41 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130216064612.GA22626@sigill.intra.peff.net>
Jeff King wrote:
> --- a/pkt-line.c
> +++ b/pkt-line.c
> @@ -234,9 +234,10 @@ int packet_get_line(struct strbuf *out,
> *src_len -= 4;
> len -= 4;
>
> - strbuf_add(out, *src_buf, len);
> + if (out)
> + strbuf_add(out, *src_buf, len);
> + packet_trace(*src_buf, len, 0);
> *src_buf += len;
> *src_len -= len;
> - packet_trace(out->buf, out->len, 0);
> return len;
For what it's worth,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
The above code has a structure of
prepare to return(buf, len);
trace(buf, len);
discard used part of buf;
return;
which is nice and readable.
Jonathan
^ permalink raw reply
* Re: rev-parse fails on objects that contain colon
From: Orgad Shaneh @ 2013-02-17 8:48 UTC (permalink / raw)
To: git
In-Reply-To: <CAGHpTBJXM4F3=n3g_Lcb7Dnxkmya5KYeJ5XAsY0PtxftYmUeMw@mail.gmail.com>
On Sun, Feb 17, 2013 at 10:37 AM, Orgad Shaneh <orgads@gmail.com> wrote:
> $ git stash save foo:bar
> HEAD is now at 9f88dce Foo
> $ git stash pop foo:bar
> fatal: Invalid object name 'foo'.
> $ git rev-parse foo:bar
> foo:bar
> fatal: Invalid object name 'foo'.
>
> Tested on Windows (msysGit) and Linux.
>
> - Orgad
Oops! stash pop requires explicit stash. Disregard my message...
- Orgad
^ permalink raw reply
* rev-parse fails on objects that contain colon
From: Orgad Shaneh @ 2013-02-17 8:37 UTC (permalink / raw)
To: git
$ git stash save foo:bar
HEAD is now at 9f88dce Foo
$ git stash pop foo:bar
fatal: Invalid object name 'foo'.
$ git rev-parse foo:bar
foo:bar
fatal: Invalid object name 'foo'.
Tested on Windows (msysGit) and Linux.
- Orgad
^ permalink raw reply
* Re: [PATCH v2] read_directory: avoid invoking exclude machinery on tracked files
From: Duy Nguyen @ 2013-02-17 4:39 UTC (permalink / raw)
To: Pete Wyckoff
Cc: git, Junio C Hamano, Karsten Blees, kusmabite,
Ramkumar Ramachandra, Robert Zeh, finnag
In-Reply-To: <20130216181110.GA27233@padd.com>
On Sun, Feb 17, 2013 at 1:11 AM, Pete Wyckoff <pw@padd.com> wrote:
> pclouds@gmail.com wrote on Sat, 16 Feb 2013 14:17 +0700:
>> Finally some numbers (best of 20 runs) that shows why it's worth all
>> the hassle:
>>
>> git status | webkit linux-2.6 libreoffice-core gentoo-x86
>> -------------+----------------------------------------------
>> before | 1.097s 0.208s 0.399s 0.539s
>> after | 0.736s 0.159s 0.248s 0.501s
>> nr. patterns | 89 376 19 0
>> nr. tracked | 182k 40k 63k 101k
>
> Thanks for this work. I repeated some of the tests across NFS,
> where I'd expect to see bigger differences.
This is about reducing CPU processing time, not I/O time. So no bigger
differences is expected. I/O time can be reduced with inotify, or fam
in nfs case because inotify does not support nfs.
> Best of 20 values reported in "min ...".
>
> webkit
> Stock min 9.61 avg 11.61 +/- 1.35 max 14.26
> Duy min 6.91 avg 7.67 +/- 0.46 max 8.71
>
> linux
> Stock min 2.27 avg 3.16 +/- 0.56 max 4.49
> Duy min 2.04 avg 3.12 +/- 0.69 max 4.87
>
> libreoffice-core
> Stock min 4.56 avg 5.79 +/- 0.79 max 7.08
> Duy min 3.96 avg 5.25 +/- 0.95 max 6.95
>
> Similar 30%-ish speedup on webkit. And an absolute gain
> of 2.7 seconds is quite nice.
>
> -- Pete
--
Duy
^ 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