* Re: bug? in checkout with ambiguous refnames
From: Jeff King @ 2011-01-08 21:40 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Uwe Kleine-König, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.10.1101081449220.12031@debian>
On Sat, Jan 08, 2011 at 03:40:33PM -0500, Martin von Zweigbergk wrote:
> > Yeah, we generally resolve ambiguities in favor of the tag (and that
> > warning comes from deep within get_sha1_basic). So the real bug here is
> > that it still said "Switched to branch", which is totally wrong.
> >
> > That being said, it probably would make more sense for "git checkout" to
> > prefer branches to tags.
>
> What was the rationale for generally favoring tags?
I don't recall hearing any specific argument, but it has always been
that way from early on. I think it is from a vague sense of "tags are
more important than branch tips because they are about marking specific
points, not lines of development". But maybe other old-timers can say
more.
I don't necessarily buy that argument; my only reasoning is that we
should probably keep historic behavior.
> Why does that reasoning not apply to 'git checkout' too?
Because checkout has always been fundamentally about branches. It did
end up growing sane behavior for "git checkout tag" (i.e., a detached
HEAD), but branches are still the fundamental unit for most of its
arguments.
> Btw, what exactly does "generally" mean, i.e. which other commands
> don't favor tags? I know rebase is one example of a command that does
> not favor tags.
It means "we favor tags in resolve_ref, which is the underlying
machinery for most commands, so unless a command special-cases it, that
will be the behavior, and I am too lazy to exhaustively search for such
special cases".
> Slightly off topic, but why does 'git rev-parse --symbolic-full-name'
> not output anything when the input is ambiguous? 'git rev-parse'
> without any flags favors tags, so I would have expected to get
> something like refs/tags/$name back.
I dunno. I never tried it, but I would have expected to get the tag-name
back.
> The reason I'm asking is because I just happened to see in the rebase
> code the other day that it will rebase a detached head if the <branch>
> parameter is not "completely unqualified". For example 'git rebase
> master heads/topic' or 'git rebase master refs/heads/topic' will not
> update refs/heads/topic. I was trying to fix that by using 'git
> rev-parse --symbolic-full-name' to parse <branch>. That seemed to work
> fine until I saw this thread :-).
Heh. I think that would be an argument in favor of changing rev-parse's
behavior.
-Peff
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Martin von Zweigbergk @ 2011-01-09 2:43 UTC (permalink / raw)
To: Jeff King
Cc: Martin von Zweigbergk, Uwe Kleine-König, git, Junio C Hamano
In-Reply-To: <20110108214011.GA4753@sigill.intra.peff.net>
On Sat, 8 Jan 2011, Jeff King wrote:
> On Sat, Jan 08, 2011 at 03:40:33PM -0500, Martin von Zweigbergk wrote:
>
> > > Yeah, we generally resolve ambiguities in favor of the tag (and that
> > > warning comes from deep within get_sha1_basic). So the real bug here is
> > > that it still said "Switched to branch", which is totally wrong.
> > >
> > > That being said, it probably would make more sense for "git checkout" to
> > > prefer branches to tags.
> >
> > What was the rationale for generally favoring tags?
>
> I don't recall hearing any specific argument, but it has always been
> that way from early on. I think it is from a vague sense of "tags are
> more important than branch tips because they are about marking specific
> points, not lines of development". But maybe other old-timers can say
> more.
>
> I don't necessarily buy that argument; my only reasoning is that we
> should probably keep historic behavior.
>
> > Why does that reasoning not apply to 'git checkout' too?
>
> Because checkout has always been fundamentally about branches. It did
> end up growing sane behavior for "git checkout tag" (i.e., a detached
> HEAD), but branches are still the fundamental unit for most of its
> arguments.
I had a look at the history of the lines Junio mentioned in another
message on this thread (lookup_commit_reference_gently() and
setup_branch_path()). I don't understand the code, but just looking at
where the lines came from, they seem to have been there ever since
782c2d6 (Build in checkout, 2008-02-07). If that is correct (but
please check for yourselves), it seems like the broken checkout of
ambiguous references causes problems rarely enough that no one has
bothered to report it for almost two years. If it has been broken for
that long, it seems to me like we could resolve it whichever way makes
most sense, without much concern to how it used to work, no?
> > Btw, what exactly does "generally" mean, i.e. which other commands
> > don't favor tags? I know rebase is one example of a command that does
> > not favor tags.
>
> It means "we favor tags in resolve_ref, which is the underlying
> machinery for most commands, so unless a command special-cases it, that
> will be the behavior, and I am too lazy to exhaustively search for such
> special cases".
Sensible definition :-). I was just hoping for an example where it
more obviously makes sense to favor branches. Maybe rebase is actually
one of the better examples.
> > The reason I'm asking is because I just happened to see in the rebase
> > code the other day that it will rebase a detached head if the <branch>
> > parameter is not "completely unqualified". For example 'git rebase
> > master heads/topic' or 'git rebase master refs/heads/topic' will not
> > update refs/heads/topic. I was trying to fix that by using 'git
> > rev-parse --symbolic-full-name' to parse <branch>. That seemed to work
> > fine until I saw this thread :-).
>
> Heh. I think that would be an argument in favor of changing rev-parse's
> behavior.
I was hoping to do something like
head_name=$(git rev-parse --symbolic-full-name -q --verify "$1")
case "$head_name" in
refs/heads/*) ;;
*) head_name="detached HEAD" ;;
esac
plus setting another variable or two in each case. So even if 'git
rev-parse --symbolic-full-name' would return refs/tags/$name, it
wouldn't actually help here, since rebase currently favors
branches. In order to keep that behavior, I will need to add an extra
check before the above code.
It still feels like rev-parse should return refs/tags/$name, though.
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again)
From: Nguyen Thai Ngoc Duy @ 2011-01-09 3:34 UTC (permalink / raw)
To: Luke Kenneth Casson Leighton; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <AANLkTim2A4=y=XcuPuPiYGDGZyKAUEk-yv2cZVEGhQ3C@mail.gmail.com>
On Sun, Jan 9, 2011 at 12:21 AM, Luke Kenneth Casson Leighton
<luke.leighton@gmail.com> wrote:
> ok - you haven't answered the question: are the chains perfectly
> fixed identical sizes?
No.
> if so they can be slotted into the bittorrent protocol by simply
> pre-selecting the size to match. with the downside that if there are
> a million such "chains" you now pretty much overwhelm the peers with
> the amount of processing, network traffic and memory requirements to
> maintain the "pieces" map.
No, there are thousands of them only (less than 100k for repos I
examined). It's precisely the reason I stay away from commits as
pieces because commits can potentially go up to millions.
> if not then you now need to modify the bittorrent protocol to cope
> with variable-length block sizes: the protocol only allows for the
> last block to be of variable-length.
Ah I see. I do not reuse bittorrent code out there. Just its ideas,
adapted to git model. If you don't want to modify bittorrent protocol
at all, seed a bundle (as mentioned in another thread).
--
Duy
^ permalink raw reply
* Re: [BUG] git rev-list --no-walk A B C sorts by commit date incorrectly
From: Junio C Hamano @ 2011-01-09 6:58 UTC (permalink / raw)
To: Kevin Ballard; +Cc: git list
In-Reply-To: <7vk4ig7y0t.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "git rev-list --no-walk ^HEAD~3 HEAD"? Isn't it a nonsense? If it is "no
> walk", then why do you even list a negative one?
The above was my thinko.
When you explicitly give range to no-walk, you override that no-walk with
"please walk". This is primarily to help Linus who wanted to do "git show
HEAD~3..HEAD"---see how his thinking changed over time by comparing
aa27e461 and f222abde.
The right fix then would be to first always add in the order things were
given, and sort by date at the end after adding everything to queue and we
still have no_walk set, or something like that.
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Junio C Hamano @ 2011-01-09 7:31 UTC (permalink / raw)
To: Jeff King; +Cc: Martin von Zweigbergk, Uwe Kleine-König, git
In-Reply-To: <20110108214011.GA4753@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Jan 08, 2011 at 03:40:33PM -0500, Martin von Zweigbergk wrote:
>
>> > Yeah, we generally resolve ambiguities in favor of the tag (and that
>> > warning comes from deep within get_sha1_basic). So the real bug here is
>> > that it still said "Switched to branch", which is totally wrong.
>> >
>> > That being said, it probably would make more sense for "git checkout" to
>> > prefer branches to tags.
>>
>> What was the rationale for generally favoring tags?
>
> I don't recall hearing any specific argument, but it has always been
> that way from early on. I think it is from a vague sense of "tags are
> more important than branch tips because they are about marking specific
> points, not lines of development". But maybe other old-timers can say
> more.
>
> I don't necessarily buy that argument; my only reasoning is that we
> should probably keep historic behavior.
I don't think "tags are more important" has ever been a serious argument,
either. We prefix refs/tags/ and refs/heads/ to see if what the user gave
us is a short hand, and we have to pick one to check first, and we
happened to have chosen to check tags/ before heads/. Majority of people
have been trained by the ambiguity warning not to use the same name for
their tags and branches, and the rest have learned to live with this
convention.
Among those "rest who have learned to live with" minority are people who
use v1.0 branch to maintain v1.0 codebase after it is tagged, and they
would want to work on v1.0 branch (by checking out v1.0 branch) and
measure their progress by disambiguating between heads/v1.0 and tags/v1.0
when driving "git log" family. There is no strong reason to forbid them
from doing this by requiring uniqueness if that is what they want,
although I personally would suggest them to use maint-1.0 branch that
forks from v1.0 tag.
Aside from your "'checkout branch' is about checking out a branch"
explanation, there are two reasons to favor branches over tags in
"checkout" command:
(1) You cannot disambiguate "git checkout heads/master" when you have
"master" tag, as this notation is used to tell the command "I want to
detach HEAD at that commit"; and
(2) The command already treats an unadorned branch name specially by not
complaining ref/path ambiguity when you said "git checkout master"
and you have a file called "master" in your working tree, so users
already expect that an unadorned branch name is special to it.
^ permalink raw reply
* [PATCH] index-pack: support --pack-stream to concatenate packs
From: Nguyễn Thái Ngọc Duy @ 2011-01-09 7:45 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
--pack-stream --stdin assumes stdin is a stream of packs and creates
a single pack containing all objects of the stream.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Don't know if it's useful for anybody else. Might be a cheaper way
than git-repack to reduce the number of packs.
builtin/index-pack.c | 119 ++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 101 insertions(+), 18 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 8dc5c0b..4864913 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -59,6 +59,7 @@ static int nr_deltas;
static int nr_resolved_deltas;
static int from_stdin;
+static int pack_stream;
static int strict;
static int verbose;
@@ -68,7 +69,7 @@ static struct progress *progress;
static unsigned char input_buffer[4096];
static unsigned int input_offset, input_len;
static off_t consumed_bytes;
-static git_SHA_CTX input_ctx;
+static git_SHA_CTX input_ctx, pack_stream_ctx;
static uint32_t input_crc32;
static int input_fd, output_fd, pack_fd;
@@ -115,23 +116,35 @@ static void check_objects(void)
/* Discard current buffer used content. */
-static void flush(void)
+static void flush_1(int in_pack_stream)
{
if (input_offset) {
- if (output_fd >= 0)
- write_or_die(output_fd, input_buffer, input_offset);
+ if (output_fd >= 0 &&
+ (!pack_stream || (pack_stream && in_pack_stream)))
+ write_or_die(output_fd, input_buffer, input_offset);
+
git_SHA1_Update(&input_ctx, input_buffer, input_offset);
+ if (pack_stream && in_pack_stream)
+ git_SHA1_Update(&pack_stream_ctx, input_buffer, input_offset);
memmove(input_buffer, input_buffer + input_offset, input_len);
input_offset = 0;
}
}
+static void flush(void)
+{
+ flush_1(1);
+}
+
/*
* Make sure at least "min" bytes are available in the buffer, and
* return the pointer to the buffer.
*/
-static void *fill(int min)
+static void *fill_gently(int min, int *got_eof)
{
+ if (got_eof)
+ *got_eof = 0;
+
if (min <= input_len)
return input_buffer + input_offset;
if (min > sizeof(input_buffer))
@@ -141,9 +154,16 @@ static void *fill(int min)
ssize_t ret = xread(input_fd, input_buffer + input_len,
sizeof(input_buffer) - input_len);
if (ret <= 0) {
- if (!ret)
- die("early EOF");
- die_errno("read error on input");
+ if (!ret) {
+ if (!got_eof)
+ die("early EOF");
+ else {
+ *got_eof = 1;
+ return NULL;
+ }
+ }
+ else
+ die_errno("read error on input");
}
input_len += ret;
if (from_stdin)
@@ -152,6 +172,11 @@ static void *fill(int min)
return input_buffer;
}
+static void *fill(int min)
+{
+ return fill_gently(min, NULL);
+}
+
static void use(int bytes)
{
if (bytes > input_len)
@@ -188,6 +213,8 @@ static const char *open_pack_file(const char *pack_name)
pack_fd = input_fd;
}
git_SHA1_Init(&input_ctx);
+ if (pack_stream)
+ git_SHA1_Init(&pack_stream_ctx);
return pack_name;
}
@@ -202,7 +229,7 @@ static void parse_pack_header(void)
die("pack version %"PRIu32" unsupported",
ntohl(hdr->hdr_version));
- nr_objects = ntohl(hdr->hdr_entries);
+ nr_objects += ntohl(hdr->hdr_entries);
use(sizeof(struct pack_header));
}
@@ -590,10 +617,10 @@ static int compare_delta_entry(const void *a, const void *b)
}
/* Parse all objects and return the pack content SHA1 hash */
-static void parse_pack_objects(unsigned char *sha1)
+static void parse_pack_objects(unsigned char *sha1, int start_object)
{
int i;
- struct delta_entry *delta = deltas;
+ struct delta_entry *delta = deltas + nr_deltas;
struct stat st;
/*
@@ -606,7 +633,7 @@ static void parse_pack_objects(unsigned char *sha1)
progress = start_progress(
from_stdin ? "Receiving objects" : "Indexing objects",
nr_objects);
- for (i = 0; i < nr_objects; i++) {
+ for (i = start_object; i < nr_objects; i++) {
struct object_entry *obj = &objects[i];
void *data = unpack_raw_entry(obj, &delta->base);
obj->real_type = obj->type;
@@ -630,11 +657,13 @@ static void parse_pack_objects(unsigned char *sha1)
use(20);
/* If input_fd is a file, we should have reached its end now. */
- if (fstat(input_fd, &st))
- die_errno("cannot fstat packfile");
- if (S_ISREG(st.st_mode) &&
- lseek(input_fd, 0, SEEK_CUR) - input_len != st.st_size)
- die("pack has junk at the end");
+ if (!pack_stream) {
+ if (fstat(input_fd, &st))
+ die_errno("cannot fstat packfile");
+ if (S_ISREG(st.st_mode) &&
+ lseek(input_fd, 0, SEEK_CUR) - input_len != st.st_size)
+ die("pack has junk at the end");
+ }
if (!nr_deltas)
return;
@@ -871,6 +900,54 @@ static int git_index_pack_config(const char *k, const char *v, void *cb)
return git_default_config(k, v, cb);
}
+static void parse_following_packs(unsigned char *pack_sha1,
+ const char *curr_pack,
+ int fix_thin_pack)
+{
+ unsigned char sha1[20];
+
+ for (;;) {
+ int got_eof;
+ int last_nr_objects = nr_objects;
+
+ /* SHA1 trailer of the previous pack */
+ consumed_bytes -= 20;
+ flush_1(0);
+
+ fill_gently(sizeof(struct pack_header), &got_eof);
+ if (got_eof) {
+ /*
+ * pretend we also consume the trailer like in
+ * single pack case, a new trailer will be
+ * rewritten by fixup_pack_header_footer().
+ */
+ consumed_bytes += 20;
+ break;
+ }
+
+ git_SHA1_Init(&input_ctx);
+ parse_pack_header();
+ /* un-use() pack headers */
+ consumed_bytes -= sizeof(struct pack_header);
+ flush_1(0);
+
+ objects = xrealloc(objects, (nr_objects + 1) * sizeof(struct object_entry));
+ deltas = xrealloc(deltas, nr_objects * sizeof(struct delta_entry));
+ parse_pack_objects(sha1, last_nr_objects);
+ }
+ git_SHA1_Final(pack_sha1, &pack_stream_ctx);
+
+ if (!fix_thin_pack ||
+ (nr_deltas - nr_resolved_deltas) == 0) {
+ unsigned char read_sha1[20];
+
+ hashcpy(read_sha1, pack_sha1);
+ fixup_pack_header_footer(output_fd, pack_sha1,
+ curr_pack, nr_objects,
+ read_sha1, consumed_bytes-20);
+ }
+}
+
int cmd_index_pack(int argc, const char **argv, const char *prefix)
{
int i, fix_thin_pack = 0;
@@ -898,6 +975,8 @@ int cmd_index_pack(int argc, const char **argv, const char *prefix)
from_stdin = 1;
} else if (!strcmp(arg, "--fix-thin")) {
fix_thin_pack = 1;
+ } else if (!strcmp(arg, "--pack-stream")) {
+ pack_stream = 1;
} else if (!strcmp(arg, "--strict")) {
strict = 1;
} else if (!strcmp(arg, "--keep")) {
@@ -946,6 +1025,8 @@ int cmd_index_pack(int argc, const char **argv, const char *prefix)
usage(index_pack_usage);
if (fix_thin_pack && !from_stdin)
die("--fix-thin cannot be used without --stdin");
+ if (pack_stream && !from_stdin)
+ die("--pack-stream cannot be used without --stdin");
if (!index_name && pack_name) {
int len = strlen(pack_name);
if (!has_extension(pack_name, ".pack"))
@@ -971,7 +1052,9 @@ int cmd_index_pack(int argc, const char **argv, const char *prefix)
parse_pack_header();
objects = xmalloc((nr_objects + 1) * sizeof(struct object_entry));
deltas = xmalloc(nr_objects * sizeof(struct delta_entry));
- parse_pack_objects(pack_sha1);
+ parse_pack_objects(pack_sha1, 0);
+ if (pack_stream)
+ parse_following_packs(pack_sha1, curr_pack, fix_thin_pack);
if (nr_deltas == nr_resolved_deltas) {
stop_progress(&progress);
/* Flush remaining pack final 20-byte SHA1. */
--
1.7.2.2
^ permalink raw reply related
* [PATCH v2] Introduce new configuation option to override committer information
From: Ramkumar Ramachandra @ 2011-01-09 10:29 UTC (permalink / raw)
To: Git List; +Cc: Stephen Kelly, Thomas Rast, Erik Faye-Lund
In-Reply-To: <igadki$4tb$2@dough.gmane.org>
Currently, there is no way to set committer information on a
per-repository basis. The 'user.name' and 'user.email' configuration
options set both author and committer information. To solve this,
introduce 'user.committername' and 'user.committeremail' configuration
options to override committer name and email respectively.
Reported-by: Stephen Kelly <steveire@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Differences since v1: just rebased. Applies cleanly to master now.
Stephen: Please do not cull CC.
Documentation/config.txt | 29 +++++++++++++++++++++++------
builtin/blame.c | 2 +-
builtin/commit.c | 2 +-
cache.h | 4 +++-
config.c | 15 +++++++++++++++
environment.c | 2 ++
ident.c | 18 ++++++++++++------
7 files changed, 57 insertions(+), 15 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ff7c225..0b89cb6 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1866,14 +1866,31 @@ url.<base>.pushInsteadOf::
setting for that remote.
user.email::
- Your email address to be recorded in any newly created commits.
- Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and
- 'EMAIL' environment variables. See linkgit:git-commit-tree[1].
+ The email address to be recorded in any newly created commits.
+ Sets both author and committer email. To override only
+ committer email, use 'user.committeremail'. Can be overridden
+ by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and 'EMAIL'
+ environment variables. See linkgit:git-commit-tree[1].
user.name::
- Your full name to be recorded in any newly created commits.
- Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
- environment variables. See linkgit:git-commit-tree[1].
+ The full name to be recorded in any newly created commits.
+ Sets both author and committer name. To override only
+ committer name, use 'user.committername'. Can be overridden
+ by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME' environment
+ variables. See linkgit:git-commit-tree[1].
+
+user.committeremail::
+ The email address of the committer to use while recording
+ newly created commits. Used to override committer email
+ specified in 'user.email'. Can be overridden by the
+ 'GIT_COMMITTER_EMAIL', and 'EMAIL' environment variables. See
+ linkgit:git-commit-tree[1].
+
+user.committername::
+ The full name of the committer to use while recording newly
+ created commits. Used to override committer name specified in
+ 'user.name'. Can be overridden by the 'GIT_COMMITTER_NAME'
+ environment variable. See linkgit:git-commit-tree[1].
user.signingkey::
If linkgit:git-tag[1] is not selecting the key you want it to
diff --git a/builtin/blame.c b/builtin/blame.c
index aa30ec5..7fc4d56 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2161,7 +2161,7 @@ static struct commit *fake_working_tree_commit(struct diff_options *opt,
cache_tree_invalidate_path(active_cache_tree, path);
commit->buffer = xmalloc(400);
- ident = fmt_ident("Not Committed Yet", "not.committed.yet", NULL, 0);
+ ident = fmt_ident("Not Committed Yet", "not.committed.yet", NULL, 0, 0);
snprintf(commit->buffer, 400,
"tree 0000000000000000000000000000000000000000\n"
"parent %s\n"
diff --git a/builtin/commit.c b/builtin/commit.c
index 22ba54f..4d0dcac 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -505,7 +505,7 @@ static void determine_author_info(struct strbuf *author_ident)
if (force_date)
date = force_date;
- strbuf_addstr(author_ident, fmt_ident(name, email, date,
+ strbuf_addstr(author_ident, fmt_ident(name, email, date, 0,
IDENT_ERROR_ON_NO_NAME));
}
diff --git a/cache.h b/cache.h
index d83d68c..bf22df6 100644
--- a/cache.h
+++ b/cache.h
@@ -834,7 +834,7 @@ enum date_mode parse_date_format(const char *format);
#define IDENT_NO_DATE 4
extern const char *git_author_info(int);
extern const char *git_committer_info(int);
-extern const char *fmt_ident(const char *name, const char *email, const char *date_str, int);
+extern const char *fmt_ident(const char *name, const char *email, const char *date_str, int, int);
extern const char *fmt_name(const char *name, const char *email);
extern const char *git_editor(void);
extern const char *git_pager(int stdout_is_tty);
@@ -1013,6 +1013,8 @@ extern const char *config_exclusive_filename;
#define MAX_GITNAME (1000)
extern char git_default_email[MAX_GITNAME];
extern char git_default_name[MAX_GITNAME];
+extern char git_default_committeremail[MAX_GITNAME];
+extern char git_default_committername[MAX_GITNAME];
#define IDENT_NAME_GIVEN 01
#define IDENT_MAIL_GIVEN 02
#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN)
diff --git a/config.c b/config.c
index 625e051..3032522 100644
--- a/config.c
+++ b/config.c
@@ -682,6 +682,21 @@ static int git_default_user_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "user.committername")) {
+ if (!value)
+ return config_error_nonbool(var);
+ strlcpy(git_default_committername, value,
+ sizeof(git_default_committername));
+ return 0;
+ }
+
+ if (!strcmp(var, "user.committeremail")) {
+ if (!value)
+ return config_error_nonbool(var);
+ strlcpy(git_default_committeremail, value,
+ sizeof(git_default_committeremail));
+ return 0;
+ }
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index 9564475..641d6ca 100644
--- a/environment.c
+++ b/environment.c
@@ -11,6 +11,8 @@
char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
+char git_default_committeremail[MAX_GITNAME];
+char git_default_committername[MAX_GITNAME];
int user_ident_explicitly_given;
int trust_executable_bit = 1;
int trust_ctime = 1;
diff --git a/ident.c b/ident.c
index 1c4adb0..1a616b7 100644
--- a/ident.c
+++ b/ident.c
@@ -183,7 +183,7 @@ static const char *env_hint =
"\n";
const char *fmt_ident(const char *name, const char *email,
- const char *date_str, int flag)
+ const char *date_str, int committer_info, int flag)
{
static char buffer[1000];
char date[50];
@@ -193,9 +193,15 @@ const char *fmt_ident(const char *name, const char *email,
int name_addr_only = (flag & IDENT_NO_DATE);
setup_ident();
- if (!name)
+ if (committer_info) {
+ if (!name)
+ name = git_default_committername;
+ if (!email)
+ email = git_default_committeremail;
+ }
+ if (!name || !*name)
name = git_default_name;
- if (!email)
+ if (!email || !*email)
email = git_default_email;
if (!*name) {
@@ -239,7 +245,7 @@ const char *fmt_ident(const char *name, const char *email,
const char *fmt_name(const char *name, const char *email)
{
- return fmt_ident(name, email, NULL, IDENT_ERROR_ON_NO_NAME | IDENT_NO_DATE);
+ return fmt_ident(name, email, NULL, 0, IDENT_ERROR_ON_NO_NAME | IDENT_NO_DATE);
}
const char *git_author_info(int flag)
@@ -247,7 +253,7 @@ const char *git_author_info(int flag)
return fmt_ident(getenv("GIT_AUTHOR_NAME"),
getenv("GIT_AUTHOR_EMAIL"),
getenv("GIT_AUTHOR_DATE"),
- flag);
+ 0, flag);
}
const char *git_committer_info(int flag)
@@ -259,7 +265,7 @@ const char *git_committer_info(int flag)
return fmt_ident(getenv("GIT_COMMITTER_NAME"),
getenv("GIT_COMMITTER_EMAIL"),
getenv("GIT_COMMITTER_DATE"),
- flag);
+ 1, flag);
}
int user_ident_sufficiently_given(void)
--
1.7.2.2.409.gdbb11.dirty
^ permalink raw reply related
* Re: git-archive and core.eol
From: René Scharfe @ 2011-01-09 12:52 UTC (permalink / raw)
To: kusmabite; +Cc: Git Mailing List, msysGit, eyvind.bernhardsen
In-Reply-To: <AANLkTi==eqwrwq-P6czDvOH5GDEi6WgvRUuZ2dMoiK7e@mail.gmail.com>
Am 08.01.2011 18:28, schrieb Erik Faye-Lund:
> Really? I haven't looked through what the test actually does (I'm out
> sick right now, and don't have many working brain-cells), but every
> single test fails for me:
[...]
> $ git --version
> git version 1.7.4.rc1.3196.gfd693
>
> (This is the current 'devel'-branch from
> git://repo.or.cz/git/mingw/4msysgit.git)
I cloned it, but even though it reports a different version string for
me we probably use the same (fd6937e0e6ccb78eb4347c427248e25c2d6739c8):
$ ./git version
git version 1.7.3.4.3902.gfd693
And all the tests succeed for me (on Windows Vista Home Premium x64)
with that one.
I'm especially interested in how the setup step manages to fail for you.
But first, get well soon!
René
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again)
From: Luke Kenneth Casson Leighton @ 2011-01-09 13:55 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <AANLkTi=KPVMEviQhyJeWHynPa2q6NJpQ2VyAhbRcmQ1D@mail.gmail.com>
On Sun, Jan 9, 2011 at 3:34 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Sun, Jan 9, 2011 at 12:21 AM, Luke Kenneth Casson Leighton
> <luke.leighton@gmail.com> wrote:
>> ok - you haven't answered the question: are the chains perfectly
>> fixed identical sizes?
>
> No.
>
>> if so they can be slotted into the bittorrent protocol by simply
>> pre-selecting the size to match. with the downside that if there are
>> a million such "chains" you now pretty much overwhelm the peers with
>> the amount of processing, network traffic and memory requirements to
>> maintain the "pieces" map.
>
> No, there are thousands of them only (less than 100k for repos I
> examined). It's precisely the reason I stay away from commits as
> pieces because commits can potentially go up to millions.
ok - thousands is still a lot. i recommend that you examine:
* the heuristics algorithm in bittorrent for piece-selection
* large repositories such as webkit (1.2gb) and the linux kernel (600mb)
you still have to come up with a mapping from "chains" to "pieces".
in the bittorrent protocol the mapping is done *entirely* implicitly
and algorithmically. the "meta" info in the .torrent contains
filenames and file lengths. stack the files one after the other in a
big long data block, get a chopper and just go "whack, whack, whack"
at regular piece-long points, that's your "pieces". so, reassembly is
a complete bitch, and picking just _one_ file to download rather than
the whole lot becomes a total pain.
why the bloody hell the bittorrent protocol doesn't just have a file
id i _really_ don't know, it would have made things a damn sight
easier. anyway - if you're going to modify and "be inspired by" the
bittorrent protocol, you really should look at adding some sort of
"chain" identification - f*** the "chains"-to-"pieces" algorithm, just
add a unique chain id to the relevant bittorrent[-like] command.
>> if not then you now need to modify the bittorrent protocol to cope
>> with variable-length block sizes: the protocol only allows for the
>> last block to be of variable-length.
>
> Ah I see. I do not reuse bittorrent code out there. Just its ideas,
> adapted to git model.
that's hard work and you're now into "unproven" territory. the
successful R&D proof-of-concept code that i wrote i _deliberately_
stayed away from "adapting" a proven bittorrent protocol, and as a
result managed to get that proof-of-concept up and running within ...
i think it was... 3 days. most of the time was spent arseing about
adding in a VFS layer into bittornado, in order to libratise it.
i mention that just to give you something to think about. if you're
up to the challenge of writing your own p2p protocol, however, GREAT!
you'll become a world expert on _both_ peer-to-peer protocols _and_
git :)
l.
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Martin von Zweigbergk @ 2011-01-09 16:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Martin von Zweigbergk, Uwe Kleine-König, git
In-Reply-To: <7v1v4m8reh.fsf@alter.siamese.dyndns.org>
On Sat, 8 Jan 2011, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Sat, Jan 08, 2011 at 03:40:33PM -0500, Martin von Zweigbergk wrote:
> >
> >> > Yeah, we generally resolve ambiguities in favor of the tag (and that
> >> > warning comes from deep within get_sha1_basic). So the real bug here is
> >> > that it still said "Switched to branch", which is totally wrong.
> >> >
> >> > That being said, it probably would make more sense for "git checkout" to
> >> > prefer branches to tags.
> >>
> >> What was the rationale for generally favoring tags?
> >
> > I don't recall hearing any specific argument, but it has always been
> > that way from early on. I think it is from a vague sense of "tags are
> > more important than branch tips because they are about marking specific
> > points, not lines of development". But maybe other old-timers can say
> > more.
> >
> Aside from your "'checkout branch' is about checking out a branch"
> explanation, there are two reasons to favor branches over tags in
> "checkout" command:
>
> (1) You cannot disambiguate "git checkout heads/master" when you have
> "master" tag, as this notation is used to tell the command "I want to
> detach HEAD at that commit"; and
Interesting. I had no idea that 'git checkout heads/master' means to
detach the HEAD. Thanks.
By analogy, I guess that means that 'git rebase master heads/topic' is
supposed to rebase a detached HEAD, so I will stop trying to "fix"
that then :-)
> (2) The command already treats an unadorned branch name specially by not
> complaining ref/path ambiguity when you said "git checkout master"
> and you have a file called "master" in your working tree, so users
> already expect that an unadorned branch name is special to it.
If I understand correctly, that actually applies to tags as well.
Checking out a tag called e.g. Makefile doesn't give any warnings or
errors.
/Martin
^ permalink raw reply
* Re: manual http authorization (no netrc)
From: Tay Ray Chuan @ 2011-01-09 16:35 UTC (permalink / raw)
To: tfogal; +Cc: git
In-Reply-To: <auto-000024252997@sci.utah.edu>
On Fri, Jan 7, 2011 at 1:20 AM, tom fogal <tfogal@sci.utah.edu> wrote:
> I'm getting authorization errors when I lack a .netrc for an http-based
> server. Specifically:
>
> tf@shigeru tmp $ git clone http://myhost:port/git/io.git
> Cloning into io...
> Username:
> Password:
> error: The requested URL returned error: 401 (curl_result = 22, http_code =
> 401, sha1 = 9c201da4d64e2fd178935b9ebbd6e110a97578d4)
> error: Unable to find 9c201da4d64e2fd178935b9ebbd6e110a97578d4 under
> http://shigeru.sci.utah.edu:1234/git/io.git
> Cannot obtain needed blob 9c201da4d64e2fd178935b9ebbd6e110a97578d4
> while processing commit b1853d6f6a54cf22e259a75f77770eef53b8cb38.
> error: Fetch failed.
>
> I did try multiple times; the username/password combo is correct :)
hmm, can you try passing username and password in this manner
http://<user>:<pwd>@server:port/
?
Also, does your username/password contain special, non-alphanumeric
characters? I remember there was a change to how we handled those some
time ago.
--
Cheers,
Ray Chuan
^ permalink raw reply
* [PATCH/RFC] completion: support git blame
From: Martin von Zweigbergk @ 2011-01-09 16:38 UTC (permalink / raw)
To: git; +Cc: Martin von Zweigbergk
Add basic support for completion of refs with git blame.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
Maybe leave --porcelain and --incremental out since they are intended
for scripts?
blame is pretty uninteresting on untracked files. It would be nice if
to only complete files that exist in the specified commit, just like
'git show $rev:$file' does. I think this applies to some other
commands as well, like 'git checkout $rev [--] $file'. Has this been
discussed before? I didn't find anything when searching the
archives. I can imagine it might have been rejected because of
performance problems.
contrib/completion/git-completion.bash | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 645549c..d9074ba 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1128,6 +1128,26 @@ _git_bisect ()
esac
}
+_git_blame ()
+{
+ __git_has_doubledash && return
+
+ local cur
+ _get_comp_words_by_ref -n =: cur
+ case "$cur" in
+ --*)
+ __gitcomp "
+ --root --show-stats --reverse --encoding=
+ --contents --date --score-debug --show-name
+ --show-number --show-email
+ "
+ ;;
+ *)
+ __gitcomp "$(__git_refs)"
+ ;;
+ esac
+}
+
_git_branch ()
{
local i c=1 only_local_ref="n" has_r="n" cur words cword
--
1.7.3.2.864.gbbb96
^ permalink raw reply related
* Re: [PATCH v2] Introduce new configuation option to override committer information
From: Jonathan Nieder @ 2011-01-09 17:24 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Stephen Kelly, Thomas Rast, Erik Faye-Lund
In-Reply-To: <1294568989-5848-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> The 'user.name' and 'user.email' configuration
> options set both author and committer information. To solve this,
> introduce 'user.committername' and 'user.committeremail' configuration
> options to override committer name and email respectively.
Predictably, I don't like this idea at all. How would we explain this
to a new user that is reading over gitconfig(5) for the first time?
It makes the semantics of the committer and author name (that are mostly
meant for giving credit and a contact address) much more murky.
Stephen Kelly:
> In KDE the committer email address is used to be able to use keywords in
> commit messages to automatically close bugs.
Is it impossible to fix this on the KDE side? I would think a
many-to-one mapping from committer identities to bugzilla account
names could be a useful thing to have in any case.
Hopeful,
Jonathan
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again)
From: Nguyen Thai Ngoc Duy @ 2011-01-09 17:48 UTC (permalink / raw)
To: Luke Kenneth Casson Leighton; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <AANLkTinwb8orMBjcQjK0ogXd6rMEtRwT8SV41k8D3AXL@mail.gmail.com>
On Sun, Jan 9, 2011 at 8:55 PM, Luke Kenneth Casson Leighton
<luke.leighton@gmail.com> wrote:
> you still have to come up with a mapping from "chains" to "pieces".
> in the bittorrent protocol the mapping is done *entirely* implicitly
> and algorithmically.
Given a commit SHA-1, the mapping can be done algorithmically because
the graph from the commit tip is fixed. Perhaps not mapping all at
once, but as you have more pieces in the graph, you can map more.
> the "meta" info in the .torrent contains
> filenames and file lengths. stack the files one after the other in a
> big long data block, get a chopper and just go "whack, whack, whack"
> at regular piece-long points, that's your "pieces". so, reassembly is
> a complete bitch, and picking just _one_ file to download rather than
> the whole lot becomes a total pain.
Well, there won't be .torrent files. Torrent files serve as checksums
for file pieces (let's forget the tracker part). We do sha-1 checksum
on every objects in git. The object graph without real content _is_
"info" part in .torrent files. Instead of passing around torrent
files, I only need to pass around the sha-1 of the commit tip(s). That
should be enough for any peer to discover the rest.
Reassembling, in its simplest way, is to just dump loose objects to
$GIT_DIR/objects. But it's been six years since git's birth now, I'll
pack them instead.
> that's hard work and you're now into "unproven" territory. the
> successful R&D proof-of-concept code that i wrote i _deliberately_
> stayed away from "adapting" a proven bittorrent protocol, and as a
> result managed to get that proof-of-concept up and running within ...
> i think it was... 3 days. most of the time was spent arseing about
> adding in a VFS layer into bittornado, in order to libratise it.
>
> i mention that just to give you something to think about. if you're
> up to the challenge of writing your own p2p protocol, however, GREAT!
> you'll become a world expert on _both_ peer-to-peer protocols _and_
> git :)
Maybe I have gone insane ;) But I have another aim for this work: to
adjust narrow clone area (pretty much path-based clones). So while it
may not become real torrent for git (i.e p2p exchanging, depends on my
needs), restartable clone from multiple sources is still worth it.
--
Duy
^ permalink raw reply
* Re: git color in commit editor
From: Pavan Savoy @ 2011-01-09 18:26 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git
In-Reply-To: <AANLkTimAXV9u4FfL2cv5vE9oDgs-LfJu2DopRw=FEqUE@mail.gmail.com>
On Thu, Jan 6, 2011 at 4:28 PM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> On Thu, Jan 6, 2011 at 07:42, Pavan Savoy <pavan_savoy@sify.com> wrote:
>> I have git version git version 1.5.6.3, on 1 system and get the colors
>> right during a git commit (commit editor being vim..)
>
> FWIW here's how to get those colors under Emacs:
> https://github.com/rafl/git-commit-mode
>
Thanks, I do have syntax on in my vimrc, as I mentioned, I also have colors in
vim for .c files on both machines...
The only differences being git versions, also what syntax or color
format would vim get for git and from where?
^ permalink raw reply
* Re: git color in commit editor
From: Jonathan Nieder @ 2011-01-09 18:33 UTC (permalink / raw)
To: Pavan Savoy; +Cc: Ævar Arnfjörð Bjarmason, git
In-Reply-To: <AANLkTikns9XyM48HkggaKFEsj61hP1y3Y-QczA0Pp9Bs@mail.gmail.com>
Pavan Savoy wrote:
> Thanks, I do have syntax on in my vimrc, as I mentioned, I also have colors in
> vim for .c files on both machines...
> The only differences being git versions, also what syntax or color
> format would vim get for git and from where?
$ find /usr/share/vim -name git\*
/usr/share/vim/vim73/ftplugin/gitconfig.vim
/usr/share/vim/vim73/ftplugin/gitsendemail.vim
/usr/share/vim/vim73/ftplugin/gitrebase.vim
/usr/share/vim/vim73/ftplugin/gitcommit.vim
/usr/share/vim/vim73/ftplugin/git.vim
/usr/share/vim/vim73/indent/gitconfig.vim
/usr/share/vim/vim73/syntax/gitconfig.vim
/usr/share/vim/vim73/syntax/gitsendemail.vim
/usr/share/vim/vim73/syntax/gitrebase.vim
/usr/share/vim/vim73/syntax/gitcommit.vim
/usr/share/vim/vim73/syntax/git.vim
":help :syn-files" explains how to use them.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: PostScript files: textconv and "git add -p"
From: Matthieu Moy @ 2011-01-09 18:55 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110105051807.GB5884@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> you can get what you want with:
>
> echo '*.ps diff=ps' >.gitattributes
> git config diff.ps.textconv ps2ascii
> git config diff.ps.binary true
Yes, this works great. Thanks.
Did I miss something, or is this undocumented? I can't find that in
either man gitattributes or man git-config.
> PS Your question made me very happy. I implemented "diff.*.binary" the
> way I did out of a vague sense of orthogonality, but I never quite
> came up with a concrete example where it was useful to set both.
> Thanks for providing one. :)
I vaguely remember such discussions, and may well have thought "hmm,
yet another overkill stuff that nobody'll ever use" at that time ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] fast-import: Create import-marks file when necessary
From: Ramkumar Ramachandra @ 2011-01-09 19:33 UTC (permalink / raw)
To: Git List; +Cc: Jonathan Nieder
When both --import-marks and --export-marks are given, and specify the
same file, that file should be created if it doesn't exist. Without
this patch, the caller would have to check for the existence of a
marks file and vary its fast-import invocation accordingly.
Requested-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
fast-import.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 5055504..cb7a9c9 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -3247,8 +3247,23 @@ static void parse_argv(void)
usage(fast_import_usage);
seen_data_command = 1;
- if (import_marks_file)
+ if (import_marks_file) {
+ FILE *f = fopen(import_marks_file, "r");
+ if (!f) {
+ if (errno == ENOENT &&
+ !strcmp(import_marks_file, export_marks_file)) {
+ FILE *d = fopen(import_marks_file, "w");
+ if (!d)
+ die_errno("cannot create '%s'", import_marks_file);
+ fclose(d);
+ }
+ else
+ die_errno("cannot read '%s'", import_marks_file);
+ }
+ else
+ fclose(f);
read_marks();
+ }
}
int main(int argc, const char **argv)
--
1.7.4.rc1.8.g98938a.dirty
^ permalink raw reply related
* Re: manual http authorization (no netrc)
From: tom fogal @ 2011-01-09 19:49 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <AANLkTik2QjOOoOcx0E7NeYEbs3YnLFPbG3x5J2RUFmRU@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> On Fri, Jan 7, 2011 at 1:20 AM, tom fogal <tfogal@sci.utah.edu> wrote:
> > I'm getting authorization errors when I lack a .netrc for an
> > http-based server. Specifically:
> >
> > =A0tf@shigeru tmp $ git clone http://myhost:port/git/io.git
> > =A0Cloning into io...
> > =A0Username:
> > =A0Password:
> > =A0error: The requested URL returned error: 401 (curl_result =3D 22, http=
> > _code =3D
[snip]
> hmm, can you try passing username and password in this manner
>
> http://<user>:<pwd>@server:port/
>
> ?
Yes. That worked! Though it was very quiet; the only message I
got was "Cloning into io..."; no "remote:" messages or "Receiving "
messages. That's neither here nor there, though.
> Also, does your username/password contain special, non-alphanumeric
> characters? I remember there was a change to how we handled those
> some time ago.
Nope, both would encode fine in 7bit ascii.
Thanks much for the workaround,
-tom
^ permalink raw reply
* [PATCH] docs: explain diff.*.binary option
From: Jeff King @ 2011-01-09 20:10 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqr5clsy8g.fsf@bauges.imag.fr>
This was added long ago as part of the userdiff refactoring
for textconv, as internally it made the code simpler and
cleaner. However, there was never a concrete use case for
actually using the config variable.
Now that Matthieu Moy has provided such a use case, it's
easy to explain it using his example.
Signed-off-by: Jeff King <peff@peff.net>
---
On Sun, Jan 09, 2011 at 07:55:43PM +0100, Matthieu Moy wrote:
> Jeff King <peff@peff.net> writes:
>
> > you can get what you want with:
> >
> > echo '*.ps diff=ps' >.gitattributes
> > git config diff.ps.textconv ps2ascii
> > git config diff.ps.binary true
>
> Yes, this works great. Thanks.
>
> Did I miss something, or is this undocumented? I can't find that in
> either man gitattributes or man git-config.
Nope, it was never documented, probably because I never figured out what
it was good for. :)
Documentation/gitattributes.txt | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 22b8582..a282adb 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -591,6 +591,39 @@ and now produces better output), you can remove the cache
manually with `git update-ref -d refs/notes/textconv/jpg` (where
"jpg" is the name of the diff driver, as in the example above).
+Marking files as binary
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Git usually guesses correctly whether a blob contains text or binary
+data by examining the beginning of the contents. However, sometimes you
+may want to override its decision, either because a blob contains binary
+data later in the file, or because the content, while technically
+composed of text characters, is opaque to a human reader. For example,
+many postscript files contain only ascii characters, but produce noisy
+and meaningless diffs.
+
+The simplest way to mark a file as binary is to unset the diff
+attribute in the `.gitattributes` file:
+
+------------------------
+*.ps -diff
+------------------------
+
+This will cause git to generate `Binary files differ` (or a binary
+patch, if binary patches are enabled) instead of a regular diff.
+
+However, one may also want to specify other diff driver attributes. For
+example, you might want to use `textconv` to convert postscript files to
+an ascii representation for human viewing, but otherwise treat them as
+binary files. You cannot specify both `-diff` and `diff=ps` attributes.
+The solution is to use the `diff.*.binary` config option:
+
+------------------------
+[diff "ps"]
+ textconv = ps2ascii
+ binary = true
+------------------------
+
Performing a three-way merge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
1.7.3.5.4.g0dc52
^ permalink raw reply related
* Re: [PATCH] docs: explain diff.*.binary option
From: Matthieu Moy @ 2011-01-09 20:31 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20110109201003.GA4406@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This was added long ago as part of the userdiff refactoring
> for textconv, as internally it made the code simpler and
> cleaner. However, there was never a concrete use case for
> actually using the config variable.
>
> Now that Matthieu Moy has provided such a use case, it's
> easy to explain it using his example.
>
> Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Maybe there should be a git-grep plumbing interface for ack et al.
From: Ævar Arnfjörð Bjarmason @ 2011-01-09 22:17 UTC (permalink / raw)
To: perl5-porters, Andy Lester, Git Mailing List
On Sun, Jan 9, 2011 at 18:17, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
[CC'd Andy & the Git list in case they're interested]
> * Aaron Crane <perl@aaroncrane.co.uk> [2011-01-09 13:10]:
>> AFAICT, the most important reason for the speed of `git grep`
>> is that (in recent versions, at least) it uses multiple
>> threads. […] I believe that ability should be reasonably easy
>> to reimplement in a Perl grep-a-like
>
> I assumed, on no factual basis, that one of the reasons is that
> it uses the object store whenever possible instead of the working
> copy, which would speed up `git grep` in much the same way it
> makes `git checkout` faster than `cp -R`. (Compression and linear
> pack files reduce I/O.) I don’t know if that’s actually the case,
> though. But such an avenue is not open to generic grep clones.
Yes, this is correct. git-grep(1) is fast because it doesn't have to
do the I/O that grep(1) and ack(1) have to do. It can just read the
git tree/object files.
Incidentally (since I also work on git.git) one idea for a project I
had was to add a new plumbing command that does the grep-like things
git-grep(1) does but allow someone to implement their own
grep-er. I.e. just spew out filename/line pairs on stdout.
Then e.g. ack(1) could use this new plumbing command to read files
when in a git repository, but could provide Perl's regex features and
other things it has.
But last I looked Ack was fairly unmodularized, so adding that sort of
stuff might be hard. But that might have changed.
^ permalink raw reply
* Re: [PATCH] fast-import: Create import-marks file when necessary
From: Junio C Hamano @ 2011-01-09 22:48 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Jonathan Nieder
In-Reply-To: <1294601637-18416-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> When both --import-marks and --export-marks are given, and specify the
> same file, that file should be created if it doesn't exist. Without
> this patch, the caller would have to check for the existence of a
> marks file and vary its fast-import invocation accordingly.
>
> Requested-by: Jonathan Nieder <jrnieder@gmail.com>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Do you mean that you are solving a problem for bootstrapping a script that
says "read from this file if exists, do work, and then write to the same
file for later invocation"?
Assuming that is what you are solving, why do you create the file in your
patch in the import codepath? I would imagine a sane logic flow for "read
if exists, do work and then write to the same" would be more like:
if (import_marks) {
FILE = *f = fopen(import_marks);
if (f)
read_marks();
else if (errno == ENOENT && !strcmp(import_marks, export_marks))
; /* Bootstrapping with "read if exists" */
else
barf();
}
no?
Also I find it a bad taste to use "The user gave the same file to import
and export" as a hint for "read if exists".
The first two lines of the proposed commit message is way suboptimal, if
the problem is "Not allowing read-if-exists-but-do-not-barf-if-missing
makes it hard to bootstrap repeated invocations that use a single
import/export marks file as the state-keeping mechanism".
It does not have to be created if it doesn't exist---the program only
needs not to barf. The condition does not have to be "if they are the
same file". The caller may want to script
command --import-if-exists=state --export=new-state+ &&
mv new-state+ state
to make sure that when the underlying command fails, the previous state is
still kept intact without getting overwritten.
^ permalink raw reply
* Re: Maybe there should be a git-grep plumbing interface for ack et al.
From: Andy Lester @ 2011-01-10 3:38 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: perl5-porters, Git Mailing List
In-Reply-To: <AANLkTi=E0x55-RUz5CJXL_LJ6hPr--Nupp-Ti72kpNv=@mail.gmail.com>
On Jan 9, 2011, at 4:17 PM, Ævar Arnfjörð Bjarmason wrote:
> Then e.g. ack(1) could use this new plumbing command to read files
> when in a git repository, but could provide Perl's regex features and
> other things it has.
The plan for ack 2.0 is to have plugins that anyone can write to allow acking for whatever you want. You'll write a plugin for PDF files and go acking for text in there, or an Excel file, or some file that specifies a Postgresql table, or whatever. It's up to the plugin to figure out how that happens. I'm not interested in writing hooks to git or any file system any more complicated than straight calls to open(), but plugin writers will have the flexibility to do it themselves.
xoa
--
Andy Lester => andy@petdance.com => www.techworklove.com => AIM:petdance
^ permalink raw reply
* Re: cvsimport still not working with cvsnt
From: Guy Rouillier @ 2011-01-10 7:33 UTC (permalink / raw)
To: Emil Medve
Cc: Jonathan Nieder, git, Pascal Obry, Clemens Buchacher,
Martin Langhoff
In-Reply-To: <4D119015.6020207@burntmail.com>
On 12/22/2010 12:43 AM, Guy Rouillier wrote:
>
> Emil and Jonathan, thanks for the feedback. Perl is not my strong point,
> but I'll take a crack at it over the upcoming holidays. I'm inclined not
> to get too fancy and try to second-guess the user's environment. Perhaps
> he has both cvs and cvsnt installed for some reason (testing one, using
> the other for regular work); perhaps a tool installed one or the other
> and he doesn't even know he has them both. Etc.
>
> So, at most I can see, as Emil suggested, seeing if the entry exists in
> both files and is the same in both. If so, or if the entry is only in
> one of them, then just use the entry. However, if the entry is in both
> files and is different, I'd prefer to just exit with an error and have
> the user clarify his environment.
Here is my patch for accomplishing the above. As this is my first time
submitting a patch, please let me know the correct procedure if
submitting a diff here is not appropriate. Thanks.
--- git-cvsimport.org 2011-01-09 03:52:39.000000000 -0500
+++ git-cvsimport.cvsnt 2011-01-10 01:42:29.000000000 -0500
@@ -260,6 +260,8 @@
if ($pass) {
$pass = $self->_scramble($pass);
} else {
+ # First try the original CVS location.
+
open(H,$ENV{'HOME'}."/.cvspass") and do {
# :pserver:cvs@mea.tmt.tele.fi:/cvsroot/zmailer Ah<Z
while (<H>) {
@@ -272,7 +274,30 @@
}
}
};
- $pass = "A" unless $pass;
+
+ # Now try the CVSNT location.
+
+ open(H,$ENV{'HOME'}."/.cvs/cvspass") and do {
+ # :pserver:cvs@mea.tmt.tele.fi:/cvsroot/zmailer Ah<Z
+ while (<H>) {
+ chomp;
+ s/^\/\d+\s+//;
+ my ($w,$p) = split(/=/,$_,2);
+ if ($w eq $rr or $w eq $rr2) {
+ my $cvsntpass = $p;
+
+ if (!$pass) {
+ $pass = $cvsntpass;
+ } elsif ($pass ne $cvsntpass) {
+ die("CVSROOT found in both CVS and CVSNT cvspass files, passwords do not match\n");
+ }
+ last;
+ }
+ }
+ };
+
+
+ die("Password not found for CVSROOT: $opt_d\n") unless $pass;
}
my ($s, $rep);
--
Guy Rouillier
^ 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