* Re: [PATCH] Fix empty line processing in git-shortlog.perl
From: Petr Baudis @ 2005-11-06 22:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20051106224218.22797.97260.stgit@machine.or.cz>
Dear diary, on Sun, Nov 06, 2005 at 11:42:18PM CET, I got a letter
where Petr Baudis <pasky@suse.cz> told me that...
> diff --git a/git-shortlog.perl b/git-shortlog.perl
> index 0b14f83..7283159 100755
> --- a/git-shortlog.perl
> +++ b/git-shortlog.perl
> @@ -94,7 +94,7 @@ sub changelog_input {
>
> # skip to non-blank line
> elsif ($pstate == 3) {
> - next unless /^\s*?(.*)/;
> + next unless /^\s*?(\S.*)$/;
>
> # skip lines that are obviously not
> # a 1-line cset description
>
Whoops, the ? was not part of the original regexp and is obviously
useless. Well, I don't think it really matters, so it is up to you...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [PATCH] Support for passing path to custom map in git-shortlog.perl
From: Petr Baudis @ 2005-11-06 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Aside of looking into .mailmap, add support for -m MAPFILE.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-shortlog.txt | 10 +++++++++-
git-shortlog.perl | 10 ++++++++++
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
index 65ca77f..c8de78e 100644
--- a/Documentation/git-shortlog.txt
+++ b/Documentation/git-shortlog.txt
@@ -8,13 +8,21 @@ git-shortlog - Summarize 'git log' outpu
SYNOPSIS
--------
-'git-log --pretty=short | git shortlog'
+'git-log --pretty=short | git shortlog [-m MAILMAP_FILE]'
DESCRIPTION
-----------
Summarizes 'git log' output in a format suitable for inclusion
in release announcements.
+OPTIONS
+-------
+-m MAILMAP_FILE::
+ File containing the email-to-realname mappings to be used
+ in case of the realname missing in the "Author" field of
+ the commit. In addition, the '.mailmap' file and few predefined
+ mappings are also always searched.
+
Author
------
diff --git a/git-shortlog.perl b/git-shortlog.perl
index 7283159..cd83dbe 100755
--- a/git-shortlog.perl
+++ b/git-shortlog.perl
@@ -1,6 +1,7 @@
#!/usr/bin/perl -w
use strict;
+use Getopt::Std;
my (%mailmap);
my (%email);
@@ -9,6 +10,9 @@ my $pstate = 1;
my $n_records = 0;
my $n_output = 0;
+my (%opts);
+getopts('m:', \%opts);
+
sub shortlog_entry($$) {
my ($name, $desc) = @_;
my $key = $name;
@@ -132,6 +136,12 @@ sub setup_mailmap {
read_mailmap($fh, \%mailmap);
close $fh;
}
+ if ($opts{'m'}) {
+ my $fh = undef;
+ open($fh, '<', $opts{'m'}) or die "Cannot open mailmap $opts{m}: $!";
+ read_mailmap($fh, \%mailmap);
+ close($fh);
+ }
}
sub finalize {
^ permalink raw reply related
* [PATCH] Allow GIT_DIR to be an absolute path
From: Johannes Schindelin @ 2005-11-06 23:36 UTC (permalink / raw)
To: git, junkio
This fixes a problem in safe_create_leading_directories() when the
argument starts with a '/' (i.e. the path is absolute).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
I did not thoroughly check if there are more places where a
relative path is assumed. Could well be the only one.
sha1_file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 8a2743d0d424a3bc0ff120cdba66ee20b59f5a56
e1f7e03e178889c53367745810130ef3e933d2aa
diff --git a/sha1_file.c b/sha1_file.c
index 642f00d..544db4e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -50,7 +50,7 @@ int get_sha1_hex(const char *hex, unsign
int safe_create_leading_directories(char *path)
{
- char *pos = path;
+ char *pos = path+1;
while (pos) {
pos = strchr(pos, '/');
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] http-fetch: do not use curl_message after releasing it
From: Johannes Schindelin @ 2005-11-06 23:59 UTC (permalink / raw)
To: git, junkio
When curl_message is released using curl_multi_remove_handle(), it's
contents are undefined. Therefore, get the information before releasing it.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
http-fetch.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
applies-to: a216f59923735f7680de8b3d9d333dc14de12b77
0516b1524ce60af57bf056f24b29983a70fb113f
diff --git a/http-fetch.c b/http-fetch.c
index b12779d..ea8af1b 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -578,6 +578,7 @@ void process_curl_messages(void)
while (curl_message != NULL) {
if (curl_message->msg == CURLMSG_DONE) {
+ int curl_result = curl_message->data.result;
slot = active_queue_head;
while (slot != NULL &&
slot->curl != curl_message->easy_handle)
@@ -587,7 +588,7 @@ void process_curl_messages(void)
active_requests--;
slot->done = 1;
slot->in_use = 0;
- slot->curl_result = curl_message->data.result;
+ slot->curl_result = curl_result;
curl_easy_getinfo(slot->curl,
CURLINFO_HTTP_CODE,
&slot->http_code);
@@ -599,8 +600,7 @@ void process_curl_messages(void)
fprintf(stderr, "Received DONE message for unknown request!\n");
}
if (request != NULL) {
- request->curl_result =
- curl_message->data.result;
+ request->curl_result = curl_result;
request->http_code = slot->http_code;
request->slot = NULL;
request->state = COMPLETE;
---
0.99.9.GIT
^ permalink raw reply related
* Re: git binary directory?
From: Junio C Hamano @ 2005-11-07 0:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20051106221952.GP1431@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> You are also going to break the porcelains (w/o manual user
> intervention), so I'm not happy about it but if you are doing it, do it
> now, please. :-)
I thought Porcelains and people's script can just say 'git foo'
everywhere where it currently says 'git-foo', and it should work
before and after the change, and that is what I did to my
private scripts. But you are right, it is nicer if 'git-foo'
continued to work with a single patch to cg-Xlib or somewhere
central like that.
> BTW, can I easily get the patch from the 'git' tool, so that I can
> extend $PATH appropriately during Cogito initialization?
Do you mean 'git --show-git-libdir' or something like that?
^ permalink raw reply
* Re: [PATCH] Support for passing path to custom map in git-shortlog.perl
From: Junio C Hamano @ 2005-11-07 0:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051106230757.24941.19267.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Aside of looking into .mailmap, add support for -m MAPFILE.
I thought about this when I did .mailmap because I felt
the more flexibility the better, but wouldn't maintaining the
project-wide .mailmap as part of the project easier to manage?
^ permalink raw reply
* Re: git binary directory?
From: Petr Baudis @ 2005-11-07 0:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7virv5wc86.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Nov 07, 2005 at 01:08:57AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > You are also going to break the porcelains (w/o manual user
> > intervention), so I'm not happy about it but if you are doing it, do it
> > now, please. :-)
>
> I thought Porcelains and people's script can just say 'git foo'
> everywhere where it currently says 'git-foo', and it should work
> before and after the change, and that is what I did to my
> private scripts. But you are right, it is nicer if 'git-foo'
> continued to work with a single patch to cg-Xlib or somewhere
> central like that.
I want to avoid extra fork()s and exec()s. They seem to routinely matter
in orders of magnitude of speed in tight loops.
Besides, I'm more used to the dash form. ;-)
> > BTW, can I easily get the patch from the 'git' tool, so that I can
> > extend $PATH appropriately during Cogito initialization?
>
> Do you mean 'git --show-git-libdir' or something like that?
Yes. Well... you said you have the gitdir changes in your 'pu' branch,
but http://www.kernel.org/git/?p=git/git.git;a=tree;h=pu;hb=pu doesn't
appear to have the changes...?
Is --show-git-libdir already implemented?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: git binary directory?
From: Linus Torvalds @ 2005-11-07 0:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20051107004346.GR1431@pasky.or.cz>
On Mon, 7 Nov 2005, Petr Baudis wrote:
>
> I want to avoid extra fork()s and exec()s. They seem to routinely matter
> in orders of magnitude of speed in tight loops.
Yes. The more I think about it, the less I like the separate binary
directory after all. The "git cmd" format is great for high-level
commands, but we've always done "git-diff-tree" and "git-rev-list" etc
without the "git cmd" indirection.
The downsides of a separate binary directory appear to be bigger than the
upside..
Linus
^ permalink raw reply
* Re: Expected Behavior?
From: Junio C Hamano @ 2005-11-07 1:38 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EYsny-0004hq-IW@jdl.com>
Jon Loeliger <jdl@freescale.com> writes:
> # Untracked files:
> # (use "git add" to add to commit)
> #
> # file3
>
> Why is file3 considered untracked and needing to be added?
> It was present in both "dev" and "master" branches before
> the merge. It doesn't end up with "<<< one === other >>>"
> style diffs either.
It is because Untracked uses different program than git-diff-*
and, it mishandles unmerged paths. Let me see...
Yup, it uses "git-ls-files --others", which considers that
unmerged paths do not "exist" in the index. This is wrong.
The attached is a patch to fix ls-files.
I also think that file3 should not appear in "Updated but not
checked in (will commit)" list -- we are _not_ going to commit
unmerged paths until you tell git what you want to do with
them. The patch in the next message fixes it.
-- >8 -- cut here -- >8 --
Subject: ls-files: --others should not say unmerged paths are unknown.
Jon Loeliger noticed that an unmerged path appears as
"Untracked" in git-status output, even though we show the same
path as updated/changed. Since --others means "we have not told
git about that path", we should not show unmerged paths --
obviously, git knows about them; it just does not know what we
want to do about them yet.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
ls-files.c | 26 ++++++++++++++++++++++++--
1 files changed, 24 insertions(+), 2 deletions(-)
applies-to: f571975209b0bc38ca099684f9731efe4163b396
fcbc3083e37f3c025d85d7b2c8a1c53d07a81fac
diff --git a/ls-files.c b/ls-files.c
index d9c8b21..f7653e7 100644
--- a/ls-files.c
+++ b/ls-files.c
@@ -348,6 +348,29 @@ static void show_dir_entry(const char *t
putchar(line_terminator);
}
+static void show_other_files(void)
+{
+ int i;
+ for (i = 0; i < nr_dir; i++) {
+ /* We should not have a matching entry, but we
+ * may have an unmerged entry for this path.
+ */
+ struct nond_on_fs *ent = dir[i];
+ int pos = cache_name_pos(ent->name, ent->len);
+ struct cache_entry *ce;
+ if (0 <= pos)
+ die("bug in show-other-files");
+ pos = -pos - 1;
+ if (pos < active_nr) {
+ ce = active_cache[pos];
+ if (ce_namelen(ce) == ent->len &&
+ !memcmp(ce->name, ent->name, ent->len))
+ continue; /* Yup, this one exists unmerged */
+ }
+ show_dir_entry(tag_other, ent);
+ }
+}
+
static void show_killed_files(void)
{
int i;
@@ -438,8 +461,7 @@ static void show_files(void)
read_directory(path, base, baselen);
qsort(dir, nr_dir, sizeof(struct nond_on_fs *), cmp_name);
if (show_others)
- for (i = 0; i < nr_dir; i++)
- show_dir_entry(tag_other, dir[i]);
+ show_other_files();
if (show_killed)
show_killed_files();
}
---
0.99.9.GIT
^ permalink raw reply related
* git-status: do not mark unmerged paths as committable.
From: Junio C Hamano @ 2005-11-07 1:39 UTC (permalink / raw)
To: git
An unmerged path appears as both "Updated but not checked in" list,
and "Changed but not updated" list. We are not going to commit that
path until it is resolved, so remove it from the former list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-status.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 49ac95e5ebfd28b32ec1a23a0982900426f0c06c
f1790448628262e46496861bb6da76be63a2a247
diff --git a/git-status.sh b/git-status.sh
index 62a24a9..837f334 100755
--- a/git-status.sh
+++ b/git-status.sh
@@ -41,7 +41,7 @@ git-update-index -q --unmerged --refresh
if GIT_DIR="$GIT_DIR" git-rev-parse --verify HEAD >/dev/null 2>&1
then
- git-diff-index -M --cached --name-status HEAD |
+ git-diff-index -M --cached --name-status --diff-filter=MDTCRA HEAD |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
---
0.99.9.GIT
^ permalink raw reply related
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through the history
From: Junio C Hamano @ 2005-11-07 1:45 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <436E85DA.1080904@michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> I've written a tool that will take a single commit, add it as a parent
> of another commit, and recreate the history above that second commit in
> a fully compatible manner.
I think the procedure is reproducible, which is a very nice
property to have for a tool like this, but I am not sure what
you mean by "in a fully compatible manner". What are you
compatible with?
Also another rhetorical, tongue-in-cheek question. What is your
plan to ripple the graft through to update signed tags? ;-)
^ permalink raw reply
* Re: Expected Behavior?
From: Junio C Hamano @ 2005-11-07 2:01 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git, torvalds
In-Reply-To: <E1EYsny-0004hq-IW@jdl.com>
Jon Loeliger <jdl@freescale.com> writes:
> git checkout -b dev
>
> echo "More for file1" >> file1
> rm -f file2
> echo "Another file!" > file3
>
> git update-index file1
> git update-index --force-remove file2
> git add file3
You do not have file2 in the working tree, so regular --remove
would do.
git-update-index --add --remove file1 file2 file3
> git merge "Grab dev stuff" master dev
This is good. We used to use (and the tutorial only talks
about) git-resolve to do this step, like this:
git-resolve master dev 'Merge dev branch'
And I've kept using git-resolve myself; not that I do not trust
git-merge but purely from inertia, although I was the one who
did 'git merge' ;-). Maybe I should first update the tutorial
to use git-merge instead of git-resolve.
It appears that as the everyday workhorse, using Daniel's
git-merge-resolve is stable through git-merge have proven stable
enough. So here is a question. Do people mind if 'git-resolve'
and 'git-octopus' are dropped before 1.0? This means 2 less
programs in your /usr/bin ;-).
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through the history
From: Ryan Anderson @ 2005-11-07 2:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vll01ut6j.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]
Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
>
>>I've written a tool that will take a single commit, add it as a parent
>>of another commit, and recreate the history above that second commit in
>>a fully compatible manner.
>
>
> I think the procedure is reproducible, which is a very nice
> property to have for a tool like this, but I am not sure what
> you mean by "in a fully compatible manner". What are you
> compatible with?
Well, what I meant was, "It creates a history that is purely a superset
of the old history, so merges should work cleanly from the pre-graft
subhistory to the fully merged history."
But clearly I was too ... terse.
IOW, this should work perfectly, assuming neither tree has been pulled
into since the history was merged into historical-graft tree:
$ cd linux-head
$ git branch -b ryan-hacking HEAD
$ quilt push -a
$ git commit -a -m "Apply quilt tree"
$ cd ../linux-historical-graft/
$ git pull ../linux-historical-graft/
> Also another rhetorical, tongue-in-cheek question. What is your
> plan to ripple the graft through to update signed tags? ;-)
:) Well, since I can't resist answering your rhetorical question:
They signed a specific DAG. I'm providing a richer, more complete DAG
that is a pure-superset of the one they signed. It is not, however,
equivalent, so their signature is not related to the superset DAG I have
created. In practice, however, I don't expect that any tag-signers
would state that there is a meaningful difference between the two DAGs,
from the perspective of their signature.
FYI - I don't think merging the trees like this is a good idea, from the
perspective of something like gitk - gitk took long enough to startup
and display something on my merged tree here that I gave up and killed
it off.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* HTTP push
From: Johannes Schindelin @ 2005-11-07 2:35 UTC (permalink / raw)
To: git
Hi,
I played a little with git-http-push. There are some strange things going
on: whenever I commented out the calls to curl_multi_remove_handle() and
curl_multi_cleanup(), all was well. Whenever I did not, there was either a
segfault, or an endless loop.
Also, I had to update my curl, because http-push *absolutely* needs
CURLOPT_HTTPGET. I tried to fake it with any combination of
CURLOPT_{NOBODY,POST,PUT,UPLOAD}, but failed. (Yes, that means that you
won't have to deal any longer with my patches to support older curl
versions...)
Note: all my tests are from an iBook (client) to an Intel Linux (server).
I will run some tests on another client with valgrind (that will wait
until tomorrow; it's 3.30am local time, so I head to bed).
Ciao,
Dscho
^ permalink raw reply
* Re: Errors cloning over http -- git-clone and cg-clone fail to fetch a reachable object...
From: Martin Langhoff @ 2005-11-07 2:52 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <46a038f90511061354k5378a92ckc427841f90ec8b4@mail.gmail.com>
On 11/7/05, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Strange!
>
> I'm getting errors when cloning over http
More info on this.
git-fetch-pack (invoked by cg-fetch) bails out because it thinks it
got a 404 fetching one of the packs:
Getting pack 9cbe4a5eb777d4ee535f08feb471e812208ed3a5
which contains 7004cdf821ab5ddcded7819dea34015b0e84cd9a
error: Unable to get pack file
http://locke.catalyst.net.nz/git/moodle.git//objects/pack/pack-9cbe4a5eb777d4ee535f08feb471e812208ed3a5.pack
The requested URL returned error: 404
However, the url is reachable via http (tested with curl and wget) and
Apache records the transaction as a 200 OK -- there's no 404 there!
(There are 404s, of course, for objects that are in the pack but not
for any pack). Trying to read http-fetch.c and http-pull.c to figure
out where we could get the return status wrong, but my C is just
nonexistant. Hints appreciated.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Fix empty line processing in git-shortlog.perl
From: Junio C Hamano @ 2005-11-07 2:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051106224218.22797.97260.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Faced with a commit such as
>
> commit f1b2646c7f2713c3ea4bce120e1d0d8091808be4
> Author: Adrian Bunk <bunk@r063144.stusta.swh.mhn.de>
> Date: Sun Nov 6 20:30:38 2005 +0100
>
> From: Michal Wronski <wrona@mat.uni.torun.pl>
>
> I've jchanged my email. Please apply this patch so as to everybody
> could send me a remarks about mqueuefs.
>
> Signed-off-by: Michal Wronski <Michal.Wronski@motorola.com>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> git-shortlog.perl would produce a line with an empty commit title.
> This patch fixes that...
> - next unless /^\s*?(.*)/;
> + next unless /^\s*?(\S.*)$/;
I suspect /(\S.*)$/ would do the same thing, but in any case
I do not think it is the right fix.
I think the problem is deeper than that. Shortlog summarizes to
only one line per commit, so I suspect what you would be feeding
it would say something like this for the above example:
commit f1b2646c7f2713c3ea4bce120e1d0d8091808be4
Author: Adrian Bunk <bunk@r063144.stusta.swh.mhn.de>
From: Michal Wronski <wrona@mat.uni.torun.pl>
That is, the commit you quoted is done by 'git log --pretty',
but a typical shortlog invocation would be:
git log --pretty=short rev1..rev2 | git shortlog
With or without your fix, the command barfs.
Of course, that "From: " line should have been used as the
commit author by the tool that created the commit out of e-mail
Adrian received, but that is a separate issue.
^ permalink raw reply
* Re: HTTP push
From: Nick Hengeveld @ 2005-11-07 4:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511070328230.25684@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, Nov 07, 2005 at 03:35:33AM +0100, Johannes Schindelin wrote:
> I played a little with git-http-push. There are some strange things going
> on: whenever I commented out the calls to curl_multi_remove_handle() and
> curl_multi_cleanup(), all was well. Whenever I did not, there was either a
> segfault, or an endless loop.
http-push is a bit more aggressive than http-fetch about freeing up memory,
perhaps too aggressive... I ran into similar issues when memory was
freed more than once.
> I will run some tests on another client with valgrind (that will wait
> until tomorrow; it's 3.30am local time, so I head to bed).
Thanks, I'll work on memory cleanup some more.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Errors cloning over http -- git-clone and cg-clone fail to fetch a reachable object...
From: Nick Hengeveld @ 2005-11-07 4:37 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90511061852h5cdf9539o34f69b4deb9f041a@mail.gmail.com>
On Mon, Nov 07, 2005 at 03:52:41PM +1300, Martin Langhoff wrote:
> > I'm getting errors when cloning over http
>
> More info on this.
>
> git-fetch-pack (invoked by cg-fetch) bails out because it thinks it
> got a 404 fetching one of the packs:
Does it always error out on the same pack file?
Which build of git are you using, and which version of curl?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Errors cloning over http -- git-clone and cg-clone fail to fetch a reachable object...
From: Martin Langhoff @ 2005-11-07 4:50 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Git Mailing List
In-Reply-To: <20051107043737.GI3001@reactrix.com>
On 11/7/05, Nick Hengeveld <nickh@reactrix.com> wrote:
> On Mon, Nov 07, 2005 at 03:52:41PM +1300, Martin Langhoff wrote:
>
> > > I'm getting errors when cloning over http
> >
> > More info on this.
> >
> > git-fetch-pack (invoked by cg-fetch) bails out because it thinks it
> > got a 404 fetching one of the packs:
>
> Does it always error out on the same pack file?
Yes.
> Which build of git are you using, and which version of curl?
A mix of 0.99.9, 0.99.9{b,c,d} and today's. Tested with Johannes'
patch of today for curl message handling, thinking it was related. No
dice.
On the Debian x86 box, it's
$ curl -V
curl 7.13.2 (i386-pc-linux-gnu) libcurl/7.14.0 OpenSSL/0.9.7g
zlib/1.2.2 libidn/0.5.18
Protocols: ftp gopher telnet dict ldap http file https ftps
Features: IDN IPv6 Largefile NTLM SSL libz
On the MacOSX box, it's
$ curl -V
curl 7.10.2 (powerpc-apple-darwin7.0) libcurl/7.10.2 OpenSSL/0.9.7g zlib/1.1.4
cheers,
martin
^ permalink raw reply
* [PATCH] Introducing: git-cvsexportcommit
From: Martin Langhoff @ 2005-11-07 4:57 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
A script that can replay commits git into a CVS checkout. Tries to ensure the
sanity of the operation and supports mainly manual usage.
If you are reckless enough, you can ask it to autocommit when everything has
applied cleanly. Combined with a couple more scripts could become part of
a git2cvs gateway.
Should support adds/removes and binary files.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
The script has been in use in-house for a few days now, so it seems to
work. Should grow a matching git-cvsexport script to drive it...
---
Documentation/git-cvsexportcommit.txt | 56 ++++++++
Makefile | 2
git-cvsexportcommit.perl | 225 +++++++++++++++++++++++++++++++++
3 files changed, 282 insertions(+), 1 deletions(-)
create mode 100644 Documentation/git-cvsexportcommit.txt
create mode 100755 git-cvsexportcommit.perl
applies-to: faf296a197318ad6a001a672e3b585e6fe31f37b
3c52d7ffb4ce62605a132c72170613be84b5d733
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
new file mode 100644
index 0000000..532db66
--- /dev/null
+++ b/Documentation/git-cvsexportcommit.txt
@@ -0,0 +1,56 @@
+git-cvsexportcommit(1)
+================
+
+NAME
+----
+git-cvsexportcommit - Export a commit to a CVS checkout
+
+
+SYNOPSIS
+--------
+git-cvsapplycommmit.perl
+ [ -h ] [ -v ] [ -c ] [ -p ] [PARENTCOMMIT] COMMITID
+
+
+DESCRIPTION
+-----------
+Exports a commit from GIT to a CVS checkout, making it easier
+to merge patches from a git repository into a CVS repository.
+
+Execute it from the root of the CVS working copy. GIT_DIR must be defined.
+
+It does its best to do the safe thing, it will check that the files are
+unchanged and up to date in the CVS checkout, and it will not autocommit
+by default.
+
+Supports file additions, removals, and commits that affect binary files.
+
+If the commit is a merge commit, you must tell git-cvsapplycommit what parent
+should the changeset be done against.
+
+OPTIONS
+-------
+
+-c::
+ Commit automatically if the patch applied cleanly. It will not
+ commit if any hunks fail to apply or there were other problems.
+
+-p::
+ Be pedantic (paranoid) when applying patches. Invokes patch with
+ --fuzz=0
+
+-v::
+ Verbose.
+
+Author
+------
+Written by Martin Langhoff <martin@catalyst.net.nz>
+
+Documentation
+--------------
+Documentation by Martin Langhoff <martin@catalyst.net.nz>
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index 6c01dc2..9ee1605 100644
--- a/Makefile
+++ b/Makefile
@@ -94,7 +94,7 @@ SCRIPT_SH = \
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
git-rename.perl git-shortlog.perl git-fmt-merge-msg.perl \
- git-svnimport.perl git-mv.perl
+ git-svnimport.perl git-mv.perl git-cvsexportcommit.perl
SCRIPT_PYTHON = \
git-merge-recursive.py
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
new file mode 100755
index 0000000..7074b0c
--- /dev/null
+++ b/git-cvsexportcommit.perl
@@ -0,0 +1,225 @@
+#!/usr/bin/perl -w
+
+use strict;
+use Getopt::Std;
+use File::Temp qw(tempdir);
+use Data::Dumper;
+
+unless ($ENV{GIT_DIR} && -r $ENV{GIT_DIR}){
+ die "GIT_DIR is not defined or is unreadable";
+}
+
+our ($opt_h, $opt_p, $opt_v, $opt_c );
+
+getopt('hpvc');
+
+$opt_h && usage();
+
+die "Need at least one commit identifier!" unless @ARGV;
+
+# setup a tempdir
+our ($tmpdir, $tmpdirname) = tempdir('git-cvsapplycommit-XXXXXX',
+ TMPDIR => 1,
+ CLEANUP => 1);
+
+print Dumper(@ARGV);
+# resolve target commit
+my $commit;
+$commit = pop @ARGV;
+$commit = `git-rev-parse --verify "$commit"^0`;
+chomp $commit;
+if ($?) {
+ die "The commit reference $commit did not resolve!";
+}
+
+# resolve what parent we want
+my $parent;
+if (@ARGV) {
+ $parent = pop @ARGV;
+ $parent = `git-rev-parse --verify "$parent"^0"`;
+ chomp $parent;
+ if ($?) {
+ die "The parent reference did not resolve!";
+ }
+}
+
+# find parents from the commit itself
+my @commit = `git-cat-file commit $commit`;
+my @parents;
+foreach my $p (@commit) {
+ if ($p =~ m/^$/) { # end of commit headers, we're done
+ last;
+ }
+ if ($p =~ m/^parent (\w{40})$/) { # found a parent
+ push @parents, $1;
+ }
+}
+
+if ($parent) {
+ # double check that it's a valid parent
+ foreach my $p (@parents) {
+ my $found;
+ if ($p eq $parent) {
+ $found = 1;
+ last;
+ }; # found it
+ die "Did not find $parent in the parents for this commit!";
+s }
+} else { # we don't have a parent from the cmdline...
+ if (@parents == 1) { # it's safe to get it from the commit
+ $parent = $parents[0];
+ } else { # or perhaps not!
+ die "This commit has more than one parent -- please name the parent you want to use explicitly";
+ }
+}
+
+$opt_v && print "Applying to CVS commit $commit from parent $parent\n";
+
+# grab the commit message
+`git-cat-file commit $commit | sed -e '1,/^\$/d' > .msg`;
+$? && die "Error extraction the commit message";
+
+my (@afiles, @dfiles, @mfiles);
+my @files = `git-diff-tree -r $parent $commit`;
+print @files;
+$? && die "Error in git-diff-tree";
+foreach my $f (@files) {
+ chomp $f;
+ my @fields = split(m/\s+/, $f);
+ if ($fields[4] eq 'A') {
+ push @afiles, $fields[5];
+ }
+ if ($fields[4] eq 'M') {
+ push @mfiles, $fields[5];
+ }
+ if ($fields[4] eq 'R') {
+ push @dfiles, $fields[5];
+ }
+}
+$opt_v && print "The commit affects:\n ";
+$opt_v && print join ("\n ", @afiles,@mfiles,@dfiles) . "\n\n";
+undef @files; # don't need it anymore
+
+# check that the files are clean and up to date according to cvs
+my $dirty;
+foreach my $f (@afiles, @mfiles, @dfiles) {
+ # TODO:we need to handle removed in cvs and/or new (from git)
+ my $status = `cvs -q status "$f" | grep '^File: '`;
+
+ unless ($status =~ m/Status: Up-to-date$/) {
+ $dirty = 1;
+ warn "File $f not up to date in your CVS checkout!\n";
+ }
+}
+if ($dirty) {
+ die "Exiting: your CVS tree is not clean for this merge.";
+}
+
+###
+### NOTE: if you are planning to die() past this point
+### you MUST call cleanupcvs(@files) before die()
+###
+
+
+print "'Patching' binary files\n";
+
+my @bfiles = `git-diff-tree -p $parent $commit | grep '^Binary'`;
+@bfiles = map { chomp } @bfiles;
+foreach my $f (@bfiles) {
+ # check that the file in cvs matches the "old" file
+ # extract the file to $tmpdir and comparre with cmp
+ my $tree = `git-rev-parse $parent^{tree} `;
+ chomp $tree;
+ my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
+ chomp $blob;
+ `git-cat-file blob $blob > $tmpdir/blob`;
+ `cmp -q $f $tmpdir/blob`;
+ if ($?) {
+ warn "Binary file $f in CVS does not match parent.\n";
+ $dirty = 1;
+ next;
+ }
+
+ # replace with the new file
+ `git-cat-file blob $blob > $f`;
+
+ # TODO: something smart with file modes
+
+}
+if ($dirty) {
+ cleanupcvs(@files);
+ die "Exiting: Binary files in CVS do not match parent";
+}
+
+## apply non-binary changes
+my $fuzz = $opt_p ? 0 : 2;
+
+print "Patching non-binary files\n";
+print `(git-diff-tree -p $parent -p $commit | patch -p1 -F $fuzz ) 2>&1`;
+
+my $dirtypatch = 0;
+if (($? >> 8) == 2) {
+ cleanupcvs(@files);
+ die "Exiting: Patch reported serious trouble -- you will have to apply this patch manually";
+} elsif (($? >> 8) == 1) { # some hunks failed to apply
+ $dirtypatch = 1;
+}
+
+foreach my $f (@afiles) {
+ `cvs add $f`;
+ if ($?) {
+ $dirty = 1;
+ warn "Failed to cvs add $f -- you may need to do it manually";
+ }
+}
+
+foreach my $f (@dfiles) {
+ `cvs rm -f $f`;
+ if ($?) {
+ $dirty = 1;
+ warn "Failed to cvs rm -f $f -- you may need to do it manually";
+ }
+}
+
+print "Commit to CVS\n";
+my $commitfiles = join(' ', @afiles, @mfiles, @dfiles);
+my $cmd = "cvs commit -F .msg $commitfiles";
+
+if ($dirtypatch) {
+ print "NOTE: One or more hunks failed to apply cleanly.\n";
+ print "Resolve the conflicts and then commit using:n";
+ print "\n $cmd\n\n";
+ exit;
+}
+
+
+if ($opt_c) {
+ print "Autocommit\n $cmd\n";
+ print `cvs commit -F .msg $commitfiles 2>&1`;
+ if ($?) {
+ cleanupcvs(@files);
+ die "Exiting: The commit did not succeed";
+ }
+ print "Committed successfully to CVS\n";
+} else {
+ print "Ready for you to commit, just run:\n\n $cmd\n";
+}
+sub usage {
+ print STDERR <<END;
+Usage: GIT_DIR=/path/to/.gi ${\basename $0} # fetch/update GIT from CVS
+ [-h] [-p] [ parent ] commit
+END
+ exit(1);
+}
+
+# ensure cvs is clean before we die
+sub cleanupcvs {
+ my @files = @_;
+ foreach my $f (@files) {
+ `cvs -q update -C "$f"`;
+ if ($?) {
+ warn "Warning! Failed to cleanup state of $f\n";
+ }
+ }
+}
+
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH] Refactored merge options into separate merge-options.txt.
From: Jon Loeliger @ 2005-11-07 5:30 UTC (permalink / raw)
To: git
Refactored fetch options into separate fetch-options.txt.
Made git-merge use merge-options.
Made git-fetch use fetch-options.
Made git-pull use merge-options and fetch-options.
Added --help option to git-pull and git-format-patch scripts.
Rewrote Documentation/Makefile to dynamically determine
include dependencies.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Documentation/Makefile | 23 +++++++++++++----------
Documentation/fetch-options.txt | 14 ++++++++++++++
Documentation/git-fetch.txt | 16 ++++------------
Documentation/git-merge.txt | 2 +-
Documentation/git-pull.txt | 17 +++++++----------
Documentation/merge-options.txt | 16 ++++++++++++++++
Documentation/merge-pull-opts.txt | 14 --------------
git-format-patch.sh | 4 ++++
git-pull.sh | 12 +++++++++++-
9 files changed, 70 insertions(+), 48 deletions(-)
create mode 100644 Documentation/fetch-options.txt
create mode 100644 Documentation/merge-options.txt
delete mode 100644 Documentation/merge-pull-opts.txt
mode change 100755 => 100644 git-pull.sh
applies-to: ba0221fabc6d203e08fbe63442e816ed84193bb1
2cf02ee5ec5f3b5ecaec5a80399988661ea5117b
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 741f14c..b8f62cb 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -49,22 +49,25 @@ install: man
$(INSTALL) $(DOC_MAN1) $(DESTDIR)/$(man1)
$(INSTALL) $(DOC_MAN7) $(DESTDIR)/$(man7)
-# 'include' dependencies
-$(patsubst %.txt,%.1,$(wildcard git-diff-*.txt)): \
- diff-format.txt diff-options.txt
-$(patsubst %.txt,%.html,$(wildcard git-diff-*.txt)): \
- diff-format.txt diff-options.txt
-$(patsubst %,%.1,git-fetch git-pull git-push): pull-fetch-param.txt
-$(patsubst %,%.html,git-fetch git-pull git-push): pull-fetch-param.txt
+#
+# Determine "include::" file references in asciidoc files.
+#
+TEXTFILES = $(wildcard *.txt)
+DEPFILES = $(TEXTFILES:%.txt=%.dep)
+
+%.dep : %.txt
+ @rm -rf $@
+ @$(foreach dep, $(shell grep include:: $< | sed -e 's/include::/ /' -e 's/\[\]//'), \
+ echo $(<:%.txt=%.html) $(<:%.txt=%.1) : $(dep) >> $@; )
-$(patsubst %,%.1,git-merge git-pull): merge-pull-opts.txt
-$(patsubst %,%.html,git-merge git-pull): merge-pull-opts.txt
+-include $(DEPFILES)
git.7: ../README
+
clean:
- rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html
+ rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html *.dep
%.html : %.txt
asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
new file mode 100644
index 0000000..12d12b2
--- /dev/null
+++ b/Documentation/fetch-options.txt
@@ -0,0 +1,14 @@
+-a, \--append::
+ Append ref names and object names of fetched refs to the
+ existing contents of `.git/FETCH_HEAD`. Without this
+ option old data in `.git/FETCH_HEAD` will be overwritten.
+
+-f, \--force::
+
+-t, \--tags::
+
+-u, \--update-head-ok::
+ By default `git-fetch` refuses to update the head which
+ corresponds to the current branch. This flag disables the
+ check. Note that fetching into the current branch will not
+ update the index and working directory, so use it with care.
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 73f8a99..438240c 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -8,7 +8,7 @@ git-fetch - Download objects and a head
SYNOPSIS
--------
-'git-fetch' <repository> <refspec>...
+'git-fetch' <options> <repository> <refspec>...
DESCRIPTION
@@ -17,24 +17,16 @@ Fetches named heads or tags from another
the objects necessary to complete them.
The ref names and their object names of fetched refs are stored
-in $GIT_DIR/FETCH_HEAD. This information is left for a later merge
+in `.git/FETCH_HEAD`. This information is left for a later merge
operation done by "git resolve" or "git octopus".
OPTIONS
-------
+include::fetch-options.txt[]
+
include::pull-fetch-param.txt[]
--a, \--append::
- Append ref names and object names of fetched refs to the
- existing contents of $GIT_DIR/FETCH_HEAD. Without this
- option old data in $GIT_DIR/FETCH_HEAD will be overwritten.
-
--u, \--update-head-ok::
- By default 'git-fetch' refuses to update the head which
- corresponds to the current branch. This flag disables the
- check. Note that fetching into the current branch will not
- update the index and working directory, so use it with care.
SEE ALSO
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index b3ef19b..904e2fc 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -19,7 +19,7 @@ which drives multiple merge strategy scr
OPTIONS
-------
-include::merge-pull-opts.txt[]
+include::merge-options.txt[]
<msg>::
The commit message to be used for the merge commit (in case
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 7ebb08d..c65ca9a 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -20,21 +20,18 @@ Note that you can use `.` (current direc
<repository> to pull from the local repository -- this is useful
when merging local branches into the current branch.
+
OPTIONS
-------
-include::pull-fetch-param.txt[]
+include::merge-options.txt[]
--a, \--append::
- Append ref names and object names of fetched refs to the
- existing contents of `$GIT_DIR/FETCH_HEAD`. Without this
- option old data in `$GIT_DIR/FETCH_HEAD` will be overwritten.
+include::fetch-options.txt[]
-include::merge-pull-opts.txt[]
+include::pull-fetch-param.txt[]
include::merge-strategies.txt[]
-
EXAMPLES
--------
@@ -72,7 +69,7 @@ $ git fetch origin master:origin +pu:pu
$ git pull . origin
------------------------------------------------
+
-Here, a typical `$GIT_DIR/remotes/origin` file from a
+Here, a typical `.git/remotes/origin` file from a
`git-clone` operation is used in combination with
command line options to `git-fetch` to first update
multiple branches of the local repository and then
@@ -85,7 +82,7 @@ known to have already obtained and made
all the necessary objects.
-Pull of multiple branches from one repository using `$GIT_DIR/remotes` file::
+Pull of multiple branches from one repository using `.git/remotes` file::
+
------------------------------------------------
$ cat .git/remotes/origin
@@ -98,7 +95,7 @@ $ git checkout master
$ git pull origin
------------------------------------------------
+
-Here, a typical `$GIT_DIR/remotes/origin` file from a
+Here, a typical `.git/remotes/origin` file from a
`git-clone` operation has been hand-modified to include
the branch-mapping of additional remote and local
heads directly. A single `git-pull` operation while
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
new file mode 100644
index 0000000..eebaf3a
--- /dev/null
+++ b/Documentation/merge-options.txt
@@ -0,0 +1,16 @@
+-n, \--no-summary::
+ Do not show diffstat at the end of the merge.
+
+--no-commit::
+ Perform the merge but pretend the merge failed and do
+ not autocommit, to give the user a chance to inspect and
+ further tweak the merge result before committing.
+
+
+-s <strategy>, \--strategy=<strategy>::
+ Use the given merge strategy; can be supplied more than
+ once to specify them in the order they should be tried.
+ If there is no `-s` option, a built-in list of strategies
+ is used instead (`git-merge-resolve` when merging a single
+ head, `git-merge-octopus` otherwise).
+
diff --git a/Documentation/merge-pull-opts.txt b/Documentation/merge-pull-opts.txt
deleted file mode 100644
index d9164a0..0000000
--- a/Documentation/merge-pull-opts.txt
+++ /dev/null
@@ -1,14 +0,0 @@
--n, --no-summary::
- Do not show diffstat at the end of the merge.
-
---no-commit::
- Perform the merge but pretend the merge failed and do
- not autocommit, to give the user a chance to inspect and
- further tweak the merge result before committing.
-
--s <strategy>::
- use that merge strategy; can be given more than once to
- specify them in the order they should be tried. If
- there is no `-s` option, built-in list of strategies is
- used instead (`git-merge-resolve` when merging a single
- head, `git-merge-octopus` otherwise).
diff --git a/git-format-patch.sh b/git-format-patch.sh
index b43ba39..548d2d5 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -8,6 +8,7 @@
usage () {
echo >&2 "usage: $0"' [-n] [-o dir | --stdout] [--keep-subject] [--mbox]
[--check] [--signoff] [-<diff options>...]
+ [--help]
( from..to ... | upstream [ our-head ] )
Prepare each commit with its patch since our-head forked from upstream,
@@ -63,6 +64,9 @@ do
--output-directo|--output-director|--output-directory)
case "$#" in 1) usage ;; esac; shift
outdir="$1" ;;
+ -h|--h|--he|--hel|--help)
+ usage
+ ;;
-*' '* | -*"$LF"* | -*' '*)
# Ignore diff option that has whitespace for now.
;;
diff --git a/git-pull.sh b/git-pull.sh
old mode 100755
new mode 100644
index e23d4f5..2358af6
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -7,7 +7,14 @@
. git-sh-setup || die "Not a git archive"
usage () {
- die "git pull [-n] [--no-commit] [-s strategy]... <repo> <head>..."
+ echo >&2 "usage: $0"' [-n] [--no-commit] [--no-summary] [--help]
+ [-s strategy]...
+ [<fetch-options>]
+ <repo> <head>...
+
+Fetch one or more remote refs and merge it/them into the current HEAD.
+'
+ exit 1
}
strategy_args= no_summary= no_commit=
@@ -33,6 +40,9 @@ do
esac
strategy_args="${strategy_args}-s $strategy "
;;
+ -h|--h|--he|--hel|--help)
+ usage
+ ;;
-*)
# Pass thru anything that is meant for fetch.
break
---
0.99.9.GIT
^ permalink raw reply related
* GIT 0.99.9e
From: Junio C Hamano @ 2005-11-07 5:43 UTC (permalink / raw)
To: git; +Cc: linux-kernel
GIT 0.99.9e maintenance release is found at the usual places:
RPM, tarballs, and deb:
http://www.kernel.org/pub/software/scm/git/
With git, fetch maint branch from
git://git.kernel.org/pub/scm/git/git.git/
It contains everything from the master branch. Since we seem to
be shelving the separate git binary directory idea indefinitely,
what we have here is pretty much what will be in 1.0, from the
source code POV.
- http-push seems to still have a bug or two but that is to be
expected for any new code, and I am reasonably sure it can be
ironed out; preferably before 1.0 but it is not a
showstopper.
- I've done the initial round of package splitting for Debian
side myself, but it probably needs proofreading and fixing by
experienced Debian person. Similar RPM package splitting
that parallels the above is needed. Although it is not an
absolute requirement for my sources to have perfect binary
packaging support (I am just an upstream for binary
packagers), it is certainly desirable to have RPM specs and
debian/ files in a presentable shape for 1.0.
- I still need to go over the tutorial and core-ish
documentation once for consistency checks.
Changes since 0.99.9d are:
Johannes Schindelin:
Allow GIT_DIR to be an absolute path
http-fetch: do not use curl_message after releasing it
Jon Loeliger:
Refactor merge strategies into separate includable file.
Junio C Hamano:
test: t4102-apply-rename fails with strict umask (Peter Baumann).
git-format-patch: silly typo fix.
Documentation: pull/clone ref mapping clarification (Josef Weidendorfer).
git-fetch: fail if specified refspec does not match remote.
Simplify CFLAGS/DEFINES in Makefile
Package split: Debian.
Install asciidoc sources as well.
Further Debian split fixes.
Debian: test build.
Merge in http-push first stage.
Document expat dependency when using http-push.
ls-files: --others should not say unmerged paths are unknown.
git-status: do not mark unmerged paths as committable.
Set up remotes/origin to track all remote branches.
Nick Hengeveld:
Add support for pushing to a remote repository using HTTP/DAV
Verify remote packs, speed up pending request queue
Support remote references with slashes in their names
Improve lock handling
Refresh the remote lock if it is about to expire
Paul Collins:
http-push.c: include with angle bracket, not dq.
Randal L. Schwartz:
Use fink/darwinport paths for OSX
^ permalink raw reply
* Re: expat.h missing
From: Marco Roeland @ 2005-11-07 8:24 UTC (permalink / raw)
To: alxneit; +Cc: git
In-Reply-To: <200511062139.15622.ivo.alxneit@psi.ch>
On Sunday November 6th 2005 at 21:39 uur alxneit wrote:
> Nick Hengevelds patch to add support for pushing to a remote repository using
> HTTP/DAV (58e60dd203362ecb9fdea765dcc2eb573892dbaf)
> introduces "#include expat.h" in http-push.c. this file seems to be missing.
Expat is a standard package for reading XML files, it is not part of git
itself. You have to install the expat development kit package of your
distribution to get its headers installed, or alternatively set
"NO_EXPAT" before compilation.
--
Marco Roeland
^ permalink raw reply
* Re: git binary directory?
From: Petr Baudis @ 2005-11-07 9:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0511061653380.3316@g5.osdl.org>
Dear diary, on Mon, Nov 07, 2005 at 01:54:55AM CET, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Mon, 7 Nov 2005, Petr Baudis wrote:
> >
> > I want to avoid extra fork()s and exec()s. They seem to routinely matter
> > in orders of magnitude of speed in tight loops.
>
> Yes. The more I think about it, the less I like the separate binary
> directory after all. The "git cmd" format is great for high-level
> commands, but we've always done "git-diff-tree" and "git-rev-list" etc
> without the "git cmd" indirection.
>
> The downsides of a separate binary directory appear to be bigger than the
> upside..
Well, _one_ fork per user invocation (subsequent invocations wouldn't
need it, I already "cache" this kind of stuff in the environment) of a
Cogito command (to get the path to the gitdir) is not such a big deal,
I think.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Tags not transferred with git pull?
From: Erik Mouw @ 2005-11-07 10:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vll04tdsz.fsf@assigned-by-dhcp.cox.net>
On Fri, Nov 04, 2005 at 11:26:20AM -0800, Junio C Hamano wrote:
> Sorry for the confusion. The barebone Porcelainish shipped with
> git-core does not fetch and store tags unconditionally under the
> same name as the remote has without being told; you need to
> explicitly tell it to 'git fetch --tags'.
>
> What was added recently was a low level support for Cogito to
> implement the automatic tracking. This is supposed to (I do not
> offhand know if the Cogito side has been updated to do so
> already) work a bit differently. Instead of grabbing all tags
> and all objects reachable from them, as you fetch commits from
> the remote, the automatic tracking fetches tags that point at
> them. What this means is that the tags on the remote branch you
> are tracking would be fetched automatically but tags on a remote
> branch you are not interested in are not.
Thanks for the explanation.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ 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