* Re: [PATCH take 3 0/4] color-words improvements
From: Santi Béjar @ 2009-01-16 12:01 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Boyd Stephen Smith Jr., Teemu Likonen,
Thomas Rast, git
In-Reply-To: <adf1fd3d0901160102y32a08e26q96728495fc0b6fcf@mail.gmail.com>
Hi,
can you both provide a public repository to be able to test the
lastest version without having to search and apply them?
Thanks,
Santi
P.D.: I know it will be rebased.
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johannes Schindelin @ 2009-01-16 12:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: SZEDER Gábor, Sverre Rabbelier, Anders Melchiorsen, git
In-Reply-To: <7v3afkqcnt.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 15 Jan 2009, Junio C Hamano wrote:
> (2) making completely unrelated commits on top of the state "edit" gave
> you; this inserts a new commit in the sequence.
>
> (3) first "reset HEAD^", commit selected parts of the difference in one
> commit, commit the reaminder in another commit; this splits the
> commit the machinery just picked into two.
>
> By the way, "rebase --continue" codepath has extra code that does
> something magical when the index does not match the HEAD commit. I
> suspect what it does makes sense only in the originally intended usage
> sequence (i.e. "edit" stops, you want to do "commit --amend" and then
> "rebase --continue" but somehow you forgot to commit everything).
>
> How well does that logic work when the user wanted to do (2) or (3) above,
> and happened to have the index unclean when s/he said "rebase --continue"?
> Does it do something nonsensical?
AFAICT the special handling is the only sane way to cope with (2) and (3),
if it is the special handling that I am talking about:
If the current HEAD differs with the HEAD just after dropping to the
shell, rebase --continue will _not_ just commit with the recorded
information and continue.
The intended effect is that when you split a commit and continue with
uncommitted changes, it will not just go ahead and call an editor with the
original commit message: this message is now likely wrong.
It will only call an editor with the original message as a convenience
when you did changes, but did not commit at all before continuing. Just a
convenience I found quite useful.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-16 12:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7vocy8s51o.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 15 Jan 2009, Junio C Hamano wrote:
> I do not see a reason to limit the new notation "where I was" only to
> "git checkout". Wouldn't it be handy if you can use the notation as the
> other branch to merge from, or the commit to rebase on?
>
> [...]
>
> Another reason is the one level limitation. If we do not use LAST_HEAD,
> and instead used HEAD reflog, to get to this information, there is no
> reason we cannot to give an equally easy access to the second from the
> last branch the user was on.
>
> So I think it is just the matter of coming up with a clever syntax that
> works on reflogs to name the nth last branch we were on and teach that
> syntax to both get_sha1() and resolve_ref().
>
> With the attached illustration patch,
>
> $ git checkout junk
> $ git chekcout master
> $ git checkout @{-1}
>
> will take you back to junk branch. It probably would serve as a starting
> point, if anybody is interested.
I like it. Additionaly, we could teach "checkout" that "-" is
equivalent to "@{-1}", as checkout cannot possibly take stdin, so
it would not hurt. Thomas?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Johannes Schindelin @ 2009-01-16 12:40 UTC (permalink / raw)
To: Santi Béjar
Cc: Junio C Hamano, Boyd Stephen Smith Jr., Teemu Likonen,
Thomas Rast, git
In-Reply-To: <adf1fd3d0901160401s7a363076x1bcd8e90db4f56a1@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 261 bytes --]
Hi,
On Fri, 16 Jan 2009, Santi Béjar wrote:
> can you both provide a public repository to be able to test the
> lastest version without having to search and apply them?
You will always find my latest version in git://repo.or.cz/git/dscho.git.
Hth,
Dscho
^ 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 12:42 UTC (permalink / raw)
To: Johan Herland
Cc: Anders Melchiorsen, git, Jay Soffian, Wincent Colaiuta,
Johannes Schindelin, Junio C Hamano, Sverre Rabbelier,
Johannes Sixt
In-Reply-To: <200901161158.06828.johan@herland.net>
On Fri, Jan 16, 2009 at 11:58:06AM +0100, Johan Herland wrote:
> On Friday 16 January 2009, Anders Melchiorsen wrote:
> > Johan Herland wrote:
> > > amend e8902c1 Foo
> > >
> > > does a "pick" followed by "commit --amend" (for editing the commit
> > > message), followed by "rebase --continue".
> >
> > I do not think that "amend" is the best word for editing only the
> > commit message. A "commit --amend" can also make a new tree, so
> > reusing the word with a different meaning could be bad.
> >
> > As for alternatives, however, I can only come up with "copyedit", and
> > that is so horrible that I will not even propose it :-)
>
> "rephrase"?
This is the first one that I found acceptable.
'amend', 'modify' and 'edit' are just too close and non-intuitive:
they don't indicate _what_ will be amended, modified or edited at all.
'rephrase', on the other hand, is better, as you can rephrase a commit
message, but it's weird to say "rephrase the patch". But it's still
not as to-the-point as 'editmsg' (but that one has conflicting
abbreviation).
Best,
Gábor
^ permalink raw reply
* [PATCH] revision walker: include a detached HEAD in --all
From: Johannes Schindelin @ 2009-01-16 12:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Johannes Sixt, git
In-Reply-To: <7vhc40s50t.fsf@gitster.siamese.dyndns.org>
When HEAD is detached, --all should list it, too, logically, as a
detached HEAD is by definition a temporary, unnamed branch.
It is especially necessary to list it when garbage collecting, as
the detached HEAD would be trashed.
Noticed by Thomas Rast.
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.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Thu, 15 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Thu, 15 Jan 2009, Johannes Schindelin wrote:
> >
> >> [PATCH] pack-objects --all: include HEAD, which could be
> >> detached
> >
> > In hind sight, it would probably be better to add this to
> > revision.c.
>
> If you mean that "git log --all" should also include a possibly
> detached HEAD in its traversal, and a patch that implements such a fix
> would automatically fix "repack -a" without the patch you are
> responding to, I think I agree 100%.
Here it is. (Sorry for the delay, it was due to some
well-deserved inebriation.)
revision.c | 1 +
t/t5701-clone-local.sh | 4 ++--
t/t6014-rev-list-all.sh | 38 ++++++++++++++++++++++++++++++++++++++
3 files changed, 41 insertions(+), 2 deletions(-)
create mode 100755 t/t6014-rev-list-all.sh
diff --git a/revision.c b/revision.c
index db60f06..b065184 100644
--- a/revision.c
+++ b/revision.c
@@ -1263,6 +1263,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
if (!strcmp(arg, "--all")) {
handle_refs(revs, flags, for_each_ref);
+ handle_refs(revs, flags, head_ref);
continue;
}
if (!strcmp(arg, "--branches")) {
diff --git a/t/t5701-clone-local.sh b/t/t5701-clone-local.sh
index 8dfaaa4..14413f8 100755
--- a/t/t5701-clone-local.sh
+++ b/t/t5701-clone-local.sh
@@ -11,8 +11,8 @@ test_expect_success 'preparing origin repository' '
git clone --bare . x &&
test "$(GIT_CONFIG=a.git/config git config --bool core.bare)" = true &&
test "$(GIT_CONFIG=x/config git config --bool core.bare)" = true
- git bundle create b1.bundle --all HEAD &&
- git bundle create b2.bundle --all &&
+ git bundle create b1.bundle master HEAD &&
+ git bundle create b2.bundle master &&
mkdir dir &&
cp b1.bundle dir/b3
cp b1.bundle b4
diff --git a/t/t6014-rev-list-all.sh b/t/t6014-rev-list-all.sh
new file mode 100755
index 0000000..991ab4a
--- /dev/null
+++ b/t/t6014-rev-list-all.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+
+test_description='--all includes detached HEADs'
+
+. ./test-lib.sh
+
+
+commit () {
+ test_tick &&
+ echo $1 > foo &&
+ git add foo &&
+ git commit -m "$1"
+}
+
+test_expect_success 'setup' '
+
+ commit one &&
+ commit two &&
+ git checkout HEAD^ &&
+ commit detached
+
+'
+
+test_expect_success 'rev-list --all lists detached HEAD' '
+
+ test 3 = $(git rev-list --all | wc -l)
+
+'
+
+test_expect_success 'repack does not lose detached HEAD' '
+
+ git gc &&
+ git prune --expire=now &&
+ git show HEAD
+
+'
+
+test_done
--
1.6.1.299.gfdbb
^ permalink raw reply related
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johannes Schindelin @ 2009-01-16 12:57 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Johan Herland, Anders Melchiorsen, git, Jay Soffian,
Wincent Colaiuta, Junio C Hamano, Sverre Rabbelier, Johannes Sixt
In-Reply-To: <20090116124239.GA28870@neumann>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 307 bytes --]
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?
Ciao,
Dscho
^ permalink raw reply
* [PATCH next v4] git-notes: fix printing of multi-line notes
From: Tor Arne Vestbø @ 2009-01-16 13:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Jeff King, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901142209570.3586@pacific.mpi-cbg.de>
The line length was read from the same position every time,
causing mangled output when printing notes with multiple lines.
Also, adding new-line manually for each line ensures that we
get a new-line between commits, matching git-log for commits
without notes.
Test case added to t3301-notes.sh.
Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Sorry about the delay. Here's a squashed patch.
notes.c | 13 +++++++------
t/t3301-notes.sh | 32 +++++++++++++++++++++++++++++++-
2 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/notes.c b/notes.c
index ad43a2e..bd73784 100644
--- a/notes.c
+++ b/notes.c
@@ -110,8 +110,8 @@ void get_commit_notes(const struct commit *commit, struct strbuf *sb,
{
static const char *utf8 = "utf-8";
unsigned char *sha1;
- char *msg;
- unsigned long msgoffset, msglen;
+ char *msg, *msg_p;
+ unsigned long linelen, msglen;
enum object_type type;
if (!initialized) {
@@ -148,12 +148,13 @@ void get_commit_notes(const struct commit *commit, struct strbuf *sb,
strbuf_addstr(sb, "\nNotes:\n");
- for (msgoffset = 0; msgoffset < msglen;) {
- int linelen = strchrnul(msg, '\n') - msg;
+ for (msg_p = msg; msg_p < msg + msglen; msg_p += linelen + 1) {
+ linelen = strchrnul(msg_p, '\n') - msg_p;
strbuf_addstr(sb, " ");
- strbuf_add(sb, msg + msgoffset, linelen);
- msgoffset += linelen;
+ strbuf_add(sb, msg_p, linelen);
+ strbuf_addch(sb, '\n');
}
+
free(msg);
}
diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh
index ba42c45..9393a25 100755
--- a/t/t3301-notes.sh
+++ b/t/t3301-notes.sh
@@ -59,7 +59,37 @@ EOF
test_expect_success 'show notes' '
! (git cat-file commit HEAD | grep b1) &&
git log -1 > output &&
- git diff expect output
+ test_cmp expect output
+'
+test_expect_success 'create multi-line notes (setup)' '
+ : > a3 &&
+ git add a3 &&
+ test_tick &&
+ git commit -m 3rd &&
+ MSG="b3
+c3c3c3c3
+d3d3d3" git notes edit
+'
+
+cat > expect-multiline << EOF
+commit 1584215f1d29c65e99c6c6848626553fdd07fd75
+Author: A U Thor <author@example.com>
+Date: Thu Apr 7 15:15:13 2005 -0700
+
+ 3rd
+
+Notes:
+ b3
+ c3c3c3c3
+ d3d3d3
+EOF
+
+printf "\n" >> expect-multiline
+cat expect >> expect-multiline
+
+test_expect_success 'show multi-line notes' '
+ git log -2 > output &&
+ test_cmp expect-multiline output
'
test_done
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Sverre Rabbelier @ 2009-01-16 13:12 UTC (permalink / raw)
To: Johan Herland, Stephan Beyer
Cc: git, Jay Soffian, Wincent Colaiuta, Johannes Schindelin,
Junio C Hamano, Johannes Sixt, Anders Melchiorsen
In-Reply-To: <200901161050.13971.johan@herland.net>
On Fri, Jan 16, 2009 at 10:50, Johan Herland <johan@herland.net> wrote:
> we should consider something like
> pick e8902c1 Foo
> halt
I very much like this suggestion, Stephan, is this somewhat similar to
how git sequencer will do things?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] revision walker: include a detached HEAD in --all
From: Santi Béjar @ 2009-01-16 13:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Thomas Rast, Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0901161351460.3586@pacific.mpi-cbg.de>
2009/1/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> When HEAD is detached, --all should list it, too, logically, as a
> detached HEAD is by definition a temporary, unnamed branch.
>
> It is especially necessary to list it when garbage collecting, as
> the detached HEAD would be trashed.
>
> Noticed by Thomas Rast.
>
> 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.
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).
Santi
^ permalink raw reply
* Re: [PATCH] revision walker: include a detached HEAD in --all
From: Johannes Schindelin @ 2009-01-16 13:17 UTC (permalink / raw)
To: Santi Béjar; +Cc: Junio C Hamano, Thomas Rast, Johannes Sixt, git
In-Reply-To: <adf1fd3d0901160512i2de8f473gd471cc1dcb72afa4@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1258 bytes --]
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, and I disagree with that.
> 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_.
Ciao,
Dscho
^ permalink raw reply
* Re: Weird behaviour of git status
From: Sverre Rabbelier @ 2009-01-16 13:17 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: devel, git@vger.kernel.org
In-Reply-To: <2A29AD77-2B8D-4491-92C1-62F5FFFBB00F@wincent.com>
On Fri, Jan 16, 2009 at 10:44, Wincent Colaiuta <win@wincent.com> wrote:
> "git status" shows you what would be committed if you ran "git commit" with
> the same parameters. So in your example, the output for "git status ." is
> exactly as you would expect.
>
> This is stated in the man page.
This is one of the first things I stumbled on when I started using
git. I often times wanted to do "git status -- pathspec" to see only
what changed in a certain directory, rather than what would be
committed if only the contents of that directory is committed.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [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
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