* Re: Merging adjacent deleted lines?
From: Robin Rosenberg @ 2009-01-22 20:13 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <57518fd10901220257p62b6d1efof97ba3fcf90dbfda@mail.gmail.com>
torsdag 22 januari 2009 11:57:41 skrev Jonathan del Strother:
> On Wed, Jan 21, 2009 at 7:49 PM, Robin Rosenberg
> <robin.rosenberg.lists@dewire.com> wrote:
> > onsdag 21 januari 2009 20:20:50 skrev Jonathan del Strother:
> > [...]
> > I think you've illustrated a case for graphical merge resolution tools, i.e.
> > run git mergetool to help resolve the conlicts. It will run a graphical tool
> > for you.
> >
>
> Mmm. I use opendiff, which is generally ok, but in this case produced
> a merge looking like this :
> http://pastie.org/paste/asset/367587/Picture_6.png
> Which, in my mind, isn't any clearer about the fact that both lines
> ought to be deleted than the text conflict markers are. Do any of the
> other graphical tools present conflicts like that differently?
Try a three-way merge tool instead like, e.g. xxdiff.
-- robin
^ permalink raw reply
* [PATCH] Fix Documentation for git-describe
From: Boyd Stephen Smith Jr. @ 2009-01-22 18:26 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: Martin Pirker, git, Junio C Hamano
In-Reply-To: <497867BE.8070509@dbservice.com>
The documentation for git-describe says the default abbreviation is 8
hexadecimal digits while cache.c clearly shows DEFAULT_ABBREV set to 7.
This patch corrects the documentation.
Signed-off-by: Boyd Stephen Smith Jr <bss@iguanasuicide.net>
---
On Thursday 2009 January 22 06:34:06 Tomas Carnecky wrote:
>On 01/22/2009 12:26 PM, Martin Pirker wrote:
>> john@doe:/workspace$ git version
>> git version 1.6.1
>> john@doe:/workspace$ git describe
>> fatal: cannot describe '7aee61cc635a923e70b74091486742481ee0928b'
>> john@doe:/workspace$ git describe --always
>> 7aee61c
>> john@doe:/workspace$ git describe --always --abbrev=8
>> 7aee61cc
>>
>> man git-describe:
>> --abbrev=<n>
>> Instead of using the default 8 hexadecimal digits as the
>> abbreviated object name, use<n> digits.
>>
>> There is one character missing from default or what am I missing?
>
>The man page is wrong:
>
>cache.h:#define DEFAULT_ABBREV 7
>builtin-describe.c:static int abbrev = DEFAULT_ABBREV;
Let's fix it then! This is a patch against maint.
Is there any way to include values from the source as text in the ascidoc
other than copy-and-paste? It would be nice if we don't have to do this fix
again in the future.
I did a quick scan of 'git grep 8 -- Documentation' and didn't see
anywhere else this needed fixing.
Documentation/git-describe.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 3d79f05..a30c5ac 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -43,7 +43,7 @@ OPTIONS
Automatically implies --tags.
--abbrev=<n>::
- Instead of using the default 8 hexadecimal digits as the
+ Instead of using the default 7 hexadecimal digits as the
abbreviated object name, use <n> digits.
--candidates=<n>::
--
1.6.0.2
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
^ permalink raw reply related
* Re[2]: [PATCH] cygwin: Convert paths for html help from posix to windows
From: Steffen Jaeckel @ 2009-01-22 19:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Björn Steinbrink, git
In-Reply-To: <alpine.DEB.1.00.0901221829180.3586@pacific.mpi-cbg.de>
Hi,
-----Original Message-----
From: Johannes Schindelin [mailto:Johannes.Schindelin@gmx.de]
> Hi,
> On Thu, 22 Jan 2009, Junio C Hamano wrote:
>> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>>
>> > OK, I don't really know if this is the right way to do it. Maybe when
>> > the browser was built for cygwin this breaks? I have no clue,...
>>
>> It might be simple enough to check if all it takes is to install a
>> prepackaged browser from Cygwin suite and try to run it. Doesn't Cygwin
>> have small ones such as lynx (or links)?
> Was it not the case that Cygwin programs could grok Windows paths, too?
> IIRC w3m is available, dunno about lynx.
> Ciao,
> Dscho
The intention of this patch was to hand over the url to a windows
application.
In cygwin you can use lynx, links and others, but they are not as
smart to use as a browser with a real gui.
Cygwin can't handle windows paths, and this patch will break
cygwin based browsers like links...
My first idea was to patch the git-web--browse.sh script in the section
where the browser is called.
--------
diff --git a/git-web--browse.sh b/git-web--browse.sh
index 78d236b..f726f8f 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -143,7 +143,7 @@ case "$browser" in
vers=$(expr "$($browser_path -version)" : '.* \([0-9][0-9]*\)\..*')
NEWTAB='-new-tab'
test "$vers" -lt 2 && NEWTAB=''
- "$browser_path" $NEWTAB "$@" &
+ "$browser_path" $NEWTAB "`cygpath -w $@`" &
;;
konqueror)
case "$(basename "$browser_path")" in
--------
This solution works for cygwin internal browsers where the posix path
is required and it works for windows apps called out of the cygwin
environment as well.
This is certainely not a proper solution but I've got no other idea
how to solve the problem.
Best regards,
steffen
--
Steffen Jaeckel
Steinbeis-Transferzentrum/Steinbeis-Innovationszentrum
Embedded Design und Networking
an der Berufsakademie Lörrach
Poststraße 35, 79423 Heitersheim
Leiter: Prof. Dr.-Ing. Axel Sikora
Phone: +49 7634 6949341
Mob : +49 170 2328968
Fax : +49 7634 5049886
www.stzedn.de
HINWEIS
Das Steinbeis Transferzentrum Embedded Design und Networking (stzedn)
an der Dualen Hochschule Baden-Württemberg/Berufsakademie Lörrach wird
vom 3.-5.3.2009 auf der Embedded World 2009 in Nürnberg mit einem Stand
vertreten sein. Bitte besuchen Sie uns in Halle 12 Stand 322h.
Zentrale:
Steinbeis GmbH & Co. KG für Technologietransfer
Willi-Bleicher-Straße 19, 70174 Stuttgart
Registergericht Stuttgart HRA 12 480
Komplementär: Steinbeis-Verwaltung-GmbH, Registergericht Stuttgart HRB 18715
Geschäftsführer: Prof. Dr. Heinz Trasch, Prof. Dr. Michael Auer
Der Inhalt dieser E-Mail einschließlich aller Anhänge ist vertraulich und
ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der
vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so
beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung,
Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail unzulässig ist.
Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung
zu setzen, sowie die Originalnachricht zu löschen und alle Kopien hiervon zu
vernichten.
This e-mail message including any attachments is for the sole use of the
intended recipient(s) and may contain privileged or confidential information.
Any unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please immediately contact the sender by reply
e-mail and delete the original message and destroy all copies thereof.
^ permalink raw reply related
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Hannu Koivisto @ 2009-01-22 18:59 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <94a0d4530901220857q1027c05bs137dcc0244a1cc5a@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Thu, Jan 22, 2009 at 6:17 PM, Hannu Koivisto <azure@iki.fi> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> This brings back my previous question: where is the home directory in
>>> a Windows system?
>>
>> It's where %HOMEDRIVE%%HOMEPATH% points to.
>
> I thought it was something like that. Do we want something like that
> in the manual, or should we assume Windows users know that?
I should have added that Unix programs (i.e. Cygwin programs and
even some native ports) probably use %HOME% which may be different
from %HOMEDRIVE%%HOMEPATH%. I recall that if you haven't
explicitly set up HOME in Windows environment, Cygwin sets it up
magically from passwd or falls back to %HOMEDRIVE%%HOMEPATH%. I
have no idea if msysgit respects %HOME% if it is set or always uses
%HOMEDRIVE%%HOMEPATH% or something completely different (user
profile, most likely).
It certainly may be that "home directory" is a foreign concept to
some Windows users. Some might know it as a user profile or a
personal folder (just guessing, I'm pretty isolated from less
experienced Windows users), even though user profile is a separate
concept from "home directory" (note that there is %USERPROFILE%
which by default is the same as %HOMEDRIVE%%HOMEPATH% at least in
XP).
In any case, what Cygwin git does should be expected by Cygwin
users. If msysgit wanted to be a really native Windows application
and store the configuration where Microsoft thinks it should be
stored, it probably shouldn't store the config under "home
directory" to begin with (I'm guessing that's what it does) but
under %USERPROFILE\Application Data\Git (...FILE\Local
Settings\... in case non-roaming storage is wanted). And in that
case the manual might be misleading for msysgit users. See
e.g. <http://msdn.microsoft.com/en-us/library/ms995853.aspx>.
--
Hannu
^ permalink raw reply
* How to prefix existing svn remotes?
From: Sébastien Mazy @ 2009-01-22 17:32 UTC (permalink / raw)
To: git
Hi all,
I created a few months ago a git-svn repository using:
git svn clone -s https://my_svn_repo .
wich also created the following remotes:
git branch -r
branch0
tags/tag0
trunk
I would like to prefix theses remotes, so that it shows:
git branch -r
prefix/branch0
prefix/tags/tag0
prefix/trunk
Of course I should have used the -prefix back when creating the repo but
it's too late. 'git help svn' doesn't explain how to achieve that and
simply editing .git/config to add the missing prefix will cause the next
'git svn fetch' to download again the whole history (which in my case is
huge).
Is it possible? Did I miss something obvious?
Cheers,
--
Sébastien Mazy
^ permalink raw reply
* Re: [PATCH] cygwin: Convert paths for html help from posix to windows
From: Johannes Schindelin @ 2009-01-22 17:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, jaeckel, git
In-Reply-To: <7veiyv6ynm.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 564 bytes --]
Hi,
On Thu, 22 Jan 2009, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > OK, I don't really know if this is the right way to do it. Maybe when
> > the browser was built for cygwin this breaks? I have no clue,...
>
> It might be simple enough to check if all it takes is to install a
> prepackaged browser from Cygwin suite and try to run it. Doesn't Cygwin
> have small ones such as lynx (or links)?
Was it not the case that Cygwin programs could grok Windows paths, too?
IIRC w3m is available, dunno about lynx.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] git-log: Follow file copies with 'git log --follow -C -C'
From: Junio C Hamano @ 2009-01-22 17:28 UTC (permalink / raw)
To: Arjen Laarhoven; +Cc: git
In-Reply-To: <1232642245-94405-2-git-send-email-arjen@yaph.org>
Arjen Laarhoven <arjen@yaph.org> writes:
> When the '--follow' option is used with '--find-copies-harder' ('-C -C')
> logs on individual files will work across file copies as well as
> renames.
Is there a reason to limit this to "harder" case?
> diff --git a/tree-diff.c b/tree-diff.c
> index 9f67af6..73652b2 100644
> --- a/tree-diff.c
> +++ b/tree-diff.c
> @@ -333,6 +333,8 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
>
> diff_setup(&diff_opts);
> DIFF_OPT_SET(&diff_opts, RECURSIVE);
> + if (DIFF_OPT_TST(opt, FIND_COPIES_HARDER))
> + DIFF_OPT_SET(&diff_opts, FIND_COPIES_HARDER);
> diff_opts.detect_rename = DIFF_DETECT_RENAME;
Hmm, why isn't this DIFF_DETECT_COPY?
> diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
> diff_opts.single_follow = opt->paths[0];
> --
> 1.6.1.354.gd9e51
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Johannes Schindelin @ 2009-01-22 17:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, Hannu Koivisto, git
In-Reply-To: <7v1vuv8dqy.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 22 Jan 2009, Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > On Thu, Jan 22, 2009 at 6:17 PM, Hannu Koivisto <azure@iki.fi> wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >>
> >>> This brings back my previous question: where is the home directory in
> >>> a Windows system?
> >>
> >> It's where %HOMEDRIVE%%HOMEPATH% points to.
> >
> > I thought it was something like that. Do we want something like that
> > in the manual, or should we assume Windows users know that?
>
> Funny; while I was test driving Msysgit (I wrote the report in my blog
> pages some time ago), I got curious about this exact issue. I thought the
> choice of $HOME at that path was quite natural even for me who does not
> usually use Windows.
That's what they said when they convinced me that /home/<user>/ was not a
natural place on Windows.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cygwin: Convert paths for html help from posix to windows
From: Junio C Hamano @ 2009-01-22 17:25 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: jaeckel, git
In-Reply-To: <20090122171605.GA16684@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> OK, I don't really know if this is the right way to do it. Maybe when
> the browser was built for cygwin this breaks? I have no clue,...
It might be simple enough to check if all it takes is to install a
prepackaged browser from Cygwin suite and try to run it. Doesn't Cygwin
have small ones such as lynx (or links)?
^ permalink raw reply
* Re: [PATCH] Add --contains flag to git tag
From: Junio C Hamano @ 2009-01-22 17:17 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jake Goulding, git
In-Reply-To: <20090121032058.GG21473@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Tue, Jan 20, 2009 at 08:37:09PM -0500, Jake Goulding <goulding@vivisimo.com> wrote:
>> Please let me know what else I have inevitably messed up, and I shall
>> endeavor to fix and resubmit.
>
> Please document your improvements in Documentation/git-tag.txt and don't
> forget to add a testcase to t7004-tag.sh.
Thanks for saving me time ;-)
^ permalink raw reply
* [PATCH] cygwin: Convert paths for html help from posix to windows
From: Björn Steinbrink @ 2009-01-22 17:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jaeckel, git
When using "git help --web" with cygwin, we used to pass the posix path
to the browser, but a native windows browser will expect a windows path
and is unable to make use of the given path.
So the cygwin port gets its own open_html implementation that handles
the path conversion.
Reported-by: Steffen Jaeckel <jaeckel@stzedn.de>
Tested-by: Steffen Jaeckel <jaeckel@stzedn.de>
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
OK, I don't really know if this is the right way to do it. Maybe when
the browser was built for cygwin this breaks? I have no clue, it's
admittedly just the result of a quick glance at the code and some
googling to find the "right" cygwin function... :-/
compat/cygwin.c | 7 +++++++
compat/cygwin.h | 3 +++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/compat/cygwin.c b/compat/cygwin.c
index ebac148..70ecd2d 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -141,3 +141,10 @@ static int cygwin_lstat_stub(const char *file_name, struct stat *buf)
stat_fn_t cygwin_stat_fn = cygwin_stat_stub;
stat_fn_t cygwin_lstat_fn = cygwin_lstat_stub;
+void cygwin_open_html(const char *unixpath)
+{
+ char cygpath[PATH_MAX];
+
+ cygwin_conv_to_win32_path(unixpath, cygpath);
+ execl_git_cmd("web--browse", "-c", "help.browser", cygpath, NULL);
+}
diff --git a/compat/cygwin.h b/compat/cygwin.h
index a3229f5..7cbefea 100644
--- a/compat/cygwin.h
+++ b/compat/cygwin.h
@@ -7,3 +7,6 @@ extern stat_fn_t cygwin_lstat_fn;
#define stat(path, buf) (*cygwin_stat_fn)(path, buf)
#define lstat(path, buf) (*cygwin_lstat_fn)(path, buf)
+
+void cygwin_open_html(const char *path);
+#define open_html cygwin_open_html
--
1.6.1.230.gf873d
^ permalink raw reply related
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Junio C Hamano @ 2009-01-22 17:14 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Hannu Koivisto, git
In-Reply-To: <94a0d4530901220857q1027c05bs137dcc0244a1cc5a@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Thu, Jan 22, 2009 at 6:17 PM, Hannu Koivisto <azure@iki.fi> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> This brings back my previous question: where is the home directory in
>>> a Windows system?
>>
>> It's where %HOMEDRIVE%%HOMEPATH% points to.
>
> I thought it was something like that. Do we want something like that
> in the manual, or should we assume Windows users know that?
Funny; while I was test driving Msysgit (I wrote the report in my blog
pages some time ago), I got curious about this exact issue. I thought the
choice of $HOME at that path was quite natural even for me who does not
usually use Windows.
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Felipe Contreras @ 2009-01-22 16:57 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: Junio C Hamano, git
In-Reply-To: <831vuvfh7t.fsf@kalahari.s2.org>
On Thu, Jan 22, 2009 at 6:17 PM, Hannu Koivisto <azure@iki.fi> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> This brings back my previous question: where is the home directory in
>> a Windows system?
>
> It's where %HOMEDRIVE%%HOMEPATH% points to.
I thought it was something like that. Do we want something like that
in the manual, or should we assume Windows users know that?
--
Felipe Contreras
^ permalink raw reply
* Re: CR codes from git commands
From: Johannes Schindelin @ 2009-01-22 16:52 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Brent Goodrick, Mike Ralphson, Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0901221117110.19665@iabervon.org>
Hi,
On Thu, 22 Jan 2009, Daniel Barkalow wrote:
> In any case, it's all done in progress.c, so it should be easy enough to
> make changes to if you can come up with something better to do with
> progress messages and some way to determine when it should be done.
Maybe "git --no-progress <program>" would be a sensible user interface?
Ciao,
Dscho
^ permalink raw reply
* Re: CR codes from git commands
From: Johannes Schindelin @ 2009-01-22 16:50 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Brent Goodrick, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <e2b179460901220841h17c9eda2h38e8baff2964dac3@mail.gmail.com>
Hi,
On Thu, 22 Jan 2009, Mike Ralphson wrote:
> My $EDITOR is set to vim, as god intended. 8-)
Sorry, that is not true: from
http://www.biblegateway.com/passage/?book_id=50&chapter=1&verse=1&version=31&context=verse
we know that in the beginning was the Word.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/2] t/t4202-log.sh: Add testcases
From: Arjen Laarhoven @ 2009-01-22 16:37 UTC (permalink / raw)
To: git
Add testcases for 'git log --diff-filter=[CM]' (copies and renames).
Also add a testcase for 'git log --follow'.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
---
t/t4202-log.sh | 59 +++++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 50 insertions(+), 9 deletions(-)
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 0ab925c..7b976ee 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -16,27 +16,31 @@ test_expect_success setup '
test_tick &&
git commit -m second &&
- mkdir a &&
- echo ni >a/two &&
- git add a/two &&
+ git mv one ichi &&
test_tick &&
git commit -m third &&
- echo san >a/three &&
- git add a/three &&
+ cp ichi ein &&
+ git add ein &&
test_tick &&
git commit -m fourth &&
- git rm a/three &&
+ mkdir a &&
+ echo ni >a/two &&
+ git add a/two &&
+ test_tick &&
+ git commit -m fifth &&
+
+ git rm a/two &&
test_tick &&
- git commit -m fifth
+ git commit -m sixth
'
test_expect_success 'diff-filter=A' '
actual=$(git log --pretty="format:%s" --diff-filter=A HEAD) &&
- expect=$(echo fourth ; echo third ; echo initial) &&
+ expect=$(echo fifth ; echo fourth ; echo third ; echo initial) &&
test "$actual" = "$expect" || {
echo Oops
echo "Actual: $actual"
@@ -60,7 +64,43 @@ test_expect_success 'diff-filter=M' '
test_expect_success 'diff-filter=D' '
actual=$(git log --pretty="format:%s" --diff-filter=D HEAD) &&
- expect=$(echo fifth) &&
+ expect=$(echo sixth ; echo third) &&
+ test "$actual" = "$expect" || {
+ echo Oops
+ echo "Actual: $actual"
+ false
+ }
+
+'
+
+test_expect_success 'diff-filter=R' '
+
+ actual=$(git log -M --pretty="format:%s" --diff-filter=R HEAD) &&
+ expect=$(echo third) &&
+ test "$actual" = "$expect" || {
+ echo Oops
+ echo "Actual: $actual"
+ false
+ }
+
+'
+
+test_expect_success 'diff-filter=C' '
+
+ actual=$(git log -C -C --pretty="format:%s" --diff-filter=C HEAD) &&
+ expect=$(echo fourth) &&
+ test "$actual" = "$expect" || {
+ echo Oops
+ echo "Actual: $actual"
+ false
+ }
+
+'
+
+test_expect_success 'git log --follow' '
+
+ actual=$(git log --follow --pretty="format:%s" ichi) &&
+ expect=$(echo third ; echo second ; echo initial) &&
test "$actual" = "$expect" || {
echo Oops
echo "Actual: $actual"
@@ -72,6 +112,7 @@ test_expect_success 'diff-filter=D' '
test_expect_success 'setup case sensitivity tests' '
echo case >one &&
test_tick &&
+ git add one
git commit -a -m Second
'
--
1.6.1.354.gd9e51
^ permalink raw reply related
* [PATCH 2/2] git-log: Follow file copies with 'git log --follow -C -C'
From: Arjen Laarhoven @ 2009-01-22 16:37 UTC (permalink / raw)
To: git
In-Reply-To: <1232642245-94405-1-git-send-email-arjen@yaph.org>
When the '--follow' option is used with '--find-copies-harder' ('-C -C')
logs on individual files will work across file copies as well as
renames.
Intermediate copies will not be shown as a result of the workings of the
'--find-copies-harder' option.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
---
Documentation/git-log.txt | 6 +++++-
t/t4202-log.sh | 12 ++++++++++++
tree-diff.c | 2 ++
3 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 34cf4e5..2d42101 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -52,7 +52,11 @@ include::diff-options.txt[]
commits, and doesn't limit diff for those commits.
--follow::
- Continue listing the history of a file beyond renames.
+ Continue listing the history of a file beyond renames. When
+ combined with `--find-copies-harder` (`-C -C`) git will also
+ list the file history beyond copies. Intermediate copies
+ will be skipped, e.g. a copy of file A to B to C will not
+ show B when showing the log on file C.
--log-size::
Before the log message print out its size in bytes. Intended
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 7b976ee..a8dd690 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -109,6 +109,18 @@ test_expect_success 'git log --follow' '
'
+test_expect_success 'git log --follow --find-copies-harder' '
+
+ actual=$(git log --follow -C -C --pretty="format:%s" ein) &&
+ expect=$(echo fourth; echo third ; echo second ; echo initial) &&
+ test "$actual" = "$expect" || {
+ echo Oops
+ echo "Actual: $actual"
+ false
+ }
+
+'
+
test_expect_success 'setup case sensitivity tests' '
echo case >one &&
test_tick &&
diff --git a/tree-diff.c b/tree-diff.c
index 9f67af6..73652b2 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -333,6 +333,8 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
diff_setup(&diff_opts);
DIFF_OPT_SET(&diff_opts, RECURSIVE);
+ if (DIFF_OPT_TST(opt, FIND_COPIES_HARDER))
+ DIFF_OPT_SET(&diff_opts, FIND_COPIES_HARDER);
diff_opts.detect_rename = DIFF_DETECT_RENAME;
diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
diff_opts.single_follow = opt->paths[0];
--
1.6.1.354.gd9e51
^ permalink raw reply related
* [StGit PATCH 2/2] Make bash completion fail to bashdefault before default completion.
From: Ted Pavlic @ 2009-01-22 16:44 UTC (permalink / raw)
To: catalin.marinas; +Cc: git, Ted Pavlic
In-Reply-To: <4978A0F1.9080703@tedpavlic.com>
If "-o bashdefault" isn't possible, use old "-o default" only.
(this patch inspired by similar mechanism in Mercurial bash completion
script)
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
This patch corrects a bug in the previous one of the same name. In
particular, the second "complete" lacked the "||" in front of it needed
for proper operation. The first complete command should fail over to the
second if "bashdefault" isn't available.
stgit/completion.py | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/stgit/completion.py b/stgit/completion.py
index b3fd282..38f0670 100644
--- a/stgit/completion.py
+++ b/stgit/completion.py
@@ -129,7 +129,8 @@ def main_switch(commands):
'esac')
def install():
- return ['complete -o default -F _stg stg']
+ return ['complete -o bashdefault -o default -F _stg stg 2>/dev/null \\', [
+ '|| complete -o default -F _stg stg' ] ]
def write_completion(f):
commands = stgit.commands.get_commands(allow_cached = False)
--
1.6.1.213.g28da8
^ permalink raw reply related
* Re: CR codes from git commands
From: Daniel Barkalow @ 2009-01-22 16:44 UTC (permalink / raw)
To: Brent Goodrick; +Cc: Mike Ralphson, Junio C Hamano, git
In-Reply-To: <18808.39712.351656.138702@hungover.brentg.com>
On Thu, 22 Jan 2009, Brent Goodrick wrote:
> Mike Ralphson writes:
> > >2009/1/22 Brent Goodrick <bgoodr@gmail.com>:
> > > The environment I'm running git under is the Shell mode inside GNU
> > > Emacs. I can't tell you what type of terminal it is, because I believe
> > > that is defined deep in the guts of Emacs. Having read your reply
> > > above, I'm now wondering whether this is an Emacs issue versus a git
> > > issue. If it is an Emacs issue, then I am truly embarrassed for having
> > > wasted everyones time with it.
> >
> > 2009/1/22 Junio C Hamano <gitster@pobox.com>:
> > > I think we pay attention to "dumb" when deciding if pager is useful and if
> > > we can do color, but I do not think we check anything beyond "is it a tty"
> > > when deciding to show progress or not. The only thing we do differently
> > > for "dumb" terminal is if we use ANSI clear-to-eol escape sequence or fill
> > > with a run of SPs to overwrite trailing part of a line, and we assume even
> > > dumb terminals know how to do a carriage-return.
> >
> > I think this earlier discussion is probably relevant... I'm guessing
> > though, $EDITOR is set correctly here 8-)
>
> I do have EDITOR set to a home-built version of gnuclient, and git
> talks to Emacs by way of that gnuclient just fine when I'm not using the
> -m "commit_message" git-commit option.
>
> >
> > 2008/12/17 Junio C Hamano <gitster@pobox.com>:
> > > Any semi-good emacs users (let alone hackers) export PAGER=cat to be used
> > > in compilation mode (and possibly shell mode), so this is not a problem in
> > > practice.
> > >
> > > I have something like this in my .emacs:
> > >
> > > (setenv "PAGER" "cat")
> > >
> > > I suspect (I am just a user not a hacker) this will have bad interaction
> > > with emacs terminal emulation mode, but I do not use the mode, so it is
> > > enough for me.
>
> I have PAGER set to "cat" in the environment before I run Emacs for
> the same reason.
>
> Unfortunately, this morning when I rebooted and reloaded from scratch,
> I am now unable to reproduce the CR codes output from "git pull" no
> matter what I do. I even tried the older git installed on Debian Linux
> "testing", and tried unsetting PAGER and GIT_PAGER, and saw the pager
> prompts and the terminal escape sequence output as I expected to
> (which is not the issue here). I can't expect anyone else to help me
> debug this problem further if I can't even reproduce it
> anymore. Frustrating.
>
> I do have automatic updates turned on, so perhaps something changed in
> the termcap or how terminal I/O is being done outside of git in my
> system. Emacs would not have changed since I build Emacs from top of
> trunk CVS, and it only uses local Elisp packages AFAIK.
>
> I don't suppose git has any logic that emits the progress messages
> based upon some estimate of amount of work it has to do, or has done,
> does it?
It does have logic to only emit progress messages at a reasonable rate
(otherwise, you might be waiting for the progress messages to be printed
instead of just waiting for the data to arrive). So it's possible that you
now have things going fast enough that it only needs to print one message.
It can also estimate that something hasn't taken long enough for the user
to get impatient yet, and therefore not show progress at all (so the
output won't be littered with progress output for every operation that
could have taken a long time for some data, but didn't for this data).
In any case, it's all done in progress.c, so it should be easy enough to
make changes to if you can come up with something better to do with
progress messages and some way to determine when it should be done.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: CR codes from git commands
From: Mike Ralphson @ 2009-01-22 16:41 UTC (permalink / raw)
To: Brent Goodrick; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <18808.39712.351656.138702@hungover.brentg.com>
2009/1/22 Brent Goodrick <bgoodr@gmail.com>:
> Mike Ralphson writes:
> > I think this earlier discussion is probably relevant... I'm guessing
> > though, $EDITOR is set correctly here 8-)
>
> I do have EDITOR set to a home-built version of gnuclient...
Sorry, I was being too subtle. My $EDITOR is set to vim, as god intended. 8-)
Mike
^ permalink raw reply
* [PATCH] git-describe documentation: --match pattern is glob
From: ecashin @ 2009-01-22 16:21 UTC (permalink / raw)
To: git; +Cc: ecashin
I finally took a few minutes to figure out what kind of pattern
specification the "--match" option to git-describe expects. I
think it would be helpful to mention it explicitly in the manpage
so that trial and error isn't the only recourse for git-describe
users.
It seemed a bit weird to use "torvalds@g5" in the examples,
but I guess it's good to be consistent.
commit 0cbed245ca2812cb7708d9d97a8b5092a8b22b73
Author: Ed L. Cashin <ecashin@coraid.com>
Date: Thu Jan 22 11:09:22 2009 -0500
mention what kind of pattern the --match option expects
It wasn't clear whether the --match option expects a regular
expression or some other kind of pattern specification.
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index a99b4ef..92a7995 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -73,7 +73,8 @@ OPTIONS
--match <pattern>::
Only consider tags matching the given pattern (can be used to avoid
- leaking private tags made from the repository).
+ leaking private tags made from the repository). The pattern
+ syntax is similar to shell globbing.
--always::
Show uniquely abbreviated commit object as fallback.
@@ -117,6 +118,21 @@ closest tagname without any suffix:
[torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
tags/v1.0.0
+When multiple trees are being tracked, --match can specify which tags
+are interesting. I see that a certain commit appeared first in a
+linux-next release, because I am tracking the linux-next tree as a
+remote:
+
+ [torvalds@g5 linux-2.6]$ git describe --contains 9514dff9
+ next-20080623~13^2~72
+
+But since I really want to know the first mainline release containing
+the commit, I use --match to get those results:
+
+ [torvalds@g5 linux-2.6]$ git describe --contains --match 'v*' 9514dff9
+ v2.6.27-rc1~1103^2~85
+
+
SEARCH STRATEGY
---------------
^ permalink raw reply related
* Re: [StGit PATCH 2/2] Make bash completion fail to bashdefault before default completion.
From: Ted Pavlic @ 2009-01-22 16:38 UTC (permalink / raw)
To: Ted Pavlic; +Cc: catalin.marinas, git
In-Reply-To: <1232412373-10836-2-git-send-email-ted@tedpavlic.com>
> def install():
> - return ['complete -o default -F _stg stg']
> + return ['complete -o bashdefault -o default -F _stg stg 2>/dev/null \\', [
> + 'complete -o default -F _stg stg' ] ]
Oops -- that second "complete" should have two pipes in front of it...
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* RE: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Johannes Schindelin @ 2009-01-22 16:31 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302BC6921@emailmn.mqsoftware.com>
Hi,
On Thu, 22 Jan 2009, Kelly F. Hickel wrote:
> I found the section in question, it is:
> -- snip --
> commit refs/heads/TAG.FIXUP
> mark :1000007128
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 88
> This commit was manufactured by cvs2svn to create tag
> 'T_BU_Problem_9xxx_Merge_3-21-2000'.
> merge :1000007126
> M 100755 :180810 mfcdev/Domedit/DlgAddAlias.h
> -- snap --
>
> By my count, 88 is the ending single quote character, leaving the '.' to
> be interpreted as a command.
Great!
> Looks like I should go post this on the cvs2svn list.....
Indeed. I think that Michael will find the culprit very soon, with this
detailed report.
BTW for future reference, please Cc: the people you are responding to.
The Git mailing list is a high volume list, and people will miss you
answers otherwise.
Thanks,
Dscho
^ permalink raw reply
* Re: [StGit PATCH] Added basic bash completion script for StGit.
From: Karl Hasselström @ 2009-01-22 16:18 UTC (permalink / raw)
To: Ted Pavlic; +Cc: catalin.marinas, git
In-Reply-To: <49789A1F.8010203@tedpavlic.com>
On 2009-01-22 11:09:03 -0500, Ted Pavlic wrote:
> The only downside is that it's a little harder to keep track of when
> the completion script changes (e.g., when you have made your own
> local changes).
It's a generated file -- you're not supposed to edit it! Wouldn't it
be a better idea to edit the program that generates it instead?
> However, the method you use provides very *fast* completion (as
> opposed to git and hg completion, which generate their keywords on
> the fly and thus run relatively slowly).
Yes, I was always irritated by how slow the StGit completion was
compared to git's. Python sucks in this respect.
> HOWEVER, please see the threads (which modify the Python that
> generates the script):
Yes, I'll take a look.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Hannu Koivisto @ 2009-01-22 16:17 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git
In-Reply-To: <94a0d4530901211319t8126611wc1437848631fe988@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> This brings back my previous question: where is the home directory in
> a Windows system?
It's where %HOMEDRIVE%%HOMEPATH% points to.
--
Hannu
^ 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