* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Andreas Ericsson @ 2006-04-19 8:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0604181745410.3701@g5.osdl.org>
Linus Torvalds wrote:
>
> On Tue, 18 Apr 2006, Linus Torvalds wrote:
>
>>And I thought we already disallowed ':' in branch names because cogito
>>uses them for the strange <rev>:<rev> syntax..
>
>
> Btw, pathnames with ':' in them aren't a problem. It's only revision
> names that can't have ':' in them and still be used together with this
> syntax.
>
> If you have a pathname with ':', it's fine to do
>
> git cat-file v1.2.4:pathname:with:colon
>
> because the magic revision parsing only cares about the _first_ colon, and
> will split that into "v1.2.4" and "pathname:with:colon" without ever even
> looking at the other ones.
>
Except that you'll have to explicitly state HEAD:pathname:with:colon, or
does it try finding a file with the argument verbatim first?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: cg-clone produces "___" file and no working tree
From: Junio C Hamano @ 2006-04-19 6:53 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20060419053640.GA16334@tumblerings.org>
Zack Brown <zbrown@tumblerings.org> writes:
> What is going on? I'm completely unable to clone a repository.
I have no idea how cg-* is broken, so I'll let Pasky answer
that, but I suspect your git installation is broken.
> If I try
> "git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git",
> I get this error: "git: 'clone' is not a git-command", and it prints a usage
> page, but "clone" is listed on that usage page.
That sounds intersting. Although rsync is deprecated for a long
time and git:// is the preferred transport, I do not get "is not
a git-command" error. Are you installing things correctly?
For example, as the first paragraph of INSTALL says, if you
override prefix= from the make command line, you need to do so
consistently when you build and when you install.
What do these command say?
$ git --exec-path
$ ls -l "`git --exec-path`/git-clone"
^ permalink raw reply
* cg-clone produces "___" file and no working tree
From: Zack Brown @ 2006-04-19 5:36 UTC (permalink / raw)
To: git
Hi folks,
I'm experiencing a problem that seems like it must be my fault, but I
can't figure it out. I'm using cogito-0.17.2-ga543f4f and git version
1.3.0.g2473-dirty.
When I do something like
cg-clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
The first few lines of output are:
defaulting to local storage area
warning: templates not found /home/zbrown/share/git-core/templates/
/home/zbrown/git/cogito/cg-clone: line 137: .git/info/cg-fetch-earlydie: No such file or directory
/home/zbrown/git/cogito/cg-clone: line 148: .git/info/cg-fetch-initial: No such file or directory
The rest of the process seems to go without incident. However, when I look
at the repository I see:
$ ls -A
.git ___
$
Then when I cat the "___" file, I see:
$ cat ___
This is a clone-in-progress GIT working tree containing a GIT repository
in the .git subdirectory. If you see this file and noone is fetching or
cloning in this repository, the clone has been interrupted; you can restart
it by issuing this command (it's enough as-is):
cg-fetch
$
I give the "cg-fetch" command as instructed, but it seems to have no effect,
and the "___" file remains unchanged.
What is going on? I'm completely unable to clone a repository. If I try
"git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git",
I get this error: "git: 'clone' is not a git-command", and it prints a usage
page, but "clone" is listed on that usage page.
I don't know what to make of this, and I don't see any other discussion of this
problem, so I assume it's my own fault, but I don't see what I might have done
wrong.
Be well,
Zack
--
Zack Brown
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY
From: Junio C Hamano @ 2006-04-19 5:00 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <4445C1D6.3070504@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Jörn Engel wrote:
>>
>> Excellent! I have a faint memory of hpa recently saying that the git
>> daemon would be too resource-hungry. One of the cases where being
>> wrong is a Good Thing.
>
> Well, we ended up making some tweaks to the git daemon, and it hasn't
> been a problem since.
Ah, I am glad the daemon expert was listening... Do you have
comments on recent patch from Serge E. Hallyn? It looks OK to
me, but that standalone daemon part is not something I run
myself, so...
-- >8 --
[PATCH] socksetup: don't return on set_reuse_addr() error
The set_reuse_addr() error case was the only error case in
socklist() where we returned rather than continued. Not sure
why. Either we must free the socklist, or continue. This patch
continues on error.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
daemon.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
0032d548db56eac9ea09b4ba05843365f6325b85
diff --git a/daemon.c b/daemon.c
index a1ccda3..776749e 100644
--- a/daemon.c
+++ b/daemon.c
@@ -535,7 +535,7 @@ #endif
if (set_reuse_addr(sockfd)) {
close(sockfd);
- return 0; /* not fatal */
+ continue;
}
if (bind(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
--
1.3.0.rc4.g5247-dirty
^ permalink raw reply related
* Re: GIT_OBJECT_DIRECTORY
From: H. Peter Anvin @ 2006-04-19 4:51 UTC (permalink / raw)
To: Jörn Engel; +Cc: Linus Torvalds, git
In-Reply-To: <20060418182650.GB25688@wohnheim.fh-wedel.de>
Jörn Engel wrote:
> On Tue, 18 April 2006 11:08:40 -0700, Linus Torvalds wrote:
>> On Tue, 18 Apr 2006, Jörn Engel wrote:
>>>> git clone git://git.kernel.org/... foo/
>>> Is it possible for non-owners of a kernel.org account to do this?
>> Yes, kernel.org runs the git daemon.
>
> Excellent! I have a faint memory of hpa recently saying that the git
> daemon would be too resource-hungry. One of the cases where being
> wrong is a Good Thing.
>
Well, we ended up making some tweaks to the git daemon, and it hasn't
been a problem since.
-hpa
^ permalink raw reply
* Re: Fix uninteresting tags in new revision parsing
From: Junio C Hamano @ 2006-04-19 4:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604182027460.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> When I unified the revision argument parsing, I introduced a simple bug
> wrt tags that had been marked uninteresting. When it was preparing for the
> revision walk, it would mark all the parent commits of an uninteresting
> tag correctly uninteresting, but it would forget about the commit itself.
Thanks. Can't believe I missed it...
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 4:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xq2ciws.fsf@assigned-by-dhcp.cox.net>
On Tue, 18 Apr 2006, Junio C Hamano wrote:
>
> A small fry in the ointment. What should the parts that are
> output with --name-only say for such a diff?
I have no idea, I have to say ;)
> Blob references like v0.99.6:git-commit-script are resolved by
> the extended SHA1 interpreter, and all what the caller of
> setup_revisions() can see and feed the diff machinery with has
> are their object names.
Actually, the names are there. The object list has the "->name" field
(used to do the name-based sorting), and we actually even fill it in for
the stuff we pass in as arguments. See the "add_pending_object()" calls
in setup_revisions().
We just don't use them right now. We _could_.
> Something like this is a possibility, but is ugly.
>
> diff --git a/a2455b0... b/01c73bd...
> index a2455b0..01c73bd 100644
> --- a/a2455b0...
> +++ b/01c73bd...
Yes. But if you look at the object list name (in the "pending_object"
thing), you _could_ actually get this to be something like
diff --git v0.99.6:git-commit-script git-commit.sh
index a2455b0..01c73bd 100644
--- v0.99.6:git-commit-script
+++ git-commit.sh
which would be much prettier, although I'm not saying it's necessarily
worth it. I'm just saying that it's _possible_ with the cmd line parsing
infrastructure we have now.
Linus
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 4:04 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0604182056390.3701@g5.osdl.org>
On Tue, 18 Apr 2006, Linus Torvalds wrote:
>
> And no, I didn't actually test it. But it really _should_ work with that
> trivial diff, including with the "a..b" format.
Ok, tested and verified.
On the kernel:
git diff v2.6.13:drivers/block/..HEAD:block/ -- ll_rw_blk.c
actually does the right thing - it shows the diff for ll_rw_blk.c which
got moved from drivers/block/ into block/ between 2.6.13 and current.
Note that the "--" is required, since ll_rw_blk.c doesn't exist in the
top-level directory where we run the command (but does exist in the git
trees that we have specified manually with the new shorthand).
Linus
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Junio C Hamano @ 2006-04-19 4:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604181836400.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Actually, it's not ambiguous. Just take the named file. If you want to
> diff it against HEAD:<named-file>, you should just say so.
>
> Now, if you _really_ want to be difficult, there's a third option: to diff
> it against the named file as named in the index. "git diff" does have the
> "--cached" option that would make that case unambiguous too, of course.
>
> Ie:
>
> (a) diff against the current HEAD:
>
> git diff v0.99.6:git-commit-script HEAD:git-commit.sh
>
> (b) diff against the current index contents for "git-commit.sh":
>
> git diff --cached v0.99.6:git-commit-script git-commit.sh
>
> (c) diff against a random file (which may not even be in the index):
>
> git diff v0.99.6:git-commit-script git-commit.sh
>
> are all sensible operations, and unambiguous.
A small fry in the ointment. What should the parts that are
output with --name-only say for such a diff?
Blob references like v0.99.6:git-commit-script are resolved by
the extended SHA1 interpreter, and all what the caller of
setup_revisions() can see and feed the diff machinery with has
are their object names. Something like this is a possibility,
but is ugly.
diff --git a/a2455b0... b/01c73bd...
index a2455b0..01c73bd 100644
--- a/a2455b0...
+++ b/01c73bd...
@@ -1,118 +1,509 @@
#!/bin/sh
#
# Copyright (c) 2005 Linus Torvalds
+# Copyright (c) 2006 Junio C Hamano
+
+USAGE='[-a] [-s] [-v] [--no-verify] [-m <message>...
+SUBDIRECTORY_OK=Yes
...
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 3:58 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <46a038f90604182051n4a16ee9atd2577d658befc335@mail.gmail.com>
On Wed, 19 Apr 2006, Martin Langhoff wrote:
>
> <wishlist>
> What about support for diffing a subtree?
>
> git diff v2.2:net/appletalk v2.9:net/appletalk-ng
>
> </whishlist>
Did you try it? It works as-is with that patch. Exactly because it will
call git-diff-tree with the two SHA1's, and since they are now trees (and
not blobs) git-diff-tree will do the right thing.
And no, I didn't actually test it. But it really _should_ work with that
trivial diff, including with the "a..b" format.
Linus
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Martin Langhoff @ 2006-04-19 3:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vd5fecpyd.fsf@assigned-by-dhcp.cox.net>
<wishlist>
What about support for diffing a subtree?
git diff v2.2:net/appletalk v2.9:net/appletalk-ng
</whishlist>
cheers,
martin
^ permalink raw reply
* Fix uninteresting tags in new revision parsing
From: Linus Torvalds @ 2006-04-19 3:31 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
When I unified the revision argument parsing, I introduced a simple bug
wrt tags that had been marked uninteresting. When it was preparing for the
revision walk, it would mark all the parent commits of an uninteresting
tag correctly uninteresting, but it would forget about the commit itself.
This means that when I just did my 2.6.17-rc2 release, and my scripts
generated the log for "v2.6.17-rc1..v2.6.17-rc2", everything was fine,
except the commit pointed to by 2.6.17-rc1 (which shouldn't have been
there) was included. Even though it should obviously have been marked as
being uninteresting.
Not a huge deal, and the fix is trivial.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/revision.c b/revision.c
index dbd54da..113dd5a 100644
--- a/revision.c
+++ b/revision.c
@@ -152,6 +152,7 @@ static struct commit *handle_commit(stru
if (parse_commit(commit) < 0)
die("unable to parse commit %s", name);
if (flags & UNINTERESTING) {
+ commit->object.flags |= UNINTERESTING;
mark_parents_uninteresting(commit);
revs->limited = 1;
}
^ permalink raw reply related
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 1:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5fecpyd.fsf@assigned-by-dhcp.cox.net>
On Tue, 18 Apr 2006, Junio C Hamano wrote:
> > git diff v0.99.6:git-commit-script git-commit.sh
> >
> > which parses as one SHA1 of a blob (put onto the rev.pending_objects
> > list), and one filename (in the rev.prune_data array). We could decide to
> > automatically do the "right thing" for that case too.
>
> The "right thing" is ambiguous, I am afraid.
>
> I think it would be natural to interpret the request as a diff
> between the blob from v0.99.6 and a random working tree file,
> which may not even exist in the index.
Actually, it's not ambiguous. Just take the named file. If you want to
diff it against HEAD:<named-file>, you should just say so.
Now, if you _really_ want to be difficult, there's a third option: to diff
it against the named file as named in the index. "git diff" does have the
"--cached" option that would make that case unambiguous too, of course.
Ie:
(a) diff against the current HEAD:
git diff v0.99.6:git-commit-script HEAD:git-commit.sh
(b) diff against the current index contents for "git-commit.sh":
git diff --cached v0.99.6:git-commit-script git-commit.sh
(c) diff against a random file (which may not even be in the index):
git diff v0.99.6:git-commit-script git-commit.sh
are all sensible operations, and unambiguous.
The only real downside is that the nice "a..b" syntax doesn't work for
them, except fot the very first case. That syntax requires both sides to
be SHA1 names (and while the "index" case could be a SHA1 name, we have no
way to say so).
> Oh, another possibility is to act as if the user said
>
> git diff v0.99.6:this :git-commit.sh
>
> where "(empty):" would stand for "look up in the index, not in a
> tree".
That would possibly be a nice extension, yes. But I really did mean
"random file, possibly not even in the index".
> Unfortunatly, I do not think this parses well:
>
> git diff git-commit.sh v0.99.6:git-commit-script
Correct. As you point out, that would have to be done with -R.
Linus
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Junio C Hamano @ 2006-04-19 1:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604181805080.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Now, the thing that an internal "git diff" could do better is to notice
> when it gets _one_ blob revision, and one filename, ie we could do
>
> git diff v0.99.6:git-commit-script git-commit.sh
>
> which parses as one SHA1 of a blob (put onto the rev.pending_objects
> list), and one filename (in the rev.prune_data array). We could decide to
> automatically do the "right thing" for that case too.
The "right thing" is ambiguous, I am afraid.
I think it would be natural to interpret the request as a diff
between the blob from v0.99.6 and a random working tree file,
which may not even exist in the index.
However I suspect what you are getting at is to act as if the
user said:
git diff v0.99.6:git-commit-script HEAD:git-commit.sh
Oh, another possibility is to act as if the user said
git diff v0.99.6:this :git-commit.sh
where "(empty):" would stand for "look up in the index, not in a
tree".
I think these are all valid interpretations and there are useful
use cases (admittably the last one is "diff-cache --cached").
Unfortunatly, I do not think this parses well:
git diff git-commit.sh v0.99.6:git-commit-script
but you could always say:
git diff -R v0.99.6:git-commit-script git-commit.sh
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Ray Lehtiniemi @ 2006-04-19 1:20 UTC (permalink / raw)
To: Shawn Pearce
Cc: Martin Langhoff, Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <20060419002159.GD8915@spearce.org>
one more lightweight vote in favor.... such a feature would eliminate a few
shell scripts i cobbled together which essentially allow me to say
git diff 8a6352:path/to/module 5f3461:moved/and/hacked/copy
On Tuesday 18 April 2006 18:21, Shawn Pearce wrote:
> Not that my voice carries much weight, but a coworker has been
> asking for this feature to be added to pg for months. I've just
> been too lazy to get around to writing the shell code to do it.
> Making it part of git cat-file seems like a good idea, making it
> usable by other tools like git diff just rocks. :-)
>
> I think its a very worthwhile addition.
>
> Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > On 4/19/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > > What do people think? Have you ever wanted to
> > > access individual files in some random revision? Do you think this is
> > > useful?
> >
> > Definitely, I've several times had to go through contortions to do
> > this easily, and I've ended up turning to gitweb often to quickly see
> > the state of a file at a given revision.
> >
> > > With this, you can do something like
> > >
> > > git cat-file blob v1.2.4:Makefile
> > >
> > > to get the contents of "Makefile" at revision v1.2.4.
> > >
> > > Now, this isn't necessarily something you really need all that often,
> > > but the concept itself is actually pretty powerful. We could, for
> > > example, allow things like
> > >
> > > git diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh
> >
> > These two examples are more than enough -- I buy ;-)
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 1:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604181805080.3701@g5.osdl.org>
On Tue, 18 Apr 2006, Linus Torvalds wrote:
>
> So if we added the test for "are the objects two commits" to git-diff-tree
> and diffed them directly, it would all "just work".
That "two commits" should obviously be "two blobs".
"Dave, my mind is going.. I can feel it.."
Linus
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 1:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsjecriu.fsf@assigned-by-dhcp.cox.net>
On Tue, 18 Apr 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > git diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh
>
> This is interesting.
>
> Yet to be born "internal diff". Should I start one, or are you
> already hacking on it?
I'm not working on it, but I might get back to it if nobody else beats me
to it.
Probably not in the next few days, though, so if you feel the urge, please
do look into it.
Anyway, the above syntax would actually work even with the current
external diff, because with my suggested patch we get:
git-rev-parse v0.99.6:git-commit-script..v1.3.0:git-commit.sh
resulting in
01c73bdd08e075d650e58664650bcd7fe1cd1551
^a2455b0f8ff1582248b0678b9c85b2f064d972c4
(which are just the SHA1's for the object), and then the external diff
will just see that it's two commits, so it decides to just feed them
directly into git-diff-tree.
So if we added the test for "are the objects two commits" to git-diff-tree
and diffed them directly, it would all "just work".
But you're certainly correct in stating that it would be _cleaner_ to do
it with a internal "git diff" command. Everything should be perfectly set
up by just calling the regular "setup_revisions()", and looking at the
"rev.pending_objects" list.
Now, the thing that an internal "git diff" could do better is to notice
when it gets _one_ blob revision, and one filename, ie we could do
git diff v0.99.6:git-commit-script git-commit.sh
which parses as one SHA1 of a blob (put onto the rev.pending_objects
list), and one filename (in the rev.prune_data array). We could decide to
automatically do the "right thing" for that case too.
Linus
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Junio C Hamano @ 2006-04-19 0:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604181627101.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> git diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh
This is interesting.
Yet to be born "internal diff". Should I start one, or are you
already hacking on it?
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 0:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604181735480.3701@g5.osdl.org>
On Tue, 18 Apr 2006, Linus Torvalds wrote:
>
> And I thought we already disallowed ':' in branch names because cogito
> uses them for the strange <rev>:<rev> syntax..
Btw, pathnames with ':' in them aren't a problem. It's only revision
names that can't have ':' in them and still be used together with this
syntax.
If you have a pathname with ':', it's fine to do
git cat-file v1.2.4:pathname:with:colon
because the magic revision parsing only cares about the _first_ colon, and
will split that into "v1.2.4" and "pathname:with:colon" without ever even
looking at the other ones.
Linus
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 0:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7y2csv8.fsf@assigned-by-dhcp.cox.net>
On Tue, 18 Apr 2006, Junio C Hamano wrote:
>
> Yes, I wanted to do this myself for a while. The only issue I
> might have is what the separator character between rev and path
> should be.
I didn't put a lot of thought into it, but using ':' not only is pretty
visually pleasing, it also means that shell completion automatically works
at least on bash, even without any git-specific completion rules.
That's not true for a lot of other special characters: colon really is
special, exactly because it has been used for things like PATH separators,
etc.
I'm a total filename completion junkie - I simply cannot type in a
filename any more. I'll literally press <tab> to complete even short
filenames, just because it gives me that nice confirmation of the
existence of the filename (ie I've typed it all in, and the <tab> adds the
space after the filename).
So to me, ':' is just clearly superior. I can't think of any other
separator that works with filename completion and has no shell issues,
_and_ looks logical.
And I thought we already disallowed ':' in branch names because cogito
uses them for the strange <rev>:<rev> syntax..
Linus
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Junio C Hamano @ 2006-04-19 0:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604181627101.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> [ NOTE! The reason I put "RFC" in the subject rather than "PATCH" is that
> I'm not 100% sure this isn't just a "shiny object" of mine rather than a
> really useful thing to do. What do people think? Have you ever wanted to
> access individual files in some random revision? Do you think this is
> useful? I think it's cool and _may_ be useful, but I'm not going to
> really push this patch. Consider it a throw-away patch unless somebody
> else finds it intriguing enough.. ]
Yes, I wanted to do this myself for a while. The only issue I
might have is what the separator character between rev and path
should be.
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Shawn Pearce @ 2006-04-19 0:21 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <46a038f90604181714j6fce1867wc17952d898f8e7ae@mail.gmail.com>
Not that my voice carries much weight, but a coworker has been
asking for this feature to be added to pg for months. I've just
been too lazy to get around to writing the shell code to do it.
Making it part of git cat-file seems like a good idea, making it
usable by other tools like git diff just rocks. :-)
I think its a very worthwhile addition.
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 4/19/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> > What do people think? Have you ever wanted to
> > access individual files in some random revision? Do you think this is
> > useful?
>
> Definitely, I've several times had to go through contortions to do
> this easily, and I've ended up turning to gitweb often to quickly see
> the state of a file at a given revision.
>
> > With this, you can do something like
> >
> > git cat-file blob v1.2.4:Makefile
> >
> > to get the contents of "Makefile" at revision v1.2.4.
> >
> > Now, this isn't necessarily something you really need all that often, but
> > the concept itself is actually pretty powerful. We could, for example,
> > allow things like
> >
> > git diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh
>
> These two examples are more than enough -- I buy ;-)
--
Shawn.
^ permalink raw reply
* [PATCH] Document git-clone --reference
From: Shawn Pearce @ 2006-04-19 0:19 UTC (permalink / raw)
To: git; +Cc: dwmw2
In-Reply-To: <20060418235658.GB8915@spearce.org>
The new --reference flag introduced to git-clone in
GIT 1.3.0 was not documented but is rather handy.
So document it.
Also corrected a minor issue with the documentation for the
-s flag; the info/alternates file name was spelled wrong.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Shawn Pearce <spearce@spearce.org> wrote:
> git clone --reference=/foo git://remote/foo
>
> would do the trick. This is new in 1.3.0. I just noticed its also
> not documented in 1.3.0. :-)
Documentation/git-clone.txt | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
base 6625864c8ce9868ba4ab41165d97084f3f04bbed
last 66a5bd88d2a8d9d64d86733852fbaba9caa756b0
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 9ac54c2..131e445 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -10,6 +10,7 @@ SYNOPSIS
--------
[verse]
'git-clone' [-l [-s]] [-q] [-n] [--bare] [-o <name>] [-u <upload-pack>]
+ [--reference <repository>]
<repository> [<directory>]
DESCRIPTION
@@ -46,10 +47,18 @@ OPTIONS
-s::
When the repository to clone is on the local machine,
instead of using hard links, automatically setup
- .git/objects/info/alternatives to share the objects
+ .git/objects/info/alternates to share the objects
with the source repository. The resulting repository
starts out without any object of its own.
+--reference <repository>::
+ If the reference repository is on the local machine
+ automatically setup .git/objects/info/alternates to
+ obtain objects from the reference repository. Using
+ an already existing repository as an alternate will
+ require less objects to be copied from the repository
+ being cloned, reducing network and local storage costs.
+
--quiet::
-q::
Operate quietly. This flag is passed to "rsync" and
@@ -112,6 +121,16 @@ Make a local clone that borrows from the
------------
+Clone from upstream while borrowing from an existing local directory::
++
+------------
+$ git clone --reference my2.6 \
+ git://git.kernel.org/pub/scm/.../linux-2.7 \
+ my2.7
+$ cd my2.7
+------------
+
+
Create a bare repository to publish your changes to the public::
+
------------
--
1.3.0.rc4.g8060
^ permalink raw reply related
* Re: [PATCH] git-svnimport symlink support
From: Martin Langhoff @ 2006-04-19 0:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Karl Hasselström, Martin Langhoff, Matthias Urlichs,
Herbert Valerio Riedel, git
In-Reply-To: <7v3bgcngqc.fsf@assigned-by-dhcp.cox.net>
On 4/18/06, Junio C Hamano <junkio@cox.net> wrote:
> Karl, Martin, Smurf, Comments?
+1 but bear in mind that I am not learned in the ways of the SVN specials...
martin
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Martin Langhoff @ 2006-04-19 0:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0604181627101.3701@g5.osdl.org>
On 4/19/06, Linus Torvalds <torvalds@osdl.org> wrote:
> What do people think? Have you ever wanted to
> access individual files in some random revision? Do you think this is
> useful?
Definitely, I've several times had to go through contortions to do
this easily, and I've ended up turning to gitweb often to quickly see
the state of a file at a given revision.
> With this, you can do something like
>
> git cat-file blob v1.2.4:Makefile
>
> to get the contents of "Makefile" at revision v1.2.4.
>
> Now, this isn't necessarily something you really need all that often, but
> the concept itself is actually pretty powerful. We could, for example,
> allow things like
>
> git diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh
These two examples are more than enough -- I buy ;-)
martin
^ 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