* Re: Weird behaviour of git status
From: Wincent Colaiuta @ 2009-01-16 9:44 UTC (permalink / raw)
To: devel; +Cc: git@vger.kernel.org
In-Reply-To: <4970488B.3010608@morey-chaisemartin.com>
El 16/1/2009, a las 9:42, Nicolas Morey-Chaisemartin escribió:
> Hello everyone,
>
> I just noticed a weird behaviour in git status.
> I have created new files in different directories in my project.
> I have added all of them in the index with git add.
> When I run "git status" It shows me that all my 3 files are in the
> index.
> However if I run git-status specifying a directory, it returns that
> the
> file in this directory are in the index but the other one isn't.
>
> In my opinion, it should
> - either display all the files as in the index (specifying a directory
> wouldn't have any effect then)
> - treat only file in the specified dir. So "external" files wouldn't
> be
> shown at all.
"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.
Cheers,
Wincent
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johan Herland @ 2009-01-16 9:50 UTC (permalink / raw)
To: git
Cc: Jay Soffian, Wincent Colaiuta, Johannes Schindelin,
Junio C Hamano, Sverre Rabbelier, Johannes Sixt,
Anders Melchiorsen
In-Reply-To: <76718490901151226l704d119bh297db4e91a4da05b@mail.gmail.com>
On Thursday 15 January 2009, Jay Soffian wrote:
> On Thu, Jan 15, 2009 at 2:27 PM, Wincent Colaiuta <win@wincent.com> wrote:
> > wait - best suggestion so far, seeing as we can't use "stop"
> This is a fun game. I like the color "halt".
Nice. I like this one as well.
After some more thinking (triggered by Junio's recent post in another
subthread), it occured to me that the current behaviour (currently known
as "edit") is not something that is applied to one of the commits in the
rebase list per se, but rather something that affects the rebase machinery
*between* commits. So instead of
edit e8902c1 Foo
we should consider something like
pick e8902c1 Foo
halt
which I think better encapsulates the current behaviour. (IOW, insert "halt"
wherever you'd like to muck about with the history; e.g.
doing "commit --amend", inserting extra commits, etc.)
We can then make shortcuts for common actions:
amend e8902c1 Foo
does a "pick" followed by "commit --amend" (for editing the commit message),
followed by "rebase --continue". Finally, we implement Anders' suggestion:
modify e8902c1 Foo
(or whatever synonym for "edit" we converge on) does a "pick" followed by
a "reset --soft HEAD^", followed by a "halt".
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: autoconf: C99 format check
From: Ralf Wildenhues @ 2009-01-16 9:41 UTC (permalink / raw)
To: Julius Naperkowski; +Cc: git
In-Reply-To: <loom.20090115T123123-915@post.gmane.org>
Hello Julius,
* Julius Naperkowski wrote on Thu, Jan 15, 2009 at 02:22:54PM CET:
> I am trying to cross-compile git for mips on a x86 host. But it seems that it is
> impossible to pass the C99 Format check in the configure script when
> cross_compile mode is activated because the script quits even before it starts
> the testprogramm. Is this behavior intentional?
Cross compilation assumes that test programs can be compiled and linked,
but not executed on the build system, i.e., at configure time. The
fourth argument of AC_RUN_IFELSE may be used to set a default test
result value in the cross compilation case, typically either a
pessimistic default, or one based on $host or so (using $host requires
AC_CANONICAL_HOST, and the config.{guess,sub} scripts).
As a workaround, you the user can pass preset results if you know what
features the host system will have, to configure. git's configure
script uses three runtime tests. You can set them with something like
./configure ac_cv_c_c99_format=yes \
ac_cv_fread_reads_directories=no \
ac_cv_snprintf_returns_bogus=no --host=... ...
although I'm not quite sure if uclibc's *printf functions indeed do
support C99 size specifiers (I think they do though).
I can post a patch to add sane default settings for AC_RUN_IFELSE in
cross compile setups, this weekend.
Cheers,
Ralf
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Anders Melchiorsen @ 2009-01-16 10:27 UTC (permalink / raw)
To: Johan Herland
Cc: git, Jay Soffian, Wincent Colaiuta, Johannes Schindelin,
Junio C Hamano, Sverre Rabbelier, Johannes Sixt
In-Reply-To: <200901161050.13971.johan@herland.net>
Johan Herland wrote:
> edit e8902c1 Foo
>
> we should consider something like
>
> pick e8902c1 Foo
> halt
Of all the suggestions, I like this one the most. Also, when placed like
this, I am suddenly no longer opposed to the word "halt".
> 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 :-)
Cheers,
Anders.
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johan Herland @ 2009-01-16 10:58 UTC (permalink / raw)
To: Anders Melchiorsen
Cc: git, Jay Soffian, Wincent Colaiuta, Johannes Schindelin,
Junio C Hamano, Sverre Rabbelier, Johannes Sixt
In-Reply-To: <49548.bFoQE3daRhY=.1232101666.squirrel@webmail.hotelhot.dk>
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"?
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-16 11:18 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <200901161008.16234.trast@student.ethz.ch>
Hi,
On Fri, 16 Jan 2009, Thomas Rast wrote:
> search_reflog () {
> next=
> git reflog show HEAD |
> while read sha ref msg; do
> if test -n "$next"; then
> next=
> echo ${sha%...}
> fi
> if echo "$msg" | grep -q "^checkout: moving from $branch "; then
> next=t
> fi
> if echo "$msg" | grep -q "^merge $branch:"; then
> git rev-list --parents -1 ${sha%...} \
> | cut -d' ' -f3
> fi
> done
> }
How about this instead:
search_reflog () {
sed -n 's/\([^ ]*\) .*\tcheckout: moving from $branch .*/\1/p' \
< .git/logs/HEAD
}
Of course, this leaves out the merges... but I'd make that a command line
option anyway: would you like to resurrect a branch that you recently were
on, or one that you recently merged, or one that was merged by someone
else?
Ciao,
Dscho
^ permalink raw reply
* Re: how to edit commit message in history
From: Jakub Narebski @ 2009-01-16 11:18 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090116035714.GA6984@b2j>
bill lam <cbill.lam@gmail.com> writes:
> I made some typos in commit messages, how to edit them without
> affecting everything else?
If it is last commit that you want to edit, and if you didn't publish
this commit to soem public repository, you can simply use
$ git commit --amend
If the commit is deeper in history, use "git rebase --interactive".
If you published commit, you are out of luck.
See http://git.or.cz/gitwiki/GitTips
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Johannes Schindelin @ 2009-01-16 11:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20090116022408.GG12275@machine.or.cz>
Hi,
On Fri, 16 Jan 2009, Petr Baudis wrote:
> On Fri, Jan 16, 2009 at 03:17:14AM +0100, Johannes Schindelin wrote:
>
> > I wondered what the point was, and I would _welcome_ links that
> > pointed to the mails containing the patches (identified either by
> > patch ids or by manual editing; best would be to have both methods at
> > the same time).
>
> Well, but you already have that, or at least an approximation.
Oh, I see! Somehow I missed that this link exists for all non-merge
commits...
> I was not actually planning to carry the patch over the next gitweb
> update since I got no feedback on it (IIRC) since I implemented it.
Well, now you got one: I find it nice. And I agree with you on the false
positive thing: it is better to have that link also for commits for which
no mails can be found.
I just had to scratch my head about what "mail" is about...
Ciao,
Dscho
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Johannes Schindelin @ 2009-01-16 11:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20090116022408.GG12275@machine.or.cz>
Hi,
On Fri, 16 Jan 2009, Petr Baudis wrote:
> On Fri, Jan 16, 2009 at 03:17:14AM +0100, Johannes Schindelin wrote:
> > On Thu, 15 Jan 2009, Junio C Hamano wrote:
> >
> > > Petr Baudis <pasky@suse.cz> writes:
> > >
> > > >> That is, it links to marc (not gmane?) but finds no matches...
> > > >
> > > > what mailing list post should it point to?
> >
> > I found gmane to be much nicer to click through than marc.
>
> IIRC I found no way to actually make a gmane link since it requires POST
> query for the searches or something.
The site seems to be down ATM, but it should be
http://search.gmane.org/search.php?group=gmane.comp.version-control.git&query=pasky
BTW how about calling the link "find mail"? When I saw "mail" first time,
I thought "oh, so I can mail that commitdiff to somebody? Nice, let's
try."
Ciao,
Dscho
^ permalink raw reply
* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: SZEDER Gábor @ 2009-01-16 11:41 UTC (permalink / raw)
To: George Spelvin; +Cc: Johannes.Schindelin, gitster, git
In-Reply-To: <20090116032708.21156.qmail@science.horizon.com>
On Thu, Jan 15, 2009 at 10:27:08PM -0500, George Spelvin wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > Or perhaps someone did more than two years ago with --full-name?
>
> Thank you for pointing that out! It's a bit of a handful to type,
Well, if you happen to use bash, you will find our excellent ;) bash
completion script under contrib/completion.
hth,
Gábor
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
From: Johannes Schindelin @ 2009-01-16 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kirill Smelkov, git
In-Reply-To: <7vd4enacf2.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 16 Jan 2009, Junio C Hamano wrote:
> I thought there is somebody on this list who insists his name is of form:
>
> From: A U Thor (MonikeR) <a.u@thor.xz>
It is Philippe Bruhat (BooK), who sometimes forgets the closing
parenthesis, and who is listed in .mailmap without the moniker.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Johannes Schindelin @ 2009-01-16 11:57 UTC (permalink / raw)
To: Santi Béjar
Cc: Junio C Hamano, Boyd Stephen Smith Jr., Teemu Likonen,
Thomas Rast, git
In-Reply-To: <adf1fd3d0901160102y32a08e26q96728495fc0b6fcf@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 853 bytes --]
Hi,
On Fri, 16 Jan 2009, Santi Béjar wrote:
> 2009/1/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >
> > 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 guess that you want something like
> >
> > [A-Za-z0-9]+|[^A-Za-z0-9 \t]+
> >
>
> 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.
Sure. If you can come up with a nice name for it, we could add special
handling for something like "[[:words:]]" expanding into said regexp.
Ciao,
Dscho
^ permalink raw reply
* 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
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