* [ANNOUNCE] Git 1.7.8.rc1
From: Junio C Hamano @ 2011-11-08 2:56 UTC (permalink / raw)
To: git
A release candidate Git 1.7.8.rc1 is available for testing. Since rc0, we
killed all known regressions. Because there won't be any more new feature
merged until the 1.7.8 final, it is a good time for the coolest kids on
the block to start using the upcoming release before others do.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
f35e5c4410b21710434cb591f4c89843e75bb793 git-1.7.8.rc1.tar.gz
72e27cd397f5ae7b3c9d8bb030a76d7c99cdbb50 git-htmldocs-1.7.8.rc1.tar.gz
95429858e879df3f9425cf1279e03cdec7832379 git-manpages-1.7.8.rc1.tar.gz
Also the following public repositories all have a copy of the v1.7.8.rc1
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
----------------------------------------------------------------
Changes since v1.7.8-rc0 are as follows:
Dan McGee (4):
pack-objects: mark add_to_write_order() as inline
pack-objects: use unsigned int for counter and offset values
pack-objects: rewrite add_descendants_to_write_order() iteratively
pack-objects: don't traverse objects unnecessarily
Erik Faye-Lund (4):
mingw: move poll out of sys-folder
compat/win32/poll.c: upgrade from upstream
upload-archive: use start_command instead of fork
mingw: poll.h is no longer in sys/
Johannes Sixt (1):
name-hash.c: always initialize dir_next pointer
Junio C Hamano (5):
(squash) test for previous
Git 1.7.7.2
Update draft release notes to 1.7.8
receive-pack: do not expect object 0{40} to exist
Git 1.7.8-rc1
Nguyễn Thái Ngọc Duy (2):
pretty.c: free get_header() return value
pretty.c: use original commit message if reencoding fails
Pat Thoyts (1):
t7511: avoid use of reserved filename on Windows.
Pete Wyckoff (1):
git-p4: ignore apple filetype
Sebastian Schuberth (2):
blame.c: Properly initialize strbuf after calling, textconv_object()
blame.c: Properly initialize strbuf after calling textconv_object(), again
Stefan Naewe (2):
t3200: add test case for 'branch -m'
http: don't always prompt for password
Tay Ray Chuan (1):
branch -m: handle no arg properly
Ted Percival (1):
svn: Quote repository root in regex match
Ævar Arnfjörð Bjarmason (2):
t/t6030-bisect-porcelain.sh: use test_i18ngrep
t/t7508-status.sh: use test_i18ncmp
^ permalink raw reply
* [PATCH] Copy resolve_ref() return value for longer use
From: Nguyễn Thái Ngọc Duy @ 2011-11-08 2:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Tony Wang, Nguyễn Thái Ngọc Duy
In-Reply-To: <CACsJy8Aw4_O_GMiK_D=HTENfxGUXTTzCHqM7FkriqU+mQtVWtA@mail.gmail.com>
resolve_ref() may return a pointer to a static buffer. Callers that
use this value outside of a block should copy the value to avoid some
hidden resolve_ref() call that may change the static buffer's value.
The bug found by Tony Wang <wwwjfy@gmail.com> in builtin/merge.c
demonstrates this. The first call is in cmd_merge()
branch = resolve_ref("HEAD", head_sha1, 0, &flag);
Then deep in lookup_commit_or_die() a few lines after, resolve_ref()
may be called again and destroy "branch".
lookup_commit_or_die
lookup_commit_reference
lookup_commit_reference_gently
parse_object
lookup_replace_object
do_lookup_replace_object
prepare_replace_object
for_each_replace_ref
do_for_each_ref
get_loose_refs
get_ref_dir
get_ref_dir
resolve_ref
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/checkout.c | 4 +++-
builtin/commit.c | 3 ++-
builtin/fmt-merge-msg.c | 1 +
builtin/merge.c | 7 +++++--
builtin/notes.c | 1 +
builtin/receive-pack.c | 2 ++
6 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 2a80772..98ddbcd 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -699,7 +699,9 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
unsigned char rev[20];
int flag;
memset(&old, 0, sizeof(old));
- old.path = xstrdup(resolve_ref("HEAD", rev, 0, &flag));
+ old.path = resolve_ref("HEAD", rev, 0, &flag);
+ if (old.path)
+ old.path = xstrdup(old.path);
old.commit = lookup_commit_reference_gently(rev, 1);
if (!(flag & REF_ISSYMREF)) {
free((char *)old.path);
diff --git a/builtin/commit.c b/builtin/commit.c
index c46f2d1..f3a6ed2 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1259,7 +1259,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1,
struct commit *commit;
struct strbuf format = STRBUF_INIT;
unsigned char junk_sha1[20];
- const char *head = resolve_ref("HEAD", junk_sha1, 0, NULL);
+ const char *head;
struct pretty_print_context pctx = {0};
struct strbuf author_ident = STRBUF_INIT;
struct strbuf committer_ident = STRBUF_INIT;
@@ -1304,6 +1304,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1,
rev.diffopt.break_opt = 0;
diff_setup_done(&rev.diffopt);
+ head = resolve_ref("HEAD", junk_sha1, 0, NULL);
printf("[%s%s ",
!prefixcmp(head, "refs/heads/") ?
head + 11 :
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 7e2f225..cab50e0 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -268,6 +268,7 @@ static int do_fmt_merge_msg(int merge_title, struct strbuf *in,
die("No current branch");
if (!prefixcmp(current_branch, "refs/heads/"))
current_branch += 11;
+ current_branch = xstrdup(current_branch);
/* get a line */
while (pos < in->len) {
diff --git a/builtin/merge.c b/builtin/merge.c
index dffd5ec..6865cb7 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1096,8 +1096,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
* current branch.
*/
branch = resolve_ref("HEAD", head_sha1, 0, &flag);
- if (branch && !prefixcmp(branch, "refs/heads/"))
- branch += 11;
+ if (branch) {
+ if (!prefixcmp(branch, "refs/heads/"))
+ branch += 11;
+ branch = xstrdup(branch);
+ }
if (!branch || is_null_sha1(head_sha1))
head_commit = NULL;
else
diff --git a/builtin/notes.c b/builtin/notes.c
index f8e437d..c6e4c86 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -828,6 +828,7 @@ static int merge_commit(struct notes_merge_options *o)
o->local_ref = resolve_ref("NOTES_MERGE_REF", sha1, 0, NULL);
if (!o->local_ref)
die("Failed to resolve NOTES_MERGE_REF");
+ o->local_ref = xstrdup(o->local_ref);
if (notes_merge_commit(o, t, partial, sha1))
die("Failed to finalize notes merge");
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 7ec68a1..6065bf0 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -696,6 +696,8 @@ static void execute_commands(struct command *commands, const char *unpacker_erro
check_aliased_updates(commands);
head_name = resolve_ref("HEAD", sha1, 0, NULL);
+ if (head_name)
+ head_name = xstrdup(head_name);
for (cmd = commands; cmd; cmd = cmd->next)
if (!cmd->skip_update)
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* Re: git-apply that handles rejects like merge conflicts
From: Junio C Hamano @ 2011-11-07 23:45 UTC (permalink / raw)
To: Jeff King; +Cc: Ori Avtalion, git
In-Reply-To: <20111107225508.GB28188@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> In the general case, you can't represent all failed hunks with conflict
> markers, can you?
Conflict markers come from the use of a 3-way merge, and if you were to do
a 3-way merge, by definition, you would need some way to tell where the
preimage of the patch and the target tree you are attempting to apply the
patch forked from. That's done by fall-back-3way in "am -3".
You _could_ lift that logic out of "am -3", but I do not think it is worth
the effort to do so (IOW, I do not see a reason to avoid "am -3").
If you do not want to create a commit for whatever reason, then you can
"reset --soft" back.
^ permalink raw reply
* Re: pretty placeholders for reflog entries
From: Junio C Hamano @ 2011-11-07 23:41 UTC (permalink / raw)
To: Jeff King; +Cc: Jack Nagel, git
In-Reply-To: <20111107224556.GA28188@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It would be a little nicer to provide explicit date placeholders, but we
> can't quite make them match the author-date specifiers, because "gd" is
> taken. We could add %gt, %gr, etc. But in the long run, I'd like to
> move to considering most of %ar, %at, etc to be historical, and have
> something like "%ad(short)" be the official way of picking different
> date formats[1]. And then the reflog placeholders could learn
> "%gt(short)". So making more reflog placeholders right now just feels
> like cluttering a namespace I'd like to get changed eventually.
I tend to agree with the direction.
As we are not adding anything new before the 1.7.8 final, I'd rather ask
you to hold onto this and other changes in your footnote, instead of
having me to carry them in 'pu', which is an integration branch even less
official than it would otherwise be during the freeze period.
^ permalink raw reply
* Re: git-apply that handles rejects like merge conflicts
From: Ori Avtalion @ 2011-11-07 23:18 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111107225508.GB28188@sigill.intra.peff.net>
On 11/08/2011 12:55 AM, Jeff King wrote:
> If it's an actual git diff, the same 3-way trick will yield good
> results, and it would be nice if it were easier to do that trick without
> calling "git am". But if it's not a git diff (i.e., missing the original
> blob information), then you won't be able to do that.
I'm dealing with two codebases that have branched in the past, before
any VCS was used, and now I'm tracking both separately with git. I'm
trying to apply changes from one to the other with format-patch and
git-am/apply. So yeah, no blob info.
> In the general case, you can't represent all failed hunks with conflict
> markers, can you? I'm thinking something where we couldn't find any
> relevant context. You know the lines from the original patch from the
> hunk header, so you can drop the failed content from the patch in the
> right spot. But how do you know how big a conflict marker to make for
> the "current" side? The same number of lines as were in the hunk?
> I think you'd end up with confusing conflict markers.
Personally, I wouldn't object to having both "computable" conflicts, and
the .rej files for hunks that lack context, but I see how that would be
very confusing. :)
-Ori
^ permalink raw reply
* Re: Is there a pdf git manual?
From: Jakub Narebski @ 2011-11-07 23:17 UTC (permalink / raw)
To: Peng Yu; +Cc: git
In-Reply-To: <CABrM6w=ADwdGNKdCWnOKKvrOp=5RZYMSJHU39qY=cMFHj6sg9w@mail.gmail.com>
Peng Yu wrote:
> Jakub Narebski wrote:
>
> > "make pdf" would generate PDF version of (some of) documentation.
>
> I get the pdf generated. When you say 'some of", what is missing from
> the pdf?
I just was not sure if it generates PDF version of all documentation,
though I was reasonably sure that user's manual has PDF version.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-apply that handles rejects like merge conflicts
From: Jeff King @ 2011-11-07 22:55 UTC (permalink / raw)
To: Ori Avtalion; +Cc: git
In-Reply-To: <4EB85768.1060508@avtalion.name>
On Tue, Nov 08, 2011 at 12:10:48AM +0200, Ori Avtalion wrote:
> I'm trying to get git-apply to apply patches, and let me handle the
> conflicts in a way I'm comfortable with -- by staging the "successful"
> hunks and leaving conflict markers in the working tree.
>
> With the available flags, I seem to only be able to have successful
> hunks in the index, and rejected ones in patch-like .rej files.
>
> Is there a way to accomplish this? If not, does anyone think it's a good
> idea?
No, I don't think there's a way to do it now. I do find the conflict
markers the easiest way to mark something up. But most of my "git apply"
use is through "git am", which knows the trick of falling back to a
3-way merge (see fall_back_3way in git-am.sh).
If it's an actual git diff, the same 3-way trick will yield good
results, and it would be nice if it were easier to do that trick without
calling "git am". But if it's not a git diff (i.e., missing the original
blob information), then you won't be able to do that.
In the general case, you can't represent all failed hunks with conflict
markers, can you? I'm thinking something where we couldn't find any
relevant context. You know the lines from the original patch from the
hunk header, so you can drop the failed content from the patch in the
right spot. But how do you know how big a conflict marker to make for
the "current" side? The same number of lines as were in the hunk?
I think you'd end up with confusing conflict markers.
-Peff
^ permalink raw reply
* Re: pretty placeholders for reflog entries
From: Jeff King @ 2011-11-07 22:45 UTC (permalink / raw)
To: Jack Nagel; +Cc: Junio C Hamano, git
In-Reply-To: <CAMYxyaWJO7e8Lg__8N9BhL16mwfQtd-GBuLpBSCYmLMZ3gsMPA@mail.gmail.com>
On Mon, Nov 07, 2011 at 03:41:29PM -0600, Jack Nagel wrote:
> On Mon, Nov 7, 2011 at 3:13 PM, Jeff King <peff@peff.net> wrote:
> > I doubt it would be a very big patch. Want to get your feet wet in git
> > development? :)
>
> I'll certainly give it a shot if I find some free time to do so. Though if
> someone else felt like doing it in the meantime, my feelings wouldn't be
> hurt. =)
Actually, it needed to touch a few ugly corners of the code, so I just
went ahead and did it. The result is below.
-- >8 --
Subject: [PATCH] pretty: give placeholders to reflog identity
When doing a reflog walk, you can get some information about
the reflog (such as the subject line), but not the identity
information (i.e., name and email).
Let's make those available, mimicing the options for author
and committer identity.
Signed-off-by: Jeff King <peff@peff.net>
---
We're still missing date specifiers. However, if you specify a "--date"
flag, then the reflog selector ("%gd") will have the date inside the
curly braces instead of the reflog counter.
It would be a little nicer to provide explicit date placeholders, but we
can't quite make them match the author-date specifiers, because "gd" is
taken. We could add %gt, %gr, etc. But in the long run, I'd like to
move to considering most of %ar, %at, etc to be historical, and have
something like "%ad(short)" be the official way of picking different
date formats[1]. And then the reflog placeholders could learn
"%gt(short)". So making more reflog placeholders right now just feels
like cluttering a namespace I'd like to get changed eventually.
So I think in the meantime, this is a good start.
[1] I floated some patches about 8 months ago, and Will Palmer had some,
too. I really need to take a look at them and push the topic forward.
Documentation/pretty-formats.txt | 4 ++++
pretty.c | 25 +++++++++++++++++++++++++
reflog-walk.c | 12 ++++++++++++
reflog-walk.h | 1 +
t/t6006-rev-list-format.sh | 6 ++++++
5 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 561cc9f..880b6f2 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -132,6 +132,10 @@ The placeholders are:
- '%N': commit notes
- '%gD': reflog selector, e.g., `refs/stash@\{1\}`
- '%gd': shortened reflog selector, e.g., `stash@\{1\}`
+- '%gn': reflog identity name
+- '%gN': reflog identity name (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1])
+- '%ge': reflog identity email
+- '%gE': reflog identity email (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1])
- '%gs': reflog subject
- '%Cred': switch color to red
- '%Cgreen': switch color to green
diff --git a/pretty.c b/pretty.c
index 230fe1c..1580299 100644
--- a/pretty.c
+++ b/pretty.c
@@ -822,6 +822,23 @@ static void rewrap_message_tail(struct strbuf *sb,
c->indent2 = new_indent2;
}
+static int format_reflog_person(struct strbuf *sb,
+ char part,
+ struct reflog_walk_info *log,
+ enum date_mode dmode)
+{
+ const char *ident;
+
+ if (!log)
+ return 2;
+
+ ident = get_reflog_ident(log);
+ if (!ident)
+ return 2;
+
+ return format_person_part(sb, part, ident, strlen(ident), dmode);
+}
+
static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
void *context)
{
@@ -963,6 +980,14 @@ static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
if (c->pretty_ctx->reflog_info)
get_reflog_message(sb, c->pretty_ctx->reflog_info);
return 2;
+ case 'n':
+ case 'N':
+ case 'e':
+ case 'E':
+ return format_reflog_person(sb,
+ placeholder[1],
+ c->pretty_ctx->reflog_info,
+ c->pretty_ctx->date_mode);
}
return 0; /* unknown %g placeholder */
case 'N':
diff --git a/reflog-walk.c b/reflog-walk.c
index 5d81d39..590737e 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -291,6 +291,18 @@ void get_reflog_message(struct strbuf *sb,
strbuf_add(sb, info->message, len);
}
+const char *get_reflog_ident(struct reflog_walk_info *reflog_info)
+{
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
+ struct reflog_info *info;
+
+ if (!commit_reflog)
+ return NULL;
+
+ info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ return info->email;
+}
+
void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
enum date_mode dmode)
{
diff --git a/reflog-walk.h b/reflog-walk.h
index 7bd2cd4..afb1ae3 100644
--- a/reflog-walk.h
+++ b/reflog-walk.h
@@ -14,6 +14,7 @@ extern void show_reflog_message(struct reflog_walk_info *info, int,
enum date_mode);
extern void get_reflog_message(struct strbuf *sb,
struct reflog_walk_info *reflog_info);
+extern const char *get_reflog_ident(struct reflog_walk_info *reflog_info);
extern void get_reflog_selector(struct strbuf *sb,
struct reflog_walk_info *reflog_info,
enum date_mode dmode,
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index d918cc0..4442790 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -267,6 +267,12 @@ test_expect_success '%gd shortens ref name' '
test_cmp expect.gd-short actual.gd-short
'
+test_expect_success 'reflog identity' '
+ echo "C O Mitter:committer@example.com" >expect &&
+ git log -g -1 --format="%gn:%ge" >actual &&
+ test_cmp expect actual
+'
+
test_expect_success 'oneline with empty message' '
git commit -m "dummy" --allow-empty &&
git commit -m "dummy" --allow-empty &&
--
1.7.7.2.7.g9f96f.dirty
^ permalink raw reply related
* Re: [PATCH 3/4] git-p4: importing labels should cope with missing owner
From: Pete Wyckoff @ 2011-11-07 22:34 UTC (permalink / raw)
To: Luke Diamand; +Cc: git
In-Reply-To: <1320701799-26071-4-git-send-email-luke@diamand.org>
luke@diamand.org wrote on Mon, 07 Nov 2011 21:36 +0000:
> In p4, the Owner field is optional. If it is missing,
> construct something sensible rather than crashing.
Nice. One question:
> owner = labelDetails["Owner"]
> tagger = ""
> - if author in self.users:
> + if not owner:
> + tagger = "%s <a@b> %s %s" % (self.p4UserId(), epoch, self.tz)
> + elif author in self.users:
> tagger = "%s %s %s" % (self.users[owner], epoch, self.tz)
> else:
> tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
We trust p4 always returns a key "Owner", but it could
be an empty string? I'm okay with that, if that's how it works.
Should be "author in self.users"? I'm looking at the
creation of the committer string above, and guessing
that we try to use owner, and if that doesn't exist, try
to use author just like as above, so something like:
if owner:
if owner in self.users:
email = self.users[owner]
else:
email = "%s <a@b>" % owner
else:
if author in self.users:
email = self.users[author]
else:
email = "%s <a@b>" % author
I could misunderstand this.
Maybe that lookup in self.users[] and <a@b> default wants to
have a function since it will be repeated three times now.
Ack to the whole series.
-- Pete
^ permalink raw reply
* Re: [PATCH 3/3] grep: get rid of useless x < 0 comparison on an enum member
From: Jonathan Nieder @ 2011-11-07 22:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, git, Jim Meyering,
Fredrik Gustafsson, Andreas Schwab
In-Reply-To: <7vd3d31u4e.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> With the removal of the check, you _have_ to rely on static analyzers to
> do the _right thing_, but if you have static analyzers that do the right
> thing, you do not have to have such a workaround to begin with.
No, automatic static analyzers will not help you avoid using an
uninitialized enum value here (well, I guess they could, but I don't
believe gcc or clang is nearly smart enough for that). The only
replacement for the check is (1) humans and (2) valgrind.
In this particular case, as you mentioned before, (1) seems to be
quite sufficient.
^ permalink raw reply
* git-apply that handles rejects like merge conflicts
From: Ori Avtalion @ 2011-11-07 22:10 UTC (permalink / raw)
To: git
Hey,
I'm trying to get git-apply to apply patches, and let me handle the
conflicts in a way I'm comfortable with -- by staging the "successful"
hunks and leaving conflict markers in the working tree.
With the available flags, I seem to only be able to have successful
hunks in the index, and rejected ones in patch-like .rej files.
Is there a way to accomplish this? If not, does anyone think it's a good
idea?
-Ori
^ permalink raw reply
* Re: A Python script to put CTAN into git (from DVDs)
From: Jonathan Fine @ 2011-11-07 22:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: python-list, git
In-Reply-To: <m3ipmv38o2.fsf@localhost.localdomain>
On 07/11/11 21:49, Jakub Narebski wrote:
[snip]
> But now I understand that you are just building tree objects, and
> creating references to them (with implicit ordering given by names,
> I guess). This is to be a start of further work, isn't it?
Yes, that's exactly the point, and my apologies if I was not clear enough.
I'll post again when I've finished the script and performed placed
several years of DVD into git. Then the discussion will be more
concrete - we have this tree, how do we make it more useful.
Thank you for your contributions, particularly telling me about gitpan.
--
Jonathan
^ permalink raw reply
* Re: A Python script to put CTAN into git (from DVDs)
From: Jakub Narebski @ 2011-11-07 21:50 UTC (permalink / raw)
To: Jonathan Fine; +Cc: python-list, git
In-Reply-To: <4EB83DDD.1080103@pytex.org>
The following message is a courtesy copy of an article
that has been posted to comp.text.tex as well.
Jonathan Fine <jfine@pytex.org> writes:
> On 06/11/11 20:28, Jakub Narebski wrote:
>
> > Note that for gitPAN each "distribution" (usually but not always
> > corresponding to single Perl module) is in separate repository.
> > The dependencies are handled by CPAN / CPANPLUS / cpanm client
> > (i.e. during install).
>
> Thank you for your interest, Jakub, and also for this information.
> With TeX there's a difficult which Perl, I think, does not have. With
> TeX we process documents, which may demand specific versions of
> packages. LaTeX users are concerned that move on to a later version
> will cause documents to break.
How you can demand specific version of package?
In the "\usepackage[options]{packages}[version]" LaTeX command the
<version> argument specifies _minimal_ (oldest) version. The same
is true for Perl "use Module VERSION LIST".
Nevertheless while with "use Module VERSION" / "use Module VERSION LIST"
you can request minimal version of Perl Module, the META build-time spec
can include requirement of exact version of required package:
http://p3rl.org/CPAN::Meta::Spec
Version Ranges
~~~~~~~~~~~~~~
Some fields (prereq, optional_features) indicate the particular
version(s) of some other module that may be required as a
prerequisite. This section details the Version Range type used to
provide this information.
The simplest format for a Version Range is just the version number
itself, e.g. 2.4. This means that *at least* version 2.4 must be
present. To indicate that *any* version of a prerequisite is okay,
even if the prerequisite doesn't define a version at all, use the
version 0.
Alternatively, a version range *may* use the operators < (less than),
<= (less than or equal), > (greater than), >= (greater than or
equal), == (equal), and != (not equal). For example, the
specification < 2.0 means that any version of the prerequisite less
than 2.0 is suitable.
For more complicated situations, version specifications *may* be
AND-ed together using commas. The specification >= 1.2, != 1.5, <
2.0 indicates a version that must be *at least* 1.2, *less than* 2.0,
and *not equal to* 1.5.
> > Putting all DVD (is it "TeX Live" DVD by the way?) into single
> > repository would put quite a bit of stress to git; it was created for
> > software development (although admittedly of large project like Linux
> > kernel), not 4GB+ trees.
>
> I'm impressed by how well git manages it. It took about 15 minutes to
> build the 4GB tree, and it was disk speed rather than CPU which was
> the bottleneck.
I still think that using modified contrib/fast-import/import-zips.py
(or import-tars.perl, or import-directories.perl) would be a better
solution here...
[...]
> We may be at cross purposes. My first task is get the DVD tree into
> git, performing necessary transformations such as expanding zip files
> along the way. Breaking the content into submodules can, I believe,
> be done afterwards.
'reposurgeon' might help there... or might not. Same with git-subtree
tool.
But now I understand that you are just building tree objects, and
creating references to them (with implicit ordering given by names,
I guess). This is to be a start of further work, isn't it?
> With DVDs from several years it could take several hours to load
> everything into git. For myself, I'd like to do that once, more or
> less as a batch process, and then move on to the more interesting
> topics. Getting the DVD contents into git is already a significant
> piece of work.
>
> Once done, I can them move on to what you're interested in, which is
> organising the material. And I hope that others in the TeX community
> will get involved with that, because I'm not building this repository
> just for myself.
[...]
> > > In addition, many TeX users have a TeX DVD. If they import it into a
> > > git repository (using for example my script) then the update from 2011
> > > to 2012 would require much less bandwidth.
> >
> > ???
>
> A quick way to bring your TeX distribution up to date is to do a delta
> with a later distribution, and download the difference. That's what
> git does, and it does it well. So I'm keen to convert a TeX DVD into
> a git repository, and then differences can be downloaded.
Here perhaps you should take a look at git-based 'bup' backup system.
Anyway I am not sure if for git to be able to generate deltas well you
have to have DAG of commits, so Git can notice what you have and what
you have not. Trees might be not enough here. (!)
> > Commit = tree + parent + metadata.
>
> Actually, any number of parents, including none. What metadata do I
> have to provide? At this time nothing, I think, beyond that provided
> by the name of a reference (to the root of a tree).
Metadata = commit message (here you can e.g. put the official name of
DVD), author and committer info (name, email, date and time, timezone;
date and time you can get from mtime / creation time of DVD).
[cut]
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH 3/3] grep: get rid of useless x < 0 comparison on an enum member
From: Junio C Hamano @ 2011-11-07 21:48 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason, git,
Jim Meyering, Fredrik Gustafsson, Andreas Schwab
In-Reply-To: <20111107213219.GA13537@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> So, the purpose of this patch was to work around this common bug in
> static analyzers.
I fail to see how it could be even considered a work around.
If you do not use static analyzers, you do not have to do such a change,
and the resulting code would (not the "negative" side, but the "positive"
side) catch real bugs when somebody screwes up and stuffs a bogus oob
value in p->field.
With the removal of the check, you _have_ to rely on static analyzers to
do the _right thing_, but if you have static analyzers that do the right
thing, you do not have to have such a workaround to begin with.
^ permalink raw reply
* Re: pretty placeholders for reflog entries
From: Jack Nagel @ 2011-11-07 21:41 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111107211325.GB7380@sigill.intra.peff.net>
On Mon, Nov 7, 2011 at 3:13 PM, Jeff King <peff@peff.net> wrote:
> I doubt it would be a very big patch. Want to get your feet wet in git
> development? :)
I'll certainly give it a shot if I find some free time to do so. Though if
someone else felt like doing it in the meantime, my feelings wouldn't be
hurt. =)
Jack
^ permalink raw reply
* [PATCH 4/4] git-p4: add test for p4 labels
From: Luke Diamand @ 2011-11-07 21:36 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1320701799-26071-1-git-send-email-luke@diamand.org>
Add basic test of p4 label import. Checks label import and
import with shell metachars; labels with different length
descriptions.
---
t/t9804-git-p4-label.sh | 73 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 73 insertions(+), 0 deletions(-)
create mode 100755 t/t9804-git-p4-label.sh
diff --git a/t/t9804-git-p4-label.sh b/t/t9804-git-p4-label.sh
new file mode 100755
index 0000000..eba3521
--- /dev/null
+++ b/t/t9804-git-p4-label.sh
@@ -0,0 +1,73 @@
+test_description='git-p4 p4 label tests'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d' '
+ start_p4d
+'
+
+# Basic p4 label tests.
+#
+# Note: can't have more than one label per commit - others
+# are silently discarded.
+#
+test_expect_success 'basic p4 labels' '
+ test_when_finished cleanup_git &&
+ (
+ cd "$cli" &&
+ mkdir -p main &&
+
+ echo f1 >main/f1 &&
+ p4 add main/f1 &&
+ p4 submit -d "main/f1" &&
+
+ echo f2 >main/f2 &&
+ p4 add main/f2 &&
+ p4 submit -d "main/f2" &&
+
+ echo f3 >main/file_with_\$metachar &&
+ p4 add main/file_with_\$metachar &&
+ p4 submit -d "file with metachar" &&
+
+ p4 tag -l tag_f1_only main/f1 &&
+ p4 tag -l tag_with\$_shell_char main/... &&
+
+ echo f4 >main/f4 &&
+ p4 add main/f4 &&
+ p4 submit -d "main/f4" &&
+
+ p4 label -i <<-EOF &&
+ Label: long_label
+ Description:
+ A Label first line
+ A Label second line
+ View: //depot/...
+ EOF
+
+ p4 tag -l long_label ... &&
+
+ p4 labels ... &&
+
+ cd "$git" &&
+ pwd &&
+ "$GITP4" clone --dest=. --detect-labels //depot@all &&
+
+ git tag &&
+ git tag >taglist &&
+ test_line_count = 3 taglist &&
+
+ cd main &&
+ git checkout tag_tag_f1_only &&
+ ! test -f f2 &&
+ git checkout tag_tag_with\$_shell_char &&
+ test -f f1 && test -f f2 && test -f file_with_\$metachar &&
+
+ git show tag_long_label | grep -q "A Label second line"
+ )
+'
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.7.295.g34dd4
^ permalink raw reply related
* [PATCH 3/4] git-p4: importing labels should cope with missing owner
From: Luke Diamand @ 2011-11-07 21:36 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1320701799-26071-1-git-send-email-luke@diamand.org>
In p4, the Owner field is optional. If it is missing,
construct something sensible rather than crashing.
---
contrib/fast-import/git-p4 | 45 +++++++++++++++++++++++--------------------
1 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 02f0f54..d97f927 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -553,6 +553,27 @@ class Command:
def __init__(self):
self.usage = "usage: %prog [options]"
self.needsGit = True
+ self.myP4UserId = None
+
+ def p4UserId(self):
+ if self.myP4UserId:
+ return self.myP4UserId
+
+ results = p4CmdList("user -o")
+ for r in results:
+ if r.has_key('User'):
+ self.myP4UserId = r['User']
+ return r['User']
+ die("Could not find your p4 user id")
+
+ def p4UserIsMe(self, p4User):
+ # return True if the given p4 user is actually me
+ me = self.p4UserId()
+ if not p4User or p4User != me:
+ return False
+ else:
+ return True
+
class P4UserMap:
def __init__(self):
@@ -694,7 +715,6 @@ class P4Submit(Command, P4UserMap):
self.verbose = False
self.preserveUser = gitConfig("git-p4.preserveUser").lower() == "true"
self.isWindows = (platform.system() == "Windows")
- self.myP4UserId = None
def check(self):
if len(p4CmdList("opened ...")) > 0:
@@ -802,25 +822,6 @@ class P4Submit(Command, P4UserMap):
return 1
return 0
- def p4UserId(self):
- if self.myP4UserId:
- return self.myP4UserId
-
- results = p4CmdList("user -o")
- for r in results:
- if r.has_key('User'):
- self.myP4UserId = r['User']
- return r['User']
- die("Could not find your p4 user id")
-
- def p4UserIsMe(self, p4User):
- # return True if the given p4 user is actually me
- me = self.p4UserId()
- if not p4User or p4User != me:
- return False
- else:
- return True
-
def prepareSubmitTemplate(self):
# remove lines in the Files section that show changes to files outside the depot path we're committing into
template = ""
@@ -1506,7 +1507,9 @@ class P4Sync(Command, P4UserMap):
owner = labelDetails["Owner"]
tagger = ""
- if author in self.users:
+ if not owner:
+ tagger = "%s <a@b> %s %s" % (self.p4UserId(), epoch, self.tz)
+ elif author in self.users:
tagger = "%s %s %s" % (self.users[owner], epoch, self.tz)
else:
tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
--
1.7.7.295.g34dd4
^ permalink raw reply related
* [PATCH 2/4] git-p4: cope with labels with empty descriptions
From: Luke Diamand @ 2011-11-07 21:36 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1320701799-26071-1-git-send-email-luke@diamand.org>
Use an explicit length for the data in a label, rather
than EOT, so that labels with empty descriptions are
passed through correctly.
---
contrib/fast-import/git-p4 | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index bcac6ec..02f0f54 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1511,9 +1511,11 @@ class P4Sync(Command, P4UserMap):
else:
tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
self.gitStream.write("tagger %s\n" % tagger)
- self.gitStream.write("data <<EOT\n")
- self.gitStream.write(labelDetails["Description"])
- self.gitStream.write("EOT\n\n")
+
+ description = labelDetails["Description"]
+ self.gitStream.write("data %d\n" % len(description))
+ self.gitStream.write(description)
+ self.gitStream.write("\n")
else:
if not self.silent:
--
1.7.7.295.g34dd4
^ permalink raw reply related
* [PATCH 1/4] git-p4: handle p4 branches and labels containing shell chars
From: Luke Diamand @ 2011-11-07 21:36 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1320701799-26071-1-git-send-email-luke@diamand.org>
Don't use shell expansion when detecting branches, as it will
fail if the branch name contains a shell metachar. Similarly
for labels.
Add additional test for branches with shell metachars.
---
contrib/fast-import/git-p4 | 8 +++---
t/t9801-git-p4-branch.sh | 48 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index b975d67..bcac6ec 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -793,7 +793,7 @@ class P4Submit(Command, P4UserMap):
def canChangeChangelists(self):
# check to see if we have p4 admin or super-user permissions, either of
# which are required to modify changelists.
- results = p4CmdList("protects %s" % self.depotPath)
+ results = p4CmdList(["protects", self.depotPath])
for r in results:
if r.has_key('perm'):
if r['perm'] == 'admin':
@@ -1528,7 +1528,7 @@ class P4Sync(Command, P4UserMap):
def getLabels(self):
self.labels = {}
- l = p4CmdList("labels %s..." % ' '.join (self.depotPaths))
+ l = p4CmdList(["labels", "%s..." % ' '.join (self.depotPaths)])
if len(l) > 0 and not self.silent:
print "Finding files belonging to labels in %s" % `self.depotPaths`
@@ -1570,7 +1570,7 @@ class P4Sync(Command, P4UserMap):
command = "branches"
for info in p4CmdList(command):
- details = p4Cmd("branch -o %s" % info["branch"])
+ details = p4Cmd(["branch", "-o", info["branch"]])
viewIdx = 0
while details.has_key("View%s" % viewIdx):
paths = details["View%s" % viewIdx].split(" ")
@@ -1708,7 +1708,7 @@ class P4Sync(Command, P4UserMap):
sourceRef = self.gitRefForBranch(sourceBranch)
#print "source " + sourceBranch
- branchParentChange = int(p4Cmd("changes -m 1 %s...@1,%s" % (sourceDepotPath, firstChange))["change"])
+ branchParentChange = int(p4Cmd(["changes", "-m", "1", "%s...@1,%s" % (sourceDepotPath, firstChange)])["change"])
#print "branch parent: %s" % branchParentChange
gitParent = self.gitCommitByP4Change(sourceRef, branchParentChange)
if len(gitParent) > 0:
diff --git a/t/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh
index a25f18d..bd08dff 100755
--- a/t/t9801-git-p4-branch.sh
+++ b/t/t9801-git-p4-branch.sh
@@ -226,6 +226,54 @@ test_expect_success 'git-p4 clone simple branches' '
)
'
+# Create a branch with a shell metachar in its name
+#
+# 1. //depot/main
+# 2. //depot/branch$3
+
+test_expect_success 'branch with shell char' '
+ test_when_finished cleanup_git &&
+ test_create_repo "$git" &&
+ (
+ cd "$cli" &&
+
+ mkdir -p main &&
+
+ echo f1 >main/f1 &&
+ p4 add main/f1 &&
+ p4 submit -d "main/f1" &&
+
+ p4 integrate //depot/main/... //depot/branch\$3/... &&
+ p4 submit -d "integrate main to branch\$3" &&
+
+ echo f1 >branch\$3/shell_char_branch_file &&
+ p4 add branch\$3/shell_char_branch_file &&
+ p4 submit -d "branch\$3/shell_char_branch_file" &&
+
+ p4 branch -i <<-EOF &&
+ Branch: branch\$3
+ View: //depot/main/... //depot/branch\$3/...
+ EOF
+
+ p4 edit main/f1 &&
+ echo "a change" >> main/f1 &&
+ p4 submit -d "a change" main/f1 &&
+
+ p4 integrate -b branch\$3 &&
+ p4 resolve -am branch\$3/... &&
+ p4 submit -d "integrate main to branch\$3" &&
+
+ cd "$git" &&
+
+ git config git-p4.branchList main:branch\$3 &&
+ "$GITP4" clone --dest=. --detect-branches //depot@all &&
+ git log --all --graph --decorate --stat &&
+ git reset --hard p4/depot/branch\$3 &&
+ test -f shell_char_branch_file &&
+ test -f f1
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.7.7.295.g34dd4
^ permalink raw reply related
* [RFC/PATCH 0/4] git-p4: small fixes to branches and labels; tests
From: Luke Diamand @ 2011-11-07 21:36 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
This is a small set of patches to git-p4 to fix a couple of issues with
branches and labels.
Firstly, I've added the fixes needed so that branches and labels can
contain shell metacharacters (missed from the previous series). Added
a test case for this.
In adding the test case for labels I also found a few other small bugs
in the label handling:
- labels missing a description or "EOT" in their text cause problems;
- labels without an owner cause problems.
I also noticed, but did not fix, that you can't have more than one label
per commit (the others are silently dropped) and the documentation for
branch import could be improved.
Luke Diamand (4):
git-p4: handle p4 branches and labels containing shell chars
git-p4: cope with labels with empty descriptions
git-p4: importing labels should cope with missing owner
git-p4: add test for p4 labels
contrib/fast-import/git-p4 | 61 ++++++++++++++++++++-----------------
t/t9801-git-p4-branch.sh | 48 +++++++++++++++++++++++++++++
t/t9804-git-p4-label.sh | 73 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 154 insertions(+), 28 deletions(-)
create mode 100755 t/t9804-git-p4-label.sh
--
1.7.7.295.g34dd4
^ permalink raw reply
* Re: [PATCH 3/3] grep: get rid of useless x < 0 comparison on an enum member
From: Jonathan Nieder @ 2011-11-07 21:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, git, Jim Meyering,
Fredrik Gustafsson, Andreas Schwab
In-Reply-To: <7vlirr1vi5.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> [jn: drop the GREP_HEADER_FIELD_MAX <= p->field check, too,
>> for symmetry]
>
> Umm, why is this removal of defensive programming practice an improvement?
Checking "p->filed < 0" makes static analyzers complain. There's no
clean way I know of[*] to get them to shut up and keep the check. The
fundamental question is whether the -Wtype-limits check is worth it or
not:
- on one hand, it catches real bugs, such as the mistaken check for
negative size_t Ævar mentioned;
- on the other hand, it trips for cases like this in which the type
only happened to be unsigned on the build platform. I consider
that a gcc bug (and apparently clang shares it) --- see
<http://bugs.debian.org/615525>.
So, the purpose of this patch was to work around this common bug in
static analyzers.
Checking "GREP_HEADER_FIELD_MAX <= p->field" without checking for
"p->field < 0", like the original patch did, would be only checking
half of what it intends to and not add any real guarantees. And
more importantly, it would be distracting to people like me and
Andreas who would wonder "why doesn't this check p->field < 0, too?".
I guess the commit message should have said
grep: remove a defensive check to work around common static analyzer bug
> This part is mostly my code and because I know what I wrote is almost
> always perfect, so I do not think there is any real harm done, but still...
Heh.
[*] There are plenty of cryptic, hackish ways possible, though. :)
if ((size_t) p->field >= GREP_HEADER_FIELD_MAX)
die(...);
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Jeff King @ 2011-11-07 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, git
In-Reply-To: <7vhb2f1v7g.fsf@alter.siamese.dyndns.org>
On Mon, Nov 07, 2011 at 01:25:23PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > That makes sense. But I think it fits in with git's current UI to do
> > this via a combination of push options and refspecs. Even if we want to
> > wrap it in some "git remote" command for convenience, I think what
> > you're asking should be implemented as part of "git push".
>
> Yeah, I think it makes sense to give --prune to "push" just like "fetch"
> already has. These two are the primary (and in the ideal world, only)
> operations that talk to the outside world. "remote add -f" might have been
> a tempting "convenience" feature, but I personally think it probably was a
> mistake for the exact reason that letting anything but "push" and "fetch"
> talk to the outside world just invites more confusion. There does not have
> to be 47 different ways to do the same thing.
I don't mind "add -f" too much, which is at least very clear that it is
simply a convenience feature for "git remote add foo && git fetch foo".
But the other "git remote" features like "set-head -a", which can't be
done any other way, or the "auto-check-what-the-remote-has" feature of
"git remote show" are a little gross.
Anyway, I think we are on the same page; this feature (and btw, I think
this is a great feature that we should have) should go into "push".
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Junio C Hamano @ 2011-11-07 21:25 UTC (permalink / raw)
To: Jeff King; +Cc: Felipe Contreras, git
In-Reply-To: <20111107210134.GA7380@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> That makes sense. But I think it fits in with git's current UI to do
> this via a combination of push options and refspecs. Even if we want to
> wrap it in some "git remote" command for convenience, I think what
> you're asking should be implemented as part of "git push".
Yeah, I think it makes sense to give --prune to "push" just like "fetch"
already has. These two are the primary (and in the ideal world, only)
operations that talk to the outside world. "remote add -f" might have been
a tempting "convenience" feature, but I personally think it probably was a
mistake for the exact reason that letting anything but "push" and "fetch"
talk to the outside world just invites more confusion. There does not have
to be 47 different ways to do the same thing.
^ permalink raw reply
* Re: [PATCH 3/3] grep: get rid of useless x < 0 comparison on an enum member
From: Junio C Hamano @ 2011-11-07 21:18 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð Bjarmason, git, Jim Meyering,
Fredrik Gustafsson
In-Reply-To: <20111107194912.GA12469@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> [jn: drop the GREP_HEADER_FIELD_MAX <= p->field check, too,
> for symmetry]
Umm, why is this removal of defensive programming practice an improvement?
This part is mostly my code and because I know what I wrote is almost
always perfect, so I do not think there is any real harm done, but still...
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> grep.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/grep.c b/grep.c
> index b29d09c7..424c46cd 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -327,8 +327,6 @@ static struct grep_expr *prep_header_patterns(struct grep_opt *opt)
> for (p = opt->header_list; p; p = p->next) {
> if (p->token != GREP_PATTERN_HEAD)
> die("bug: a non-header pattern in grep header list.");
> - if (p->field < 0 || GREP_HEADER_FIELD_MAX <= p->field)
> - die("bug: unknown header field %d", p->field);
> compile_regexp(p, opt);
> }
^ permalink raw reply
* Re: pretty placeholders for reflog entries
From: Jeff King @ 2011-11-07 21:13 UTC (permalink / raw)
To: Jack Nagel; +Cc: git
In-Reply-To: <CAMYxyaWPWVGUHz0qQOnARb9wexHCx73a04Bu_UhrJR=xrinX7g@mail.gmail.com>
On Sun, Nov 06, 2011 at 11:49:48PM -0600, Jack Nagel wrote:
> I have the reflog enabled on a bare repo so that I can have a record of
> "who pushed what, when". I'd like to define a custom pretty format for
> use with "git log -g" for reading it, but unfortunately the placeholders
> for reflog information are somewhat limited. In particular, I'd like to
> be able to access the identity (i.e., name and email) and date from each
> reflog entry.
>
> Is it possible to extract this information in current git? Perhaps I
> overlooked something.
Sorry, but there aren't convenient placeholders for that. There probably
should be.
As a workaround, you can get the reflog selector ("%gD"), and then
cross-reference it with the output of "git log -g". But obviously that's
inefficient and a giant pain. We really should have "%gn" and "%ge" for
the reflog name and email. And related date options, though annoyingly
"%gd" is already taken for the default format.
I doubt it would be a very big patch. Want to get your feet wet in git
development? :)
-Peff
^ 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