* Re: [PATCH] Documentation/git-commit: rewrite to make it more end-user friendly.
From: Nicolas Pitre @ 2006-12-10 0:51 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Junio C Hamano, git, J. Bruce Fields
In-Reply-To: <200612100130.48812.Josef.Weidendorfer@gmx.de>
On Sun, 10 Dec 2006, Josef Weidendorfer wrote:
> Very nice.
>
> On Saturday 09 December 2006 06:48, Junio C Hamano wrote:
> > DESCRIPTION
> > -----------
> > -Updates the index file for given paths, or all modified files if
> > -'-a' is specified, and makes a commit object. The command specified
> > -by either the VISUAL or EDITOR environment variables are used to edit
> > -the commit log message.
> > +Use 'git commit' when you want to record your changes into the repository
> > +along with a log message describing what the commit is about. All changes
> > +to be committed must be explicitly identified using one of the following
>
> What about: "... must be explicitly identified (that is,
> must be "staged") ..."
>
> This way, it will be clear for the reader that "to explicitly identify" is the
> same thing as "to stage", which is used quite often later.
Hmmm, maybe, maybe not. Although I don't have particular problem with
"staging area", I'm still unconvinced about the verb "stage".
> > +methods:
> >
> > -Several environment variable are used during commits. They are
> > -documented in gitlink:git-commit-tree[1].
> > +1. by using gitlink:git-add[1] to incrementally "add" changes to the
> > + next commit before using the 'commit' command (Note: even modified
> > + files must be "added");
>
> Regarding this note: Of course unmodified files do not have to be added ;-)
>
> What about: "(Note: changes in files already known to git, and even new
> changes done after a previous `git add` for a given file, still must
> be staged again)"
This is getting too long for what it is worth in this case IMHO.
^ permalink raw reply
* Re: git-commit: select which files to commit while editing the commit message
From: Junio C Hamano @ 2006-12-10 0:54 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200612100146.09175.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Saturday 09 December 2006 01:59, Junio C Hamano wrote:
>> Maybe the "git add --interactive" would give you a transcript
>> like this:
> ...
> Something like this really would be good.
I think I already had the code in jit --- I need to dig it out.
But the above is trivial for anybody who knows how to use
git-diff-index and "git-apply --cached", so...
^ permalink raw reply
* [PATCH] remove "[PATCH]" prefix from shortlog output
From: Nicolas Pitre @ 2006-12-10 0:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This doesn't convey much information in the shortlog context.
And the perl version did strip it as well.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 7a2ddfe..6c4606b 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -146,6 +146,11 @@ static void insert_author_oneline(struct path_list *list,
while (onelinelen > 0 && isspace(oneline[onelinelen - 1]))
onelinelen--;
+ if (onelinelen > 8 && !strncasecmp(oneline, "[PATCH] ", 8)) {
+ oneline += 8;
+ onelinelen -= 8;
+ }
+
buffer = xmalloc(onelinelen + 1);
memcpy(buffer, oneline, onelinelen);
^ permalink raw reply related
* Re: [PATCH] Make cvsexportcommit work with filenames with spaces and non-ascii characters.
From: Junio C Hamano @ 2006-12-10 1:18 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <20061209232919.31863.58547.stgit@lathund.dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> This patch uses git-apply to do the patching which simplifies the code a lot.
>
> Removed the test for checking for matching binary files when deleting them
> since git-apply happily deletes the file. This is matter of taste since we
> allow some fuzz for text patches also.
>
> Error handling was cleaned up, but not much tested.
Interesting.
I think you should be able to generate the patchfile once, and
use git-apply to figure out additions, deletions and binaryness,
and then use the same patchfile to apply the changes. Currently
checking for binaryness is not easy with git-apply, so we would
want to fix git-apply first, instead of forcing you to have a
change like this:
# the --binary format is harder to grok for names of binary
# files so we execute a new diff
# if it looks like binary files exists to find out
if (grep /^GIT binary patch$/, @diff) {
@binfiles = grep m/^Binary files/,
safe_pipe_capture('git-diff-tree', '-p', $parent, $commit);
which is way too ugly.
... goes to look and comes back, with a big grin ...
Well, have you tried this?
git diff-tree -p --binary fe142b3a | git apply --summary --numstat
The numstat part would let you see the binaryness, so we do not
have to "fix" git-apply.
Another thing that _might_ be interesting is to use rename
detection when preparing the patch, and make the matching rename
on the CVS side, but I do not recall the details of how one
would make CVS pretend to support renamed paths ;-). I think it
involved copying the ,v file to a new name, and marking the
older revisions in that new ,v file as nonexistent or something
like that, but I did it only in my distant past and forgot the
details.
By the way, I am not sure if giving fuzz by default is such a
good idea, though.
^ permalink raw reply
* Re: [PATCH 1/3] diff_tree_sha1(): avoid rereading trees if possible
From: Junio C Hamano @ 2006-12-10 1:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.63.0612100055160.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> If the tree has already been read, no need to read it into memory
> again.
Hmm...
> This also helps when this function is called on temporary trees;
> these no longer have to be written to disk.
To generate tree-diff, probably yes, but I am not sure that
allows you to use hash_sha1_file() everywhere in merge_recursive
instead of write_sha1_file(), if that is what you are getting
at.
> +static int get_tree_desc_from_sha1(const unsigned char *sha1,
> + struct tree_desc *t)
> +{
> + struct object *o;
> +
> + o = lookup_object(sha1);
> + if (o && o->type == OBJ_TREE && o->parsed) {
> + struct tree *tree = (struct tree *)o;
> + t->size = tree->size;
> + t->buf = xmalloc(t->size);
> + memcpy(t->buf, tree->buffer, t->size);
> + } else {
> + t->buf = read_object_with_reference(sha1,
> + tree_type, &t->size, NULL);
> + if (!t->buf)
> + die("unable to read source tree (%s)",
> + sha1_to_hex(sha1));
> + }
> +}
Are you absolutely sure that all users of "struct tree" retains
the tree->buffer for a parsed tree? If nobody does
"free(tree->buffer)" without "tree->buffer = NULL", then the
situation is still salvageable (you need a bit more code above),
though.
I think this is overkill that only helps a very narrow "empty
tree" special case that [PATCH 2/3] addresses, and can be easily
and incorrectly abused. We do not want people to expect that
reading many trees from different revisions as "struct tree"
objects and keeping all of them in memory would magically speed
up diff-tree, for example.
I'd prefer write_sha1_file() approach in Shawn's patch for its
simplicity at least for now.
I suspect gitlink/subproject people might want to modify in-core
representation of a tree to graft in subproject directory
somewhere in the superproject, just like the history traversal
code modifies in-core representation of a commit to simplify
parents. Your approach might turn out to be the right thing to
for that application --- populate tree objects in the in-core
obj_hash[], muck with its entries and then have everybody else
go through get_tree_desc_from_sha1() interface to pretend as if
the superproject has everything contained in the subproject
tree. I dunno.
^ permalink raw reply
* Re: [PATCH 3/3] add test case for recursive merge
From: Junio C Hamano @ 2006-12-10 3:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.63.0612100114440.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> this test succeeds consistently on the machine where I tested it
> originally, but fails on another of my machines, but only when run without
> "-v". Very annoying. I will not have time to investigate until Monday,
> though.
There seem to be cases where stage #1 contains blob 'B' or 'A'
or nothing depending on something totally random. Ring a bell?
^ permalink raw reply
* Re: [PATCH] shortlog: fix segfault on empty authorname
From: Jeff King @ 2006-12-10 3:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <Pine.LNX.4.63.0612100019270.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, Dec 10, 2006 at 12:21:03AM +0100, Johannes Schindelin wrote:
> > Instead, remove at most one space between name and address.
>
> Why? We can fix it properly: Instead of
>
> > - while (isspace(bob[-1]))
> > + if (isspace(bob[-1]))
>
> do something like
>
> while (bob - 1 != buffer + 7 &&
> isspace(bob[-1]))
It doesn't look like there are ever extra spaces to get soaked up in the
kernel or git repositories, but if there is a reason to expect
Full Name <user@domain>
then we should probably replace my fix with yours.
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Dongsheng Song @ 2006-12-10 3:49 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Daniel Drake, git
In-Reply-To: <20061208203230.GA9193@sashak.voltaire.com>
I met the broken too, when I downgrade to 1.4.3.4, it's fine.
I have not test your patch, but you can try your self,
http://tortoisesvn.tigris.org/svn/tortoisesvn
and the master branch(today) fail between r6000~r7000 too
2006/12/9, Sasha Khapyorsky <sashak@voltaire.com>:
> Hi,
>
> On 10:26 Thu 07 Dec , Daniel Drake wrote:
> >
> > git-svnimport broken between git-1.4.3.5 and git-1.4.4
> >
>
> Is this 'server' public? Can I rerun this git-svnimport?
>
> If not, please try the patch:
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Martin Langhoff @ 2006-12-10 3:55 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jakub Narebski, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <457AAF31.2050002@garzik.org>
On 12/10/06, Jeff Garzik <jeff@garzik.org> wrote:
> > P.S. Can anyone post some benchmark comparing gitweb deployed under
> > mod_perl as compared to deployed as CGI script? Does kernel.org use
> > mod_perl, or CGI version of gitweb?
>
> CGI version of gitweb.
>
> But again, mod_perl vs. CGI isn't the issue.
IO is the issue, and the CGI startup of Perl is quite IO & CPU
intensive. Even if the caching headers, thundering herds and planet
collisions are resolved, I don't think you'll ever be happy with IO
and CPU load on kernel.org running gitweb as CGI.
cheers,
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Martin Langhoff @ 2006-12-10 4:07 UTC (permalink / raw)
To: Jakub Narebski
Cc: Jeff Garzik, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <200612091437.01183.jnareb@gmail.com>
On 12/10/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Jeff Garzik wrote:
> > Jakub Narebski wrote:
>
> >> In addition to setting either Expires: header or Cache-Control: max-age
> >> gitweb should also set Last-Modified: and ETag headers, and also
> >> probably respond to If-Modified-Since: and If-None-Match: requests.
> >>
> >> Would be worth implementing this?
> >
> > IMO yes, since most major browsers, caches, and spiders support these
> > headers.
>
> Sending Last-Modified: should be easy; sending ETag needs some consensus
> on the contents: mainly about validation. Responding to If-Modified-Since:
> and If-None-Match: should cut at least _some_ of the page generating time.
> If ETag can be calculated on URL alone, then we can cut If-None-Match:
> just at beginning of script.
Indeed. Let me add myself to the pileup agreeing that a combination of
setting Last-Modified and checking for If-Modified-Since for
ref-centric pages (log, shortlog, RSS, and summary) is the smartest
scheme. I got locked into thinking ETags.
> > That would be a good start, and suffice for many cases. If the CGI can
> > simply stat(2) files rather than executing git-* programs, that would
> > increase efficiency quite a bit.
>
> As I said, I'm not talking (at least now) about saving generated HTML
> output. This I think is better solved in caching engine like Squid can
> be. Although even here some git specific can be of help: we can invalidate
> cache on push, and we know that some results doesn't ever change (well,
> with exception of changing output of gitweb).
Indeed - gitweb should not be saving HTML around bit giving the best
possible hints to squid and friends. And improving our ability to
short-cut and send a 304 - Not Modified.
> What can be _easily_ done:
Great plan. :-)
cheers,
^ permalink raw reply
* Re: [PATCH] shortlog: fix segfault on empty authorname
From: Junio C Hamano @ 2006-12-10 6:01 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Nicolas Pitre, git
In-Reply-To: <20061210034524.GA11819@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It doesn't look like there are ever extra spaces to get soaked up in the
> kernel or git repositories, but if there is a reason to expect
> Full Name <user@domain>
> then we should probably replace my fix with yours.
As far as I know, commit-tree removes the extra space if exists,
so your fix would be fine in practice.
People could write crappy replacements of plumbing, and we may
end up with names with trailing whitespaces, but with your fix
at least that would not make us crash, and it may even be
considered a feature -- it would serve as a coalmine canary to
detect such a broken alternative program that creates bogus
commit objects.
We might want to tighten fsck-objects to warn about them,
though. But that is probably rather low priority.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-10 7:05 UTC (permalink / raw)
To: Martin Langhoff
Cc: Jeff Garzik, Jakub Narebski, Git Mailing List, Linus Torvalds,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <46a038f90612091955i5bdd6e85l749a2f511f27953@mail.gmail.com>
Martin Langhoff wrote:
> On 12/10/06, Jeff Garzik <jeff@garzik.org> wrote:
>> > P.S. Can anyone post some benchmark comparing gitweb deployed under
>> > mod_perl as compared to deployed as CGI script? Does kernel.org use
>> > mod_perl, or CGI version of gitweb?
>>
>> CGI version of gitweb.
>>
>> But again, mod_perl vs. CGI isn't the issue.
>
> IO is the issue, and the CGI startup of Perl is quite IO & CPU
> intensive. Even if the caching headers, thundering herds and planet
> collisions are resolved, I don't think you'll ever be happy with IO
> and CPU load on kernel.org running gitweb as CGI.
>
I/O - nonexistent; that stuff will be in memory.
CPU - we have more CPU than you can shake a stick at, and it's 95+% idle.
*NOT AN ISSUE*.
^ permalink raw reply
* Re: Collection of stgit issues and wishes
From: Jakub Narebski @ 2006-12-10 8:55 UTC (permalink / raw)
To: git
In-Reply-To: <elconr$uku$2@sea.gmane.org>
Jakub Narebski wrote:
> Here are some issues which are a bit annoying for me:
> - make "stg help" (without command name) equivalent to "stg --help"
> - stg new lacks --sign option (I have to remember to do this during
> "stg refresh").
And another one: git uses VISUAL, then EDITOR, while stgit uses EDITOR
only, so when I prepare VISUAL for git (I use emacsclient), stgit still
uses EDITOR.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation/git-commit: rewrite to make it more end-user friendly.
From: Alan Chandler @ 2006-12-10 9:17 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nicolas Pitre, J. Bruce Fields
In-Reply-To: <7vd56tei20.fsf_-_@assigned-by-dhcp.cox.net>
On Saturday 09 December 2006 05:48, Junio C Hamano wrote:
> OPTIONS
> -------
> -a|--all::
> - Update all paths in the index file. This flag notices
> - files that have been modified and deleted, but new files
> - you have not told git about are not affected.
> + Tell the command to automatically stage files that have
> + been modified and deleted, but new files you have not
> + told git about are not affected.
The "but" in this sentence doesn't seem right to me, I would either
use "although", or slightly better (IMHO) make it two sentences
Tell the command to automatically stage files that have been modified
and deleted. Note that files that you have not told git about are not
included with this option.
--
Alan Chandler
^ permalink raw reply
* Re: Documentation/git-commit.txt
From: Alan Chandler @ 2006-12-10 9:23 UTC (permalink / raw)
To: git; +Cc: Horst H. von Brand
In-Reply-To: <200612100011.kBA0BuTo028252@laptop13.inf.utfsm.cl>
On Sunday 10 December 2006 00:11, Horst H. von Brand wrote:
> Alan Chandler <alan@chandlerfamily.org.uk> wrote:
>
> [...]
>
> > How about the following wording here
> >
> > Instead of staging the content of each file immediately after
> > changing it, you can wait until you have completed all the changes
> > you want to make and then use the `-a` option to tell `git commit`
> > to look for all changes to the content it is tracking and commit it
> > automatically. That
>
> ^^^^^^^
> files
> (or "files whose contents")
>
> > is, this example ...
>
> [Yes, git tracks the contents of files, but it also has a list of
> files whose contents it is tracking]
regardless, I think "it" should become "them"
... it is tracking and commit them automatically.
--
Alan Chandler
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: rda @ 2006-12-10 9:43 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Rogan Dawes, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <457995F8.1080405@zytor.com>
On 12/8/06, H. Peter Anvin <hpa@zytor.com> wrote:
> Linus Torvalds wrote:
> > I could write a simple C caching thing that just hashes the CGI arguments
> > and uses a hash to create a cache (and proper lock-files etc to serialize
> > access to a particular cache object while it's being created) fairly
> > easily, but I'm pretty sure people would much prefer a mod_perl thing just
> > to avoid the fork/exec overhead with Apache (I think mod_perl allows
> > Apache to run perl scripts without it), and that means I'm not the right
> > person any more.
>
> True about mod_perl. Haven't messed with that myself, either.
> fork/exec really is very cheap on Linux, so it's not a huge deal.
In the case of Perl scripts, it's not really the fork/exec overhead,
but the Perl startup overhead that you want to try to optimize. But
given your later statement (lots of spare cpu), this ends up just
being a bit of a latency hit. In general, I think mod_perl has a
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jakub Narebski @ 2006-12-10 10:09 UTC (permalink / raw)
To: Martin Langhoff
Cc: Jeff Garzik, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <46a038f90612092007w4637637aya1a01ec18ff16f6f@mail.gmail.com>
Martin Langhoff wrote:
> On 12/10/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Sending Last-Modified: should be easy; sending ETag needs some consensus
>> on the contents: mainly about validation. Responding to If-Modified-Since:
>> and If-None-Match: should cut at least _some_ of the page generating time.
>> If ETag can be calculated on URL alone, then we can cut If-None-Match:
>> just at beginning of script.
>
> Indeed. Let me add myself to the pileup agreeing that a combination of
> setting Last-Modified and checking for If-Modified-Since for
> ref-centric pages (log, shortlog, RSS, and summary) is the smartest
> scheme. I got locked into thinking ETags.
Sometimes it is easier to use ETags, sometimes it is easier to use
Last-Modified:. Usually you can check ETag earlier (after calling
git-rev-list) than Last-Modified (after parsing first commit). But
some pages doesn't have natural ETag...
Besides, because ETag is HTTP/1.1 we should provide and validate
both.
P.S. Any hints to how to do this with CGI Perl module?
--
Jakub Narebski
^ permalink raw reply
* Re: Collection of stgit issues and wishes
From: Jakub Narebski @ 2006-12-10 11:06 UTC (permalink / raw)
To: git
In-Reply-To: <elght6$tjb$1@sea.gmane.org>
Jakub Narebski wrote:
>> Here are some issues which are a bit annoying for me:
>> - make "stg help" (without command name) equivalent to "stg --help"
>> - stg new lacks --sign option (I have to remember to do this during
>> "stg refresh").
And as far as I can see it doe not use git credentials (user.name and
user.email).
> And another one: git uses VISUAL, then EDITOR, while stgit uses EDITOR
> only, so when I prepare VISUAL for git (I use emacsclient), stgit still
> uses EDITOR.
And yet another one: better support for reflog, namely giving the "reason"
i.e. the reflog message (like "stg push: <subject>", "stg refresh:
<subject>", "stg pop: <subject>", "stg commit" etc.), like git-rebase,
git-commit --amend and git-am (for example) does.
P.S. The Vendor: field in stgit RPM has incorrectly
Catalin Marinas <catalin.marinas@gmail.org>
instead of
Catalin Marinas <catalin.marinas@gmail.com>
(.org instead of .com).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [RFC \ WISH] Add -o option to git-rev-list
From: Marco Costalba @ 2006-12-10 11:38 UTC (permalink / raw)
To: Git Mailing List
Cc: Junio C Hamano, Alex Riesen, Shawn Pearce, Linus Torvalds
I have done some tests about reading git-rev-list output with
different IPC facilities:
- Native Qt QProcess socket based IPC
- pipe based: popen() and fread()
- redirecting git-rev-list to a file (under tmpfs) and 'block reading'
back the file: read() under Qt QFile class. The file, always in
memory, is deleted at the end of loading.
I have tested with different block sizes and different CPU speed on
linux and git trees.
The averaged results on linux tree (about 30MB of data) and CPU set at
1.2GHz are:
- QProcess 6734ms
- pipe and fread() with 64KB blocks 4832ms (38% faster then QProcess)
- temporary file and read() with 64KB blocks 4321ms (10% faster then pipe)
I have not enough knowledge to understand why temporary file is faster
then pipe. My guess is, after reading some docs around, fread() uses a
C standard I/O buffer, while read() is unbuffered.
To make git-rev-list writing a temporary file I create and run a
script more or less like:
git rev-list --header --boundary --parents --topo-order HEAD >
/tmp/qgit_135902672.txt
There is also some additional kludge to get git-rev-list pid, so to
use in case of a cancel request arrives while loading.
So my request is if it is possible to make git-rev-list write
_directly_ to a file, without shell redirection, I would ask if it is
possible:
- Add a -o, --output option to git-rev-list to specify output file
instead of stdout
- Use an unbuffered binary block write to be as fastest as possible
- Do *not* flush ever the file, it's only a waste under this scenario.
This will let me to avoid the shell launching crap and probably gain
also some more speed.
I understand this could be not exactly a top priority feature for git
people, but I would really like to get the best possible interface
with the plumbing git and the -o options is also a very common one.
Thanks
Marco
P.S: On another thread I explained why I see problematic linking
directly against libgit.a
I rewrite here for completeness:
> I've looked again to Shawn idea (and code) of linking qgit
> against libgit.a but I found these two difficult points:
>
> - traverse_commit_list(&revs, show_commit, show_object) is blocking,
> i.e. the GUI will stop responding for few seconds while traversing the
> list. This is easily and transparently solved by the OS scheduler if
> an external process is used for git-rev-list. To solve this in qgit I
> have two ways: 1) call QEventLoop() once in a while from inside
> show_commit()/ show_object() to process pending events 2) Use a
> separate thread (QThread class). The first idea is not nice, the
> second opens a whole a new set of problems and it's a big amount of
> not trivial new code to add.
>
> - traverse_commit_list() having an internal state it's not
> re-entrant. git-rev-list it's used to load main view data but also
> file history in another tab, and the two calls _could_ be ran
> concurrently. With external process I simply run two instances of
> DataLoader class and consequently two external git-rev-list processes,
> but If I link against libgit.a that would be a big problem.
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Sasha Khapyorsky @ 2006-12-10 11:47 UTC (permalink / raw)
To: Dongsheng Song; +Cc: Daniel Drake, git
In-Reply-To: <4b3406f0612091949qc75cb10x13f09e2017d71d91@mail.gmail.com>
On 11:49 Sun 10 Dec , Dongsheng Song wrote:
> I met the broken too, when I downgrade to 1.4.3.4, it's fine.
>
> I have not test your patch, but you can try your self,
>
> http://tortoisesvn.tigris.org/svn/tortoisesvn
>
> and the master branch(today) fail between r6000~r7000 too
Thanks for the link. but I cannot access - this requires
username/password authentication.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Torgil Svensson @ 2006-12-10 11:47 UTC (permalink / raw)
To: R. Steve McKown; +Cc: Linus Torvalds, git
In-Reply-To: <200612091434.15001.rsmckown@yahoo.com>
What if we use linus "module" file concept and allow the link objects
to track subtrees? An object may look like this:
commit: <SHA1>
link: <SHA1> /path/to/remote/tree/or/blob
Tracking upstream library:
--------------------------
clone as usual
Inhouse libraries/applications:
-------------------------------
To satisfy versioning of build-dependencies - make links of type
"external/lib1_header.h" -> "<commit>/headers/lib1_header.h" (blob)
"external/lib1_interface" -> "<commit>/api" (tree)
If git supports "sparse fetching" of subtrees we can follow the
history in the submodule only concerning the files we want without
fetching the whole subtree. "modules" file could specify something
like "always clone on fetch"
Build environment
------------------
First make links to all tools, applications, etc ...
"buildtools/random_app1" -> "<commit>/"
"buildtools/random_app2" -> "<commit>/"
"sub_build_projects/user_interface" -> "<commit>/"
"sub_build_projects/kernel" -> "<commit>/"
"apps/special_app1" -> "<commit>/"
"libs/special_lib1" ->
"<commit-from-another-build-project>/special/lib/binary/path"
Here we can have a build system that for example creates a "i386"
folder and the repo itself
Documentation release
----------------------
"Lib1/" -> "<lib1 commit>/docs"
"Lib2/" -> "<lib2 commit>/docs"
"App1/" -> "<app1 commit>/docs"
Special customer release for a specific HW platform
---------------------------------------------------
"Lib1/lib1.h" -> "<lib1-commit>/headers/lib1.h"
"Lib1/lib1.so" -> "<build-environment-commit>/i386/Lib1/lib1.so"
"Lib1/docs" -> "<lib1-commit>/docs"
"App1_binary" -> "<build-environment-commit>/i386/App1/App1_binary"
"docs" -> "<app1-commit>/docs"
commit&tag&bag this and send to customer. If the customer says
something is broken, we can make an SHA1 of the customers tree and
immediately see if there's changes not belonging to us.
Now this can be broken in so many ways that I can't even count, so I
appreciate some feedback to correct my head.
On 12/9/06, R. Steve McKown <rsmckown@yahoo.com> wrote:
> On Saturday 02 December 2006 12:41 pm, Linus Torvalds wrote:
> > In other words, I _suspect_ that that is really what module users are all
> > about. They want the ability to specify an arbitrary collection of these
> > atomic snapshots (for releases etc), and just want a way to copy and move
> > those things around, and are less interested in making everything else
> > very seamless (because most people are happy to do the actual
> > _development_ entirely within the submodules, so the "development" part
> > is actually not that important for the supermodule, the supermodule is
> > mostly for aggregation and snapshots, and tying different versions of
> > different submodules together).
> >
> > So that's where I come from. And maybe I'm totally wrong. I'd like to hear
> > what people who actually _use_ submodules think.
>
> Here's some thoughts on subprojects from my company's perspective. I
> apologize for the long message.
>
> Abstract: We use submodules heavily in CVS and SVN. I like what I've read
> from Linus about the "thin veneer" approach of integrating subprojects. It
> seems conceptually to provide the support we desire. For us, it's important
> that the mandated linkage between a master project and a subproject is
> minimal to maximize our flexibility in building our processes.
>
>
> We develop and maintain a lot of embedded applications. Both for higher level
> systems (ex: 32MB RAM/32MB storage) running the Linux kernel and a customized
> set of libs/app support code and more deeply embedded environments (ex: 8KB
> of RAM and 32KB of storage). Even though these two cases are very different
> in many repects, the version management issues are the same.
>
> - We (mostly) track everything needed to build historical versions of code
> with 100% fidelity. This includes all of the tools used to compile, build,
> test, deploy, debug, etc. the actual build results themselves. I initially
> looked at Vesta several years ago. I love their conceptual approach to this
> problem (integrated build system that caches mid-level build results within
> the repository itself), but it's too unwieldy, very hard to set up (lots of
> up-front effort), and lacks many useful features.
>
> - Most of our "applications" are a relatively small amount of app-specific
> code with references to several/many shared modules. Shared modules can
> contain support tools, like build/test/debug/deploy support for a given
> embedded platform, in-house developed shared app code, or shared code
> developed by third parties.
>
> - We use CVS to manage our larger system development projects. The repo is
> about 2GB and has several dozen application-code submodules. We use the
> "third party sources" approach to tracking submodules as outlined in Ch.13 of
> the CVS manual. Additionally, we manage our "buildox" (similar to buildroot
> in concept) in another CVS repo. All prior interesting versions of the
> buildroot can be built from source (toolchains, everything), if necessary.
> Applications contain metadata (a file...) in the repo so the app-level build
> system can ensure it is being ran under the correct version of buildbox;
> clunky but serviceable. CVS is a nightmare because of its poor
> branch/tagging facilities, and many of the things we *ought* to be doing with
> revision control we don't because of the complexity.
>
> - We use SVN to manage our deeply embedded system projects. The repo is about
> 250MB in size. Applications use the svn:externals property to reference
> needed modules. We aren't using a buildbox in this environment yet (bad!).
> SVN's simple branching and svn:externals are a giant leap forward in
> comparison to CVS's capabilities.
>
>
> Below are some common use case scenarios that are to varying degrees unweildy
> in CVS and/or SVN. Many of these involving non-trivial branching and merging
> operations are nearly impractical in CVS, and the lack of merge tracking (to
> support repeated safe merging from one branch to another) makes some of these
> a bit tricky in SVN too. Of course neither repo supports
> disconnected/distributed operation, which would make a number of activities
> that much simpler as well.
>
> - Round trip module management. A specific app requires a change to a shared
> module, so it makes a local branch to develop the change. The "diff" is
> presented to the maintainer (who may be inhouse). The next interesting
> maintainer version of the module gets imported into our repo (if in house,
> it's already there), where the app can reference it. This merge process may
> leave changes not yet implemented (or never to be implemented) by the module
> maintainer in the local branch used by the apps. Other apps are unaffected,
> as they are linking to a prior version in the local branch.
>
> - Pragmatic development. It's typical that in developing an application, a
> developer will need to simultaneously make changes to one or more submodules.
> If more than trivial, he/she should branch the submodules and continually
> tracking the HEAD of those branches in the relevant app. This is so complex
> and fraught with problems in CVS that it doesn't get done, and developers
> house too much change over time in their working directories. With SVN and
> svn:externals, the process is workable. It is nice that an svn:external can
> point to (the HEAD of) a branch when making changes.
>
> - An application implements a new feature internally (say support for a new
> digital chipset in the embedded world) which later needs to be "promoted" to
> a subproject for use by others. Pretty easy in SVN. A challenge in CVS;
> it's really not possible to "convert" app code into a "third party source"
> and retain an historical link.
>
> - Updating build tools. In concept no different than updating a shared code
> module. In practice, due to the buildbox strategy, it's a bit convoluted. I
> don't expect this to get much smoother. Getting Vesta-like features, where
> integrated build suport can cache lower-level build results in a version-safe
> manner (like the binary code built when the cross toolchain was built) would
> be killer, but that's surely OT for the submodules discussion.
>
> Thanks,
> Steve
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/3] gitweb: Better symbolic link support in "tree" view
From: Jakub Narebski @ 2006-12-10 12:25 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vk616ezu5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote in
"Re: [PATCH] gitweb: Better symbolic link support in "tree" view":
> If you wanted to do this, a better way would be to have a new
> view that takes a commit/tree object and a path from the top of
> the repository, and shows either "no such path in that tree" or
> "here is the view for that object, by the way it was a blob."
> page. Then your list drawing would still need to open each
> symlink blob to show " -> link_target", and need to check if it
> goes outside the repository (I would assume you are handling
> relative links as well), but you do not need to do expensive
> ls-tree step one per symlink on the page. The href attr of the
> A element " -> link_target" would point at that "universal
> object view" with the link_target pathname (that is, the blob
> contents) and the commit/tree object name (h or hb I do not know
> which) and you will spend cycles to run ls-tree only when the
> user actually asks to follow that link.
>
> In other words, I think trying to be lazy is extremely important
> while drawing a big list.
I not necessarily agree; I think that symbolic links are sufficnetly
rare that a bit more time spent to make the view better for end user
(link only if target exists) is worth it. But...
Here follows the implementation of this idea: first to read link
target and show it in "tree" view _without_ hyperlink, then
introduction of generic "object" view which does the verification and
redirect to correct view accorting to the type of object, and last
show link target hyperlinked in "tree" view using "object" view/action
link.
While at it implement the same "lazy" solution in commitsha1 commitag
in format_log_line_html subroutine.
Table of contents:
[PATCH 1/3] gitweb: Show target of symbolic link in "tree" view
[PATCH 2/3] gitweb: Add generic git_object subroutine to display object of any type
[PATCH 3/3] gitweb: Hyperlink target of symbolic link in "tree" view (if possible)
[PATCH/RFC 4/3] gitweb: SHA-1 in commit log message links to "object" view
Diffstat:
gitweb/gitweb.perl | 152 ++++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 137 insertions(+), 15 deletions(-)
--
Jakub Narebski
ShadeHawk on #git
^ permalink raw reply
* [PATCH 0/3] gitweb: Better symbolic link support in "tree" view
From: Jakub Narebski @ 2006-12-10 12:25 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vk616ezu5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote in
"Re: [PATCH] gitweb: Better symbolic link support in "tree" view":
> If you wanted to do this, a better way would be to have a new
> view that takes a commit/tree object and a path from the top of
> the repository, and shows either "no such path in that tree" or
> "here is the view for that object, by the way it was a blob."
> page. Then your list drawing would still need to open each
> symlink blob to show " -> link_target", and need to check if it
> goes outside the repository (I would assume you are handling
> relative links as well), but you do not need to do expensive
> ls-tree step one per symlink on the page. The href attr of the
> A element " -> link_target" would point at that "universal
> object view" with the link_target pathname (that is, the blob
> contents) and the commit/tree object name (h or hb I do not know
> which) and you will spend cycles to run ls-tree only when the
> user actually asks to follow that link.
>
> In other words, I think trying to be lazy is extremely important
> while drawing a big list.
I not necessarily agree; I think that symbolic links are sufficnetly
rare that a bit more time spent to make the view better for end user
(link only if target exists) is worth it. But...
Here follows the implementation of this idea: first to read link
target and show it in "tree" view _without_ hyperlink, then
introduction of generic "object" view which does the verification and
redirect to correct view accorting to the type of object, and last
show link target hyperlinked in "tree" view using "object" view/action
link.
While at it implement the same "lazy" solution in commitsha1 commitag
in format_log_line_html subroutine.
Table of contents:
[PATCH 1/3] gitweb: Show target of symbolic link in "tree" view
[PATCH 2/3] gitweb: Add generic git_object subroutine to display object of any type
[PATCH 3/3] gitweb: Hyperlink target of symbolic link in "tree" view (if possible)
[PATCH/RFC 4/3] gitweb: SHA-1 in commit log message links to "object" view
Diffstat:
gitweb/gitweb.perl | 152 ++++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 137 insertions(+), 15 deletions(-)
--
Jakub Narebski
ShadeHawk on #git
^ permalink raw reply
* [PATCH 1/3] gitweb: Show target of symbolic link in "tree" view
From: Jakub Narebski @ 2006-12-10 12:25 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
In-Reply-To: <7vk616ezu5.fsf@assigned-by-dhcp.cox.net>
In "tree" view (git_print_tree_entry subroutine), for entries which are
symbolic links, add " -> link_target" after file name (a la "ls -l").
Link target is _not_ hyperlinked.
While at it, correct whitespaces (tabs are for aling, spaces are for indent)
in modified git_print_tree_entry subroutine.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Jakub Narebski wrote:
> I'll split the patch into two: first to read link target and show it in
> "tree" view _without_ hyperlink, and later perhaps either your or mine
> solution (most probably yours), depending on feedback.
That implements the first part.
gitweb/gitweb.perl | 42 ++++++++++++++++++++++++++++++++++--------
1 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5ea3fda..0c2cfc7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1989,12 +1989,31 @@ sub git_print_log ($;%) {
}
}
+# return link target (what link points to)
+sub git_get_link_target {
+ my $hash = shift;
+ my $link_target;
+
+ # read link
+ open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
+ or return;
+ {
+ local $/;
+ $link_target = <$fd>;
+ }
+ close $fd
+ or return;
+
+ return $link_target;
+}
+
+
# print tree entry (row of git_tree), but without encompassing <tr> element
sub git_print_tree_entry {
my ($t, $basedir, $hash_base, $have_blame) = @_;
my %base_key = ();
- $base_key{hash_base} = $hash_base if defined $hash_base;
+ $base_key{'hash_base'} = $hash_base if defined $hash_base;
# The format of a table row is: mode list link. Where mode is
# the mode of the entry, list is the name of the entry, an href,
@@ -2005,16 +2024,23 @@ sub git_print_tree_entry {
print "<td class=\"list\">" .
$cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
file_name=>"$basedir$t->{'name'}", %base_key),
- -class => "list"}, esc_path($t->{'name'})) . "</td>\n";
+ -class => "list"}, esc_path($t->{'name'}));
+ if (S_ISLNK(oct $t->{'mode'})) {
+ my $link_target = git_get_link_target($t->{'hash'});
+ if ($link_target) {
+ print " -> " . esc_path($link_target);
+ }
+ }
+ print "</td>\n";
print "<td class=\"link\">";
print $cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key)},
- "blob");
+ file_name=>"$basedir$t->{'name'}", %base_key)},
+ "blob");
if ($have_blame) {
print " | " .
$cgi->a({-href => href(action=>"blame", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key)},
- "blame");
+ file_name=>"$basedir$t->{'name'}", %base_key)},
+ "blame");
}
if (defined $hash_base) {
print " | " .
@@ -2036,8 +2062,8 @@ sub git_print_tree_entry {
print "</td>\n";
print "<td class=\"link\">";
print $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key)},
- "tree");
+ file_name=>"$basedir$t->{'name'}", %base_key)},
+ "tree");
if (defined $hash_base) {
print " | " .
$cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
--
1.4.4.1
^ permalink raw reply related
* [PATCH 2/3] gitweb: Add generic git_object subroutine to display object of any type
From: Jakub Narebski @ 2006-12-10 12:25 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
In-Reply-To: <7vk616ezu5.fsf@assigned-by-dhcp.cox.net>
Add generic "object" view implemented in git_object subroutine, which is
used to display object of any type; to be more exact it redirects to the
view of correct type: "blob", "tree", "commit" or "tag". To identify object
you have to provide either hash (identifier of an object), or (in the case of
tree and blob objects) hash of commit object (hash_base) and path (file_name).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
First version had checking if $hash and $hash_base are explicit SHA-1
if are defined. This version doesn't have this check, which is
important for next patch.
gitweb/gitweb.perl | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0c2cfc7..a988f85 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -434,6 +434,7 @@ my %actions = (
"tags" => \&git_tags,
"tree" => \&git_tree,
"snapshot" => \&git_snapshot,
+ "object" => \&git_object,
# those below don't need $project
"opml" => \&git_opml,
"project_list" => \&git_project_list,
@@ -3620,6 +3621,53 @@ sub git_commit {
git_footer_html();
}
+sub git_object {
+ # object is defined by:
+ # - hash or hash_base alone
+ # - hash_base and file_name
+ my $type;
+
+ # - hash or hash_base alone
+ if ($hash || ($hash_base && !defined $file_name)) {
+ my $object_id = $hash || $hash_base;
+
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command cat-file -t $object_id 2>/dev/null"
+ or die_error('404 Not Found', "Object does not exist");
+ $type = <$fd>;
+ chomp $type;
+ close $fd
+ or die_error('404 Not Found', "Object does not exist");
+
+ # - hash_base and file_name
+ } elsif ($hash_base && defined $file_name) {
+ $file_name =~ s,/+$,,;
+
+ system(git_cmd(), "cat-file", '-e', $hash_base) == 0
+ or die_error('404 Not Found', "Base object does not exist");
+
+ # here errors should not hapen
+ open my $fd, "-|", git_cmd(), "ls-tree", $hash_base, "--", $file_name
+ or die_error(undef, "Open git-ls-tree failed");
+ my $line = <$fd>;
+ close $fd;
+
+ #'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa panic.c'
+ unless ($line && $line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t/) {
+ die_error('404 Not Found', "File or directory for given base does not exist");
+ }
+ $type = $2;
+ $hash = $3;
+ } else {
+ die_error('404 Not Found', "Not enough information to find object");
+ }
+
+ print $cgi->redirect(-uri => href(action=>$type, -full=>1,
+ hash=>$hash, hash_base=>$hash_base,
+ file_name=>$file_name),
+ -status => '302 Found');
+}
+
sub git_blobdiff {
my $format = shift || 'html';
--
1.4.4.1
^ 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