* Re: ~/.git/config ?
From: Jakub Narebski @ 2006-05-26 16:37 UTC (permalink / raw)
To: git
In-Reply-To: <20060526193325.d2a530a4.tihirvon@gmail.com>
Timo Hirvonen wrote:
> Anand Kumria <wildfire@progsoc.uts.edu.au> wrote:
>
>> Hi,
>>
>> git is unable to construct a reasonable default email address in my
>> current environment. So, I use GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL
>> to override things.
>>
>> This has worked well but, now, I need to vary the email address for some
>> repositories. Unfortunately the environment variables override
>> .git/config.
>>
>> It would be good if things were like:
>> - try to construct one automagically
>> - use ~/.git/config (if available)
>> - use .git/config
>> - use environment variables
>>
>> That way I could set my default email address in ~/.git/config and
>> override it as required for those repositories that need it.
>
> I backup my $HOME using git, so there's a .git directory in ~. I don't
> think a global config file is really needed but it would be nice if
> .git/config would override the environment variables, not the other way
> around.
Well, I'm not sure if environmental variables overriding wouldn't make
invocations like 'GIT_DIR=something git command' possible.
There are templates, also for config. Currently git lacks user (not
repository) config file, e.g. ~/.gitconfig (common for all repositories).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: ~/.git/config ?
From: Petr Baudis @ 2006-05-26 16:38 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Anand Kumria, git
In-Reply-To: <20060526193325.d2a530a4.tihirvon@gmail.com>
Dear diary, on Fri, May 26, 2006 at 06:33:25PM CEST, I got a letter
where Timo Hirvonen <tihirvon@gmail.com> said that...
> I backup my $HOME using git, so there's a .git directory in ~.
Then it should be called ~/.gitconfig. :-)
> I don't think a global config file is really needed but it would be
> nice if .git/config would override the environment variables, not the
> other way around.
Then you have no other way to override .git/config e.g. when committing
patches submitted by other people.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* [PATCH] Call builtin ls-tree in git-cat-file -p
From: Petr Baudis @ 2006-05-26 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
builtin-cat-file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-cat-file.c b/builtin-cat-file.c
index 8ab136e..4d36817 100644
--- a/builtin-cat-file.c
+++ b/builtin-cat-file.c
@@ -141,7 +141,7 @@ int cmd_cat_file(int argc, const char **
/* custom pretty-print here */
if (!strcmp(type, tree_type))
- return execl_git_cmd("ls-tree", argv[2], NULL);
+ return cmd_ls_tree(2, argv + 1, NULL);
buf = read_sha1_file(sha1, type, &size);
if (!buf)
^ permalink raw reply related
* Re: ~/.git/config ?
From: Timo Hirvonen @ 2006-05-26 17:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: wildfire, git
In-Reply-To: <20060526163829.GB10488@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Fri, May 26, 2006 at 06:33:25PM CEST, I got a letter
> where Timo Hirvonen <tihirvon@gmail.com> said that...
> > I backup my $HOME using git, so there's a .git directory in ~.
>
> Then it should be called ~/.gitconfig. :-)
I just wanted to point the fact that ~/.git/ could not be used :)
> > I don't think a global config file is really needed but it would be
> > nice if .git/config would override the environment variables, not the
> > other way around.
>
> Then you have no other way to override .git/config e.g. when committing
> patches submitted by other people.
git commit --author "name <email>"
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: ~/.git/config ?
From: Petr Baudis @ 2006-05-26 17:11 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: wildfire, git
In-Reply-To: <20060526200526.d8a2f776.tihirvon@gmail.com>
Dear diary, on Fri, May 26, 2006 at 07:05:26PM CEST, I got a letter
where Timo Hirvonen <tihirvon@gmail.com> said that...
> > > I don't think a global config file is really needed but it would be
> > > nice if .git/config would override the environment variables, not the
> > > other way around.
> >
> > Then you have no other way to override .git/config e.g. when committing
> > patches submitted by other people.
>
> git commit --author "name <email>"
Except that this just sets the environment variables for you. :-)
Now, you could do some really funny stuff with overriding the
environment variables at git commit's entry point with .git/config
stuff, then possibly setting them again in case --author was passed, but
I seriously think such a confusion is not worth it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Eric W. Biederman @ 2006-05-26 17:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vac95m799.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> diff --git a/fetch-pack.c b/fetch-pack.c
>> index a3bcad0..c767d84 100644
>> --- a/fetch-pack.c
>> +++ b/fetch-pack.c
>> @@ -260,6 +260,27 @@ static void mark_recent_complete_commits
>> }
>> }
>>
>> +static struct ref **get_sha1_heads(struct ref **refs, int nr_heads, char
> **head)
>> +{
>> + int i;
>> + for (i = 0; i < nr_heads; i++) {
>> + struct ref *ref;
>> + unsigned char sha1[20];
>> + char *s = head[i];
>> + int len = strlen(s);
>> +
>> + if (len != 40 || get_sha1_hex(s, sha1))
>> + continue;
>
> So the new convention is fetch-pack can take ref name (as
> before), or a bare 40-byte hexadecimal. I think sane people
> would not use ambiguous refname that says "deadbeef" five times,
> and even if the do so they could disambiguate by explicitly
> saying "refs/heads/" followed by "deadbeef" five times, so it
> should be OK.
Yes.
>> +
>> + ref = xcalloc(1, sizeof(*ref) + len + 1);
>> + memcpy(ref->old_sha1, sha1, 20);
>> + memcpy(ref->name, s, len + 1);
>> + *refs = ref;
>> + refs = &ref->next;
>> + }
>> + return refs;
>> +}
>> +
>
> This function takes the pointer to a location that holds a
> pointer to a "struct ref" -- it is the location to store the
> newly allocated ref structure, i.e. the next pointer of the last
> element in the list. When it returns, the location pointed at
> by the pointer given to you points at the first element you
> allocated, and it returns the next pointer of the last element
> allocated by it. That is the same calling convention as
> connect.c::get_remote_heads(). So when calling this function to
> append to a list you already have, you would give the next
> pointer to the last element of the existing list. But you do
> not seem to do that.
Ack. That does look like a bug. I knew there as something
fishy about that code. But it worked for my basic testing so I didn't
worry about it.
> I think the body of fetch_pack() should become something like:
>
> struct ref *ref, **tail;
>
> tail = get_remote_heads(fd[0], &ref, 0, NULL, 0);
> if (server_supports("multi_ack")) {
> ...
> }
> tail = get_sha1_heads(tail, nr_match, match);
> if (everything_local(&ref, nr_match, match)) {
> ...
Actually because we want the filter to resolve sha1s by
default in terms of what was passed on the command line. I'm pretty
certain that should be:
tail = get_sha1_heads(&ref, nr_match, match);
tail = get_remote_heads(fd[0], tail, 0, NULL, 0);
...
>> @@ -311,6 +332,8 @@ static int everything_local(struct ref *
>> if (cutoff)
>> mark_recent_complete_commits(cutoff);
>>
>> + filter_refs(refs, nr_match, match);
>> +
>
> I am not sure about this change.
Agreed. It was a hold over from an earlier way of injecting
the sha1 into the logic.
As for what happens I think I need to audit everything that
takes a ref from fetch_pack. To make certain I have not
messed up the logic.
> In the original code we do not let get_remote_heads() to filter
> the refs but call filter_refs() after the "mark all complete
> remote refs as common" step for a reason. Even though we may
> not be fetching from some remote refs, we would want to take
> advantage of the knowledge of what objects they have so that we
> can mark as many objects as common as possible in the early
> stage. I suspect this change defeats that optimization.
It feels like it.
> So instead I would teach "mark all complete remote refs" loop
> that not everything in refs list is a valid remote ref, and skip
> what get_sha1_heads() injected, because these arbitrary ones we
> got from the command line are not something we know exist on the
> remote side. Maybe something like this.
Sounds sane. We also introduce a new possibility of having a
ref that is complete but not remote.
> /*
> * Mark all complete remote refs as common refs.
> * Don't mark them common yet; the server has to be told so first.
> */
> for (ref = *refs; ref; ref = ref->next) {
> struct object *o;
> if (ref is SHA1 from the command line)
> continue;
> o = deref_tag(lookup_object(ref->old_sha1), NULL, 0);
> if (!o || o->type != commit_type || !(o->flags & COMPLETE))
> continue;
> ...
>
> To implement "ref is SHA1 from the command line", I would add
> another 1-bit field to "struct ref" and mark the new ones you
> create in get_sha1_heads() as such (existing "force" field
> could also become an 1-bit field -- we do not neeed a char).
Sounds sane.
So that gives me:
unsigned int force : 1;
unsigned int injected : 1;
Which aligns them to an int boundary but since we are followed
immediately by a pointer should result in no additional storage being
consumed.
>> @@ -373,6 +394,7 @@ static int fetch_pack(int fd[2], int nr_
>> packet_flush(fd[1]);
>> die("no matching remote head");
>> }
>> + get_sha1_heads(&ref, nr_match, match);
>
> I talked about this one already...
>
>> diff --git a/git-parse-remote.sh b/git-parse-remote.sh
>> index 187f088..2372df8 100755
>> --- a/git-parse-remote.sh
>> +++ b/git-parse-remote.sh
>> @@ -105,6 +105,7 @@ canon_refs_list_for_fetch () {
>> '') remote=HEAD ;;
>> refs/heads/* | refs/tags/* | refs/remotes/*) ;;
>> heads/* | tags/* | remotes/* ) remote="refs/$remote" ;;
>> +
> [0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F])
> ;;
>
> Yuck. Don't we have $_x40 somewhere?
I couldn't find one in shell.
> We never use uppercase so at least we could save 24 columns from
> here ;-).
I'm not certain why we always add make $remote="refs/heads/$remote" by
default in that switch statement. git-fetch-pack at least doesn't need
it.
If that is true of the other consumers we could easily make the test:
[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]*) ;;
Or even simply make the default case *) ;;
But for the moment I will stick to the long form because it is
obviously correct.
Eric
^ permalink raw reply
* Re: ~/.git/config ?
From: Junio C Hamano @ 2006-05-26 17:38 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <20060526152837.GQ23852@progsoc.uts.edu.au>
Anand Kumria <wildfire@progsoc.uts.edu.au> writes:
> It would be good if things were like:
> - try to construct one automagically
> - use ~/.git/config (if available)
> - use .git/config
> - use environment variables
>
> That way I could set my default email address in ~/.git/config and
> override it as required for those repositories that need it.
If you mean by the above "do all of these and take the last
value that was available", that sounds sane. Except perhaps I
would suggest to use ~/.git-config instead. Some people seem to
want to track their home directory with git, and that way, your
personal fallback default file can be version controlled.
^ permalink raw reply
* Re: git-apply can't apply patches to CRLF-files
From: Junio C Hamano @ 2006-05-26 18:05 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: git
In-Reply-To: <4477262A.5000301@Intel.com>
Salikh Zakirov <Salikh.Zakirov@Intel.com> writes:
> git-apply can't apply the patch to file with windows-style CRLF line endings,
> even if the patch was generated by git-format-patch.
I do not think that is the case.
> Is this a bug or known deficiency?
This particular reproduction recipe looks like a PEBCAK; it does
not reproduce for me, but I do not have/use unix2dos so I did
DOSsy line endings a bit differently.
git init-db
echo 'abc@' | tr '[@]' '[\015]' >a
git add a
git commit -m initial
echo 'def@' | tr '[@]' '[\015]' >>a
git commit -a -m second
git format-patch HEAD^
git reset --hard HEAD^
git am 0*.txt
> The following script reproduces the problem
> ---------
> #!/bin/sh
> set -e
> mkdir trash
> cd trash
> git init-db
> echo "abc" > a
> unix2dos a
> git add a
> git commit -m "a added" a
> echo "cde" >> a
> unix2dos a
Here the first line of a ends with \r\n already end the second
line ends with a \n. Does running unix2dos on that do a
sensible thing on the first line? Compare it with my above
recipe which appends DOSsy line at the end of the file.
Having said that, CRLF is unsafe for E-mail transfers anyway, so
I think we would need a special option to tell git-apply that it
should match '\n' that appears in the patch with '\r\n' in the
file being patched. But I do not think that has anything to do
with the breakage you saw in your reproduction recipe.
^ permalink raw reply
* Re: t8001-annotate.sh fails on Mac OS X
From: Ryan Anderson @ 2006-05-27 1:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vpsi1qyi2.fsf@assigned-by-dhcp.cox.net>
On Thu, May 25, 2006 at 08:02:45PM -0700, Junio C Hamano wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > I think we had hoped that one of the two tools would prove to be
> > _the_ annotation/blame tool and would get used but thus far that
> > hasn't happened.
>
> I've been taking this as an indication that annotate/blame does
> not actually matter in the real world.
It probably doesn't matter in the real world.
At the moment, I'd blame annotate for being wrong, I know it does the
wrong thing on some merges, and I had a plan to try to fix it, but I got
distracted by finding a new job and moving across the country, so I
haven't really had a chance to fix it, something to look at shortly, I
hope. (I'm having problems getting one of my machines back up, so
that's going to slow me down slightly)
> Or git is not yet used in the real world. Or perhaps a bit of
> both.
It's just that "annotate" isn't a common operation in the communities
that Git has made it into.
^ permalink raw reply
* [PATCH/RFC] upload-pack: stop "ack continue" when we know common commits for wanted refs
From: Junio C Hamano @ 2006-05-27 2:20 UTC (permalink / raw)
To: Ralf Baechle; +Cc: git, Linus Torvalds
In-Reply-To: <20060526154239.GA20839@linux-mips.org>
When the downloader's repository has more roots than the server
side has, the "have" exchange to figure out recent common
commits ends up traversing the whole history of branches that
only exist on the downloader's side. When the downloader is
asking for newer commits on the branch that exists on both ends,
this is totally unnecessary.
This adds logic to the server side to see if the wanted refs can
reach the "have" commits received so far, and stop issuing "ack
continue" once all of them can be reached from "have" commits.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Ralf Baechle <ralf@linux-mips.org> writes:
>> [PATCH] fetch-pack: give up after getting too many "ack continue"
>
> So I did test your patch. In the big, slow repository it cuts down the
> time for a
>
> git fetch git://www./.../linux-2.6.16.y.git master:v2.6.16-stable
>
> from like 6min to about 7s.
>
> Thanks!
This patch is still rough, but it passes my test of asking for
"master" from git.git repository into a repository that is a
merge between linux-2.6.git and a slightly older git.git.
Without this change, and without the client-side hack Ralf
tested, it ends up walking down the entire kernel history.
The code to walk back from wanted ref is unnecessarily ugly and
inefficient -- if we only support a handful want's (say 25) at a
time, we could make the traversal go as we receive "have" by
using something similar to what show-branches does. I am
reworking on that part.
upload-pack.c | 182 ++++++++++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 167 insertions(+), 15 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 47560c9..e57733b 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -11,12 +11,18 @@ static const char upload_pack_usage[] =
#define THEY_HAVE (1U << 0)
#define OUR_REF (1U << 1)
#define WANTED (1U << 2)
+#define COMMON_KNOWN (1U << 3)
+
+#define TRACE_SEEN (1U << 4)
+#define TRACE_BASE 5
+#define MAX_TRACE 20 /* should not exceed bits_per_int - TRACE_BASE */
+
#define MAX_HAS 256
#define MAX_NEEDS 256
static int nr_has = 0, nr_needs = 0, multi_ack = 0, nr_our_refs = 0;
static int use_thin_pack = 0;
-static unsigned char has_sha1[MAX_HAS][20];
-static unsigned char needs_sha1[MAX_NEEDS][20];
+static struct object *has_sha1[MAX_HAS];
+static struct object *needs_sha1[MAX_NEEDS];
static unsigned int timeout = 0;
static void reset_timeout(void)
@@ -69,19 +75,22 @@ static void create_pack_file(void)
if (create_full_pack || MAX_NEEDS <= nr_needs)
*p++ = "--all";
else {
+ struct object **o = needs_sha1;
for (i = 0; i < nr_needs; i++) {
*p++ = buf;
- memcpy(buf, sha1_to_hex(needs_sha1[i]), 41);
+ memcpy(buf, sha1_to_hex((*o++)->sha1), 41);
buf += 41;
}
}
- if (!create_full_pack)
+ if (!create_full_pack) {
+ struct object **o = has_sha1;
for (i = 0; i < nr_has; i++) {
*p++ = buf;
*buf++ = '^';
- memcpy(buf, sha1_to_hex(has_sha1[i]), 41);
+ memcpy(buf, sha1_to_hex((*o++)->sha1), 41);
buf += 41;
}
+ }
*p++ = NULL;
execv_git_cmd(argv);
die("git-upload-pack: unable to exec git-rev-list");
@@ -93,6 +102,125 @@ static void create_pack_file(void)
die("git-upload-pack: unable to exec git-pack-objects");
}
+static int trace_want(struct object **trace, int cnt)
+{
+ /* start from these cnt objects, traverse the reachability
+ * chain, without parsing new objects, to see if we can
+ * reach objects they have.
+ */
+ int i, j;
+ unsigned trace_flags = 0;
+ struct object_list *list = NULL;
+
+ for (i = 0; i < cnt; i++)
+ trace_flags |= (1U << (TRACE_BASE + i));
+
+ for (i = 0; i < obj_allocs; i++)
+ if (objs[i])
+ objs[i]->flags &= ~trace_flags;
+
+ for (i = 0; i < cnt; i++) {
+ trace[i]->flags |= 1U << (TRACE_BASE + i);
+ object_list_insert(trace[i], &list);
+ }
+
+ while (list) {
+ struct object_list *next = list->next;
+ struct object *o = list->item;
+ unsigned flags = o->flags & trace_flags;
+
+ free(list);
+ list = next;
+ if (o->flags & TRACE_SEEN)
+ continue;
+ o->flags |= TRACE_SEEN;
+ if (!strcmp(o->type, tag_type)) {
+ o = deref_tag(o, NULL, 0);
+ if (o && (o->flags & trace_flags) != flags) {
+ o->flags |= flags;
+ object_list_insert(o, &list);
+ }
+ continue;
+ }
+ if (!strcmp(o->type, commit_type)) {
+ struct commit *c = (struct commit *)o;
+ struct commit_list *l = c->parents;
+ while (l) {
+ struct commit *p = l->item;
+ l = l->next;
+ if ((p->object.flags & trace_flags) != flags) {
+ p->object.flags |= flags;
+ object_list_insert(&p->object, &list);
+ }
+ }
+ }
+ }
+
+ /* Now scan the objects they have, and see if the wanted one
+ * reach which ones.
+ */
+ for (j = 0; j < nr_needs; j++) {
+ for (i = 0;
+ (i < nr_has &&
+ !(needs_sha1[j]->flags & COMMON_KNOWN));
+ i++) {
+ if (has_sha1[i]->flags & (1U << (TRACE_BASE + j)))
+ needs_sha1[j]->flags |= COMMON_KNOWN;
+ }
+ }
+
+ for (j = 0; j < nr_needs; j++) {
+ if (!(needs_sha1[j]->flags & COMMON_KNOWN))
+ return 1;
+ }
+ return 0;
+}
+
+static void check_want_heads(void)
+{
+ /* Do not keep saying "ack continue" if we already know
+ * common ancestor for all the "want"ed heads. This is
+ * particularly important if some of the "have" heads does
+ * not share any root commit with us. Otherwise we would
+ * keep asking for that branch, hoping we might get a better
+ * common ancestor than we already have.
+ */
+ int i, still_missing;
+ struct object *trace[MAX_TRACE];
+ int trace_bit;
+
+ if (!multi_ack)
+ return;
+
+ still_missing = 0;
+ trace_bit = 0;
+ for (i = 0; still_missing && i < nr_needs; i++) {
+ struct object *o = needs_sha1[i];
+ if (o->flags & COMMON_KNOWN)
+ continue;
+ if (strcmp(o->type, tag_type) &&
+ strcmp(o->type, commit_type))
+ /* Asking for non traceable types - there
+ * is not much we can do to optimize it here.
+ * We will let rev-list deal with it.
+ */
+ continue;
+ if (trace_bit < MAX_TRACE) {
+ trace[trace_bit] = o;
+ trace_bit++;
+ }
+ else {
+ still_missing = trace_want(trace, trace_bit);
+ trace_bit = 0;
+ }
+ }
+ if (trace_bit && !still_missing)
+ still_missing = trace_want(trace, trace_bit);
+
+ if (!still_missing)
+ multi_ack = 0;
+}
+
static int got_sha1(char *hex, unsigned char *sha1)
{
if (get_sha1_hex(hex, sha1))
@@ -107,15 +235,39 @@ static int got_sha1(char *hex, unsigned
die("oops (%s)", sha1_to_hex(sha1));
if (o->type == commit_type) {
struct commit_list *parents;
+ int we_knew_they_have = 0;
+
+ /* Because we deliberately stay behind by one
+ * window in order to make the protocol
+ * stream, many commits can already be in
+ * flight when we notice that the latest one
+ * in the series is already what we have. Do
+ * not waste the has_sha1[] slot for extra commits
+ * sent that way.
+ *
+ * This relies on fetch-pack sending the "have"
+ * lines without skipping.
+ */
if (o->flags & THEY_HAVE)
- return 0;
- o->flags |= THEY_HAVE;
+ we_knew_they_have = 1;
+ else
+ o->flags |= THEY_HAVE;
for (parents = ((struct commit*)o)->parents;
parents;
parents = parents->next)
parents->item->object.flags |= THEY_HAVE;
+ if (we_knew_they_have)
+ return 0;
}
- memcpy(has_sha1[nr_has++], sha1, 20);
+ has_sha1[nr_has++] = o;
+
+ /* Check to see if we know a common ancestor for
+ * all the "want" heads, and if so turn multi_ack
+ * off. There is nothing more gained by further
+ * exchange.
+ */
+ check_want_heads();
+
}
return 1;
}
@@ -141,7 +293,7 @@ static int get_common_commits(void)
len = strip(line, len);
if (!strncmp(line, "have ", 5)) {
if (got_sha1(line+5, sha1) &&
- (multi_ack || nr_has == 1)) {
+ (multi_ack || nr_has == 1)) {
if (nr_has >= MAX_HAS)
multi_ack = 0;
packet_write(1, "ACK %s%s\n",
@@ -156,7 +308,7 @@ static int get_common_commits(void)
if (nr_has > 0) {
if (multi_ack)
packet_write(1, "ACK %s\n",
- sha1_to_hex(last_sha1));
+ sha1_to_hex(last_sha1));
return 0;
}
packet_write(1, "NAK\n");
@@ -174,23 +326,21 @@ static int receive_needs(void)
needs = 0;
for (;;) {
struct object *o;
- unsigned char dummy[20], *sha1_buf;
+ unsigned char sha1_buf[20];
len = packet_read_line(0, line, sizeof(line));
reset_timeout();
if (!len)
return needs;
- sha1_buf = dummy;
if (needs == MAX_NEEDS) {
fprintf(stderr,
"warning: supporting only a max of %d requests. "
"sending everything instead.\n",
MAX_NEEDS);
}
- else if (needs < MAX_NEEDS)
- sha1_buf = needs_sha1[needs];
- if (strncmp("want ", line, 5) || get_sha1_hex(line+5, sha1_buf))
+ if (strncmp("want ", line, 5) ||
+ get_sha1_hex(line+5, sha1_buf))
die("git-upload-pack: protocol error, "
"expected to get sha, not '%s'", line);
if (strstr(line+45, "multi_ack"))
@@ -211,6 +361,8 @@ static int receive_needs(void)
die("git-upload-pack: not our ref %s", line+5);
if (!(o->flags & WANTED)) {
o->flags |= WANTED;
+ if (needs < MAX_NEEDS)
+ needs_sha1[needs] = o;
needs++;
}
}
--
1.3.3.g2a0a
^ permalink raw reply related
* [SCRIPT] chomp: trim trailing whitespace
From: Jeff Garzik @ 2006-05-27 2:27 UTC (permalink / raw)
To: Git Mailing List; +Cc: Linux Kernel
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
Attached to this email is chomp.pl, a Perl script which removes trailing
whitespace from several files. I've had this for years, as trailing
whitespace is one of my pet peeves.
Now that git-applymbox complains loudly whenever a patch adds trailing
whitespace, I figured this script may be useful to others.
Jeff
[-- Attachment #2: chomp.pl --]
[-- Type: application/x-perl, Size: 1043 bytes --]
^ permalink raw reply
* [PATCH] Actually support embedded Qt, make configuration code more robust
From: Pavel Roskin @ 2006-05-27 2:27 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
Add -DQWS and -fno-rtti flags for embedded Qt.
Don't add X11 flags for embedded Qt and threading specific flags for
non-multithreaded Qt.
Before checking for the Qt library, make sure it actually exists in the
Qt library path and not elsewhere.
Fix missing ";;" before "esac" (potentially non-portable).
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
config/gwqt.m4 | 40 ++++++++++++++++++++++++++--------------
1 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/config/gwqt.m4 b/config/gwqt.m4
index 78bed1d..cccccfe 100644
--- a/config/gwqt.m4
+++ b/config/gwqt.m4
@@ -91,17 +91,19 @@ fi
# Checking for possible dependencies of the Qt library
gwqt_save_LDFLAGS="$LDFLAGS"
-QT_LIBS="$X_PRE_LIBS -lX11 $X_EXTRA_LIBS"
-AC_CHECK_LIB(pthread, pthread_exit, [QT_LIBS="-lpthread $QT_LIBS"])
+QT_LIBS_X="$X_PRE_LIBS -lX11 $X_EXTRA_LIBS"
+AC_CHECK_LIB(pthread, pthread_exit, [QT_LIBS_MT="-lpthread $QT_LIBS"])
LDFLAGS="$LDFLAGS $X_LIBS"
-AC_CHECK_LIB(Xft, XftFontOpen, [QT_LIBS="-lXft $QT_LIBS"], , [$QT_LIBS])
+AC_CHECK_LIB(Xft, XftFontOpen, [QT_LIBS_X="-lXft $QT_LIBS_X"], , [$QT_LIBS_X])
# Checking for the Qt library
LDFLAGS="$LDFLAGS -L$QTLIBDIR"
for i in qt-mt qt qte-mt qte qt-gl; do
- AC_CHECK_LIB([$i], Get_Class, [qtlib="$i"; break], , [$QT_LIBS])
+ set X "$QTLIBDIR/lib$i."*
+ test "$[2]" = "$QTLIBDIR/lib$i.*" && continue
+ AC_CHECK_LIB([$i], main, [qtlib="$i"; break], , [$QT_LIBS_X $QT_LIBS_MT])
done
if test -z "$qtlib"; then
@@ -110,30 +112,40 @@ fi
LDFLAGS="$gwqt_save_LDFLAGS"
-# Calculate QT_CPPFLAGS
+# Calculate QT_CPPFLAGS, QT_LDFLAGS and QT_LIBS
+QT_LIBS="-l$qtlib"
case "$qtlib" in
- *-mt) QT_CPPFLAGS="-D_REENTRANT -DQT_THREAD_SUPPORT";;
+ *-mt)
+ QT_CPPFLAGS="-D_REENTRANT -DQT_THREAD_SUPPORT"
+ QT_LIBS="$QT_LIBS $QT_LIBS_MT";;
esac
+case "$qtlib" in
+ qte*)
+ QT_CPPFLAGS="-DQWS -fno-rtti";;
+ *)
+ QT_LIBS="$QT_LIBS $QT_LIBS_X"
+ QT_LDFLAGS="$X_LIBS";;
+esac
+
+# Add Qt include path
if test "$QTINCDIR" != "/usr/include"; then
QT_CPPFLAGS="-I$QTINCDIR $QT_CPPFLAGS"
fi
-AC_MSG_NOTICE([QT_CPPFLAGS = $QT_CPPFLAGS])
-AC_SUBST(QT_CPPFLAGS)
-# Calculate QT_LDFLAGS
-QT_LDFLAGS="$X_LIBS"
+# Add Qt library path
case "$QTLIBDIR" in
/usr/lib) ;;
/usr/lib64) ;;
/usr/X11R6/lib) ;;
- *) QT_LDFLAGS="$QT_LDFLAGS -L$QTLIBDIR";
+ *) QT_LDFLAGS="$QT_LDFLAGS -L$QTLIBDIR";;
esac
+
+# Report the results
+AC_MSG_NOTICE([QT_CPPFLAGS = $QT_CPPFLAGS])
+AC_SUBST(QT_CPPFLAGS)
AC_MSG_NOTICE([QT_LDFLAGS = $QT_LDFLAGS])
AC_SUBST(QT_LDFLAGS)
-
-# Calculate QT_LIBS
-QT_LIBS="-l$qtlib $QT_LIBS"
AC_MSG_NOTICE([QT_LIBS = $QT_LIBS])
AC_SUBST(QT_LIBS)
])
^ permalink raw reply related
* Re: ~/.git/config ?
From: Pavel Roskin @ 2006-05-27 2:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Timo Hirvonen, Anand Kumria, git
In-Reply-To: <20060526163829.GB10488@pasky.or.cz>
On Fri, 2006-05-26 at 18:38 +0200, Petr Baudis wrote:
> Dear diary, on Fri, May 26, 2006 at 06:33:25PM CEST, I got a letter
> where Timo Hirvonen <tihirvon@gmail.com> said that...
> > I backup my $HOME using git, so there's a .git directory in ~.
>
> Then it should be called ~/.gitconfig. :-)
No, make it .gitrc for compatibility with .cvsrc, .lynxrc and others.
I know, it's becoming a bikeshed issue :-)
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: ~/.git/config ?
From: Petr Baudis @ 2006-05-27 2:57 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Timo Hirvonen, Anand Kumria, git
In-Reply-To: <1148697382.5599.1.camel@dv>
Dear diary, on Sat, May 27, 2006 at 04:36:22AM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> On Fri, 2006-05-26 at 18:38 +0200, Petr Baudis wrote:
> > Dear diary, on Fri, May 26, 2006 at 06:33:25PM CEST, I got a letter
> > where Timo Hirvonen <tihirvon@gmail.com> said that...
> > > I backup my $HOME using git, so there's a .git directory in ~.
> >
> > Then it should be called ~/.gitconfig. :-)
>
> No, make it .gitrc for compatibility with .cvsrc, .lynxrc and others.
~/.gitrc might get useful for actually doing what ~/.cvsrc or ~/.cgrc
does, that is providing default options for git commands. ~/.gitconfig
would just give you per-user defaults for the repository config file.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: ~/.git/config ?
From: Linus Torvalds @ 2006-05-27 3:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Pavel Roskin, Timo Hirvonen, Anand Kumria, git
In-Reply-To: <20060527025750.GM11941@pasky.or.cz>
On Sat, 27 May 2006, Petr Baudis wrote:
>
> ~/.gitrc might get useful for actually doing what ~/.cvsrc or ~/.cgrc
> does, that is providing default options for git commands. ~/.gitconfig
> would just give you per-user defaults for the repository config file.
I don't think the two are necessarily any different.
I do think that
(a) we might as well use the same syntax. There's no point in having
different syntax for the files, even if they end up having slightly
different usage.
(b) a "user-wide" config file would tend to have different things in it
than a per-repository one, but some of the things it would have in it
are the things that we currently put in the per-repository one.
Notably exactly the "user.name" and "user.email" values.
(c) having a user- (and perhaps a system-) wide config file would make
some things that we do not _yet_ support in the .git/config file
format more natural, but that doesn't necessarily mean that having
them on a per-repo basis would be wrong either.
As an example of (c), let's say that somebody wants to use the CVS aliases
with git. They've used cvs for years, and as a result their brain has
atrophied, and they have a really hard time teaching their fingers to
write "git commit" when they want to write "cvs ci".
So they would do "alias cvs git" in a desperate attempt to save themselves
from CVS, and then add
[alias "co"]
cmd = commit -a
to their .gitrc file. Now, the only thing we'd need to do is to teach
"git.c" to parse that simple "alias.$1.command" variable, and that really
sounds pretty damn easy, no?
And that really does make more sense in a user-wide ".gitrc" file. But at
the same time, there's really no reason to _disallow_ it from the
repo-private .git/config file either. For example, you could do
[alias "publish"]
cmd = push public.site.com:/pub/scm/my-public-repo
and that is somethign that actually makes sense as a per-repository
command alias, so that "git publish" does the right thing for just _that_
repository.
So I would argue that yes, ".gitrc" makes sense, and no, we shouldn't have
a separate ".gitrc" and ".gitconfig", because I think what we really would
want is a way to do default .git/config entries, and that it is _also_ a
very natural way to add some things that we don't do yet.
Linus
PS. I really like my [alias "cmd"] idea. _All_ my ideas are great, of
course, but this one seems even better than some others. No?
^ permalink raw reply
* Re: ~/.git/config ?
From: Linus Torvalds @ 2006-05-27 3:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Pavel Roskin, Timo Hirvonen, Anand Kumria, git
In-Reply-To: <Pine.LNX.4.64.0605262007230.5623@g5.osdl.org>
On Fri, 26 May 2006, Linus Torvalds wrote:
>
> So they would do "alias cvs git" in a desperate attempt to save themselves
> from CVS, and then add
>
> [alias "co"]
> cmd = commit -a
That, of course, would be confusing.
It should be "ci" for commit, and "co" for "checkout".
Duh. Chalk it up to me not having used cvs in the last three or four years
or so (we used it at transmeta, although I can hope that they've since
seen the light ;).
Linus
^ permalink raw reply
* Re: ~/.git/config ?
From: Jakub Narebski @ 2006-05-27 3:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605262007230.5623@g5.osdl.org>
Linus Torvalds wrote:
> PS. I really like my [alias "cmd"] idea. _All_ my ideas are great, of
> course, but this one seems even better than some others. No?
So, would we use it also for default options of commands, like
[alias "log"]
cmd = log -p -M -C
(we could implement "git whatchanges" as an alias, keeping it's man page, or
sharing it with "git log").
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: ~/.git/config ?
From: Junio C Hamano @ 2006-05-27 4:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605262033560.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> [alias "co"]
>> cmd = commit -a
>
> That, of course, would be confusing.
>
> It should be "ci" for commit, and "co" for "checkout".
>
> Duh. Chalk it up to me not having used cvs in the last three or four years
> or so (we used it at transmeta, although I can hope that they've since
> seen the light ;).
>
> Linus
You are lucky ;-).
The alias would be a nice addition -- I can get rid of the hack
I have for show-branch. We would need an argument splitter, but
that should be trivial.
^ permalink raw reply
* Re: [PATCH] Actually support embedded Qt, make configuration code more robust
From: Marco Costalba @ 2006-05-27 6:22 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20060527022735.5879.58043.stgit@dv.roinet.com>
On 5/27/06, Pavel Roskin <proski@gnu.org> wrote:
> Add -DQWS and -fno-rtti flags for embedded Qt.
>
> Don't add X11 flags for embedded Qt and threading specific flags for
> non-multithreaded Qt.
>
> Before checking for the Qt library, make sure it actually exists in the
> Qt library path and not elsewhere.
>
Thanks, patch applied.
Please note that qgit public repository has changed. It is now
git://git.kernel.org/pub/scm/qgit/qgit.git
Marco
^ permalink raw reply
* Re: ~/.git/config ?
From: Nikolai Weibull @ 2006-05-27 8:50 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Petr Baudis, Timo Hirvonen, Anand Kumria, git
In-Reply-To: <1148697382.5599.1.camel@dv>
On 5/27/06, Pavel Roskin <proski@gnu.org> wrote:
> On Fri, 2006-05-26 at 18:38 +0200, Petr Baudis wrote:
> > Dear diary, on Fri, May 26, 2006 at 06:33:25PM CEST, I got a letter
> > where Timo Hirvonen <tihirvon@gmail.com> said that...
> > > I backup my $HOME using git, so there's a .git directory in ~.
> >
> > Then it should be called ~/.gitconfig. :-)
>
> No, make it .gitrc for compatibility with .cvsrc, .lynxrc and others.
>
> I know, it's becoming a bikeshed issue :-)
I want to paint part of it as well!
Wouldn't we be futureproofing ourselves by stuffing it in a
subdirectory instead? What if we want to add more files later?
Also, can we please make sure to make the location of the file (or
directory) configurable through an environment variable, e.g.,
GIT_CONFIG, GIT_USER_CONFIG, GIT_HOME, or GIT_USER_HOME?
Peace.
nikolai
^ permalink raw reply
* Re: ~/.git/config ?
From: Timo Hirvonen @ 2006-05-27 9:09 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: proski, pasky, wildfire, git
In-Reply-To: <dbfc82860605270150s5c43e32fja2e7ef934bc1ef0@mail.gmail.com>
"Nikolai Weibull" <now@bitwi.se> wrote:
> On 5/27/06, Pavel Roskin <proski@gnu.org> wrote:
> > On Fri, 2006-05-26 at 18:38 +0200, Petr Baudis wrote:
> > >
> > > Then it should be called ~/.gitconfig. :-)
> >
> > No, make it .gitrc for compatibility with .cvsrc, .lynxrc and others.
> >
> > I know, it's becoming a bikeshed issue :-)
>
> I want to paint part of it as well!
>
> Wouldn't we be futureproofing ourselves by stuffing it in a
> subdirectory instead? What if we want to add more files later?
Makes sense, we may want to put templates to ~/.gitsomething/templates/.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: ~/.git/config ?
From: Junio C Hamano @ 2006-05-27 9:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605262007230.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 27 May 2006, Petr Baudis wrote:
>>
>> ~/.gitrc might get useful for actually doing what ~/.cvsrc or ~/.cgrc
>> does, that is providing default options for git commands. ~/.gitconfig
>> would just give you per-user defaults for the repository config file.
>
> I don't think the two are necessarily any different.
Me neither. Default options to fall back on if repository
configuration does not specify them and when environments do not
override them -- that's exactly "per-user defaults", nothing else.
Earlier I suggested ~/.git-config, but anything other than
~/.git/config is OK. ~/.gitrc is fine. And the order suggested
by Anand sounded fine.
- use environment (if the value is obtained, stop here)
- use .git/config (if the value is obtained, stop here)
- use ~/.git-config (if the value is obtained, stop here)
- do whatever the program does by default.
> (a) we might as well use the same syntax. There's no point in having
> different syntax for the files, even if they end up having slightly
> different usage.
Absolutely.
> (b) a "user-wide" config file would tend to have different things in it
> than a per-repository one, but some of the things it would have in it
> are the things that we currently put in the per-repository one.
> Notably exactly the "user.name" and "user.email" values.
Yes. Also "preference" kind of things as opposed to "per
project policy" such as apply.whitespace.
^ permalink raw reply
* Re: git-format-patch possible regressions
From: Marco Costalba @ 2006-05-27 9:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pzdqpit.fsf@assigned-by-dhcp.cox.net>
On 5/26/06, Junio C Hamano <junkio@cox.net> wrote:
>
> What Johannes and I were discussing was the other number -- the
> total in the series. IOW, y in "[PATCH x/y]". OTOH, the number
> used for disambiguation you care about is x, which is made
> adjustable with --start-number patch.
>
New --start-number patch says:
"Since the "a..b c..d" syntax is interpreted as "b ^a d ^c" as other
range-ish commands, if you want to format a..b and then c..d and end
up with files consecutively numbered, the second run needs to be able
to tell the command what number to start from.
This does not imply --numbered (which gives [PATCH n/m] to the subject)."
Actually it seems that --numbered is needed anyway.
$ git-format-patch HEAD^..HEAD
0000-git-format-patch-start-number-n.txt
$ git-format-patch --start-number=7 HEAD^..HEAD
0000-git-format-patch-start-number-n.txt
$ git-format-patch --numbered --start-number=7 HEAD^..HEAD
0007-git-format-patch-start-number-n.txt
But with numbered also the patch subject is changed with added [PATCH n/m] that
is not needed.
Also mutually exclusive check is not performed
git-format-patch -n -k HEAD^..HEAD
0001-git-format-patch-start-number-n.txt
This patch should fix all.
Subject: [PATCH] Let git-format-patch --start-number option to work
also without --numbered
While there also fix the check for mutually exclusive -n and -k option
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
builtin-log.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 71f4ff9..c35733f 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -148,7 +148,7 @@ int cmd_format_patch(int argc, const cha
int nr = 0, total, i, j;
int use_stdout = 0;
int numbered = 0;
- int start_number = -1;
+ int start_number = 0;
int keep_subject = 0;
init_revisions(&rev);
@@ -201,9 +201,9 @@ int cmd_format_patch(int argc, const cha
}
argc = j;
- if (numbered && start_number < 0)
+ if (numbered && start_number == 0)
start_number = 1;
- if (numbered && keep_subject < 0)
+ if (numbered && keep_subject)
die ("-n and -k are mutually exclusive.");
argc = setup_revisions(argc, argv, &rev, "HEAD");
@@ -233,7 +233,7 @@ int cmd_format_patch(int argc, const cha
while (0 <= --nr) {
int shown;
commit = list[nr];
- rev.nr = rev.total - nr;
+ rev.nr = start_number + total - nr - 1;
if (!use_stdout)
reopen_stdout(commit, rev.nr, keep_subject);
shown = log_tree_commit(&rev, commit);
--
1.3.3.gfa0f-dirty
^ permalink raw reply related
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Jan Engelhardt @ 2006-05-27 10:15 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List, Linux Kernel
In-Reply-To: <4477B905.9090806@garzik.org>
> Attached to this email is chomp.pl, a Perl script which removes trailing
> whitespace from several files. I've had this for years, as trailing whitespace
> is one of my pet peeves.
>
> Now that git-applymbox complains loudly whenever a patch adds trailing
> whitespace, I figured this script may be useful to others.
>
Pretty long script. How about this two-liner? It does not show 'bytes
chomped' but it also trims trailing whitespace.
#!/usr/bin/perl -i -p
s/[ \t\r\n]+$//
Jan Engelhardt
--
^ permalink raw reply
* gitview: Add key binding for F5.
From: Aneesh Kumar K.V @ 2006-05-27 10:24 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-gitview-Add-key-binding-for-F5.txt --]
[-- Type: text/plain, Size: 2342 bytes --]
gitview: Add key binding for F5.
F5 will now refresh the window. This is useful if you are using git bisect
and want to visualize the change.
Also update the gitview version
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 17 +++++++++++++----
contrib/gitview/gitview.txt | 6 ++++--
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 781badb..c708534 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -425,7 +425,7 @@ class DiffWindow:
class GitView:
""" This is the main class
"""
- version = "0.7"
+ version = "0.8"
def __init__(self, with_diff=0):
self.with_diff = with_diff
@@ -449,8 +449,17 @@ class GitView:
self.accel_group = gtk.AccelGroup()
self.window.add_accel_group(self.accel_group)
+ self.accel_group.connect_group(0xffc2, 0, gtk.ACCEL_LOCKED, self.refresh);
- self.construct()
+ self.window.add(self.construct())
+
+ def refresh(self, widget, event=None, *arguments, **keywords):
+ self.get_encoding()
+ self.get_bt_sha1()
+ Commit.children_sha1 = {}
+ self.set_branch(sys.argv[without_diff:])
+ self.window.show()
+ return True
def get_bt_sha1(self):
""" Update the bt_sha1 dictionary with the
@@ -500,9 +509,9 @@ class GitView:
menu_bar.show()
vbox.pack_start(menu_bar, expand=False, fill=True)
vbox.pack_start(paned, expand=True, fill=True)
- self.window.add(vbox)
paned.show()
vbox.show()
+ return vbox
def construct_top(self):
@@ -987,8 +996,8 @@ class GitView:
window.set_diff(commit_sha1, parent_sha1, encoding)
self.treeview.grab_focus()
+without_diff = 0
if __name__ == "__main__":
- without_diff = 0
if (len(sys.argv) > 1 ):
if (sys.argv[1] == "--without-diff"):
diff --git a/contrib/gitview/gitview.txt b/contrib/gitview/gitview.txt
index fcf759c..e3bc4f4 100644
--- a/contrib/gitview/gitview.txt
+++ b/contrib/gitview/gitview.txt
@@ -25,6 +25,9 @@ OPTIONS
<args>
All the valid option for git-rev-list(1)
+ Key Bindings:
+ F5:
+ To reread references.
EXAMPLES
------
@@ -33,6 +36,5 @@ EXAMPLES
or drivers/scsi subdirectories
gitview --since=2.weeks.ago
- Show the changes during the last two weeks
+ Show the changes during the last two weeks
-
--
1.3.3.g4d548-dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox