* Re: maybe breakage with latest git-pull and http protocol
From: Nick Hengeveld @ 2005-10-20 17:43 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <867jciz18w.fsf@blue.stonehenge.com>
Can you try using the following patch? This cleans up curl handles for
active request slots that are no longer in use. If all other prefetched
requests finish while a large transfer is happening, the active slots
currently keep open connections to the server and I'm guessing that
perhaps by the time additional objects are prefetched the server has
timed out some of those keepalive connections.
---
http-fetch.c | 26 ++++++++++++++++++++------
1 files changed, 20 insertions(+), 6 deletions(-)
applies-to: ce9a5a0fdd52a29e370d849a132b4509c844aca1
04b4353279eaceb7e7c3d73a9565b219aa7a10a9
diff --git a/http-fetch.c b/http-fetch.c
index a7dc2cc..d26fae8 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -291,11 +291,7 @@ static struct active_request_slot *get_a
}
if (slot == NULL) {
newslot = xmalloc(sizeof(*newslot));
-#ifdef NO_CURL_EASY_DUPHANDLE
- newslot->curl = get_curl_handle();
-#else
- newslot->curl = curl_easy_duphandle(curl_default);
-#endif
+ newslot->curl = NULL;
newslot->in_use = 0;
newslot->next = NULL;
@@ -311,6 +307,14 @@ static struct active_request_slot *get_a
slot = newslot;
}
+ if (slot->curl == NULL) {
+#ifdef NO_CURL_EASY_DUPHANDLE
+ slot->curl = get_curl_handle();
+#else
+ slot->curl = curl_easy_duphandle(curl_default);
+#endif
+ }
+
active_requests++;
slot->in_use = 1;
slot->done = 0;
@@ -612,6 +616,7 @@ void process_curl_messages(void)
void process_request_queue(void)
{
struct transfer_request *request = request_queue_head;
+ struct active_request_slot *slot = active_queue_head;
int num_transfers;
while (active_requests < max_requests && request != NULL) {
@@ -624,6 +629,14 @@ void process_request_queue(void)
}
request = request->next;
}
+
+ while (slot != NULL) {
+ if (!slot->in_use && slot->curl != NULL) {
+ curl_easy_cleanup(slot->curl);
+ slot->curl = NULL;
+ }
+ slot = slot->next;
+ }
}
#endif
@@ -1297,7 +1310,8 @@ int main(int argc, char **argv)
#endif
slot = active_queue_head;
while (slot != NULL) {
- curl_easy_cleanup(slot->curl);
+ if (slot->curl != NULL)
+ curl_easy_cleanup(slot->curl);
slot = slot->next;
}
#ifdef USE_CURL_MULTI
---
0.99.8.GIT
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply related
* Re: rsync update appears broken now
From: Linus Torvalds @ 2005-10-20 17:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, Alex Riesen, Git Mailing List
In-Reply-To: <81b0412b0510200608l61c00ed0yd4dbc00c313665fe@mail.gmail.com>
On Thu, 20 Oct 2005, Alex Riesen wrote:
>
> Absolutely normal pull into a changed repository. Just fix the
> conflict (in fetch-pack.c, look for >>>), git-update-index the file
> and commit. Doesn't look like a problem at all.
No, that's wrong.
The fact is, Junio has screwed up his repository, and if you merge, you'll
never have something that matches _his_ repository.
To fix this, _Junio_ needs to fix his repository.
For those of us who have a separate branch to track the original (I call
mine "parent), this tells the story:
* refs/heads/parent: does not fast forward to branch 'master' of master.kernel.org:/pub/scm/git/git;
not updating.
IOW, it looks like Junio has screwed up his "master" branch on kernel.org
and it no longer contains what it used to contain (and this is not a
mirroring problem - I'm using "master.kernel.org" with no mirrors in
between).
Doing a
git fetch parent master:new-junio
followed by a
gitk parent new-junio
shows that Junio seems to have re-based his "master" branch by removing
his old top-most entry, and restarted the "master" branch, which is wrong,
wrong, wrong.
Junio, please don't do that. It really screws people up. Now people can't
fetch your head any more, and can't track you, because your branch isn't
stable any more. I know you're very used to doing so in your "pu" branch,
but it's _wrong_. It's wrong in "pu" too, but at least there you have an
excuse.
Reparenting things is ok in _private_ branches, but it's not ok in public
ones, since _others_ will have worked or at least downloaded the previous
state.
The fact is, "distributed" fundamentally means "mistakes cannot be
undone". Mistakes have to be _fixed_, not removed. Because the mistakes
have already percolated to others.
Linus
^ permalink raw reply
* Re: rsync update appears broken now
From: dave morgan @ 2005-10-20 18:03 UTC (permalink / raw)
To: git
In-Reply-To: <118833cc0510200715x2a17dcbfs53c824435b7381e3@mail.gmail.com>
On Thu, 20 Oct 2005 10:15:58 -0400, Morten Welinder
<mwelinder@gmail.com> wrote:
>I see the very same with an http pull.
>
>Morten
>-
>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
I got the same with a git:// update
origin git://git.kernel.org/pub/scm/git/git.git
david@tower2:~/git$ cg-update
Up to date.
Applying changes...
Merging f8765797a41a39f4dfc7030098c38283e6461a83 ->
6e1c6c103c522d01829f3a63992a023ff031e851
to ea5a65a59916503d2a14369c46b1023384d51645...
... Auto-merging fetch-pack.c
merge: warning: conflicts during merge
Conflicts during merge. Do cg-commit after resolving them.
here is status after pull
david@tower2:~/git$ cg-status
Heads:
>master ea5a65a59916503d2a14369c46b1023384d51645
R origin 6e1c6c103c522d01829f3a63992a023ff031e851
? git-build-rev-cache
? git-checkout-cache
? git-convert-cache
? git-diff-cache
? git-diff-helper
? git-export
? git-fsck-cache
? git-http-pull
? git-local-pull
? git-merge-cache
? git-rev-tree
? git-show-rev-cache
? git-update-cache
Dave
^ permalink raw reply
* git-filehistory (first cut at detecting renames)
From: David Ho @ 2005-10-20 19:51 UTC (permalink / raw)
To: git
Hi all,
This is my stupid perl script to detect renames all the way to it's
origin. This is my first attempt at writing a perl script so it looks
a bit awful. It's not perfect, if a file is renamed, the entire
commit is dumped out. Maybe if git-diff-tree -M <pathname> does post
processing to output changes relevant to <pathname> then it will work
quite well.
David
[davidho@penguin git-tutorial]$ cat git-filehistory.perl
#!/usr/bin/perl
use warnings;
use strict;
sub usage($);
# Sanity checks:
my $GIT_DIR = $ENV{'GIT_DIR'} || ".git";
unless ( -d $GIT_DIR && -d $GIT_DIR . "/objects" &&
-d $GIT_DIR . "/objects/" && -d $GIT_DIR . "/refs") {
usage("Git repository not found.");
}
usage("") if scalar @ARGV != 1;
my ($file) = @ARGV;
unless (-f $file) {
usage("git filehistory: '$file' does not exist");
}
open(F,"-|","git-rev-parse",,"--default","HEAD","--revs-only",$file);
my $git_rev_args = <F>;
chomp ($git_rev_args);
close (F);
open(F,"-|","git-rev-list", $git_rev_args);
my @commits = <F>;
close (F);
my $nextname = $file;
for (my $i=0; $i < scalar @commits; $i++)
{
my $commit = $commits[$i];
chomp ($commit);
open(F,"-|","git-diff-tree","-r","-M", $commit)
or die "Failed to open pipe from git-diff-tree: " . $!;
my @lines = grep /R\d{3}.+$nextname/, <F>;
close(F);
if (scalar @lines >=1) {
#The file is renamed!
my $rc = system
("git-diff-tree","-r","-M","-p","--pretty=medium",$commit);
die "git-diff-tree failed" if $rc;
print "\n";
if ($lines[0] =~ /R\d{3}\t(.+)\t(.+)/) {
$nextname = $1;
}
}
else {
#Not renamed
my $rc = system
("git-diff-tree","-r","-m","-p","--pretty=medium",$commit, $nextname);
die "git-diff-tree failed" if $rc;
print "\n";
}
}
sub usage($) {
my $s = shift;
print $s, "\n" if (length $s != 0);
print <<EOT;
$0 <file>
This script traces renames to find the origin of the file
EOT
exit(1);
}
^ permalink raw reply
* Re: Errors from http-fetch
From: Daniel Barkalow @ 2005-10-20 20:02 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20051019223708.GC6160@reactrix.com>
On Wed, 19 Oct 2005, Nick Hengeveld wrote:
> > Another thing I noticed was that it was in the middle of downloading the
> > pack when it suddenly exitted due to not being able to find the object; it
> > would probably be worth having a call to finish up the active transfers
> > after giving up on completing the whole thing, since we probably do
> > actually want to finish downloading a big pack if we've started.
>
> I'm not sure how that could happen - once a pack download request
> starts, it has to finish before any fetch() calls can fail. However,
> there could certainly be other object requests in process when one
> fails, and it would be polite to let them finish.
Hmm; it definitely cut off a pack download in progress. When I ran it
again, it resumed that download, which contained the missing object. Last
night, I didn't see any problems, though. I'd certainly believe that
server disagreement could be a factor, though.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-filehistory (first cut at detecting renames)
From: David Ho @ 2005-10-20 20:19 UTC (permalink / raw)
To: git
In-Reply-To: <4dd15d180510201251p57bea756s18b2e77d4be4ec35@mail.gmail.com>
Actually, just tried it on the git repository. It is very slow.
Maybe because I'm doing a complete diff-tree on each commit. Mmm...
maybe there is a better way to detect renames when walking up the
file history.
David
On 10/20/05, David Ho <davidkwho@gmail.com> wrote:
> Hi all,
>
> This is my stupid perl script to detect renames all the way to it's
> origin. This is my first attempt at writing a perl script so it looks
> a bit awful. It's not perfect, if a file is renamed, the entire
> commit is dumped out. Maybe if git-diff-tree -M <pathname> does post
> processing to output changes relevant to <pathname> then it will work
> quite well.
>
> David
>
> [davidho@penguin git-tutorial]$ cat git-filehistory.perl
> #!/usr/bin/perl
>
> use warnings;
> use strict;
>
> sub usage($);
>
> # Sanity checks:
> my $GIT_DIR = $ENV{'GIT_DIR'} || ".git";
>
> unless ( -d $GIT_DIR && -d $GIT_DIR . "/objects" &&
> -d $GIT_DIR . "/objects/" && -d $GIT_DIR . "/refs") {
> usage("Git repository not found.");
> }
>
> usage("") if scalar @ARGV != 1;
>
> my ($file) = @ARGV;
>
> unless (-f $file) {
> usage("git filehistory: '$file' does not exist");
> }
>
> open(F,"-|","git-rev-parse",,"--default","HEAD","--revs-only",$file);
> my $git_rev_args = <F>;
> chomp ($git_rev_args);
> close (F);
>
> open(F,"-|","git-rev-list", $git_rev_args);
> my @commits = <F>;
> close (F);
>
> my $nextname = $file;
> for (my $i=0; $i < scalar @commits; $i++)
> {
> my $commit = $commits[$i];
> chomp ($commit);
>
> open(F,"-|","git-diff-tree","-r","-M", $commit)
> or die "Failed to open pipe from git-diff-tree: " . $!;
> my @lines = grep /R\d{3}.+$nextname/, <F>;
> close(F);
> if (scalar @lines >=1) {
> #The file is renamed!
> my $rc = system
> ("git-diff-tree","-r","-M","-p","--pretty=medium",$commit);
> die "git-diff-tree failed" if $rc;
> print "\n";
> if ($lines[0] =~ /R\d{3}\t(.+)\t(.+)/) {
> $nextname = $1;
> }
> }
> else {
> #Not renamed
> my $rc = system
> ("git-diff-tree","-r","-m","-p","--pretty=medium",$commit, $nextname);
> die "git-diff-tree failed" if $rc;
> print "\n";
> }
> }
>
> sub usage($) {
> my $s = shift;
> print $s, "\n" if (length $s != 0);
> print <<EOT;
> $0 <file>
> This script traces renames to find the origin of the file
> EOT
> exit(1);
> }
>
^ permalink raw reply
* Re: [PATCH] Do not send "want" lines for complete objects
From: Daniel Barkalow @ 2005-10-20 20:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0510200559540.3394@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, 20 Oct 2005, Johannes Schindelin wrote:
> Hi,
>
> > > + ((o = parse_object(remote)) != NULL) &&
> > > + (o->flags & COMPLETE) &&
>
> I just realized that parse_object() always reads the file, then does a
> lookup (which makes the above code work), and then parses the file. It
> always does all of these steps, even if the object was already parsed. Any
> reason for this?
I'm lazy and haven't sent in a patch to clean that up. There's no reason
it couldn't check whether the value it gets is already parsed.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: rsync update appears broken now
From: Junio C Hamano @ 2005-10-20 20:48 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0510201038320.3369@g5.osdl.org>
Linus Torvalds <torvalds <at> osdl.org> writes:
> For those of us who have a separate branch to track the original (I call
> mine "parent), this tells the story:
>
> * refs/heads/parent: does not fast forward to branch 'master' of
master.kernel.org:/pub/scm/git/git;
> not updating.
Yes, I screwed up. One honest mistake and another stupid one.
Note that "those of us" above include everybody who did "git-clone" to
set up the repository and left the default "Pull: master:origin" line in
.git/refs/remotes/origin.
> Junio, please don't do that. It really screws people up. Now people can't
> fetch your head any more, and can't track you, because your branch isn't
> stable any more.
Sorry, and yes that was the "honest mistake" part. I know I should never
rewind beyond what I already have pushed out, and usually I carefully follow
that rule.
But this time I forgot that I pushed something out and also failed to re-check
what I pushed out before rewinding (the check is done by fetching from
master.kernel.org myself).
And another stupid mistake part was when I pushed out the result. send-pack
correctly refused to update the master side, but I forced it without much
thinking.
Sorry about these mistakes.
Having said that, all is not lost. Your message made it sound like the
new head was completely re-rooted and there is no common commit (which
almost gave me a heart attack), but I do not think it is that bad. It is
more like pulling from two places.
-----(A) head merlyn and everybody
/ pulled from kernel.org previously
--- common ------------------------------------(B) head rebased and pushed
out by mistake
The "parent" head you described in your message is A above, and what is on
kernel.org is B. A is known as "origin" in the default setup git-clone makes.
If you have *no* further development on top of (A), the recovery is simple.
$ git checkout master ;# make sure you are on your "master" branch.
$ git fetch origin +master:origin ;# force "origin" to be (B)
$ git reset --hard origin ;# reset your "master" branch to (B)
If you had any further development on top of (A), then the graph would look
like:
-----(A)---------------(X) your tip
/
--- common ----------------------(B)
The merge conflict message you got when you pulled is result of trying to
merge (X) and (B).
There are two things we could do.
One is to forward port your changes between (A) and (X) on top of (B):
$ git checkout master ;# make sure you are on your "master" branch.
$ git tag anchor-a origin ;# stash (A) away
$ git fetch origin +master:origin ;# force "origin" to be (B)
$ git checkout -b rescue-stupid-junio origin
$ rm -fr .dotest
$ git format-patch -k --stdout anchor-a..master | git am -k -3
Depending on the changes between A and X, forward porting may result in
conflicting/unapplicable patches. The individual changes are found in
.dotest/ directory and you can re-run 'git am -i' after fixing up the
conflicts.
Then validate the tip of the result to make sure forward porting did not lose
your changes:
$ git diff origin..rescue-stupid-junio
If the result look OK, then we can make this your master branch.
$ git checkout master
$ git reset --hard rescue-stupid-junio
and clean things up by
$ rm -f .git/refs/tags/anchor-a
$ git branch -d rescue-stupid-junio
Another thing we could do is to treat as if this stupid maintainer briefly
had a twin who did concurrent development, and merge (X) and (B).
$ git checkout master
$ git pull origin +master:origin
This, as Merlyn and you saw, probably would result in merge conflicts which
need to be resolved manually.
Unfortunately I do not have access right now to commits between "common" and
(A) in the above picture (I am at work), so I cannot try any of the above out
myself.
^ permalink raw reply
* Re: git-filehistory (2nd try at detecting renames)
From: David Ho @ 2005-10-20 20:52 UTC (permalink / raw)
To: git
The output is a bit more manageable with this, but still a bit slow.
I tried it on git-commit.sh
David
[davidho@penguin git-tutorial]$ cat git-filehistory.perl
#!/usr/bin/perl
use warnings;
use strict;
sub usage($);
# Sanity checks:
my $GIT_DIR = $ENV{'GIT_DIR'} || ".git";
unless ( -d $GIT_DIR && -d $GIT_DIR . "/objects" &&
-d $GIT_DIR . "/objects/" && -d $GIT_DIR . "/refs") {
usage("Git repository not found.");
}
usage("") if scalar @ARGV != 1;
my ($file) = @ARGV;
unless (-f $file) {
usage("git filehistory: '$file' does not exist");
}
open(F,"-|","git-rev-parse",,"--default","HEAD","--revs-only",$file);
my $git_rev_args = <F>;
chomp ($git_rev_args);
close (F);
open(F,"-|","git-rev-list", $git_rev_args);
my @commits = <F>;
close (F);
my $nextname = $file;
my (@renamecommit, @renamecomment, @renameentry);
for (my $i=0; $i < scalar @commits; $i++)
{
my $commit = $commits[$i];
chomp ($commit);
open(F,"-|","git-diff-tree","-r","-M", $commit)
or die "Failed to open pipe from git-diff-tree: " . $!;
my @lines = grep /R\d{3}.+$nextname/, <F>;
close(F);
if (scalar @lines >=1) {
#The file is renamed!
#my $rc = system
("git-diff-tree","-r","-M","-p","--pretty=medium",$commit);
open (F,
"-|","git-diff-tree","-r","-M","--pretty=medium",$commit);
@renamecommit = <F>;
@renamecomment = grep /^[^:]/, @renamecommit;
@renameentry = grep /R\d{3}.+$nextname/, @renamecommit;
push @renamecomment, @renameentry;
foreach (@renamecomment) {
print;
}
if ($lines[0] =~ /R\d{3}\t(.+)\t(.+)/) {
$nextname = $1;
}
close(F);
}
else {
#Not renamed
#my $rc = system
("git-diff-tree","-r","-m","-p","--pretty=medium",$commit, $nextname);
my $rc = system
("git-diff-tree","-r","--pretty=medium",$commit, $nextname);
die "git-diff-tree failed" if $rc;
}
}
sub usage($) {
my $s = shift;
print $s, "\n" if (length $s != 0);
print <<EOT;
$0 <file>
This script traces renames to find the origin of the file
EOT
exit(1);
}
^ permalink raw reply
* Re: git-filehistory (3rd try at detecting renames)
From: David Ho @ 2005-10-20 21:23 UTC (permalink / raw)
To: git
Sorry, once again, this calls git-diff-tree once per commit.
[davidho@penguin git-tutorial]$ cat git-filehistory.perl
#!/usr/bin/perl
use warnings;
use strict;
sub usage($);
# Sanity checks:
my $GIT_DIR = $ENV{'GIT_DIR'} || ".git";
unless ( -d $GIT_DIR && -d $GIT_DIR . "/objects" &&
-d $GIT_DIR . "/objects/" && -d $GIT_DIR . "/refs") {
usage("Git repository not found.");
}
usage("") if scalar @ARGV != 1;
my ($file) = @ARGV;
unless (-f $file) {
usage("git filehistory: '$file' does not exist");
}
open(F,"-|","git-rev-parse",,"--default","HEAD","--revs-only",$file);
my $git_rev_args = <F>;
chomp ($git_rev_args);
close (F);
open(F,"-|","git-rev-list", $git_rev_args);
my @commits = <F>;
close (F);
my $nextname = $file;
my (@renamecommit, @renamecomment, @renameentry);
for (my $i=0; $i < scalar @commits; $i++)
{
my $commit = $commits[$i];
chomp ($commit);
open (F, "-|","git-diff-tree","-r","-M","--pretty=medium",$commit);
@renamecommit = <F>;
close(F);
@renamecomment = grep /^[^:]/, @renamecommit;
@renameentry = grep /$nextname/, @renamecommit;
push @renamecomment, @renameentry;
if (scalar @renameentry) {
if ($renameentry[0] =~ /\t$nextname$/) {
foreach (@renamecomment) {
print;
}
}
if ($renameentry[0] =~ /R\d{3}\t(.+)\t(.+)/) {
#The file is renamed
$nextname = $1;
}
}
}
sub usage($) {
my $s = shift;
print $s, "\n" if (length $s != 0);
print <<EOT;
$0 <file>
This script traces renames to find the origin of the file
EOT
exit(1);
}
^ permalink raw reply
* Re: rsync update appears broken now
From: Linus Torvalds @ 2005-10-20 21:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <loom.20051020T220751-355@post.gmane.org>
On Thu, 20 Oct 2005, Junio C Hamano wrote:
>
> Having said that, all is not lost. Your message made it sound like the
> new head was completely re-rooted and there is no common commit (which
> almost gave me a heart attack), but I do not think it is that bad. It is
> more like pulling from two places.
No.
What you _must_ do to fix things up is that _you_ merge your current head
with your old head, and then you push out the result.
At that point:
> -----(A) head merlyn and everybody
> / pulled from kernel.org previously
> --- common ------------------------------------(B) head rebased and pushed
> out by mistake
You should have a (C) that is the merge of both A and B (or a later
commit, if you have other commits merged).
Now you can push out that merge, and everybody will be happy again:
they'll see somethign that is a proper superset of whichever HEAD they
happened to pull.
Don't make everybody else try to fix up your mistakes for you. It's easy
enough for you to just fix it up, and everybody else can just pull.
Of course, anybody who did a pull and then did the merge by hand will
always have their own private merge, and they should probably just undo
that. But undoing _private_ stuff is ok.
Linus
^ permalink raw reply
* Re: [PATCH] Do not send "want" lines for complete objects
From: Johannes Schindelin @ 2005-10-20 23:16 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0510201630000.25300@iabervon.org>
Hi,
On Thu, 20 Oct 2005, Daniel Barkalow wrote:
> On Thu, 20 Oct 2005, Johannes Schindelin wrote:
>
> > Hi,
> >
> > > > + ((o = parse_object(remote)) != NULL) &&
> > > > + (o->flags & COMPLETE) &&
> >
> > I just realized that parse_object() always reads the file, then does a
> > lookup (which makes the above code work), and then parses the file. It
> > always does all of these steps, even if the object was already parsed. Any
> > reason for this?
>
> I'm lazy and haven't sent in a patch to clean that up. There's no reason
> it couldn't check whether the value it gets is already parsed.
Actually, you don't have to... Junio already replaced parse_object() by
lookup_object() in this case. I did not use it originally, because lines
24-25 of commit.h say
/** Internal only **/
struct object *lookup_object(const unsigned char *sha1);
Is this obsolete?
Ciao,
Dscho
^ permalink raw reply
* Re: git-filehistory (3rd try at detecting renames)
From: Johannes Schindelin @ 2005-10-20 23:32 UTC (permalink / raw)
To: David Ho; +Cc: git
In-Reply-To: <4dd15d180510201423y5e200b68xec32bffec0f0cf84@mail.gmail.com>
Hi,
On Thu, 20 Oct 2005, David Ho wrote:
> Sorry, once again, this calls git-diff-tree once per commit.
How about detecting renames only when the tree does not have an object of
the same name? You could even use the pathspec optimizations to track just
that file through history, and do a git-diff-tree on the last commit
containing that file.
Ciao,
Dscho
^ permalink raw reply
* Re: Revamping the git protocol
From: Johannes Schindelin @ 2005-10-20 23:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0510201001460.3369@g5.osdl.org>
Hi,
On Thu, 20 Oct 2005, Linus Torvalds wrote:
> On Thu, 20 Oct 2005, H. Peter Anvin wrote:
> >
> > git over ssh seems to be the obvious choice.
>
> Yes, but Petr is right that there might be room for some lighter-weight
> "gits" secure protocol. One that doesn't necessarily require a whole user
> ID thing.
>
> For example, let's say that you're not the maintainer of your machine, but
> you're in an environment where you are allowed to run daemons as yourself
> (at a university, for example). And you have a group of people who want to
> work together at a project, but they don't want to give write permissions
> to the world or their bigger group (group "student").
If you are not maintainer, you could still start an SSH daemon which
listens on a port>1024 and gets its password data from a file different
from /etc/shadow (You could even use PAM...).
Ciao,
Dscho
^ permalink raw reply
* Re: rsync update appears broken now
From: Junio Hamano @ 2005-10-20 23:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0510201432260.10477@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> What you _must_ do to fix things up is that _you_ merge your current head
> with your old head, and then you push out the result.
Yes. That is what I will do when able (not right now).
I posted a workaround because I am at work and I do not have
access to kernel.org machine from here, and I did not pull
yesterday at work so I do not have an access to that lost side
branch until later today (I think I still have it in my private
repo, either on my home machine or my ~/git on hera).
> At that point:
>
>> -----(A) head merlyn and everybody
>> / pulled from kernel.org previously
>> --- common ------------------------------------(B) head rebased and pushed
>> out by mistake
Mind telling me the (A) commit ID if you know it?
^ permalink raw reply
* Re: rsync update appears broken now
From: Johannes Schindelin @ 2005-10-20 23:41 UTC (permalink / raw)
To: Junio Hamano; +Cc: Linus Torvalds, junkio, git
In-Reply-To: <7vek6f220h.fsf@arte.twinsun.com>
Hi,
On Thu, 20 Oct 2005, Junio Hamano wrote:
> > At that point:
> >
> >> -----(A) head merlyn and everybody
> >> / pulled from kernel.org previously
> >> --- common ------------------------------------(B) head rebased and pushed
> >> out by mistake
>
> Mind telling me the (A) commit ID if you know it?
ea5a65a59916503d2a14369c46b1023384d51645
Also, people having merged with (A) would not have to undo that merge as
was suggested. The new (C) commit would contain the revert of (A).
Ciao,
Dscho
^ permalink raw reply
* Re: rsync update appears broken now
From: Linus Torvalds @ 2005-10-20 23:47 UTC (permalink / raw)
To: Junio Hamano; +Cc: junkio, git
In-Reply-To: <7vek6f220h.fsf@arte.twinsun.com>
On Thu, 20 Oct 2005, Junio Hamano wrote:
>
> Mind telling me the (A) commit ID if you know it?
The latest one I have is ea5a65a59916503d2a14369c46b1023384d51645, but if
you had more pushed out at some point that I just didn't happen to pick
up, that may not be the top-most (A).
Linus
^ permalink raw reply
* Re: rsync update appears broken now
From: Linus Torvalds @ 2005-10-20 23:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio Hamano, junkio, git
In-Reply-To: <Pine.LNX.4.63.0510210140400.12723@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, 21 Oct 2005, Johannes Schindelin wrote:
>
> Also, people having merged with (A) would not have to undo that merge as
> was suggested. The new (C) commit would contain the revert of (A).
Oh, they'll need to revert if they want to match Junios history. Otherwise
they'll always generate yet another merge when they pull.
Doesn't matter that the _tree_ state may be the same, the only thing that
matters is that their history will be different, and thus they will never
be able to fast-forwared to Junio's tree unless they revert their local
merge.
Linus
^ permalink raw reply
* Re: rsync update appears broken now
From: Johannes Schindelin @ 2005-10-21 0:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio Hamano, junkio, git
In-Reply-To: <Pine.LNX.4.64.0510201647490.10477@g5.osdl.org>
Hi,
On Thu, 20 Oct 2005, Linus Torvalds wrote:
> On Fri, 21 Oct 2005, Johannes Schindelin wrote:
> >
> > Also, people having merged with (A) would not have to undo that merge as
> > was suggested. The new (C) commit would contain the revert of (A).
>
> Oh, they'll need to revert if they want to match Junios history. Otherwise
> they'll always generate yet another merge when they pull.
So?
> Doesn't matter that the _tree_ state may be the same, the only thing that
> matters is that their history will be different, and thus they will never
> be able to fast-forwared to Junio's tree unless they revert their local
> merge.
It does not have to be a fast-forward. After all, what is another merge?
Since that merge does not have Junio as committer, close inspection of
the commit will reveal that.
Of course, if you did not have local changes and merged, you might want to
do a clean "git-fetch kernel.org +master:parent".
So, no need for a revert.
Ciao,
Dscho
^ permalink raw reply
* git-rev-parse: pass on "--" flag when required
From: Linus Torvalds @ 2005-10-21 0:16 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
If rev-parse output includes both flags and files, we should pass on any
"--" marker we see, so that the end result can also tell the difference
between a flag and a filename that begins with '-'.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/rev-parse.c b/rev-parse.c
index 85230df..9ae2512 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -174,6 +174,9 @@ int main(int argc, char **argv)
if (*arg == '-') {
if (!strcmp(arg, "--")) {
as_is = 1;
+ /* Pass on the "--" if we show anything but files.. */
+ if (filter & (DO_FLAGS | DO_REVS))
+ show_file(arg);
continue;
}
if (!strcmp(arg, "--default")) {
^ permalink raw reply related
* Re: rsync update appears broken now
From: Linus Torvalds @ 2005-10-21 0:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio Hamano, junkio, git
In-Reply-To: <Pine.LNX.4.63.0510210157070.14563@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, 21 Oct 2005, Johannes Schindelin wrote:
> >
> > Oh, they'll need to revert if they want to match Junios history. Otherwise
> > they'll always generate yet another merge when they pull.
>
> So?
History matters. History matters as much as the data does.
> It does not have to be a fast-forward. After all, what is another merge?
> Since that merge does not have Junio as committer, close inspection of
> the commit will reveal that.
It _does_ have to be a fast-forward, if you expect the tree to have the
same content as Junio's.
Even if it merges everything automatically, if the history is different,
it could in theory at least merge _differently_ than what Junio had. Plus
you'll have a really ugly version history for no good reason.
But yes, it will _work_. It just won't work the way people expect it to,
so they'll make bug-reports about not being able to merge automatically,
and others will say that they can't re-create it and blame the wrong
person.
Linus
^ permalink raw reply
* Re: git-rev-parse: pass on "--" flag when required
From: Linus Torvalds @ 2005-10-21 0:24 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510201711380.10477@g5.osdl.org>
On Thu, 20 Oct 2005, Linus Torvalds wrote:
>
> If rev-parse output includes both flags and files, we should pass on any
> "--" marker we see, so that the end result can also tell the difference
> between a flag and a filename that begins with '-'.
Btw, if it wasn't obvious, this is also required to keep files and revs
separate.
I don't think we have anything that cares right now, but I'm working on
trying to get "git-rev-list" to limit its output to the files given on the
command line, and then I want to be able to do
gitk -- rev-list.c
and in my version of git-rev-list, the "--" is required to separate out
the revs from the names (since otherwise it's just too error-prone).
That requires that git-rev-parse not only honor "--", but pass it through
when the output can contain both revs/flags _and_ filenames.
Linus
^ permalink raw reply
* [PATCH 1/2] Brief documentation for the mysterious git-am script
From: Petr Baudis @ 2005-10-21 0:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The git-am script is nowhere called and nowhere (including itself)
explained, and the name isn't helpful either. For those like me who will
wonder what is it about, add some documentation stub for it to the
documentation.
I probably got something wrong and I don't feel like investigating all the
options - this is just kind of "emergency" docs.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-am.txt | 51 +++++++++++++++++++++++++++++++++++++++
Documentation/git-applymbox.txt | 2 +-
git-applymbox.sh | 2 ++
3 files changed, 54 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
new file mode 100644
index 0000000..c73a8c5
--- /dev/null
+++ b/Documentation/git-am.txt
@@ -0,0 +1,51 @@
+git-am(1)
+================
+
+NAME
+----
+git-am - Apply a series of patches in a mailbox
+
+
+SYNOPSIS
+--------
+'git-am' [--signoff] [--dotest=<dir>] [--utf8] [--3way] <mbox>
+'git-am' [--skip]
+
+DESCRIPTION
+-----------
+Splits mail messages in a mailbox into commit log message,
+authorship information and patches, and applies them to the
+current branch.
+
+This is the replacement for the 'git-applymbox' script.
+Unlike git-applymbox, it can take more than one mailbox file from
+the command line, as well as reading from the standard input when
+'-' is specified. Other differences include changed parameter names
+and less descriptive command name.
+
+
+When initially invoking it, you give it name of the mailbox to crunch.
+The usage hints that it might get interrupted and you will want to
+resume the last round of applying - to do that, pass it no mailbox
+name, and optionally the mysterious '--skip' parameter.
+
+
+SEE ALSO
+--------
+gitlink:git-applymbox[1], gitlink:git-applypatch[1].
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+This manual page is a stub. You can help the git documentation by expanding it.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-applymbox.txt b/Documentation/git-applymbox.txt
index 8f01ca6..f74c6a4 100644
--- a/Documentation/git-applymbox.txt
+++ b/Documentation/git-applymbox.txt
@@ -75,7 +75,7 @@ OPTIONS
SEE ALSO
--------
-gitlink:git-applypatch[1].
+gitlink:git-am[1], gitlink:git-applypatch[1].
Author
diff --git a/git-applymbox.sh b/git-applymbox.sh
index 4e77132..6de6932 100755
--- a/git-applymbox.sh
+++ b/git-applymbox.sh
@@ -15,6 +15,8 @@
## Pay a special attention to the commit log message if you do this and
## use a Signoff_file, because applypatch wants to append the sign-off
## message to msg-clean every time it is run.
+##
+## git-am is supposed to be the newer and better tool for this job.
. git-sh-setup || die "Not a git archive"
^ permalink raw reply related
* [PATCH 2/2] Update git-daemon's documentation wrt. new options
From: Petr Baudis @ 2005-10-21 0:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20051021002842.26819.56707.stgit@machine.or.cz>
New options --timeout, --init-timeout, --export-all and whitelist support
were added to git-daemon, but noone bothered to also add the proper
documentation. This patch aims to fix that.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-daemon.txt | 22 ++++++++++++++++++++--
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index a013a58..67c5f22 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -7,7 +7,8 @@ git-daemon - A really simple server for
SYNOPSIS
--------
-'git-daemon' [--verbose] [--syslog] [--inetd | --port=n]
+'git-daemon' [--verbose] [--syslog] [--inetd | --port=n] [--export-all]
+ [--timeout=n] [--init-timeout=n] [directory...]
DESCRIPTION
-----------
@@ -20,18 +21,35 @@ what directory to upload, and it verifie
It verifies that the directory has the magic file "git-daemon-export-ok", and
it will refuse to export any git directory that hasn't explicitly been marked
-for export this way.
+for export this way (unless the '--export-all' parameter is specified). If you
+pass some directory paths as 'git-daemon' arguments, you can further restrict
+the offers to a whitelist comprising of those.
This is ideally suited for read-only updates, ie pulling from git repositories.
OPTIONS
-------
+--export-all::
+ Allow pulling from all directories that look like GIT repositories
+ (have the 'objects' subdirectory and a 'HEAD' file), even if they
+ do not have the 'git-daemon-export-ok' file.
+
--inetd::
Have the server run as an inetd service.
--port::
Listen on an alternative port.
+--init-timeout::
+ Timeout between the moment the connection is established and the
+ client request is received (typically a rather low value, since
+ that should be basically immediate).
+
+--timeout::
+ Timeout for specific client sub-requests. This includes the time
+ it takes for the server to process the sub-request and time spent
+ waiting for next client's request.
+
--syslog::
Log to syslog instead of stderr. Note that this option does not imply
--verbose, thus by default only error conditions will be logged.
^ permalink raw reply related
* Re: rsync update appears broken now
From: Junio C Hamano @ 2005-10-21 0:26 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0510201645450.10477@g5.osdl.org>
Linus Torvalds <torvalds <at> osdl.org> writes:
> The latest one I have is ea5a65a59916503d2a14369c46b1023384d51645, but if
> you had more pushed out at some point that I just didn't happen to pick
> up, that may not be the top-most (A).
I am reasonably sure that the screw-up was only rewinding one commit too much.
I've done the merge so things should look better once mirrors catch up.
Thanks for your help.
^ 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