* Re: [PATCH 1/2] daemon: add tests
From: Clemens Buchacher @ 2012-01-02 19:47 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Junio C Hamano, Jeff King, Erik Faye-Lund, Ilari Liusvaara,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20120102092508.GA10977@elie.hsd1.il.comcast.net>
On Mon, Jan 02, 2012 at 03:25:08AM -0600, Jonathan Nieder wrote:
>
> > [Subject: daemon: add tests]
>
> Can't believe I missed this. That seems like a worthy cause ---
> can someone remind me why this is dropped, or if there are any
> tweaks I can help with to get it picked up again?
We were discussing some open issues with patch 2/2, which was based
on the tests. I later abandoned the idea for that patch. But the
tests should be ok by themselves.
Clemens
^ permalink raw reply
* Re: How to deal with historic tar-balls
From: Dirk Süsserott @ 2012-01-02 18:26 UTC (permalink / raw)
To: Philip Oakley; +Cc: Tomas Carnecky, nn6eumtr, Git List
In-Reply-To: <4C50794C7EED42A0B1A25ABD77CE7DB0@PhilipOakley>
Am 02.01.2012 11:07 schrieb Philip Oakley:
> From: "Philip Oakley" <philipoakley@iee.org>: Sunday, January 01, 2012
> 6:30 PM
>> From: "Tomas Carnecky" <tom@dbservice.com> : Sunday, January 01, 2012
>> 12:27 AM
>>> On 12/31/11 8:04 PM, nn6eumtr wrote:
>>>> I have a number of older projects that I want to bring into a git
>>>> repository. They predate a lot of the popular scm systems, so they are
>>>> primarily a collection of tarballs today.
>>> There is a script which will import sources from multiple tarballs,
>>> creating a commit with the contents of each tarball. It's in the git
>>> repository under contrib/fast-import/import-tars.perl.
>> I wasn't aware of those scripts. I'll be having a look at the zip import
>> script for my needs.
>>
>>> tom
>> Philip
>>
> I had a look at the script but Python isn't part of the Msysgit install,
> so the example wouldn't run.
>
> Also I couldn't see how the "fast_import.write(" method was being
> created - my ignorance of Python? Otherwise I could look at scripting it.
>
> Philip
Philip,
I'm not a Python guy, but I think fast_import.write() writes sth. to
whatever the popen() call in line 24 returned:
fast_import = popen('git fast-import --quiet', 'w')
I guess it returns a filehandle and 'git fast-import' reads its data
from stdin. My guess is, that -- instead of writing to that pipe -- you
could as well write everything to a temporary file and finally call
git fast-import < $tempfile
But that's only a guess.
Dirk
^ permalink raw reply
* [BUG] gitweb generates wrong links in grep search results (git_search_files)
From: Thomas Perl @ 2012-01-02 13:29 UTC (permalink / raw)
To: git
Hi,
I think I found a bug in gitweb when grep'ing for text in a branch
different from "master". Here's how to reproduce it:
1. Have a project with a master branch and a branch different from master
2. Start gitweb for that project (e.g. using "git instaweb") and open
it in a web browser
3. Switch to the non-master branch (e.g.
http://127.0.0.1:1234/?p=.git;a=shortlog;h=refs/heads/mynonmasterbranch)
4. In the top right search box, select "grep" in the combo box and
enter a text that only appears in the non-master branch
5. Submit the search by pressing enter, you should be at:
http://127.0.0.1:1234/?p=.git&a=search&h=refs%2Fheads%2Fmynonmasterbranch&st=grep&s=somesearchtext
ACTUAL RESULT
In that list of results, you should now see some files matching the
search - note that the links for the file names and the line numbers
go to e.g. http://127.0.0.1:1234/?p=.git;a=blob;f=somefile.txt for a
file "somefile.txt". The links therefore go to the master branch,
while the search results refer to the non-master branch.
EXPECTED RESULT
The link should (presumably) go to
http://127.0.0.1:1234/?p=.git;a=blob;hb=refs%2Fheads%2Fmynonmasterbranch;f=somefile.txt
so that when the link is clicked, the right file (somefile.txt in
mynonmasterbranch) is shown.
I also investigated a bit in where the problem happens, and nailed it
down to: gitweb/gitweb.perl, sub git_search_files, line 5871 in commit
17b4e93d5b849293e6a3659bbc4075ed8a6e97e2 (current master tip of
https://github.com/gitster/git). I haven't looked at the intrinsics of
the "href" sub, but I believe that it should somehow get the "h"
parameter from the original page and incorporate it into the final
link (as "hb" parameter?) to the file. The same fix that is applied
there then also needs to be applied at line 5891 (same commit, same
file).
No patch, because after several tries, I didn't get it to work, my
Perl foo might not be up to the task, and I believe that someone more
familiar with gitweb's code base might have an easier time to fix
this.
Thanks,
Thomas
^ permalink raw reply
* Re: How to deal with historic tar-balls
From: Philip Oakley @ 2012-01-02 10:07 UTC (permalink / raw)
To: Philip Oakley, Tomas Carnecky, nn6eumtr; +Cc: Git List
In-Reply-To: <B375E525C4704EA8807B5A59257B690B@PhilipOakley>
From: "Philip Oakley" <philipoakley@iee.org>: Sunday, January 01, 2012 6:30
PM
> From: "Tomas Carnecky" <tom@dbservice.com> : Sunday, January 01, 2012
> 12:27 AM
>>On 12/31/11 8:04 PM, nn6eumtr wrote:
>>> I have a number of older projects that I want to bring into a git
>>> repository. They predate a lot of the popular scm systems, so they are
>>> primarily a collection of tarballs today.
>> There is a script which will import sources from multiple tarballs,
>> creating a commit with the contents of each tarball. It's in the git
>> repository under contrib/fast-import/import-tars.perl.
> I wasn't aware of those scripts. I'll be having a look at the zip import
> script for my needs.
>
>> tom
> Philip
>
I had a look at the script but Python isn't part of the Msysgit install, so
the example wouldn't run.
Also I couldn't see how the "fast_import.write(" method was being created -
my ignorance of Python? Otherwise I could look at scripting it.
Philip
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Jonathan Nieder @ 2012-01-02 9:25 UTC (permalink / raw)
To: Clemens Buchacher
Cc: git, Junio C Hamano, Jeff King, Erik Faye-Lund, Ilari Liusvaara,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1318803076-4229-1-git-send-email-drizzd@aon.at>
(+cc: Erik, Ilari, Duy)
Hi,
Clemens Buchacher wrote:
> [Subject: daemon: add tests]
Can't believe I missed this. That seems like a worthy cause ---
can someone remind me why this is dropped, or if there are any
tweaks I can help with to get it picked up again?
Patch left unsnipped for convenience of people cc-ed.
Jonathan
> The semantics of the git daemon tests are similar to the http
> transport tests. In fact, they are only a slightly modified copy
> of t5550, plus the newly added remote error tests.
>
> All daemon tests will be skipped unless the environment variable
> GIT_TEST_DAEMON is set.
>
> Signed-off-by: Clemens Buchacher <drizzd@aon.at>
> ---
>
> This patch is based on jk/daemon-msgs.
>
> t/lib-daemon.sh | 52 +++++++++++++++++
> t/t5570-git-daemon.sh | 148 +++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 200 insertions(+), 0 deletions(-)
> create mode 100644 t/lib-daemon.sh
> create mode 100755 t/t5570-git-daemon.sh
>
> diff --git a/t/lib-daemon.sh b/t/lib-daemon.sh
> new file mode 100644
> index 0000000..30a89ea
> --- /dev/null
> +++ b/t/lib-daemon.sh
> @@ -0,0 +1,52 @@
> +#!/bin/sh
> +
> +if test -z "$GIT_TEST_DAEMON"
> +then
> + skip_all="Daemon testing disabled (define GIT_TEST_DAEMON to enable)"
> + test_done
> +fi
> +
> +LIB_DAEMON_PORT=${LIB_DAEMON_PORT-'8121'}
> +
> +DAEMON_PID=
> +DAEMON_DOCUMENT_ROOT_PATH="$PWD"/repo
> +DAEMON_URL=git://127.0.0.1:$LIB_DAEMON_PORT
> +
> +start_daemon() {
> + if test -n "$DAEMON_PID"
> + then
> + error "start_daemon already called"
> + fi
> +
> + mkdir -p "$DAEMON_DOCUMENT_ROOT_PATH"
> +
> + trap 'code=$?; stop_daemon; (exit $code); die' EXIT
> +
> + say >&3 "Starting git daemon ..."
> + git daemon --listen=127.0.0.1 --port="$LIB_DAEMON_PORT" \
> + --reuseaddr --verbose \
> + --base-path="$DAEMON_DOCUMENT_ROOT_PATH" \
> + "$@" "$DAEMON_DOCUMENT_ROOT_PATH" \
> + >&3 2>&4 &
> + DAEMON_PID=$!
> +}
> +
> +stop_daemon() {
> + if test -z "$DAEMON_PID"
> + then
> + return
> + fi
> +
> + trap 'die' EXIT
> +
> + # kill git-daemon child of git
> + say >&3 "Stopping git daemon ..."
> + pkill -P "$DAEMON_PID"
> + wait "$DAEMON_PID"
> + ret=$?
> + if test $ret -ne 143
> + then
> + error "git daemon exited with status: $ret"
> + fi
> + DAEMON_PID=
> +}
> diff --git a/t/t5570-git-daemon.sh b/t/t5570-git-daemon.sh
> new file mode 100755
> index 0000000..aa5771a
> --- /dev/null
> +++ b/t/t5570-git-daemon.sh
> @@ -0,0 +1,148 @@
> +#!/bin/sh
> +
> +test_description='test fetching over git protocol'
> +. ./test-lib.sh
> +
> +. "$TEST_DIRECTORY"/lib-daemon.sh
> +start_daemon
> +
> +test_expect_success 'setup repository' '
> + echo content >file &&
> + git add file &&
> + git commit -m one
> +'
> +
> +test_expect_success 'create git-accessible bare repository' '
> + mkdir "$DAEMON_DOCUMENT_ROOT_PATH/repo.git" &&
> + (cd "$DAEMON_DOCUMENT_ROOT_PATH/repo.git" &&
> + git --bare init &&
> + : >git-daemon-export-ok
> + ) &&
> + git remote add public "$DAEMON_DOCUMENT_ROOT_PATH/repo.git" &&
> + git push public master:master
> +'
> +
> +test_expect_success 'clone git repository' '
> + git clone $DAEMON_URL/repo.git clone &&
> + test_cmp file clone/file
> +'
> +
> +test_expect_success 'fetch changes via git protocol' '
> + echo content >>file &&
> + git commit -a -m two &&
> + git push public &&
> + (cd clone && git pull) &&
> + test_cmp file clone/file
> +'
> +
> +test_expect_failure 'remote detects correct HEAD' '
> + git push public master:other &&
> + (cd clone &&
> + git remote set-head -d origin &&
> + git remote set-head -a origin &&
> + git symbolic-ref refs/remotes/origin/HEAD > output &&
> + echo refs/remotes/origin/master > expect &&
> + test_cmp expect output
> + )
> +'
> +
> +test_expect_success 'prepare pack objects' '
> + cp -R "$DAEMON_DOCUMENT_ROOT_PATH"/repo.git "$DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git &&
> + (cd "$DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git &&
> + git --bare repack &&
> + git --bare prune-packed
> + )
> +'
> +
> +test_expect_success 'fetch notices corrupt pack' '
> + cp -R "$DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git "$DAEMON_DOCUMENT_ROOT_PATH"/repo_bad1.git &&
> + (cd "$DAEMON_DOCUMENT_ROOT_PATH"/repo_bad1.git &&
> + p=`ls objects/pack/pack-*.pack` &&
> + chmod u+w $p &&
> + printf %0256d 0 | dd of=$p bs=256 count=1 seek=1 conv=notrunc
> + ) &&
> + mkdir repo_bad1.git &&
> + (cd repo_bad1.git &&
> + git --bare init &&
> + test_must_fail git --bare fetch $DAEMON_URL/repo_bad1.git &&
> + test 0 = `ls objects/pack/pack-*.pack | wc -l`
> + )
> +'
> +
> +test_expect_success 'fetch notices corrupt idx' '
> + cp -R "$DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git "$DAEMON_DOCUMENT_ROOT_PATH"/repo_bad2.git &&
> + (cd "$DAEMON_DOCUMENT_ROOT_PATH"/repo_bad2.git &&
> + p=`ls objects/pack/pack-*.idx` &&
> + chmod u+w $p &&
> + printf %0256d 0 | dd of=$p bs=256 count=1 seek=1 conv=notrunc
> + ) &&
> + mkdir repo_bad2.git &&
> + (cd repo_bad2.git &&
> + git --bare init &&
> + test_must_fail git --bare fetch $DAEMON_URL/repo_bad2.git &&
> + test 0 = `ls objects/pack | wc -l`
> + )
> +'
> +
> +test_remote_error()
> +{
> + do_export=YesPlease
> + while test $# -gt 0
> + do
> + case $1 in
> + -x)
> + shift
> + chmod -X "$DAEMON_DOCUMENT_ROOT_PATH/repo.git"
> + ;;
> + -n)
> + shift
> + do_export=
> + ;;
> + *)
> + break
> + esac
> + done
> +
> + if test $# -ne 3
> + then
> + error "invalid number of arguments"
> + fi
> +
> + cmd=$1
> + repo=$2
> + msg=$3
> +
> + if test -x "$DAEMON_DOCUMENT_ROOT_PATH/$repo"
> + then
> + if test -n "$do_export"
> + then
> + : >"$DAEMON_DOCUMENT_ROOT_PATH/$repo/git-daemon-export-ok"
> + else
> + rm -f "$DAEMON_DOCUMENT_ROOT_PATH/$repo/git-daemon-export-ok"
> + fi
> + fi
> +
> + test_must_fail git "$cmd" "$DAEMON_URL/$repo" 2>output &&
> + echo "fatal: remote error: $msg: /$repo" >expect &&
> + test_cmp expect output
> + ret=$?
> + chmod +X "$DAEMON_DOCUMENT_ROOT_PATH/repo.git"
> + (exit $ret)
> +}
> +
> +msg="access denied or repository not exported"
> +test_expect_success 'clone non-existent' "test_remote_error clone nowhere.git '$msg'"
> +test_expect_success 'push disabled' "test_remote_error push repo.git '$msg'"
> +test_expect_success 'read access denied' "test_remote_error -x fetch repo.git '$msg'"
> +test_expect_success 'not exported' "test_remote_error -n fetch repo.git '$msg'"
> +
> +stop_daemon
> +start_daemon --informative-errors
> +
> +test_expect_success 'clone non-existent' "test_remote_error clone nowhere.git 'no such repository'"
> +test_expect_success 'push disabled' "test_remote_error push repo.git 'service not enabled'"
> +test_expect_success 'read access denied' "test_remote_error -x fetch repo.git 'no such repository'"
> +test_expect_success 'not exported' "test_remote_error -n fetch repo.git 'repository not exported'"
> +
> +stop_daemon
> +test_done
> --
> 1.7.7
>
>
^ permalink raw reply
* Odd remote: error: packfile ./objects/pack/pack-FOO.pack cannot be accessed
From: Sudarshan Wadkar @ 2012-01-02 9:18 UTC (permalink / raw)
To: git
In-Reply-To: <CAOoYcj2pnNtK3RshcJFwiXK356cZz6M38-NG1_uORjknyhdAKQ@mail.gmail.com>
I have a simple post-receive hook as follows :
#!/bin/bash
# using bash and not simple sh
# simply checkout the master branch to notBare path, use tools from
that portion to deploy further
notBareRepo='/home/sudhi/repo/notBare/myproj-master'
GIT_WORK_TREE="$notBareRepo" git reset --hard master
#end post-receive
But when I push, I get this odd error from remote
$ git push --verbose --mirror
ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myproj.git
Pushing to ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myproj.git
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 323 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: error: packfile
./objects/pack/pack-17900952dc824651db15369a341eec8d3e8f39d2.pack
cannot be accessed
remote: HEAD is now at 4d5a6f1 Investigate and report odd error
To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myproj.git
d066a2f..4d5a6f1 master -> master
This happens even if I do a fresh clone on remote server as:
$ cd repo/bare; git clone --mirror wadkar@my_ip_address:myproj
Local " git fsck " reports few dangling blobs but nothing
fancy/serious. Remote git version is 1.7.4.1 on a CentOS 5.7, while
the local is same (1.7.4.1) on a Ubuntu 11.04.
1. How bad is the situation?
2. Have I done something wrong, or this is not my doing?
3. The checked out version in repo/notBare is fine, and seems to be
working (I can pass my unit-tests). Should I be worried?
4. If not, then can I ignore this particular error and move on?
-Sudarshan Wadkar
"Success is getting what you want. Happiness is wanting what you get."
- Dale Carnegie
"It's always our decision who we are"
- Robert Solomon in Waking Life
"The truth is the truth, so all you can do is live with it."
--Systematic Chaos
^ permalink raw reply
* Re: What's the best way to push/fetch replace refs?
From: Slawomir Testowy @ 2012-01-02 6:16 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <CAP8UFD3KSjdZz1q+QYsH4JpRkiavtTbT1WqQSdxqCaxc24j=Rg@mail.gmail.com>
2011/12/30 Christian Couder <christian.couder@gmail.com>:
> On Fri, Dec 30, 2011 at 12:59 PM, Slawomir Testowy
> <slawomir.testowy@gmail.com> wrote:
>>
>> # I also added "fetch = +refs/replace/*:refs/replace/*" to [remote
>> "origin"] in "b" and this also seems to work.
>
> Yeah, the simplest is probably to just add "fetch =
> +refs/replace/*:refs/replace/*" to the remote(s) you want to get the
> replace refs from, and "push = +refs/replace/*:refs/replace/*" to the
> remote(s) you want to push the replace refs to.
>
> Regards,
> Christian.
Thanks Christian, I thought maybe there is some magic "git clone
--get-also-replace-refs" or something. I'm asking because I'm about to
tell people how to clone my repository and some of them don't know Git
at all so I wanted to find out the simplest/best way to fetch replace refs.
Thanks.
^ permalink raw reply
* Re: git alias question
From: Michael Horowitz @ 2012-01-02 5:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Aguilar, Dave Borowitz, git, Junio C Hamano
In-Reply-To: <m3zke8e2vh.fsf@localhost.localdomain>
Nice, works perfectly! Didn't notice that was there, guess last time
I looked, I was using an older version. I see it is in the git config
man page and all now.
Thanks,
Mike
On Sat, Dec 31, 2011 at 6:30 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> Michael Horowitz <michael.horowitz@ieee.org> writes:
>
> > The log operation does seem to make the most sense as the mechanism to
> > search for the results. Making it work with difftool would work...
> > Not sure if "--log" to difftool or some other options as suggested in
> > the other thread would be most consistent UI-wise as stated, but
> > either would work for me.
> >
> > On a separate note, some environment variable like GIT_PREFIX with the
> > CWD would make the alias functionality more flexible.
>
> 1f5d271 (setup: Provide GIT_PREFIX to built-ins, 2011-05-25) is
> present in v1.7.7; 7cf16a1 (handle_alias: provide GIT_PREFIX to
> !alias, 2011-04-27) is in 1.7.6
>
> --
> Jakub Narebski
^ permalink raw reply
* Re: Possible submodule or submodule documentation issue
From: Bill Zaumen @ 2012-01-02 3:53 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git, Junio C Hamano
In-Reply-To: <4F00780C.7090801@web.de>
On Sun, 2012-01-01 at 16:13 +0100, Jens Lehmann wrote:
> Am 29.12.2011 03:50, schrieb Bill Zaumen:
> > So what about clarifying
> the docs: ...
Clarifying the docs is a good solution given that a possibly large
number of existing repositories are dependent on the current behavior.
One way of explaining it is to say that "git first appends a
'/' to the superproject's origin URL if that URL does not already
end in a '/'. Relative URLs for submodules' origin repository are
resolved relative to this modified URL." Then the reader can simply
apply the normal URL rules.
I think either is OK - it's simply a judgment call as to which
explanation is easiest for a typical git user to understand.
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Sven Strickroth @ 2012-01-01 20:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <4F00BAA6.9050104@tu-clausthal.de>
Following you can find my first proposal, based upon patch 1. It's only the
perl part, because I haven't checked out Peffs git_prompt patch(es) and to
avoid double work.
ATM I'm unsure about the 'username' type, but I think it's quite necessary
to make git-svn behave like git-core in case of asking for a username. A type
'userpass' (username and password in one dialog) isn't mentioned here, because
it's not necessary for the git-svn part, but we should also specify/document it
if we want to use it in the future.
Btw. happy new year! ;)
---
git-svn.perl | 24 +++++++------------
perl/Git.pm | 70 ++++++++++++++++++++++++++++++++++++++++-----------------
2 files changed, 58 insertions(+), 36 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 26d3559..54cf77f 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -4356,17 +4356,16 @@ sub ssl_server_trust {
map $cert_info->$_, qw(hostname valid_from valid_until
issuer_dname fingerprint);
my $choice;
-prompt:
- print STDERR $may_save ?
+ my $prompt = $may_save ?
"(R)eject, accept (t)emporarily or accept (p)ermanently? " :
"(R)eject or accept (t)emporarily? ";
- STDERR->flush;
- $choice = lc(substr(<STDIN> || 'R', 0, 1));
- if ($choice =~ /^t$/i) {
+prompt:
+ $choice = lc(substr(Git->prompt($prompt) || 'R', 0, 1));
+ if ($choice eq "t") {
$cred->may_save(undef);
- } elsif ($choice =~ /^r$/i) {
+ } elsif ($choice eq "r") {
return -1;
- } elsif ($may_save && $choice =~ /^p$/i) {
+ } elsif ($may_save && $choice eq "p") {
$cred->may_save($may_save);
} else {
goto prompt;
@@ -4378,10 +4377,7 @@ prompt:
sub ssl_client_cert {
my ($cred, $realm, $may_save, $pool) = @_;
$may_save = undef if $_no_auth_cache;
- print STDERR "Client certificate filename: ";
- STDERR->flush;
- chomp(my $filename = <STDIN>);
- $cred->cert_file($filename);
+ $cred->cert_file(Git->prompt("Client certificate filename: ", 'filename'));
$cred->may_save($may_save);
$SVN::_Core::SVN_NO_ERROR;
}
@@ -4404,9 +4400,7 @@ sub username {
if (defined $_username) {
$username = $_username;
} else {
- print STDERR "Username: ";
- STDERR->flush;
- chomp($username = <STDIN>);
+ $username = Git->prompt("Username: ", 'username');
}
$cred->username($username);
$cred->may_save($may_save);
@@ -4415,7 +4409,7 @@ sub username {
sub _read_password {
my ($prompt, $realm) = @_;
- my $password = Git->prompt($prompt);
+ my $password = Git->prompt($prompt, 'pass');
$password;
}
diff --git a/perl/Git.pm b/perl/Git.pm
index ba9a5f2..17ddf40 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -512,52 +512,80 @@ C<git --html-path>). Useful mostly only internally.
sub html_path { command_oneline('--html-path') }
-=item prompt ( PROMPT )
+=item prompt ( PROMPT , TYPE )
Query user C<PROMPT> and return answer from user.
-If an external helper is specified via GIT_ASKPASS or SSH_ASKPASS, it
-is used to interact with the user; otherwise the prompt is given to
-and the answer is read from the terminal.
+If an external helper is specified via GIT_DIALOG, GIT_ASKPASS or
+SSH_ASKPASS, it is used to interact with the user; otherwise the
+prompt is given to and the answer is read from the terminal.
+
+Possible values for C<TYPE>:
+- '' or 'text': prompt for normal text (only GIT_DIALOG)
+- 'username': prompt for username (behaves exactly as 'text', but also
+ uses *_ASKPASS)
+- 'pass': prompt for password, echoing of what is typed is disabled on
+ the terminal, GUI tool shows asterisks.
+- 'filename': prompt for a filename, GUI tool migh provide file chooser
+ (only GIT_DIALOG)
=cut
sub prompt {
- my ($self, $prompt) = _maybe_self(@_);
+ my ($self, $prompt, $type) = _maybe_self(@_);
+ $type = 'text' unless ($type);
+ my $useAskPass = ($type eq 'pass' || $type eq 'username');
my $ret;
if (!defined $ret) {
- $ret = _prompt($ENV{'GIT_ASKPASS'}, $prompt);
+ $ret = _promptgitdialog($ENV{'GIT_DIALOG'}, $prompt, $type);
}
- if (!defined $ret) {
- $ret = _prompt($ENV{'SSH_ASKPASS'}, $prompt);
+ if ($useAskPass && !defined $ret) {
+ $ret = _promptaskpass($ENV{'GIT_ASKPASS'}, $prompt);
+ }
+ if ($useAskPass && !defined $ret) {
+ $ret = _promptaskpass($ENV{'SSH_ASKPASS'}, $prompt);
}
if (!defined $ret) {
$ret = '';
print STDERR $prompt;
STDERR->flush;
- require Term::ReadKey;
- Term::ReadKey::ReadMode('noecho');
- while (defined(my $key = Term::ReadKey::ReadKey(0))) {
- last if $key =~ /[\012\015]/; # \n\r
- $ret .= $key;
+ if ($type eq 'pass') {
+ require Term::ReadKey;
+ Term::ReadKey::ReadMode('noecho');
+ while (defined(my $key = Term::ReadKey::ReadKey(0))) {
+ last if $key =~ /[\012\015]/; # \n\r
+ $ret .= $key;
+ }
+ Term::ReadKey::ReadMode('restore');
+ print STDERR "\n";
+ STDERR->flush;
+ } else {
+ chomp($ret = <STDIN>);
}
- Term::ReadKey::ReadMode('restore');
- print STDERR "\n";
- STDERR->flush;
}
return $ret;
}
-sub _prompt {
+sub _promptgitdialog {
+ my ($gitdialog, $prompt, $type) = @_;
+ return undef unless ($askpass);
+ my $ret;
+ open my $fh, "-|", $gitdialog, $type, $prompt
+ or return undef;
+ $ret = <$fh>;
+ $ret =~ s/\r?\n$//; # strip \r\n, chomp does not work on all systems (i.e. windows) as expected
+ close ($fh);
+ return $ret;
+}
+
+sub _promptaskpass {
my ($askpass, $prompt) = @_;
- unless ($askpass) {
- return undef;
- }
+ return undef unless ($askpass);
my $ret;
open my $fh, "-|", $askpass, $prompt
or return undef;
$ret = <$fh>;
- $ret =~ s/[\012\015]//g; # \n\r
+ $ret =~ s/\r?\n$//; # strip \r\n, chomp does not work on all systems (i.e. windows) as expected
close ($fh);
return $ret;
}
--
--
Best regards,
Sven Strickroth
ClamAV, a GPL anti-virus toolkit http://www.clamav.net
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply related
* Re: How to deal with historic tar-balls
From: Philip Oakley @ 2012-01-01 20:54 UTC (permalink / raw)
To: Tomas Carnecky, nn6eumtr; +Cc: Git List
In-Reply-To: <B375E525C4704EA8807B5A59257B690B@PhilipOakley>
From: "Philip Oakley" <philipoakley@iee.org> Sent: Sunday, January 01, 2012
6:30 PM
> From: "Tomas Carnecky" <tom@dbservice.com> Sent: Sunday, January 01, 2012
> 12:27 AM
>>On 12/31/11 8:04 PM, nn6eumtr wrote:
>>> I have a number of older projects that I want to bring into a git
>>> repository. They predate a lot of the popular scm systems, so they are
>>> primarily a collection of tarballs today.
> I'm doing a similar thing with a set of zip files. I grouped mine into
> batches for easier checking and putting on to separate branches. Planning
> your branch requirements is probably the biggest task, and will depend on
> how you hope to use the new repo.
>
<snip>
>> There is a script which will import sources from multiple tarballs,
>> creating a commit with the contents of each tarball. It's in the git
>> repository under contrib/fast-import/import-tars.perl.
> I wasn't aware of those scripts. I'll be having a look at the zip import
> script for my needs.
Is there a mechanism for either having fast-import respect a .gitignore,
or determining if a given file/path should be ignored?
My zips contain a lot of compile by-products that should be excluded from
the repo.
> My extra problem is that almost all my zips have an extra top level
> directory that changes its name for every zip (but some don't..). The TLD
> changes confuses the git rename detection if I don't remove them before
> committing. Fortunately it's an internal development project with no
> formal
> releases so creating the history is a bit of a personal project which
> doesn't affect ongoing development (which is the crunch question for
> fidelity of the repo you create).
>
>> tom
> Philip
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Sven Strickroth @ 2012-01-01 19:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <7v8vlrwzw9.fsf@alter.siamese.dyndns.org>
Am 01.01.2012 10:11 schrieb Junio C Hamano:
> I do not think Peff means the dialog must ask these three items at the
> same time. The point is that other codepaths know they need to ask them
> and would benefit if they can instruct the dialog external helper to ask
> them in a single interaction. So if your callsite does not ask them
> together, it is OK. You can keep asking them separately in two dialog
> interactions.
Sure. This is possible with my proposed interface.
Two parameters should be sufficient, since we get the path to the
repository from the CWD.
TYPE: 'text' (default), 'pass', 'userpass' (username + password in one
dialog), 'filename'
PROMPT
Am I missing something?
--
Best regards,
Sven Strickroth
ClamAV, a GPL anti-virus toolkit http://www.clamav.net
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Sven Strickroth @ 2012-01-01 19:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Jakub Narebski
In-Reply-To: <7vpqf8z8a6.fsf@alter.siamese.dyndns.org>
Am 28.12.2011 22:38 schrieb Junio C Hamano:
> I am however not sure if the second patch in this series is a good thing
> in the current shape. For GUI users who do not have a terminal, earlier
> they couldn't respond to these questions but now they can, so in that
> narrow sense we are not going backwards.
> But for people who use *_ASKPASS and are working from the terminal, it is
> a regression to ask these non-password questions using *_ASKPASS. Most
> likely, these helpers that are designed for password entry will hide what
> is typed, and I also wouldn't be surprised if some of them have fairly low
> input-length restriction that may be shorter than a long-ish pathname that
> users might want to give as an answer, which they could do in the terminal
> based interaction but will become impossible with this patch.
I'm still for the second patch to be applied (maybe w/o the certificate
filename prompt), too, because this makes git-svn behave the save way as
git-core does (especially asking for username).
Do you think that ppl. mainly using the terminal have *_ASKPASS set?
Most GUIs I know do set it automatically.
I agree that a new interface is needed (working on a patch), but before
we hurry, we should make git-core and git-svn behave the same way.
Btw. git-svn also does not honour git-credentials.
--
Best regards,
Sven Strickroth
ClamAV, a GPL anti-virus toolkit http://www.clamav.net
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply
* Re: How to deal with historic tar-balls
From: Dirk Süsserott @ 2012-01-01 19:04 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: nn6eumtr, git
In-Reply-To: <4EFFA868.50605@dbservice.com>
Am 01.01.2012 01:27 schrieb Tomas Carnecky:
> On 12/31/11 8:04 PM, nn6eumtr wrote:
>> I have a number of older projects that I want to bring into a git
>> repository. They predate a lot of the popular scm systems, so they are
>> primarily a collection of tarballs today.
>>
>> I'm fairly new to git so I have a couple questions related to this:
>>
>> - What is the best approach for bringing them in? Do I just create a
>> repository, then unpack the files, commit them, clean out the
>> directory unpack the next tarball, and repeat until everything is loaded?
>>
>> - Do I need to pay special attention to files that are renamed/removed
>> from version to version?
>>
>> - If the timestamps change on a file but the actual content does not,
>> will git treat it as a non-change once it realizes the content hasn't
>> changed?
>>
>> - Last, if after loading the repository I find another version of the
>> files that predates those I've loaded, or are intermediate between two
>> commits I've already loaded, is there a way to go say that commit B is
>> actually the ancestor of commit C? (i.e. a->c becomes a->b->c if you
>> were to visualize the commit timeline or do diffs) Or do I just reload
>> the tarballs in order to achieve this?
>
> There is a script which will import sources from multiple tarballs,
> creating a commit with the contents of each tarball. It's in the git
> repository under contrib/fast-import/import-tars.perl.
>
> tom
@tom: True. I didn't know about that script, but it should work.
@nn6eumtr: Basically your workflow is perfect. But let me give you some
explanation:
git init
foreach archive in *.tar; do
tar xf $archive
git add --all .
git commit -m "Added $archive"
# now remove everything except for the .git directory
# with regular shell commands (rm -rf *). Also remove
# any dot-files (and the tarball itself, if it's in the
# current directory).
done
Notice the '--all' switch to 'git add': Normally, 'git add .' adds all
files that match the given pattern '.', i.e. all files in the current
directory (and below, it's recursive). The '--all' switch together with
the pattern '.' adds or updates all files already known to git *AND*
adds the files not yet known *AND* removes the files that are no longer
in the working tree. That's exactly what you want.
Consider archive1.tar with files A, B, C:
git add --all . # will add A, B, and C
Now remove A, B, C, and unpack archive2.tar. Assume it has files B, C,
D. A was deleted, B was changed, C is unchanged, D is new.
git add --all . # will remove A, add B, leave C, add D.
git will notice that C hasn't changed its content (timestamp doesn't
matter).
Without the '--all' switch, git would simply add B and D.
There is no problem re-arranging the history after your import (see "git
rebase --help", especially the --interactive section), but then you
probably will have conflicts and have to resolve them. I'd suggest to
re-start the import instead.
Please note that "for archive in *.tar" will pick the tarballs in
lexicographical order. That might not be your intention.
HTH,
Dirk
^ permalink raw reply
* Re: How to deal with historic tar-balls
From: Philip Oakley @ 2012-01-01 18:30 UTC (permalink / raw)
To: Tomas Carnecky, nn6eumtr; +Cc: Git List
In-Reply-To: <4EFFA868.50605@dbservice.com>
From: "Tomas Carnecky" <tom@dbservice.com> Sent: Sunday, January 01, 2012
12:27 AM
>On 12/31/11 8:04 PM, nn6eumtr wrote:
>> I have a number of older projects that I want to bring into a git
>> repository. They predate a lot of the popular scm systems, so they are
>> primarily a collection of tarballs today.
I'm doing a similar thing with a set of zip files. I grouped mine into
batches for easier checking and putting on to separate branches. Planning
your branch requirements is probably the biggest task, and will depend on
how you hope to use the new repo.
>> I'm fairly new to git so I have a couple questions related to this:
>>
>> - What is the best approach for bringing them in? Do I just create a
>> repository, then unpack the files, commit them, clean out the
>> directory unpack the next tarball, and repeat until everything is loaded?
Essentially yes; Obviously if you have an organisation in mind then you can
introduce maintenance branches etc as you develop the import.
If it is simply to create a nice history that isn't really looked at, then a
simple linear model is OK. If you need to keep old mintenance versions and
obtain diffs with newer versions then look at the various branching models
and populate appropriately.
>>
>> - Do I need to pay special attention to files that are renamed/removed
>> from version to version?
No; It is only if you use those file dates to determine the implied date for
the commit.
>>
>> - If the timestamps change on a file but the actual content does not,
>> will git treat it as a non-change once it realizes the content hasn't
>> changed?
Correct. In fact git doesn't record the time stamps anyway. It simply
records the content, and structure, of the snapshot.
>>
>> - Last, if after loading the repository I find another version of the
>> files that predates those I've loaded, or are intermediate between two
>> commits I've already loaded, is there a way to go say that commit B is
>> actually the ancestor of commit C? (i.e. a->>c becomes a->>b->>c if you
>> were to visualize the commit timeline or do diffs) Or do I just reload
>> the tarballs in order to achieve this?
You can use 'grafts' as a mechanism to re-arrange the commit order, and/or
join partial repos, and then use git filter-branch to re-write the lot as a
single cohesive repo. But this 'hack' does re-write all the commit SHA1
values, so you should minimise the number of times that happens...
It is worth capturing your import sequence as a script so that you can wash
/ rinse / repeat as often as needed to get a result you like.
> There is a script which will import sources from multiple tarballs,
> creating a commit with the contents of each tarball. It's in the git
> repository under contrib/fast-import/import-tars.perl.
I wasn't aware of those scripts. I'll be having a look at the zip import
script for my needs.
My extra problem is that almost all my zips have an extra top level
directory that changes its name for every zip (but some don't..). The TLD
changes confuses the git rename detection if I don't remove them before
committing. Fortunately it's an internal development project with no formal
releases so creating the history is a bit of a personal project which
doesn't affect ongoing development (which is the crunch question for
fidelity of the repo you create).
> tom
Philip
^ permalink raw reply
* Re: [PATCH resend] Do not create commits whose message contains NUL
From: Drew Northup @ 2012-01-01 16:27 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20111213175932.GA1663@sigill.intra.peff.net>
On Tue, 2011-12-13 at 12:59 -0500, Jeff King wrote:
> It looks like we already have a check for is_utf8, and this is not
> failing that check. I guess because is_utf8 takes a NUL-terminated
> buffer, so it simply sees the truncated result (i.e., depending on
> endianness, "foo" in utf16 is something like "f\0o\0o\0", so we check
> only "f"). We could make is_utf8 take a length parameter to be more
> accurate, and then it would catch this.
>
> However, I think that's not quite what we want. We only check is_utf8 if
> the encoding field is not set. And really, we want to reject NULs no
> matter _which_ encoding they've set, because git simply doesn't handle
> them properly.
I had already started experimenting with automatically detecting decent
UTF-16 a long while back so that compatible platforms could handle it
appropriately in terms of creating diffs and dealing with newline
munging between platforms. There is no 100% sure-fire check for UTF-16
if you don't already suspect it is possibly UTF-16. If we really want to
check for possible UTF-16 specifically I can scrape out the check I
wrote up and send it along.
The is_utf8 check was not written to detect 100% valid UTF-8 per-se. It
seems to me that it was written as part of the "is this a binary or not"
check in the add/commit path. I have thought for some time that
specifying buffer length in that whole code path would be a good idea
(but I thought that somebody else had taken up that battle while I was
busy dealing with other problems elsewhere), if for no other reason it
would force it to deal with NULs more intelligently.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Question about commit message wrapping
From: Drew Northup @ 2012-01-01 16:03 UTC (permalink / raw)
To: Sidney San Martín
Cc: Michael Haggerty, Frans Klaver, Holger Hellmuth, Andrew Ardill,
JakubNarebski, git@vger.kernel.org
In-Reply-To: <3BFBBBF6-878E-4B98-A1BB-16F841B6773D@sidneysm.com>
FWIW, I'm leaving text in this email as my mail client found it (and not
reflowing as I usually do). You can clearly see the effect of one mail
client assuming that the end display is doing all of the wrapping (I'll
not name names). When I first read the mail it looked fine because my
mail client IGNORED the inconsistencies in line wrap modes.
On Wed, 2011-12-14 at 16:04 -0500, Sidney San Martín wrote:
> On Dec 12, 2011, at 10:14 PM, Michael Haggerty wrote:
>
> > FWIW I think automatic wrapping of commit messages is a bad idea. I
> > wrap my commit messages deliberately to make them look the way I want
> > them to look. The assumption of an 80-character display has historical
> > reasons, but it is also a relatively comfortable line-width to read
> > (even on wider displays).
>
> A lot of Git repos live in heterogeneous environments. I played a little with some of the popular Git interfaces I can use on my computer. The majority of them…
>
> - compose and show commit messages in a proportional font (where the width of and formatting in "80 characters" means nothing),
In virtually all modern tools the default font is the "system default"
font, which is typically variable width. In some places I've even seen
variable pitch font rendering (I know there's a more technical term for
it, but I'm not taking the time to look it up right now) used, which is
distinct in that it makes the text easier to read when there are
potentially overlapping descenders and ascenders on adjoining lines
while leaving text without that feature unchanged in line spacing and
kerning. Try rendering ASCII-ART with that enabled!
However, it is a rare GUI tool that does not allow the user to change
the font to something more appropriate (I use fixed-width fonts for most
programming and scripting, but they are not any more helpful for reading
log messages for instance). Text-based programming tools usually just
use the console font, whatever it is--and woe be to the programmer who
switches their "console" font to something variable width. (Doing so
makes any application written with curses/ncurses in mind look very very
odd as well.)
> - don’t insert line breaks when you write a commit message (and don't provide a way to do so automatically),
Most of the "tools" I have seen that ignore all user-entered line breaks
are actually poorly written applications attempting to protect some sort
of backing database from an injection attack. Given that, many WIKI
systems typically ignore single line breaks when rendering (double line
breaks are taken to be paragraph breaks in those cases I am aware of),
so any argument about that quickly becomes moot as well. If somebody is
writing a tool that does not allow me to force multiple line breaks when
desired then so far as I am concerned their tool is broken. I don't see
a point in changing GIT as a whole because somebody writes a broken GUI
implementation.
> - do wrap commit messages when showing them.
>
> Jakub, you said that education was the answer to getting some consistency in line wrapping, but I have trouble imagining the makers of new tools using fixed-width text for anything other than code.
Remember, as soon as you think you've idiot-proofed something somebody
builds a better idiot. That's why Jakub (and many others of us) would
prefer just to tell people about the way things are intended to work and
then get out of the way and let people make their own mistakes.
> > And given that commit messages sometimes
> > contain "flowable" paragraph text, sometimes code snippets, sometimes
> > ASCII art, etc, no automatic wrapping will work correctly unless
> > everybody agrees that commit messages must be written in some specific
> > form of markup (or lightweight markup). And I can't imagine such a
> > thing ever happening.
>
> The two biggest websites I know of for talking about code, GitHub and Stack Overflow, both adopted flavors of Markdown. It is basically the formatting syntax already used for commit messages in the Git project itself (this email too), so can be formatted to look good in a specific environment (i.e. proportional fonts) and looks good by itself.
>
> (Actually, as far as I can tell commit messages are the only place GitHub doesn’t currently render user-entered text as Markdown.)
>
> I think, now and in the future, consistency will be found most easily in in Markdown-like formatting and least in 80 columns of fixed-width text.
Given that there is little consensus even between Markdown-like
formatting methods (which have in some cases been around since the
advent of movable type presses, so far as I am aware) I have to agree
with Michael here.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Possible submodule or submodule documentation issue
From: Jens Lehmann @ 2012-01-01 15:13 UTC (permalink / raw)
To: Bill Zaumen; +Cc: git, Junio C Hamano
In-Reply-To: <1325127030.1681.35.camel@yos>
Am 29.12.2011 03:50, schrieb Bill Zaumen:
> On Wed, 2011-12-28 at 20:47 +0100, Jens Lehmann wrote:
>> Am 27.12.2011 20:24, schrieb Bill Zaumen:
>> Hmm, the documentation says "the location relative to the
>> superproject’s origin repository", not the directory containing
>> it. This means you have to use ".." first to get out of the
>> repository itself, no?
>
> The problem is that the documentation also says that "<repository>
> is the URL of the new submodule's origin repository" and the wording
> would not make sense if the superproject's origin repository was not
> also named by a URL. The rules for resolving relative URIs (a URL is
> a specific type of URI) are given in
> http://tools.ietf.org/html/rfc3986#section-5.4
> which has some examples: if you resolve ./g against http://a/b/c/d;p?q
> you get http://a/b/c/g (the rules are purely syntactic and the syntax
> does not indicate that ".../foo.git" is a directory, and even the
> slashes do not definitively indicate directories in the sense of a
> file-system directory although they often do).
Thanks for that pointer, now I understand what you expected and why.
But as this behavior is in Git since September 2007 (f31a522a2d), I
suppose changing the behavior is a no-go. So what about clarifying
the docs:
---------8<-----------
[PATCH] docs: describe behavior of relative submodule URLs
Since the relative submodule URLs have been introduced in f31a522a2d, they
do not conform to the rules for resolving relative URIs but rather to
those of relative directories.
Document that behavior.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Documentation/git-submodule.txt | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 6ec3fef..b729649 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -79,7 +79,12 @@ to exist in the superproject. If <path> is not given, the
<repository> is the URL of the new submodule's origin repository.
This may be either an absolute URL, or (if it begins with ./
or ../), the location relative to the superproject's origin
-repository. If the superproject doesn't have an origin configured
+repository (Please note that to specify a repository 'foo.git'
+which is located right next to a superproject 'bar.git', you'll
+have to use '../foo.git' instead of './foo.git' - as one might expect
+when following the rules for relative URLs - because the evaluation
+of relative URLs in Git is identical to that of relative directories).
+If the superproject doesn't have an origin configured
the superproject is its own authoritative upstream and the current
working directory is used instead.
+
--
1.7.8.GIT
^ permalink raw reply related
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Jens Lehmann @ 2012-01-01 14:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antony Male, git, iveqy
In-Reply-To: <7vsjk3vw67.fsf@alter.siamese.dyndns.org>
Am 29.12.2011 23:40, schrieb Junio C Hamano:
> Antony Male <antony.male@gmail.com> writes:
> I further wonder if we can get away without using separate-git-dir option
> in this codepath, though. IOW using
>
> git clone $quiet -bare ${reference:+"$reference"} "$url" "$gitdir"
>
> might be a better solution.
A quick test shows that using a bare repo won't fly because without the
core.worktree setting commands that operate on the work tree can't be
run anymore inside submodules (starting with the initial checkout). If
we could teach setup to take the directory where the gitfile was found
as first guess for the git work tree it looks like we can make that
approach work. I'll see if I can come up with something here ...
> For example (this relates to the point I mumbled "haven't thought this
> through thoroughly yet"), doesn't the newly cloned repository have
> core.worktree that points at the working tree that records the <path>,
> which would become meaningless when a commit in the superproject that
> binds the submodule at different path <path2>?
Yes, and the core.worktree setting also contains an absolute path. So
we must either make that relative too and rewrite it on every "git
submodule add" to record the possibly changed path there or make the
bare clone work with a work tree (which sounds a bit strange ;-).
> git-submodule.sh | 21 ++++++++-------------
> 1 files changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 3adab93..9a23e9d 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -156,21 +156,16 @@ module_clone()
> ;;
> esac
>
> - if test -d "$gitdir"
> + if ! test -d "$gitdir"
> then
> - mkdir -p "$path"
> - echo "gitdir: $rel_gitdir" >"$path/.git"
> - rm -f "$gitdir/index"
> - else
> - mkdir -p "$gitdir_base"
> - if test -n "$reference"
> - then
> - git-clone $quiet "$reference" -n "$url" "$path" --separate-git-dir "$gitdir"
> - else
> - git-clone $quiet -n "$url" "$path" --separate-git-dir "$gitdir"
> - fi ||
> - die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
> + git clone $quiet -n ${reference:+"$reference"} \
> + --separate-git-dir "$gitdir" "$url" "$path" ||
> + die "$(eval_gettext "Clone of '\$url' for submodule '\$name' failed")
> fi
> +
> + mkdir -p "$path"
> + echo "gitdir: $rel_gitdir" >"$path/.git"
> + rm -f "$gitdir/index"
> }
>
> #
That broke quite some tests for me (even though I really liked
to get rid of that if ;-)
Here is a patch that solves the first part of the absolute paths
problem (passes all tests; parts of the commit message shamelessly
copied from your proposal). Then another patch can tackle the
core.worktree config setting problem to make superprojects
relocatable gain.
---------8<--------
Subject: [PATCH] submodules: always use a relative path to gitdir
Recent versions of "git submodule" maintain the submodule <name> at
<path> in the superproject using a "separate git-dir" mechanism. The
repository data for the submodule is stored in ".git/modules/<name>/"
directory of the superproject, and its working tree is created at
"<path>/" directory, with "<path>/.git" file pointing at the
".git/modules/<name>/" directory.
This is so that we can check out an older version of the superproject
that does not yet have the submodule <name> anywhere without losing
(and later having to re-clone) the submodule repository. Removing
"<path>" won't lose ".git/modules/<name>", and a different branch that
has the submodule at different location in the superproject, say
"<path2>", can create "<path2>/" and ".git" in it to point at the same
".git/modules/<name>".
When instantiating such a submodule, if ".git/modules/<name>/" does
not exist in the superproject, the submodule repository needs to be
cloned there first. Then we only need to create "<path>" directory,
point ".git/modules/<name>/" in the superproject with "<path>/.git",
and check out the working tree.
However, the current code is not structured that way. The codepath to
deal with newly cloned submodules uses "git clone --separate-git-dir"
and creates "<path>" and "<path>/.git". This can make the resulting
submodule working tree at "<path>" different from the codepath for
existing submodules. An example of such differences is that this
codepath prepares "<path>/.git" with an absolute path, while the
normal codepath uses a relative path.
Fix the latter by always writing the relative path to the git directory
in "<path>/.git". To make that work, the 'name' variable has to be set to
the value of the 'path' variable for newly added submodules.
This is only the first step to make superprojects movable again like they
were before the separate-git-dir approach was introduced. The second step
must be to either use a relative path in core.worktree too or to get rid
of that setting by using a bare repo in "./git/modules/<name>".
While at it also replace an if/else construct evaluating the presence
of the 'reference' option with a single line of bash code.
Reported-by: Antony Male <antony.male@gmail.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
git-submodule.sh | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 3adab93..2a93c61 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -131,6 +131,7 @@ module_clone()
gitdir=
gitdir_base=
name=$(module_name "$path" 2>/dev/null)
+ test -n "$name" || name="$path"
base_path=$(dirname "$path")
gitdir=$(git rev-parse --git-dir)
@@ -159,18 +160,15 @@ module_clone()
if test -d "$gitdir"
then
mkdir -p "$path"
- echo "gitdir: $rel_gitdir" >"$path/.git"
rm -f "$gitdir/index"
else
mkdir -p "$gitdir_base"
- if test -n "$reference"
- then
- git-clone $quiet "$reference" -n "$url" "$path" --separate-git-dir "$gitdir"
- else
- git-clone $quiet -n "$url" "$path" --separate-git-dir "$gitdir"
- fi ||
+ git clone $quiet -n ${reference:+"$reference"} \
+ --separate-git-dir "$gitdir" "$url" "$path" ||
die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
fi
+
+ echo "gitdir: $rel_gitdir" >"$path/.git"
}
#
--
1.7.8.2.303.g78a27
^ permalink raw reply related
* git exit with error code 1
From: ashish @ 2012-01-01 14:41 UTC (permalink / raw)
To: git
Ant script to run clone
<target name="clone" description="get the latest files">
<delete includeemptydirs="true">
<filesetdir="/opt/cruisecontrol-bin-2.8.4/projects/Mss/copyExample/local_copy/Mss"
defaultexcludes="false">
<include name="**/*" />
</fileset>
</delete>
<exec executable="git"
dir="/opt/cruisecontrol-bin-2.8.4/projects/Mss/copyExample/local_copy/Mss">
<arg line="clone -o fl ssh://git@ipaddress/git/run.git Mss" />
</exec>
</target>
In my current CruiseControl setup I am running the following target:
<modificationsetquietperiod="60">
<git
localworkingcopy="${projects.dir}/${project.name}/local_copy/${project.name}/"/>
</modificationset>
Running cruisecontrol gives git exit with error code 1. I guess
modificationset is not able to find git local working copy.
Any help would be welcome and greatly appreciable .
--
View this message in context: http://git.661346.n2.nabble.com/git-exit-with-error-code-1-tp7142041p7142041.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Junio C Hamano @ 2012-01-01 9:11 UTC (permalink / raw)
To: Sven Strickroth; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <4EFDD06A.3010708@tu-clausthal.de>
Sven Strickroth <sven.strickroth@tu-clausthal.de> writes:
> Am 30.12.2011 14:54 schrieb Jeff King:
> ...
>> Username: <text input>
>> Password: <text input>
>> Remember password? [checkbox]
>>
>> I was planning to do something custom for credentials as an extension to
>> the credential helper protocol, but this could also fall under the
>> heading of a general prompt helper.
>
> This might be problematic, because (for git-svn) username and password
> are not requested together.
I do not think Peff means the dialog must ask these three items at the
same time. The point is that other codepaths know they need to ask them
and would benefit if they can instruct the dialog external helper to ask
them in a single interaction. So if your callsite does not ask them
together, it is OK. You can keep asking them separately in two dialog
interactions.
^ permalink raw reply
* Re: How to deal with historic tar-balls
From: Tomas Carnecky @ 2012-01-01 0:27 UTC (permalink / raw)
To: nn6eumtr; +Cc: git
In-Reply-To: <4EFF5CDA.5050809@gmail.com>
On 12/31/11 8:04 PM, nn6eumtr wrote:
> I have a number of older projects that I want to bring into a git
> repository. They predate a lot of the popular scm systems, so they are
> primarily a collection of tarballs today.
>
> I'm fairly new to git so I have a couple questions related to this:
>
> - What is the best approach for bringing them in? Do I just create a
> repository, then unpack the files, commit them, clean out the
> directory unpack the next tarball, and repeat until everything is loaded?
>
> - Do I need to pay special attention to files that are renamed/removed
> from version to version?
>
> - If the timestamps change on a file but the actual content does not,
> will git treat it as a non-change once it realizes the content hasn't
> changed?
>
> - Last, if after loading the repository I find another version of the
> files that predates those I've loaded, or are intermediate between two
> commits I've already loaded, is there a way to go say that commit B is
> actually the ancestor of commit C? (i.e. a->c becomes a->b->c if you
> were to visualize the commit timeline or do diffs) Or do I just reload
> the tarballs in order to achieve this?
There is a script which will import sources from multiple tarballs,
creating a commit with the contents of each tarball. It's in the git
repository under contrib/fast-import/import-tars.perl.
tom
^ permalink raw reply
* Re: git alias question
From: Jakub Narebski @ 2011-12-31 23:30 UTC (permalink / raw)
To: Michael Horowitz; +Cc: David Aguilar, Dave Borowitz, git, Junio C Hamano
In-Reply-To: <CAFLRborAuoWKxOeHtPRujSYbQPk67RCxTiVBavtWDeh-Byfa2w@mail.gmail.com>
Michael Horowitz <michael.horowitz@ieee.org> writes:
> The log operation does seem to make the most sense as the mechanism to
> search for the results. Making it work with difftool would work...
> Not sure if "--log" to difftool or some other options as suggested in
> the other thread would be most consistent UI-wise as stated, but
> either would work for me.
>
> On a separate note, some environment variable like GIT_PREFIX with the
> CWD would make the alias functionality more flexible.
1f5d271 (setup: Provide GIT_PREFIX to built-ins, 2011-05-25) is
present in v1.7.7; 7cf16a1 (handle_alias: provide GIT_PREFIX to
!alias, 2011-04-27) is in 1.7.6
--
Jakub Narebski
^ permalink raw reply
* Re: git alias question
From: Michael Horowitz @ 2011-12-31 21:31 UTC (permalink / raw)
To: David Aguilar; +Cc: Dave Borowitz, git, Junio C Hamano
In-Reply-To: <CAJDDKr5a8TB82h4ULWtamLOVu_4Fv+cGw1YfEL987gM3yM4TMg@mail.gmail.com>
The log operation does seem to make the most sense as the mechanism to
search for the results. Making it work with difftool would work...
Not sure if "--log" to difftool or some other options as suggested in
the other thread would be most consistent UI-wise as stated, but
either would work for me.
On a separate note, some environment variable like GIT_PREFIX with the
CWD would make the alias functionality more flexible.
Mike
On Thu, Dec 29, 2011 at 8:59 PM, David Aguilar <davvid@gmail.com> wrote:
>
> On Thu, Dec 29, 2011 at 9:08 AM, Dave Borowitz <dborowitz@google.com> wrote:
> > On Wed, Dec 28, 2011 at 17:27, Michael Horowitz
> > <michael.horowitz@ieee.org> wrote:
> >> ldiff = "!git diff `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
> >
> > FWIW, you can also do this as:
> > ldiff = log -p -1 --format=format: --
> >
> >> ldifft = "!git difftool `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
> >
> > I don't know that you can do something equivalent with difftool. I
> > suppose you could do the above with "GIT_EXTERNAL_DIFF=<some difftool
> > wrapper> git ldiff", but that's not very helpful.
>
> difftool cannot be driven by log right now. It is something we
> thought would be helpful in the past:
>
> http://thread.gmane.org/gmane.comp.version-control.git/114269/focus=114367
>
> On 2009-03-23 Junio C Hamano <gitster <at> pobox.com> wrote:
> > Perhaps we would want a convenient way for "log -p" or "show -p" to drive
> > difftool as a backend?
>
> I think that's exactly it. difftool wraps diff; a log equivalent
> would be quite helpful.
>
> One idea is for difftool to learn a "--log" option to make it wrap log
> instead. I don't know if a diff-like command having a "--log" option
> is ideal from a consistency-of-user-interface POV so I'm open to
> ideas. It is convenient, though. It does seem like difftool would be
> a good place to expose this feature.
>
> I'd be interested in the "teach log / show -p about GIT_EXTERNAL_DIFF"
> route, if that sounds like a good idea.
> --
> David
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Phil Hord @ 2011-12-31 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antony Male, git, iveqy
In-Reply-To: <7vsjk3vw67.fsf@alter.siamese.dyndns.org>
On Thu, Dec 29, 2011 at 5:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Antony Male <antony.male@gmail.com> writes:
>
>> Git submoule clone uses git clone --separate-git-dir to checkout a
>> submodule's git repository into <supermodule>/.git/modules,...
>
> This is misleading. The <superproject>/.git/modules/<name> is the location
> of the $GIT_DIR for the submodule <name>, not the location of its checkout
> at <superproject>/<path> that is outside <superproject>/.git/modules/
> hierarchy.
Yes, so I think a simple s/checkout/clone/ should fix it.
[...]
>> In the submodules scenario, neither the git repository nor the working
>> copy will be moved relative to each other. However, the supermodule may
>> be moved,...
>
> Again, who said that you are allowed to move the superproject directory in
> the first place? I would understand that it might be nicer if it could be
> moved but I haven't thought this through thoroughly yet---there may be
> other side effects from doing so, other than the relativeness of "gitdir".
Previously it was accepted practice to clone a local repo with rsync.
This method continues to work well even with submodules before
git-files became the norm. But now it breaks because of the absolute
paths.
Similarly, clones on network mounts and portable drives where absolute
paths may change from time to time or machine to machine will also
break now but worked before.
So, who said you were NOT allowed to move the superproject directory
directory in the first place? It seems natural that you should be
able to do so, especially since the submodules are all contained
within the superproject path.
>> Previously, if git submodule clone was called when the submodule's git
>> repository already existed in <supermodule>/.git/modules, it would
>> simply re-create the submodule's .git file, using a relative path.
>
> ... "to point at the existing <superproject>/.git/modules/<name>".
>
> Overall, I think I can agree with the goal, but the tone of the proposed
> commit log message rubs the reader in a wrong way to see clearly what this
> patch is proposing to do and where its merit lies. It is probably not a
> big deal, and perhaps it may be just the order of explanation.
>
> I would probably explain the goal like this if I were doing this patch,
> without triggering any need for revisionist history bias.
>
> Recent versions of "git submodule" maintain the submodule <name> at
> <path> in the superproject using a "separate git-dir" mechanism. The
> repository data for the submodule is stored in ".git/modules/<name>/"
> directory of the superproject, and its working tree is created at
> "<path>/" directory, with "<path>/.git" file pointing at the
> ".git/modules/<name>/" directory.
>
> This is so that we can check out an older version of the superproject
> that does not yet have the submodule <name> anywhere without losing
> (and later having to re-clone) the submodule repository. Removing
Revisionism nit: the real danger here is that you lose local commits.
> "<path>" won't lose ".git/modules/<name>", and a different branch that
> has the submodule at different location in the superproject, say
> "<path2>", can create "<path2>/" and ".git" in it to point at the same
> ".git/modules/<name>".
This doesn't explain why one path is absolute and one is relative.
But I don't suppose this is the place for historical documentation
anyway.
> When instantiating such a submodule, if ".git/modules/<name>/" does
> not exist in the superproject, the submodule repository needs to be
> cloned there first. Then we only need to create "<path>" directory,
> point ".git/modules/<name>/" in the superproject with "<path>/.git",
> and check out the working tree.
>
> However, the current code is not structured that way. The codepath to
> deal with newly cloned submodules uses "git clone --separate-git-dir"
> and creates "<path>" and "<path>/.git". This can make the resulting
> submodule working tree at "<path>" different from the codepath for
> existing submodules. An example of such differences is that this
> codepath prepares "<path>/.git" with an absolute path, while the
> normal codepath uses a relative path.
I had to read this three times before I understood it. There are some
minor grammatical nits in it, but also the use of nearness and use of
"path" and "codepath" to mean two unrelated things was misleading me.
Here's my attempt to clean it up:
However, the current code is not structured that way. The code to
deal with newly cloned submodules is different from the code to
checkout a workdir for existing submodules. The "newly cloned
submodule" code uses "git clone --separate-git-dir" to create
"<path>" and "<path>/.git". The "existing submodules" code
simply creates the "<path>/.git" internally, using a relative path.
This makes the resulting submodule working tree at "<path>" different
depending on which code is used. An example of such differences
is that the "newly cloned submodule" code prepares "<path>/.git"
with an absolute path, while the "existing submodules" code
prepares the same file using a relative path.
> When explained this way, the remedy is quite clear, and the change is more
> forward-looking, isn't it? If we later start doing more in the codepath
> to deal with existing submodules, your patch may break without having
> extra code to cover the "newly cloned" case, too.
> I further wonder if we can get away without using separate-git-dir option
> in this codepath, though. IOW using
>
> git clone $quiet -bare ${reference:+"$reference"} "$url" "$gitdir"
>
> might be a better solution.
You may be right about this one. I still think the addition of a
--relative-path option to 'git-checkout --separate-work-dir' could be
useful and also easier to maintain/describe.
> For example (this relates to the point I mumbled "haven't thought this
> through thoroughly yet"), doesn't the newly cloned repository have
> core.worktree that points at the working tree that records the <path>,
> which would become meaningless when a commit in the superproject that
> binds the submodule at different path <path2>?
Ooh, yes it does. Maybe that should be fixed in this case too.
Because submodule cloning with a separate work-dir is a special case
of git-files and work-dirs because we know that each is relative
(subordinate) to the superproject path. Therefore, I think in this
special-case version of the "separate work-dir" scenario, we should
use super-project-relative paths for both cases.
How do we codify this so this functionality is reliably retained by
future developers? I think moving the code into someplace more
explicit would help, but I haven't looked too deeply at the code.
> git-submodule.sh | 21 ++++++++-------------
> 1 files changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 3adab93..9a23e9d 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -156,21 +156,16 @@ module_clone()
> ;;
> esac
>
> - if test -d "$gitdir"
> + if ! test -d "$gitdir"
> then
> - mkdir -p "$path"
> - echo "gitdir: $rel_gitdir" >"$path/.git"
> - rm -f "$gitdir/index"
> - else
> - mkdir -p "$gitdir_base"
> - if test -n "$reference"
> - then
> - git-clone $quiet "$reference" -n "$url" "$path" --separate-git-dir "$gitdir"
> - else
> - git-clone $quiet -n "$url" "$path" --separate-git-dir "$gitdir"
> - fi ||
> - die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
> + git clone $quiet -n ${reference:+"$reference"} \
> + --separate-git-dir "$gitdir" "$url" "$path" ||
> + die "$(eval_gettext "Clone of '\$url' for submodule '\$name' failed")
> fi
> +
> + mkdir -p "$path"
> + echo "gitdir: $rel_gitdir" >"$path/.git"
> + rm -f "$gitdir/index"
> }
Doesn't this avoid creating core.worktree in the first place? I'm ok
with that because I assume it's never used in the submodule scenario,
but I also suspect that assumption could be wrong. Any concerns?
Phil
^ 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