* Re: Mercurial 0.4e vs git network pull
From: Petr Baudis @ 2005-05-15 12:40 UTC (permalink / raw)
To: Adam J. Richter; +Cc: mpm, git, jgarzik, linux-kernel, mercurial, torvalds
In-Reply-To: <200505151122.j4FBMJa01073@adam.yggdrasil.com>
Dear diary, on Sun, May 15, 2005 at 01:22:19PM CEST, I got a letter
where "Adam J. Richter" <adam@yggdrasil.com> told me that...
> On Sun, 15 May 2005 10:54:05 +0200, Petr Baudis wrote:
> >Dear diary, on Thu, May 12, 2005 at 10:57:35PM CEST, I got a letter
> >where Matt Mackall <mpm@selenic.com> told me that...
> >> Does this need an HTTP request (and round trip) per object? It appears
> >> to. That's 2200 requests/round trips for my 800 patch benchmark.
>
> >Yes it does. On the other side, it needs no server-side CGI. But I guess
> >it should be pretty easy to write some kind of server-side CGI streamer,
> >and it would then easily take just a single HTTP request (telling the
> >server the commit ID and receiving back all the objects).
>
> I don't understand what was wrong with Jeff Garzik's previous
> suggestion of using http/1.1 pipelining to coalesce the round trips.
> If you're worried about queuing too many http/1.1 requests, the client
> could adopt a policy of not having more than a certain number of
> requests outstanding or perhaps even making a new http connection
> after a certain number of requests to avoid starving other clients
> when the number of clients doing one of these transfers exceeds the
> number of threads that the http server uses.
The problem is that to fetch a revision tree, you have to
send request for commit A
receive commit A
look at commit A for list of its parents
send request for the parents
receive the parents
look inside for list of its parents
...
(and same for the trees).
> Being able to do without a server side CGI script might
> encourage deployment a bit more, both for security reasons and
> effort of deployment.
You could still use it without the server side CGI script as it is now,
just without the speedups.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Mercurial 0.4e vs git network pull
From: Adam J. Richter @ 2005-05-15 11:52 UTC (permalink / raw)
To: pasky; +Cc: git, jgarzik, linux-kernel, mercurial, mpm, torvalds
On Sun, 15 May 2005 14:40:42 +0200, Petr Baudis wrote:
>Dear diary, on Sun, May 15, 2005 at 01:22:19PM CEST, I got a letter
>where "Adam J. Richter" <adam@yggdrasil.com> told me that...
[...]
>> I don't understand what was wrong with Jeff Garzik's previous
>> suggestion of using http/1.1 pipelining to coalesce the round trips.
>> If you're worried about queuing too many http/1.1 requests, the client
>> could adopt a policy of not having more than a certain number of
>> requests outstanding or perhaps even making a new http connection
>> after a certain number of requests to avoid starving other clients
>> when the number of clients doing one of these transfers exceeds the
>> number of threads that the http server uses.
>The problem is that to fetch a revision tree, you have to
> send request for commit A
> receive commit A
> look at commit A for list of its parents
> send request for the parents
> receive the parents
> look inside for list of its parents
> ...
>(and same for the trees).
Don't you usually have a list of many files for which you
want to retrieve this information? I'd imagine that would usually
suffice to fill the pipeline.
__ ______________
Adam J. Richter \ /
adam@yggdrasil.com | g g d r a s i l
^ permalink raw reply
* version 0.91 of gitk out now
From: Paul Mackerras @ 2005-05-15 13:11 UTC (permalink / raw)
To: git
I have just put version 0.91 of gitk on ozlabs.org at:
http://ozlabs.org/~paulus/gitk-0.91
(that's the actual script, just wget it and run it).
New features in version 0.91 include a menu bar, a widget to show the
SHA1 id of the selected commit, a find facility for searching for
commits, better error handling, and the ability to increase and
decrease the font size with control-KP+ and control-KP- (and
control-equal and control-minus).
Gitk is a commit viewer written in Tcl/Tk. Its main features are a
compact and clear representation of the commit graph and the fact that
it shows the headline, author and date of each commit in the summary
window, allowing developers to scan quickly through a large number of
commits and home in on the ones of interest to them. When a commit is
selected, the full commit message is shown, along with the colorized
diff for commits that have one parent.
Apart from the -b (use bold font for names), -c (color the commit
graph according the the committer) and -d (order commits by date)
options, all other arguments to gitk are passed to git-rev-tree to
allow the user to specify which commits to display.
Paul.
^ permalink raw reply
* Re: Mercurial 0.4e vs git network pull
From: Petr Baudis @ 2005-05-15 14:23 UTC (permalink / raw)
To: Adam J. Richter; +Cc: git, jgarzik, linux-kernel, mercurial, mpm, torvalds
In-Reply-To: <200505151152.j4FBqoW01239@adam.yggdrasil.com>
Dear diary, on Sun, May 15, 2005 at 01:52:50PM CEST, I got a letter
where "Adam J. Richter" <adam@yggdrasil.com> told me that...
> On Sun, 15 May 2005 14:40:42 +0200, Petr Baudis wrote:
> >Dear diary, on Sun, May 15, 2005 at 01:22:19PM CEST, I got a letter
> >where "Adam J. Richter" <adam@yggdrasil.com> told me that...
> [...]
> >> I don't understand what was wrong with Jeff Garzik's previous
> >> suggestion of using http/1.1 pipelining to coalesce the round trips.
> >> If you're worried about queuing too many http/1.1 requests, the client
> >> could adopt a policy of not having more than a certain number of
> >> requests outstanding or perhaps even making a new http connection
> >> after a certain number of requests to avoid starving other clients
> >> when the number of clients doing one of these transfers exceeds the
> >> number of threads that the http server uses.
>
> >The problem is that to fetch a revision tree, you have to
>
> > send request for commit A
> > receive commit A
> > look at commit A for list of its parents
> > send request for the parents
> > receive the parents
> > look inside for list of its parents
> > ...
>
> >(and same for the trees).
>
> Don't you usually have a list of many files for which you
> want to retrieve this information? I'd imagine that would usually
> suffice to fill the pipeline.
That might be true for the trees, but not for the commit lists. Most
commits have a single parent, except merges, which are however extremely
rare with more than two parents too.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: version 0.91 of gitk out now
From: Gene Heskett @ 2005-05-15 14:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17031.19069.345408.888580@cargo.ozlabs.ibm.com>
On Sunday 15 May 2005 09:11, Paul Mackerras wrote:
>I have just put version 0.91 of gitk on ozlabs.org at:
>
> http://ozlabs.org/~paulus/gitk-0.91
>
>(that's the actual script, just wget it and run it).
>
Been lurking here, waiting for an announcement of a snapshot of this
new gismo. I wgot it, and chmodded it to 0766, but got this when its
run:
[root@coyote git]# ./gitk-0.91
Error in startup script: can not find channel named "stder"
while executing
"puts stder "Error executing git-rev-tree: $err""
invoked from within
"if [catch {set commfd [open "|git-rev-tree $rargs" r]} err] {
puts stder "Error executing git-rev-tree: $err"
exit 1
}"
(procedure "getcommits" line 8)
invoked from within
"getcommits $revtreeargs"
(file "./gitk-0.91" line 993)
Typu?
>New features in version 0.91 include a menu bar, a widget to show
> the SHA1 id of the selected commit, a find facility for searching
> for commits, better error handling, and the ability to increase and
> decrease the font size with control-KP+ and control-KP- (and
> control-equal and control-minus).
>
>Gitk is a commit viewer written in Tcl/Tk. Its main features are a
>compact and clear representation of the commit graph and the fact
> that it shows the headline, author and date of each commit in the
> summary window, allowing developers to scan quickly through a large
> number of commits and home in on the ones of interest to them.
> When a commit is selected, the full commit message is shown, along
> with the colorized diff for commits that have one parent.
>
>Apart from the -b (use bold font for names), -c (color the commit
>graph according the the committer) and -d (order commits by date)
>options, all other arguments to gitk are passed to git-rev-tree to
>allow the user to specify which commits to display.
>
>Paul.
>-
>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
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply
* Re: README rewrite
From: Wink Saville @ 2005-05-15 15:30 UTC (permalink / raw)
Cc: git, zbrown
In-Reply-To: <4286F146.2090302@saville.com>
Wink Saville wrote:
> Zack Brown wrote:
>
> > Hi Petr,
> >
<snip>
> Actually looking in the repository I see that "origin" appears to be a
> "branch" not a revision, what is the relationship between a branch, tag
> and revision's? I have some experience with subversion and in subversion
> they are actually all the same, simply the state of a "sub-tree" within
> the repository at a particular "time". That time is defined by the
> repositories current revison number which is incremented after each
> succesful commit to the repository.
>
Zack,
I patched the README by hand this morning and read the explanation on cg-tag and it
appears branches, tags and revisions are synonymous, please correct me if I'm wrong.
Is there a way to use time or relative values (HEAD-1) as "revision" parameters, it would
be nice if its not already there.
Again, thanks for the update adds very useful information!
Wink
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005
^ permalink raw reply
* Re: README rewrite
From: Zack Brown @ 2005-05-15 15:17 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <4286F146.2090302@saville.com>
On Sat, May 14, 2005 at 11:50:46PM -0700, Wink Saville wrote:
> Zack,
>
> Good improvements, especially for neophytes like me who don't read enough
> and get confused when cg-init has the word DEPRECATED in its help:)
>
> Questions/Suggestions:
>
> 1) How do I actaully apply the patch supplied in the email, where
> readme.patch was the contents of the email. I tried as below, but that
> didn't work.
>
> wink@tuxws cogito-0.10 $ cg-patch < readme.patch
> patching file README
> patch unexpectedly ends in middle of line
> Hunk #1 FAILED at 1.
> 1 out of 1 hunk FAILED -- saving rejects to file README.rej
Don't use cg-patch. Just go into the Cogit directory and do
patch -p0 < readme.patch
>
> I "read" the patch and would like to suggest some additional information
> regarding cg-pull and revisons. My understanding is that it pulls the new
> "change sets" from the "parent" to my repository. I then should be able to
> compare the differences as per:
>
> "Using cg-pull is useful for a variety of purposes, for instance if you
> want
> to construct a diff against the latest version of the upstream sources,
> but
> don't want those changes to disturb your ongoing work. cg-pull will
> update
> your .git directory with the history you need to construct your diff,
> without merging that history into your tree, potentially breaking your
> changes."
>
> But I don't know how to cg-diff after the cg-pull? Well as I was writing
> this it dawned on me that if I did a cg-pull I should try:
>
> cg-diff -r origin
>
> by golly it worked.
>
> So it appears a "cg-diff" with no parameters will show me the changes
> between my working tree and the "HEAD of my repository" and appears to be
> the same as cg-diff -r HEAD. ("working tree" appears to mean the contents
> of what I "see" and therefore includes my uncommitted changes and
> "Repository" refers to contents under .git. Is that correct?)
Yes.
>
> A "cg-diff -r origin" gives me the differences between my "working tree"
> and my "origin's" current state (as defined by previous "updates" plus any
> unmerged pull's and there could be several pulls without merges).
>
> Is the above correct?
Yes.
>
> Another area of confusion for me is what are revisions I think I understand
> what "origin" and "HEAD" are but how would I reference others? For instance
> how to cg-diff between the HEAD and the revision before HEAD (or the one 3
> days ago or ...)? Can "tags" be used as "revisions" (i.e. as "-r tag-xxx").
>
> Actually looking in the repository I see that "origin" appears to be a
> "branch" not a revision, what is the relationship between a branch, tag and
> revision's? I have some experience with subversion and in subversion they
> are actually all the same, simply the state of a "sub-tree" within the
> repository at a particular "time". That time is defined by the repositories
> current revison number which is incremented after each succesful commit to
> the repository.
I don't understand branches yet, but tags are just a cute name for a
revision. A revision is identified by the SHA1 hash ID, which is ugly to
type, so you create use a tag for revisions you want to make special use of,
like for new project releases.
Be well,
Zack
>
> Cheers,
>
> Wink
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005
>
> -
> 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
--
Zack Brown
^ permalink raw reply
* Re: version 0.91 of gitk out now
From: Kay Sievers @ 2005-05-15 15:40 UTC (permalink / raw)
To: Gene Heskett; +Cc: Paul Mackerras, git
In-Reply-To: <200505151045.23198.gene.heskett@verizon.net>
On Sun, 2005-05-15 at 10:45 -0400, Gene Heskett wrote:
> On Sunday 15 May 2005 09:11, Paul Mackerras wrote:
> >I have just put version 0.91 of gitk on ozlabs.org at:
> >
> > http://ozlabs.org/~paulus/gitk-0.91
> >
> >(that's the actual script, just wget it and run it).
> >
> Been lurking here, waiting for an announcement of a snapshot of this
> new gismo. I wgot it, and chmodded it to 0766, but got this when its
Funny mode mask! :)
> run:
> [root@coyote git]# ./gitk-0.91
> Error in startup script: can not find channel named "stder"
> while executing
> "puts stder "Error executing git-rev-tree: $err""
> invoked from within
> "if [catch {set commfd [open "|git-rev-tree $rargs" r]} err] {
> puts stder "Error executing git-rev-tree: $err"
Yes, this should be stderr. But that's not your problem. :)
> exit 1
> }"
> (procedure "getcommits" line 8)
> invoked from within
> "getcommits $revtreeargs"
> (file "./gitk-0.91" line 993)
>
> Typu?
You miss the right git binaries. Is git-rev-tree in your $PATH? Do you
have the "new" git binaries starting with git-*?
Kay
^ permalink raw reply
* Re: [PATCH 0/4] Pulling refs files
From: Daniel Barkalow @ 2005-05-15 15:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git, Linus Torvalds
In-Reply-To: <7v4qd5xdby.fsf@assigned-by-dhcp.cox.net>
On Sat, 14 May 2005, Junio C Hamano wrote:
> I am having a bit hard time understanding how the end user uses
> what you are trying to give them. Is the basic idea to let them
> say "I want to get Pasky's $GIT_DIR/refs/heads/master and store
> it in my $GIT_DIR/refs/heads/git-pb, and then I want to start
> the pull starting from the commit recorded in that ref"?
Yes. This would be: git-http-pull -w heads/git-pb heads/master
http://www.kernel.org/pub/scm/cogito/git-pb.git/
> Assuming that is what you are doing, I do not have much
> objection to it. I however think introducing REFS_ENVIRONMENT
> is going overboard.
Now that we have GIT_DIR, you're probably right. I mainly kept it there
for symmetry. On the other hand, I think that, if you're using a shared
objects directory, you want to also use a shared refs directory, or you'll
never be able to identify unreachable objects accurately.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: README rewrite
From: Zack Brown @ 2005-05-15 15:40 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <42876B30.1070404@saville.com>
On Sun, May 15, 2005 at 08:30:56AM -0700, Wink Saville wrote:
> Wink Saville wrote:
> >Zack Brown wrote:
> >
> > > Hi Petr,
> > >
>
> <snip>
>
> >Actually looking in the repository I see that "origin" appears to be a
> >"branch" not a revision, what is the relationship between a branch, tag
> >and revision's? I have some experience with subversion and in subversion
> >they are actually all the same, simply the state of a "sub-tree" within
> >the repository at a particular "time". That time is defined by the
> >repositories current revison number which is incremented after each
> >succesful commit to the repository.
> >
>
>
> Zack,
>
> I patched the README by hand this morning and read the explanation on
> cg-tag and it appears branches, tags and revisions are synonymous, please
> correct me if I'm wrong.
I think that's wrong:
revision: a particular state of the tree, identified by an SHA1 hash ID
tag: a revision with a cute name
branch: a code fork, identified by name
As I understand it, a tag refers to a specific revision, and so when you use a
tag's name, you are referring only to that revision. A branch is different. When
you use a branch's name, you are referring to all the development that has
occurred in that branch.
So, when the 2.6.12 kernel comes out, Greg and Chris may decide to create a
fork for 2.6.12.x stablization. So linux and linux_2.6.12.x will be seperate
development branches in the same development tree. Patches and revisions
going into the 2.6.12.x branch will not be reflected in the 2.6.12 branch. The
two branches will diverge.
At the same time, unlike tags, their names will remain the same. With each new
revision, the linux_2.6.12.x branch will still refer to that branch with that
new revision. In the case of tagging, the tag name refers only to a single
revision that took place at a specific point in the history of the tree or
branch.
This much I think I understand. What I don't understand is how to actually use
branches. I don't see a Cogito command to create or destroy them.
>
> Is there a way to use time or relative values (HEAD-1) as "revision"
> parameters, it would be nice if its not already there.
As far as I know, you use only the SHA1 hash ID or a tag name to identify
revisions. Special cases like HEAD are the exceptions.
Be well,
Zack
>
> Again, thanks for the update adds very useful information!
>
> Wink
>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005
>
> -
> 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
--
Zack Brown
^ permalink raw reply
* Re: [PATCH 4/4] Pulling refs by ssh
From: Daniel Barkalow @ 2005-05-15 15:48 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Petr Baudis, git, Linus Torvalds
In-Reply-To: <4284F909.9000309@zytor.com>
On Fri, 13 May 2005, H. Peter Anvin wrote:
> Use && rather than semicolon, and make sure you quote things that need
> to be quoted.
This is a separate issue from the change for refs; could you send a patch
that quotes things properly? The "cd" should be unnecessary now that we
have the GIT_DIR environment variable.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: README rewrite
From: Zack Brown @ 2005-05-15 15:53 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <20050515154041.GD7391@tumblerings.org>
On Sun, May 15, 2005 at 08:40:41AM -0700, Zack Brown wrote:
> This much I think I understand. What I don't understand is how to actually use
> branches. I don't see a Cogito command to create or destroy them.
Or I'm blind. The cg-branch-add command is right there. It also has a long
comment at the top of the script. Unfortunately the comment only describes how
to use the command, not what exactly branches are or how to work with them.
Clearly 'branches' are diverging branches of development. But if I have my
own tree, with several branches in it, it's unclear to me how to specify
which branch I'm actually working on at any given moment.
Be well,
Zack
--
Zack Brown
^ permalink raw reply
* Re: speeding up cg-log -u
From: Daniel Barkalow @ 2005-05-15 16:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Zack Brown, git, Linus Torvalds
In-Reply-To: <7vk6m212g7.fsf@assigned-by-dhcp.cox.net>
On Sat, 14 May 2005, Junio C Hamano wrote:
> Whenever I work with those "struct object" derivatives, I get
> very frustrated by the fact that they are designed to cater only
> to the need of very narrow immediate users.
They aren't designed for the immediate users; they're implemented for the
immediate users. Feel free to add more fields as you need them. The
current selection is based on only adding things when there's a user for
them.
> The first round of tree objects did not even have names for each entry
> because the only thing it cared about was connectivity checking, and for
> that purpose callers would not care about what each blob or
> subtree was referred as. Now when I want to use commit objects
> I find that it only records the commit date (other than
> connectivity information). It really appears that connectivity
> is the primary thing and everything else is bolted on top.
Existance is the primary thing, and everything else was added as
needed. (Pure connectivity is a bit special, because it's a property of
generic objects so that fsck-cache doesn't need to know about particular
types of objects unless there are particular things to check about them)
If you need more fields, let me know, and I'll figure out how to include
them.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: README rewrite
From: Petr Baudis @ 2005-05-15 17:28 UTC (permalink / raw)
To: Zack Brown; +Cc: Wink Saville, git
In-Reply-To: <20050515155315.GE7391@tumblerings.org>
Dear diary, on Sun, May 15, 2005 at 05:53:15PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> On Sun, May 15, 2005 at 08:40:41AM -0700, Zack Brown wrote:
> > This much I think I understand. What I don't understand is how to actually use
> > branches. I don't see a Cogito command to create or destroy them.
>
> Or I'm blind. The cg-branch-add command is right there. It also has a long
> comment at the top of the script. Unfortunately the comment only describes how
> to use the command, not what exactly branches are or how to work with them.
>
> Clearly 'branches' are diverging branches of development. But if I have my
> own tree, with several branches in it, it's unclear to me how to specify
> which branch I'm actually working on at any given moment.
I think it's actually very BKish. Each repository has its own "master"
branch, which always corresponds with your current branch of
development. That is, your working tree is always represented by the
"master" branch.
The rest of branches are "remote", that is they just point at the other
repositories. When you want to get the new changes from them, you
cg-pull, or cg-update to merge them to your branch too.
So if you want to create a new branch, you cg-clone the original branch.
And if you want to refer to the new branch in any other branch, you
cg-branch-add it in the other branch.
So the local branch is the "master" branch, the rest are "remote"
branches. Note that there is a theoretical support for multiple local
branches, but I decided not to make things even more confusing and there
is no Cogito interface for managing them now.
I will add cg-switch which will switch the master branch to some other
branch (e.g. cg-switch linus will rename your current master to
master-1234 or something, update your "origin" branch to point to the
"linus" branch, and make your "master" branch to point at the same
commit as the "origin" branch). I might also do something like
cg-branch-add --local, which will add a local branch and you could then
cg-switch to it too.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: README rewrite
From: Matthias Urlichs @ 2005-05-15 17:33 UTC (permalink / raw)
To: git
In-Reply-To: <20050515155315.GE7391@tumblerings.org>
Hi, Zack Brown wrote:
> Clearly 'branches' are diverging branches of development. But if I have my
> own tree, with several branches in it, it's unclear to me how to specify
> which branch I'm actually working on at any given moment.
>
Branches == multiple source directories. You work on the branch whose
directory you're in. This is why there's no cg-branch-switch command.
cg-branch-add doesn't actually add or create a branch. It just tells
cogito your name for one other branch, plus its location so that you may
pull the branch's data from there.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ permalink raw reply
* Re: [PATCH cogito] "cg-whatsnew" command
From: Matthias Urlichs @ 2005-05-15 17:36 UTC (permalink / raw)
To: git
In-Reply-To: <tnx3bsoki2j.fsf@arm.com>
Hi, Catalin Marinas wrote:
> + cg-diff [-p] [-r FROM_ID[:TO_ID]] [-m [BNAME] [BNAME]] [FILE]...
That should be
[-m [BNAME [BNAME]]]
though I'd suggest something more mnemonic than two BNAMEs.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ permalink raw reply
* Re: Mercurial 0.4e vs git network pull
From: Matt Mackall @ 2005-05-15 17:39 UTC (permalink / raw)
To: Adam J. Richter; +Cc: pasky, git, jgarzik, linux-kernel, mercurial, torvalds
In-Reply-To: <200505151122.j4FBMJa01073@adam.yggdrasil.com>
On Sun, May 15, 2005 at 04:22:19AM -0700, Adam J. Richter wrote:
> On Sun, 15 May 2005 10:54:05 +0200, Petr Baudis wrote:
> >Dear diary, on Thu, May 12, 2005 at 10:57:35PM CEST, I got a letter
> >where Matt Mackall <mpm@selenic.com> told me that...
> >> Does this need an HTTP request (and round trip) per object? It appears
> >> to. That's 2200 requests/round trips for my 800 patch benchmark.
>
> >Yes it does. On the other side, it needs no server-side CGI. But I guess
> >it should be pretty easy to write some kind of server-side CGI streamer,
> >and it would then easily take just a single HTTP request (telling the
> >server the commit ID and receiving back all the objects).
>
> I don't understand what was wrong with Jeff Garzik's previous
> suggestion of using http/1.1 pipelining to coalesce the round trips.
You can't do pipelining if you can't look ahead far enough to fill the pipe.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH] Resurrect diff-tree-helper -R
From: Junio C Hamano @ 2005-05-15 18:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20050515093040.GC13024@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> ... But what I dislike
PB> more is that the diff output is now visually inconsistent - some diffs
PB> are separated by a newline and some aren't.
That is already fixed in the second patch.
^ permalink raw reply
* [PATCH] Tweak diff output further to make it a bit less distracting.
From: Junio C Hamano @ 2005-05-15 18:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <7vr7g9uhsl.fsf@assigned-by-dhcp.cox.net>
Seriously...
Adds an newline between each diff. Also change "#mode : "
string, which was misleading in that we are not showing just
mode when we talk about a file changing into a symlink.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff.c | 18 ++++++++++--------
t/t4000-diff-format.sh | 6 ++++--
2 files changed, 14 insertions(+), 10 deletions(-)
--- a/diff.c
+++ b/diff.c
@@ -83,7 +83,7 @@
struct diff_tempfile *temp)
{
int i, next_at;
- const char *git_prefix = "# mode: ";
+ const char *git_prefix = "\n@. ";
const char *diff_cmd = "diff -L'%s%s' -L'%s%s'";
const char *diff_arg = "'%s' '%s'||:"; /* "||:" is to return 0 */
const char *input_name_sq[2];
@@ -128,15 +128,17 @@
else if (!path1[1][0])
printf("%s%s . %s\n", git_prefix, temp[0].mode, name);
else {
- if (strcmp(temp[0].mode, temp[1].mode))
+ if (strcmp(temp[0].mode, temp[1].mode)) {
printf("%s%s %s %s\n", git_prefix,
temp[0].mode, temp[1].mode, name);
-
- if (strncmp(temp[0].mode, temp[1].mode, 3))
- /* we do not run diff between different kind
- * of objects.
- */
- exit(0);
+ if (strncmp(temp[0].mode, temp[1].mode, 3))
+ /* we do not run diff between different kind
+ * of objects.
+ */
+ exit(0);
+ }
+ else
+ putchar('\n');
}
fflush(NULL);
execlp("/bin/sh","sh", "-c", cmd, NULL);
--- a/t/t4000-diff-format.sh
+++ b/t/t4000-diff-format.sh
@@ -26,7 +26,8 @@
'git-diff-files -p after editing work tree.' \
'git-diff-files -p >current'
cat >expected <<\EOF
-# mode: 100644 100755 path0
+
+@. 100644 100755 path0
--- a/path0
+++ b/path0
@@ -1,3 +1,3 @@
@@ -34,7 +35,8 @@
Line 2
-line 3
+Line 3
-# mode: 100755 . path1
+
+@. 100755 . path1
--- a/path1
+++ /dev/null
@@ -1,3 +0,0 @@
------------------------------------------------
^ permalink raw reply
* Re: Mercurial 0.4e vs git network pull
From: Jeff Garzik @ 2005-05-15 18:23 UTC (permalink / raw)
To: Matt Mackall
Cc: Adam J. Richter, pasky, git, linux-kernel, mercurial, torvalds
In-Reply-To: <20050515173923.GK5914@waste.org>
Matt Mackall wrote:
> On Sun, May 15, 2005 at 04:22:19AM -0700, Adam J. Richter wrote:
>
>>On Sun, 15 May 2005 10:54:05 +0200, Petr Baudis wrote:
>>
>>>Dear diary, on Thu, May 12, 2005 at 10:57:35PM CEST, I got a letter
>>>where Matt Mackall <mpm@selenic.com> told me that...
>>>
>>>>Does this need an HTTP request (and round trip) per object? It appears
>>>>to. That's 2200 requests/round trips for my 800 patch benchmark.
>>
>>>Yes it does. On the other side, it needs no server-side CGI. But I guess
>>>it should be pretty easy to write some kind of server-side CGI streamer,
>>>and it would then easily take just a single HTTP request (telling the
>>>server the commit ID and receiving back all the objects).
>>
>> I don't understand what was wrong with Jeff Garzik's previous
>>suggestion of using http/1.1 pipelining to coalesce the round trips.
>
>
> You can't do pipelining if you can't look ahead far enough to fill the pipe.
Even if you cannot fill a pipeline, HTTP/1.1 is sufficiently useful
simply by removing the per-request connection overhead.
Jeff
^ permalink raw reply
* Request reverting some from git-pb
From: Junio C Hamano @ 2005-05-15 18:25 UTC (permalink / raw)
To: pasky; +Cc: git, torvalds
Petr, please do not do these name clean-ups yet, _especially_
without having GIT mailing list discussion about renaming. This
kind of change inevitably introduces merge conflicts.
I suspect this is something you lifted from the larger
libification patch. While I think name cleanups are good in the
long run, I do not see value in lifting only some name cleanups
from a larger libification patch and having people to adjust for
the merge conflicts twice. I would not mind if these renames
happen as a part of libification as a whole. Pending patches
need to be inspected and adjusted when that happens anyway. But
not until then, at least please have a courtecy to give people a
bit of warning and an opportunity to speak out.
------------------------------------------------
Rename some more cache-related functions
same_name -> ce_same_name()
remove_entry_at() -> remove_cache_entry_at()
Signed-off-by: Brad Roberts <braddr@puremagic.com>
Signed-off-by: Petr Baudis <pasky@ucw.cz>
------------------------------------------------
Rename cache_match_stat() to ce_match_stat()
Signed-off-by: Brad Roberts <braddr@puremagic.com>
Signed-off-by: Petr Baudis <pasky@ucw.cz>
------------------------------------------------
Rename cache_match_stat() to ce_match_stat()
Signed-off-by: Brad Roberts <braddr@puremagic.com>
Signed-off-by: Petr Baudis <pasky@ucw.cz>
------------------------------------------------
^ permalink raw reply
* Request reverting some from git-pb
From: Junio C Hamano @ 2005-05-15 18:29 UTC (permalink / raw)
To: pasky; +Cc: git, torvalds
Petr, you added two small patches to git-pb recently.
* Rename some more cache-related functions
* Rename cache_match_stat() to ce_match_stat()
I would really appreciate if you do not do these name clean-ups
yet, _especially_ not without having GIT mailing list discussion
about it first. This kind of changes inevitably introduce merge
conflicts.
I suspect this is something you lifted from a larger
libification patch. While I think name cleanups are good in the
long run, I do not see value in lifting only some name cleanups
from the libification patch and having people to adjust for the
merge conflicts twice (now and when libification is ready to be
included). I would not mind if these renames happen as a part
of libification as a whole. Pending patches need to be
inspected and adjusted when that happens anyway. But not until
then, at least please have a courtesy to give people a warning
and an opportunity to speak out.
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Brad Roberts @ 2005-05-15 19:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: Juliusz Chroboczek, git
In-Reply-To: <20050515114847.GD13024@pasky.ji.cz>
> Date: Sun, 15 May 2005 13:48:47 +0200
> From: Petr Baudis <pasky@ucw.cz>
> To: Brad Roberts <braddr@puremagic.com>
> Cc: Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>,
> git@vger.kernel.org
> Subject: Re: Darcs-git: a few notes for Git hackers
>
> Dear diary, on Sun, May 15, 2005 at 04:04:25AM CEST, I got a letter
> where Brad Roberts <braddr@puremagic.com> told me that...
> > > I wasn't able to finish redoing these against linus tip, but I got most of
> > > it done (patches 1-14 of the original 19):
> > >
> > > http://gameboy2.puremagic.com:8090/
> > > rsync://gameboy2.puremagic.com/git/
> > >
> > > The second, third, and forth to last changes need a careful review,
> > > they're direct applications of the original patches which were lightly
> > > tested during the first round and nothing other than compile tested in
> > > this round.
> > >
> > > I suspect the remaining parts of the original patch series will go in
> > > fairly smoothly. If no one gets to them before tonight I'll finish
> > > it up after work.
> > >
> > > Later,
> > > Brad
> >
> > I've completed the re-merge, and moved to tip of git-pb.git rather than
> > tip of git.git. Unfortunatly that merge was also somewhat intrusive and
> > my individual diffs along the way are somewhat useless now. The entire
> > history is available about the above locations still. Attached is the
> > full diff vs git-pb @ 902b92e00e491a60d55c4b2bce122903b8347f34.
>
> I've merged some of the minor stuff for now.
Cool, though there appears to have been some objections. :)
> > 2) Should the index changing areas be constructing a new index instead of
> > shuffling bits within the current index?
>
> When I have a big cache (the only time it matters), I do usually only
> relatively small changes to it, so...
The entire index is bit shuffled around even if nothing changed. At least
today, size and amount changed doesn't matter.
> > 3) The vocabulary and code is inconsistent between cache and index.
>
> Yes...
>
> > 4) read-cache.c does much more than reading.
>
> and yes. And cache.h is full of crap. Perhaps we could move read-cache.c
> to cache.c?
At least parts of it, probably yes.
> I'd imagine the plan of attack to continue by changing active_cache to
> be struct cache, then making it local.
Which is what the rest of that patch does.
Thanks for looking at this.
Later,
Brad
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Junio C Hamano @ 2005-05-15 19:25 UTC (permalink / raw)
To: Brad Roberts; +Cc: Petr Baudis, Juliusz Chroboczek, git
In-Reply-To: <Pine.LNX.4.44.0505151204230.2136-100000@bellevue.puremagic.com>
>>>>> "BR" == Brad Roberts <braddr@puremagic.com> writes:
>> I've merged some of the minor stuff for now.
BR> Cool, though there appears to have been some objections. :)
I do not have any problem with what the _patch_ does at all. I
had more trouble in the process of how the patch appeared in
git-pb tree, and I still do.
Please consider the revert request retracted. Request to
forewarn people in the mailing list still stands.
^ permalink raw reply
* Re: git-rev-list in local commit order
From: Thomas Gleixner @ 2005-05-15 19:48 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <4127.10.10.10.24.1116107046.squirrel@linux1>
On Sat, 2005-05-14 at 17:44 -0400, Sean wrote:
> Attached is a preliminary hackish patch to sort git-rev-list in local
> commit order.
+unsigned long sha1_local_date(const unsigned char *sha1)
+{
+ struct stat st;
+ if (find_sha1_file(sha1, &st))
+ return st.st_mtime;
+ return 0;
+}
Do you really want to base workflow and history information on file
times ?
File times are local and completely error prone in distributed
environments.
tglx
^ 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