* [PATCH 0/4] gitweb feed metadata tuneups
From: Giuseppe Bilotta @ 2009-01-23 4:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Giuseppe Bilotta
The next four patches add some metadata to gitweb generated feeds:
channel image, managing editor and last-update dates are added to RSS
feeds, and the feed generator (gitweb, with version specification) is
added to both RSS and Atom feeds.
Giuseppe Bilotta (4):
gitweb: channel image in rss feed
gitweb: feed generator metadata
gitweb: rss feed managingEditor
gitweb: rss channel date
gitweb/gitweb.perl | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
^ permalink raw reply
* Re: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Michael Haggerty @ 2009-01-23 4:14 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: git, cvs2svn users
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302BC6921@emailmn.mqsoftware.com>
Kelly F. Hickel wrote:
> I found the section in question, it is:
> -- snip --
> commit refs/heads/TAG.FIXUP
> mark :1000007128
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 88
> This commit was manufactured by cvs2svn to create tag
> 'T_BU_Problem_9xxx_Merge_3-21-2000'.
> merge :1000007126
> M 100755 :180810 mfcdev/Domedit/DlgAddAlias.h
> -- snap --
>
> By my count, 88 is the ending single quote character, leaving the '.' to
> be interpreted as a command.
>
> Looks like I should go post this on the cvs2svn list.....
Yes, that would be helpful. Please include enough information and data
to enable me to reproduce your problem, because it is very mysterious.
The lines in question are (in Python)
self.f.write('data %d\n' % (len(log_msg),))
self.f.write('%s\n' % (log_msg,))
where self.f is a file that was opened in binary mode, and log_msg is an
8-bit or unicode string. Since the log message is being output to a
binary file, f.write() should squeal if the string includes any
non-ascii characters (I just verified this with Python 2.2, 2.4, and
2.5). Nevertheless, I suspect that your problem is caused by some kind
of character encoding problem, perhaps dependent on platform or Python
version.
You might also try the trunk version of cvs2svn; there have been a lot
of changes to cvs2git since release 2.1.1--even a new command that is
actually called cvs2git! (though for now you still need to use an
options file to start conversions).
Michael
------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=1044191
To unsubscribe from this discussion, e-mail: [users-unsubscribe@cvs2svn.tigris.org].
^ permalink raw reply
* Re: does git config get any side effect other than changing .gitconfig
From: bill lam @ 2009-01-23 3:41 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: bill lam, git
In-Reply-To: <200901222126.46964.bss@iguanasuicide.net>
On Thu, 22 Jan 2009, Boyd Stephen Smith Jr. wrote:
> >Suppose I got several git repositories to maintain, instead of using
> >command git config [--global] again and again. Can I call up a text
> >editor to edit .git/config or .gitconfig manually, or just copy from
> >another .gitconfig ?
>
> Yes. Absolutely.
Thanks for confirmation. I realised that the subject is in the
opposite tone to the message body.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩157 李商隱 風雨
淒涼寶劍篇 羈泊欲窮年 黃葉仍風雨 青樓自管絃
新知遭薄俗 舊好隔良緣 心斷新豐酒 銷愁斗幾千
^ permalink raw reply
* Re: does git config get any side effect other than changing .gitconfig
From: Boyd Stephen Smith Jr. @ 2009-01-23 3:26 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090123031210.GB6931@b2j>
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
On Thursday 22 January 2009, bill lam <cbill.lam@gmail.com> wrote
about 'does git config get any side effect other than
changing .gitconfig':
>Suppose I got several git repositories to maintain, instead of using
>command git config [--global] again and again. Can I call up a text
>editor to edit .git/config or .gitconfig manually, or just copy from
>another .gitconfig ?
Yes. Absolutely.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Johannes Schindelin @ 2009-01-23 3:20 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <bd6139dc0901221847u6b8aeadcl580a091751de3d26@mail.gmail.com>
Hi,
On Fri, 23 Jan 2009, Sverre Rabbelier wrote:
> On Fri, Jan 23, 2009 at 03:42, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > HTTP being 2nd class citizen anyway (and we can always fix it after
> > Mike's cleanups), I'd say this patch is ready to roll.
>
> Aside from that, am I correct in asserting that in the "worst case"
> scenario the repo is cloned instead of erroring out, and a simple "git
> fetch" would fix the issue?
Probably. Note, however, that scripts might rely on a fail if there were
problems.
But then, scripts have no business cloning repositories (fetching, yes.
But cloning?)
Ciao,
Dscho
^ permalink raw reply
* does git config get any side effect other than changing .gitconfig
From: bill lam @ 2009-01-23 3:12 UTC (permalink / raw)
To: git
Suppose I got several git repositories to maintain, instead of using
command git config [--global] again and again. Can I call up a text
editor to edit .git/config or .gitconfig manually, or just copy from
another .gitconfig ?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩096 宋之問 題大庾嶺北驛
陽月南飛雁 傳聞至此回 我行殊未已 何日復歸來
江靜潮初落 林昏瘴不開 明朝望鄉處 應見隴頭梅
^ permalink raw reply
* Re: Short "git commit $file" syntax fails in the face of a resolved conflict
From: Asheesh Laroia @ 2009-01-23 2:55 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Johannes Sixt, Nathan Yergler, Michael J Gruber, git
In-Reply-To: <20090123094509.6117@nanako3.lavabit.com>
On Fri, 23 Jan 2009, Nanako Shiraishi wrote:
> Your explanation is a good answer to Nathan's misunderstanding; "git add
> path && git commit" and "git commit path" are different.
>
> But Nathan's first sentence is a different matter.
Thanks for seeing this!
> I do not think it is coming from the same confusion, and I think the
> question is a valid one. Your answer does not explain why it is a bad
> idea to change the behavior of "git commit path" to what "git commit -i
> path" does during a merge.
During a merge where the file called "file" is in conflict, I don't see
why the internal mechanism of how a merge gets resolved is important to
users like Nathan.
Sure, the index is nice, but let's look at the choices here. When he runs
$ git commit file -m 'fixed conflict'
git can do one of two things:
(a) Fail with an obscure (or less obscure) error message, or
(b) Succeed.
The way in which it can suceed is unambiguous. Now, in the case of more
than one file being in conflict, it makes sense to abort; success isn't
possible. But in this case, no one really benefits from the user having to
type something else to have the command actually succeed.
Those are my thoughts.
> The answer of course can be "because it changes the behavior people are
> very much used to."
I don't think anyone is "very much used to" this error message, or that
making something succeed in the only possible way is going to confuse
anyone. If you're worried about confusing people, git could print a note
like:
$ git commit file -m "Fixed conflict"
NOTE: Merge was in progress. If you have more than one file in conflict
in a future merge, be sure to "git add" each file separately and then
commit them all at once.
Created commit 12ede36: Fixed conflict
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file
$
-- Asheesh.
--
In the Spring, I have counted 136 different kinds of weather inside of
24 hours.
-- Mark Twain, on New England weather
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Sverre Rabbelier @ 2009-01-23 2:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901230333060.3586@pacific.mpi-cbg.de>
On Fri, Jan 23, 2009 at 03:42, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> HTTP transport, however, would not die() on connection errors, from my
> cursory look.
Heh, this is why I asked you, my cursory look told me "no clue" instead.
> HTTP being 2nd class citizen anyway (and we can always fix it after Mike's
> cleanups), I'd say this patch is ready to roll.
Aside from that, am I correct in asserting that in the "worst case"
scenario the repo is cloned instead of erroring out, and a simple "git
fetch" would fix the issue?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Johannes Schindelin @ 2009-01-23 2:42 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <bd6139dc0901221746h258f548etf857ab37399133da@mail.gmail.com>
Hi,
On Fri, 23 Jan 2009, Sverre Rabbelier wrote:
> On Fri, Jan 23, 2009 at 02:24, Junio C Hamano <gitster@pobox.com> wrote:
> > I think the basic idea is Ok, but is it a reliable check at this point to
> > see if (refs == NULL) to tell if the target repository is an empty one?
>
> This is the question I asked Dscho, and he said/guessed that it was.
>
> > I am mostly worried about a failure case (connected but couldn't get
> > the refs, or perhaps connection failed to start). If you get a NULL
> > in such a case you may end up saying "oh you cloned a void" when you
> > should say "nah, such a remote repository does not exist".
>
> Yes, this was my concern as well.
>From what I can see in get_remote_heads(), the native protocols would
die(), as would rsync().
HTTP transport, however, would not die() on connection errors, from my
cursory look.
That might be skewed, though, as I am on top of Mike's patches (in the
hopefully not so futile hope that Mike -- after letting me wait for over
one year -- finishes his work.
HTTP being 2nd class citizen anyway (and we can always fix it after Mike's
cleanups), I'd say this patch is ready to roll.
Ciao,
Dscho
^ permalink raw reply
* Re: egit problem with sym linked eclipse project dirs
From: Stephen Bannasch @ 2009-01-23 1:56 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
In-Reply-To: <p0624085fc592d385c7fb@[192.168.1.114]>
At 6:27 PM -0500 1/13/09, Stephen Bannasch wrote:
>At 10:37 PM +0100 1/13/09, Robin Rosenberg wrote:
>> > To hack around Eclipse's problem with projects in nested directories
>>> I clone a repo and then create a new top-level dir that just has
>>> symbolic links to all the project directories.
>>>
>>> However when I Team/Share with git using egit the resources become
>>> untracked when displayed in Eclipse -- they still are tracked however
>>> when I check from the command line.
>>
>>I've seen this too, but so far not got myself to actually fix it. I
>>think it has do with
>>that we ask eclipse project for it's path end there we gets off track. Thanks
>>for providing a good example that help "someone" to fix it.
>>
>>Could you add an issue at http://code.google.com/p/egit/issues/list and maybe
>>include a tar ball with a simple project displaying this
>>behaviour? (with a note
>>that the symlinks makes this impossible to recreate on Windows).
>
>Done: http://code.google.com/p/egit/issues/detail?id=52
>
>Fxing this will make using Eclipse and Git together SO much nicer!
Robin and Shawn,
Can you suggest where in the egit code I should look to see if I can fix this?
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Sverre Rabbelier @ 2009-01-23 1:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vwscm4xx0.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 02:24, Junio C Hamano <gitster@pobox.com> wrote:
> I think the basic idea is Ok, but is it a reliable check at this point to
> see if (refs == NULL) to tell if the target repository is an empty one?
This is the question I asked Dscho, and he said/guessed that it was.
> I am mostly worried about a failure case (connected but couldn't get the
> refs, or perhaps connection failed to start). If you get a NULL in such a
> case you may end up saying "oh you cloned a void" when you should say
> "nah, such a remote repository does not exist".
Yes, this was my concern as well.
> If transport_get_remote_refs() dies without returning NULL, that would be
> sufficient, but I didn't check.
It does, transport_get_remote_refs() calls fetch_pack, which dies when
'refs' (the fourth argument) is NULL:
static int fetch_refs_via_pack(...) {
// setup code snipped
if (!data->conn) {
connect_setup(transport);
get_remote_heads(data->fd[0], &refs_tmp, 0, NULL, 0, NULL);
}
refs = fetch_pack(&args, data->fd, data->conn,
refs_tmp ? refs_tmp : transport->remote_refs,
dest, nr_heads, heads, &transport->pack_lockfile);
So unless get_remote_heads messes with it, it will remain NULL. Now I
must admit that I'm not familiar enough with get_remote_heads to know
if this could cause a false positive, Dscho?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [kha/safe PATCH] completion bugfix: Place double pipes in front of alternate command.
From: Karl Hasselström @ 2009-01-23 1:35 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git, catalin.marinas
In-Reply-To: <1232670372-20000-1-git-send-email-ted@tedpavlic.com>
On 2009-01-22 19:26:12 -0500, Ted Pavlic wrote:
> - 'complete -o default -F _stg stg' ] ]
> + '|| complete -o default -F _stg stg' ] ]
Thanks, I've edited the patch and pushed it out again.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Junio C Hamano @ 2009-01-23 1:24 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <1232669252-21881-1-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> diff --git a/builtin-clone.c b/builtin-clone.c
> index f7e5a7b..d5bba0e 100644
> --- a/builtin-clone.c
> +++ b/builtin-clone.c
> @@ -522,14 +522,23 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> option_upload_pack);
>
> refs = transport_get_remote_refs(transport);
> - transport_fetch_refs(transport, refs);
> + if(refs)
> + transport_fetch_refs(transport, refs);
Thanks.
I think the basic idea is Ok, but is it a reliable check at this point to
see if (refs == NULL) to tell if the target repository is an empty one?
I am mostly worried about a failure case (connected but couldn't get the
refs, or perhaps connection failed to start). If you get a NULL in such a
case you may end up saying "oh you cloned a void" when you should say
"nah, such a remote repository does not exist".
If transport_get_remote_refs() dies without returning NULL, that would be
sufficient, but I didn't check.
^ permalink raw reply
* Re: [PATCH 3/3] Add --contains flag to git tag
From: Junio C Hamano @ 2009-01-23 1:18 UTC (permalink / raw)
To: Jake Goulding; +Cc: git
In-Reply-To: <497913EE.9040608@vivisimo.com>
Jake Goulding <goulding@vivisimo.com> writes:
> @@ -34,7 +35,6 @@ static int show_reference(const char *refname, const
> unsigned char *sha1,
> int flag, void *cb_data)
> {
> struct tag_filter *filter = cb_data;
> -
> if (!fnmatch(filter->pattern, refname, 0)) {
> int i;
> unsigned long size;
Here you can see a long line wrapped.
What does this hunk have to do with adding --contains option anyway?
> @@ -42,6 +42,18 @@ static int show_reference(const char *refname, const
> unsigned char *sha1,
> char *buf, *sp, *eol;
> size_t len;
>
> + if (filter->with_commit) {
> + struct commit *commit;
> +
> + commit = lookup_commit_reference_gently(sha1, 1);
> + if (!commit) {
> + error("tag '%s' does not point at a commit", refname);
> + return 0;
Drop this error() call, and just return silently. A tag that does not
point at a commit is not an error at all.
^ permalink raw reply
* Re: [PATCH 2/3] Make has_commit non-static
From: Junio C Hamano @ 2009-01-23 1:13 UTC (permalink / raw)
To: Jake Goulding; +Cc: git
In-Reply-To: <497913E4.6050806@vivisimo.com>
Jake Goulding <goulding@vivisimo.com> writes:
> Moving has_commit from branch to a common location in preparation for
> using it in tag.
has_commit() may have been a good enough name when it was a static in
builtin-branch.c but with much wider visibility, it is not specific
enough.
Perhaps you would want to rename it to something more descriptive.
Also it seems that your patch is garbled and won't apply. A blank
context line lost the leading (and only) SP, and long lines are wrapped.
> Signed-off-by: Jake Goulding <goulding@vivisimo.com>
> ---
> builtin-branch.c | 15 ---------------
> commit.c | 15 +++++++++++++++
> commit.h | 1 +
> 3 files changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/builtin-branch.c b/builtin-branch.c
> index 82d6fb2..bb42911 100644
> --- a/builtin-branch.c
> +++ b/builtin-branch.c
> @@ -193,21 +193,6 @@ struct ref_list {
> int kinds;
> };
>
> -static int has_commit(struct commit *commit, struct commit_list
> *with_commit)
> -{
> - if (!with_commit)
> - return 1;
> - while (with_commit) {
> - struct commit *other;
> -
> - other = with_commit->item;
> - with_commit = with_commit->next;
> - if (in_merge_bases(other, &commit, 1))
> - return 1;
> - }
> - return 0;
> -}
> -
> static int append_ref(const char *refname, const unsigned char *sha1,
> int flags, void *cb_data)
> {
> struct ref_list *ref_list = (struct ref_list*)(cb_data);
> diff --git a/commit.c b/commit.c
> index c99db16..5ccb338 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -705,6 +705,21 @@ struct commit_list *get_merge_bases(struct commit
> *one, struct commit *two,
> return get_merge_bases_many(one, 1, &two, cleanup);
> }
>
> +int has_commit(struct commit *commit, struct commit_list *with_commit)
> +{
> + if (!with_commit)
> + return 1;
> + while (with_commit) {
> + struct commit *other;
> +
> + other = with_commit->item;
> + with_commit = with_commit->next;
> + if (in_merge_bases(other, &commit, 1))
> + return 1;
> + }
> + return 0;
> +}
> +
> int in_merge_bases(struct commit *commit, struct commit **reference,
> int num)
> {
> struct commit_list *bases, *b;
> diff --git a/commit.h b/commit.h
> index 3a7b06a..1b8444f 100644
> --- a/commit.h
> +++ b/commit.h
> @@ -133,6 +133,7 @@ extern int is_repository_shallow(void);
> extern struct commit_list *get_shallow_commits(struct object_array *heads,
> int depth, int shallow_flag, int not_shallow_flag);
>
> +int has_commit(struct commit *, struct commit_list *);
> int in_merge_bases(struct commit *, struct commit **, int);
>
> extern int interactive_add(int argc, const char **argv, const char
> *prefix);
> --
> 1.6.0.4
^ permalink raw reply
* [PATCH] Allow cloning an empty repository
From: Sverre Rabbelier @ 2009-01-23 0:07 UTC (permalink / raw)
To: git; +Cc: Sverre Rabbelier
Cloning an empty repository manually (that is, doing 'git init' and
then doing all configuration by hand) can be a lot of work. Save the
user this work by allowing the cloning of empty repositories.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Thanks to Dscho for giving some pointers on how to do this.
builtin-clone.c | 17 +++++++++++++----
t/t5701-clone-local.sh | 16 ++++++++++++++++
2 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index f7e5a7b..d5bba0e 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -522,14 +522,23 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
option_upload_pack);
refs = transport_get_remote_refs(transport);
- transport_fetch_refs(transport, refs);
+ if(refs)
+ transport_fetch_refs(transport, refs);
}
- clear_extra_refs();
+ if(refs) {
+ clear_extra_refs();
- mapped_refs = write_remote_refs(refs, &refspec, reflog_msg.buf);
+ mapped_refs = write_remote_refs(refs, &refspec, reflog_msg.buf);
- head_points_at = locate_head(refs, mapped_refs, &remote_head);
+ head_points_at = locate_head(refs, mapped_refs, &remote_head);
+ }
+ else {
+ warning("You appear to have cloned an empty repository.");
+ head_points_at = NULL;
+ remote_head = NULL;
+ option_no_checkout = 1;
+ }
if (head_points_at) {
/* Local default branch link */
diff --git a/t/t5701-clone-local.sh b/t/t5701-clone-local.sh
index 8dfaaa4..fbd9bfa 100755
--- a/t/t5701-clone-local.sh
+++ b/t/t5701-clone-local.sh
@@ -116,4 +116,20 @@ test_expect_success 'bundle clone with nonexistent HEAD' '
test ! -e .git/refs/heads/master
'
+test_expect_success 'clone empty repository' '
+ cd "$D" &&
+ mkdir empty &&
+ (cd empty && git init) &&
+ git clone empty empty-clone &&
+ test_tick &&
+ (cd empty-clone
+ echo "content" >> foo &&
+ git add foo &&
+ git commit -m "Initial commit" &&
+ git push origin master &&
+ expected=$(git rev-parse master) &&
+ actual=$(git --git-dir=../empty/.git rev-parse master) &&
+ test $actual = $expected)
+'
+
test_done
--
1.6.1.399.g0d272.dirty
^ permalink raw reply related
* [PATCH 3/3] Add --contains flag to git tag
From: Jake Goulding @ 2009-01-23 0:48 UTC (permalink / raw)
To: git
In-Reply-To: <1232671630-19683-2-git-send-email-goulding@vivisimo.com>
This functions similar to git branch --contains - it will show all
tags that contain the specified commit. Indeed, it uses the same
lookup mechanisms as git branch.
Also adding documentation and tests for new option.
Signed-off-by: Jake Goulding <goulding@vivisimo.com>
---
Reworked with feedback from the list.
Moved commit testing inside of the regex match, instead of before.
Moved test cases into existing test.
Squashed code / doc / test into one commit.
Documentation/git-tag.txt | 5 ++-
builtin-tag.c | 32 +++++++++++-
t/t7004-tag.sh | 115
+++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 148 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index e44f543..533d18b 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]
<name> [<commit> | <object>]
'git tag' -d <name>...
-'git tag' [-n[<num>]] -l [<pattern>]
+'git tag' [-n[<num>]] -l [--contains <commit>] [<pattern>]
'git tag' -v <name>...
DESCRIPTION
@@ -68,6 +68,9 @@ OPTIONS
List tags with names that match the given pattern (or all if no
pattern is given).
Typing "git tag" without arguments, also lists all tags.
+--contains <commit>::
+ Only list tags which contain the specified commit.
+
-m <msg>::
Use the given tag message (instead of prompting).
If multiple `-m` options are given, their values are
diff --git a/builtin-tag.c b/builtin-tag.c
index a398499..33424c0 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -26,6 +26,7 @@ static char signingkey[1000];
struct tag_filter {
const char *pattern;
int lines;
+ struct commit_list *with_commit;
};
#define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----"
@@ -34,7 +35,6 @@ static int show_reference(const char *refname, const
unsigned char *sha1,
int flag, void *cb_data)
{
struct tag_filter *filter = cb_data;
-
if (!fnmatch(filter->pattern, refname, 0)) {
int i;
unsigned long size;
@@ -42,6 +42,18 @@ static int show_reference(const char *refname, const
unsigned char *sha1,
char *buf, *sp, *eol;
size_t len;
+ if (filter->with_commit) {
+ struct commit *commit;
+
+ commit = lookup_commit_reference_gently(sha1, 1);
+ if (!commit) {
+ error("tag '%s' does not point at a commit", refname);
+ return 0;
+ }
+ if (!has_commit(commit, filter->with_commit))
+ return 0;
+ }
+
if (!filter->lines) {
printf("%s\n", refname);
return 0;
@@ -79,7 +91,8 @@ static int show_reference(const char *refname, const
unsigned char *sha1,
return 0;
}
-static int list_tags(const char *pattern, int lines)
+static int list_tags(const char *pattern, int lines,
+ struct commit_list *with_commit)
{
struct tag_filter filter;
@@ -88,6 +101,7 @@ static int list_tags(const char *pattern, int lines)
filter.pattern = pattern;
filter.lines = lines;
+ filter.with_commit = with_commit;
for_each_tag_ref(show_reference, (void *) &filter);
@@ -360,6 +374,7 @@ int cmd_tag(int argc, const char **argv, const char
*prefix)
list = 0, delete = 0, verify = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
+ struct commit_list *with_commit = NULL;
struct option options[] = {
OPT_BOOLEAN('l', NULL, &list, "list tag names"),
{ OPTION_INTEGER, 'n', NULL, &lines, NULL,
@@ -378,6 +393,14 @@ int cmd_tag(int argc, const char **argv, const char
*prefix)
OPT_STRING('u', NULL, &keyid, "key-id",
"use another key to sign the tag"),
OPT_BOOLEAN('f', NULL, &force, "replace the tag if exists"),
+
+ OPT_GROUP("Tag listing options"),
+ {
+ OPTION_CALLBACK, 0, "contains", &with_commit, "commit",
+ "print only tags that contain the commit",
+ PARSE_OPT_LASTARG_DEFAULT,
+ parse_opt_with_commit, (intptr_t)"HEAD",
+ },
OPT_END()
};
@@ -402,9 +425,12 @@ int cmd_tag(int argc, const char **argv, const char
*prefix)
if (list + delete + verify > 1)
usage_with_options(git_tag_usage, options);
if (list)
- return list_tags(argv[0], lines == -1 ? 0 : lines);
+ return list_tags(argv[0], lines == -1 ? 0 : lines,
+ with_commit);
if (lines != -1)
die("-n option is only allowed with -l.");
+ if (with_commit)
+ die("--contains option is only allowed with -l.");
if (delete)
return for_each_tag_name(argv, delete_tag);
if (verify)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index f377fea..69501e2 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1090,6 +1090,121 @@ test_expect_success 'filename for the message is
relative to cwd' '
git cat-file tag tag-from-subdir-2 | grep "in sub directory"
'
+# create a few more commits to test --contains
+
+hash1=$(git rev-parse HEAD)
+
+test_expect_success 'creating second commit and tag' '
+ echo foo-2.0 >foo &&
+ git add foo &&
+ git commit -m second
+ git tag v2.0
+'
+
+hash2=$(git rev-parse HEAD)
+
+test_expect_success 'creating third commit without tag' '
+ echo foo-dev >foo &&
+ git add foo &&
+ git commit -m third
+'
+
+hash3=$(git rev-parse HEAD)
+
+# simple linear checks of --continue
+
+cat > expected <<EOF
+v0.2.1
+v1.0
+v1.0.1
+v1.1.3
+v2.0
+EOF
+
+test_expect_success 'checking that first commit is in all tags (hash)' "
+ git tag -l --contains $hash1 v* >actual
+ test_cmp expected actual
+"
+
+# other ways of specifying the commit
+test_expect_success 'checking that first commit is in all tags (tag)' "
+ git tag -l --contains v1.0 v* >actual
+ test_cmp expected actual
+"
+
+test_expect_success 'checking that first commit is in all tags
(relative)' "
+ git tag -l --contains HEAD~2 v* >actual
+ test_cmp expected actual
+"
+
+cat > expected <<EOF
+v2.0
+EOF
+
+test_expect_success 'checking that second commit only has one tag' "
+ git tag -l --contains $hash2 v* >actual
+ test_cmp expected actual
+"
+
+
+cat > expected <<EOF
+EOF
+
+test_expect_success 'checking that third commit has no tags' "
+ git tag -l --contains $hash3 v* >actual
+ test_cmp expected actual
+"
+
+# how about a simple merge?
+
+test_expect_success 'creating simple branch' '
+ git branch stable v2.0 &&
+ git checkout stable &&
+ echo foo-3.0 > foo &&
+ git commit foo -m fourth
+ git tag v3.0
+'
+
+hash4=$(git rev-parse HEAD)
+
+cat > expected <<EOF
+v3.0
+EOF
+
+test_expect_success 'checking that branch head only has one tag' "
+ git tag -l --contains $hash4 v* >actual
+ test_cmp expected actual
+"
+
+test_expect_success 'merging original branch into this branch' '
+ git merge --strategy=ours master &&
+ git tag v4.0
+'
+
+cat > expected <<EOF
+v4.0
+EOF
+
+test_expect_success 'checking that original branch head has one tag now' "
+ git tag -l --contains $hash3 v* >actual
+ test_cmp expected actual
+"
+
+cat > expected <<EOF
+v0.2.1
+v1.0
+v1.0.1
+v1.1.3
+v2.0
+v3.0
+v4.0
+EOF
+
+test_expect_success 'checking that initial commit is in all tags' "
+ git tag -l --contains $hash1 v* >actual
+ test_cmp expected actual
+"
+
# mixing modes and options:
test_expect_success 'mixing incompatibles modes and options is forbidden' '
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/3] Make has_commit non-static
From: Jake Goulding @ 2009-01-23 0:48 UTC (permalink / raw)
To: git
In-Reply-To: <1232671630-19683-1-git-send-email-goulding@vivisimo.com>
Moving has_commit from branch to a common location in preparation for
using it in tag.
Signed-off-by: Jake Goulding <goulding@vivisimo.com>
---
builtin-branch.c | 15 ---------------
commit.c | 15 +++++++++++++++
commit.h | 1 +
3 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 82d6fb2..bb42911 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -193,21 +193,6 @@ struct ref_list {
int kinds;
};
-static int has_commit(struct commit *commit, struct commit_list
*with_commit)
-{
- if (!with_commit)
- return 1;
- while (with_commit) {
- struct commit *other;
-
- other = with_commit->item;
- with_commit = with_commit->next;
- if (in_merge_bases(other, &commit, 1))
- return 1;
- }
- return 0;
-}
-
static int append_ref(const char *refname, const unsigned char *sha1,
int flags, void *cb_data)
{
struct ref_list *ref_list = (struct ref_list*)(cb_data);
diff --git a/commit.c b/commit.c
index c99db16..5ccb338 100644
--- a/commit.c
+++ b/commit.c
@@ -705,6 +705,21 @@ struct commit_list *get_merge_bases(struct commit
*one, struct commit *two,
return get_merge_bases_many(one, 1, &two, cleanup);
}
+int has_commit(struct commit *commit, struct commit_list *with_commit)
+{
+ if (!with_commit)
+ return 1;
+ while (with_commit) {
+ struct commit *other;
+
+ other = with_commit->item;
+ with_commit = with_commit->next;
+ if (in_merge_bases(other, &commit, 1))
+ return 1;
+ }
+ return 0;
+}
+
int in_merge_bases(struct commit *commit, struct commit **reference,
int num)
{
struct commit_list *bases, *b;
diff --git a/commit.h b/commit.h
index 3a7b06a..1b8444f 100644
--- a/commit.h
+++ b/commit.h
@@ -133,6 +133,7 @@ extern int is_repository_shallow(void);
extern struct commit_list *get_shallow_commits(struct object_array *heads,
int depth, int shallow_flag, int not_shallow_flag);
+int has_commit(struct commit *, struct commit_list *);
int in_merge_bases(struct commit *, struct commit **, int);
extern int interactive_add(int argc, const char **argv, const char
*prefix);
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/3] Make opt_parse_with_commit non-static
From: Jake Goulding @ 2009-01-23 0:48 UTC (permalink / raw)
To: git
Moving opt_parse_with_commit from branch to a common location in
preparation for using it in tag. Renamed it to correspond to naming
convention of other option parsing functions.
Signed-off-by: Jake Goulding <goulding@vivisimo.com>
---
builtin-branch.c | 20 ++------------------
parse-options.c | 17 +++++++++++++++++
parse-options.h | 1 +
3 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 02fa38f..82d6fb2 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -466,22 +466,6 @@ static void rename_branch(const char *oldname,
const char *newname, int force)
strbuf_release(&newsection);
}
-static int opt_parse_with_commit(const struct option *opt, const char
*arg, int unset)
-{
- unsigned char sha1[20];
- struct commit *commit;
-
- if (!arg)
- return -1;
- if (get_sha1(arg, sha1))
- die("malformed object name %s", arg);
- commit = lookup_commit_reference(sha1);
- if (!commit)
- die("no such commit %s", arg);
- commit_list_insert(commit, opt->value);
- return 0;
-}
-
static int opt_parse_merge_filter(const struct option *opt, const char
*arg, int unset)
{
merge_filter = ((opt->long_name[0] == 'n')
@@ -517,13 +501,13 @@ int cmd_branch(int argc, const char **argv, const
char *prefix)
OPTION_CALLBACK, 0, "contains", &with_commit, "commit",
"print only branches that contain the commit",
PARSE_OPT_LASTARG_DEFAULT,
- opt_parse_with_commit, (intptr_t)"HEAD",
+ parse_opt_with_commit, (intptr_t)"HEAD",
},
{
OPTION_CALLBACK, 0, "with", &with_commit, "commit",
"print only branches that contain the commit",
PARSE_OPT_HIDDEN | PARSE_OPT_LASTARG_DEFAULT,
- opt_parse_with_commit, (intptr_t) "HEAD",
+ parse_opt_with_commit, (intptr_t) "HEAD",
},
OPT__ABBREV(&abbrev),
diff --git a/parse-options.c b/parse-options.c
index 9eb55cc..4c5d09d 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -1,6 +1,7 @@
#include "git-compat-util.h"
#include "parse-options.h"
#include "cache.h"
+#include "commit.h"
#define OPT_SHORT 1
#define OPT_UNSET 2
@@ -506,6 +507,22 @@ int parse_opt_verbosity_cb(const struct option
*opt, const char *arg,
return 0;
}
+int parse_opt_with_commit(const struct option *opt, const char *arg,
int unset)
+{
+ unsigned char sha1[20];
+ struct commit *commit;
+
+ if (!arg)
+ return -1;
+ if (get_sha1(arg, sha1))
+ return error("malformed object name %s", arg);
+ commit = lookup_commit_reference(sha1);
+ if (!commit)
+ return error("no such commit %s", arg);
+ commit_list_insert(commit, opt->value);
+ return 0;
+}
+
/*
* This should really be OPTION_FILENAME type as a part of
* parse_options that take prefix to do this while parsing.
diff --git a/parse-options.h b/parse-options.h
index 034162e..9122905 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -151,6 +151,7 @@ extern int parse_options_end(struct parse_opt_ctx_t
*ctx);
extern int parse_opt_abbrev_cb(const struct option *, const char *, int);
extern int parse_opt_approxidate_cb(const struct option *, const char
*, int);
extern int parse_opt_verbosity_cb(const struct option *, const char *,
int);
+extern int parse_opt_with_commit(const struct option *, const char *, int);
#define OPT__VERBOSE(var) OPT_BOOLEAN('v', "verbose", (var), "be verbose")
#define OPT__QUIET(var) OPT_BOOLEAN('q', "quiet", (var), "be quiet")
--
1.6.0.4
^ permalink raw reply related
* Re: how to force a commit date matching info from a mbox ?
From: Nanako Shiraishi @ 2009-01-23 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list, Christian MICHON
In-Reply-To: <7vljt26fp9.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> Christian MICHON <christian.michon@gmail.com> writes:
>
>> I'd like to force the commit date to match the info/date from the time
>> I received the email (and therefore always get back the right
>> sha1sums).
>>
>> is this possible ?
>
> "am" being a tool to accept patches written in some past to faithfully
> record both author timestamp and committer timestamp, what you seem to
> want is outside of the current scope of the tool.
>
> A patch to butcher "git-am" to copy GIT_COMMITTER_DATE from
> GIT_AUTHOR_DATE and export it should be trivial to implement, though.
>
> Perhaps something like this totally untested patch.
You have test scripts already, but you say it is untested?
I often wanted to have an opposite of what Christian wants. I always have some changes I am holding off, and when I decide to trickle them out to the main repository, I do not want the resulting commit to carry old dates that are recorded in the format-patch output. Instead I want to pretend that I worked on them today. Is this something you can teach git-am and git-rebase to do easily?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Short "git commit $file" syntax fails in the face of a resolved conflict
From: Nanako Shiraishi @ 2009-01-23 0:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nathan Yergler, Michael J Gruber, Asheesh Laroia, git
In-Reply-To: <4978202C.3090703@viscovery.net>
Quoting Johannes Sixt <j.sixt@viscovery.net>:
> Please don't top-post.
>
> Nathan Yergler schrieb:
>> Can you elaborate on why doing -i automatically is a bad idea in this
>> case? [It may really be, I don't pretend to have enough knowledge
>> about git's internals to make a reasoned argument.] This was
>> unexpected behavior for me as I'd always experienced "git add path &&
>> git commit" and "git commit path" as being equivalent and so I assumed
>> they would work equivalently in this situation.
>
> They are not equivalent. 'git add path && git commit' commits changes to
> path *in addition* to what is already staged before you run this command
> sequence. But 'git commit path' commits *only* changes to path, leaving
> other changes that might be staged uncommitted.
>
> It may become obvious why the latter behavior is unwanted if a merge is in
> progress: The merge left changes (and conflicts) in the index; but with
> 'git commit path' you say that you are not interested in what the index has.
Your explanation is a good answer to Nathan's misunderstanding; "git add path && git commit" and "git commit path" are different.
But Nathan's first sentence is a different matter. I do not think it is coming from the same confusion, and I think the question is a valid one. Your answer does not explain why it is a bad idea to change the behavior of "git commit path" to what "git commit -i path" does during a merge.
The answer of course can be "because it changes the behavior people are very much used to."
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: RFC: git diff colorization idea
From: Junio C Hamano @ 2009-01-23 0:32 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git@vger.kernel.org List
In-Reply-To: <53497057-1ADE-4300-9F35-B218959606FE@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> I'm also thinking that perhaps a per-character approach might be
> useful here instead of a per-word one (it would make that last hunk
> look better in the mock-up screenshot that I posted); if I go the per-
> character route then that suggests that "--color-chars" might be the
> right option name, and the color slots would then be
> color.diff.new.char and color.diff.old.char.
>
> Any feedback or suggestions before I get in too deep?
I personally find your "prposal" picture too loud to my eye.
I would have expected you to propose something like this:
| _git_remote ()
| {
|- local subcommands="add rm show prune <red>update</red>"
|+ local subcommands="add <green>rename</green> rm show prune"
| local subcommand=$(__git_find_subcommand "$subcommands")"
| if ...
if the patch were to remove update and add rename, that is. If there is
no deletion but only insertion, you would only see green.
And that way you do not need new color slots. You can use new color and
old color as before, and the coloring will be done to highlight only the
parts that really matter.
If you were to go this route, I suspect that showing the unchanged part on
the preimage line in light gray might make sense, like:
| _git_remote ()
| {
|- <gray>local subcommands="add rm show prune<gray> <red>update</red>"
|+ local subcommands="add <green>rename</green> rm show prune"
| local subcommand=$(__git_find_subcommand "$subcommands")"
| if ...
because there will be the same chars/words on the postimage line anyway.
Just 2c from somebody who does not like colors very much.
^ permalink raw reply
* [PATCH] git-am: implement --reject option passed to git-apply
From: martin f. krafft @ 2009-01-23 0:31 UTC (permalink / raw)
To: git; +Cc: martin f. krafft, penny leach
With --reject, git-am simply passes the --reject option to git-apply and thus
allows people to work with reject files if they so prefer.
The patch does not touch t/t4252-am-options.sh (yet) because I do not really
understand how the testing system works.
Signed-off-by: martin f. krafft <madduck@madduck.net>
---
Documentation/git-am.txt | 2 ++
git-am.sh | 3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 5cbbe76..efd311b 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -12,6 +12,7 @@ SYNOPSIS
'git am' [--signoff] [--keep] [--utf8 | --no-utf8]
[--3way] [--interactive]
[--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
+ [--reject]
[<mbox> | <Maildir>...]
'git am' (--skip | --resolved | --abort)
@@ -63,6 +64,7 @@ default. You could use `--no-utf8` to override this.
-C<n>::
-p<n>::
--directory=<dir>::
+--reject::
These flags are passed to the 'git-apply' (see linkgit:git-apply[1])
program that applies
the patch.
diff --git a/git-am.sh b/git-am.sh
index e20dd88..b1c05c9 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -19,6 +19,7 @@ whitespace= pass it through git-apply
directory= pass it through git-apply
C= pass it through git-apply
p= pass it through git-apply
+reject pass it through git-apply
resolvemsg= override error message when patch failure occurs
r,resolved to be used after a patch failure
skip skip the current patch
@@ -168,6 +169,8 @@ do
git_apply_opt="$git_apply_opt $(sq "$1=$2")"; shift ;;
-C|-p)
git_apply_opt="$git_apply_opt $(sq "$1$2")"; shift ;;
+ --reject)
+ git_apply_opt="$git_apply_opt $1" ;;
--)
shift; break ;;
*)
--
tg: (9a01387..) git-am--reject (depends on: master)
^ permalink raw reply related
* [kha/safe PATCH] completion bugfix: Place double pipes in front of alternate command.
From: Ted Pavlic @ 2009-01-23 0:26 UTC (permalink / raw)
To: gitster, kha; +Cc: git, catalin.marinas, Ted Pavlic
In-Reply-To: <20090122232928.GA23456@diana.vm.bytemark.co.uk>
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
This is a patch against
git://repo.or.cz/stgit/kha.git stable
Unfortunately, the previous "[StGit PATCH 2/2]" had a small bug in it. A
bugfix was posted, but it didn't get picked up in kha/safe. This commit
should be applied against kha/safe to fix the problem.
Alternatively, the patch provided in
<1232642662-12851-1-git-send-email-ted@tedpavlic.com>
is the proper patch to stgit/master.
Sorry for the extra bother.
stgit/completion.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stgit/completion.py b/stgit/completion.py
index 56e81c2..38f0670 100644
--- a/stgit/completion.py
+++ b/stgit/completion.py
@@ -130,7 +130,7 @@ def main_switch(commands):
def install():
return ['complete -o bashdefault -o default -F _stg stg 2>/dev/null \\', [
- 'complete -o default -F _stg stg' ] ]
+ '|| complete -o default -F _stg stg' ] ]
def write_completion(f):
commands = stgit.commands.get_commands(allow_cached = False)
--
1.6.1.213.g28da8
^ permalink raw reply related
* Re: how to force a commit date matching info from a mbox ?
From: Johannes Schindelin @ 2009-01-23 0:21 UTC (permalink / raw)
To: Christian MICHON; +Cc: git list
In-Reply-To: <46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com>
Hi,
On Thu, 22 Jan 2009, Christian MICHON wrote:
> I've a big set of patches in a mbox file: there's sufficient info inside
> for git-am to work.
>
> Yet, each time I do import these, my sha1sums are changing because of
> different commit dates.
>
> I'd like to force the commit date to match the info/date from the time I
> received the email (and therefore always get back the right sha1sums).
>
> is this possible ?
Have you tried setting GIT_COMMITTER_DATE to the given date?
Alternatively, you can always use a commit-message filter with
filter-branch to fix it up.
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox