* Make "gitk" work better with dense revlists
From: Linus Torvalds @ 2005-10-25 20:01 UTC (permalink / raw)
To: Paul Mackerras, Junio C Hamano, Git Mailing List
To generate the diff for a commit, gitk used to do
git-diff-tree -p -C $p $id
(and same thing to generate filenames, except using just "-r" there) which
does actually generate the diff from the parent to the $id, exactly like
it meant to do.
However, that really sucks with --dense, where the "parent" information
has all been rewritten to point to the previous commit. The diff actually
works exactly right, but now it's the diff of the _whole_ sequence of
commits all the way to the previous commit that last changed the file(s)
that we are looking at.
And that's really not what we want 99.9% of the time, even if it may be
perfectly sensible. Not only will the diff not actually match the commit
message, but it will usually be _huge_, and all of it will be totally
uninteresting to us, since we were only interested in a particular set of
files.
It also doesn't match what we do when we write the patch to a file.
So this makes gitk just show the diff of _that_ commit.
We might even want to have some way to limit the diff to only the
filenames we're interested in, but it's often nice to see what else
changed at the same time, so that's secondary.
The merge diff handling is left alone, although I think that should also
be changed to only look at what that _particular_ merge did, not what it
did when compared to the faked-out parents.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Hmm?
Also, having now tested the previous "handle root commit in the
TREECHANGED" logic a bit more, I think it's (a) stable and (b) the right
thing to do. Sign me off on that one too.
Linus
diff --git a/gitk b/gitk
index f1ea4e1..a9d37d9 100755
--- a/gitk
+++ b/gitk
@@ -2806,7 +2806,7 @@ proc gettreediffs {ids} {
set treediff {}
set id [lindex $ids 0]
set p [lindex $ids 1]
- if [catch {set gdtf [open "|git-diff-tree -r $p $id" r]}] return
+ if [catch {set gdtf [open "|git-diff-tree -r $id" r]}] return
fconfigure $gdtf -blocking 0
fileevent $gdtf readable [list gettreediffline $gdtf $ids]
}
@@ -2842,7 +2842,7 @@ proc getblobdiffs {ids} {
set id [lindex $ids 0]
set p [lindex $ids 1]
set env(GIT_DIFF_OPTS) $diffopts
- set cmd [list | git-diff-tree -r -p -C $p $id]
+ set cmd [list | git-diff-tree -r -p -C $id]
if {[catch {set bdf [open $cmd r]} err]} {
puts "error getting diffs: $err"
return
^ permalink raw reply related
* Re: Convention for help in git commands?
From: Junio C Hamano @ 2005-10-25 18:56 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200510251508.43552.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> * All git commands should react on command line option "-h"
> for help, dumping a few lines to stderr, prefixed by "usage:", giving
> the command usage without further descriptions. For the usage
> output, use the base name of the command, and not the absolute
> path to the binary.
It drives me nuts when an error message shows only basename not
full path and I find out that I was running a wrong executable
much later after wasting a lot of time trying to debug it. But
I think "usage: " saying the basename only is user friendly and
a good convention.
> * For commands which need at least one argument, the usage
> is also printed, if the command is run without argument
This is slightly debatable. I'd rather see it error out for one
thing, and we might want to do a sane default given no arguments
later.
> Perhaps these things should be done only for commands of the
> git lightwight porcelain?
Probably.
^ permalink raw reply
* Re: [PATCH] Make fetch-pack play nicer with servers which do not speak multi_ack
From: Junio C Hamano @ 2005-10-25 18:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510251104470.24174@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 1139 bytes --]
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> But you are right. If you made 20 commits on top of my "master"
>> branch head, we should send those 20 (and the commit you based
>> on your changes, which the other end has), way before sending
>> the ancient v0.99 tag. Probably, we should never be sending
>> v0.99 tag as "have" if we are going to send your "master" branch
>> head, since the commit that tag refers to is reachable by your
>> "master" branch head but there are a lot more commit between
>> them, some of which will give us better "common" selected, and
>> that v0.99 tag is what the other end said they have so is known
>> to be ACKed if sent.
>
> You^[.A^[N4re right. Complete common refs are sent even if they are ancestors of
> other complete common refs. I^[.A^[N4ll think about that.
I just realized that I have two refs you would rather send the
last while fetching from me most of the time: junio-gpg-pub tag
and todo head. If you manage to get acked either by non multi
aware remote before saying "have" on anything on the main
branch, I think you would get *everything* back --- which is
quite bad.
^ permalink raw reply
* Re: git-rev-list: add "--dense" flag
From: Linus Torvalds @ 2005-10-25 18:52 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20051025184030.GB7463@diku.dk>
On Tue, 25 Oct 2005, Jonas Fonseca wrote:
>
> Without the workaround below it segfaults.
Yes, but your patch only partly helps. It fixes the SIGSEGV, but it still
needs to remove the "parents" pointer when the parent ends up NULL.
The patch I just sent out should be better. I think.
Linus
^ permalink raw reply
* Re: git-rev-list: add "--dense" flag
From: Linus Torvalds @ 2005-10-25 18:50 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510251110050.10477@g5.osdl.org>
On Tue, 25 Oct 2005, Linus Torvalds wrote:
>
> Right now --dense will _always_ show the root commit. I didn't do the
> logic that does the diff against an empty tree. I was lazy.
>
> This patch does that, and may or may not work.
Never mind. It's incorrect.
It's -close- to being correct, but it will SIGSEGV because now the root
won't necessarily have the TREECHANGED flag, so now it can follow the root
down to its parents (which is a NULL pointer - that's the definition of a
root commit, of course).
It needs to remove the parent pointers that become NULL.
This patch is even slightly tested, and might do a better job.
[ Sorry for sending untested crap out, but I have a fairly good track
record in general. Testing is for wimps ]
Linus
---
diff --git a/rev-list.c b/rev-list.c
index 5f125fd..edf3b37 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -81,23 +81,28 @@ static void show_commit(struct commit *c
fflush(stdout);
}
-static void rewrite_one(struct commit **pp)
+static int rewrite_one(struct commit **pp)
{
for (;;) {
struct commit *p = *pp;
if (p->object.flags & (TREECHANGE | UNINTERESTING))
- return;
- /* Only single-parent commits don't have TREECHANGE */
+ return 0;
+ if (!p->parents)
+ return -1;
*pp = p->parents->item;
}
}
static void rewrite_parents(struct commit *commit)
{
- struct commit_list *parent = commit->parents;
- while (parent) {
- rewrite_one(&parent->item);
- parent = parent->next;
+ struct commit_list **pp = &commit->parents;
+ while (*pp) {
+ struct commit_list *parent = *pp;
+ if (rewrite_one(&parent->item) < 0) {
+ *pp = parent->next;
+ continue;
+ }
+ pp = &parent->next;
}
}
@@ -439,6 +444,30 @@ static int same_tree(struct tree *t1, st
return !is_different;
}
+static int same_tree_as_empty(struct tree *t1)
+{
+ int retval;
+ void *tree;
+ struct tree_desc empty, real;
+
+ if (!t1)
+ return 0;
+
+ tree = read_object_with_reference(t1->object.sha1, "tree", &real.size, NULL);
+ if (!tree)
+ return 0;
+ real.buf = tree;
+
+ empty.buf = "";
+ empty.size = 0;
+
+ is_different = 0;
+ retval = diff_tree(&empty, &real, "", &diff_opt);
+ free(tree);
+
+ return retval >= 0 && !is_different;
+}
+
static struct commit *try_to_simplify_merge(struct commit *commit, struct commit_list *parent)
{
if (!commit->tree)
@@ -523,11 +552,17 @@ static void compress_list(struct commit_
struct commit_list *parent = commit->parents;
list = list->next;
+ if (!parent) {
+ if (!same_tree_as_empty(commit->tree))
+ commit->object.flags |= TREECHANGE;
+ continue;
+ }
+
/*
* Exactly one parent? Check if it leaves the tree
* unchanged
*/
- if (parent && !parent->next) {
+ if (!parent->next) {
struct tree *t1 = commit->tree;
struct tree *t2 = parent->item->tree;
if (!t1 || !t2 || same_tree(t1, t2))
^ permalink raw reply related
* Re: git-rev-list: add "--dense" flag
From: Jonas Fonseca @ 2005-10-25 18:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510251110050.10477@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote Tue, Oct 25, 2005:
> On Tue, 25 Oct 2005, Jonas Fonseca wrote:
> >
> > Is the initial commit supposed to be listed when the file has been added
> > later?
>
> Right now --dense will _always_ show the root commit. I didn't do the
> logic that does the diff against an empty tree. I was lazy.
>
> This patch does that, and may or may not work.
Without the workaround below it segfaults.
> Does this match what you expected?
Yes, thanks.
diff --git a/rev-list.c b/rev-list.c
index 5f125fd..82ec656 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -87,6 +87,7 @@ static void rewrite_one(struct commit **
struct commit *p = *pp;
if (p->object.flags & (TREECHANGE | UNINTERESTING))
return;
+ if (!p->parents) return;
/* Only single-parent commits don't have TREECHANGE */
*pp = p->parents->item;
}
--
Jonas Fonseca
^ permalink raw reply related
* Re: git-rev-list: add "--dense" flag
From: Linus Torvalds @ 2005-10-25 18:23 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20051025180707.GA7463@diku.dk>
On Tue, 25 Oct 2005, Jonas Fonseca wrote:
>
> Is the initial commit supposed to be listed when the file has been added
> later?
Right now --dense will _always_ show the root commit. I didn't do the
logic that does the diff against an empty tree. I was lazy.
This patch does that, and may or may not work.
Does this match what you expected?
Linus
----
diff --git a/rev-list.c b/rev-list.c
index 5f125fd..038dae2 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -439,6 +439,30 @@ static int same_tree(struct tree *t1, st
return !is_different;
}
+static int same_tree_as_empty(struct tree *t1)
+{
+ int retval;
+ void *tree;
+ struct tree_desc empty, real;
+
+ if (!t1)
+ return 0;
+
+ tree = read_object_with_reference(t1->object.sha1, "tree", &real.size, NULL);
+ if (!tree)
+ return 0;
+ real.buf = tree;
+
+ empty.buf = "";
+ empty.size = 0;
+
+ is_different = 0;
+ retval = diff_tree(&empty, &real, "", &diff_opt);
+ free(tree);
+
+ return !retval && !is_different;
+}
+
static struct commit *try_to_simplify_merge(struct commit *commit, struct commit_list *parent)
{
if (!commit->tree)
@@ -523,11 +547,17 @@ static void compress_list(struct commit_
struct commit_list *parent = commit->parents;
list = list->next;
+ if (!parent) {
+ if (!same_tree_as_empty(commit->tree))
+ commit->object.flags |= TREECHANGE;
+ continue;
+ }
+
/*
* Exactly one parent? Check if it leaves the tree
* unchanged
*/
- if (parent && !parent->next) {
+ if (!parent->next) {
struct tree *t1 = commit->tree;
struct tree *t2 = parent->item->tree;
if (!t1 || !t2 || same_tree(t1, t2))
^ permalink raw reply related
* Re: git-rev-list: add "--dense" flag
From: Jonas Fonseca @ 2005-10-25 18:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510211631400.10477@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote Fri, Oct 21, 2005:
> To see this in action, try something like
>
> gitk --dense -- gitk
>
> to see just the history that affects gitk.
Is the initial commit supposed to be listed when the file has been added
later? I would expect it to only list until (and including) the commit
where the file was introduced.
prompt > git-rev-list --dense HEAD -- compat/mmap.c
f48000fcbe1009c18f1cc46e56cde2cb632071fa
730d48a2ef88a7fb7aa4409d40b1e6964a93267f
e83c5163316f89bfbde7d9ab23ca2e25604af290
prompt > git-cat-file commit e83c
tree 2b5bfdf7798569e0b59b16eb9602d5fa572d6038
author Linus Torvalds <torvalds@ppc970.osdl.org> 1112911993 -0700
committer Linus Torvalds <torvalds@ppc970.osdl.org> 1112911993 -0700
Initial revision of "git", the information manager from hell
Interestingly, for the special gitk, the correct commit is the last rev
listed.
--
Jonas Fonseca
^ permalink raw reply
* Re: gitweb: charset problem
From: Junio C Hamano @ 2005-10-25 17:44 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510251138290.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> It wouldn't be hard to convert at some point between the editor and the
> commit object, and you don't re-edit the commit objects like you do
> tracked files. It probably wouldn't even be hard for commit-tree to
> convert its input based on locale. (And stuff which prints commit contents
> for user consumption probably ought to re-encode it if necessary, too)
Don't get me wrong. I am not opposed to giving preferential
treatment to UTF-8 by supporting it better. I think it may be a
good idea to have an *option* in commit-tree and mktag to
convert from LC_CTYPE to utf-8, just like mailinfo does.
I am just opposing to make UTF-8 mandatory.
^ permalink raw reply
* Re: 0.99.9 on Saturday next week.
From: Linus Torvalds @ 2005-10-25 17:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Catalin Marinas, git
In-Reply-To: <7virvlh6m5.fsf@assigned-by-dhcp.cox.net>
On Tue, 25 Oct 2005, Junio C Hamano wrote:
>
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>
> >> - Configuration files (Linus).
> >
> > Since the configuration files use the .ini like syntax, is it OK for
> > StGIT to use the same file, with an "[stgit]" section?
>
> I think that is a reasonable thing to do.
Absolutely. The whole thing was _designed_ to be used that way. Any C user
should be able to just link against config.o without even bothering with
the rest of git (the only git-specific thing there should be some naming),
and any script user can either
- parse the simple config language by hand (not really a good idea, but
it _is_ pretty simple)
- just run "git-var -l" and parse the output.
ie if you want to track "[stgit]" config options, just do
git-var -l | sed '/^stgit\./ s/^stgit.//p'
and it will pick up everything starting with "stgit." and remove that
part.
What remains should be a simple list or "variable=value" pairs.
Oh - and the convention is that
(a) we've already done any quote expansion (although I may have to make
git-var quote "\n" - I didn't care enough to do so)
(b) a boolean variable without a "=" means that it was set to "true"
(which is different from an _empty_ one, which has a "=" but just
doesn't have any value)
The (b) thing is just a special case, so that you can write
[stgit]
debug
and it will be the same as
[stgit]
debug = true
which just seems to be the sane thing to do.
Linus
^ permalink raw reply
* Re: [PATCH] fetch/upload: Fix corner case with few revs
From: Junio C Hamano @ 2005-10-25 17:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510251730200.12176@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When git-fetch-pack did not have enough revs to send, it did not realize
> that the server actually speaks multi_ack. The server would now continue
> sending ack', but the client would try to unpack objects. Oops.
I've already pushed your initial set out to "master", but I
suspect we may be better of if I recall them and let it simmer a
bit longer in the proposed updates branch, and defer them post
0.99.9. What do you think?
^ permalink raw reply
* Re: gitweb: charset problem
From: Junio C Hamano @ 2005-10-25 17:31 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510251138290.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> Consider if you started a project in EUC-JP, and then decided to switch to
> UTF-8 later (when your environment handled it cleanly, perhaps). You could
> convert...
I am not saying that using UTF-8 is impossible in some
situations. I am saying that if all involved parties agree to
use something else in a private project, that is their choice
and there is no reason to forbid it. They may be shooting in
the foot in the long run, they may be not.
For the internal project I was using as an example, I do not
forsee anybody who does not do Japanese ever touching it, nor it
needs to record any other language in the future (this comes
from the nature of the project -- keeping track of some
documents that are written in Japanese and we are not in
translation business). Log and contents being encoded in EUC-JP
is perfectly valid right now and in the future in that project.
In such an application there is nothing gained by using UTF-8,
and it will only inconvenience the users if we insisted on
UTF-8.
^ permalink raw reply
* Re: How to clone faster via ssh ?
From: Junio C Hamano @ 2005-10-25 17:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510251103110.24174@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 25 Oct 2005, Alexander Litvinov wrote:
>
>> Forgot to tell:
>> clone via ssh was made using this command:
>> time git-clone -n ssh://lan@lan/home/lan/tmp/git/billing/repo r3
>
> If you have a working git on the other side, you could do
>
> time git-clone lan@lan:/home/lan/tmp/git/billing/repo r3
>
> which would utilize git-clone-pack. Way faster.
I think both of these notations do the same.
The time to unpack the resulting pack on this end is eliminated
if you use git from last week, namely this commit:
commit e1c7ada6dd1fdf249d0bb84f3293d3be768b9239
Author: Junio C Hamano <junkio@cox.net>
Date: Wed Oct 19 14:43:43 2005 -0700
git-clone: always keep pack sent from remote.
This deprecates --keep and -q flags and always keeps the
pack
sent from the remote site. Corresponding configuration
variables are also removed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
But you would still pay for creating a pack on the remote side.
^ permalink raw reply
* Re: 0.99.9 on Saturday next week.
From: Junio C Hamano @ 2005-10-25 17:02 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnx64rlrjux.fsf@arm.com>
Catalin Marinas <catalin.marinas@gmail.com> writes:
>> - Configuration files (Linus).
>
> Since the configuration files use the .ini like syntax, is it OK for
> StGIT to use the same file, with an "[stgit]" section?
I think that is a reasonable thing to do.
^ permalink raw reply
* Re: latest stg/git commandline completions code
From: Blaisorblade @ 2005-10-25 17:05 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Ben Clifford, git
In-Reply-To: <b0943d9e0510250924g3f5d9281r@mail.gmail.com>
On Tuesday 25 October 2005 18:24, Catalin Marinas wrote:
> On 25/10/05, Blaisorblade <blaisorblade@yahoo.it> wrote:
> > The best idea seems to write a Python script sourcing the Stgit source
> > (stgit/main.py to get commands, and then loading each class and iterating
> > over the "options" module member).
> I can add a function in stgit/main.py which would list the options.
> The tla-completion generates a file listing a command with its option
> on every line:
> push -a -all -n --number -t --to --reverse --undo -h --help
> ...
> Since I don't know much about the bash completion, let me know of the
> format you'd prefer.
Ok, I'll look into that. Probably it'll be around "opts_push="-a --all -n
--number...", i.e. this one works fine, through name indirection, i.e. you
say "expand the var which name is given by this expr".
> > Btw, what do you think about speeding up completions by reimplementing
> > things like "stg applied" or "stg unapplied" via cat (as noted in the
> > comments at the beginning of the script)? Tab completions can easily
> > livelock a shell on a busy system, so it's worthy speeding the thing up.
> In general, it is better to use the stg commands but the repository
> structure won't probably change for a long time
Ok.
> and it's OK to
> optimise (if the speed improvement is visible).
I believe it is, yes.
> Anyway, these
> particular commands are pretty fast (they behave like cat) but there
> are others which are slower (usually the commands involving calls to
> the GIT tool).
They _would_ behave like cat, except that Python is slow enough. Half a second
on a (almost) idle system means seconds and seconds on a busy system, and
it's pretty frequent that when I don't wait enough for an op. to complete I
get a traceback from the import statements, which haven't been completed.
And let's leave Gentoo's emerge alone - I'd say imports can take up to a
minute.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: [RFC] GIT paths
From: H. Peter Anvin @ 2005-10-25 16:53 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <435E259D.3040701@op5.se>
Andreas Ericsson wrote:
>>
>> - Over a git-daemon connection, supporting ~user expansion
>> makes sense. E.g git://host.xz/~junio/ refers to my home
>> directory on that machine. It would make it impossible to
>> have a directory literally named '~junio' directly underneath
>> the root directory, but that is a good limitation anyway.
>>
>
> I like this idea, although I'd extend it with a Userdir-like config
> option in git-daemon (like ~/public_html for apache). This makes it a
> bit easier to see what's published and what isn't.
>
I've found that whenever one does a network daemon which exports paths,
sooner or later one wants namespace management. In Linux, of course,
there are a lot more tricks one can play to actually create the
namespace one wants in the filesystem (although it's complicated by
needing to have an exec-worthy environment.)
It might be worth to consider creating a library to do this.
-hpa
^ permalink raw reply
* Re: The MIT error
From: H. Peter Anvin @ 2005-10-25 16:50 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: GIT Mailing List
In-Reply-To: <435E3892.4020002@op5.se>
Andreas Ericsson wrote:
>
> No they don't. "begin with either is or to and a lowercase letter",
> meaning (is|to)[a-z].*, just as Morten wrote. is_.* doesn't fall into
> this category. The underscore exemption is so that users can write their
> own is_file(), is_whatever() str_replace() and such. Some thought has
> gone into the standard.
>
Also, note that we don't include <ctype.h>, and the reasons to stay out
of its namespace are:
a. potential for confusion (different semantics), and
b. broken system headers.
-hpa
^ permalink raw reply
* Re: latest stg/git commandline completions code
From: Catalin Marinas @ 2005-10-25 16:24 UTC (permalink / raw)
To: Blaisorblade; +Cc: Ben Clifford, git
In-Reply-To: <200510251753.20164.blaisorblade@yahoo.it>
On 25/10/05, Blaisorblade <blaisorblade@yahoo.it> wrote:
> The best idea seems to write a Python script sourcing the Stgit source
> (stgit/main.py to get commands, and then loading each class and iterating
> over the "options" module member).
I can add a function in stgit/main.py which would list the options.
The tla-completion generates a file listing a command with its option
on every line:
push -a -all -n --number -t --to --reverse --undo -h --help
...
Since I don't know much about the bash completion, let me know of the
format you'd prefer.
> Btw, what do you think about speeding up completions by reimplementing things
> like "stg applied" or "stg unapplied" via cat (as noted in the comments at
> the beginning of the script)? Tab completions can easily livelock a shell on
> a busy system, so it's worthy speeding the thing up.
In general, it is better to use the stg commands but the repository
structure won't probably change for a long time and it's OK to
optimise (if the speed improvement is visible). Anyway, these
particular commands are pretty fast (they behave like cat) but there
are others which are slower (usually the commands involving calls to
the GIT tool).
--
Catalin
^ permalink raw reply
* Re: latest stg/git commandline completions code
From: Blaisorblade @ 2005-10-25 15:53 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Ben Clifford, git
In-Reply-To: <tnxwtk1lj58.fsf@arm.com>
On Tuesday 25 October 2005 17:18, Catalin Marinas wrote:
> Blaisorblade <blaisorblade@yahoo.it> wrote:
> > I'm using stgit on the Linux kernel so when on a command I don't have tab
> > completion I add the needed one (having the time and feeling to do
> > it).
> You can have a look at the tlacontrib project scripts (I can forward
> them to you since you would need tla/baz to clone/checkout the project
> and this procedure is a combination of 'tag' and 'get' commands). They
> automatically generate the commands together with the options and are
> later used in completion.
> Of course, your approach would work as well but it requires more
> maintance.
_Yes_, it wasn't ever intended to be published, and the help output doesn't
seem, at a quick look, trivially parsable (the source is better to parse but
I refuse that. Also, some options require still a special handling.
The best idea seems to write a Python script sourcing the Stgit source
(stgit/main.py to get commands, and then loading each class and iterating
over the "options" module member). I'm not fluent in Python enough currently,
but when I'll find time I'll probably study a bit reflection and write this
down (my Python experience amounts to some random readings on reviews and a
couple of days with Python docs).
> >> if so, do you have any more formalised distribution process (like a
> >> git repo!) rather than grabbing code out of email list postings? I
> >> can't seem to find much on google...
> > Well, Catalin's TODO included "bash completions", so I assume the
> > thing could be merged by him. Anyway, I'm attaching the current
> > version.
> When you think it is ready, I'm happy to include it (though I would
> prefer a more dynamic approach like the tla one but since I don't have
> time for it I'll just use yours).
Btw, what do you think about speeding up completions by reimplementing things
like "stg applied" or "stg unapplied" via cat (as noted in the comments at
the beginning of the script)? Tab completions can easily livelock a shell on
a busy system, so it's worthy speeding the thing up.
> Thanks.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: gitweb: charset problem
From: Daniel Barkalow @ 2005-10-25 16:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtk2k08z.fsf@assigned-by-dhcp.cox.net>
On Mon, 24 Oct 2005, Junio C Hamano wrote:
> > IIRC, we actually define that to be UTF-8, unlike most of the
> > other stuff, for which we don't actually insist on a policy.
>
> No, we do not define nor insist on a particluar policy as far as
> I know. We suggest the use of UTF-8 merely from common sense to
> help interoperability, and make UTF-8 slightly easier to use
> than other encodings by giving specific support for it in some
> tools, namely -u flag in git-mailinfo.
I thought we'd decided on uninterpreted byte values for blobs, filenames,
and trees (and everything in the working tree), but using UTF-8 for tag
and commit objects.
Consider if you started a project in EUC-JP, and then decided to switch to
UTF-8 later (when your environment handled it cleanly, perhaps). You could
convert all the file contents and move files to re-encoded names, but
you'd then want to commit these changes and have the log before and after
simultaneously intelligable.
> [Footnote]
>
> *1* For example, I've never made GNU emacs to work well with
> Japanese in UTF-8 , so if people in my company internal project
> wanted to use Japanese in commit logs, I would probably
> standardize on EUC-JP for such a project. Luckily so far I have
> not been forced to make that decision.
It wouldn't be hard to convert at some point between the editor and the
commit object, and you don't re-edit the commit objects like you do
tracked files. It probably wouldn't even be hard for commit-tree to
convert its input based on locale. (And stuff which prints commit contents
for user consumption probably ought to re-encode it if necessary, too)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] fetch/upload: Fix corner case with few revs
From: Johannes Schindelin @ 2005-10-25 15:34 UTC (permalink / raw)
To: git, junkio
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2382 bytes --]
When git-fetch-pack did not have enough revs to send, it did not realize
that the server actually speaks multi_ack. The server would now continue
sending ack´s, but the client would try to unpack objects. Oops.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
I have a sizable collection of brown paper bags by now.
fetch-pack.c | 13 +++++++++----
upload-pack.c | 15 +++++++++++----
2 files changed, 20 insertions(+), 8 deletions(-)
applies-to: f4786932e8753bdd07e44829a97a47749b329ee8
9a0ea94256236f1d038b16eb834fdfa5987f308c
diff --git a/fetch-pack.c b/fetch-pack.c
index 7015dc5..b02a24a 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -224,12 +224,17 @@ done:
if (retval != 0)
flushes++;
while (flushes) {
- if (get_ack(fd[0], result_sha1)) {
+ int ack = get_ack(fd[0], result_sha1);
+ if (ack) {
if (verbose)
- fprintf(stderr, "got ack %s\n",
+ fprintf(stderr, "got ack (%d) %s\n", ack,
sha1_to_hex(result_sha1));
- if (!multi_ack)
- return 0;
+ if (!multi_ack) {
+ if (ack == 2)
+ multi_ack = 1;
+ else
+ return 0;
+ }
retval = 0;
continue;
}
diff --git a/upload-pack.c b/upload-pack.c
index 25a343e..1dbde5f 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -116,7 +116,7 @@ static int get_common_commits(void)
{
static char line[1000];
unsigned char sha1[20];
- int len;
+ int len, last_sent_was_nak = 0;
track_object_refs = 0;
save_commit_buffer = 0;
@@ -126,23 +126,30 @@ static int get_common_commits(void)
reset_timeout();
if (!len) {
- if (multi_ack || nr_has == 0)
+ if (multi_ack || nr_has == 0) {
packet_write(1, "NAK\n");
+ last_sent_was_nak = 1;
+ }
continue;
}
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)) {
packet_write(1, "ACK %s%s\n",
sha1_to_hex(sha1),
multi_ack && nr_has < MAX_HAS ?
" continue" : "");
+ last_sent_was_nak = 0;
+ }
continue;
}
if (!strcmp(line, "done")) {
- if (nr_has > 0)
+ if (nr_has > 0) {
+ if (multi_ack && !last_sent_was_nak)
+ packet_write(1, "NAK\n");
return 0;
+ }
packet_write(1, "NAK\n");
return -1;
}
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH] Add usage string to git-update-index
From: Petr Baudis @ 2005-10-25 15:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch adds usage string to git-update-index, can be printed by the -h
or --help parameter.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
update-index.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/update-index.c b/update-index.c
index a84836b..661b86a 100644
--- a/update-index.c
+++ b/update-index.c
@@ -392,6 +392,9 @@ static void read_index_info(int line_ter
}
}
+static const char update_index_usage[] =
+"git-update-index [-q] [--add] [--replace] [--remove] [--unmerged] [--refresh] [--cacheinfo] [--chmod=(+|-)x] [--info-only] [--force-remove] [--stdin] [--index-info] [--ignore-missing] [-z] [--version] [--] <file>...";
+
int main(int argc, const char **argv)
{
int i, newfd, entries, has_errors = 0, line_termination = '\n';
@@ -489,6 +492,8 @@ int main(int argc, const char **argv)
verbose = 1;
continue;
}
+ if (!strcmp(path, "-h") || !strcmp(path, "--help"))
+ usage(update_index_usage);
die("unknown option %s", path);
}
update_one(path, prefix, prefix_length);
^ permalink raw reply related
* Re: latest stg/git commandline completions code
From: Catalin Marinas @ 2005-10-25 15:18 UTC (permalink / raw)
To: Blaisorblade; +Cc: Ben Clifford, git
In-Reply-To: <200510251642.46169.blaisorblade@yahoo.it>
Blaisorblade <blaisorblade@yahoo.it> wrote:
> I'm using stgit on the Linux kernel so when on a command I don't have tab
> completion I add the needed one (having the time and feeling to do
> it).
You can have a look at the tlacontrib project scripts (I can forward
them to you since you would need tla/baz to clone/checkout the project
and this procedure is a combination of 'tag' and 'get' commands). They
automatically generate the commands together with the options and are
later used in completion.
Of course, your approach would work as well but it requires more
maintance.
>> if so, do you have any more formalised distribution process (like a
>> git repo!) rather than grabbing code out of email list postings? I
>> can't seem to find much on google...
>
> Well, Catalin's TODO included "bash completions", so I assume the
> thing could be merged by him. Anyway, I'm attaching the current
> version.
When you think it is ready, I'm happy to include it (though I would
prefer a more dynamic approach like the tla one but since I don't have
time for it I'll just use yours).
Thanks.
--
Catalin
^ permalink raw reply
* Re: latest stg/git commandline completions code
From: Blaisorblade @ 2005-10-25 14:42 UTC (permalink / raw)
To: Ben Clifford; +Cc: git, Catalin Marinas
In-Reply-To: <Pine.LNX.4.60.0510251222510.8565@mundungus.clifford.ac>
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
On Tuesday 25 October 2005 14:24, Ben Clifford wrote:
> hi. I'm interested in playing with the stg/git commandline completion code
> - are you still actively working on it?
Well, yes, I've been still tuning it - but actually I'm not _maintaining_ it,
I'm using stgit on the Linux kernel so when on a command I don't have tab
completion I add the needed one (having the time and feeling to do it).
However, it's still done with enough care and polish to be shippable.
> if so, do you have any more
> formalised distribution process (like a git repo!) rather than grabbing
> code out of email list postings? I can't seem to find much on google...
Well, Catalin's TODO included "bash completions", so I assume the thing could
be merged by him. Anyway,
I'm attaching the current version.
Btw, it's under GPL v2.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
[-- Attachment #2: stg-compl --]
[-- Type: text/plain, Size: 5672 bytes --]
#Stacked git bash completion.
#TODO:
# My opinion about bash completion is that they're excessively slow, especially
# when the system is under load.
#
# So:
# - save the list of stg commands in a file, created at install moment; on an
# idle Athlon 64 laptop at 800MHz, stg help takes 0.22 seconds of CPU time,
# without disk I/O.
#
# - read .git/patches/$branch/{applied,unapplied} directly instead of invoking
# stg.
#
#XXX: must test for bash version, done in generic bash-completion and the
#generic value can be seen from here, if we are included by the loop at the end
#of /etc/bash_completion, i.e. if we're installed in /etc/bash-completion.d.
#
#Gentoo should be fixed to allow this.
bashdefault="-o bashdefault"
default="-o default"
#XXX: not StGit specific, valid for git too.
__git_refs()
{
for i in $(echo .git/refs/heads/*); do
echo ${i#.git/refs/heads/}
done
for i in $(echo .git/refs/tags/*); do
echo ${i#.git/refs/tags/}
done
echo HEAD
}
__stg_unapplied()
{
stg unapplied 2>/dev/null $@
}
__stg_applied()
{
stg applied 2>/dev/null $@
}
__stg_all_patches()
{
__stg_applied $@; __stg_unapplied $@
}
#XXX: Find a better name for this.
#
__stg_all_patch_ranges()
{
__stg_all_patches $@|while read i; do echo $i/; done
}
__stg_top()
{
stg top 2>/dev/null $@
}
__stg_branches()
{
#for i in $(compgen -f .git/patches/); do
for i in $(echo .git/patches/*); do
echo ${i#.git/patches/}
done
}
_stg_range()
{
#Ugly - should return the result rather than set COMPREPLY.
local cur=$1 patches=$2
if [ "${cur#*:}" != "${cur}" ]; then
# Complete the 2nd range component, after ':'.
COMPREPLY=( $(compgen -W "${patches}" -- ${cur#*:}) )
else
COMPREPLY=( $(compgen -W "${patches}" -- $cur) )
fi
}
_stg ()
{
local cur cmd cmds opts
cur=${COMP_WORDS[COMP_CWORD]}
COMPREPLY=()
if [ $COMP_CWORD -eq 1 ]; then
cmds=$(stg help|tail +4|awk '{print $1}')
COMPREPLY=( $(compgen -W "${cmds}" -- $cur) )
else
local cmd=${COMP_WORDS[1]}
local prev=${COMP_WORDS[COMP_CWORD-1]}
local o_help="-h --help"
local o_branch="-b --branch"
#XXX: Add -b support - pass "-b branch" to unapplied and applied.
#This can be done by calling __stg_unapplied directly below
#instead of setting patches here.
#But: how to look for -b? I'm scared about looping over opts
#(I don't like completions when they take so much time).
case $cmd in
push)
if [ "$prev" = "-t" -o "$prev" = "--to" ]; then
_stg_range "$cur" "$(__stg_unapplied)"
# if [ "${cur#*:}" != "${cur}" ]; then
# COMPREPLY=( $(compgen -W "$(__stg_unapplied)" -- ${cur#*:}) )
# else
# COMPREPLY=( $(compgen -W "$(__stg_unapplied)" -- $cur) )
# fi
else
opts="-a --all -n --number -t --to --reverse --undo $o_help"
COMPREPLY=( $(compgen -W "${opts} $(__stg_unapplied)" -- $cur) )
fi
;;
pop)
if [ "$prev" = "-t" -o "$prev" = "--to" ]; then
COMPREPLY=( $(compgen -W "$(__stg_applied)" -- $cur) )
else
opts="-a --all -n --number -t --to $o_help"
COMPREPLY=( $(compgen -W "${opts}" -- $cur) )
fi
;;
export)
if [ "$prev" = "-r" -o "$prev" = "--range" ]; then
_stg_range "$cur" "$(__stg_applied)"
else
opts="-n --numbered -d --diff -t --template -r --range \
$o_branch $o_help"
COMPREPLY=( $(compgen $default -W "${opts}" -- $cur) )
fi
;;
mail)
if [ "$prev" = "-r" -o "$prev" = "--range" ]; then
_stg_range "$cur" "$(__stg_applied)"
# if [ "${cur#*:}" != "${cur}" ]; then
# COMPREPLY=( $(compgen -W "$(__stg_applied)" -- ${cur#*:}) )
# else
# COMPREPLY=( $(compgen -W "$(__stg_applied)" -- $cur) )
# fi
else
opts="-a --all -r --range --to --cc --bcc -v --version \
-t --template -f --first -s --sleep --refid -u --smtp-user \
-p --smtp-password $o_branch $o_help"
COMPREPLY=( $(compgen $bashdefault -W "${opts} \
$(__stg_applied)" -- $cur) )
fi
;;
diff)
if [ "$prev" = "-r" ]; then
if [ "${cur#*:}" != "${cur}" ]; then
COMPREPLY=( $(compgen -W "$(__stg_all_patch_ranges)" -- \
${cur#*:}) )
else
COMPREPLY=( $(compgen -W "$(__stg_all_patch_ranges)" -- \
$cur) )
fi
else
opts="-r -s --stat $o_help"
COMPREPLY=( $(compgen -W "${opts}" -- $cur) )
fi
;;
id)
if [ "$prev" = "-b" -o "$prev" = "--branch" ]; then
COMPREPLY=( $(compgen -W "$(__stg_branches)" -- $cur) )
else
opts="$o_branch $o_help"
#there's a lot of possible id's to complete
COMPREPLY=( $(compgen -W "${opts} $(__stg_all_patch_ranges) \
$(__git_refs)" -- $cur) )
fi
;;
rename)
if [ "$prev" = "-b" -o "$prev" = "--branch" ]; then
COMPREPLY=( $(compgen -W "$(__stg_branches)" -- $cur) )
else
COMPREPLY=( $(compgen -W "$(__stg_all_patches)" -- $cur) )
fi
;;
delete)
opts="${o_help}"
COMPREPLY=( $(compgen -W "${opts} $(__stg_unapplied; __stg_top)" \
-- $cur) )
;;
series|unapplied|applied)
if [ "$prev" = "-b" -o "$prev" = "--branch" ]; then
COMPREPLY=( $(compgen -W "$(__stg_branches)" -- $cur) )
else
opts="$o_branch $o_help"
[ "$cmd" = "series" ] && \
opts="$opts -e --empty"
COMPREPLY=( $(compgen -W "${opts}" -- $cur) )
fi
;;
refresh)
opts="-f --force -e --edit -s --showpatch -m --message \
-a --author --authname --authemail --authdate --commname
--commemail $o_help"
COMPREPLY=( $(compgen $bashdefault -W "${opts}" -- $cur) )
;;
*)
COMPREPLY=( $(compgen $bashdefault -W "${o_help}" -f -- $cur) )
;;
esac
fi
}
complete $default -F _stg stg
# vi: set ft=sh sw=4:
^ permalink raw reply
* Re: The MIT error
From: Andreas Ericsson @ 2005-10-25 13:52 UTC (permalink / raw)
To: GIT Mailing List
In-Reply-To: <200510251340.j9PDeGGt006248@laptop11.inf.utfsm.cl>
Horst von Brand wrote:
> Morten Welinder <mwelinder@gmail.com> wrote:
>
>>After the isspace/BSD conflict I looked into what reserved symbols are
>>being used by git. Quite a few, it turns out.
>
>
> [...]
>
>
>>Just as isspace is reserved by the C implementation...
>>
>> 7.26.2 Character handling <ctype.h>
>>
>> [#1] Function names that begin with either is or to, and a
>> lowercase letter (possibly followed by any combination of
>> digits, letters, and underscore) may be added to the
>> declarations in the <ctype.h> header.
>
>
> There go is_space(), etc as suggested by the relevant patches...
No they don't. "begin with either is or to and a lowercase letter",
meaning (is|to)[a-z].*, just as Morten wrote. is_.* doesn't fall into
this category. The underscore exemption is so that users can write their
own is_file(), is_whatever() str_replace() and such. Some thought has
gone into the standard.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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