* [StGIT PATCH 4/4] Port stg-whatchanged improvements to stg-mdiff and have the former use the latter.
From: Yann Dirson @ 2007-07-24 18:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070724185535.17180.24577.stgit@gandelf.nowhere.earth>
From: Yann Dirson <yann.dirson@sagem.com>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-mdiff | 2 ++
contrib/stg-whatchanged | 10 ++++------
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/contrib/stg-mdiff b/contrib/stg-mdiff
index 61cba9e..74d7f77 100755
--- a/contrib/stg-mdiff
+++ b/contrib/stg-mdiff
@@ -46,4 +46,6 @@ case "$2" in
esac
colordiff $diffopts \
+ -I '^index [0-9a-b]*..[0-9a-b]*' \
+ -I '^@@ .* @@' \
<($cmd1 "$1") <($cmd2 "$2") | less -RFX
diff --git a/contrib/stg-whatchanged b/contrib/stg-whatchanged
index 231f4f5..afeda2c 100755
--- a/contrib/stg-whatchanged
+++ b/contrib/stg-whatchanged
@@ -25,11 +25,9 @@ fi
# in this case (unlike, eg., "pick --fold")
patchdir="$(git-rev-parse --git-dir)/patches/$(stg branch)/patches/$(stg top)"
case $(stg log | head -n1) in
- *push\(c\)*) current_cmd="stg show //top.old" ;;
- *) current_cmd="stg show" ;;
+ *push\(c\)*) former="//top.old" ;;
+ *) former="//top" ;;
esac
-colordiff "$@" \
- -I '^index [0-9a-b]*..[0-9a-b]*' \
- -I '^@@ .* @@' \
- <($current_cmd) <(stg diff -r//bottom) | less -RFX
+stg-mdiff -o "$*" \
+ $former //bottom..
^ permalink raw reply related
* [StGIT PATCH 3/4] Add to stg-mdiff the ability to pass options to underlying diff opts.
From: Yann Dirson @ 2007-07-24 18:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070724185535.17180.24577.stgit@gandelf.nowhere.earth>
From: Yann Dirson <yann.dirson@sagem.com>
So we now have -O, similar to the existing option in stg diff, to pass
flags to git-diff when computing the 2 diffs to compare (-M, -C and -w
come to mind as being potentially useful here), and -o can be used to
tune the invocation of diff on those 2 diffs.
Note that -o is only there temporarily, and will disappear when a more
sophisticated process than plain diff will be used.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-mdiff | 29 +++++++++++++++++++++++------
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/contrib/stg-mdiff b/contrib/stg-mdiff
index 9bb324a..61cba9e 100755
--- a/contrib/stg-mdiff
+++ b/contrib/stg-mdiff
@@ -12,21 +12,38 @@ set -e
usage()
{
- echo "Usage: $(basename $0) <from1>..[<to1>]|<patch1> <from2>..[<to2>]|<patch2>"
+ echo "Usage: [-o <diff-flags>] [-O <gitdiff-flags>] $(basename $0) <from1>..[<to1>]|<patch1> <from2>..[<to2>]|<patch2>"
exit 1
}
+diffopts=
+subdiffopts=
+while [ "$#" -gt 0 ]; do
+ case "$1" in
+ -o) diffopts="$2"; shift ;;
+ -O) subdiffopts="-O $2"; shift ;;
+ -*) usage ;;
+ *) break ;;
+ esac
+ shift
+done
+
if [ "$#" != 2 ]; then
usage
fi
+if [ -z "$diffopts" ]; then
+ diffopts="-u"
+fi
+
case "$1" in
-*..*) cmd1="stg diff" ;;
-*) cmd1="stg show" ;;
+*..*) cmd1="stg diff $subdiffopts -r" ;;
+*) cmd1="stg show $subdiffopts" ;;
esac
case "$2" in
-*..*) cmd2="stg diff" ;;
-*) cmd2="stg show" ;;
+*..*) cmd2="stg diff $subdiffopts -r" ;;
+*) cmd2="stg show $subdiffopts" ;;
esac
-colordiff -u <($cmd1 "$1") <($cmd2 "$2") | less -RFX
+colordiff $diffopts \
+ <($cmd1 "$1") <($cmd2 "$2") | less -RFX
^ permalink raw reply related
* [StGIT PATCH 2/4] Add range comparison support to stg-mdiff.
From: Yann Dirson @ 2007-07-24 18:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070724185535.17180.24577.stgit@gandelf.nowhere.earth>
From: Yann Dirson <yann.dirson@sagem.com>
We can now compare arbitrary deltas, not just single commits.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-mdiff | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/contrib/stg-mdiff b/contrib/stg-mdiff
index cd0c678..9bb324a 100755
--- a/contrib/stg-mdiff
+++ b/contrib/stg-mdiff
@@ -12,7 +12,7 @@ set -e
usage()
{
- echo "Usage: $(basename $0) <patch1> <patch2>"
+ echo "Usage: $(basename $0) <from1>..[<to1>]|<patch1> <from2>..[<to2>]|<patch2>"
exit 1
}
@@ -20,4 +20,13 @@ if [ "$#" != 2 ]; then
usage
fi
-colordiff -u <(stg show "$1") <(stg show "$2") | less -RFX
+case "$1" in
+*..*) cmd1="stg diff" ;;
+*) cmd1="stg show" ;;
+esac
+case "$2" in
+*..*) cmd2="stg diff" ;;
+*) cmd2="stg show" ;;
+esac
+
+colordiff -u <($cmd1 "$1") <($cmd2 "$2") | less -RFX
^ permalink raw reply related
* [StGIT PATCH 1/4] Fix stg-whatchanged to deal with conflicts already solved.
From: Yann Dirson @ 2007-07-24 18:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070724185535.17180.24577.stgit@gandelf.nowhere.earth>
From: Yann Dirson <yann.dirson@sagem.com>
The most reliable way I found to decide if we were in the process of
solving a conflict, including when all conflicted files have already
been marked resolved, is to check the latest patchlog entry.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-whatchanged | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/contrib/stg-whatchanged b/contrib/stg-whatchanged
index a416e97..231f4f5 100755
--- a/contrib/stg-whatchanged
+++ b/contrib/stg-whatchanged
@@ -24,12 +24,10 @@ fi
# Merges via "push" leave top=bottom so we must look at old patch
# in this case (unlike, eg., "pick --fold")
patchdir="$(git-rev-parse --git-dir)/patches/$(stg branch)/patches/$(stg top)"
-if [ -s "$(git-rev-parse --git-dir)/conflicts" ];
-then
- current_cmd="stg show //top.old"
-else
- current_cmd="stg show"
-fi
+case $(stg log | head -n1) in
+ *push\(c\)*) current_cmd="stg show //top.old" ;;
+ *) current_cmd="stg show" ;;
+esac
colordiff "$@" \
-I '^index [0-9a-b]*..[0-9a-b]*' \
^ permalink raw reply related
* [StGIT PATCH 0/4] stg-whatchanged improvements
From: Yann Dirson @ 2007-07-24 18:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
The following series fixes a case where contrib/stg-whatchanged did
not work as expected, and makes it use contrib/stg-mdiff instead of
reimplementing the same logic. Especially since stg-whatchanged had
already gained metadiff-related improvements that stg-mdiff did not
had :)
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Johannes Schindelin @ 2007-07-24 18:30 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Junio C Hamano, Shawn O. Pearce, Julian Phillips, git
In-Reply-To: <46A63EAA.6080203@trolltech.com>
Hi,
On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:
> 1) IMO, git should on Windows always do CRLF conversion, as this is what
> Windows developers in general expect. (CRLF text-files that is, not the
> conversion.) Meaning that
> core.autocrlf = Windows
> by default. Where 'Windows' would be of true/false value which is true
> when on Windows and false when on other platforms. (Not that we should
> _have_ such an option, but the concept at least.)
I do not think so.
core.autocrlf is only about the relationship between the working tree and
the repository.
So if you want CR/LF line endings always, just do not set that flag
(which defaults to false).
If you want LF line endings in the repo, but not necessarily in the
working tree, set core.autocrlf to input.
If you want LF line endings sometimes, but CR/LF at other times, but do
not care if the revisions in the repository will have LF or CR/LF, do not
set that flag.
Git is really slowed down tremendously just by the fact that it runs on
Windows. You should not add to that.
IMHO in most cases -- even on Windows -- you do not want to set autocrlf
at all. Because you do not need to store the file different from the
version you have in the working tree.
The only situation where I think it makes sense, is when you have both
Windows and Unix developers, _and_ your Windows tools sometimes produce
CR/LF stupidly. But then I'd set it to "input".
BTW no need to fuzz about binary files, which want to be in the object
database without being converted. Our heuristics has so far been pretty
successful in discerning binary from text files.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Teach approxidate() to understand "never"
From: Johannes Schindelin @ 2007-07-24 18:18 UTC (permalink / raw)
To: git, gitster
If you want to keep the reflogs around for a really long time, you should be
able to say so:
$ git config gc.reflogExpire never
Now it works, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Guess how surprised I was when "gc.reflogExpire = never" triggered
a pruning of _all_ reflogs! Happily, this was only in a test
environment.
Another strange thing there is this: As an alternative, I set
reflogExpire to "1970", which git interpreted as "now" (just like
"never", before this patch). Another alternative was even worse:
"1 Jan 1970". Because I am at +0100 right now, the debugger said
this:
Breakpoint 1, cmd_reflog_expire (argc=1, argv=0xbfb92968, prefix=0x0)
at builtin-reflog.c:307
307 if (!default_reflog_expire_unreachable)
(gdb) p show_date(default_reflog_expire, 0, 0)
$3 = 0x8113560 "Wed Dec 31 23:00:00 1969 +0000"
(gdb) p default_reflog_expire
$4 = 4294963696
IOW, if I had not looked at the timestamp, I would have thunk
everything is fine, while "git reflog expire" again would have
merrily removed _every_ reflog.
date.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/date.c b/date.c
index 45b0b1d..59fe4f8 100644
--- a/date.c
+++ b/date.c
@@ -660,6 +660,12 @@ static void date_am(struct tm *tm, int *num)
tm->tm_hour = (hour % 12);
}
+static void date_never(struct tm *tm, int *num)
+{
+ tm->tm_year = tm->tm_mon = tm->tm_mday = tm->tm_wday = tm->tm_yday
+ = tm->tm_hour = tm->tm_min = tm->tm_sec = 0;
+}
+
static const struct special {
const char *name;
void (*fn)(struct tm *, int *);
@@ -670,6 +676,7 @@ static const struct special {
{ "tea", date_tea },
{ "PM", date_pm },
{ "AM", date_am },
+ { "never", date_never },
{ NULL }
};
--
1.5.3.rc2.42.gda8d
^ permalink raw reply related
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Marius Storm-Olsen @ 2007-07-24 18:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Shawn O. Pearce, Julian Phillips, git
In-Reply-To: <Pine.LNX.4.64.0707241431540.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]
>> So, it's look like this ('yes' mean CRLF EOL):
>> Repo | Working dir | Convert EOL?
>> ---------------------------------
>> 1) - LF no
>> 2) - CRLF yes
>> 3) LF LF no
>> 4) LF CRLF yes
>> 5) CRLF LF no
>> 6) CRLF CRLF yes
>>
>> The problem is that currently 6) is 'yes', and turns the file into
>> a LF file, which it shouldn't.
>
> Shouldn't it? But then you should set core.autocrlf = false, no?
>
> AFAIU the purpose of autocrlf is to _always_ have UNIX line endings
> in the checked in stuff.
I realize that I might be talking 'out of context', so to speak; so it's
hard to see where I'm going with this. So, I'll start from the
beginning. :-)
1) IMO, git should on Windows always do CRLF conversion, as this is what
Windows developers in general expect. (CRLF text-files that is, not the
conversion.) Meaning that
core.autocrlf = Windows
by default. Where 'Windows' would be of true/false value which is true
when on Windows and false when on other platforms. (Not that we should
_have_ such an option, but the concept at least.)
2) Most Windows developers in the category above currently do
git-config --global core.autocrlf true
once, and be done with it.
However, for every text-file they want in the repo which _should_
contain CRLF EOLs they would have to add this file to either a
.gitattributes file in that same directory, or to
.git/info/attributes
with the
<filepath> -crlf
to ensure that the autocrlf conversion is not triggered for those files.
Now, for Unix users that seems like a small price to pay, and of course
_they_ don't have to worry about it. It's up to the Windows developers
to take the pain and add these .gitattributes files, and keep track
whenever new CRLF files appear in the repo from other non-Windows
developers.
3) My suggestion in the previous mail would to a large extent alleviate
this problem, since once in the repo with CRLF lineendings the 'autocrlf
conversion' routine wouldn't automatically try to convert it back to LF
endings, even if this file is not in any attributes file with '-crlf'.
It would mean that we wouldn't have to add _any_ files to attributes
files at all, but only have to teach git a way to avoid crlf-converting
a given file when commiting a change. For example, on Windows you could
then do something like:
git update-index --crlf my_DOS_file.txt
git commit -m "Add a CRLF file to the repo"
then forget about it.
No need to add a .gitattributes in your own repo.
No need for linux users to worry about Windows users.
No need to Windows users to clean up the repos for the linux users.
IMO, the .gitattributes file with '<filepath> -crlf' is a hack-fix to a
problem we shouldn't be having in the first place. We should be able to
write in the git documentation:
"Text files are stored with Unix line ending in Git. If you need a
text file to contain DOS line endings on all platforms, use the --crlf
option on the update-index command."... or something to that effect.
Ok, a bit longer mail than I expected/wanted, but I hope it explains the
idea successfully, and convincingly. ;-)
Later!
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix translation of strings in foreach lists.
From: Brett Schwarz @ 2007-07-24 17:54 UTC (permalink / raw)
To: Christian Stimming, Shawn O. Pearce; +Cc: git, Paul Mackerras, Junio C Hamano
> ----- Original Message ----
> From: Christian Stimming <stimming@tuhh.de>
> To: Shawn O. Pearce <spearce@spearce.org>
> Cc: Brett Schwarz <brett_schwarz@yahoo.com>; git@vger.kernel.org; Paul Mackerras <paulus@samba.org>; Junio C Hamano <gitster@pobox.com>
> Sent: Tuesday, July 24, 2007 8:20:28 AM
> Subject: Re: [PATCH] Fix translation of strings in foreach lists.
>
> Quoting "Shawn O. Pearce" <spearce@spearce.org>:
> >> >I not sure if it's worth changing, but you don't necessarily need
> >> >those [append]'s in there.
> >>
> >> Thanks for the info. It is basically up to Shawn to decide which style
> >> he likes more.
> >
> > "[mc Foo]\n\n$err"
> >
> > is much shorter. So I'd prefer that over [append [mc Foo] "\n\n$err"].
>
> Err, but the usual case is that the argument to [mc] is more than one
> word, and (additionally) that argument has to be quoted by
> double-quotes (as opposed to braces) because otherwise xgettext
> doesn't extract the message correctly. Hence, the only possibility
> here were
>
> "[mc "Some Text"]\n\n$err"
>
> Is this valid Tcl? Being a newcomer to this language I have to says
> the quotes here look rather strange :-)
>
Yes, that's valid.
bschwarz@bschwarz-desktop:~/gittcl$ tclsh
% package require msgcat
1.3.4
% namespace import msgcat::mc
% set err "ERROR"
ERROR
% msgcat::mcset en "hello there" HOWDY
HOWDY
% puts "[mc "hello there"]\n\n$err"
HOWDY
ERROR
%
HTH,
--brett
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/
^ permalink raw reply
* Re: http git clone memory problem.
From: Benjamin Sergeant @ 2007-07-24 17:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707241842270.14781@racer.site>
On 7/24/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 24 Jul 2007, Benjamin Sergeant wrote:
>
> > I still have the segfault with 1.5.2.4. If I try to gdb it, it abort
> > before I can do anything. Is there an environment variable that I can
> > set to disable signal handling or something in git ?
>
> Did you gdb http-fetch?
>
> If not, please use "sh -x git-clone..." to find out what command line to
> use.
>
> And when you have the command line, please use valgrind to find out where
> the leak/corruption is.
>
> There are some flags that are automatically set/unset when compiling the
> http transport, and it is not easy to know which flags are enabled in your
> setup.
>
> But for starters, you might want to recompile http-fetch without -O2. My
> gdb always has problems attributing the correct line, which does not
> exactly make it easier for me to debug things. I could imagine your gdb
> is as annoying.
>
> Ciao,
> Dscho
I got that, but it's not super-usefull ... I will try valgrind instead.
[bsergean@marge1 sandbox]$ gdb /home/bsergean/git/bin/git-clone
/tmp/corefiles/core.18531
GNU gdb 6.6-1mdv2007.1 (Mandriva Linux release 2007.1)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu"...
"/home/bsergean/git/bin/git-clone": not in executable format: File
format not recognized
(no debugging symbols found)
Using host libthread_db library "/lib/i686/libthread_db.so.1".
Core was generated by `git-http-fetch -v -a -w remotes/origin/html
cc13f556fc72f6f0670e61599363f6e3277'.
Program terminated with signal 6, Aborted.
#0 0xbfffe410 in __kernel_vsyscall ()
(gdb) where
#0 0xbfffe410 in __kernel_vsyscall ()
#1 0xb7c78590 in ?? ()
#2 0xb7d7aff4 in ?? ()
#3 0xb7bd7aa0 in ?? ()
#4 0xbf928f84 in ?? ()
#5 0xb7c79e21 in ?? ()
#6 0x00000006 in ?? ()
#7 0xbf928ef8 in ?? ()
#8 0x00000000 in ?? ()
>
>
^ permalink raw reply
* Re: http git clone memory problem.
From: Johannes Schindelin @ 2007-07-24 17:45 UTC (permalink / raw)
To: Benjamin Sergeant; +Cc: git
In-Reply-To: <1621f9fa0707241033l7ac53b97i8c8ea068be0cba2f@mail.gmail.com>
Hi,
On Tue, 24 Jul 2007, Benjamin Sergeant wrote:
> I still have the segfault with 1.5.2.4. If I try to gdb it, it abort
> before I can do anything. Is there an environment variable that I can
> set to disable signal handling or something in git ?
Did you gdb http-fetch?
If not, please use "sh -x git-clone..." to find out what command line to
use.
And when you have the command line, please use valgrind to find out where
the leak/corruption is.
There are some flags that are automatically set/unset when compiling the
http transport, and it is not easy to know which flags are enabled in your
setup.
But for starters, you might want to recompile http-fetch without -O2. My
gdb always has problems attributing the correct line, which does not
exactly make it easier for me to debug things. I could imagine your gdb
is as annoying.
Ciao,
Dscho
^ permalink raw reply
* Re: http git clone memory problem.
From: Benjamin Sergeant @ 2007-07-24 17:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <1621f9fa0707241033l7ac53b97i8c8ea068be0cba2f@mail.gmail.com>
I found this patch on the net, which was probably integrated a while
ago, about curl, git and segfault ...
http://www.gelato.unsw.edu.au/archives/git/0606/21489.html
"""
If a curl handle is configured with special options, they may reference
information that is freed after the request is complete which can cause
a segfault if the curl handle is reused for a different type of request.
This patch resets these options to a safe state when a transfer slot is
assigned to a new request.
"""
I'm looking for the right MALLOC_* glibc variable so that I can see
where it crash.
On 7/24/07, Benjamin Sergeant <bsergean@gmail.com> wrote:
> Sorry, the mail went all alone by itself :)
>
> I still have the segfault with 1.5.2.4. If I try to gdb it, it abort
> before I can do anything. Is there an environment variable that I can
> set to disable signal handling or something in git ?
>
> *** glibc detected *** git-http-fetch: corrupted double-linked list:
> 0x080a4628 ***
>
> [bsergean@marge1 sandbox]$ git --version
> git version 1.5.2.4
> [bsergean@marge1 sandbox]$
> [bsergean@marge1 sandbox]$
> [bsergean@marge1 sandbox]$
> [bsergean@marge1 sandbox]$
> [bsergean@marge1 sandbox]$
> [bsergean@marge1 sandbox]$
> [bsergean@marge1 sandbox]$
> [bsergean@marge1 sandbox]$
> [bsergean@marge1 sandbox]$
> [bsergean@marge1 sandbox]$
> [bsergean@marge1 sandbox]$
> [bsergean@marge1 sandbox]$ git clone http://www.kernel.org/pub/scm/git/git.git
> Initialized empty Git repository in /home/bsergean/sandbox/git/.git/
> got cc13f556fc72f6f0670e61599363f6e327736ffb
> walk cc13f556fc72f6f0670e61599363f6e327736ffb
> got d33dfef836519e288b1f561a608020c10d01f8da
> got a196f6d93a21ebac9befc4b52a2b0586471b5fa4
> Getting alternates list for http://www.kernel.org/pub/scm/git/git.git
> walk a196f6d93a21ebac9befc4b52a2b0586471b5fa4
> Getting pack list for http://www.kernel.org/pub/scm/git/git.git
> Getting index for pack 6ce718d496eba4857e76cc9b8f7a1a82f5dfb416
> got 896ff1d95a2a307fd764b66de4fbd882e64dd9c6
> got dd98d95d9748cdcb4fd0926a049b4a68dad47a73
> Getting index for pack ffecdbabefeb7d684650f6c920c53c384bc65b5e
> *** glibc detected *** git-http-fetch: corrupted double-linked list:
> 0x080a4628 ***
> ======= Backtrace: =========
> /lib/i686/libc.so.6[0xb7c8a516]
> /lib/i686/libc.so.6[0xb7c8c728]
> /lib/i686/libc.so.6(__libc_calloc+0x94)[0xb7c8dd74]
> /usr/lib/libcurl.so.4[0xb7d98013]
> git-http-fetch[0x804adbb]
> git-http-fetch[0x804d9b4]
> git-http-fetch[0x804a642]
> git-http-fetch[0x804c150]
> /lib/i686/libc.so.6(__libc_start_main+0xdc)[0xb7c3cd8c]
> git-http-fetch[0x8049f81]
> ======= Memory map: ========
> 08048000-08070000 r-xp 00000000 03:06 841397
> /home/bsergean/git/bin/git-http-fetch
> 08070000-08071000 rwxp 00028000 03:06 841397
> /home/bsergean/git/bin/git-http-fetch
> 08071000-08494000 rwxp 08071000 00:00 0 [heap]
> b7800000-b7821000 rwxp b7800000 00:00 0
> b7821000-b7900000 ---p b7821000 00:00 0
> b79e9000-b79f3000 r-xp 00000000 03:02 678969 /lib/libgcc_s-4.1.2.so.1
> b79f3000-b79f4000 rwxp 0000a000 03:02 678969 /lib/libgcc_s-4.1.2.so.1
> b7a09000-b7a29000 rwxp b7a09000 00:00 0
> b7a29000-b7b6e000 r-xp 00000000 03:06 841551
> /home/bsergean/sandbox/git/.git/objects/pack/pack-6ce718d496eba4857e76cc9b8f7a1a82f5dfb416.idx
> b7b6e000-b7b7c000 r-xp 00000000 03:02 678959 /lib/libresolv-2.4.so
> b7b7c000-b7b7e000 rwxp 0000e000 03:02 678959 /lib/libresolv-2.4.so
> b7b7e000-b7b80000 rwxp b7b7e000 00:00 0
> b7b80000-b7b84000 r-xp 00000000 03:02 678947 /lib/libnss_dns-2.4.so
> b7b84000-b7b86000 rwxp 00003000 03:02 678947 /lib/libnss_dns-2.4.so
> b7b86000-b7b96000 r-xp 00000000 03:02 678943 /lib/libnsl-2.4.so
> b7b96000-b7b98000 rwxp 00010000 03:02 678943 /lib/libnsl-2.4.so
> b7b98000-b7b9a000 rwxp b7b98000 00:00 0
> b7b9a000-b7ba2000 r-xp 00000000 03:02 678953 /lib/libnss_nis-2.4.so
> b7ba2000-b7ba4000 rwxp 00007000 03:02 678953 /lib/libnss_nis-2.4.so
> b7ba4000-b7bac000 r-xp 00000000 03:02 678949 /lib/libnss_files-2.4.so
> b7bac000-b7bae000 rwxp 00007000 03:02 678949 /lib/libnss_files-2.4.so
> b7bae000-b7baf000 rwxp b7bae000 00:00 0
> b7baf000-b7bee000 r-xp 00000000 03:02 36383 /usr/lib/libssl.so.0.9.8
> b7bee000-b7bf2000 rwxp 0003e000 03:02 36383 /usr/lib/libssl.so.0.9.8
> b7bf2000-b7c22000 r-xp 00000000 03:02 215594 /usr/lib/libidn.so.11.5.23
> b7c22000-b7c23000 rwxp 0002f000 03:02 215594 /usr/lib/libidn.so.11.5.23
> b7c23000-b7c25000 r-xp 00000000 03:02 678939 /lib/libdl-2.4.so
> b7c25000-b7c27000 rwxp 00001000 03:02 678939 /lib/libdl-2.4.so
> b7c27000-b7d50000 r-xp 00000000 03:02 678918 /lib/i686/libc-2.4.so
> b7d50000-b7d51000 r-xp 00129000 03:02 678918 /lib/i686/libc-2.4.so
> b7d51000-b7d53000 rwxp 0012a000 03:02 678918 /lib/i686/libc-2.4.so
> b7d53000-b7d57000 rwxp b7d53000 00:00 0
> b7d57000-b7d75000 r-xp 00000000 03:02 215102 /usr/lib/libexpat.so.0.5.0
> b7d75000-b7d77000 rwxp 0001e000 03:02 215102 /usr/lib/libexpat.so.0.5.0
> b7d77000-b7dc5000 r-xp 00000000 03:02 215628 /usr/lib/libcurl.so.4.0.0
> b7dc5000-b7dc6000 rwxp 0004d000 03:02 215628 /usr/lib/libcurl.so.4.0.0
> b7dc6000-b7f11000 r-xp 00000000 03:02 36382 /usr/lib/libcrypto.so.0.9.8
> b7f11000-b7f26000 rwxp 0014b000 03:02 36382 /usr/lib/libcrypto.so.0.9.8
> b7f26000-b7f29000 rwxp b7f26000 00:00 0
> b7f29000-b7f3b000 r-xp 00000000 03:02 678968 /lib/libz.so.1.2.3
> b7f3b000-b7f3c000 rwxp 00011000 03:02 678968 /lib/libz.so.1.2.3
> b7f51000-b7f52000 rwxp b7f51000 00:00 0
> b7f52000-b7f6a000 r-xp 00000000 03:02 678928 /lib/ld-2.4.so
> b7f6a000-b7f6b000 r-xp 00017000 03:02 678928 /lib/ld-2.4.so
> b7f6b000-b7f6c000 rwxp 00018000 03:02 678928 /lib/ld-2.4.so
> bfafc000-bfb11000 rw-p bfafc000 00:00 0 [stack]
> bfffe000-bffff000 r-xp bfffe000 00:00 0
> /home/bsergean/git/bin/git-clone: line 40: 17529 Aborted
> git-http-fetch $v -a -w "$tname" "$sha1" "$1"
>
>
>
> On 7/24/07, Benjamin Sergeant <bsergean@gmail.com> wrote:
> > With
> >
> > On 7/24/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Hi,
> > >
> > > On Mon, 23 Jul 2007, Benjamin Sergeant wrote:
> > >
> > > > - Sorry for the noise if this has already been reported.
> > > > - It's on a Mandriva Spring machine with git 1.5.0.4
> > >
> > > That is really old. Could you try with a newer version? I do not
> > > remember off-hand if we had fixed such a problem.
> > >
> > > Ciao,
> > > Dscho
> > >
> > >
> >
>
^ permalink raw reply
* Re: http git clone memory problem.
From: Benjamin Sergeant @ 2007-07-24 17:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <1621f9fa0707240958y7c5f1b66lbfa940d60c082067@mail.gmail.com>
Sorry, the mail went all alone by itself :)
I still have the segfault with 1.5.2.4. If I try to gdb it, it abort
before I can do anything. Is there an environment variable that I can
set to disable signal handling or something in git ?
*** glibc detected *** git-http-fetch: corrupted double-linked list:
0x080a4628 ***
[bsergean@marge1 sandbox]$ git --version
git version 1.5.2.4
[bsergean@marge1 sandbox]$
[bsergean@marge1 sandbox]$
[bsergean@marge1 sandbox]$
[bsergean@marge1 sandbox]$
[bsergean@marge1 sandbox]$
[bsergean@marge1 sandbox]$
[bsergean@marge1 sandbox]$
[bsergean@marge1 sandbox]$
[bsergean@marge1 sandbox]$
[bsergean@marge1 sandbox]$
[bsergean@marge1 sandbox]$
[bsergean@marge1 sandbox]$ git clone http://www.kernel.org/pub/scm/git/git.git
Initialized empty Git repository in /home/bsergean/sandbox/git/.git/
got cc13f556fc72f6f0670e61599363f6e327736ffb
walk cc13f556fc72f6f0670e61599363f6e327736ffb
got d33dfef836519e288b1f561a608020c10d01f8da
got a196f6d93a21ebac9befc4b52a2b0586471b5fa4
Getting alternates list for http://www.kernel.org/pub/scm/git/git.git
walk a196f6d93a21ebac9befc4b52a2b0586471b5fa4
Getting pack list for http://www.kernel.org/pub/scm/git/git.git
Getting index for pack 6ce718d496eba4857e76cc9b8f7a1a82f5dfb416
got 896ff1d95a2a307fd764b66de4fbd882e64dd9c6
got dd98d95d9748cdcb4fd0926a049b4a68dad47a73
Getting index for pack ffecdbabefeb7d684650f6c920c53c384bc65b5e
*** glibc detected *** git-http-fetch: corrupted double-linked list:
0x080a4628 ***
======= Backtrace: =========
/lib/i686/libc.so.6[0xb7c8a516]
/lib/i686/libc.so.6[0xb7c8c728]
/lib/i686/libc.so.6(__libc_calloc+0x94)[0xb7c8dd74]
/usr/lib/libcurl.so.4[0xb7d98013]
git-http-fetch[0x804adbb]
git-http-fetch[0x804d9b4]
git-http-fetch[0x804a642]
git-http-fetch[0x804c150]
/lib/i686/libc.so.6(__libc_start_main+0xdc)[0xb7c3cd8c]
git-http-fetch[0x8049f81]
======= Memory map: ========
08048000-08070000 r-xp 00000000 03:06 841397
/home/bsergean/git/bin/git-http-fetch
08070000-08071000 rwxp 00028000 03:06 841397
/home/bsergean/git/bin/git-http-fetch
08071000-08494000 rwxp 08071000 00:00 0 [heap]
b7800000-b7821000 rwxp b7800000 00:00 0
b7821000-b7900000 ---p b7821000 00:00 0
b79e9000-b79f3000 r-xp 00000000 03:02 678969 /lib/libgcc_s-4.1.2.so.1
b79f3000-b79f4000 rwxp 0000a000 03:02 678969 /lib/libgcc_s-4.1.2.so.1
b7a09000-b7a29000 rwxp b7a09000 00:00 0
b7a29000-b7b6e000 r-xp 00000000 03:06 841551
/home/bsergean/sandbox/git/.git/objects/pack/pack-6ce718d496eba4857e76cc9b8f7a1a82f5dfb416.idx
b7b6e000-b7b7c000 r-xp 00000000 03:02 678959 /lib/libresolv-2.4.so
b7b7c000-b7b7e000 rwxp 0000e000 03:02 678959 /lib/libresolv-2.4.so
b7b7e000-b7b80000 rwxp b7b7e000 00:00 0
b7b80000-b7b84000 r-xp 00000000 03:02 678947 /lib/libnss_dns-2.4.so
b7b84000-b7b86000 rwxp 00003000 03:02 678947 /lib/libnss_dns-2.4.so
b7b86000-b7b96000 r-xp 00000000 03:02 678943 /lib/libnsl-2.4.so
b7b96000-b7b98000 rwxp 00010000 03:02 678943 /lib/libnsl-2.4.so
b7b98000-b7b9a000 rwxp b7b98000 00:00 0
b7b9a000-b7ba2000 r-xp 00000000 03:02 678953 /lib/libnss_nis-2.4.so
b7ba2000-b7ba4000 rwxp 00007000 03:02 678953 /lib/libnss_nis-2.4.so
b7ba4000-b7bac000 r-xp 00000000 03:02 678949 /lib/libnss_files-2.4.so
b7bac000-b7bae000 rwxp 00007000 03:02 678949 /lib/libnss_files-2.4.so
b7bae000-b7baf000 rwxp b7bae000 00:00 0
b7baf000-b7bee000 r-xp 00000000 03:02 36383 /usr/lib/libssl.so.0.9.8
b7bee000-b7bf2000 rwxp 0003e000 03:02 36383 /usr/lib/libssl.so.0.9.8
b7bf2000-b7c22000 r-xp 00000000 03:02 215594 /usr/lib/libidn.so.11.5.23
b7c22000-b7c23000 rwxp 0002f000 03:02 215594 /usr/lib/libidn.so.11.5.23
b7c23000-b7c25000 r-xp 00000000 03:02 678939 /lib/libdl-2.4.so
b7c25000-b7c27000 rwxp 00001000 03:02 678939 /lib/libdl-2.4.so
b7c27000-b7d50000 r-xp 00000000 03:02 678918 /lib/i686/libc-2.4.so
b7d50000-b7d51000 r-xp 00129000 03:02 678918 /lib/i686/libc-2.4.so
b7d51000-b7d53000 rwxp 0012a000 03:02 678918 /lib/i686/libc-2.4.so
b7d53000-b7d57000 rwxp b7d53000 00:00 0
b7d57000-b7d75000 r-xp 00000000 03:02 215102 /usr/lib/libexpat.so.0.5.0
b7d75000-b7d77000 rwxp 0001e000 03:02 215102 /usr/lib/libexpat.so.0.5.0
b7d77000-b7dc5000 r-xp 00000000 03:02 215628 /usr/lib/libcurl.so.4.0.0
b7dc5000-b7dc6000 rwxp 0004d000 03:02 215628 /usr/lib/libcurl.so.4.0.0
b7dc6000-b7f11000 r-xp 00000000 03:02 36382 /usr/lib/libcrypto.so.0.9.8
b7f11000-b7f26000 rwxp 0014b000 03:02 36382 /usr/lib/libcrypto.so.0.9.8
b7f26000-b7f29000 rwxp b7f26000 00:00 0
b7f29000-b7f3b000 r-xp 00000000 03:02 678968 /lib/libz.so.1.2.3
b7f3b000-b7f3c000 rwxp 00011000 03:02 678968 /lib/libz.so.1.2.3
b7f51000-b7f52000 rwxp b7f51000 00:00 0
b7f52000-b7f6a000 r-xp 00000000 03:02 678928 /lib/ld-2.4.so
b7f6a000-b7f6b000 r-xp 00017000 03:02 678928 /lib/ld-2.4.so
b7f6b000-b7f6c000 rwxp 00018000 03:02 678928 /lib/ld-2.4.so
bfafc000-bfb11000 rw-p bfafc000 00:00 0 [stack]
bfffe000-bffff000 r-xp bfffe000 00:00 0
/home/bsergean/git/bin/git-clone: line 40: 17529 Aborted
git-http-fetch $v -a -w "$tname" "$sha1" "$1"
On 7/24/07, Benjamin Sergeant <bsergean@gmail.com> wrote:
> With
>
> On 7/24/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Mon, 23 Jul 2007, Benjamin Sergeant wrote:
> >
> > > - Sorry for the noise if this has already been reported.
> > > - It's on a Mandriva Spring machine with git 1.5.0.4
> >
> > That is really old. Could you try with a newer version? I do not
> > remember off-hand if we had fixed such a problem.
> >
> > Ciao,
> > Dscho
> >
> >
>
^ permalink raw reply
* Re: [QGIT4 PATCH 0/6] Some UI Improvements
From: Peter Oberndorfer @ 2007-07-24 17:29 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550707231513u8568e48hb280151b8f40681c@mail.gmail.com>
On Tuesday 24 July 2007 00:13, Marco Costalba wrote:
> On 7/23/07, Peter Oberndorfer <kumbayo84@arcor.de> wrote:
> > Hi,
> > the initial reason for this patches is that here on my system qgit4 looks like this
> > http://img77.imageshack.us/my.php?image=qgit4strangewindowgi0.png
>
> Hi Peter,
>
> OMG that's horrific! I can't understand how it is possible, on my box
> (Mandriva with QT4.3) everything is fine.
>
> Anyway thanks a lot for the patches. Already applied and pushed.
Thanks for applying.
>
> > If anyone wants me to remove that too, i would be happy to send more patches
>
> Please feel free to send me any patch that could improve the GUI,
> unfortunately on my box I'm unable to see all these defects, so any
> patch from you is more then welcome.
Will send them when they are cleaned up properly.
>
> >
> > If you want i can provide more screenshots of how patches change appearance.
> >
>
> Patchview has not changed for me with your patches, fileview yes, I
> can see the difference and also customaction. I would say nice job!
> thanks.
Without patch 5 (remove empty space below "diff to" header in patch view)
qgit4 looks like this on my machine
http://img409.imageshack.us/img409/5174/qgitwithoutpatch5zp9.png
Greetings Peter
>
> Marco
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: rfe: bisecting with a tristate
From: Johannes Schindelin @ 2007-07-24 17:21 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Sean, Jan Engelhardt, git
In-Reply-To: <200707241907.57857.robin.rosenberg.lists@dewire.com>
Hi,
On Tue, 24 Jul 2007, Robin Rosenberg wrote:
> tisdag 24 juli 2007 skrev Johannes Schindelin:
>
> > On Tue, 24 Jul 2007, Sean wrote:
> >
> > > > git bisect start
> > > > git bisect bad v2.6.23-rc1
> > > > # bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1
> > > > git bisect good v2.6.22
> > > > # good: [098fd16f00005f665d3baa7e682d8cb3d7c0fe6f] Linux 2.6.22
> > > >
> > > > Then 1f1c2881f673671539b25686df463518d69c4649 will be the next commit
> > > > git bisect hands out. Now let's assume this commit would not compile.
> > > > What would the user do? git-bisect good or git-bisect bad?
> > >
> > > Check out the section "Avoiding to test a commit" in the git-bisect
> > > man page; it addresses this issue. Basically you just use git-reset
> > > to pick a different nearby commit to compile, and then continue with
> > > git bisect good/bad.
> >
> > But a "git bisect dunno" would be handy.
>
> Why? Not doing anything is enough, just select a new commit. Going back
> can be done by git reset, but forward (towards original HEAD) requires
> more thinking so a git bisect forward [n] would help there.
And why exactly do you want to make it hard on the user?
Imagine this history:
A - B - broken - bad - C
Now you bisect. It goes to "broken". You compile. Darn, does not
compile. Why not have a "git bisect dunno", which considers only the
_rest_ of the commits for the next bisection point? When it finally found
the "bad" one, it has to say it broke somewhere between "B..bad".
Now that would be user friendly, wouldn't it?
Ciao,
Dscho
^ permalink raw reply
* Re: rfe: bisecting with a tristate
From: Robin Rosenberg @ 2007-07-24 17:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sean, Jan Engelhardt, git
In-Reply-To: <Pine.LNX.4.64.0707241447200.14781@racer.site>
tisdag 24 juli 2007 skrev Johannes Schindelin:
> Hi,
>
> On Tue, 24 Jul 2007, Sean wrote:
>
> > > git bisect start
> > > git bisect bad v2.6.23-rc1
> > > # bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1
> > > git bisect good v2.6.22
> > > # good: [098fd16f00005f665d3baa7e682d8cb3d7c0fe6f] Linux 2.6.22
> > >
> > > Then 1f1c2881f673671539b25686df463518d69c4649 will be the next commit
> > > git bisect hands out. Now let's assume this commit would not compile.
> > > What would the user do? git-bisect good or git-bisect bad?
> >
> > Check out the section "Avoiding to test a commit" in the git-bisect
> > man page; it addresses this issue. Basically you just use git-reset
> > to pick a different nearby commit to compile, and then continue with
> > git bisect good/bad.
>
> But a "git bisect dunno" would be handy.
Why? Not doing anything is enough, just select a new commit. Going back can be done by
git reset, but forward (towards original HEAD) requires more thinking so a git bisect forward [n]
would help there.
-- robin
^ permalink raw reply
* Re: http git clone memory problem.
From: Benjamin Sergeant @ 2007-07-24 16:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707241025450.14781@racer.site>
With
On 7/24/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 23 Jul 2007, Benjamin Sergeant wrote:
>
> > - Sorry for the noise if this has already been reported.
> > - It's on a Mandriva Spring machine with git 1.5.0.4
>
> That is really old. Could you try with a newer version? I do not
> remember off-hand if we had fixed such a problem.
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: workflow question
From: Julian Phillips @ 2007-07-24 16:35 UTC (permalink / raw)
To: Patrick Doyle; +Cc: Alex Riesen, git
In-Reply-To: <e2a1d0aa0707240930gb99cb0csd1ce9946d33982d@mail.gmail.com>
On Tue, 24 Jul 2007, Patrick Doyle wrote:
>> > ... and I don't commit until I've completed
>> > the particular feature I'm working on, I can get a fairly good idea of
>> > where I am and what I was doing last (which might be 5-7 days ago,
>> > given high priority interrupts on other projects, summer vacations,
>> > etc...) just by running a "git status". I see that there are 7 new
>> > files, and 2 modified files. I know that, when I fork my branch, I
>> > can use "git diff master" to see what's different between my branch
>> > and the master, but then I get the diff of all of the changes as well,
>> > which is too much information. "git diff --name-only" and "git diff
>> > --summary" are closer, but I can't tell what's been added vs. what's
>> > been changed. Any suggestions?
>>
>> "git log -p ..master", or even simpler "gitk ..master"
> I was hoping for something less verbose than a diff or a patch file --
> something that just listed what has changed -- I'll have to
> investigate whether your "my_status()" macro provides the information
> for which I was looking -- thanks for the pointer.
"git log --stat ..master" perhaps?
--
Julian
---
The future isn't what it used to be. (It never was.)
^ permalink raw reply
* Re: workflow question
From: Patrick Doyle @ 2007-07-24 16:30 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0707240837l16844dbct52ffa426d8b8547b@mail.gmail.com>
On 7/24/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 7/24/07, Patrick Doyle <wpdster@gmail.com> wrote:
> > 2) When I don't fork a branch,
>
> this is a confusing sentence: "fork" does not happen as
> an explicit operation (if at all). You just commit somewhere
> and depending on how you look at the history you either
> see or not see a "fork".
ok, I probably should have said, "When I don't create a branch, and
when I have not yet committed any changes for the particular
feature..."
>
> > ... and I don't commit until I've completed
> > the particular feature I'm working on, I can get a fairly good idea of
> > where I am and what I was doing last (which might be 5-7 days ago,
> > given high priority interrupts on other projects, summer vacations,
> > etc...) just by running a "git status". I see that there are 7 new
> > files, and 2 modified files. I know that, when I fork my branch, I
> > can use "git diff master" to see what's different between my branch
> > and the master, but then I get the diff of all of the changes as well,
> > which is too much information. "git diff --name-only" and "git diff
> > --summary" are closer, but I can't tell what's been added vs. what's
> > been changed. Any suggestions?
>
> "git log -p ..master", or even simpler "gitk ..master"
I was hoping for something less verbose than a diff or a patch file --
something that just listed what has changed -- I'll have to
investigate whether your "my_status()" macro provides the information
for which I was looking -- thanks for the pointer.
And, as for gitk, there is something about the combination of the
screen on my laptop, my Linux installation (FC6), my X server
configuration, and/or me that makes the fonts totally unreadable. I
keep meaning to follow up on that, but I'm stuck in a
chicken-and-the-egg situation. I don't see the utility of gitk
because I can't read the display that it produces. I don't look for
the time to fix the display that it produces because, thus far, I
don't see the utility of gitk. Sigh...
> my_status() {
> git diff --cached --name-status -r -M -C HEAD -- "$@" && \
> git diff --name-status -r -M -C -- "$@"
> }
>
> Use as: my_status [pathname-limiter].
> Does not show untracked files, though.
>
Ahhh... I was looking around git-status instead of git-diff. That
makes sense now that you mention it. Someday I may have the intuitive
understanding of git that would point me in that direction myself, but
I ain't there yet :-)
Thanks.
--wpd
^ permalink raw reply
* Re: workflow question
From: Alex Riesen @ 2007-07-24 15:37 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <e2a1d0aa0707240653x55dd82b3pf9e3986f5c3bb344@mail.gmail.com>
On 7/24/07, Patrick Doyle <wpdster@gmail.com> wrote:
> 2) When I don't fork a branch,
this is a confusing sentence: "fork" does not happen as
an explicit operation (if at all). You just commit somewhere
and depending on how you look at the history you either
see or not see a "fork".
> ... and I don't commit until I've completed
> the particular feature I'm working on, I can get a fairly good idea of
> where I am and what I was doing last (which might be 5-7 days ago,
> given high priority interrupts on other projects, summer vacations,
> etc...) just by running a "git status". I see that there are 7 new
> files, and 2 modified files. I know that, when I fork my branch, I
> can use "git diff master" to see what's different between my branch
> and the master, but then I get the diff of all of the changes as well,
> which is too much information. "git diff --name-only" and "git diff
> --summary" are closer, but I can't tell what's been added vs. what's
> been changed. Any suggestions?
"git log -p ..master", or even simpler "gitk ..master"
> As an aside, is there an undocumented option to "git status" to
> produce a less verbose report of what's been changed and what's not
> checked in? Perhaps a single line per file with a one or two letter
> indication of the status of the file followed by the name? If not,
> would there be any violent objections to my submitting a patch to add
> such a feature?
my_status() {
git diff --cached --name-status -r -M -C HEAD -- "$@" && \
git diff --name-status -r -M -C -- "$@"
}
Use as: my_status [pathname-limiter].
Does not show untracked files, though.
^ permalink raw reply
* Re: [PATCH] Add a 1-second sleep to git-cvsexportcommit test
From: Jason Sewall @ 2007-07-24 15:31 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Junio C Hamano, Simon 'corecode' Schubert, git, raa.lkml
In-Reply-To: <200707241457.53414.robin.rosenberg.lists@dewire.com>
Fedora 7
Kernel 2.6.22 (SMP)
CVS 1.11.22
ext3 (unsure of version or how to discover version)
As one would expect from the above, the 'granularity' test you gave my
reveals 1-second granularity.
On 7/24/07, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> tisdag 24 juli 2007 skrev Junio C Hamano:
> > > Here CVS sleeps. The amount varies between invocations since it
> > > only sleeps enough for the seconds to wrap.
> >
> > Makes one wonder what it would do if you are on a filesystem
> > with coarser-than-a-second timestamp resolution.
>
> Like fat, but then the last test fails on FAT, which wasn't the case. Any other reasonable file
> systems that comes to your mind?
>
> Jason, could you provide us with some more information on OS, fs, cvs version etc.
>
> Whether timestamp granularity is larger than a second or not can be checked with this line, I think:
>
> touch a && ls --full-time a && sleep 1 && touch a && ls --full-time a
>
> Sample output where the timestamps are roughly one second apart.
> -rw-r--r-- 1 me me 0 2007-07-24 14:15:47.330927250 +0200 a
> -rw-r--r-- 1 me me 0 2007-07-24 14:15:48.338990250 +0200 a
>
> -- robin
>
^ permalink raw reply
* Re: [PATCH] Fix translation of strings in foreach lists.
From: Christian Stimming @ 2007-07-24 15:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Brett Schwarz, git, Paul Mackerras, Junio C Hamano
In-Reply-To: <20070724150136.GM32566@spearce.org>
Quoting "Shawn O. Pearce" <spearce@spearce.org>:
>> >I not sure if it's worth changing, but you don't necessarily need
>> >those [append]'s in there.
>>
>> Thanks for the info. It is basically up to Shawn to decide which style
>> he likes more.
>
> "[mc Foo]\n\n$err"
>
> is much shorter. So I'd prefer that over [append [mc Foo] "\n\n$err"].
Err, but the usual case is that the argument to [mc] is more than one
word, and (additionally) that argument has to be quoted by
double-quotes (as opposed to braces) because otherwise xgettext
doesn't extract the message correctly. Hence, the only possibility
here were
"[mc "Some Text"]\n\n$err"
Is this valid Tcl? Being a newcomer to this language I have to says
the quotes here look rather strange :-)
> Its not like you've saved a dq-eval either, as you still have to do one
> for the \n\n. But either way is valid Tcl, and works, and the append
> version is not so bad that I'd reject a patch that used it.
Ok, thanks.
Christian
^ permalink raw reply
* Re: [PATCH] filter-branch: rewrite only refs which were not excludedbythe options
From: Johannes Sixt @ 2007-07-24 15:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0707241518290.14781@racer.site>
Johannes Schindelin wrote:
>
> Hi,
>
> On Tue, 24 Jul 2007, Johannes Sixt wrote:
>
> > Johannes Schindelin wrote:
> >
> > > On Tue, 24 Jul 2007, Johannes Sixt wrote:
> > >
> > > > But there's another problem. Consider this history:
> > > >
> > > > ---X--o--M <- master
> > > > \
> > > > ...-o-...-o <- topic
> > > >
> > > > Then this (rather contrieved) command:
> > > >
> > > > $ git-filter-branch -n $n master topic --not X
> > > >
> > > > If $n is small enough so that M is never rewritten, then
> > > >
> > > > git rev-list -1 "$ref" $negatives
> > > >
> > > > still expands to non-empty even for 'master' (= M), which then
> > > > incorrectly ends up in "$tempdir"/heads.
> > >
> > > Aaargh! Of course! Since I have to add --topo-order at the end.
> > > Otherwise it makes no sense.
> >
> > No, that was no my point: In my example above, if n=1, `git rev-list -1
> > "$ref" $negatives` evaluates to
> >
> > $ git rev-list -1 "master" -n 1 ^X
> >
> > which returns M, even though M is not going to be rewritten.
> > --topo-order changes nothing. The problem is that the -n is a relative
> > restriction. --since is turned into --max-age, which is absolute,
> > therefore, the test works as expected with --since.
>
> So you think we have to say something like
>
> git rev-list "$ref" $negatives | grep "$ref" > /dev/null || continue
>
> ?
No, doesn't help either.
We are talking about a case where there is more than one positive ref.
We need not consider the -- sub/ case - it makes things just even more
complicated. There are two different rev ranges to be considered:
# (1) candidate range to be rewritten
$ git rev-list "$@"
# (2) test if positive ref is in candidate range
$ git rev-list $ref $negatives
Usually (without -n) (2) is a subset of (1) because (1) has all positive
refs and (2) has only one. And the subset is empty iff the positive ref
is not in the rewritten range.
However, if "$@" (and, hence, $negatives) contains the -n limiter, this
is no longer true. Example:
(1) is: "rev-list -n 1 A B ^C": we get either A or B, but not both;
lets say A.
(2A) is: "rev-list -n 1 A ^C": we get A -- good
(2B) is: "rev-list -n 1 B ^C": we get B -- ouch!
For each positive ref, A, B, we conduct test (2). For A, the test result
is correct. But for B it is not. We expect it to tell us that B is not
rewritten; but in fact it tells the opposite by returning something
instead of nothing.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Fix translation of strings in foreach lists.
From: Shawn O. Pearce @ 2007-07-24 15:01 UTC (permalink / raw)
To: Christian Stimming; +Cc: Brett Schwarz, git, Paul Mackerras, Junio C Hamano
In-Reply-To: <20070724112701.ndpm5fxaocks804s@webmail.tu-harburg.de>
Christian Stimming <stimming@tuhh.de> wrote:
> Fix translation of strings in foreach lists.
>
> Signed-off-by: Christian Stimming <stimming@tuhh.de>
> ---
> Quoting Brett Schwarz <brett_schwarz@yahoo.com>:
> >I not sure if it's worth changing, but you don't necessarily need
> >those [append]'s in there.
>
> Thanks for the info. It is basically up to Shawn to decide which style
> he likes more.
"[mc Foo]\n\n$err"
is much shorter. So I'd prefer that over [append [mc Foo] "\n\n$err"].
Its not like you've saved a dq-eval either, as you still have to do one
for the \n\n. But either way is valid Tcl, and works, and the append
version is not so bad that I'd reject a patch that used it.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/5] Internationalization of git-gui
From: Shawn O. Pearce @ 2007-07-24 14:57 UTC (permalink / raw)
To: Christian Stimming; +Cc: Brett Schwarz, git, Paul Mackerras
In-Reply-To: <200707232123.01682.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> wrote:
> Am Sonntag, 22. Juli 2007 09:38 schrieb Shawn O. Pearce:
> > > +## Internationalization (i18n) through msgcat and gettext. See
> > > +## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html
> > > +package require msgcat
> > > +::msgcat::mcload [file join $oguilib msgs]
> > > +namespace import ::msgcat::mc
> >
> > Thanks. We'll probably also want to modify the lib/class.tcl to
> > import ::msgcat::mc ...
>
> As I was adding the markup in all the other files, I didn't have to add
> another import statement anywhere else. Seems like the global mc procedure
> works just fine.
>
> In other words, if you think the mc procedure should be imported in another
> place as well, please do so because I don't know your future plans with class
> structure (and I also don't need to know for adding the i18n support right
> now).
Hmm. Actually that makes sense. We probably don't need to make
any changes, other than to make sure we don't override the "mc"
definition in any of the other UI namespaces, since it is currently
being inherited from :: (the global namespace).
Thanks.
--
Shawn.
^ 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