* Re: git notes: notes
From: Christian Couder @ 2010-01-27 20:01 UTC (permalink / raw)
To: john.koleszar
Cc: Johan Herland, Joey Hess, git@vger.kernel.org,
Johannes.Schindelin@gmx.de
In-Reply-To: <1264442884.14641.33.camel@cp-jk-linux.corp.on2.com>
On lundi 25 janvier 2010, John Koleszar wrote:
> On Wed, 2010-01-20 at 21:05 -0500, Johan Herland wrote:
> > On Wednesday 20 January 2010, Joey Hess wrote:
>
> > In any case, I would not use "git notes" to maintain the bisect hints.
> > Rather, I'd add subcommands to "git bisect" that would take care of
> > maintaining the notes tree @ "refs/notes/bisect". Much more
> > user-friendly than telling the user to write their own bisect-notes by
> > hand.
>
> I haven't read up on notes more than enough to know its in the pipe, but
> I had a similar idea for using them to store bisect hints. I've been
> doing a lot of bisecting lately into a range that had a couple dormant
> bugs where I'm trying to bisect bug B but bug A prevents me from making
> a determination. Rather than skip what I know is an interesting commit,
> I cherry-pick the bugfix commit(s) A' and test that, then reset and
> continue bisecting.
>
> Teaching bisect to consistently skip a commit, or to automatically
> squash in A' if we have A and not A', would be a desirable feature. I
> will have to read up some more on notes.
Perhaps you can read about "git replace" in my article:
http://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html
and/or my related presentation:
http://www.linux-kongress.org/2009/slides/fighting_regressions_with_git_bisect_christian_couder.pdf
I think in the long run it's much better to use git replace rather than
notes, especially as replace refs for bisecting could be in their own
refs/replace/bisect namespace. I may take the time to implement that soon
if you or other people are interested.
Regards,
Christian.
^ permalink raw reply
* Re: [PATCHv12 00/23] git notes
From: Junio C Hamano @ 2010-01-27 20:00 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <1264593120-4428-1-git-send-email-johan@herland.net>
Johan Herland <johan@herland.net> writes:
> - Patch #23 is a new patch adding the "git notes add" command for appending
> contents to notes (instead of editing/replacing).
I find this even more confusing. Originally I was puzzled by the lack of
"git notes add"; it took me for quite until I managed to figure out that
"git notes edit" was the command to use, even if I wanted to add notes to
a commit that I know that does not have any.
I would expect "git notes edit" to be "edit starting from the existing one
(if exists)", and "git notes add" to be "add notes to a commit that lacks
one, complain if it already has notes, and allow --force to replace".
^ permalink raw reply
* [PATCH] Fix git rev-list --reverse --max-count=N
From: Michael Spang @ 2010-01-27 20:03 UTC (permalink / raw)
To: git; +Cc: Junio C. Hamano
Using --max-count with --reverse currently outputs the last N commits
in the final output rather than the first N commits. We want to
truncate the reversed list after the first few commits, rather than
truncating the initial list and reversing that.
Signed-off-by: Michael Spang <spang@google.com>
---
revision.c | 20 +++++++++++++++++---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/revision.c b/revision.c
index f54d43f..62135e0 100644
--- a/revision.c
+++ b/revision.c
@@ -1993,7 +1993,8 @@ static struct commit *get_revision_internal(struct rev_info *revs)
c = NULL;
break;
default:
- revs->max_count--;
+ if (!revs->reverse)
+ revs->max_count--;
}
if (c)
@@ -2055,8 +2056,21 @@ struct commit *get_revision(struct rev_info *revs)
revs->reverse_output_stage = 1;
}
- if (revs->reverse_output_stage)
- return pop_commit(&revs->commits);
+ if (revs->reverse_output_stage) {
+ c = pop_commit(&revs->commits);
+
+ switch (revs->max_count) {
+ case -1:
+ break;
+ case 0:
+ c = NULL;
+ break;
+ default:
+ revs->max_count--;
+ }
+
+ return c;
+ }
c = get_revision_internal(revs);
if (c && revs->graph)
--
1.6.6
^ permalink raw reply related
* Re: [PATCHv12 00/23] git notes
From: Sverre Rabbelier @ 2010-01-27 20:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Herland, git
In-Reply-To: <7vzl3zpbbz.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Jan 27, 2010 at 21:00, Junio C Hamano <gitster@pobox.com> wrote:
> I would expect "git notes edit" to be "edit starting from the existing one
> (if exists)", and "git notes add" to be "add notes to a commit that lacks
> one, complain if it already has notes, and allow --force to replace".
Agreed, that makes a lot of sense; I had similar thoughts (at least,
on that the current design was flawed), and I think what you propose
is a sane interface.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2] Fix remote.<remote>.vcs
From: Junio C Hamano @ 2010-01-27 20:22 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Daniel Barkalow, git, Tor Arvid Lund
In-Reply-To: <20100127185927.GA22630@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> On Wed, Jan 27, 2010 at 01:39:00PM -0500, Daniel Barkalow wrote:
>> On Wed, 27 Jan 2010, Ilari Liusvaara wrote:
>> >
>> > if (!remote)
>> > die("No remote provided to transport_get()");
>> >
>> > ret->remote = remote;
>> > + helper = remote->foreign_vcs;
>>
>> Needs to be "helper = remote ? remote->foreign_vcs : NULL", for the same
>> reason that the test below had been "remote && remote->foreign_vcs".
>
> Few lines above that:
>
> if (!remote)
> die("No remote provided to transport_get()");
Perhaps we would want this micro-clean-up on top then.
-- >8 --
Subject: transport_get(): drop unnecessary check for !remote
At the beginning of the function we make sure remote is not NULL, and
the remainder of the funciton already depends on it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff --git a/transport.c b/transport.c
index 87581b8..3846aac 100644
--- a/transport.c
+++ b/transport.c
@@ -921,7 +921,7 @@ struct transport *transport_get(struct remote *remote, const char *url)
ret->remote = remote;
helper = remote->foreign_vcs;
- if (!url && remote && remote->url)
+ if (!url && remote->url)
url = remote->url[0];
ret->url = url;
^ permalink raw reply related
* git-tag -s can't find GPG private key
From: Mike.lifeguard @ 2010-01-27 21:02 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
It seems that when the GPG key name and user.name in git's config are
different, git can't find the appropriate private key to sign the tag.
Git should attempt to use user.email to find the key. Setting
user.signingkey is of course a workaround. The relevant code would be in
builtin-tag.c.
- -Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAktgqewACgkQst0AR/DaKHuDZgCgpYHD05aJHKF/Wj/uU8CK5swP
SccAoMjHVKM/OZBhbvSvC+aWCQ123Tje
=ZIo0
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: git-tag -s can't find GPG private key
From: Sverre Rabbelier @ 2010-01-27 21:06 UTC (permalink / raw)
To: Mike.lifeguard; +Cc: git
In-Reply-To: <4B60A9F0.5000904@gmail.com>
Heya,
On Wed, Jan 27, 2010 at 22:02, Mike.lifeguard <mike.lifeguard@gmail.com> wrote:
> It seems that when the GPG key name and user.name in git's config are
> different, git can't find the appropriate private key to sign the tag.
> Git should attempt to use user.email to find the key. Setting
> user.signingkey is of course a workaround. The relevant code would be in
> builtin-tag.c.
It seems you already know where to look, why don't you try and come up
with a patch since it is indeed, your itch to scratch?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git-tag -s can't find GPG private key
From: Junio C Hamano @ 2010-01-27 21:16 UTC (permalink / raw)
To: Mike.lifeguard; +Cc: git
In-Reply-To: <4B60A9F0.5000904@gmail.com>
"Mike.lifeguard" <mike.lifeguard@gmail.com> writes:
> It seems that when the GPG key name and user.name in git's config are
> different, git can't find the appropriate private key to sign the tag.
> Git should attempt to use user.email to find the key. Setting
> user.signingkey is of course a workaround.
user.signingkey was devised for this exact case, and I don't think it is a
work-around.
I do not think "should attempt" is a correct attitude, even though I can
100% agree with "it would have been nicer if it attempted to do this from
day one". You are unfortunately not interacting with git codebase in
early 2005 anymore and there are thousands if not millions of existing
users you should worry about.
Using user.email changes the behaviour for people who do not want a key
that has the same e-mail address, and because the choice of key is all
about security, the logic to choose which one shouldn't be changed
lightly.
^ permalink raw reply
* Re: [PATCHv12 01/23] Minor non-functional fixes to notes.c
From: Junio C Hamano @ 2010-01-27 21:20 UTC (permalink / raw)
To: Johan Herland; +Cc: gitster, git
In-Reply-To: <1264593120-4428-2-git-send-email-johan@herland.net>
Johan Herland <johan@herland.net> writes:
> Signed-off-by: Johan Herland <johan@herland.net>
Is it just me who goes "Huh? Why is he sending a non-working fix?" when
seeing "non-functional fixes"?
I'd retitle it to "Cosmetic fixes" and apply.
Thanks.
^ permalink raw reply
* Re: [PATCH] Fix git rev-list --reverse --max-count=N
From: Johannes Sixt @ 2010-01-27 22:09 UTC (permalink / raw)
To: Michael Spang; +Cc: git, Junio C. Hamano
In-Reply-To: <1264622600-20981-1-git-send-email-spang@google.com>
On Mittwoch, 27. Januar 2010, Michael Spang wrote:
> Using --max-count with --reverse currently outputs the last N commits
> in the final output rather than the first N commits. We want to
> truncate the reversed list after the first few commits, rather than
> truncating the initial list and reversing that.
So when you have this history (A is oldest, D is newest):
A--B--C--D
and you say
git log --max-count=2 --reverse D
then you want
A
B
but I want
C
D
Why is your interpretation correct, an mine wrong?
-- Hannes
^ permalink raw reply
* Re: [PATCH] Fix git rev-list --reverse --max-count=N
From: Sverre Rabbelier @ 2010-01-27 22:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Michael Spang, git, Junio C. Hamano
In-Reply-To: <201001272309.26054.j6t@kdbg.org>
Heya,
> So when you have this history (A is oldest, D is newest):
>
> A--B--C--D
>
> and you say
>
> git log --max-count=2 --reverse D
>
> then you want
>
> A
> B
>
> but I want
>
> C
> D
>
And the current behavior is
B
A
Isn't it? I agree btw, that C D is the 'correct' result.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: cvs revision number -> git commit name?
From: Johan Herland @ 2010-01-27 22:19 UTC (permalink / raw)
To: Hallvard B Furuseth; +Cc: git, Aaron Crane
In-Reply-To: <hbf.20100127jjbx@bombur.uio.no>
On Wednesday 27 January 2010, Hallvard B Furuseth wrote:
> Johan Herland writes:
> > You could consider adding the CVS revision numbers as notes (see "git
> > help notes" in >= v1.6.6) to the corresponding commits. Then they don't
> > pollute the commit messages, but instead live in a separate, but
> > parallel hierarchy that can be easily pulled in when you need to
> > reference them (e.g. GIT_NOTES_REF="refs/" git log).
>
> Thanks, looks better than munging the log. Though with one common
> weakness - should likely omit noting mass commits, since they'd clutter
> what 'git log' displays too much. Of course, either could used combined
> with a mapping table.
Of course, you wouldn't put the cvs revision numbers on the default notes
ref ("refs/notes/commits"). You would rather put them on a _different_ notes
refs (e.g. "refs/notes/cvs"), where they would not clutter you "git log",
and then when you _need_ to look at them, you simply run:
GIT_NOTES_REF=refs/notes/cvs git log
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Fix git rev-list --reverse --max-count=N
From: Michael Spang @ 2010-01-27 22:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C. Hamano
In-Reply-To: <201001272309.26054.j6t@kdbg.org>
On Wed, Jan 27, 2010 at 5:09 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Mittwoch, 27. Januar 2010, Michael Spang wrote:
>
> So when you have this history (A is oldest, D is newest):
>
> A--B--C--D
>
> and you say
>
> git log --max-count=2 --reverse D
>
> then you want
>
> A
> B
>
> but I want
>
> C
> D
>
> Why is your interpretation correct, an mine wrong?
Perhaps not wrong, but for me it was unexpected. For whatever reason,
I expected "--reverse" to give you the illusion that you are iterating
from the beginning of the history, even if it's not actually possible
to iterate that way directly. In line with that, limiting the output
to N commits would give you the earliest N commits. If you instead
think "stop descending through the history once we have N commits" the
current behavior makes sense.
I talked to Junio and he says the current behavior is here to stay.
Michael
^ permalink raw reply
* Re: [PATCH] Fix git rev-list --reverse --max-count=N
From: Junio C Hamano @ 2010-01-27 22:28 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Michael Spang, git
In-Reply-To: <201001272309.26054.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> On Mittwoch, 27. Januar 2010, Michael Spang wrote:
>> Using --max-count with --reverse currently outputs the last N commits
>> in the final output rather than the first N commits. We want to
>> truncate the reversed list after the first few commits, rather than
>> truncating the initial list and reversing that.
>
> So when you have this history (A is oldest, D is newest):
>
> A--B--C--D
>
> and you say
>
> git log --max-count=2 --reverse D
>
> then you want
>
> A
> B
>
> but I want
>
> C
> D
>
> Why is your interpretation correct, an mine wrong?
The interaction between --max-count and --reverse was designed a long time
ago to support "I want to review the recent N commits in order to make
sure that they are natural and logical progression". So an unconditional
change of semantics to break that expectation this late in the game will
never be acceptable, and giving title to such a patch with a word "Fix"
won't fly well (it simply _breaks_ behaviour users have long learned to
expect).
It is a different matter to add an explicit command line option (and no
configuration to change it to default) to apply reversal before count
limiting.
^ permalink raw reply
* Re: [PATCHv12 01/23] Minor non-functional fixes to notes.c
From: Johan Herland @ 2010-01-27 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrz3nt2s.fsf@alter.siamese.dyndns.org>
On Wednesday 27 January 2010, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > Signed-off-by: Johan Herland <johan@herland.net>
>
> Is it just me who goes "Huh? Why is he sending a non-working fix?"
non-working? Does it break something for you?
> when seeing "non-functional fixes"?
>
> I'd retitle it to "Cosmetic fixes" and apply.
Ok. Fixed locally, will be part of the next iteration.
> Thanks.
Thanks for the review.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Fix git rev-list --reverse --max-count=N
From: Michael Spang @ 2010-01-27 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vsk9rnpxo.fsf@alter.siamese.dyndns.org>
On Wed, Jan 27, 2010 at 5:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
>
> The interaction between --max-count and --reverse was designed a long time
> ago to support "I want to review the recent N commits in order to make
> sure that they are natural and logical progression". So an unconditional
> change of semantics to break that expectation this late in the game will
> never be acceptable, and giving title to such a patch with a word "Fix"
> won't fly well (it simply _breaks_ behaviour users have long learned to
> expect).
You have my apology for calling it a fix. I just don't have the same
visibility into what undocumented behavior users depend on that you
do, and so I thought it actually was one.
The patch can die here. I understand the current behavior now, and I
don't have a strong need for the behavior I expected (piping to head
works fine).
Michael
^ permalink raw reply
* Re: [PATCHv12 00/23] git notes
From: Johan Herland @ 2010-01-27 23:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzl3zpbbz.fsf@alter.siamese.dyndns.org>
On Wednesday 27 January 2010, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > - Patch #23 is a new patch adding the "git notes add" command for
> > appending contents to notes (instead of editing/replacing).
>
> I find this even more confusing. Originally I was puzzled by the lack of
> "git notes add"; it took me for quite until I managed to figure out that
> "git notes edit" was the command to use, even if I wanted to add notes to
> a commit that I know that does not have any.
Not sure what you're getting at here. For the case where a commit has no
notes, "git notes add" and "git notes edit" are already _identical_. I was
only trying to emphasize that when there is an existing note, "git notes
add" will append to it, whereas "git notes edit" will replace it with your
edited version. I'm sorry if this was unclear.
> I would expect "git notes edit" to be "edit starting from the existing
> one (if exists)", and "git notes add" to be "add notes to a commit that
> lacks one,
Up to here, the current patch does exactly what you expect.
> complain if it already has notes, and allow --force to replace".
I disagree. I wrote the current semantics with the following use case in
mind:
"I have just reviewed a commit, and want to add a 'Reviewed-by' tag to the
commit notes. I don't really care if the commit already has notes, but I
certainly _don't_ want to delete them when adding my 'Reviewed-by'.
Furthermore, I want to do this with a simple command, without being thrown
into an editor."
Now, 'git notes edit -m "Reviewed-by: ..."' will do the job nicely for
commits that have no notes, but it will discard any existing notes, so it is
not a good solution in this case.
Instead, the current semantics of "git notes add" _does_ solve this use case
('git notes add -m "Reviewed-by: ..."' will append to the existing notes, or
create a new notes object if none exist).
I'm not opposed to changing the semantics if people find them unintuitive,
but I would want the new semantics to provide for this use case as well.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] filter-branch fix and tests
From: Michal Sojka @ 2010-01-27 23:41 UTC (permalink / raw)
To: Johannes Sixt, Johannes Schindelin; +Cc: git
In-Reply-To: <4B606748.2050209@viscovery.net>
On Wednesday 27 of January 2010 17:18:16 Johannes Sixt wrote:
> Michal Sojka schrieb:
> > +orig_head=`git show-ref --hash HEAD`
> > +export orig_head
>
> You place the tree filter in double-quotes. Hence, orig_head will be
> interpolated on the filter-branch command line. You don't need to export
> it.
You're right. Fixed.
> > +test_expect_success 'rewrite submodule with another content' '
> > + git filter-branch --tree-filter "test -d submod && {
> > + rm -rf submod &&
> > + git rm -rf --quiet submod &&
> > + mkdir submod &&
> > + : > submod/file
> > + } || : &&
> > + test $orig_head != `git show-ref --hash HEAD`"
>
> What is the purpose of the check in the last line?
It should check that something was rewritten, but it was incorrectly put into
the filed. Fixed.
> As long as you have another command after the "} || : &&", you can just
> write "}" instead.
OK.
> > +test_expect_failure 'checkout submodule during rewrite' '
> > + git reset --hard original &&
> > + git filter-branch -f --tree-filter \
> > + "git submodule update --init &&
> > + cd submod &&
> > + git reset --hard origin/master" HEAD
>
> You must not change the directory without changing back. Use a sub-shell.
>
> I'm not sure whether it's worth catering for this use-case anyway.
> Replacing a submodule commit should really be done only in the
> --index-filter. The tree that --tree-filter checks out is intended only as
> a temporary scratch area. It is not intended as a full worktree. In
> particular, since 'submodule update --init' changes the configuration, it
> is extremly dangerous to call from a filter.
I fully agree. I don't plan to put this test in the final version of the
patch. I wrote this test because I didn't exactly know which issue has Dscho
in mind. If it was this one, I wanted to show that this is not relevant.
I'm sending corrected version of the patch with tests.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH v2] Fix remote.<remote>.vcs
From: Daniel Barkalow @ 2010-01-27 23:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ilari Liusvaara, git, Tor Arvid Lund
In-Reply-To: <7vk4v3pabr.fsf@alter.siamese.dyndns.org>
On Wed, 27 Jan 2010, Junio C Hamano wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>
> > On Wed, Jan 27, 2010 at 01:39:00PM -0500, Daniel Barkalow wrote:
> >> On Wed, 27 Jan 2010, Ilari Liusvaara wrote:
> >> >
> >> > if (!remote)
> >> > die("No remote provided to transport_get()");
> >> >
> >> > ret->remote = remote;
> >> > + helper = remote->foreign_vcs;
> >>
> >> Needs to be "helper = remote ? remote->foreign_vcs : NULL", for the same
> >> reason that the test below had been "remote && remote->foreign_vcs".
> >
> > Few lines above that:
> >
> > if (!remote)
> > die("No remote provided to transport_get()");
>
> Perhaps we would want this micro-clean-up on top then.
>
> -- >8 --
> Subject: transport_get(): drop unnecessary check for !remote
>
> At the beginning of the function we make sure remote is not NULL, and
> the remainder of the funciton already depends on it.
I agree with both of these; there used to be code that used a NULL remote
and just a URL, but that's gone now.
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> diff --git a/transport.c b/transport.c
> index 87581b8..3846aac 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -921,7 +921,7 @@ struct transport *transport_get(struct remote *remote, const char *url)
> ret->remote = remote;
> helper = remote->foreign_vcs;
>
> - if (!url && remote && remote->url)
> + if (!url && remote->url)
> url = remote->url[0];
> ret->url = url;
>
>
^ permalink raw reply
* [PATCHv3] filter-branch: Add tests for submodules
From: Michal Sojka @ 2010-01-27 23:55 UTC (permalink / raw)
To: git; +Cc: j.sixt, Johannes.Schindelin, Michal Sojka
In-Reply-To: <201001280041.23182.sojkam1@fel.cvut.cz>
There are three important tests:
1) 'rewrite submodule with another content' passes only with the
previous patch applied.
2) 'checkout submodule during rewrite' demonstrates that it is not
possible to replace a submodule revision in tree-filter by checking
the submodule out and reseting the submodule's HEAD. Fails both
with and without the previous patch. This is because filter-branch
sets GIT_WORKING_TREE to "." which causes clone (called from
git-submodule) to fail.
3) 'replace submodule revision' shows that replacing submodule
revision is possible by direct index manipulation. Succeeds both
with and without the previous patch.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
---
t/t7003-filter-branch.sh | 47 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 9503875..fabe038 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -306,4 +306,51 @@ test_expect_success '--remap-to-ancestor with filename filters' '
test $orig_invariant = $(git rev-parse invariant)
'
+test_expect_success 'setup submodule' '
+ rm -rf * .*
+ git init &&
+ test_commit file &&
+ mkdir submod &&
+ submodurl="$PWD/submod"
+ ( cd submod &&
+ git init &&
+ test_commit file-in-submod ) &&
+ git submodule add "$submodurl"
+ git commit -m "added submodule" &&
+ test_commit add-file &&
+ ( cd submod && test_commit add-in-submodule ) &&
+ git add submod &&
+ git commit -m "changed submodule" &&
+ git branch original HEAD
+'
+
+orig_head=`git show-ref --hash --head HEAD`
+
+test_expect_success 'rewrite submodule with another content' '
+ git filter-branch --tree-filter "test -d submod && {
+ rm -rf submod &&
+ git rm -rf --quiet submod &&
+ mkdir submod &&
+ : > submod/file
+ } || :" HEAD &&
+ test $orig_head != `git show-ref --hash --head HEAD`
+'
+
+test_expect_failure 'checkout submodule during rewrite' '
+ git reset --hard original &&
+ git filter-branch -f --tree-filter \
+ "git submodule update --init &&
+ ( test -d submod && cd submod &&
+ git reset --hard origin/master )" HEAD
+'
+
+test_expect_success 'replace submodule revision' '
+ git reset --hard original &&
+ git filter-branch -f --tree-filter \
+ "if git ls-files --error-unmatch -- submod > /dev/null 2>&1
+ then git update-index --cacheinfo 160000 0123456789012345678901234567890123456789 submod
+ fi" HEAD &&
+ test $orig_head != `git show-ref --hash --head HEAD`
+'
+
test_done
--
1.6.6
^ permalink raw reply related
* Re: [PATCHv12 00/23] git notes
From: Junio C Hamano @ 2010-01-28 0:02 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <201001280005.03190.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> On Wednesday 27 January 2010, Junio C Hamano wrote:
>> Johan Herland <johan@herland.net> writes:
>> > - Patch #23 is a new patch adding the "git notes add" command for
>> > appending contents to notes (instead of editing/replacing).
>>
>> I find this even more confusing. Originally I was puzzled by the lack of
>> "git notes add"; it took me for quite until I managed to figure out that
>> "git notes edit" was the command to use, even if I wanted to add notes to
>> a commit that I know that does not have any.
>
> Not sure what you're getting at here.
The earlier frustration of mine was about adding a note, not adding _to_ a
note. The semantic difference I described with add/edit was "adding anew"
vs "modify".
Once I realize that Dscho's original "edit" lacks an explicit "adding
anew" and it simply means "replace if exists otherwise add", then I can
agree the argument that "adding anew" mode is not necessary.
The semantic difference your add/edit try to capture works at a different
level. They are "append to it" vs "replace it". Current "edit -m 'foo'"
that replaces feels to me quite counterintuitive.
If two modes are useful, then I would suggest to deprecate the use of
"edit" subcommand with -m/-F (because its name doesn't tell the user which
one between "append" and "replace" it happens to implement) and instead
introduce two more explicit subcommands, "append" and "replace". For the
same reason, "add" would cause confusion between "is this to add a new
note" vs "is this to add _to_ a new note", and I'd recommend against it.
"edit" could still open an editor to "modify" existing one (and if there
is no existing one, then the editor starts empty).
On the other hand, if "replace" is not very useful, then it might be
enough to just introduce a new "append" subcommand. Or course, we could
redefine the useless "replace" semantics from "edit -m/-F" and change it
to always append.
^ permalink raw reply
* Re: [PATCHv3] filter-branch: Add tests for submodules
From: Junio C Hamano @ 2010-01-28 0:14 UTC (permalink / raw)
To: Michal Sojka; +Cc: git, j.sixt, Johannes.Schindelin
In-Reply-To: <1264636547-24496-1-git-send-email-sojkam1@fel.cvut.cz>
Michal Sojka <sojkam1@fel.cvut.cz> writes:
> There are three important tests:
It is unnecessary and counterproductive to self-proclaim the importance of
a patch or new tests. If anything, what are important are not tests
themselves but the conditions that they check, so "Add tests to check
three important cases:" is slightly more palatable.
I'd suggest to just start with "Add three tests to make sure:".
> 1) 'rewrite submodule with another content' passes only with the
> previous patch applied.
Sorry, but I think I am missing some context here to understand this
sentence. Which previous patch?
> 2) 'checkout submodule during rewrite' demonstrates that it is not
> possible to replace a submodule revision in tree-filter by checking
> the submodule out and reseting the submodule's HEAD. Fails both
> with and without the previous patch. This is because filter-branch
> sets GIT_WORKING_TREE to "." which causes clone (called from
> git-submodule) to fail.
I thought you agreed with Hannes that this is not something we would even
want to support?
> 3) 'replace submodule revision' shows that replacing submodule
> revision is possible by direct index manipulation. Succeeds both
> with and without the previous patch.
>
> Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
> ---
Thanks.
^ permalink raw reply
* Re: [PATCH] git-gui: use themed tk widgets with Tk 8.5
From: Shawn O. Pearce @ 2010-01-28 0:51 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, msysgit
In-Reply-To: <878wbln0oa.fsf@users.sourceforge.net>
Pat Thoyts <patthoyts@users.sourceforge.net> wrote:
>
> This patch enables the use of themed Tk widgets with Tk 8.5 and above.
> These make a significant difference on Windows in making the
> application appear native. On Windows and MacOSX ttk defaults to the
> native look as much as possible. On X11 the user may select a theme
> using the TkTheme XRDB resource class by adding an line to the
> .Xresources file. The set of installed theme names is available using
> the Tk command 'ttk::themes'. The default on X11 is similar to the current
> un-themed style - a kind of thin bordered motif look.
>
> A new git config variable 'gui.usettk' may be set to disable this if
> the user prefers the classic Tk look. Using Tk 8.4 will also avoid the
> use of themed widgets as these are only available since 8.5.
>
> Some support is included for Tk 8.6 features (themed spinbox and native
> font chooser for MacOSX and Windows).
Thanks. I've been running with this pretty much all day today;
it seems sane. I'll probably push it shortly.
--
Shawn.
^ permalink raw reply
* make install error
From: kap4lin @ 2010-01-28 0:58 UTC (permalink / raw)
To: git
Hi,
(Kindly Cc me, I am not subscribed)
Process followed:
$ make configure
$ ./configure --prefix=/scratch/kap4lin/usr
$ make all
$ make install
The make install step is giving the following error:
make -C templates DESTDIR='' install
make[1]: Entering directory `/scratch/kap4lin/softwares/git-1.6.6.1/templates'
install -d -m 755 '/scratch/kap4lin/usr/share/git-core/templates'
(cd blt && gtar cf - .) | \
(cd '/scratch/kap4lin/usr/share/git-core/templates' && umask
022 && gtar xof -)
gtar: This does not look like a tar archive
gtar: Skipping to next header
gtar: Archive contains obsolescent base-64 headers
gtar: Error exit delayed from previous errors
make[1]: *** [install] Error 2
make[1]: Leaving directory `/scratch/kap4lin/softwares/git-1.6.6.1/templates'
make: *** [install] Error 2
Any help?
--
Regards
Kap4Lin
--------------------------------------
http://counter.li.org #402424
^ permalink raw reply
* [PATCH] bash: support 'git notes' and its subcommands
From: SZEDER Gábor @ 2010-01-28 1:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano, SZEDER Gábor
... and it will offer refs unless after -m or -F, because these two
options require a non-ref argument.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 9651720..8b56c34 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1306,6 +1306,24 @@ _git_name_rev ()
__gitcomp "--tags --all --stdin"
}
+_git_notes ()
+{
+ local subcommands="edit show"
+ if [ -z "$(__git_find_on_cmdline "$subcommands")" ]; then
+ __gitcomp "$subcommands"
+ return
+ fi
+
+ case "${COMP_WORDS[COMP_CWORD-1]}" in
+ -m|-F)
+ COMPREPLY=()
+ ;;
+ *)
+ __gitcomp "$(__git_refs)"
+ ;;
+ esac
+}
+
_git_pull ()
{
__git_complete_strategy && return
@@ -2218,6 +2236,7 @@ _git ()
merge-base) _git_merge_base ;;
mv) _git_mv ;;
name-rev) _git_name_rev ;;
+ notes) _git_notes ;;
pull) _git_pull ;;
push) _git_push ;;
rebase) _git_rebase ;;
--
1.7.0.rc0.28.g3ad3d5
^ 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