* Re: [PATCH 1/2] Add git-archive
From: Jakub Narebski @ 2006-09-06 20:29 UTC (permalink / raw)
To: git
In-Reply-To: <44FF2C37.2010400@lsrfire.ath.cx>
Rene Scharfe wrote:
> IMHO should work like in the following example, and the code above
> cuts off the Documentation part:
>
> $ cd Documentation
> $ git-archive --format=tar --prefix=v1.0/ HEAD howto | tar tf -
> v1.0/howto/
> v1.0/howto/isolate-bugs-with-bisect.txt
> ...
>
> I agree that simple subtree matching would be enough, at least for
> now.
What about
$ git-archive --format=tar --prefix=v1.0/ HEAD:Documentation/howto
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/2] Add git-archive
From: Rene Scharfe @ 2006-09-06 20:17 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Junio C Hamano, git
In-Reply-To: <cda58cb80609050516v699338b9y57fd54f50c66e49e@mail.gmail.com>
Franck Bui-Huu schrieb:
> diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
> index 61a4135..e0da01e 100644
> --- a/builtin-tar-tree.c
> +++ b/builtin-tar-tree.c
> @@ -9,6 +9,7 @@ #include "strbuf.h"
> #include "tar.h"
> #include "builtin.h"
> #include "pkt-line.h"
> +#include "archive.h"
>
> #define RECORDSIZE (512)
> #define BLOCKSIZE (RECORDSIZE * 20)
> @@ -338,6 +339,71 @@ static int generate_tar(int argc, const
> return 0;
> }
>
> +static int write_tar_entry(const unsigned char *sha1,
> + const char *base, int baselen,
> + const char *filename, unsigned mode, int stage)
> +{
> + static struct strbuf path;
> + int filenamelen = strlen(filename);
> + void *buffer;
> + char type[20];
> + unsigned long size;
> +
> + if (!path.alloc) {
> + path.buf = xmalloc(PATH_MAX);
> + path.alloc = PATH_MAX;
> + path.len = path.eof = 0;
> + }
> + if (path.alloc < baselen + filenamelen) {
> + free(path.buf);
> + path.buf = xmalloc(baselen + filenamelen);
> + path.alloc = baselen + filenamelen;
> + }
> + memcpy(path.buf, base, baselen);
> + memcpy(path.buf + baselen, filename, filenamelen);
> + path.len = baselen + filenamelen;
> + if (S_ISDIR(mode)) {
> + strbuf_append_string(&path, "/");
> + buffer = NULL;
> + size = 0;
> + } else {
> + buffer = read_sha1_file(sha1, type, &size);
> + if (!buffer)
> + die("cannot read %s", sha1_to_hex(sha1));
> + }
> +
> + write_entry(sha1, &path, mode, buffer, size);
Here occurs the memory leak that I've been talking about. buffer needs
to be free'd.
> +
> + return READ_TREE_RECURSIVE;
> +}
^ permalink raw reply
* Re: [PATCH 1/2] Add git-archive
From: Rene Scharfe @ 2006-09-06 20:14 UTC (permalink / raw)
To: Franck; +Cc: Junio C Hamano, git
In-Reply-To: <44FED12E.7010409@innova-card.com>
Franck Bui-Huu schrieb:
> Junio C Hamano wrote:
>> "Franck Bui-Huu" <vagabon.xyz@gmail.com> writes:
>>
>>> git-archive is a command to make TAR and ZIP archives of a git tree.
>>> It helps prevent a proliferation of git-{format}-tree commands.
>> Thanks. I like the overall structure, at least mostly.
>> Also dropping -tree suffix from the command name is nice, short
>> and sweet.
>>
>
> great !
>
>> Obviously I cannot apply this patch because it is totally
>> whitespace damaged, but here are some comments.
>
> (sigh), sorry for that.
>
>>> diff --git a/archive.h b/archive.h
>>> new file mode 100644
>>> index 0000000..6c69953
>>> --- /dev/null
>>> +++ b/archive.h
>>> @@ -0,0 +1,43 @@
>>> +#ifndef ARCHIVE_H
>>> +#define ARCHIVE_H
>>> +
>>> +typedef int (*write_archive_fn_t)(struct tree *tree,
>>> + const unsigned char *commit_sha1,
>>> + const char *prefix,
>>> + time_t time,
>>> + const char **pathspec);
>> The type of the first argument might have to be different,
>> depending on performance analysis by Rene on struct tree vs
>> struct tree_desc.
>>
>
> OK. We'll wait for Rene.
The performance difference I noticed was caused by a memleak; the speed
advantage of a struct tree_desc based traverser is significant if you
look only at the traversers' performance, but it is lost in the noise
of the "real" work that the payload function is doing (see my other
mail).
>>> +static int run_remote_archiver(struct archiver_struct *ar, int argc,
>>> + const char **argv)
>>> +{
>>> + char *url, buf[1024];
>>> + pid_t pid;
>>> + int fd[2];
>>> + int len, rv;
>>> +
>>> + sprintf(buf, "git-upload-%s", ar->name);
>> Are you calling git-upload-{tar,zip,rar,...} here?
>>
>
> yes. Actually git-upload-{tar,zip,...} commands are going to be
> removed, but git-daemon know them as a daemon service. It will
> map these services to the generic "git-upload-archive" command.
> One benefit is that we could still disable TAR format and enable
> TGZ one. Please take a look to the second patch that adds
> git-upload-archive command.
I don't think git-daemon should need to care about specific
archivers. Policy decisions, like disallowing certain archive types
or compression levels, should be made in git-upload-archive. This
way all code regarding archive uploading is found in one place:
git-upload-archive. We can keep git-upload-tar as a legacy
interface, but please use only git-upload-archive for the new stuff
(and not git-upload-zip etc.).
>>> +int parse_treeish_arg(const char **argv, struct tree **tree,
>>> + const unsigned char **commit_sha1,
>>> + time_t *archive_time, const char *prefix,
>>> + const char **reason)
>>> +{
>>> ...
>>> + if (prefix) {
>>> + unsigned char tree_sha1[20];
>>> + unsigned int mode;
>>> + int err;
>>> +
>>> + err = get_tree_entry((*tree)->object.sha1, prefix,
>>> + tree_sha1, &mode);
>>> + if (err || !S_ISDIR(mode)) {
>>> + *reason = "current working directory is untracked";
>>> + goto out;
>>> + }
>>> + free(*tree);
>>> + *tree = parse_tree_indirect(tree_sha1);
>>> + }
>> I like the simplicity of just optionally sending one subtree (or
>> the whole thing), but I think this part would be made more
>> efficient if we go with "struct tree_desc" based interface.
>>
>> Also I wonder how this interacts with the pathspec you take from
>> the command line. Personally I think this single subtree
>> support is good enough and limiting with pathspec is not needed.
[Note: There's potential for confusion here because we have two
types of prefixes. One is the present working directory inside the
git archive, the other is the one specified with --prefix=. Here
we have the working directory kind of prefix.]
IMHO should work like in the following example, and the code above
cuts off the Documentation part:
$ cd Documentation
$ git-archive --format=tar --prefix=v1.0/ HEAD howto | tar tf -
v1.0/howto/
v1.0/howto/isolate-bugs-with-bisect.txt
...
I agree that simple subtree matching would be enough, at least for
now.
René
^ permalink raw reply
* Re: file rename causes history to disappear
From: Jakub Narebski @ 2006-09-06 19:25 UTC (permalink / raw)
To: git
In-Reply-To: <edn5dd$c4s$2@sea.gmane.org>
Jakub Narebski wrote:
> Linus Torvalds wrote:
>
>>> git-rev-list could then output hash with current set of <filenames>, which
>>> were given <filename> at the beginning, i.e.
>>> <hash> -- <filename> [<filename>...]
> I'm not that sure. The output could be changed to, for example
> <hash> SP <quoted-filename> [SP <quoted-filename> ...]
The "<hash> -- <filename> [<filename>...]" was to allow the followed
<filename> to be pathspec for other command, for example
git-diff-tree --stdin
(if git-diff-tree accepts pathspec limiting on stdin, and not only
revisions, or pairs of revisions; according to 1.4.2 documentation
--stdin is for reading either one <commit> or a pair of <tree-ish>
separated with a single space from its input -- no pathspecs).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: file rename causes history to disappear
From: Junio C Hamano @ 2006-09-06 19:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609060922110.27779@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Side note: one thing that I wanted to do, but never got around to, is to
> allow wildcards in the tree-parsing code. It might be too expensive, but
> it's still occasionally something I'd like to do:
>
> git log -- 'mm/*.c'
>
> to track every single C file in the VM (even if they don't exist right
> _now_).
I am happy to see we are in agreement. I touched this in the
ending note to
http://article.gmane.org/gmane.comp.version-control.git/26432
The only people who will get burnt by this change are the ones
with metacharacters in their pathnames, so it is relative safe
change.
I think 'git grep' pathspec code is probably the best to reuse
to convert diff-tree family. It knows how to match globs while
traversing a tree down without descending into a subtree that
would never match, which is what we need for them.
^ permalink raw reply
* Re: [PATCH] Include local config before platform tweaks
From: Brian Gernhardt @ 2006-09-06 19:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce
In-Reply-To: <7vwt8h8nuf.fsf@assigned-by-dhcp.cox.net>
On Sep 6, 2006, at 3:18 AM, Junio C Hamano wrote:
> Thanks Shawn. Brian does Shawn's patch work for you?
Short answer: Yes
Long answer:
The patch from his e-mail failed (git apply: fatal: corrupt patch at
line 27), but manually making the changes worked. I didn't pull
before applying that, so that's probably the problem there.
~~Brian
^ permalink raw reply
* Re: file rename causes history to disappear
From: Linus Torvalds @ 2006-09-06 19:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edn5dd$c4s$2@sea.gmane.org>
On Wed, 6 Sep 2006, Jakub Narebski wrote:
>
> But --follow=<filename> with <pathspec> can be useful, e.g. when <pathspec>
> is a directory (or, perhaps in the future, glob), which would mean "follow
> the contents indicated in starting hash by <filename>, and stop following
> when it falls out outside given <pathspec>, in our case given directory".
Yes, that would indeed make sense. The pathspec ends up being kept as a
"limiter", and basically tells you what the "context" for following is
allowed to be.
Color me convinced.
Linus
^ permalink raw reply
* Re: [PATCH 0/7] gitweb: Trying to improve history view speed
From: Linus Torvalds @ 2006-09-06 19:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edn54s$c4s$1@sea.gmane.org>
On Wed, 6 Sep 2006, Jakub Narebski wrote:
>
> Well, I just didn't realize that --parents gives parents in _simplified_
> history, unless --full-history is used. Hence my confusion.
Right. That's really the main reason for "--parents" existing in the first
place. I added it exactly so that "gitk" would work with pathname
limiting.
If you don't want the simplified history parents, you might as well just
parse the parents information directly from the commit data yourself
(although with grafting, there's arguably _some_ reason to have
git-rev-list do it for you regardless of simplification).
Linus
^ permalink raw reply
* Re: file rename causes history to disappear
From: Jakub Narebski @ 2006-09-06 18:52 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0609061131100.27779@g5.osdl.org>
Linus Torvalds wrote:
>> git-rev-list could then output hash with current set of <filenames>, which
>> were given <filename> at the beginning, i.e.
>> <hash> -- <filename> [<filename>...]
>
> I would argue that "--follow" would be incompatible with having other
> <paths> listed. But maybe there is some sensible rule for what the
> combination means (show the listed paths _and_ the file we're following?)
> I dunno.
I'm not that sure. The output could be changed to, for example
<hash> SP <quoted-filename> [SP <quoted-filename> ...]
although I'm not sure if git can detect that two files were joined into one
(or, in reverse that one file was split into several; this doesn't matter
for following history of a file from top)
But --follow=<filename> with <pathspec> can be useful, e.g. when <pathspec>
is a directory (or, perhaps in the future, glob), which would mean "follow
the contents indicated in starting hash by <filename>, and stop following
when it falls out outside given <pathspec>, in our case given directory".
As pathspecs doesn't change, there is no need to output them.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/7] gitweb: Trying to improve history view speed
From: Jakub Narebski @ 2006-09-06 18:48 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0609061125000.27779@g5.osdl.org>
Linus Torvalds wrote:
>> Every single merge is for parents to be connected, or what?
>
> Well, "--parents" on its own means that we want a connected graph. It's
> just that if you don't ask for full history, then the connected graph
> result is obviously much smaller.
Well, I just didn't realize that --parents gives parents in _simplified_
history, unless --full-history is used. Hence my confusion.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: file rename causes history to disappear
From: Linus Torvalds @ 2006-09-06 18:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edmvfv$lt7$2@sea.gmane.org>
On Wed, 6 Sep 2006, Jakub Narebski wrote:
>
> So if/when git would have --follow option to git-log and git-diff-*, it
> would be rather --follow=<filename>, rather than --follow -- <paths>?
That would probably be sensible, yes. Especially since "--follow" is
fundamentally different from the "<paths>" thing in that you really should
be able to only follow a single file.
(Following multiple files causes huge amounts of pain - it might be
possible, but I don't think it's worth it).
> git-rev-list could then output hash with current set of <filenames>, which
> were given <filename> at the beginning, i.e.
> <hash> -- <filename> [<filename>...]
I would argue that "--follow" would be incompatible with having other
<paths> listed. But maybe there is some sensible rule for what the
combination means (show the listed paths _and_ the file we're following?)
I dunno.
Linus
^ permalink raw reply
* Re: [PATCH 0/7] gitweb: Trying to improve history view speed
From: Linus Torvalds @ 2006-09-06 18:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edmv57$lt7$1@sea.gmane.org>
On Wed, 6 Sep 2006, Jakub Narebski wrote:
> Linus Torvalds wrote:
>
> > So the rule is:
> >
> > - using "--full-history" + "--parents" means that you want (surprise
> > surprise) full history with parenthood, which means that you get all
> > the connecting merges too. And since you asked for the _full_ history,
> > that means EVERY SINGLE MERGE.
>
> I just don't quite understand where <pathspec> filtering takes place
> in this case.
Well, since you asked for full history, by definition it doesn't take
place for merges, since you'll be wanting to follow both sides of the
merge (to see the full history) regardless of whether the parents of that
merge seem interesting or not.
> Every single merge is for parents to be connected, or what?
Well, "--parents" on its own means that we want a connected graph. It's
just that if you don't ask for full history, then the connected graph
result is obviously much smaller.
Think "graphical visualizer", and you'll see what's going on. Do a
gitk git.c
gitk --full-history git.c
and see the difference, and you'll understand (gitk already asks for
"--parents" on its own).
Basically, "--full-history" means that we traverse every parent of a
merge, whether it looks interesting or not.
> When I though about it, git_history needs not parents of a commit; from
> parsed commit it needs only date, author and title/summary (and of course
> commit sha1), so we can skip '--parents' option to git-rev-list, and have
> nice _history of a file_, using only one call to git-rev-list to make it.
Yes. Once you get rid of "--parents", git-rev-list should indeed do
exactly what you want (because it no longer tries to keep things
connected, and thus happily drops uninteresting merges).
Of course, there could well be a bug _there_, since "--full-history" isn't
used very much (but "git whatchanged" uses it, so it should have gotten
_some_ testing).
Linus
^ permalink raw reply
* Re: git.kernel.org not putting out or git-daemon bug?
From: Marco Costalba @ 2006-09-06 18:17 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <44FEC9D6.3030105@op5.se>
On 9/6/06, Andreas Ericsson <ae@op5.se> wrote:
> Andreas Ericsson wrote:
> > Is it just me, or is anyone else having problems 'git fetch'-ing from
> > git.kernel.org? I've been trying on and off for two hours now, but keep
> > getting
> >
> > fatal: unexpected EOF
> > Fetch failure: git://git.kernel.org/pub/scm/git/git.git
> >
> > Around 10 o'clock GMT I got a couple of timeouts, but I haven't seen one
> > of those for several hours now.
> >
> > Using git version 1.4.2.ga444 to do the fetching, and trying to pull
> > things on to a clone of that revision of the git repo.
> >
>
> Fetch over rsync seems to work fine, but git version 1.4.2.g8f5d has no
> better luck fetching over the git-protocol.
>
gitweb it's also veeeery slow to update. I've pushed a patch to qgit
repository more then one hour ago and still http://kernel.org/git/ is
not updated.
It's not the first time gitweb takes time to update, but never more
then one hour!
Also the http://kernel.org/git/ page refresh is very slow and is
getting slower each week more. Unfortunately I have no quantitative
data on it, but my impression is that there is a drift in response
times in the last months.
^ permalink raw reply
* Re: [PATCH][RFC] Add git-archive-tree
From: Rene Scharfe @ 2006-09-06 18:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Franck Bui-Huu
In-Reply-To: <7vwt8mx8lb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Currently git-archive-tree -f tar is slower than git-tar-tree. This is
>> because it is welded to the side of the existing code to minimize patch
>> size, and I also suspect read_tree_recursive() to be quite a bit slower
>> than builtin-tar-tree.c::traverse_tree().
>
> Yes, I suspect "struct object" and friends are very inefficient
> to use for things like this. "struct tree_desc" based traverser
> is much preferred.
Turns out the reason for git-archive-tree -f tar being 10% slower than
git-tar-tree was a stupid memory leak in write_tar_entry(). *blush*
It caused lots of brk() calls (i.e. system calls).
In order to simplify measurement, I commented out the body of
write_entry(), which both git-archive-tree and git-tar-tree are calling
to write their output. The rest left is basically two pure tree
traversers, git-archive-tree using read_tree_recursive() and git-tar-tree
using its struct tree_desc based traverse_tree().
I then let the two chew away on the kernel repository. And as
kcachegrind impressively shows, all we do with our trees and objects is
dwarfed by inflate(). In both cases more than 96.6% of the cost lies
within libz. That's not too surprising, because archivers need to
decompress _all_ objects, not only trees.
So for git-archive we can pretty much chose which traverser to use based
on convenience.
As a second experiment I wrote a struct tree_desc based traverser plus a
matching read_tree_recursive() compatibility wrapper (included below for
reference, not for inclusion) and compared the performance of
'git-ls-tree -r -t' on the kernel repository with and without it. The
result is that the relative cost of all functions from tree.c combined
decreased from 0.93% to 0.66%. Ugh.
So while a struct tree_desc based traverser can be significantly faster
than read_tree_recursive(), as soon as you actually start to do something
to the trees that difference pales to insignificance.
René
diff --git a/tree.c b/tree.c
index ea386e5..977a4aa 100644
--- a/tree.c
+++ b/tree.c
@@ -4,6 +4,7 @@ #include "blob.h"
#include "commit.h"
#include "tag.h"
#include "tree-walk.h"
+#include "strbuf.h"
#include <stdlib.h>
const char *tree_type = "tree";
@@ -227,3 +228,99 @@ struct tree *parse_tree_indirect(const u
parse_object(obj->sha1);
} while (1);
}
+
+static int do_read_tree_recursive_light(struct tree_desc *desc,
+ struct strbuf *base,
+ const char **match, read_tree_fn_t fn)
+{
+ struct name_entry entry;
+ int err = 0;
+ int baselen = base->len;
+
+ while (tree_entry(desc, &entry)) {
+ if (!match_tree_entry(base->buf, base->len, entry.path, entry.mode, match))
+ continue;
+
+ err = fn(entry.sha1, base->buf, base->len, entry.path, entry.mode, 0);
+ switch (err) {
+ case 0:
+ continue;
+ case READ_TREE_RECURSIVE:
+ break;
+ default:
+ return -1;
+ }
+
+ if (S_ISDIR(entry.mode)) {
+ struct tree_desc subtree;
+ char type[20];
+ void *buf;
+ int newbaselen;
+
+ buf = read_sha1_file(entry.sha1, type, &subtree.size);
+ if (!buf)
+ return error("cannot read %s",
+ sha1_to_hex(entry.sha1));
+ if (strcmp(type, tree_type)) {
+ free(buf);
+ return error("Object %s not a tree",
+ sha1_to_hex(entry.sha1));
+ }
+ subtree.buf = buf;
+
+ newbaselen = baselen + entry.pathlen + 1;
+ if (newbaselen > base->alloc) {
+ base->buf = xrealloc(base->buf, newbaselen);
+ base->alloc = newbaselen;
+ }
+ memcpy(base->buf + baselen, entry.path, entry.pathlen);
+ base->buf[baselen + entry.pathlen] = '/';
+ base->len = newbaselen;
+
+ err = do_read_tree_recursive_light(&subtree,
+ base,
+ match, fn);
+ base->len = baselen;
+ free(buf);
+ if (err)
+ break;
+ }
+ }
+
+ return err;
+}
+
+int read_tree_recursive_light(struct tree *tree,
+ const char *base, int baselen, int stage,
+ const char **match, read_tree_fn_t fn)
+{
+ unsigned char *sha1 = tree->object.sha1;
+ struct tree_desc desc;
+ char type[20];
+ void *buf;
+ int err;
+ struct strbuf sb;
+
+ sb.buf = xmalloc(PATH_MAX);
+ sb.alloc = PATH_MAX;
+ sb.len = 0;
+ if (baselen > sb.alloc) {
+ sb.buf = xrealloc(sb.buf, baselen);
+ sb.alloc = baselen;
+ }
+ memcpy(sb.buf, base, baselen);
+ sb.len = baselen;
+
+ desc.buf = buf = read_sha1_file(sha1, type, &desc.size);
+ if (!buf)
+ return error("Could not read %s", sha1_to_hex(sha1));
+ if (strcmp(type, tree_type)) {
+ free(buf);
+ return error("Object %s not a tree", sha1_to_hex(sha1));
+ }
+
+ err = do_read_tree_recursive_light(&desc, &sb, match, fn);
+ free(buf);
+
+ return err;
+}
diff --git a/tree.h b/tree.h
index dd25c53..2294bc2 100644
--- a/tree.h
+++ b/tree.h
@@ -30,4 +30,8 @@ extern int read_tree_recursive(struct tr
extern int read_tree(struct tree *tree, int stage, const char **paths);
+extern int read_tree_recursive_light(struct tree *tree,
+ const char *base, int baselen, int stage,
+ const char **match, read_tree_fn_t fn);
+
#endif /* TREE_H */
^ permalink raw reply related
* Re: Some issues with current qgit on exit
From: Marco Costalba @ 2006-09-06 17:28 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1157493650.2803.8.camel@dv>
On 9/6/06, Pavel Roskin <proski@gnu.org> wrote:
> Hi, Marco!
>
Hello Pavel,
nice to hear you again!
> The current qgit reports assertion failure on exit:
> ASSERT in tabWdg_currentChanged
>
> That's how you can trigger it:
>
> select one of the patches
> double click on the entry to open the "patch" tab
> double click on one of the modified files on the right
> switch back to the "rev list" or "patch" tab
> close qgit by Ctrl-Q
>
> I've tried to debug the problem. MainImpl::currentTabType() returns -1.
> It's possible that the logic in that function is flawed, or maybe it
> doesn't work properly on exit.
>
> Another problem is segmentation fault when closing qgit with more that
> one file tab and the "rev list" tab selected:
>
> select one of the patches
> select "view file" in the pop-up menu on one of the files
> activate the "rev list" tab
> select "view file in new tab" on the same file
> activate the "rev list" tab
> close qgit by Ctrl-Q
>
Thanks for the very good bug reports. I have just pushed the fix: it
was a bogus delayed delete on exit the origin of this issues.
I was planning (well, still I am) to release new version this week
end, and your bug report is arrived just in time ;-)
Thanks
Marco
^ permalink raw reply
* Re: GitWiki lost ability to parse macros
From: Jakub Narebski @ 2006-09-06 17:18 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0609061712410.7168@reaper.quantumfyre.co.uk>
Julian Phillips wrote:
> On Wed, 6 Sep 2006, Jakub Narebski wrote:
>
>> Hmm... I still get for http://git.or.cz/gitwiki/RecentChanges
>>
>> {{RandomQuote()}}
>>
>> {{RecentChanges}}
>>
>>
>
> MoinMoin caches a copy of the generated html page, which is automatically
> updated when you edit the page. Since fixing the macros doesn't mean
> updating the page you have to manually delete the cache - this can be done
> from the "More Actions:" list.
Could admin of GitWiki then delete cache of all files?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: file rename causes history to disappear
From: Jakub Narebski @ 2006-09-06 17:11 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0609060858050.27779@g5.osdl.org>
Linus Torvalds wrote:
> There's a huge difference between "pathname" and "inode". And git operates
> on _pathnames_, not on inodes. So when you give a pathname specifier,
> that's _exactly_ what it is. It's a pathname specifier, _not_ an "inode"
> specifier.
>
> And pathnames don't change. They're just names for paths to possibly
> _find_ a file/inode. They can't be "renamed". The data that is found
> behind a pathname may be moved to _another_ pathname (and we call that a
> rename), but that doesn't change the original pathname in any way, shape,
> or form.
So if/when git would have --follow option to git-log and git-diff-*, it
would be rather --follow=<filename>, rather than --follow -- <paths>?
git-rev-list could then output hash with current set of <filenames>, which
were given <filename> at the beginning, i.e.
<hash> -- <filename> [<filename>...]
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/7] gitweb: Trying to improve history view speed
From: Jakub Narebski @ 2006-09-06 17:06 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0609060847521.27779@g5.osdl.org>
Linus Torvalds wrote:
> So the rule is:
>
> - using "--full-history" + "--parents" means that you want (surprise
> surprise) full history with parenthood, which means that you get all
> the connecting merges too. And since you asked for the _full_ history,
> that means EVERY SINGLE MERGE.
I just don't quite understand where <pathspec> filtering takes place
in this case.
Every single merge is for parents to be connected, or what?
> So what you are asking for is pretty nonsensical. You ask for parenthood
> info, but then you seem to not want to actually connect the dots. So why
> do you ask for parents in the first place? If you don't want to connect
> the commits to their parents, you shouldn't ask for it.
When I though about it, git_history needs not parents of a commit; from
parsed commit it needs only date, author and title/summary (and of course
commit sha1), so we can skip '--parents' option to git-rev-list, and have
nice _history of a file_, using only one call to git-rev-list to make it.
This means that parse_rev_list has to be changes, and that '--parents'
option must be specified explicitely as argument to parse_rev_list.
Besides [primitive] benchmarking shows that there we gain only a little:
1.53s user+sys vs 2.13s user+sys when run from command line,
2.8s mean vs 3.6s mean when tested using ApacheBench...
that is _after_ paginating history output.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: file rename causes history to disappear
From: Linus Torvalds @ 2006-09-06 16:37 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0609060858050.27779@g5.osdl.org>
On Wed, 6 Sep 2006, Linus Torvalds wrote:
>
> git log -- drivers/scsi drivers/ata include/linux/ata.h
>
> So taking a filename-based approach is actually more _powerful_. You
> can emulate the "follow a single file" behaviour on top of it, but you
> can't sanely go the other way.
Side note: one thing that I wanted to do, but never got around to, is to
allow wildcards in the tree-parsing code. It might be too expensive, but
it's still occasionally something I'd like to do:
git log -- 'mm/*.c'
to track every single C file in the VM (even if they don't exist right
_now_).
Notice the difference between
git log mm/*.c
and the above idea - the latter does actually work, but it only tracks the
C files that exist right now under mm/. But it should be possible (and is
potentially useful) to let the wildcard act over the history, rather than
just a single point in time.
Because one additional advantage of thinking in terms of pathnames is
exactly the fact that wildcards make sense in a way that they do _not_
make sense if you think of tracking "inodes". Exactly because "pathnames
are forever", and a pathname has validity and exists regardless of whether
a repository contains a _file_ with that name at any particular point in
time.
So right now git does do the wildcard thing, but only for "git ls-files"
(and through that, things like "git add", which used to be implemented in
terms of ls-files). So you can do
git add '*.c'
to add all C files (recursively - it's not the shell matcher).
Linus
^ permalink raw reply
* Re: file rename causes history to disappear
From: Linus Torvalds @ 2006-09-06 16:14 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <44FEED4B.30909@garzik.org>
On Wed, 6 Sep 2006, Jeff Garzik wrote:
>
> Since I'm just interested in the log (ATM), even the lack of "-M" seems to
> produce useful results. Thanks.
Sure, if you don't actually want the diff, the "-M" isn't worthwhile.
> IMO it is highly counter-intuitive that renames are -not- followed. I don't
> see the point of a "--follow-rename", it should Just Work(tm).
No, it should not.
You haven't thought it through, and I excuse you, because even people who
should know better (and design SCM's) often haven't thought it through.
There's a huge difference between "pathname" and "inode". And git operates
on _pathnames_, not on inodes. So when you give a pathname specifier,
that's _exactly_ what it is. It's a pathname specifier, _not_ an "inode"
specifier.
And pathnames don't change. They're just names for paths to possibly
_find_ a file/inode. They can't be "renamed". The data that is found
behind a pathname may be moved to _another_ pathname (and we call that a
rename), but that doesn't change the original pathname in any way, shape,
or form.
Now, you can say "git shouldn't work with pathnames, it should work with
inodes, and use the pathnames to look them up", but you'd be wrong. You'd
be wrong for many reasons, so let me explain:
- pathnames are actually often a hell of a lot more interesting that
"inodes". Doing thing by pathname means that you have sane and
well-defined semantics for something like
git log -- drivers/scsi drivers/ata include/linux/ata.h
even if (for example) some of those files or directories don't
necessarily even exist at one particular point in time. Exactly
_because_ a pathname is not actually affected by the contents of the
repository.
So taking a filename-based approach is actually more _powerful_. You
can emulate the "follow a single file" behaviour on top of it, but you
can't sanely go the other way.
- following inodes/files instead of following pathnames happens to also
be fundamentally ambiguous when you split or merge the file contents.
What happens? You simply _cannot_ describe that in the form of "files".
It's impossible. Really. Yet it's actually fairly common.
In contrast, if you think of pathnames of _pathnames_ (rather than the
contents they point to), that particular sticky wicket simply doesn't
exist. It's a non-issue. File contents that get split? Big deal. We
don't care. We care about a particular set of pathnames, and if the
file content came from (or got split into) that set of pathnames, we
show it.
So thinking in terms of pathnames is not only fundamentally more powerful,
it also very fundamentally avoids a confusing situation that you cannot
avoid with a "inode" based model.
You just need to get used to the fact that the arguments you give to "git
log" and friends really have _nothing_ to do with any particular "file" or
"content at any particular time". They are immutable path specifiers. When
you say
git log -- drivers/scsi/libata.c
you're asking git "tell me what happened to this _pathname_". Not file.
Not content (although if you ask for diffs it will show you the diff,
but not for that "file", but simple AS IT PERTAINS TO THAT PATHNAME!)
It may take a bit of getting used to, but once you realize that git talks
about immutable pathnames, and once you do get used to it, it's a hell of
a powerful thing.
And then we can have "--follow-renames" when we are lazy and we
_understand_ that git talks about pathnames, but we want git to show us
the data _as_if_ it cared about how the inodes moved around.
Linus
^ permalink raw reply
* Re: GitWiki lost ability to parse macros
From: Julian Phillips @ 2006-09-06 16:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edmcd6$9or$1@sea.gmane.org>
On Wed, 6 Sep 2006, Jakub Narebski wrote:
> Hmm... I still get for http://git.or.cz/gitwiki/RecentChanges
>
> {{RandomQuote()}}
>
> {{RecentChanges}}
>
>
MoinMoin caches a copy of the generated html page, which is automatically
updated when you edit the page. Since fixing the macros doesn't mean
updating the page you have to manually delete the cache - this can be done
from the "More Actions:" list.
--
Julian
---
If you are smart enough to know that you're not smart enough to be an
Engineer, then you're in Business.
^ permalink raw reply
* Re: [PATCH 0/7] gitweb: Trying to improve history view speed
From: Linus Torvalds @ 2006-09-06 15:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200609061504.40725.jnareb@gmail.com>
On Wed, 6 Sep 2006, Jakub Narebski wrote:
>
> Unfortunately, git-rev-list is broken: 'git rev-list <commit>
> --full-history --parents -- <filename>' shows all merges in addition
> to what 'git rev-list <commit> --parents -- <filename>' and
> 'git rev-list <commit> --full-history -- <filename>' shows, see
> "git-rev-list --full-history --parents doesn't respect path limit
> and shows all merges" thread
If you ask for "--full-history" and "--parents", then pretty much by
_definition_ you need every single merge, because otherwise your history
wouldn't be fully connected.
Without that, things like "gitk" and "qgit" wouldn't work.
> So probably those patches should be dropped or put in freezer until
> git-rev-list is corrected.
git-rev-list _is_ correct, and if you want something else, you need to
either use a different set of flags (like _only_ using "--full-history")
or ask for a totally new flag (like "--most-history").
So the rule is:
- using "--full-history" + "--parents" means that you want (surprise
surprise) full history with parenthood, which means that you get all
the connecting merges too. And since you asked for the _full_ history,
that means EVERY SINGLE MERGE.
- using _just_ "--parents" means that you want a connected history with
parenthood information, but since you didn't ask for the _full_
history, it will optimize away the merges that didn't change the file,
and only follow the changed side. You still get merges, but now you get
only those merges where both (all) sides actually mattered.
- using _just_ "--full-history" (without asking for parenthood) means
that you're not asking for a connected history (since you're not asking
for parents), and as such, it will only show individual _commits_ that
change the file. That does potentially include merges, but again, it
only includes merges that actually _changed_ something.
In other words, "--parents" means a lot more than just "show what the
parents" were. In particular, it means (and always has meant, apart from
bugs) that we show the _rewritten_ parents after we've done history
munging, and that we always output enough commits to actually make sense
of that history from the result.
So what you are asking for is pretty nonsensical. You ask for parenthood
info, but then you seem to not want to actually connect the dots. So why
do you ask for parents in the first place? If you don't want to connect
the commits to their parents, you shouldn't ask for it.
Linus
^ permalink raw reply
* Re: file rename causes history to disappear
From: Jeff Garzik @ 2006-09-06 15:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0609060834520.27779@g5.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 6 Sep 2006, Jeff Garzik wrote:
>> I moved a bunch of SATA drivers in the Linux kernel from drivers/scsi to
>> drivers/ata.
>>
>> When I tried to look at the past history of a file using git-whatchanged,
>> post-rename, it only shows the history from HEAD to the point of rename.
>> Everything prior to the rename is lost.
>>
>> I also tried git-whatchanged on the old path, but that produces an error.
>
> For filenames that don't exist right now, you need to clearly separate the
> revision name from the filename (ie you need to use "--").
>
> There were patches to do "--follow-rename" which I don't think got applied
> yet, but in the meantime, just do
>
> git whatchanged -M -- drivers/ata/filename.c drivers/scsi/filename.c
>
> where the "-M" means "show diffs as renames if possible" (which is
> different from having the history actually _follow_ them), and the "--" is
> the filename separator to tell git that the nonexistent
> "drivers/ata/filename.c" file isn't a (currently) nonexistent revision
> name, it's a (currently) nonexistent _filename_.
Since I'm just interested in the log (ATM), even the lack of "-M" seems
to produce useful results. Thanks.
IMO it is highly counter-intuitive that renames are -not- followed. I
don't see the point of a "--follow-rename", it should Just Work(tm).
Jeff
^ permalink raw reply
* Re: file rename causes history to disappear
From: Linus Torvalds @ 2006-09-06 15:38 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <44FEE0BB.2060601@garzik.org>
On Wed, 6 Sep 2006, Jeff Garzik wrote:
>
> I moved a bunch of SATA drivers in the Linux kernel from drivers/scsi to
> drivers/ata.
>
> When I tried to look at the past history of a file using git-whatchanged,
> post-rename, it only shows the history from HEAD to the point of rename.
> Everything prior to the rename is lost.
>
> I also tried git-whatchanged on the old path, but that produces an error.
For filenames that don't exist right now, you need to clearly separate the
revision name from the filename (ie you need to use "--").
There were patches to do "--follow-rename" which I don't think got applied
yet, but in the meantime, just do
git whatchanged -M -- drivers/ata/filename.c drivers/scsi/filename.c
where the "-M" means "show diffs as renames if possible" (which is
different from having the history actually _follow_ them), and the "--" is
the filename separator to tell git that the nonexistent
"drivers/ata/filename.c" file isn't a (currently) nonexistent revision
name, it's a (currently) nonexistent _filename_.
Linus
^ permalink raw reply
* Re: [PATCH] git-svnimport: Parse log message for Signed-off-by: lines
From: Matthias Urlichs @ 2006-09-06 15:33 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Junio C Hamano, git
In-Reply-To: <20060906125317.GA21645@sashak.voltaire.com>
Hi,
Sasha Khapyorsky:
> At least I didn't succeed with reversed layout. With option
> -T <trunk>/$project import works but only for trunk branch, attempts
> to specify branch as -b <branches> or -b <branches>/$project don't help,
> the same is with tags.
>
That's true. The problem is that it wants the tag or branch name as the
last component of the path.
A more generic solution would be to use wildcards in the branch/tag
specification, to allow more than one wildcard, and to be able to
specify the exact form of the branch or tag name on the git side.
All of this should be specified in the repository's git config file,
not on the command line.
Somebody who wants to implement that is certainly invited to do so.
(I don't have time for that at the moment, unfortunately.)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ 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