* Re: [PATCH] Fix wrong failures in config test
From: Junio C Hamano @ 2011-01-10 18:30 UTC (permalink / raw)
To: Ingo Brückl; +Cc: git
In-Reply-To: <4d2b3198.674034bb.bm000@wupperonline.de>
Ingo Brückl <ib@wupperonline.de> writes:
> The tests after '--set in alternative GIT_CONFIG' failed because
> variable GIT_CONFIG was still set.
>
> Signed-off-by: Ingo Brückl <ib@wupperonline.de>
> ---
>
> Is it only me (bash 3.2.48(1)-release) experiencing these failures?
>
> t/t1300-repo-config.sh | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
t1300 first sources test-lib.sh that explicitly unsets GIT_CONFIG and the
tests that might touch GIT_CONFIG all do so by a single-shot assignment to
be exported, i.e.
GIT_CONFIG=other-config git config anwohner.park ausweis
that shouldn't affect the later test, unless the shell is broken.
With this patch, can you check which one of the new tests barf on you?
t/t1300-repo-config.sh | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index d0e5546..c91d166 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -7,6 +7,10 @@ test_description='Test git config in different settings'
. ./test-lib.sh
+test_expect_success 'is GIT_CONFIG set (0)?' '
+ test "z${GIT_CONFIG+set}" = z
+'
+
test -f .git/config && rm .git/config
git config core.penguin "little blue"
@@ -399,8 +403,17 @@ cat > expect << EOF
ein.bahn=strasse
EOF
+
+test_expect_success 'is GIT_CONFIG set (1)?' '
+ test "z${GIT_CONFIG+set}" = z
+'
+
GIT_CONFIG=other-config git config -l > output
+test_expect_success 'is GIT_CONFIG set (2)?' '
+ test "z${GIT_CONFIG+set}" = z
+'
+
test_expect_success 'alternative GIT_CONFIG' 'cmp output expect'
test_expect_success 'alternative GIT_CONFIG (--file)' \
@@ -419,6 +432,10 @@ test_expect_success 'refer config from subdirectory' '
GIT_CONFIG=other-config git config anwohner.park ausweis
+test_expect_success 'is GIT_CONFIG set (3)?' '
+ test "z${GIT_CONFIG+set}" = z
+'
+
cat > expect << EOF
[ein]
bahn = strasse
@@ -426,6 +443,10 @@ cat > expect << EOF
park = ausweis
EOF
+test_expect_success 'is GIT_CONFIG set (4)?' '
+ test "z${GIT_CONFIG+set}" = z
+'
+
test_expect_success '--set in alternative GIT_CONFIG' 'cmp other-config expect'
cat > .git/config << EOF
^ permalink raw reply related
* Re: [PATCH] submodule: fix relative url parsing for scp-style origin
From: Thomas Rast @ 2011-01-10 18:18 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Junio C Hamano, Mark Levedahl, Jeffrey Phillips Freeman
In-Reply-To: <20110110172227.GA7882@burratino>
Jonathan Nieder wrote:
>
> manually using a relative path as in
>
> git remote add origin subdir
>
> creates a remote that is not usable, perhaps because different parts
> of the code treat it as relative to different directories (.git or the
> toplevel).
Oh, now I see. I just assumed this was not supported without looking,
so thanks for double-checking.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Avoid unportable nested double- and backquotes in shell scripts.
From: Junio C Hamano @ 2011-01-10 18:09 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20110108090105.GB14536@gmx.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> diff --git a/contrib/examples/git-fetch.sh b/contrib/examples/git-fetch.sh
> index a314273..06caf6b 100755
> --- a/contrib/examples/git-fetch.sh
> +++ b/contrib/examples/git-fetch.sh
> @@ -67,7 +67,7 @@ do
> keep='-k -k'
> ;;
> --depth=*)
> - shallow_depth="--depth=`expr "z$1" : 'z-[^=]*=\(.*\)'`"
> + shallow_depth=--depth=`expr "z$1" : 'z-[^=]*=\(.*\)'`
> ;;
> --depth)
> shift
I do not very much like the idea of updating contrib/examples, one of
whose purposes is to document the historical implementation, to ship a
version that has never been battle tested in the field.
There also seem to be a few more uses of `` (the majority used $() even
back then) that are still left behind. To make it more useful to serve as
an example (which is the other purpose of contrib/examples), it would make
more sense to update them all at once.
> diff --git a/t/t9107-git-svn-migrate.sh b/t/t9107-git-svn-migrate.sh
> index 289fc31..3d2ae3e 100755
> --- a/t/t9107-git-svn-migrate.sh
> +++ b/t/t9107-git-svn-migrate.sh
> @@ -94,7 +94,7 @@ test_expect_success 'migrate --minimize on old inited layout' '
> echo "$svnrepo"$path > "$GIT_DIR"/svn/$ref/info/url ) || exit 1;
> done &&
> git svn migrate --minimize &&
> - test -z "`git config -l | grep "^svn-remote\.git-svn\."`" &&
> + ! git config -l | grep "^svn-remote\.git-svn\." &&
> git config --get-all svn-remote.svn.fetch > fetch.out &&
> grep "^trunk:refs/remotes/trunk$" fetch.out &&
> grep "^branches/a:refs/remotes/a$" fetch.out &&
^ permalink raw reply
* Re: [PATCH] docs: explain diff.*.binary option
From: Junio C Hamano @ 2011-01-10 17:59 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20110109201003.GA4406@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This was added long ago as part of the userdiff refactoring
> for textconv, as internally it made the code simpler and
> cleaner. However, there was never a concrete use case for
> actually using the config variable.
>
> Now that Matthieu Moy has provided such a use case, it's
> easy to explain it using his example.
Thanks. I take it that this documents 122aa6f (diff: introduce
diff.<driver>.binary, 2008-10-05) where you said...
This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.
I am scratching my head about the last sentence, though. Shouldn't that
be "false"? In the olden days, setting diff.foo.funcname made it text but
with this change it no longer is the case and instead binaryness is
determined by content inspection, so forcing "text" needs to be done by
saying "this is _not_ binary", no?
^ permalink raw reply
* Re: [PATCH] Fix wrong failures in config test
From: Jonathan Nieder @ 2011-01-10 17:29 UTC (permalink / raw)
To: Ingo Brückl; +Cc: git
In-Reply-To: <4d2b3ecd.7c62abb5.bm000@wupperonline.de>
Ingo Brückl wrote:
> Jonathan Nieder wrote on Mon, 10 Jan 2011 10:52:51 -0600:
>> How does output from "sh t1300-repo-config.sh -v -i" end?
>
> expecting success: git config --rename-section branch.eins branch.zwei
> fatal: No such section!
> not ok - 50 rename section
> # git config --rename-section branch.eins branch.zwei
Thanks.
> The problem is that the last 'git config' worked on other-config due to
> variable GIT_CONFIG.
I'm still missing something.
GIT_CONFIG=other-config git config -l > output
echo $GIT_CONFIG
should result in no output to stdout, right? In other words, the
construct
envvar=value git command
is not supposed to pollute the current environment.
It sounds like you've checked that "unset GIT_CONFIG" fixes it; what's
left is to explain why GIT_CONFIG had a value in the first place.
Confused,
Jonathan
^ permalink raw reply
* Re: [PATCH] submodule: fix relative url parsing for scp-style origin
From: Jonathan Nieder @ 2011-01-10 17:22 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano, Mark Levedahl, Jeffrey Phillips Freeman
In-Reply-To: <201101101805.13251.trast@student.ethz.ch>
Thomas Rast wrote:
> Jonathan Nieder wrote:
>> url = /local/path/with/a/colon:in:it
>> url = git://example.com/path/with/a/colon:in:it
>
> These work fine because the first case arm is "do we still have a
> slash?", and thus takes precedence over the colon splitting.
Ah, nice (sorry I missed that). So this can't create a regression
and for what it's worth
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
>> url = simple.subdir.of.cwd
>
> That's caught by the outer 'case':
I meant if remoteurl is not fully qualified. For what it's worth,
the answer seems to be that
git clone repo newdir
replaces "repo" with the absolute path "$(pwd)/repo" and manually
using a relative path as in
git remote add origin subdir
creates a remote that is not usable, perhaps because different parts
of the code treat it as relative to different directories (.git or the
toplevel).
Sorry for the laziness --- I should have just checked.
^ permalink raw reply
* Re: [PATCH] Fix wrong failures in config test
From: Ingo Brückl @ 2011-01-10 17:15 UTC (permalink / raw)
To: git
In-Reply-To: <20110110165251.GB7714@burratino>
Jonathan Nieder wrote on Mon, 10 Jan 2011 10:52:51 -0600:
> Could you explain the nature of the failures in more detail?
Yeah, sorry.
> What version of git are you building?
1.7.3.5
> Is GIT_CONFIG already set in the environment before you run
> t1300-repo-config.sh (it shouldn't matter)?
No.
> How does output from "sh t1300-repo-config.sh -v -i" end?
expecting success: git config --rename-section branch.eins branch.zwei
fatal: No such section!
not ok - 50 rename section
# git config --rename-section branch.eins branch.zwei
The problem is that the last 'git config' worked on other-config due to
variable GIT_CONFIG. Test 50 should work now on .git/config, but as
GIT_CONFIG is still set, it doesn't and fails.
Ingo
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.4-rc1
From: Junio C Hamano @ 2011-01-10 17:11 UTC (permalink / raw)
To: Johan Herland; +Cc: Junio C Hamano, git
In-Reply-To: <201101100221.34077.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> I can't find "git merge --abort" and "git notes merge" in this list.
> Suggested paragraphs:
>
> * "git merge" learned "--abort" option, synonymous to
> "git reset --merge" when a merge is in progress.
>
> * "git notes" learned the "merge" subcommand to merge notes refs.
> In addition to the default manual conflict resolution, there are
> also several notes merge strategies for automatically resolving
> notes merge conflicts.
Thanks.
^ permalink raw reply
* Re: [PATCH] submodule: fix relative url parsing for scp-style origin
From: Thomas Rast @ 2011-01-10 17:05 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Junio C Hamano, Mark Levedahl, Jeffrey Phillips Freeman
In-Reply-To: <20110110164801.GA7714@burratino>
Jonathan Nieder wrote:
> Thomas Rast wrote:
> > + case "$remoteurl" in
> > + */*)
> > + remoteurl="${remoteurl%/*}"
> > + ;;
> > + *:*)
> > + remoteurl="${remoteurl%:*}"
> > + sep=:
> > + ;;
>
> What happens to
>
> url = ssh://example.com:1234
> url = ftp://ftp.example.com
Neither specifies a repo, unless you count "the default dir on the
remote side" (do we support that?). The existing code would have
snipped at the / and constructed something like ssh:/otherrepo.
> url = /local/path/with/a/colon:in:it
> url = git://example.com/path/with/a/colon:in:it
These work fine because the first case arm is "do we still have a
slash?", and thus takes precedence over the colon splitting.
> url = simple.subdir.of.cwd
That's caught by the outer 'case':
case "$url" in
../*)
url="${url#../}"
# ... what we're discussing here
;;
./*)
url="${url#./}"
;;
*)
break;;
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] submodule: fix relative url parsing for scp-style origin
From: Junio C Hamano @ 2011-01-10 17:01 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Mark Levedahl, Jeffrey Phillips Freeman
In-Reply-To: <7a578ef3384a891cebd4a39421302983499771e0.1294655635.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> The function resolve_relative_url was not prepared to deal with an
> scp-style origin 'user@host:path' in the case where 'path' is only a
> single component. Fix this by extending the logic that strips one
> path component from the $remoteurl.
>
> Also add tests for both styles of URLs.
>
> Noticed-by: Jeffrey Phillips Freeman <jeffrey.freeman@syncleus.com>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> If Mark agrees with the fix, I think this should go in before 1.7.4
> since it's a pretty annoying bug.
Seems obvious to me from a cursory look; thanks.
^ permalink raw reply
* Re: [PATCH] Fix wrong failures in config test
From: Jonathan Nieder @ 2011-01-10 16:52 UTC (permalink / raw)
To: Ingo Brückl; +Cc: git
In-Reply-To: <4d2b3198.674034bb.bm000@wupperonline.de>
Ingo Brückl wrote:
> The tests after '--set in alternative GIT_CONFIG' failed because
> variable GIT_CONFIG was still set.
[...]
> Is it only me (bash 3.2.48(1)-release) experiencing these failures?
Could you explain the nature of the failures in more detail? What
version of git are you building? Is GIT_CONFIG already set in the
environment before you run t1300-repo-config.sh (it shouldn't matter)?
How does output from "sh t1300-repo-config.sh -v -i" end? If that
doesn't end up being helpful, how about "GIT_TRACE=1 sh -x
t1300-repo-config.sh -v -i"?
Regards,
Jonathan
^ permalink raw reply
* Re: [PATCH] submodule: fix relative url parsing for scp-style origin
From: Jonathan Nieder @ 2011-01-10 16:48 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano, Mark Levedahl, Jeffrey Phillips Freeman
In-Reply-To: <7a578ef3384a891cebd4a39421302983499771e0.1294655635.git.trast@student.ethz.ch>
Thomas Rast wrote:
> The function resolve_relative_url was not prepared to deal with an
> scp-style origin 'user@host:path' in the case where 'path' is only a
> single component. Fix this by extending the logic that strips one
> path component from the $remoteurl.
The above description does not mention that the relative URL in
question is "../otherpath". Anyway, I think it's a great idea; thanks
for doing it!
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
[...]
> @@ -37,12 +37,24 @@ resolve_relative_url ()
[...]
> - remoteurl="${remoteurl%/*}"
> + case "$remoteurl" in
> + */*)
> + remoteurl="${remoteurl%/*}"
> + ;;
> + *:*)
> + remoteurl="${remoteurl%:*}"
> + sep=:
> + ;;
What happens to
url = ssh://example.com:1234
url = ftp://ftp.example.com
url = /local/path/with/a/colon:in:it
url = git://example.com/path/with/a/colon:in:it
> + *)
> + die "cannot strip one component off url '$remoteurl'"
> + ;;
url = simple.subdir.of.cwd
? (Not a rhetorical question; I'm only curious. If the ftp example
is valid then the existing code already would not cope well with it.)
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
Nice.
^ permalink raw reply
* [PATCH] Fix wrong failures in config test
From: Ingo Brückl @ 2011-01-10 16:13 UTC (permalink / raw)
To: git
The tests after '--set in alternative GIT_CONFIG' failed because
variable GIT_CONFIG was still set.
Signed-off-by: Ingo Brückl <ib@wupperonline.de>
---
Is it only me (bash 3.2.48(1)-release) experiencing these failures?
t/t1300-repo-config.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index d0e5546..d1c9a8f 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -428,6 +428,8 @@ EOF
test_expect_success '--set in alternative GIT_CONFIG' 'cmp other-config expect'
+unset GIT_CONFIG
+
cat > .git/config << EOF
# Hallo
#Bello
--
1.7.3.5
^ permalink raw reply related
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: John Wyzer @ 2011-01-10 16:39 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTinc12H01Us1mkKieZo75hwjgTCZth_wFvRNscMq@mail.gmail.com>
On 06/01/11 18:05, Shawn Pearce wrote:
> On Wed, Jan 5, 2011 at 18:29, Zenaan Harkness<zen@freedbms.net> wrote:
>> Bittorrent requires some stability around torrent files.
>>
>> Can packs be generated deterministically?
>
I hope that I don't get something technically wrong (did not read any
code, only skimmed the docs) and that this question is not redundant:
Why not provide an alternative mode for the git:// protocoll that
instead of retrieving a big packaged blob breaks this down to the
smallest atomic objects from the repository? Those are not changing and
should be able to survive partial transfers.
While this might not be as efficient network traffic-wise it would
provide a solution for those behind breaking connections.
^ permalink raw reply
* Re: cvsimport still not working with cvsnt
From: Martin Langhoff @ 2011-01-10 15:38 UTC (permalink / raw)
To: Guy Rouillier
Cc: Emil Medve, Jonathan Nieder, git, Pascal Obry, Clemens Buchacher
In-Reply-To: <4D2AB63D.7040803@burntmail.com>
On Mon, Jan 10, 2011 at 2:33 AM, Guy Rouillier <guyr@burntmail.com> wrote:
> Here is my patch for accomplishing the above. As this is my first time
> submitting a patch, please let me know the correct procedure if
> submitting a diff here is not appropriate. Thanks.
The concept of what the patch is doing is good, but I'd recommend
@cvspasslocations = ($ENV{'HOME'}."/cvspass", $ENV{'HOME'}."/.cvs/cvspass")
foreach $cvspass (@cvspasslocations) {
open(...
and forgo the "matching" test.
cheers,
m
--
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: Nicolas Pitre @ 2011-01-10 13:50 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Zenaan Harkness, git
In-Reply-To: <AANLkTinVYWit95O9Y0r5BKJiMGJRAOvgPqZ0s8Eez7KJ@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 986 bytes --]
On Mon, 10 Jan 2011, Nguyen Thai Ngoc Duy wrote:
> On Fri, Jan 7, 2011 at 11:33 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > Here's what I suggest:
> >
> > cd my_project
> > BUNDLENAME=my_project_$(date "+%s").gitbundle
> > git bundle create $BUNDLENAME --all
> > maketorrent-console your_favorite_tracker $BUNDLENAME
> >
> > Then start seeding that bundle, and upload $BUNDLENAME.torrent as
> > bundle.torrent inside my_project.git on your server.
>
> I was about to ask if we could put more "trailer" sha-1 checksums to
> the bundle, so we can verify which part is corrupt without
> redownloading the whole thing (this is over http/ftp.. not torrent).
Aren't HTTP and FTP based on TCP which is meant to be a reliable
transport protocol already? In this case, isn't the final SHA1 embedded
in the bundle/pack sufficient enough? Normally, your HTTP/FTP client
should get you all data or partial data, but not wrong data.
Nicolas
^ permalink raw reply
* Re: git-archive and core.eol
From: Erik Faye-Lund @ 2011-01-10 13:00 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, msysGit, eyvind.bernhardsen
In-Reply-To: <AANLkTinxVCQuTMeKHQ9mLbs=94fck90rwJwa1DhzGPmX@mail.gmail.com>
On Mon, Jan 10, 2011 at 1:11 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> test. So now I've got to figure out what is different between your
> test and mine. Perhaps I misdiagnosed to begin with?
>
No, it doesn't quite seem like I misdiagnosed, but your test had
different expectations than I have after reading the documentation. I
expected core.autocrlf=true + core.eol=lf to pretty much be identical
to core.autocrlf=false, but only because LF->LF conversion is a NOP.
'core.autocrlf' is documented as meaning the same as setting the
'text' attribute to 'auto' for all files, plus "files that contain
CRLF in the repository will not be touched". I figured that last part
shouldn't affect me as I only had LFs in the repository.
If I disable core.autocrlf, I get what I want (no matter what I set
core.eol to, it seems). But I still don't understand WHY
core.autocrlf=true + core.eol=lf outputs CRLF.
It seems to me that there's a big gap between what the documentation
claims and what actually happens here.
^ permalink raw reply
* [PATCH] Documentation/git-archive: spell --worktree-attributes correctly
From: Thomas Rast @ 2011-01-10 12:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeffrey Phillips Freeman
The --worktree-attributes option was correctly documented in ba053ea
(archive: do not read .gitattributes in working directory,
2009-04-18). However, later in 9b4c8b0 (archive documentation:
attributes are taken from the tree by default, 2010-02-10) the
misspelling "--work-tree-attributes" was used to refer to it. Fix
this.
Noticed-by: Jeffrey Phillips Freeman <jeffrey.freeman@syncleus.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-archive.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 4163a1b..bf5037a 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -116,7 +116,7 @@ Note that attributes are by default taken from the `.gitattributes` files
in the tree that is being archived. If you want to tweak the way the
output is generated after the fact (e.g. you committed without adding an
appropriate export-ignore in its `.gitattributes`), adjust the checked out
-`.gitattributes` file as necessary and use `--work-tree-attributes`
+`.gitattributes` file as necessary and use `--worktree-attributes`
option. Alternatively you can keep necessary attributes that should apply
while archiving any tree in your `$GIT_DIR/info/attributes` file.
--
1.7.4.rc1.309.g58aa0
^ permalink raw reply related
* [PATCH maint] Documentation/githooks: post-rewrite-copy-notes never existed
From: Thomas Rast @ 2011-01-10 12:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The documentation for the post-rewrite hook contains a paragraph from
its early development, where the automatic notes copying facilities
were not part of the series and thus this had to be a hook. Later
versions of the series implemented notes copying as a core feature.
Thus mentioning post-rewrite-copy-notes was never correct. As the
other hooks do not have a "there is no default hook, but..." sentence
unless they ship a sample hook in either templates or contrib, we
simply remove the whole paragraph.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/githooks.txt | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 7183aa9..28edefa 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -350,10 +350,6 @@ rebase::
The commits are guaranteed to be listed in the order that they were
processed by rebase.
-There is no default 'post-rewrite' hook, but see the
-`post-receive-copy-notes` script in `contrib/hooks` for an example
-that copies your git-notes to the rewritten commits.
-
GIT
---
--
1.7.4.rc1.309.g58aa0
^ permalink raw reply related
* Re: git-archive and core.eol
From: Erik Faye-Lund @ 2011-01-10 12:11 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, msysGit, eyvind.bernhardsen
In-Reply-To: <4D29AF80.5060008@lsrfire.ath.cx>
On Sun, Jan 9, 2011 at 1:52 PM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> Am 08.01.2011 18:28, schrieb Erik Faye-Lund:
>> Really? I haven't looked through what the test actually does (I'm out
>> sick right now, and don't have many working brain-cells), but every
>> single test fails for me:
> [...]
>> $ git --version
>> git version 1.7.4.rc1.3196.gfd693
>>
>> (This is the current 'devel'-branch from
>> git://repo.or.cz/git/mingw/4msysgit.git)
>
> I cloned it, but even though it reports a different version string for
> me we probably use the same (fd6937e0e6ccb78eb4347c427248e25c2d6739c8):
>
> $ ./git version
> git version 1.7.3.4.3902.gfd693
>
This is probably just because you haven't pulled junio's repo
recently, which contains the 1.7.4.rc1 tag. The tip is the same,
indeed.
> And all the tests succeed for me (on Windows Vista Home Premium x64)
> with that one.
>
I'm on Vista 64 if that matters. And I'm using msysGit e59039e.
> I'm especially interested in how the setup step manages to fail for you.
It's the line "git add .gitattributes" is the first that fails in
'setup'. Actually, all git-commands seems to fail.
But now I also observe that just trying to run t0000-basic fails:
$ ./t0000-basic.sh
./t0000-basic.sh: line 24: ../git: is a directory
You do not seem to have built git yet.
Now this is suspicious:
$ ls ../git.exe
../git.exe*
$ ls ../git
Debug/ git.vcproj git.vcproj.Hue-PC.kusma.user git.wwdb
Aha! The MSVC project generator creates a folder called 'git' at the
root, so anything trying to execute '../git' fails!
$ ../git help
sh.exe": ../git: is a directory
After deleting that folder, t0000-basic passes again. As does your
test. So now I've got to figure out what is different between your
test and mine. Perhaps I misdiagnosed to begin with?
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: Nguyen Thai Ngoc Duy @ 2011-01-10 11:48 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Zenaan Harkness, git
In-Reply-To: <alpine.LFD.2.00.1101062221480.22191@xanadu.home>
On Fri, Jan 7, 2011 at 11:33 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> Here's what I suggest:
>
> cd my_project
> BUNDLENAME=my_project_$(date "+%s").gitbundle
> git bundle create $BUNDLENAME --all
> maketorrent-console your_favorite_tracker $BUNDLENAME
>
> Then start seeding that bundle, and upload $BUNDLENAME.torrent as
> bundle.torrent inside my_project.git on your server.
I was about to ask if we could put more "trailer" sha-1 checksums to
the bundle, so we can verify which part is corrupt without
redownloading the whole thing (this is over http/ftp.. not torrent).
But I realize it's just easier to split the bundle into multiple
packs, so we can verify and redownload only corrupt packs. Logically
it is still a single pack. Splitting help put more sha-1 checksums in
without changing pack format. The packs will be merged back into one
with "index-pack --pack-stream" patch I sent elsewhere.
--
Duy
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.4-rc1
From: Johan Herland @ 2011-01-10 10:51 UTC (permalink / raw)
To: git
On Thursday 06 January 2011, Junio C Hamano wrote:
> A release candidate Git 1.7.4-rc1 is available at the usual places
> for testing:
[...]
> Git v1.7.4 Release Notes (draft)
> ================================
>
> Updates since v1.7.3
> --------------------
I can't find "git merge --abort" and "git notes merge" in this list.
Suggested paragraphs:
* "git merge" learned "--abort" option, synonymous to
"git reset --merge" when a merge is in progress.
* "git notes" learned the "merge" subcommand to merge notes refs.
In addition to the default manual conflict resolution, there are
also several notes merge strategies for automatically resolving
notes merge conflicts.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH] submodule: fix relative url parsing for scp-style origin
From: Thomas Rast @ 2011-01-10 10:37 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Mark Levedahl, Jeffrey Phillips Freeman
The function resolve_relative_url was not prepared to deal with an
scp-style origin 'user@host:path' in the case where 'path' is only a
single component. Fix this by extending the logic that strips one
path component from the $remoteurl.
Also add tests for both styles of URLs.
Noticed-by: Jeffrey Phillips Freeman <jeffrey.freeman@syncleus.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
If Mark agrees with the fix, I think this should go in before 1.7.4
since it's a pretty annoying bug.
git-submodule.sh | 16 ++++++++++++++--
t/t7400-submodule-basic.sh | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index c21b77a..8b90589 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -37,12 +37,24 @@ resolve_relative_url ()
die "remote ($remote) does not have a url defined in .git/config"
url="$1"
remoteurl=${remoteurl%/}
+ sep=/
while test -n "$url"
do
case "$url" in
../*)
url="${url#../}"
- remoteurl="${remoteurl%/*}"
+ case "$remoteurl" in
+ */*)
+ remoteurl="${remoteurl%/*}"
+ ;;
+ *:*)
+ remoteurl="${remoteurl%:*}"
+ sep=:
+ ;;
+ *)
+ die "cannot strip one component off url '$remoteurl'"
+ ;;
+ esac
;;
./*)
url="${url#./}"
@@ -51,7 +63,7 @@ resolve_relative_url ()
break;;
esac
done
- echo "$remoteurl/${url%/}"
+ echo "$remoteurl$sep${url%/}"
}
#
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 2c49db9..874279e 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -446,4 +446,42 @@ test_expect_success 'add should fail when path is used by an existing directory'
)
'
+test_expect_success 'set up for relative path tests' '
+ mkdir reltest &&
+ (
+ cd reltest &&
+ git init &&
+ mkdir sub &&
+ (
+ cd sub &&
+ git init &&
+ test_commit foo
+ ) &&
+ git add sub &&
+ git config -f .gitmodules submodule.sub.path sub &&
+ git config -f .gitmodules submodule.sub.url ../subrepo &&
+ cp .git/config pristine-.git-config
+ )
+'
+
+test_expect_success 'relative path works with URL' '
+ (
+ cd reltest &&
+ cp pristine-.git-config .git/config &&
+ git config remote.origin.url ssh://hostname/repo &&
+ git submodule init &&
+ test "$(git config submodule.sub.url)" = ssh://hostname/subrepo
+ )
+'
+
+test_expect_success 'relative path works with user@host:path' '
+ (
+ cd reltest &&
+ cp pristine-.git-config .git/config &&
+ git config remote.origin.url user@host:repo &&
+ git submodule init &&
+ test "$(git config submodule.sub.url)" = user@host:subrepo
+ )
+'
+
test_done
--
1.7.4.rc1.309.g58aa0
^ permalink raw reply related
* Re: git fails on large repo clone on intermittent, or intermittently-high-latency, connections
From: James Cloos @ 2011-01-09 20:04 UTC (permalink / raw)
To: Zenaan Harkness; +Cc: git
In-Reply-To: <AANLkTinkhmHpAQjraviKjqFAczThR5GtT_qdyf6Sb3nm@mail.gmail.com>
In addition to the other replies, if you have a shell login elswhere you
can clone there, bundle the file, and use rsync, http, ftp or the like
to copy it down.
If the remote site's git is too old to have git bundle, use a bare clone
and tar it. You will not need to compress the tar.
You can also use split(1) to break up the bundle or tar into smaller
chunks if that helps. cat(1) will happily recombine those chunks.
If git bundle was not available, you can use the copied bare repo as
a --reference for a new clone, then copy the bare's pack file into
that new clone and remove the new clone's objects/info/alternates file.
I've had to use that method to get a clean clone across a small straw
(dialup or wireless) for several large repositories over the years.
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
^ permalink raw reply
* Re: cvsimport still not working with cvsnt
From: Guy Rouillier @ 2011-01-10 7:33 UTC (permalink / raw)
To: Emil Medve
Cc: Jonathan Nieder, git, Pascal Obry, Clemens Buchacher,
Martin Langhoff
In-Reply-To: <4D119015.6020207@burntmail.com>
On 12/22/2010 12:43 AM, Guy Rouillier wrote:
>
> Emil and Jonathan, thanks for the feedback. Perl is not my strong point,
> but I'll take a crack at it over the upcoming holidays. I'm inclined not
> to get too fancy and try to second-guess the user's environment. Perhaps
> he has both cvs and cvsnt installed for some reason (testing one, using
> the other for regular work); perhaps a tool installed one or the other
> and he doesn't even know he has them both. Etc.
>
> So, at most I can see, as Emil suggested, seeing if the entry exists in
> both files and is the same in both. If so, or if the entry is only in
> one of them, then just use the entry. However, if the entry is in both
> files and is different, I'd prefer to just exit with an error and have
> the user clarify his environment.
Here is my patch for accomplishing the above. As this is my first time
submitting a patch, please let me know the correct procedure if
submitting a diff here is not appropriate. Thanks.
--- git-cvsimport.org 2011-01-09 03:52:39.000000000 -0500
+++ git-cvsimport.cvsnt 2011-01-10 01:42:29.000000000 -0500
@@ -260,6 +260,8 @@
if ($pass) {
$pass = $self->_scramble($pass);
} else {
+ # First try the original CVS location.
+
open(H,$ENV{'HOME'}."/.cvspass") and do {
# :pserver:cvs@mea.tmt.tele.fi:/cvsroot/zmailer Ah<Z
while (<H>) {
@@ -272,7 +274,30 @@
}
}
};
- $pass = "A" unless $pass;
+
+ # Now try the CVSNT location.
+
+ open(H,$ENV{'HOME'}."/.cvs/cvspass") and do {
+ # :pserver:cvs@mea.tmt.tele.fi:/cvsroot/zmailer Ah<Z
+ while (<H>) {
+ chomp;
+ s/^\/\d+\s+//;
+ my ($w,$p) = split(/=/,$_,2);
+ if ($w eq $rr or $w eq $rr2) {
+ my $cvsntpass = $p;
+
+ if (!$pass) {
+ $pass = $cvsntpass;
+ } elsif ($pass ne $cvsntpass) {
+ die("CVSROOT found in both CVS and CVSNT cvspass files, passwords do not match\n");
+ }
+ last;
+ }
+ }
+ };
+
+
+ die("Password not found for CVSROOT: $opt_d\n") unless $pass;
}
my ($s, $rep);
--
Guy Rouillier
^ 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