Thanks. The script was a bit more scary than I thought, but in the end I managed to generate something. There are trailing dots in project names, but I'm not going to waste time on that anymore - this has long gone over the 20 minutes I originally alotted the project anyway; I hope cgit will gain a builtin capability for this in the future, since this is still quite a pain. Attached is a random patch for your script I had to use, FWIW. Unfortunately, the recommended RewriteRule is not working ...

This patch adds the autosign configuration variable which is checked by the "new" command to automatically sign the patch message. Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com> --- BTW, what happened to the patchdescr.tmpl file? It doesn't seem to be used anymore, however one can save a template file examples/gitconfig | 3 +++ stgit/commands/new.py | 8 +++++++- 2 files changed, 10 insertions(+), 1 deletions(-) diff --git a/examples/gitconfig ...

Since we'll get rid of the individual patch logs, StGit should ignore if such a ref is missing when deleting the compatibility patch files. Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com> --- stgit/lib/stack.py | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/stgit/lib/stack.py b/stgit/lib/stack.py index 9cb3967..1059955 100644 --- a/stgit/lib/stack.py +++ b/stgit/lib/stack.py @@ -68,7 +68,11 @@ class Patch(object): for f in ...

This patch introduces basic tests for git submodule add covering the basic functionality and the -b parameter. A trivial update --init test fix freeloads on this commit as well. Signed-off-by: Petr Baudis <pasky@suse.cz> --- t/t7400-submodule-basic.sh | 28 +++++++++++++++++++++++++++- 1 files changed, 27 insertions(+), 1 deletions(-) diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh index be73f7b..8a002bc 100755 --- a/t/t7400-submodule-basic.sh +++ ...

Another thing --- can submodule_by_path() ever return NULL saying "I do not see one in the configuration"? --

This interface itself is ugly (why should a caller pass "it is unmerged or does not exist" without checking?), and it also makes the hunk that begins at 84/105 ugly. Why not "path_is_gitlink(const char*)" and run cache_name_pos() here instead? The interface, even if it is internal, should be done with a better taste than that, even though I understand that you wanted to reuse the cache_pos for the source one while you check. Oh, by the way, what should happen when you have an unmerged path ...

This patch adds support for moving submodules to 'git mv', including rewriting of the .gitmodules file to reflect the movement. Signed-off-by: Petr Baudis <pasky@suse.cz> --- I'm sorry, I was careless - this is the correct patch version, referring to string_list_item.string instead of .path. Also, the testsuite in patch 4 is for some reason marked as (c)'d by Dscho. Not that it would be a big deal. builtin-mv.c | 37 +++++++++++++++++++++++++++++++++---- 1 files changed, 33 ...

Hmmmm. If I did... $ git init $ create and add normal paths $ git clone git://..../gitk.git gitk $ git add gitk : heh, I changed my mind $ git rm gitk the last step would die, because I changed my mind before fully initializing gitk repository as a proper submodule? How would I get rid of the index entry to recover from the mistake? $ rm -fr gitk $ git rm gitk would presumably fail the same way, no? I hope I am misreading ...

I will collect your feedback on the whole series, then resend it from scratch - sounds good? This is still easier to use than explicit snprintf(), but in the long run, you're right that returning just the submodule name is the right Sensible idea. No, it would rather die(). -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates --

The testsuite for newly added submodule support in git mv, git rm. Signed-off-by: Petr Baudis <pasky@suse.cz> --- t/t7403-submodule-mvrm.sh | 242 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 242 insertions(+), 0 deletions(-) create mode 100755 t/t7403-submodule-mvrm.sh diff --git a/t/t7403-submodule-mvrm.sh b/t/t7403-submodule-mvrm.sh new file mode 100755 index 0000000..9b50d6a --- /dev/null +++ b/t/t7403-submodule-mvrm.sh @@ -0,0 +1,242 @@ +#!/bin/sh +# +# ...

This patch adds support for moving submodules to 'git mv', including rewriting of the .gitmodules file to reflect the movement. Signed-off-by: Petr Baudis <pasky@suse.cz> --- builtin-mv.c | 37 +++++++++++++++++++++++++++++++++---- 1 files changed, 33 insertions(+), 4 deletions(-) diff --git a/builtin-mv.c b/builtin-mv.c index 4f65b5a..52e3ea5 100644 --- a/builtin-mv.c +++ b/builtin-mv.c @@ -9,6 +9,7 @@ #include "cache-tree.h" #include "string-list.h" #include ...

- Make citool return nonzero exit code if it did not commit. - Add a mode where it does not actually commit and simply exits with zero code. Commit message is either disabled, or simply dumped to GITGUI_EDITMSG before exiting. - Add an option to immediately start it in amend mode. Rationale: 1) Use 'git citool --nocommit' instead of mergetool in scripts. 2) Use 'git citool --amend' to edit commits while rebasing. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> --- I think ...

First, what operating system, and in the case of Linux what distribution do you use? For example both Fedora Core and Debian (so also all Debian-derived distributions like Ubuntu) have gitweb* package; so it should be very simple to install this. Because installing CGI script (or legacy mod_perl script) differs from distribution to distribution, therefore stock RPMS from kernel.org doesn't create gitweb package. So you would have to either download source tarball, or clone git repository, ...

Hello, Since we cannot change management to decide on using git instead of whatever they are using overnight. Best is to have tools like git-p4/git-svn which allows interoperability. Once people gain confidence, they can replace that whatever SCM with git. That is the path I am planning at my place of work. -dhruva Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here http://in.promos.yahoo.com/address --

This patch introduces a new attribute "dashed" to be used in the master command list. Server type commands are marked as "dashed", and "cmd-list.perl" is taught to use this attributes when writing out links in the command lists by category: git-cvsserver git-daemon git-receive-pack git-shell git-upload-archive git-upload-pack Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> --- Documentation/cmd-list.perl | 7 ++++++- command-list.txt | 12 ++++++------ 2 ...

Heck, please ignore this one, sorry. This is what happens when you rebase to change the subject but forget to clean out 00*. It's identical with the other 2/6 otherwise. Michael --

This converts all links for git commands whose names do not begin with "git-". We use the "linkgitasis" macro for them which preserves the name. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> --- Documentation/config.txt | 10 +++++----- Documentation/diff-options.txt | 4 ++-- Documentation/git-add.txt | 4 ++-- Documentation/git-am.txt | 2 +- Documentation/git-annotate.txt | 2 +- ...

This introduces a new macro "link-git" which prepends "git-" or "git " to the link target, depending on the backend. We keep the dash for the docbook backend because some man viewers depend on it. There are no dashes for the html backend. This patch also renames the existing "linkgit" macro to "linkgitasis", in preparation for the upcoming changes. This makes it easier to split the changes into parts: dashed form for server type programmes, dashless form for all other ...

Signed-off-by: Christian Stimming <stimming@tuhh.de> --- gitk | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/gitk b/gitk index 2eaa2ae..ccf6952 100755 --- a/gitk +++ b/gitk @@ -269,7 +269,7 @@ proc parseviewrevs {view revs} { lappend badrev $line } } - error_popup "Error parsing revisions: $err" + error_popup "[mc "Error parsing revisions:"] $err" return {} } set ret {} @@ -324,7 +324,7 @@ proc start_rev_list ...

Oh - right. Thanks for pointing this out. Please modify the patch accordingly. Christian --

Fixed and applied. Thanks, both. -- Shawn. --

To check whether it actually matters for me, I have counted HTTP requests for info/refs: 42 per hour for the last 5.5 days. So it might. 28% of the requests are web crawlers. For objects/../, it is more fun - 1942 requests per hour. 46% is accounted for web crawlers. I will put up a robots.txt. ;-) -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates --

Hi, this finally tripped me over and I wanted to quickly add cgit as an alternate viewing interface at repo.or.cz. But it seems that cgit requires all the repositories explicitly listed in the config file. Do you plan to remove this limitation in the future? Thanks, Petr "Pasky" Baudis --

This statistics are already available at ...and I don't know out of the top of my head how to best gather the rest either. ;-) (If someone is really interested about all this, that's fine, but they have to give me a pre-made cookbook of recipes how to hook that up to RRD.) -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates --

Hi all, I am new git.. I would like to configure git as a public repository for my rails application.. Please help me.. Thanks Sg.. -- View this message in context: http://www.nabble.com/configuring-git-public-repository-tp19449377p19449377.html Sent from the git mailing list archive at Nabble.com. --

<plug> Current cgit also allows cloning over http using the same url as for browsing the repo, i.e. you may $ git clone http://hjemli.net/git/cgit This has one advantage over just publishing the repo; you don't have to run `git-update-server-info` (thanks to the work done by Shawn O. Pearce on git-http-backend, which is shamelessly reimplemented in cgit). </plug> -- larsh --

In the simplest case just some averaged system load (perhaps load average from uptime, or from top, or from /proc) before and after. Perhaps bandwidth used per week or something like that too. If you have time and interest, CPU load, disk IO, network IO or network bandwidth used, and average time to serve request (latency) for fetching via HTTP protocol, for "dumb" and "smart" clients, perhaps averaged over number of requests. (I don't know unfortunately how to get such data). In short: ...

Not really, I'd rather add another command (or a commandline option) to generate an include-file for cgitrc by scanning directory-trees for git repos. I've CC'd Kristian since I believe he's got such a script running for freedesktop.org; if so, maybe it could be included/used as basis for something similar in cgit? -- larsh --

The real improvement is on the client side; how long does it take to do a clone or a fetch with dumb HTTP vs. with smart HTTP. The latency is horrible for dumb HTTP if the repository is not packed, or bad if it just repacked and you have to download everything again. Knowing the transfer time of each request start-to-finish and the total time for a "session" (e.g. a period of where that IP appears actively requesting in the logs) would tell you how long a given client needs to do a fetch or ...

Signed-off-by: Jonas Fonseca <fonseca@diku.dk> --- .../src/org/spearce/jgit/lib/Repository.java | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java index b27c23d..730a267 100644 --- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java @@ -628,7 +628,7 @@ else if ...

Fix Repository.resolve("tag^0") failing with "not a commit" (issue 23). Add test for resolving "tag^{tree}" where "tag" points to a tag Signed-off-by: Jonas Fonseca <fonseca@diku.dk> --- .../spearce/jgit/test/resources/create-second-pack | 8 +++++ ...ck-546ff360fe3488adb20860ce3436a2d6373d2796.idx | Bin 0 -> 1324 bytes ...k-546ff360fe3488adb20860ce3436a2d6373d2796.pack | Bin 0 -> 1265 bytes .../org/spearce/jgit/test/resources/packed-refs | 18 ++++++++++++ ...

tag^2 means you have a merge commit. I think rev^0 is mentioned here My guess is you added to original test tag C manually so it got an "non-deterministic" time stamp. -- robin --

To be compatible with git-rev-parse, commit~0 should resolve to commit, commit~1 to commit^, etc. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> --- .../org/spearce/jgit/lib/T0008_testparserev.java | 9 +++++---- .../src/org/spearce/jgit/lib/Repository.java | 2 +- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java index ...

Nothing. I should stop advertising that I still use a lot of plumbing when a porcelain like 'git reset' does the job as well. ;-( Thanks for the correction.

Hi, I'm afraid you will have to elaborate on "had no luck". Kind regards, Petr "Pasky" Baudis --

As Karl said, we have some plans to allow collaboration between multiple StGit repositories but we didn't have much time to look at it recently. Karl's "merge" stuff looks promising though. What "sync" does is that it allow the same set of patches between two branches to be synchronised in case modifications happened on one of these branches. In your situation, you would have to fetch the remote branch, uncommit as in Karl's method and either import or sync the remote patches with those on ...

BTW, "sync" allows synchronisation with a series of patches stored in a directory. So you can also share patches using exported repositories with import and sync. -- Catalin --

I've considered this question a lot before and could not come up with anything; you cannot undo a merge. --=20 martin | http://madduck.net/ | http://two.sentenc.es/ =20 it may look like i'm just sitting here doing nothing. but i'm really actively waiting for all my problems to go away. =20 spamtraps: madduck.bogus@madduck.net

No (that would be useless), see http://kerneltrap.org/mailarchive/git/2008/8/13/2925144 #first tg redepend idea I've just implemented the second idea http://kerneltrap.org/mailarchive/git/2008/8/15/2954214 but haven't got any time to test it yet. Then there's also http://kerneltrap.org/mailarchive/git/2008/8/15/2952004 Yeah, i've been thinking that too. It would be nice if we could hack around that. It seems that the two redepend ideas get around it at the ...

The read-tree step is broken, you can't do that. The dependencies content will be gone from your base, but not from the actual head - what's the point of removing them at all? Actually, tg patch will then show diff not only of your patch, but the removed dependencies as well! There's plenty of other problems with this approach as well. And I can't That's good point, indirect dependencies problem did not occur to me before. That's troublesome... I'm beginning to wonder if it is worth ...

Yeah, I must admit I am okay with *this* cache. Paolo --

By definition of the origin headerfield that is not wrong, there are no other rules. But the point is moot at the moment, since I'm going to create a proof of concept which puts the field in the free-form trailer. -- Sincerely, Stephen R. van den Berg. "Father's Day: Nine months before Mother's Day." --

Actually its the association in the other direction which you'd want to cache. It's fast given the commit SHA to dig the original patch id out of the commit message. What is harder is given a patch id X, to find all of the commits which either (a) have a patch id of X, or (b) have a commit message indicating that the original patch-id was X. So having a database which caches this information, so given a patch-id, you can quickly look up the related commits, is what I believe Sam ...

For a local clone, git could be taught to copy the cache file. For a network-based clone, the percentage of time needed to download is roughly 2-3 times that (although that will obviously depend on your network connectivity). Building this cache can be done in the background, though, or delayed until the first time the cache is needed. - Ted --

For a rough estimate, try: time git log -p | git patch-id >/dev/null -Peff --

Fair enough. If noone beats me to it, I'll probably take a stab at implementing something like this and see how it fares for my own application. -- Sincerely, Stephen R. van den Berg. "Father's Day: Nine months before Mother's Day." --

Nope, as Sam suggested in his original message (but which got clipped by Linus when he was replying) all you have to do is to have a separate local database which ties commits and patch-id's together as a cache/index. I know you seem to be resistent to caches, but caches are **good** because they are local information, which by definition can be implementation-dependent; you can always generate the cache from the git repository if for some reason you need to extend it. It also means that if ...

Maybe you're right. The reason why my first knee-jerk reaction is "performance problem" is because: - The field is rarely present. - When it is used, we look for it on every commit we traverse. - This means that finding out the field does *not* exist is the most common operation, and that effort rises linearly with the number of commits visited. Whereas if the information is present in the header or trailer of the commit, finding out that the field does not exist there is ...

And that's WRONG. Both prior and origin must fetch them if they're reference in the header. --

Attack-wise, you're right, it's not a big deal. I think the comforting feeling one gets about the hashes protecting integrity is what matters more for me here. -- Sincerely, Stephen R. van den Berg. "Father's Day: Nine months before Mother's Day." --

Hmmm... it looks _exactly_ like a problem I had with writing "syntax highlighting" (and linkage) for the patchset part of 'commitdiff' and 'blobdiff' views, namely that typechange (file to symlink and vice versa) generates two patches for single difftree (raw diff format output) line. See git_patchset_body in gitweb/gitweb.perl, and is_patch_split function, and commit message of 0cec6db (gitweb: Fix and simplify "split patch" detection), which tells about alternate solution. -- Jakub ...

Technically, you write the test to make sure that your new feature works as intended and won't break in the future. But since that's Nice. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle --

>>>>> "Clark" == Clark Williams <clark.williams@gmail.com> writes: Clark> Zowie, I thought I only had to worry about folks sending Clark> patches with incomplete information. So you get patches to the Clark> ada compiler that are rooted in gcc/ada (e.g. patch in tarball Clark> says "./ChangeLog", instead of gcc/ada/ChangeLog) rather than Clark> at a top level? Only way I could see to deal with that would be Clark> to try and pass in the appropriate prefix from the command Clark> line. Yes, ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm not sure how easy this is going to be. It looks like the patch is applied with 'git --apply' from the file stgit/git.py:apply_patch(). The default '-p' value is 1, so we'd have to figure out how to pass the 0 along and then get it into the Zowie, I thought I only had to worry about folks sending patches with incomplete information. So you get patches to the ada compiler that are rooted in gcc/ada (e.g. patch in tarball says "./ChangeLog", ...

True, I have forgot that "I use this SCM" (or "I used this SCM") doesn't necessarily mean that one _choose_ this SCM. One can use some SCM because it is SCM project uses, or because their company requires it; but not necessary, as git-svn and git-p4 show one can use Git, and make it interact with respectively Subversion and Perforce, and trying I hope not. Even Microsoft themselves supposedly doesn't recommend I don't think 59% (in the example case of using currently Subversion) is ...

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Turns out that asciidoc, at least the 8.2.5 on my system, does not honour the custom caption when converting to manpages. They become numbered 'Example' blocks instead. Is there another way to get a similar result? =2D Thomas =2D-=20 Thomas Rast trast@student.ethz.ch

Adds the functions git-mark-regexp and git-unmark-regexp to git.el. Creates a mark-map keymap to support dired-like behavior for marking/unmarking via regexp. Also adds these functions to the menubar. Signed-off-by: David Christensen <david@endpoint.com> --- contrib/emacs/git.el | 25 +++++++++++++++++-------- 1 files changed, 17 insertions(+), 8 deletions(-) diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el index 580652c..a982fbe 100644 --- a/contrib/emacs/git.el +++ ...