* Re: Strange behaviour of git diff branch1 ... branch2
From: Nguyen Thai Ngoc Duy @ 2012-10-27 13:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Aaron Schrab
In-Reply-To: <4ecbe65e-4b56-4a49-96c3-1ea8b3f0c473@email.android.com>
On Sat, Oct 27, 2012 at 7:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>>
>>Notice the --cc in the first line, which is combined diff. Usually
>>combined-diff is between two points and one parent. Though somehow git
>>passes 4 parents down combined-diff.c:show_combined_header, as you can
>>see in the "index" line. I think we should fix rev parsing code as it
>>does not make sense to pass 4 identical parents this way.
>
> The two heads home from HEAD...HEAD the user has on the command line.
>
> The user is getting exactly what she asked; there is nothing to fix.
Is there any use case where HEAD...HEAD (or "..." alone) is actually useful?
I have re-read the git-diff man page and I don't think it explains
"git diff foo ... bar" syntax (from a user's point of view, not a git
guru's). We could improve the documentation if "git diff foo ... bar"
is useful, or reject it with an error to avoid confusion.
--
Duy
^ permalink raw reply
* Re: git config error message
From: Andreas Schwab @ 2012-10-27 13:14 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: Ben Walton, git
In-Reply-To: <CAB9Jk9COSZOske5xzgnE=1oHe7qiwwOzHYE6pJkuZ0sZyZYhng@mail.gmail.com>
Angelo Borsotti <angelo.borsotti@gmail.com> writes:
> Besides that, it is common practice in *nix OSs to
> consider a return != 0 as an error.
Is grep not finding a match an error? Is cmp finding a difference an
error? It all depends on the context.
> How can otherwise the user tell a corrupted configuration file from a
> missing key?
You cannot, as long as your configuration file is well-formed, because a
missing key is an expected condition in many cases.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Strange behaviour of git diff branch1 ... branch2
From: Junio C Hamano @ 2012-10-27 12:33 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy, git, Aaron Schrab
In-Reply-To: <CACsJy8CX4Wbf3Bqez2kcQ7NGYMkqXC8MK+=hrH4iaev+0ZrQ8Q@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>
>Notice the --cc in the first line, which is combined diff. Usually
>combined-diff is between two points and one parent. Though somehow git
>passes 4 parents down combined-diff.c:show_combined_header, as you can
>see in the "index" line. I think we should fix rev parsing code as it
>does not make sense to pass 4 identical parents this way.
The two heads home from HEAD...HEAD the user has on the command line.
The user is getting exactly what she asked; there is nothing to fix.
^ permalink raw reply
* Mistake in git-reset documentation
From: Bojan Petrović @ 2012-10-27 11:21 UTC (permalink / raw)
To: git
None of the three forms of git-reset accept: "git reset" which is the
equivalent of "git reset -mixed".
Square brackets should be used instead of parentheses for "--soft |
--mixed | --hard | --merge | --keep".
Bojan
^ permalink raw reply
* Re: git config error message
From: Angelo Borsotti @ 2012-10-27 10:36 UTC (permalink / raw)
To: Ben Walton; +Cc: Andreas Schwab, git
In-Reply-To: <CAP30j15pUwX9sD3FXAfroxFK9paHmb1eAg+M5YAHT4aB22DBEw@mail.gmail.com>
Hi Ben
> This still wouldn't be an error condition though, especially in terms
> of how "git config" should treat it.
The man page says:
"This command will fail with non-zero status upon error."
Of course, one might claim that this does not mean the truth of the
reverse condition, i.e. that when the command returns 1 that is
necessarily an error, but I would leave that avenue of thinking to
philosophers. Besides that, it is common practice in *nix OSs to
consider a return != 0 as an error.
> It should be up to the consumer
> of the information to display, or not, any error or diagnostics that
> don't result from either a bad request (your first case) or a
> malformed configuration file. This fits with the callback nature of
> how the config file is parsed by builtin tools. The exit code from
> "git config" with a missing key is enough for the consumer to make
> this decision.
>
A well-behaved, user-friendly program, when detects an error tells the
user what went wrong.
How can otherwise the user tell a corrupted configuration file from a
missing key?
Of course, is is possible to provide a git-config that simply returns
0 when it has got the key and 1 when it does not, without issuing any
error message, but the current one is not like that, it is a middle
way solution.
-Angelo
^ permalink raw reply
* Re: git config error message
From: Ben Walton @ 2012-10-27 8:45 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: Andreas Schwab, git
In-Reply-To: <CAB9Jk9CONVSZvBUgnZHiniwPHHvcap8Wyjyw-sCHaSokDoNRWA@mail.gmail.com>
On Sat, Oct 27, 2012 at 9:32 AM, Angelo Borsotti
<angelo.borsotti@gmail.com> wrote:
Hi Angelo,
> I wrote "value", but I meant "name". The first example I made contains
> a name with a nonexistent section, the second a name with a
> nonexistent key.
This still wouldn't be an error condition though, especially in terms
of how "git config" should treat it. It should be up to the consumer
of the information to display, or not, any error or diagnostics that
don't result from either a bad request (your first case) or a
malformed configuration file. This fits with the callback nature of
how the config file is parsed by builtin tools. The exit code from
"git config" with a missing key is enough for the consumer to make
this decision.
This is just my take on it, but I think the current approach makes sense.
Thanks
-Ben
--
---------------------------------------------------------------------------------------------------------------------------
Take the risk of thinking for yourself. Much more happiness,
truth, beauty and wisdom will come to you that way.
-Christopher Hitchens
---------------------------------------------------------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] mergetools/p4merge: Handle "/dev/null"
From: Jeremy Morton @ 2012-10-27 8:47 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git
In-Reply-To: <1349925756-87801-1-git-send-email-davvid@gmail.com>
Sorry to be replying to this so late; I hadn't noticed the post until now!
I've tried putting that code in my p4merge script and yes it does indeed
work fine. However, it puts a temporary file in the working directory
which I'm not sure is a good idea? If we look at this patch which
actually solved pretty much the same problem, but when merging and,
during a merge conflict, a file was created in both branches:
https://github.com/git/git/commit/ec245ba
... it is creating a temp file in a proper temp dir, rather than in the
working dir. I think that would be the proper solution here. However,
I really want to get this fixed so I'd be happy for this band-aid fix of
the p4merge script to be checked in until we could get a patch more like
the aforementioned one, at a later date, to create empty files in a
proper temp dir and pass them as $LOCAL and $REMOTE. :-)
--
Best regards,
Jeremy Morton (Jez)
On 11/10/2012 04:22, David Aguilar wrote:
> p4merge does not properly handle the case where "/dev/null"
> is passed as a filename.
>
> Workaround it by creating a temporary file for this purpose.
>
> Reported-by: Jeremy Morton<admin@game-point.net>
> Signed-off-by: David Aguilar<davvid@gmail.com>
> ---
> Jeremy, can you test this?
>
> mergetools/p4merge | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/mergetools/p4merge b/mergetools/p4merge
> index 1a45c1b..295361a 100644
> --- a/mergetools/p4merge
> +++ b/mergetools/p4merge
> @@ -1,5 +1,30 @@
> diff_cmd () {
> + # p4merge does not like /dev/null
> + rm_local=
> + rm_remote=
> + if test "/dev/null" = "$LOCAL"
> + then
> + LOCAL="./p4merge-dev-null.LOCAL.$$"
> + >"$LOCAL"
> + rm_local=true
> + fi
> + if test "/dev/null" = "$REMOTE"
> + then
> + REMOTE="./p4merge-dev-null.REMOTE.$$"
> + >"$REMOTE"
> + rm_remote=true
> + fi
> +
> "$merge_tool_path" "$LOCAL" "$REMOTE"
> +
> + if test -n "$rm_local"
> + then
> + rm -f "$LOCAL"
> + fi
> + if test -n "$rm_remote"
> + then
> + rm -f "$REMOTE"
> + fi
> }
>
> merge_cmd () {
^ permalink raw reply
* Re: git config error message
From: Andreas Schwab @ 2012-10-27 8:44 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9CONVSZvBUgnZHiniwPHHvcap8Wyjyw-sCHaSokDoNRWA@mail.gmail.com>
Angelo Borsotti <angelo.borsotti@gmail.com> writes:
> I wrote "value", but I meant "name". The first example I made contains
> a name with a nonexistent section, the second a name with a
> nonexistent key.
And a nonexistent key is a valid key, so not an error.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: git config error message
From: Angelo Borsotti @ 2012-10-27 8:32 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git
In-Reply-To: <m2bofo9v93.fsf@linux-m68k.org>
Hi Andreas,
I wrote "value", but I meant "name". The first example I made contains
a name with a nonexistent section, the second a name with a
nonexistent key.
-Angelo
^ permalink raw reply
* Re: git config error message
From: Andreas Schwab @ 2012-10-27 8:25 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9AQkSiv=F8NeYs+uspR5f4CeJS5L-hwZUXdq7dts1W5ng@mail.gmail.com>
Angelo Borsotti <angelo.borsotti@gmail.com> writes:
> git config --get issues an error message when the specified value
> contains a section that does not exist, but does not issue any message
> when the value contains a key that does not exist while in both cases
> returning a status 1. E.g.
>
> $ git config --get xxx
> error: key does not contain a section: xxx
>
> $ git config --get xxx.yyy
>
> Proposal: to issue an error message also when the key does not exist.
The two cases are different: a key without a section is malformed,
whereas a nonexistent value is usually not an error (use the default
instead).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* git config error message
From: Angelo Borsotti @ 2012-10-27 8:10 UTC (permalink / raw)
To: git
Hello,
git config --get issues an error message when the specified value
contains a section that does not exist, but does not issue any message
when the value contains a key that does not exist while in both cases
returning a status 1. E.g.
$ git config --get xxx
error: key does not contain a section: xxx
$ git config --get xxx.yyy
Proposal: to issue an error message also when the key does not exist.
-Angelo Borsotti
^ permalink raw reply
* Re: Strange behaviour of git diff branch1 ... branch2
From: Nguyen Thai Ngoc Duy @ 2012-10-27 3:51 UTC (permalink / raw)
To: git, Aaron Schrab
In-Reply-To: <20121026212650.GB2612@pug.qqx.org>
On Sat, Oct 27, 2012 at 4:26 AM, Aaron Schrab <aaron@schrab.com> wrote:
> I came across this odd question on stackoverflow:
> http://stackoverflow.com/q/13092854/1507392
>
>
> If git diff is run with "..." as a separate argument between two commit-ish
> arguments causes it to produce strange output. The differences seem to be
> the same as if "..." was left out, but change lines begin with 4 + or -
> characters rather than just 1.
>
> Can anybody explain what is happening here? I don't have any reason to want
> to use that form myself, but I'm very curious about why it produces this odd
> output.
I'm curious too. It shows this to me
diff --cc .gitignore
index a188a82,a188a82,a188a82,a188a82..d4473d8
--- a/.gitignore
+++ b/.gitignore
@@@@@ -2,9 -2,9 -2,9 -2,9 +2,6 @@@@@
/GIT-CFLAGS
/GIT-LDFLAGS
/GIT-GUI-VARS
----/GIT-PREFIX
----/GIT-SCRIPT-DEFINES
----/GIT-USER-AGENT
/GIT-VERSION-FILE
/bin-wrappers/
/git
Notice the --cc in the first line, which is combined diff. Usually
combined-diff is between two points and one parent. Though somehow git
passes 4 parents down combined-diff.c:show_combined_header, as you can
see in the "index" line. I think we should fix rev parsing code as it
does not make sense to pass 4 identical parents this way.
--
Duy
^ permalink raw reply
* Bizarre problem cloning repo from Codeplex
From: Jeremy Morton @ 2012-10-26 22:48 UTC (permalink / raw)
To: git
I'm trying to clone the following repository from Codeplex:
https://git01.codeplex.com/entityframework.git
git downloads all the objects, creates the directory "entityframework",
then displays "error: RPC failed; result=56, HTTP code = 200" and
immediately deletes the directory.
I can clone other HTTPS repos with this git installation, for example
from Bitbucket and Github. It's git 1.7.10.4 on Debian. I can also
clone this codeplex repo OK on my windows git installation
(1.7.11.msysgit.1). I'm totally perplexed; anyone have any idea what is
going wrong with the Debian git installation here?
--
Best regards,
Jeremy Morton (Jez)
^ permalink raw reply
* Re: strange problems applying --no-prefix patch with -p0 and added files
From: Sergey Shelukhin @ 2012-10-26 22:14 UTC (permalink / raw)
To: git
In-Reply-To: <CAHXxaiCELHomSPQoZWw+SdV61Y0gVb9MEdRv-gCOfkJG50xCeQ@mail.gmail.com>
Hi. Any pointers? Is there some bug tracking system to file a bug to?
Thanks.
On Wed, Oct 24, 2012 at 1:54 PM, Sergey Shelukhin
<sergey@hortonworks.com> wrote:
> Hello.
> I am trying to apply a patch made via {git diff somehash^ somehash >
> ....} before (same version of Git, same machine). I have no-prefix
> enabled by default.
> If I try to apply the patch with -p0, it fails.
> If I go to a directory where all the changed files are ("src/" below)
> to "simulate" the prefix for -p1, it silently does nothing.
> Only if I make it a -p1 patch, it actually tries to do apply (and
> applies the new files that cause problems in -p0 alright too, if used
> with --reject).
>
> I am relatively new to git, so while researching I realized I might be
> using wrong ways to do things (e.g. not using cherry-pick), but this
> seems like a bug regardless.
>
> Here's the log of my interactions with git:
>
> reznor-mbp:git-hbase-089 sergey$ git version
> git version 1.7.10.2 (Apple Git-33)
> reznor-mbp:git-hbase-089 sergey$ git status
> # On branch 0.94
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # HBASE-6371.patch
> nothing added to commit but untracked files present (use "git add" to track)
> reznor-mbp:git-hbase-089 sergey$ git apply -p0 HBASE-6371.patch
> fatal: git apply: bad git-diff - inconsistent new filename on line 128
> reznor-mbp:git-hbase-089 sergey$ sed -n 125,129p HBASE-6371.patch
> diff --git src/main/java/org/apache/
> hadoop/hbase/regionserver/CompactSelection.java
> src/main/java/org/apache/hadoop/hbase/regionserver/CompactSelection.java
> new file mode 100644
> index 0000000..a9ee0d4
> --- /dev/null
> +++ src/main/java/org/apache/hadoop/hbase/regionserver/CompactSelection.java
> reznor-mbp:git-hbase-089 sergey$ cd src
> reznor-mbp:src sergey$ git apply -p1 -v --whitespace=nowarn ../HBASE-6371.patch
> [ there's nothing here, e.g. no output ]
> reznor-mbp:src sergey$ git status
> # On branch 0.94
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # ../HBASE-6371.patch
> nothing added to commit but untracked files present (use "git add" to track)
> reznor-mbp:src sergey$ cd ..
> reznor-mbp:git-hbase-089 sergey$ sed -E "s/(--git|---) src/\1 a\/src/"
> HBASE-6371.patch | sed -E "s/ src\// b\/src\//" >
> HBASE-6371-prefix.patch
> reznor-mbp:git-hbase-089 sergey$ git apply HBASE-6371-prefix.patch
> HBASE-6371-prefix.patch:169: trailing whitespace.
> ...
> error: patch failed:
> src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java:64
> error: src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java:
> patch does not apply
> ....
^ permalink raw reply
* [PATCH] gitk: Do not select file list entries during diff loading
From: Peter Oberndorfer @ 2012-10-26 22:03 UTC (permalink / raw)
To: git; +Cc: Stefan Haller, Paul Mackerras
In-Reply-To: <1348078647-22516-1-git-send-email-stefan@haller-berlin.de>
Scrolling notification works by callingscrolltext{}
with with 2 values between 0 and 1
for the beginning and the end of the view relative to the total length.
When a long diff with several files is loaded,
the diff view length is updated several times
and causes executions of scrolltext{} even when
the current view never changed.
Every time scrolltext{} is executed,
a entry in the file list is selected and scrolled to.
This makes it impossible for a user to scroll the file list
while a long diff is still loading.
Signed-off-by: Peter Oberndorfer <kumbayo84@arcor.de>
---
Hi,
i used v3 of the Synchronize patch (+ the 2 fixes on top)
for some time now on mingw,
but i found a slight problem for my usage.
While the diff is loaded, the file list on the right side always scrolls up.
When a single revision touches hundreds of files [1] the loading takes
quite long.
During the diff loading i want to scroll down in the file list to the
relevant file i
am interested in. But the file list jumps up all the time.
Please review/test the patch carefully before applying,
since i do not often work with tcl/tk :-)
(Or suggest better ways to solve this problem)
Greetings Peter
[1] I imported history of a historic project. Each release is represented
by a single commit. Thus one commit contains a lot of files/big amount
of changes.
But most times i am interested in only a single file in the middle of
the file list.
gitk-git/gitk | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index b294c9e..621db87 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -8004,7 +8004,7 @@ proc nextfile {} {
proc clear_ctext {{first 1.0}} {
global ctext smarktop smarkbot
- global ctext_file_names ctext_file_lines
+ global ctext_file_names ctext_file_lines ctext_last_scroll_pos
global pendinglinks
set l [lindex [split $first .] 0]
@@ -8020,6 +8020,7 @@ proc clear_ctext {{first 1.0}} {
}
set ctext_file_names {}
set ctext_file_lines {}
+ set ctext_last_scroll_pos -1
}
proc settabs {{firstab {}}} {
@@ -8162,21 +8163,24 @@ proc
suppress_highlighting_file_for_current_scrollpos {} {
}
proc scrolltext {f0 f1} {
- global searchstring cmitmode ctext
+ global searchstring cmitmode ctext ctext_last_scroll_pos
global suppress_highlighting_file_for_this_scrollpos
+ .bleft.bottom.sb set $f0 $f1
+ if {$searchstring ne {}} {
+ searchmarkvisible 0
+ }
+
set topidx [$ctext index @0,0]
+ if {$topidx eq $ctext_last_scroll_pos} return
+ set ctext_last_scroll_pos $topidx
+
if {![info exists suppress_highlighting_file_for_this_scrollpos]
|| $topidx ne $suppress_highlighting_file_for_this_scrollpos} {
highlightfile_for_scrollpos $topidx
}
catch {unset suppress_highlighting_file_for_this_scrollpos}
-
- .bleft.bottom.sb set $f0 $f1
- if {$searchstring ne {}} {
- searchmarkvisible 0
- }
}
proc setcoords {} {
@@ -11643,6 +11647,7 @@ set autoselect 1
set autosellen 40
set perfile_attrs 0
set want_ttk 1
+set ctext_last_scroll_pos -1
if {[tk windowingsystem] eq "aqua"} {
set extdifftool "opendiff"
--
1.8.0.rc2.251.g3315d86
^ permalink raw reply related
* Strange behaviour of git diff branch1 ... branch2
From: Aaron Schrab @ 2012-10-26 21:26 UTC (permalink / raw)
To: git
I came across this odd question on stackoverflow:
http://stackoverflow.com/q/13092854/1507392
If git diff is run with "..." as a separate argument between two
commit-ish arguments causes it to produce strange output. The
differences seem to be the same as if "..." was left out, but change
lines begin with 4 + or - characters rather than just 1.
Can anybody explain what is happening here? I don't have any reason to
want to use that form myself, but I'm very curious about why it produces
this odd output.
Thanks.
^ permalink raw reply
* Re: Can't understand the behaviour of git-diff --submodule
From: Francis Moreau @ 2012-10-26 20:43 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <508AED26.3090805@web.de>
On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
[...]
>
> That is weird, "git diff --submodule" should show that too. Is there
> anything unusual about your setup? (The only explanation I can come
> up with after checking the code is that your submodule has neither a
> .git directory nor a gitfile or the objects directory in there doesn't
> contain these commits)
Oh now you're asking, I think the submodule has been added by using
the --reference option of git-submodule-add.
$ cd configs
$ cat .git
gitdir: ../.git/modules/configs
Thanks
--
Francis
^ permalink raw reply
* Re: Can't understand the behaviour of git-diff --submodule
From: Jens Lehmann @ 2012-10-26 20:05 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <CAC9WiBjiHLJggUzmmx4sPpXNNq=Kz0TOZAzmRShc1AZcPjGvig@mail.gmail.com>
Am 26.10.2012 21:54, schrieb Francis Moreau:
> On Fri, Oct 26, 2012 at 9:08 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Am 26.10.2012 16:07, schrieb Francis Moreau:
>>> I'm trying to use the --submodule switch with git-diff but doesnt
>>> understand the following behaviour:
>>>
>>> $ git diff 2c9a257718d1803de720f95766ff256d33accad5 HEAD
>>> diff --git a/configs b/configs
>>> index 16c6a89..ce12289 160000
>>> --- a/configs
>>> +++ b/configs
>>> @@ -1 +1 @@
>>> -Subproject commit 16c6a89f245f0eed7fb0bce8e027c59fcf1d543e
>>> +Subproject commit ce12289c5bfca7b2c423d9f1871c13ad1ba1dc32
>>>
>>> but adding the --submodule option gives:
>>>
>>> $ git diff --submodule=log 2c9a257718d1803de720f95766ff256d33accad5 HEAD
>>> Submodule configs 16c6a89...ce12289 (commits not present)
>>>
>>> Could anybody enlight me ?
>>
>> The output "Submodule configs 16c6a89...ce12289 (commits not present)"
>> contains same SHA-1s, only in their abbreviated form. That is the same
>> information you get without the --submodule option, but in shorter
>> format: it says the submodule moved from 16c6a89 to ce12289 in the
>> given commit range of the superproject (and the "..." part tells us it
>> wasn't a fast-forward). The "(commits not present)" part indicates that
>> even though git diff would have wanted to show you what happened in the
>> submodule between 16c6a89 and ce12289 by displaying the first line of
>> each commit message, it couldn't because these commit(s) are not present
>> in the submodule repo. If you do a "git log --oneline 16c6a89...ce12289"
>> inside the submodule you'll get an "unknown revision" error for the same
>> reason.
>
> Well, no the commits are present in the submodule, that's what I tried
> to show with the first 'git-diff' command I did in my previous post
> (without the --submodule switch).
Oh, that only shows the commits of the submodule recorded in the
superproject and not that they are present there (you'll even get
that output when the submodule was never initialized and is empty).
> And to check again, this is the result of git log:
>
> $ cd configs
> $ git log --oneline 16c6a89...ce12289
> ce12289 test 2
>
> [...]
That is weird, "git diff --submodule" should show that too. Is there
anything unusual about your setup? (The only explanation I can come
up with after checking the code is that your submodule has neither a
.git directory nor a gitfile or the objects directory in there doesn't
contain these commits)
^ permalink raw reply
* Re: git submodule summary doesn't return an error when passed a wrong commit/rev
From: Francis Moreau @ 2012-10-26 19:56 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <508AEA39.2020205@web.de>
On Fri, Oct 26, 2012 at 9:53 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 26.10.2012 16:03, schrieb Francis Moreau:
>> it seems to me that when passed an unknown rev or a wrong commit/sha1,
>> git-submodule-summary should at least exit with an error status. Even better
>> would be a error output.
>>
>> Test was done with git version 1.7.10.4 from debian wheezy.
>
> Thanks for your report, I think you found a real issue. Some quick
> tests showed some problems with other parameter combinations too.
> I'll take a deeper look the next days.
Glad to help :)
--
Francis
^ permalink raw reply
* Re: Can't understand the behaviour of git-diff --submodule
From: Francis Moreau @ 2012-10-26 19:54 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <508ADFAE.1050800@web.de>
Hi,
Thanks for answering
On Fri, Oct 26, 2012 at 9:08 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 26.10.2012 16:07, schrieb Francis Moreau:
>> I'm trying to use the --submodule switch with git-diff but doesnt
>> understand the following behaviour:
>>
>> $ git diff 2c9a257718d1803de720f95766ff256d33accad5 HEAD
>> diff --git a/configs b/configs
>> index 16c6a89..ce12289 160000
>> --- a/configs
>> +++ b/configs
>> @@ -1 +1 @@
>> -Subproject commit 16c6a89f245f0eed7fb0bce8e027c59fcf1d543e
>> +Subproject commit ce12289c5bfca7b2c423d9f1871c13ad1ba1dc32
>>
>> but adding the --submodule option gives:
>>
>> $ git diff --submodule=log 2c9a257718d1803de720f95766ff256d33accad5 HEAD
>> Submodule configs 16c6a89...ce12289 (commits not present)
>>
>> Could anybody enlight me ?
>
> The output "Submodule configs 16c6a89...ce12289 (commits not present)"
> contains same SHA-1s, only in their abbreviated form. That is the same
> information you get without the --submodule option, but in shorter
> format: it says the submodule moved from 16c6a89 to ce12289 in the
> given commit range of the superproject (and the "..." part tells us it
> wasn't a fast-forward). The "(commits not present)" part indicates that
> even though git diff would have wanted to show you what happened in the
> submodule between 16c6a89 and ce12289 by displaying the first line of
> each commit message, it couldn't because these commit(s) are not present
> in the submodule repo. If you do a "git log --oneline 16c6a89...ce12289"
> inside the submodule you'll get an "unknown revision" error for the same
> reason.
Well, no the commits are present in the submodule, that's what I tried
to show with the first 'git-diff' command I did in my previous post
(without the --submodule switch).
And to check again, this is the result of git log:
$ cd configs
$ git log --oneline 16c6a89...ce12289
ce12289 test 2
[...]
> Does that make it clearer?
Unforunately not really.
Thanks.
--
Francis
^ permalink raw reply
* Re: git submodule summary doesn't return an error when passed a wrong commit/rev
From: Jens Lehmann @ 2012-10-26 19:53 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <CAC9WiBgdgy1bwh0c16jd017q2rqQAq-suDADn2-vGw9eubBs_w@mail.gmail.com>
Am 26.10.2012 16:03, schrieb Francis Moreau:
> it seems to me that when passed an unknown rev or a wrong commit/sha1,
> git-submodule-summary should at least exit with an error status. Even better
> would be a error output.
>
> Test was done with git version 1.7.10.4 from debian wheezy.
Thanks for your report, I think you found a real issue. Some quick
tests showed some problems with other parameter combinations too.
I'll take a deeper look the next days.
^ permalink raw reply
* [PATCHv3 2/2] Add tests for submodule sync --recursive
From: Phil Hord @ 2012-10-26 19:44 UTC (permalink / raw)
To: git; +Cc: phil.hord, Jens Lehmann, Jeff King, Phil Hord
In-Reply-To: <1351280683-8402-1-git-send-email-hordp@cisco.com>
Signed-off-by: Phil Hord <hordp@cisco.com>
---
t/t7403-submodule-sync.sh | 55 +++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh
index 524d5c1..94e26c4 100755
--- a/t/t7403-submodule-sync.sh
+++ b/t/t7403-submodule-sync.sh
@@ -17,18 +17,25 @@ test_expect_success setup '
git commit -m upstream &&
git clone . super &&
git clone super submodule &&
+ (cd submodule &&
+ git submodule add ../submodule sub-submodule &&
+ test_tick &&
+ git commit -m "sub-submodule"
+ ) &&
(cd super &&
git submodule add ../submodule submodule &&
test_tick &&
git commit -m "submodule"
) &&
git clone super super-clone &&
- (cd super-clone && git submodule update --init) &&
+ (cd super-clone && git submodule update --init --recursive) &&
git clone super empty-clone &&
(cd empty-clone && git submodule init) &&
git clone super top-only-clone &&
git clone super relative-clone &&
- (cd relative-clone && git submodule update --init)
+ (cd relative-clone && git submodule update --init --recursive) &&
+ git clone super recursive-clone &&
+ (cd recursive-clone && git submodule update --init --recursive)
'
test_expect_success 'change submodule' '
@@ -46,6 +53,11 @@ test_expect_success 'change submodule url' '
git pull
) &&
mv submodule moved-submodule &&
+ (cd moved-submodule &&
+ git config -f .gitmodules submodule.sub-submodule.url ../moved-submodule &&
+ test_tick &&
+ git commit -a -m moved-sub-submodule
+ ) &&
(cd super &&
git config -f .gitmodules submodule.submodule.url ../moved-submodule &&
test_tick &&
@@ -61,6 +73,9 @@ test_expect_success '"git submodule sync" should update submodule URLs' '
test -d "$(cd super-clone/submodule &&
git config remote.origin.url
)" &&
+ test ! -d "$(cd super-clone/submodule/sub-submodule &&
+ git config remote.origin.url
+ )" &&
(cd super-clone/submodule &&
git checkout master &&
git pull
@@ -70,6 +85,25 @@ test_expect_success '"git submodule sync" should update submodule URLs' '
)
'
+test_expect_success '"git submodule sync --recursive" should update all submodule URLs' '
+ (cd super-clone &&
+ (cd submodule &&
+ git pull --no-recurse-submodules
+ ) &&
+ git submodule sync --recursive
+ ) &&
+ test -d "$(cd super-clone/submodule &&
+ git config remote.origin.url
+ )" &&
+ test -d "$(cd super-clone/submodule/sub-submodule &&
+ git config remote.origin.url
+ )" &&
+ (cd super-clone/submodule/sub-submodule &&
+ git checkout master &&
+ git pull
+ )
+'
+
test_expect_success '"git submodule sync" should update known submodule URLs' '
(cd empty-clone &&
git pull &&
@@ -107,6 +141,23 @@ test_expect_success '"git submodule sync" handles origin URL of the form foo/bar
#actual foo/submodule
test "$(git config remote.origin.url)" = "../foo/submodule"
)
+ (cd submodule/sub-submodule &&
+ test "$(git config remote.origin.url)" != "../../foo/submodule"
+ )
+ )
+'
+
+test_expect_success '"git submodule sync --recursive" propagates changes in origin' '
+ (cd recursive-clone &&
+ git remote set-url origin foo/bar &&
+ git submodule sync --recursive &&
+ (cd submodule &&
+ #actual foo/submodule
+ test "$(git config remote.origin.url)" = "../foo/submodule"
+ )
+ (cd submodule/sub-submodule &&
+ test "$(git config remote.origin.url)" = "../../foo/submodule"
+ )
)
'
--
1.8.0.3.g9dae067
^ permalink raw reply related
* [PATCHv3 1/2] Teach --recursive to submodule sync
From: Phil Hord @ 2012-10-26 19:44 UTC (permalink / raw)
To: git; +Cc: phil.hord, Jens Lehmann, Jeff King, Phil Hord
In-Reply-To: <1351280683-8402-1-git-send-email-hordp@cisco.com>
The submodule sync command was somehow left out when
--recursive was added to the other submodule commands.
Teach sync to handle the --recursive switch by recursing
when we're in a submodule we are sync'ing.
Change the report during sync to show submodule-path
instead of submodule-name to be consistent with the other
submodule commands and to help recursed paths make sense.
Signed-off-by: Phil Hord <hordp@cisco.com>
---
git-submodule.sh | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..0ca3af2 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -11,7 +11,7 @@ USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <r
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: $dashless [--quiet] foreach [--recursive] <command>
- or: $dashless [--quiet] sync [--] [<path>...]"
+ or: $dashless [--quiet] sync [--recursive] [--] [<path>...]"
OPTIONS_SPEC=
. git-sh-setup
. git-sh-i18n
@@ -1010,6 +1010,10 @@ cmd_sync()
GIT_QUIET=1
shift
;;
+ --recursive)
+ recursive=1
+ shift
+ ;;
--)
shift
break
@@ -1051,7 +1055,7 @@ cmd_sync()
if git config "submodule.$name.url" >/dev/null 2>/dev/null
then
- say "$(eval_gettext "Synchronizing submodule url for '\$name'")"
+ say "$(eval_gettext "Synchronizing submodule url for '\$prefix\$sm_path'")"
git config submodule."$name".url "$super_config_url"
if test -e "$sm_path"/.git
@@ -1061,6 +1065,12 @@ cmd_sync()
cd "$sm_path"
remote=$(get_default_remote)
git config remote."$remote".url "$sub_origin_url"
+
+ if test -n "$recursive"
+ then
+ prefix="$prefix$sm_path/"
+ eval cmd_sync
+ fi
)
fi
fi
--
1.8.0.3.g9dae067
^ permalink raw reply related
* [PATCHv3 0/2] Teach --recursive to submodule sync
From: Phil Hord @ 2012-10-26 19:44 UTC (permalink / raw)
To: git; +Cc: phil.hord, Jens Lehmann, Jeff King
In-Reply-To: <508AE3E9.6000304@web.de>
[PATCHv3 1/2] Teach --recursive to submodule sync
Now with less noise and no redundant flags passed to the recursive call.
[PATCHv3 2/2] Add tests for submodule sync --recursive
The test remains unchanged.
^ permalink raw reply
* Re: [PATCH] t7407: Fix recursive submodule test
From: Jens Lehmann @ 2012-10-26 19:29 UTC (permalink / raw)
To: Phil Hord; +Cc: Git Mailing List, phil.hord, Jeff King
In-Reply-To: <1351278834-28867-1-git-send-email-hordp@cisco.com>
Am 26.10.2012 21:13, schrieb Phil Hord:
> A test in t7404-submodule-foreach purports to test that
> the --cached flag is properly noticed by --recursive calls
> to the foreach command as it descends into nested
> submodules. However, the test really does not perform this
> test since the change it looks for is in a top-level
> submodule handled by the first invocation of the command.
> To properly test for the flag being passed to recursive
> invocations, the change must be buried deeper in the
> hierarchy.
>
> Move the change one level deeper so it properly verifies
> the recursive machinery of the 'git submodule status'
> command.
Me thinks we should definitely do this.
> Signed-off-by: Phil Hord <hordp@cisco.com>
> ---
> t/t7407-submodule-foreach.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
> index 9b69fe2..107b4b7 100755
> --- a/t/t7407-submodule-foreach.sh
> +++ b/t/t7407-submodule-foreach.sh
> @@ -226,14 +226,14 @@ test_expect_success 'test "status --recursive"' '
> test_cmp expect actual
> '
>
> -sed -e "/nested1 /s/.*/+$nested1sha1 nested1 (file2~1)/;/sub[1-3]/d" < expect > expect2
> +sed -e "/nested2 /s/.*/+$nested2sha1 nested1\/nested2 (file2~1)/;/sub[1-3]/d" < expect > expect2
> mv -f expect2 expect
>
> test_expect_success 'ensure "status --cached --recursive" preserves the --cached flag' '
> (
> cd clone3 &&
> (
> - cd nested1 &&
> + cd nested1/nested2 &&
> test_commit file2
> ) &&
> git submodule status --cached --recursive -- nested1 > ../actual
>
^ 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