* git alias question
From: Michael Horowitz @ 2011-12-29 1:27 UTC (permalink / raw)
To: git
Hello all,
I have been unable to find a solution to this, so I figured I would
post to this list...
I am trying to make an easy command to let me look at the last diff to
a specified file, either plain or with a diff tool, such as vimdiff.
This is the last actual change, not just HEAD^, because the file may
not have changed in many commits.
I was able to make the following 2 aliases, which work perfectly
except for one problem...
ldiff = "!git diff `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
ldifft = "!git difftool `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
The problem is the limitation that shell commands are always executed
at the top-level directory of the repository. Normally I am in a
deeply nested directory, so if I specify the file name in that
directory, it doesn't work. Having to specify the full path relative
to the top level makes these aliases more cumbersome to use than their
worth.
Is there a way to get around this, or even a completely different way
to do this that I am missing? I want to avoid making a completely
separate shell script.
Thanks,
Mike
^ permalink raw reply
* Re: Possible submodule or submodule documentation issue
From: Bill Zaumen @ 2011-12-29 2:50 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <4EFB725C.7030600@web.de>
On Wed, 2011-12-28 at 20:47 +0100, Jens Lehmann wrote:
> Am 27.12.2011 20:24, schrieb Bill Zaumen:
> > For the 'add' command, the man page for get-submodule states
> >
> > "<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."
> >
...
> I assume you did forget to add a "cd library-pkg" here.
Yes, sorry for miscopying.
>
> 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). Also, I've enclosed a
Java program illustrating the correct behavior (a method in the Java
class library can resolve URIs so this is an independent test).
import java.net.*;
public class Test {
public static void main(String argv[]) {
try {
URI base = new URI("file:///home/USER/Projects/test/repo.git");
URI relative = new URI("./submodule.git");
URI absolute = base.resolve(relative);
System.out.println(relative.toString() + " -> "
+absolute.toString());
relative = new URI("../submodule.git");
absolute = base.resolve(relative);
System.out.println(relative.toString() + " -> "
+absolute.toString());
} catch (Exception e) {
e.printStackTrace();
System.exit(1);
}
System.exit(0);
}
}
^ permalink raw reply
* Re: GIT and SSH
From: Reza Mostafid @ 2011-12-29 3:06 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20111228T091942-66@post.gmane.org>
Thanks for all the feedback so far.....helps me find out where to look.
Regards
Reza
^ permalink raw reply
* Re: git alias question
From: Miles Bader @ 2011-12-29 3:21 UTC (permalink / raw)
To: Michael Horowitz; +Cc: git
In-Reply-To: <CAFLRbopjqW7OEWN4kxy+6Gb828h4zBC_h=4WiP-q1__LeezxUw@mail.gmail.com>
Michael Horowitz <michael.horowitz@ieee.org> writes:
> I was able to make the following 2 aliases, which work perfectly
> except for one problem...
>
> ldiff = "!git diff `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
> ldifft = "!git difftool `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
>
> The problem is the limitation that shell commands are always executed
> at the top-level directory of the repository.
Hmmm, it'd be cool if git exported an environment variable containing
the CWD when it invoked external aliases like this...!
-Miles
--
Love is the difficult realization that something other than oneself is real.
[Iris Murdoch]
^ permalink raw reply
* [PATCH] Add MYMETA.json to perl/.gitignore
From: Jack Nagel @ 2011-12-29 4:42 UTC (permalink / raw)
To: git, gitster; +Cc: jacknagel
ExtUtils::MakeMaker generates MYMETA.json in addition to MYMETA.yml
since version 6.57_07. As it suggests, it is just meta information about
the build and is cleaned up with 'make clean', so it should be ignored.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
---
perl/.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/perl/.gitignore b/perl/.gitignore
index 9235e73..d5c6e22 100644
--- a/perl/.gitignore
+++ b/perl/.gitignore
@@ -1,5 +1,6 @@
perl.mak
perl.mak.old
+MYMETA.json
MYMETA.yml
blib
blibdirs
--
1.7.8.2.302.g17b4
^ permalink raw reply related
* Re: git alias question
From: Junio C Hamano @ 2011-12-29 5:32 UTC (permalink / raw)
To: Miles Bader; +Cc: Michael Horowitz, git
In-Reply-To: <87wr9g2hcd.fsf@catnip.gol.com>
Miles Bader <miles@gnu.org> writes:
> Michael Horowitz <michael.horowitz@ieee.org> writes:
>> I was able to make the following 2 aliases, which work perfectly
>> except for one problem...
>>
>> ldiff = "!git diff `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
>> ldifft = "!git difftool `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
>>
>> The problem is the limitation that shell commands are always executed
>> at the top-level directory of the repository.
>
> Hmmm, it'd be cool if git exported an environment variable containing
> the CWD when it invoked external aliases like this...!
Yeah, something like GIT_PREFIX environment variable, I guess.
^ permalink raw reply
* Re: [PATCH] Add MYMETA.json to perl/.gitignore
From: Junio C Hamano @ 2011-12-29 5:34 UTC (permalink / raw)
To: Jack Nagel; +Cc: git
In-Reply-To: <1325133725-20671-1-git-send-email-jacknagel@gmail.com>
Jack Nagel <jacknagel@gmail.com> writes:
> ExtUtils::MakeMaker generates MYMETA.json in addition to MYMETA.yml
> since version 6.57_07. As it suggests, it is just meta information about
Are we better off ignoring MYMETA.* instead, so that we won't get affected
when they start dropping new cruft with the same information in yet more
different formats?
> the build and is cleaned up with 'make clean', so it should be ignored.
>
> Signed-off-by: Jack Nagel <jacknagel@gmail.com>
> ---
> perl/.gitignore | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/perl/.gitignore b/perl/.gitignore
> index 9235e73..d5c6e22 100644
> --- a/perl/.gitignore
> +++ b/perl/.gitignore
> @@ -1,5 +1,6 @@
> perl.mak
> perl.mak.old
> +MYMETA.json
> MYMETA.yml
> blib
> blibdirs
^ permalink raw reply
* how can i read git repository information.
From: sp @ 2011-12-29 6:16 UTC (permalink / raw)
To: git
hi all,
i new to git.i have git repository folder of one existing project. i want to
read git repository files from that folder but when i open that file in
notepad ++ it shows some encoded information,,
pleas help...
--
View this message in context: http://git.661346.n2.nabble.com/how-can-i-read-git-repository-information-tp7134908p7134908.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Add MYMETA.json to perl/.gitignore
From: Junio C Hamano @ 2011-12-29 6:58 UTC (permalink / raw)
To: git; +Cc: Jack Nagel
In-Reply-To: <7vty4kx7ol.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jack Nagel <jacknagel@gmail.com> writes:
>
>> ExtUtils::MakeMaker generates MYMETA.json in addition to MYMETA.yml
>> since version 6.57_07. As it suggests, it is just meta information about
>
> Are we better off ignoring MYMETA.* instead, so that we won't get affected
> when they start dropping new cruft with the same information in yet more
> different formats?
Just to make sure there is no misunderstanding. The above is _not_ a
rhetorical question that implies that I _think_ the patch should instead
change the existing "MYMETA.yml" to "MYMETA.*" without adding a new entry
to ignore "MYMETA.json". It is a pure question, and a valid answer could
be "I checked with Perl people and they promise they won't be adding any
more MYMETA.foo left and right with new MakeMaker releases", in which case
the original patch is absolutely the right thing to do.
I am simply asking because I do not know.
>
>> the build and is cleaned up with 'make clean', so it should be ignored.
>>
>> Signed-off-by: Jack Nagel <jacknagel@gmail.com>
>> ---
>> perl/.gitignore | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/perl/.gitignore b/perl/.gitignore
>> index 9235e73..d5c6e22 100644
>> --- a/perl/.gitignore
>> +++ b/perl/.gitignore
>> @@ -1,5 +1,6 @@
>> perl.mak
>> perl.mak.old
>> +MYMETA.json
>> MYMETA.yml
>> blib
>> blibdirs
^ permalink raw reply
* Re: how can i read git repository information.
From: Magnus Bäck @ 2011-12-29 8:21 UTC (permalink / raw)
To: sp; +Cc: git
In-Reply-To: <1325139370841-7134908.post@n2.nabble.com>
On Thursday, December 29, 2011 at 07:16 CET,
sp <sonali.treewalker@gmail.com> wrote:
> i new to git.i have git repository folder of one existing project.
> i want to read git repository files from that folder but when i
> open that file in notepad ++ it shows some encoded information,,
Which file are you attempting to open? What is it that you
want to do?
A non-bare git repository consists of the working tree files
(i.e. the files you keep under version control) and the files
in the .git directory. Most of the latter files aren't meant
for human consumption but are used internally by Git for
bookkeeping purposes. Opening them in a text editor won't be
useful.
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
^ permalink raw reply
* Re: [PATCH] Add MYMETA.json to perl/.gitignore
From: Ævar Arnfjörð Bjarmason @ 2011-12-29 9:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jack Nagel
In-Reply-To: <7vmxabyiby.fsf@alter.siamese.dyndns.org>
On Thu, Dec 29, 2011 at 07:58, Junio C Hamano <gitster@pobox.com> wrote:
> I am simply asking because I do not know.
It'll stay JSON for the forseeable future. It's part of the CPAN META
Specification.
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2011, #09; Tue, 27)
From: Nguyen Thai Ngoc Duy @ 2011-12-29 11:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v62h14mdt.fsf@alter.siamese.dyndns.org>
On Wed, Dec 28, 2011 at 6:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * nd/index-pack-no-recurse (2011-12-27) 4 commits
> - fixup! 3413d4d
> - index-pack: eliminate unlimited recursion in get_delta_base()
> - index-pack: eliminate recursion in find_unresolved_deltas
> - Eliminate recursion in setting/clearing marks in commit list
>
> Expecting a reroll.
Hmm.. I thought you could easily squash the fixup in. Any reasons for
a reroll besides the fixup?
--
Duy
^ permalink raw reply
* Re: git alias question
From: Dave Borowitz @ 2011-12-29 17:08 UTC (permalink / raw)
To: Michael Horowitz; +Cc: git
In-Reply-To: <CAFLRbopjqW7OEWN4kxy+6Gb828h4zBC_h=4WiP-q1__LeezxUw@mail.gmail.com>
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.
^ permalink raw reply
* Re: [PATCH] Add MYMETA.json to perl/.gitignore
From: Jack Nagel @ 2011-12-29 17:40 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, git
In-Reply-To: <CACBZZX5kkX3jc-PvSe2=ZWm1DC8tWvsZN9q5G4JabEVnvf6TQA@mail.gmail.com>
On Thu, Dec 29, 2011 at 3:50 AM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> On Thu, Dec 29, 2011 at 07:58, Junio C Hamano <gitster@pobox.com> wrote:
>> I am simply asking because I do not know.
>
> It'll stay JSON for the forseeable future. It's part of the CPAN META
> Specification.
Yep, cf. [1]. Thanks.
Jack
[1] http://search.cpan.org/~mschwern/ExtUtils-MakeMaker-6.62/lib/ExtUtils/MakeMaker.pm#Module_Meta-Data_(META_and_MYMETA)
^ permalink raw reply
* Re: [PATCH] gc --auto: warn garbage collection happens soon
From: Mark Brown @ 2011-12-29 18:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguy???n Th??i Ng???c Duy, git
In-Reply-To: <7vpqf94r8c.fsf@alter.siamese.dyndns.org>
On Tue, Dec 27, 2011 at 01:52:35PM -0800, Junio C Hamano wrote:
> And if the answer to that tongue-in-cheek question is no, what is the
> reason why the users will not find the messages disturbing, while loathing
> the auto-gc?
The main problem I've noticed with the auto gc is that git gui seems to
want to do one at a much lower threashold than the command line tools
(and far too aggressive), it seems that the logic that determines when
to do one isn't quite in agreement within all the git tools.
^ permalink raw reply
* git-log --pretty=format:'[%x00]%w(0,0,1)' doesn't print NUL and "]"
From: Tanaka Akira @ 2011-12-29 18:41 UTC (permalink / raw)
To: git
I found that git-log doesn't print characters in --pretty option as follows.
% git log --pretty=format:'[%x00]%w(0,0,1)' |od -c
0000000 [ \n [ \n [ \n [ \n [ \n [ \n [ \n [ \n
*
0022320 [ \n [ \n [ \n [
0022327
I think NUL and "]" should be printed.
Note that git log works as I expected if I use %w(0,0,0) instead of %w(0,0,1),
I don't use %w(0,0,1) or I use %x01 instead of %x00.
% git log --pretty=format:'[%x00]%w(0,0,0)' |od -c
0000000 [ \0 ] \n [ \0 ] \n [ \0 ] \n [ \0 ] \n
*
0044640 [ \0 ] \n [ \0 ] \n [ \0 ] \n [ \0 ]
0044657
% git log --pretty=format:'[%x00]' |od -c
0000000 [ \0 ] \n [ \0 ] \n [ \0 ] \n [ \0 ] \n
*
0044640 [ \0 ] \n [ \0 ] \n [ \0 ] \n [ \0 ]
0044657
% git log --pretty=format:'[%x01]%w(0,0,1)' |od -c
0000000 [ 001 ] \n [ 001 ] \n [ 001 ] \n [ 001 ] \n
*
0044640 [ 001 ] \n [ 001 ] \n [ 001 ] \n [ 001 ]
0044657
I used git 1.7.8.2.
% git --version
git version 1.7.8.2
--
Tanaka Akira
^ permalink raw reply
* Re: git-log --pretty=format:'[%x00]%w(0,0,1)' doesn't print NUL and "]"
From: Jeff King @ 2011-12-29 19:23 UTC (permalink / raw)
To: Tanaka Akira; +Cc: git
In-Reply-To: <CANjopZFqiy+Ai4u6QYYnza5J7A3NAt-f17yR9AsYok-g3Hbb3w@mail.gmail.com>
On Fri, Dec 30, 2011 at 03:41:20AM +0900, Tanaka Akira wrote:
> I found that git-log doesn't print characters in --pretty option as follows.
>
> % git log --pretty=format:'[%x00]%w(0,0,1)' |od -c
> 0000000 [ \n [ \n [ \n [ \n [ \n [ \n [ \n [ \n
> *
> 0022320 [ \n [ \n [ \n [
> 0022327
>
> I think NUL and "]" should be printed.
I think there is a bug in strbuf_add_indented_text, which uses
strchrnul, even though a strbuf may contain literal NULs. Although one
could argue that trying to wrap a NUL is questionable (after all, what
is its character width?), the current behavior seems pretty wrong.
I think the whole wrapping callchain needs to be adjusted to handle
arbitrary bytes (there are also several checks in
strbuf_add_wrapped_text for NUL terminators).
-Peff
^ permalink raw reply
* [PATCH] stash: Don't fail if work dir contains file named 'HEAD'
From: Jonathon Mah @ 2011-12-29 20:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
When performing a plain "git stash" (without --patch), git-diff would fail
with "fatal: ambiguous argument 'HEAD': both revision and filename". The
output was piped into git-update-index, masking the failed exit status.
The output is now sent to a temporary file (which is cleaned up by
existing code), and the exit status is checked. The "HEAD" arg to the
git-diff invocation has been disambiguated too, of course.
In patch mode, "git stash -p" would fail harmlessly, leaving the working
dir untouched.
Signed-off-by: Jonathon Mah <me@JonathonMah.com>
---
git-stash.sh | 5 ++-
t/t3903-stash.sh | 25 +++++++++++++++++++
t/t3904-stash-patch.sh | 47 ++++++++++++++++++++++-------------
t/t3905-stash-include-untracked.sh | 13 +++++++++-
4 files changed, 69 insertions(+), 21 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index c766692..a46f32a 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -115,7 +115,8 @@ create_stash () {
git read-tree --index-output="$TMPindex" -m $i_tree &&
GIT_INDEX_FILE="$TMPindex" &&
export GIT_INDEX_FILE &&
- git diff --name-only -z HEAD | git update-index -z --add --remove --stdin &&
+ git diff --name-only -z HEAD -- > "$TMP-stagenames" &&
+ git update-index -z --add --remove --stdin < "$TMP-stagenames" &&
git write-tree &&
rm -f "$TMPindex"
) ) ||
@@ -134,7 +135,7 @@ create_stash () {
w_tree=$(GIT_INDEX_FILE="$TMP-index" git write-tree) ||
die "$(gettext "Cannot save the current worktree state")"
- git diff-tree -p HEAD $w_tree > "$TMP-patch" &&
+ git diff-tree -p HEAD $w_tree -- > "$TMP-patch" &&
test -s "$TMP-patch" ||
die "$(gettext "No changes selected")"
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index fcdb182..8f1d07a 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -601,4 +601,29 @@ test_expect_success 'stash apply shows status same as git status (relative to cu
test_cmp expect actual
'
+cat > expect << EOF
+diff --git a/HEAD b/HEAD
+new file mode 100644
+index 0000000..fe0cbee
+--- /dev/null
++++ b/HEAD
+@@ -0,0 +1 @@
++file-not-a-ref
+EOF
+
+test_expect_success 'stash where working directory contains "HEAD" file' '
+ git stash clear &&
+ git reset --hard &&
+ echo file-not-a-ref > HEAD &&
+ git add HEAD &&
+ git stash &&
+ git diff-files --quiet &&
+ git diff-index --cached --quiet HEAD &&
+ test_tick &&
+ test $(git rev-parse stash^) = $(git rev-parse HEAD) &&
+ git diff stash^..stash > output &&
+ test_cmp output expect &&
+ git stash drop
+'
+
test_done
diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
index 781fd71..70655c1 100755
--- a/t/t3904-stash-patch.sh
+++ b/t/t3904-stash-patch.sh
@@ -7,7 +7,8 @@ test_expect_success PERL 'setup' '
mkdir dir &&
echo parent > dir/foo &&
echo dummy > bar &&
- git add bar dir/foo &&
+ echo committed > HEAD &&
+ git add bar dir/foo HEAD &&
git commit -m initial &&
test_tick &&
test_commit second dir/foo head &&
@@ -17,47 +18,57 @@ test_expect_success PERL 'setup' '
save_head
'
-# note: bar sorts before dir, so the first 'n' is always to skip 'bar'
+# note: order of files with unstaged changes: HEAD bar dir/foo
test_expect_success PERL 'saying "n" does nothing' '
+ set_state HEAD HEADfile_work HEADfile_index &&
set_state dir/foo work index &&
- (echo n; echo n) | test_must_fail git stash save -p &&
- verify_state dir/foo work index &&
- verify_saved_state bar
+ (echo n; echo n; echo n) | test_must_fail git stash save -p &&
+ verify_state HEAD HEADfile_work HEADfile_index &&
+ verify_saved_state bar &&
+ verify_state dir/foo work index
'
test_expect_success PERL 'git stash -p' '
- (echo n; echo y) | git stash save -p &&
- verify_state dir/foo head index &&
+ (echo y; echo n; echo y) | git stash save -p &&
+ verify_state HEAD committed HEADfile_index &&
verify_saved_state bar &&
+ verify_state dir/foo head index &&
git reset --hard &&
git stash apply &&
- verify_state dir/foo work head &&
- verify_state bar dummy dummy
+ verify_state HEAD HEADfile_work committed &&
+ verify_state bar dummy dummy &&
+ verify_state dir/foo work head
'
test_expect_success PERL 'git stash -p --no-keep-index' '
- set_state dir/foo work index &&
+ set_state HEAD HEADfile_work HEADfile_index &&
set_state bar bar_work bar_index &&
- (echo n; echo y) | git stash save -p --no-keep-index &&
- verify_state dir/foo head head &&
+ set_state dir/foo work index &&
+ (echo y; echo n; echo y) | git stash save -p --no-keep-index &&
+ verify_state HEAD committed committed &&
verify_state bar bar_work dummy &&
+ verify_state dir/foo head head &&
git reset --hard &&
git stash apply --index &&
- verify_state dir/foo work index &&
- verify_state bar dummy bar_index
+ verify_state HEAD HEADfile_work HEADfile_index &&
+ verify_state bar dummy bar_index &&
+ verify_state dir/foo work index
'
test_expect_success PERL 'git stash --no-keep-index -p' '
- set_state dir/foo work index &&
+ set_state HEAD HEADfile_work HEADfile_index &&
set_state bar bar_work bar_index &&
- (echo n; echo y) | git stash save --no-keep-index -p &&
+ set_state dir/foo work index &&
+ (echo y; echo n; echo y) | git stash save --no-keep-index -p &&
+ verify_state HEAD committed committed &&
verify_state dir/foo head head &&
verify_state bar bar_work dummy &&
git reset --hard &&
git stash apply --index &&
- verify_state dir/foo work index &&
- verify_state bar dummy bar_index
+ verify_state HEAD HEADfile_work HEADfile_index &&
+ verify_state bar dummy bar_index &&
+ verify_state dir/foo work index
'
test_expect_success PERL 'none of this moved HEAD' '
diff --git a/t/t3905-stash-include-untracked.sh b/t/t3905-stash-include-untracked.sh
index ef44fb2..7f75622 100755
--- a/t/t3905-stash-include-untracked.sh
+++ b/t/t3905-stash-include-untracked.sh
@@ -17,6 +17,7 @@ test_expect_success 'stash save --include-untracked some dirty working directory
echo 3 > file &&
test_tick &&
echo 1 > file2 &&
+ echo 1 > HEAD &&
mkdir untracked &&
echo untracked >untracked/untracked &&
git stash --include-untracked &&
@@ -35,6 +36,13 @@ test_expect_success 'stash save --include-untracked cleaned the untracked files'
'
cat > expect.diff <<EOF
+diff --git a/HEAD b/HEAD
+new file mode 100644
+index 0000000..d00491f
+--- /dev/null
++++ b/HEAD
+@@ -0,0 +1 @@
++1
diff --git a/file2 b/file2
new file mode 100644
index 0000000..d00491f
@@ -51,6 +59,7 @@ index 0000000..5a72eb2
+untracked
EOF
cat > expect.lstree <<EOF
+HEAD
file2
untracked
EOF
@@ -58,7 +67,8 @@ EOF
test_expect_success 'stash save --include-untracked stashed the untracked files' '
test "!" -f file2 &&
test ! -e untracked &&
- git diff HEAD stash^3 -- file2 untracked >actual &&
+ test "!" -f HEAD &&
+ git diff HEAD stash^3 -- HEAD file2 untracked >actual &&
test_cmp expect.diff actual &&
git ls-tree --name-only stash^3: >actual &&
test_cmp expect.lstree actual
@@ -75,6 +85,7 @@ git clean --force --quiet
cat > expect <<EOF
M file
+?? HEAD
?? actual
?? expect
?? file2
--
1.7.8
Jonathon Mah
me@JonathonMah.com
^ permalink raw reply related
* [PATCH] Submodules always use a relative path to gitdir
From: Antony Male @ 2011-12-29 21:00 UTC (permalink / raw)
To: git; +Cc: gitster, iveqy, Antony Male
This fixes a problem where moving a git repository with checked-out
submodules would cause a fatal error when commands such as 'git
submodule update' were run.
Git submoule clone uses git clone --separate-git-dir to checkout a
submodule's git repository into <supermodule>/.git/modules, if this
folder does not already exist. git clone --separate-git-dir was
designed for a scenario where the git repository stays in one location
and the working copy can be moved. Therefore the .git file in the
working copy uses an absolute path to specify the location of the
repository.
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, which moves both the submodule's git repository and its
working copy. This means that the submodule's .git file no longer
points to its repository, causing the error.
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.
This patch uses the above mechanism to re-write the .git file after git
clone --separate-git-dir is run, replacing the absolute path with a
relative one.
An alternative patch would teach git-clone an option to control whether
an absolute or relative path is used when --separate-git-dir is passed.
Signed-off-by: Antony Male <antony.male@gmail.com>
---
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 3adab93..18eb5ff 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -159,7 +159,6 @@ 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"
@@ -171,6 +170,7 @@ module_clone()
fi ||
die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
fi
+ echo "gitdir: $rel_gitdir" >"$path/.git"
}
#
--
1.7.8
^ permalink raw reply related
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Junio C Hamano @ 2011-12-29 22:40 UTC (permalink / raw)
To: Antony Male; +Cc: git, iveqy
In-Reply-To: <1325192426-10103-1-git-send-email-antony.male@gmail.com>
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.
> folder does not already exist. git clone --separate-git-dir was
> designed for a scenario where the git repository stays in one location
> and the working copy can be moved.
Are you sure about this "clone's design"? It sounds like a revisionist
history.
Saying something like "it would be nicer if it also let us use in this new
different scenario" in the proposed commit log message is perfectly fine,
but my understanding is that the --separate-git-dir option and "gitdir: "
support were designed to allow having the $GIT_DIR in a different place
from the working tree that has ".git" in it, nothing more, nothing less. I
do not think we meant to support moving either directory after they are
set up. If you want to move either, you would need to (and you can, like
your patch does) tweak "gitdir:" to adjust.
By-the-way-Nit. We do not use any folders. s/folder/directory/.
> 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, 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
"<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.
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.
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>?
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"
}
#
^ permalink raw reply related
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Fredrik Gustafsson @ 2011-12-29 22:48 UTC (permalink / raw)
To: Antony Male; +Cc: git, gitster, Jens Lehmann, Heiko Voigt
In-Reply-To: <1325192426-10103-1-git-send-email-antony.male@gmail.com>
2011/12/29 Antony Male <antony.male@gmail.com>:
<snip>
> die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
> fi
> + echo "gitdir: $rel_gitdir" >"$path/.git"
This will replace an already created file. Is it really the best
solution to create a gitfile with an absolute path and after that
replace it with a relative path. Why not write the relative path from
the beginning?
The patch also breaks two tests:
t7406 and t5526.
Regards
Fredrik
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2011, #09; Tue, 27)
From: Junio C Hamano @ 2011-12-29 22:49 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8A=xg_c9xbNvZH19LamEBsKSOO_X-KP2-wFMAARbeq3Fw@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Wed, Dec 28, 2011 at 6:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * nd/index-pack-no-recurse (2011-12-27) 4 commits
>> - fixup! 3413d4d
>> - index-pack: eliminate unlimited recursion in get_delta_base()
>> - index-pack: eliminate recursion in find_unresolved_deltas
>> - Eliminate recursion in setting/clearing marks in commit list
>>
>> Expecting a reroll.
>
> Hmm.. I thought you could easily squash the fixup in. Any reasons for
> a reroll besides the fixup?
The parts that needed fix-ups are the only parts I read. I didn't see any
comments on the list from the reviewers, and I think it is because nobody
read to comment on a series that needs such a quick fix-ups to compile and
run.
^ permalink raw reply
* permissin of /usr/share/locale changed after make install
From: bill lam @ 2011-12-30 0:09 UTC (permalink / raw)
To: git
In recent git versions (git version 1.7.8.2.302.g17b4), I found that the
permission of /usr/share/locale was changed to drwxr-x--- after
"sudo make install" in my debian. I (non-root) use umask 027 if that matters.
Thanks!
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: git alias question
From: David Aguilar @ 2011-12-30 1:59 UTC (permalink / raw)
To: Dave Borowitz; +Cc: Michael Horowitz, git, Junio C Hamano
In-Reply-To: <CAD0k6qTp9sKCb==Jh1vuLuZoxx99Kt2Z=VAbjYbGaUE7nbOxdQ@mail.gmail.com>
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
* extended hook api and tweak-fetch hook
From: Joey Hess @ 2011-12-30 1:07 UTC (permalink / raw)
To: git
This patch series adds an extended hook API, and uses it to implement
the new tweak-fetch hook.
The remaining hooks (that do not already use run_hook()) could be
refactored later to use this new API.
Also, the API has been designed to allow several programs to be run
for a single hook, when someone wants to add that into git.
^ 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