* 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
* [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
* 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
* 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 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
* 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: 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
* 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: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: [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: 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: 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
* 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: 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
* 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: 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
* 'git describe' is very slow on development trees with lots of commits
From: Ingo Molnar @ 2012-10-27 13:33 UTC (permalink / raw)
To: David Ahern, git
Cc: Arnaldo Carvalho de Melo, linux-kernel, Andrew Vagin,
Borislav Petkov, David Howells, Frederic Weisbecker, Jiri Olsa,
Namhyung Kim, Paul Mackerras, Peter Zijlstra, Stephane Eranian,
Steven Rostedt, arnaldo.melo, Arnaldo Carvalho de Melo
In-Reply-To: <508AA709.7010202@gmail.com>
(Cc:-ed the Git development list.)
* David Ahern <dsahern@gmail.com> wrote:
> PERF-VERSION-GEN and specifically the git commands are the
> cause of more delay than the config checks, especially when
> doing the build in a VM with the kernel source on an NFS
> mount.
Yes, I have noticed that too.
So, the problem is that we use 'git describe' on the kernel tree
to generate the version string, which is very, very slow if we
are far away from any tagged release - which is the case for the
-tip tree:
comet:~/tip> perf stat --null --repeat 3 git describe
v3.7-rc2-2007-g83e8223
v3.7-rc2-2007-g83e8223
v3.7-rc2-2007-g83e8223
'git describe' is much faster if we are on or near to a tag:
$ git checkout v3.6
$ perf stat --null --repeat 3 git describe
v3.6
v3.6
v3.6
Performance counter stats for 'git describe' (3 runs):
0.020171640 seconds time elapsed ( +- 3.64% )
$ git checkout b34e5f55a1e6
$ perf stat --null --repeat 3 git describe
v3.6-41-gb34e5f5
v3.6-41-gb34e5f5
v3.6-41-gb34e5f5
Performance counter stats for 'git describe' (3 runs):
0.155603676 seconds time elapsed ( +- 0.23% )
The cost on this pretty fast machine is about 1 msecs per commit
- which adds up to about 2.5 seconds during much of the
development cycle.
So maybe we should be using a different version string, for
example, instead of:
v3.7-rc2-2007-g83e8223
this would be perfectly fine:
v3.7-rc2-g83e8223
the 'commit count' is informative but not essential - and in
counting the number of off-tag commits is where much of the
overhead is:
#
# Overhead Command Shared Object Symbol
# ........ ....... .................. ..........................................
#
39.79% git libz.so.1.2.5 [.] 0x000000000000c1fe
26.39% git libz.so.1.2.5 [.] inflate
22.42% git git [.] 0x000000000009bd1e
2.99% git libz.so.1.2.5 [.] adler32
1.23% git libc-2.15.so [.] _int_malloc
0.72% git libc-2.15.so [.] __GI_____strtoull_l_internal
0.67% git libc-2.15.so [.] _int_free
0.62% git libc-2.15.so [.] malloc_consolidate
0.54% git [kernel.kallsyms] [k] clear_page_c
0.32% git [kernel.kallsyms] [k] page_fault
So by switching to the shorter version string that still embedds
the tag and the exact sha1 we'd be able to run this script a
*lot* faster.
Thanks,
Ingo
^ permalink raw reply
* Re: git config error message
From: Angelo Borsotti @ 2012-10-27 14:50 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Ben Walton, git
In-Reply-To: <m2d3049hvs.fsf@igel.home>
Hi Andreas,
>
> Is grep not finding a match an error? Is cmp finding a difference an
> error? It all depends on the context.
>
Manpage of grep, exit staus:
"Normally, the exit status is 0 if selected lines are found and 1
otherwise. But the exit status is 2 if an error occurred, ..."
cmp uses the same convention (albeit not reported in its manpage).
I am not stating that all linux commands and utilities follow exactly
the same convention, but these
two are at least consistent with themselves always returning an exit
status that has a well defined meaning. git-config returns
consistently the exit status, it only issues in certain cases messages
and in others not. A consistent solution could be for it to return 0
upon success, 1 when the section or key is absent, and 2 when the
config file does not exist or is corrupt issuing also an error
message.
-Angelo
>> 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: git config error message
From: Andreas Schwab @ 2012-10-27 16:12 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: Ben Walton, git
In-Reply-To: <CAB9Jk9A-uXXXKCBKvxyDN6QQx1b0zqemg7UbeRMcWeY7gi4MRQ@mail.gmail.com>
Angelo Borsotti <angelo.borsotti@gmail.com> writes:
> when the section or key is absent
When the key is malformed you get an error, otherwise not.
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
* crash on git diff-tree -Ganything <tree> for new files with textconv filter
From: Peter Oberndorfer @ 2012-10-27 18:37 UTC (permalink / raw)
To: git, Junio C Hamano
Hi,
It seems "git diff-tree -Ganything <tree>" crashes[1] with a null
pointer dereference
when run on a commit that adds a file (pdf) with a textconv filter.
It can be reproduced with vanilla git by having a commit on top that
adds a file with a textconv filter and executing git diff-tree
-Ganything HEAD
But running git log -Ganything still works without a crash.
This problem seems to exist since the feature was first added in f506b8e8b5.
While testing I also noticed the -S and -G act on the original file
instead of the textconv munged data.
Is this intentional or caused by accessing the wrong data?
Wild guess: should we really access p->one->data and not mf1.ptr?
Is there some more information i should provide?
Greetings Peter
[1]
I am running msysgit v1.8.0.msysgit.0 (52d3a7583a)
and i tried added -G pickaxe support to gitk.
gitk runs git diff-tree -r -s --stdin -Gpattern
This is how i detected the crash the first time.
(but only because of a crash popup on Windows, gitk does not complain...)
For testing on vanilla git I used .git/config:
[diff "upcase2"]
textconv = tr a-z A-Z <
.gitatrributes:
newtext diff=upcase2
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 3864.0x83c]
0x0049d90c in regexec (preg=0x22f900, string=0x0, nmatch=1,
pmatch=0x22f46c, eflags=0) at compat/regex/regexec.c:241
241 length = strlen (string);
(gdb) bt
#0 0x0049d90c in regexec (preg=0x22f900, string=0x0, nmatch=1,
pmatch=0x22f46c, eflags=0) at compat/regex/regexec.c:241
#1 0x004f5763 in diff_grep (p=0x109a530, o=0x550b48, regexp=0x22f900,
kws=0x0) at diffcore-pickaxe.c:110
#2 0x004f59dc in pickaxe (o=<value optimized out>, regexp=0x22f900,
kws=0xffffffff, fn=0x4f5620 <diff_grep>) at diffcore-pickaxe.c:40
#3 0x004f5bd4 in diffcore_pickaxe_grep (o=0x550b48) at
diffcore-pickaxe.c:154
#4 0x0048049a in diffcore_std (options=0x550b48) at diff.c:4630
#5 0x004dc16a in log_tree_diff_flush (opt=0x5508c0) at log-tree.c:697
#6 0x004dc32e in log_tree_commit (opt=0x5508c0, commit=0xffc620) at
log-tree.c:790
#7 0x004206dd in cmd_diff_tree (argc=<value optimized out>,
argv=0x3d24bc, prefix=0x0) at builtin/diff-tree.c:43
#8 0x00401a16 in handle_internal_command (argc=<value optimized out>,
argv=<value optimized out>) at git.c:306
#9 0x00401c00 in main (argc=6, argv=0x3d24b8) at git.c:513
(gdb) up
#1 0x004f5763 in diff_grep (p=0x109a530, o=0x550b48, regexp=0x22f900,
kws=0x0) at diffcore-pickaxe.c:110
110 hit = !regexec(regexp, p->one->data, 1,
®match, 0);
(gdb) info locals
regmatch = {rm_so = 17408640, rm_eo = 2291968}
textconv_one = (struct userdiff_driver *) 0x0
textconv_two = (struct userdiff_driver *) 0xe10468
mf1 = {ptr = 0x0, size = 0}
mf2 = {
ptr = 0x2bbcaf0 ' ' <repeats 52 times>, "PROJECT
DESCRIPTION\r\n\r\n\r\nProject Number:", ' ' <repeats 19 times>,
"xxxxx\r\nProject Description:", ' ' <repeats 14 times>,
"xxxxxxxx\r\nxxxxx:", ' ' <repeats 11 times>..., size = 64185}
hit = <value optimized out>
(gdb) print p
$1 = (struct diff_filepair *) 0x109a530
(gdb) print *p
$2 = {one = 0x109a320, two = 0x109a428, score = 0, status = 0 '\0',
broken_pair = 0, renamed_pair = 0, is_unmerged = 0}
(gdb) print p->one
$3 = (struct diff_filespec *) 0x109a320
(gdb) print *p->one
$4 = {sha1 = '\0' <repeats 19 times>, path = 0x109a360
"xxxxxxxx/xxx/doc/xxxx xxxxx 1.4.pdf", data = 0x0, cnt_data = 0x0,
funcname_pattern_ident = 0x0, size = 0, count = 1, xfrm_flags = 0,
rename_used = 0, mode = 0, sha1_valid = 0, should_free = 0,
should_munmap = 0,
dirty_submodule = 0, is_stdin = 0, has_more_entries = 0, driver = 0x0,
is_binary = -1}
(gdb) print *p->two
$5 = {sha1 = "0aax\217\231)oBaAa(\021\234^'Q\236\230", path = 0x109a468
"xxxxxxxx/xxx/doc/xxxx xxxxx 1.4.pdf", data = 0x0,
cnt_data = 0x0, funcname_pattern_ident = 0x0, size = 0, count = 1,
xfrm_flags = 0, rename_used = 0, mode = 33188, sha1_valid = 1,
should_free = 0,
should_munmap = 0, dirty_submodule = 0, is_stdin = 0, has_more_entries
= 0, driver = 0xe10468, is_binary = -1}
(gdb) print textconv_one
$6 = (struct userdiff_driver *) 0x0
(gdb) print textconv_two
$7 = (struct userdiff_driver *) 0xe10468
(gdb) print *textconv_two
$10 = {name = 0xfe4fc0 "astextplain", external = 0x0, binary = -1,
funcname = {pattern = 0x0, cflags = 0}, word_regex = 0x0,
textconv = 0xfe4fd8 "astextplain", textconv_cache = 0x0,
textconv_want_cache = 0}
(gdb)
^ permalink raw reply
* Re: Workflow for templates?
From: Enrico Weigelt @ 2012-10-27 18:45 UTC (permalink / raw)
To: Josef Wolf; +Cc: git
In-Reply-To: <20121025211522.GA28437@raven.wolf.lan>
Hi,
<snip>
I'd suggest a 3 level branch hierachy (IOW: the lower level
is rebased ontop of the next higher level):
* #0: upstream branch
* #1: generic local maintenance branch
* #2: per-instance cutomization branches
Normal additions go to the lowest level #2. When you've got
some generic commit, you propagate it to the next level
(cherry-pick) and rebase layer #2 ontop of it.
Now you can send your layer #1 to upstream for integration.
When upstream updated his branch, you simply rebase #1
ontop of it, do your checks etc, then proceed to rebasing #3.
You could also introduce more intermediate layers (eg when you've
got different groups of similar instance that share certain changes)
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Re: [PATCH] Fix t9200 on case insensitive file systems
From: Ben Walton @ 2012-10-27 21:36 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git, bosch, brian, robin.rosenberg
In-Reply-To: <201210261818.25620.tboegi@web.de>
On Fri, Oct 26, 2012 at 5:18 PM, Torsten Bögershausen <tboegi@web.de> wrote:
> t/t9200-git-cvsexportcommit.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
> index b59be9a..69934b2 100755
> --- a/t/t9200-git-cvsexportcommit.sh
> +++ b/t/t9200-git-cvsexportcommit.sh
> @@ -19,7 +19,7 @@ then
> test_done
> fi
>
> -CVSROOT=$PWD/cvsroot
> +CVSROOT=$PWD/tmpcvsroot
FWIW, this looks obviously correct given the code snippet from the cvs
version you shared the other day.
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
* [PATCH] mailmap: avoid out-of-bounds memory access
From: Romain Francoise @ 2012-10-27 22:49 UTC (permalink / raw)
To: git; +Cc: gitster, peff
AddressSanitizer (http://clang.llvm.org/docs/AddressSanitizer.html)
complains of a one-byte buffer underflow in parse_name_and_email() while
running the test suite. And indeed, if one of the lines in the mailmap
begins with '<', we dereference the address just before the beginning of
the buffer when looking for whitespace to remove, before checking that
we aren't going too far.
So reverse the order of the tests to make sure that we don't read
outside the buffer.
Signed-off-by: Romain Francoise <romain@orebokech.com>
---
mailmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mailmap.c b/mailmap.c
index 47aa419..ea4b471 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -118,7 +118,7 @@ static char *parse_name_and_email(char *buffer, char **name,
while (isspace(*nstart) && nstart < left)
++nstart;
nend = left-1;
- while (isspace(*nend) && nend > nstart)
+ while (nend > nstart && isspace(*nend))
--nend;
*name = (nstart < nend ? nstart : NULL);
--
1.7.10.4
^ permalink raw reply related
* Re: Can't understand the behaviour of git-diff --submodule
From: Jens Lehmann @ 2012-10-27 23:02 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <CAC9WiBhZWJihPToMawPCxEVkTKL0e-GzUw3qneJMUx-WqSNbjw@mail.gmail.com>
Am 26.10.2012 22:43, schrieb Francis Moreau:
> 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, I suspect the --reference option makes the difference here,
I'll check that as soon as I find some time.
^ permalink raw reply
* [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-10-28 3:54 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Sverre Rabbelier, Johannes Schindelin,
Ilari Liusvaara, Daniel Barkalow, Jeff King, Michael J Gruber,
Felipe Contreras
Hi,
I've ported the tests from hg-git and made sure that the output from remote-hg
matches the output of hg-git. With these extensive tests I would consider this
one ready for wide use. Not only do the tests pass, I've compared the generated
repos of a few projects, and the SHA-1's are exactly the same :)
This remote-hg has advantages other tools don't have:
* Uses transport-helper (git clone hg::path)
* The code is small
* The code is simple
* No external dependencies (other than mercurial)
* It's easy to install (put into your path)
* Has extensive tests
* Active development
* Has compatibility with hg-git
* The required patches are available
* No changes necesary to git core
One important alternative is the one written by Sverre Rabbelier that is now
maintained and distributed in msysgit. It's hard to evaluate this option as
there isn't a branch specific to this remote helper so it would be possible to
evaluate the necessary patches.
Changes since v3:
* New extensive tests
* Add compatibility mode with hg-git
* Added support for boomkars
* Add mercurial information to the git msg (branch, renames, extra, etc.)
* Properly handle HEAD
* Fix author/committer information
* Implement 'done' feature for error handling
* Restore hg user properly
* Set file correct modes
* Match hg merge behavior
* Prefix hg branches
* Encoding fixes
* Stricter parser
* Support for 'reset' command
* Fix support for URL pushing (unaliased)
Changes since v2:
* Added support for pushing
* Tests copied from original remote-hg
* Custom default -> master renames removed
* Code reorganized
Changes since v1:
* Improved documentation
* Use more common 'python' binary
* Warn, don't barf when a branch has multiple heads
* Fixed marks to fetch after cloned
* Support for cloning/pulling remote repositories
* Use a more appropriate internal directory (e.g. .git/hg/origin)
* Fixes for python3
Felipe Contreras (13):
Add new remote-hg transport helper
remote-hg: add support for bookmarks
remote-hg: add support for pushing
remote-hg: add support for remote pushing
remote-hg: add support to push URLs
remote-hg: make sure the encoding is correct
remote-hg: match hg merge behavior
remote-hg: add support for hg-git compat mode
remote-hg: add compat for hg-git author fixes
remote-hg: fake bookmark when there's none
remote-hg: add support for fake remote
remote-hg: add tests to compare with hg-git
remote-hg: add extra author test
contrib/remote-hg/git-remote-hg | 770 ++++++++++++++++++++++++++++++++++++++++
t/t5802-remote-hg-hg-git.sh | 449 +++++++++++++++++++++++
2 files changed, 1219 insertions(+)
create mode 100755 contrib/remote-hg/git-remote-hg
create mode 100755 t/t5802-remote-hg-hg-git.sh
--
1.8.0
^ 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