* [PATCH/RFC] git-am: Make it easier to see which patch failed
From: Jonas Flodén @ 2009-01-16 13:18 UTC (permalink / raw)
To: git
When git-am fails it's not always easy to see which patch failed,
since it's often hidden by a lot of error messages.
Add an extra line which prints the name of the failed patch just
before the resolve message to make it easier to find.
Signed-off-by: Jonas Flodén <jonas@floden.nu>
---
This is something I have thought about for a long time.
I always wonder why git rebase couldn't print the patch
name when it failed... Finally I took the time to fix it.
Please feel free to comment. It's my first Git patch...
With regards,
Jonas
git-am.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 4b157fe..5d72a66 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -502,6 +502,7 @@ do
if test $apply_status != 0
then
echo Patch failed at $msgnum.
+ printf '\nFailed to apply: %s\n' "$FIRSTLINE"
stop_here_user_resolve $this
fi
--
1.6.1.28.gc32f76
^ permalink raw reply related
* Re: [PATCH] revision walker: include a detached HEAD in --all
From: David Kastrup @ 2009-01-16 13:22 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0901161415230.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 16 Jan 2009, Santi Béjar wrote:
>
>> 2009/1/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> >
>> > Note that this affects creating bundles with --all; I contend that it
>> > is a good change to add the HEAD, so that cloning from such a bundle
>> > will give you a current branch. However, I had to fix t5701 as it
>> > assumed that --all does not imply HEAD.
>>
>> From the description I understand that it only affects when the HEAD is
>> detached, but in t5701 the HEAD is not detached so nothing should be
>> fixed.
>
> The error in t5701 was that it _wanted_ to test a bundle without a HEAD,
> but it actually created it with --all. That was implying that --all does
> not mean HEAD, and I disagree with that.
I don't think that a detached HEAD should be a special case, since you
can have other detached symbolic references no longer on a branch. None
of those should be garbage-collected either, I think.
--
David Kastrup
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: SZEDER Gábor @ 2009-01-16 13:27 UTC (permalink / raw)
To: Johannes Schindelin
Cc: SZEDER Gábor, Johan Herland, Anders Melchiorsen, git,
Jay Soffian, Wincent Colaiuta, Junio C Hamano, Sverre Rabbelier,
Johannes Sixt
In-Reply-To: <alpine.DEB.1.00.0901161357230.3586@pacific.mpi-cbg.de>
On Fri, Jan 16, 2009 at 01:57:57PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 16 Jan 2009, SZEDER Gábor wrote:
>
> > On Fri, Jan 16, 2009 at 11:58:06AM +0100, Johan Herland wrote:
> >
> > > "rephrase"?
> >
> > This is the first one that I found acceptable.
>
> I assume you missed
> http://article.gmane.org/gmane.comp.version-control.git/105783 in all that
> bikeshedding?
Yes, I indeed missed that. And still think that 'rephrase' is best
among all the suggestions for this "edit just the commit message"
thing. ('editmsg' conflicts; 'amend', 'modify', and 'correct' are
not obvious enough (they don't clearly indicate what will be
modified); and I'm not sure about 'redact', but I don't really like it
because I had to look it up in the dictionary first).
Best,
Gábor
^ permalink raw reply
* Re: [BUG] assertion failure in builtin-mv.c with "git mv -k"
From: Matthieu Moy @ 2009-01-16 12:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, git
In-Reply-To: <7vr634qkjn.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> I'm happy to follow any variant ("1+2+3", "1 2+3", "1 2 3", in
>> increasing order of preference) so there's no need to discuss or explain
>> this further, just tell me "do x" ;)
>
> Do nothing ;-) Your 1=3772923 and 2+3=be17262d are already in and we can
> include the fix in the next 1.6.1.X maintenance release.
Thanks!
--
Matthieu
^ permalink raw reply
* Re: [PATCH] revision walker: include a detached HEAD in --all
From: Santi Béjar @ 2009-01-16 13:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Thomas Rast, Johannes Sixt, git
In-Reply-To: <adf1fd3d0901160546o50db0594h7377774fed9fef99@mail.gmail.com>
2009/1/16 Santi Béjar <santi@agolina.net>:
> 2009/1/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> Hi,
>>
>> On Fri, 16 Jan 2009, Santi Béjar wrote:
>>
>>> 2009/1/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>> >
>>> > Note that this affects creating bundles with --all; I contend that it
>>> > is a good change to add the HEAD, so that cloning from such a bundle
>>> > will give you a current branch. However, I had to fix t5701 as it
>>> > assumed that --all does not imply HEAD.
>>>
>>> From the description I understand that it only affects when the HEAD is
>>> detached, but in t5701 the HEAD is not detached so nothing should be
>>> fixed.
>>
>> The error in t5701 was that it _wanted_ to test a bundle without a HEAD,
>> but it actually created it with --all. That was implying that --all does
>> not mean HEAD
>
> Yes, that is the current behaviour.
>
>> , and I disagree with that.
>
> I know you disagree, but in the commit log you said:
>
> ---
> [PATCH] revision walker: include a detached HEAD in --all
>
> When HEAD is detached, --all should list it, too, logically, as a
> detached HEAD is by definition a temporary, unnamed branch.
> ---
>
> so nothing talks about changing the behaviour when the HEAD is not detached.
>
> But the problem with t5701 is another thing. If you run this:
>
> git init
> : >file
> git add .
> git commit -m1
> git bundle create b1.bundle --all HEAD
> git ls-remote b1.bundle
> git rev-parse --all HEAD
>
> you will see that the same rev-parse parameters in "git bundle"
> produce tree lines while with "git rev-parse" only two are produced.
>
Sorry, there are two problems with t5701, the one of the changing
behaviour of the --all flag and this one.
Santi
^ permalink raw reply
* Re: [PATCH] revision walker: include a detached HEAD in --all
From: Santi Béjar @ 2009-01-16 13:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Thomas Rast, Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0901161415230.3586@pacific.mpi-cbg.de>
2009/1/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Fri, 16 Jan 2009, Santi Béjar wrote:
>
>> 2009/1/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> >
>> > Note that this affects creating bundles with --all; I contend that it
>> > is a good change to add the HEAD, so that cloning from such a bundle
>> > will give you a current branch. However, I had to fix t5701 as it
>> > assumed that --all does not imply HEAD.
>>
>> From the description I understand that it only affects when the HEAD is
>> detached, but in t5701 the HEAD is not detached so nothing should be
>> fixed.
>
> The error in t5701 was that it _wanted_ to test a bundle without a HEAD,
> but it actually created it with --all. That was implying that --all does
> not mean HEAD
Yes, that is the current behaviour.
> , and I disagree with that.
I know you disagree, but in the commit log you said:
---
[PATCH] revision walker: include a detached HEAD in --all
When HEAD is detached, --all should list it, too, logically, as a
detached HEAD is by definition a temporary, unnamed branch.
---
so nothing talks about changing the behaviour when the HEAD is not detached.
But the problem with t5701 is another thing. If you run this:
git init
: >file
git add .
git commit -m1
git bundle create b1.bundle --all HEAD
git ls-remote b1.bundle
git rev-parse --all HEAD
you will see that the same rev-parse parameters in "git bundle"
produce tree lines while with "git rev-parse" only two are produced.
>
>> For gc for sure it is a good thing, but I'm not convinced of the others,
>> as a detached HEAD is a very special thing (temporary and unnamed
>> branch).
>
> So? What does "--all" mean? All branches or what? :-)
>
> Seriously, I think that --all should imply HEAD at all times, as the only
> time when it makes a difference is when you have that unnamed _branch_
> that is a detached HEAD.
>
> Maybe I would be more amenable to your criticism if you could come up with
> a scenario where implying HEAD with --all is _wrong_.
I don't think it is plainly wrong. I think both makes sense, but I
think it is not a good idea to change the behaviour now as some
scripts may rely on it.
Santi
^ permalink raw reply
* Re: [PATCH/RFC] git-am: Make it easier to see which patch failed
From: Johannes Schindelin @ 2009-01-16 14:14 UTC (permalink / raw)
To: Jonas Flodén; +Cc: git
In-Reply-To: <636ecac0901160518o16706bbia9acaf09fdf92946@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 286 bytes --]
Hi,
On Fri, 16 Jan 2009, Jonas Flodén wrote:
> then
> echo Patch failed at $msgnum.
> + printf '\nFailed to apply: %s\n' "$FIRSTLINE"
> stop_here_user_resolve $this
Maybe
- echo Patch failed at $msgnum.
+ echo Patch failed at $msgnum($FIRSTLINE).
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Wincent Colaiuta @ 2009-01-16 14:28 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Johannes Schindelin, Johan Herland, Anders Melchiorsen, git,
Jay Soffian, Junio C Hamano, Sverre Rabbelier, Johannes Sixt
In-Reply-To: <20090116132714.GN9794@neumann>
El 16/1/2009, a las 14:27, SZEDER Gábor escribió:
> On Fri, Jan 16, 2009 at 01:57:57PM +0100, Johannes Schindelin wrote:
>> Hi,
>>
>> On Fri, 16 Jan 2009, SZEDER Gábor wrote:
>>
>>> On Fri, Jan 16, 2009 at 11:58:06AM +0100, Johan Herland wrote:
>>>
>>>> "rephrase"?
>>>
>>> This is the first one that I found acceptable.
>>
>> I assume you missed
>> http://article.gmane.org/gmane.comp.version-control.git/105783 in
>> all that
>> bikeshedding?
>
> Yes, I indeed missed that. And still think that 'rephrase' is best
> among all the suggestions for this "edit just the commit message"
> thing. ('editmsg' conflicts; 'amend', 'modify', and 'correct' are
> not obvious enough (they don't clearly indicate what will be
> modified); and I'm not sure about 'redact', but I don't really like it
> because I had to look it up in the dictionary first).
Two more colors for consideration:
- "msg"/"msgedit"/"message" or similar
- "reword"
I agree with Gábor that options like "modify" aren't clear because
there's nothing in them that suggests that they're intended to operate
on the commit _message_.
Wincent
^ permalink raw reply
* [PATCH/RFC] git-am: Make it easier to see which patch failed
From: Jonas Flodén @ 2009-01-16 14:34 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <alpine.DEB.1.00.0901161513400.3586@pacific.mpi-cbg.de>
When git-am fails it's not always easy to see which patch failed,
since it's often hidden by a lot of error messages.
Add an extra line which prints the name of the failed patch just
before the resolve message to make it easier to find.
Signed-off-by: Jonas Flodén <jonas@floden.nu>
---
Johannes Schindelin wrote:
> Maybe
>
> - echo Patch failed at $msgnum.
> + echo Patch failed at $msgnum($FIRSTLINE).
How about this instead. Though the line could get very long.
This makes the line stand out a little more.
git-am.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 4b157fe..09c2f9c 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -501,7 +501,7 @@ do
fi
if test $apply_status != 0
then
- echo Patch failed at $msgnum.
+ printf '\nPatch failed at %s (%s)\n' "$msgnum" "$FIRSTLINE"
stop_here_user_resolve $this
fi
--
1.6.1.28.gc32f76
^ permalink raw reply related
* Re: [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors can recognize, it as a bash script. Also adds a few simple comments above commands that, take arguments. The comments are meant to remind editors of potential, problems that
From: Baz @ 2009-01-16 15:06 UTC (permalink / raw)
To: markus.heidelberg
Cc: Adeodato Simó, Boyd Stephen Smith Jr., Shawn O. Pearce,
Ted Pavlic, git, Junio C Hamano
2009/1/15 Markus Heidelberg <markus.heidelberg@web.de>:
> Adeodato Simó, 13.01.2009:
>> * Boyd Stephen Smith Jr. [Tue, 13 Jan 2009 14:03:11 -0600]:
>>
>> > On Tuesday 2009 January 13 10:45:18 Shawn O. Pearce wrote:
>> > >See [...] how the subject is a niceshort, one
>> > >line summary of the module impacted and the change?
>>
>> > My rule for this is absolutely no more than 80 characters.
>>
>> My rule for *all* of the commit message is "absolutely no more than 76
>> characters". With more than 76, `git log` wraps in a 80-column terminal.
>
> What about the 50 character limit proposed in the documentation
> (git-commit, gittutorial, user-manual)?
>
> At the beginning I tried to fulfil this limit, but often it's not easy.
> So should it be adjusted to a slightly higher value in the documentation
> or even split into a recommended limit (e.g. 50) and a recommended
> absolute maximum (e.g. 76)? Hmm, the split wouldn't make sense, I think.
The 50 character limit is for the first line, try "git log
--pretty=oneline" and it should be obvious why.
The rest of the lines can be longer, 72 is another popular choice.
I'm wondering if the default commit-msg hook should have something like:
perl -ne '$lim = (50,0,72)[($.>3?3:$.)-1];
chomp;
if (length($_) > $lim) {
print STDERR "Line $. of commit message exceeded $lim
characters";
exit 1;
}' $1
to more forcefully suggest what's in the manual, like the pre-commit hook does.
(I wish I'd had something like this when one of the devs here pushed a
commit with a 346-line message,
just listing what files he was changing...doh)
-Baz
>
> Markus
>
> --
> 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
* [RFC PATCH] Fix gitdir detection when in subdir of gitdir
From: SZEDER Gábor @ 2009-01-16 15:37 UTC (permalink / raw)
To: git; +Cc: SZEDER Gábor
If the current working directory is a subdirectory of the gitdir (e.g.
<repo>/.git/refs/), then setup_git_directory_gently() will climb its
parent directories until it finds itself in a gitdir. However, no
matter how many parent directories it climbs, it sets
'GIT_DIR_ENVIRONMENT' to ".", which is obviously wrong.
This behaviour affected at least 'git rev-parse --git-dir' and hence
caused some errors in bash completion (e.g. customized command prompt
when on a detached head and completion of refs).
To fix this, we set the absolute path of the found gitdir instead.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
I'm not sure about setting an absolut path instead of a relative one
(hence the RFC), although I think it should not make any difference.
Of course I could have count the number of chdir("..") calls and then
construct a "../../..", but that would have been more intrusive than
this two-liner.
setup.c | 3 ++-
t/t1501-worktree.sh | 7 +++++++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/setup.c b/setup.c
index 6b277b6..b787a54 100644
--- a/setup.c
+++ b/setup.c
@@ -456,7 +456,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
inside_git_dir = 1;
if (!work_tree_env)
inside_work_tree = 0;
- setenv(GIT_DIR_ENVIRONMENT, ".", 1);
+ cwd[offset] = '\0';
+ setenv(GIT_DIR_ENVIRONMENT, cwd, 1);
check_repository_format_gently(nongit_ok);
return NULL;
}
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index f6a6f83..27dc6c5 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -92,6 +92,13 @@ cd sub/dir || exit 1
test_rev_parse 'in repo.git/sub/dir' false true true sub/dir/
cd ../../../.. || exit 1
+test_expect_success 'detecting gitdir when cwd is in a subdir of gitdir' '
+ (expected=$(pwd)/repo.git &&
+ cd repo.git/refs &&
+ unset GIT_DIR &&
+ test "$expected" = "$(git rev-parse --git-dir)")
+'
+
test_expect_success 'repo finds its work tree' '
(cd repo.git &&
: > work/sub/dir/untracked &&
--
1.6.1.153.g15508
^ permalink raw reply related
* [PATCH 2/5] bash: removed unnecessary checks for long options with argument
From: SZEDER Gábor @ 2009-01-16 16:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
__gitcomp takes care of it since 5447aac7 (bash: fix long option with
argument double completion, 2008-03-05)
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 4292b23..c35f86d 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -643,7 +643,6 @@ _git_branch ()
done
case "${COMP_WORDS[COMP_CWORD]}" in
- --*=*) COMPREPLY=() ;;
--*)
__gitcomp "
--color --no-color --verbose --abbrev= --no-abbrev
@@ -1692,7 +1691,6 @@ _git ()
if [ -z "$command" ]; then
case "${COMP_WORDS[COMP_CWORD]}" in
- --*=*) COMPREPLY=() ;;
--*) __gitcomp "
--paginate
--no-pager
--
1.6.1.198.geb475f
^ permalink raw reply related
* [PATCH 3/5] bash: add missing format-patch command line options
From: SZEDER Gábor @ 2009-01-16 16:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c35f86d..fc16aaa 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -838,6 +838,8 @@ _git_format_patch ()
--not --all
--cover-letter
--no-prefix --src-prefix= --dst-prefix=
+ --inline --suffix= --ignore-if-in-upstream
+ --subject-prefix=
"
return
;;
--
1.6.1.198.geb475f
^ permalink raw reply related
* [PATCH 5/5] bash: refactor 'git log --pretty=<format>' options
From: SZEDER Gábor @ 2009-01-16 16:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
Both 'git log' and 'show' have the same '--pretty=<format>' option
with the same formats. So refactor these formats into a common
variable.
While at it, also add 'format:' to the list.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 3a26d2b..b5b40c2 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -947,6 +947,8 @@ _git_ls_tree ()
__git_complete_file
}
+__git_log_pretty_formats="oneline short medium full fuller email raw format:"
+
_git_log ()
{
__git_has_doubledash && return
@@ -954,8 +956,7 @@ _git_log ()
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--pretty=*)
- __gitcomp "
- oneline short medium full fuller email raw
+ __gitcomp "$__git_log_pretty_formats
" "" "${cur##--pretty=}"
return
;;
@@ -1487,8 +1488,7 @@ _git_show ()
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--pretty=*)
- __gitcomp "
- oneline short medium full fuller email raw
+ __gitcomp "$__git_log_pretty_formats
" "" "${cur##--pretty=}"
return
;;
--
1.6.1.198.geb475f
^ permalink raw reply related
* Re: [PATCH 2/5] bash: removed unnecessary checks for long options with argument
From: SZEDER Gábor @ 2009-01-16 16:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1232121717-10145-1-git-send-email-szeder@ira.uka.de>
Oh, I have run 'git format-patch master.. && rm
patches-i-dont-want-to-submit-yet' and haven't noticed that
'format-patch' autonumbered the patches. So, there are only three
patches: 2, 3, 5.
Gábor
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Boyd Stephen Smith Jr. @ 2009-01-16 16:11 UTC (permalink / raw)
To: Santi Béjar
Cc: Johannes Schindelin, Junio C Hamano, Teemu Likonen, Thomas Rast,
git
In-Reply-To: <adf1fd3d0901160102y32a08e26q96728495fc0b6fcf@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]
On Friday 2009 January 16 03:02:33 Santi Béjar wrote:
> 2009/1/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> Hi,
>>
>> On Fri, 16 Jan 2009, Santi Béjar wrote:
>>> If everything works as I think (it's late night :-) with the above two
>>> lines:
>>>
>>> matrix[a,b,c]
>>> matrix{d,b,c}
>>>
>>> the word diff would be
>>>
>>> matrix<RED>[<GREEN>{<RED>a<GREEN>d<RESET>,b,c<RED>]<GREEN>}<RED>
>
>So, I see, it is a matter of finding the right regexp.
>
>But the only use case for me is of this kind, and I think for the
>others too. So maybe an easier way to specify it could be worth. But
>I'll write an alias as this is the only regexp I would use, apart from
>the default word diff.
I think that the C/C++ language word-diff driver would work here, and there
should be a shortcut for that.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] git-am: Make it easier to see which patch failed
From: Johannes Schindelin @ 2009-01-16 16:27 UTC (permalink / raw)
To: Jonas Flodén; +Cc: git
In-Reply-To: <636ecac0901160634r586c72a0r9bb63c6f019f5bff@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 341 bytes --]
Hi,
On Fri, 16 Jan 2009, Jonas Flodén wrote:
> Johannes Schindelin wrote:
> > Maybe
> >
> > - echo Patch failed at $msgnum.
> > + echo Patch failed at $msgnum($FIRSTLINE).
>
> How about this instead. Though the line could get very long.
> This makes the line stand out a little more.
Fine by me!
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Fix gitdir detection when in subdir of gitdir
From: Johannes Schindelin @ 2009-01-16 16:29 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <1232120253-1551-1-git-send-email-szeder@ira.uka.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 524 bytes --]
Hi,
On Fri, 16 Jan 2009, SZEDER Gábor wrote:
> I'm not sure about setting an absolut path instead of a relative one
> (hence the RFC), although I think it should not make any difference.
> Of course I could have count the number of chdir("..") calls and then
> construct a "../../..", but that would have been more intrusive than
> this two-liner.
IIRC the absolute paths were shot down already... for performance reasons.
So we try very hard to keep relative paths instead of absolute ones.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Fix gitdir detection when in subdir of gitdir
From: Johannes Sixt @ 2009-01-16 16:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: SZEDER Gábor, git
In-Reply-To: <alpine.DEB.1.00.0901161729070.3586@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
> Hi,
>
> On Fri, 16 Jan 2009, SZEDER Gábor wrote:
>
>> I'm not sure about setting an absolut path instead of a relative one
>> (hence the RFC), although I think it should not make any difference.
>> Of course I could have count the number of chdir("..") calls and then
>> construct a "../../..", but that would have been more intrusive than
>> this two-liner.
>
> IIRC the absolute paths were shot down already... for performance reasons.
>
> So we try very hard to keep relative paths instead of absolute ones.
This is a different matter.
The question is basically: How should git behave if $PWD is inside a bare
repository? And if you are inside .git/refs, than for git this looks as if
it were a bare repository.
The current behavior is that we chdir() up into .git, but do not set a
prefix. Nor do we chdir() back where we started after the discovery.
Gábor's patch needs a better justification which misbehavior it tries to
fix, and the spot that it changes:
if (is_git_directory(".")) {
inside_git_dir = 1;
if (!work_tree_env)
inside_work_tree = 0;
setenv(GIT_DIR_ENVIRONMENT, ".", 1);
check_repository_format_gently(nongit_ok);
return NULL;
}
needs a comment why it does what it does (and that this if-branch is only
about bare repositories).
-- Hannes
^ permalink raw reply
* Confusing text in git-prune.txt
From: Adeodato Simó @ 2009-01-16 16:50 UTC (permalink / raw)
To: git
From git-prune.txt:
[...] prunes all unpacked objects unreachable from any of
these head objects from the object database. In addition,
it prunes the unpacked objects that are also found in packs by
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
running git-prune-packed.
How can "unpacked objects" be "found in packs"? Maybe the first
"unpacked" should be "unreachable". But if that's the case, wouldn't
this be better:
[...] prunes from the object database all objects unreachable from
any of these heads. Prunning already-packed objects is done with
the help of git-prune-packed.
Thoughts? Or am I reading the original text wrong?
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
I promise you. Once I enter into an exclusive relationship, I sleep with
very few people.
-- Denny Crane
^ permalink raw reply
* Re: [RFC PATCH] Fix gitdir detection when in subdir of gitdir
From: Johannes Sixt @ 2009-01-16 16:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: SZEDER Gábor, git
In-Reply-To: <4970BA2B.7090807@viscovery.net>
Johannes Sixt schrieb:
> Gábor's patch needs a better justification which misbehavior it tries to
> fix, and the spot that it changes:
I actually meant: "which use-case the patch tries to help". Because the
current behavior can hardly be classified as bug. ("You have no business
cd-ing around in .git." ;)
-- Hannes
^ permalink raw reply
* Re: Confusing text in git-prune.txt
From: Johannes Sixt @ 2009-01-16 16:56 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git
In-Reply-To: <20090116165013.GA14196@chistera.yi.org>
Adeodato Simó schrieb:
> From git-prune.txt:
>
> [...] prunes all unpacked objects unreachable from any of
> these head objects from the object database. In addition,
> it prunes the unpacked objects that are also found in packs by
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> running git-prune-packed.
>
> How can "unpacked objects" be "found in packs"?
An object can exist more than once in the database. prune-packed removes
the loose (unpacked) instance of the object if it also available in a pack.
-- Hannes
^ permalink raw reply
* Re: Confusing text in git-prune.txt
From: Adeodato Simó @ 2009-01-16 17:02 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4970BC25.7020007@viscovery.net>
* Johannes Sixt [Fri, 16 Jan 2009 17:56:05 +0100]:
> Adeodato Simó schrieb:
> > From git-prune.txt:
> > [...] prunes all unpacked objects unreachable from any of
> > these head objects from the object database. In addition,
> > it prunes the unpacked objects that are also found in packs by
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > running git-prune-packed.
> > How can "unpacked objects" be "found in packs"?
> An object can exist more than once in the database. prune-packed removes
> the loose (unpacked) instance of the object if it also available in a pack.
Ah, thanks, that explains everything.
I read the manpage for git-prune-unpacked, but I didn't manage to figure
it out. It may have helped if instead of saying:
git-prune-packed - Remove extra objects that are already in pack files
it would have said:
git-prune-packed - Remove loose objects that are already in pack files
^^^^^
By stating that those objects are "extra", we're losing the information
of where are they. And by reading that synopsis, one can already infer
they are "extra".
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Radiohead - Bodysnatchers
^ permalink raw reply
* Re: [PATCH 5/5] bash: refactor 'git log --pretty=<format>' options
From: Shawn O. Pearce @ 2009-01-16 17:18 UTC (permalink / raw)
To: SZEDER Gábor, Junio C Hamano; +Cc: git
In-Reply-To: <1232121735-10239-1-git-send-email-szeder@ira.uka.de>
SZEDER Gábor <szeder@ira.uka.de> wrote:
> Both 'git log' and 'show' have the same '--pretty=<format>' option
> with the same formats. So refactor these formats into a common
> variable.
>
> While at it, also add 'format:' to the list.
>
> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
For all 3 patches in the series:
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Thanks.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH] Fix gitdir detection when in subdir of gitdir
From: SZEDER Gábor @ 2009-01-16 17:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git
In-Reply-To: <4970BAE5.8080006@viscovery.net>
On Fri, Jan 16, 2009 at 05:50:45PM +0100, Johannes Sixt wrote:
> Johannes Sixt schrieb:
> > Gábor's patch needs a better justification which misbehavior it tries to
> > fix, and the spot that it changes:
>
> I actually meant: "which use-case the patch tries to help". Because the
> current behavior can hardly be classified as bug. ("You have no business
> cd-ing around in .git." ;)
I agree that fiddling around in '.git' is a quite rare use case.
I did it while I was working on bash completion support for the
upcoming 'git sequencer' to see where it stores its temporary files
and what is in those files. And I got errors from the completion
script after each executed command, which quickly made me upset enough
to look after it.
I thought it worths fixing, but it's even better if it's not a bug,
because then I don't have to fix my fix (;
Regards,
Gábor
^ 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