* Re: documentation issues
From: Chuck Lever @ 2005-12-01 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64q8fqm8.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
Junio C Hamano wrote:
>>also, git-diff-index supports a "-r" option, but that doesn't seem to be
>>documented on this page.
>
>
> What Chris Shoemaker said is right.
>
> But we could do this instead if you want. I am neutral myself.
thanks for clarifying.
StGIT does use "git-diff-index -r" in git.__tree_status(). i think it
can be safely removed.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 445 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: git-ls-tree: add "-t" option to always show the tree entries
From: Junio C Hamano @ 2005-12-01 22:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512011354500.3099@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Maybe nobody else uses that "--name-only" thing.
I often use --name-status for diff, so that makes me nobody.
^ permalink raw reply
* Re: git-ls-tree: add "-t" option to always show the tree entries
From: Linus Torvalds @ 2005-12-01 21:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git
In-Reply-To: <7vlkz4friv.fsf@assigned-by-dhcp.cox.net>
On Thu, 1 Dec 2005, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > NOTE! This also means that it will show all trees leading up to that tree.
>
> ... which is logical but slightly unexpected. Also I noticed we
> lost '-d' but still accept it as an option, so...
Yes. I like the notion of doing
git-ls-tree -r -d HEAD
to get a full list of directories for the project.
That brings up another issue. I typed
git-ls-tree -r --name-only ..
and it obviously didn't work. That's kind of sad. I use that quite a lot
for "git diff", for example, because quite often I want to see the files,
but I don't care about anything else.
Maybe nobody else uses that "--name-only" thing.
Linus
^ permalink raw reply
* Re: documentation issues
From: Chris Shoemaker @ 2005-12-01 21:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: cel, git
In-Reply-To: <7v64q8fqm8.fsf@assigned-by-dhcp.cox.net>
On Thu, Dec 01, 2005 at 01:34:55PM -0800, Junio C Hamano wrote:
> > also, git-diff-index supports a "-r" option, but that doesn't seem to be
> > documented on this page.
>
> What Chris Shoemaker said is right.
>
> But we could do this instead if you want. I am neutral myself.
I think it is more clear without this, since we imply elsewhere that
diff-* accepts the options in diff-options.txt. Documenting "-r" in
the only place it applies (diff-tree) means we don't need exceptions
anywhere else.
Incidentally, I think it would make more sense if diff-tree defaulted
to recursive behavior and required a flag to produce non-recursive
behavior, but I realize that's impractical now, and only of minor
benefit.
-chris
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Randal L. Schwartz @ 2005-12-01 21:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, linux, git
In-Reply-To: <20051201215039.GX22159@pasky.or.cz>
>>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
Petr> I'm still perplexed and curious about what _did_ git-send-pack actually
Petr> receive as URL, since it apparnetly decided it's ssh as well.
Sorry... $work is swallowing my time right now. It's on my list
of "very important things to get back to sometime real soon".
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Petr Baudis @ 2005-12-01 21:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: linux, git, Randal L. Schwartz
In-Reply-To: <7vd5khjf9g.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Dec 01, 2005 at 11:14:19AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Speaking of shell gotchas, I do not know what the resolution was
> on the problem Merlyn was having the other day in "lost again on
> syntax change - local repository?" thread, which seemed that the
> failure described in <868xv86dam.fsf@blue.stonehenge.com> was
> his bash mishandling an if..then..elif..else..fi chain, which
> was sort of unexpected for me. I was curious but do not
> remember seeing the conclusion. Pasky, what happened to that
> thread?
I'm still perplexed and curious about what _did_ git-send-pack actually
receive as URL, since it apparnetly decided it's ssh as well.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH 6/7] Add a "--clone" option to "stg branch"
From: Chuck Lever @ 2005-12-01 21:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0512011305v3299f27au@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]
Catalin Marinas wrote:
> On 29/11/05, Chuck Lever <cel@netapp.com> wrote:
>
>>Cloning a branch means creating a new branch and copying all of the
>>original branch's patches and its base to it. Like creating a tag,
>>but this also preserves all the StGIT patches as well.
>
> [...]
>
>>--- a/stgit/commands/branch.py
>>+++ b/stgit/commands/branch.py
>
> [...]
>
>>+ print 'Cloning current branch to "%s"...' % clone
>
>
> I would put a comma after this line and add sys.stdout.flush(). So
> that 'done' is shown on the same line.
d'oh! that's left over from when the Series.clone() method actually
printed the name of each patch as it was cloning. fixed.
> [...]
>
>>--- a/stgit/stack.py
>>+++ b/stgit/stack.py
>
> [...]
>
>>+ def clone(self, target_series):
>>+ """Clones a series
>>+ """
>
>
> Wouldn't it be easier to do a recursive copy at the directory level
> (.git/patches/<branch> into .git/patches/<clone> and
> .git/refs/bases/<branch> into .git/refs/bases/<clone>)? Is there
> anything that could go wrong if we do this?
well, then you'd also clone any junk files that were left in there (for
example, development notes).
also, by doing this a patch at a time, it gives the ability to hook in
additional functionality in the future, in case we want to do something
special to each newly cloned patch, like mechanically change the patch
names, or automatically add some annotation, for example.
it also automatically converts an old-style branch (patches and series
control files in same directory) to a new-style branch (patches in
separate directory from series control files).
it follows the same basic pattern of logic as "stg pick". cloning a
branch is kind of like 'picking' all of it's patches into a new branch.
but finally (and most practically speaking), i hunted around for Python
code to copy a directory hierarchy, and interestingly enough it looks
about as complicated (or maybe more complicated) than the clone
implementation i finally came up with, which is only about 30 lines. i
suppose we could just do a "os.system('cp -r yada yada')" but that's
just lame ;^) and it only works on UNIX.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 445 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: documentation issues
From: Junio C Hamano @ 2005-12-01 21:34 UTC (permalink / raw)
To: cel; +Cc: git
In-Reply-To: <438F5D05.4080101@citi.umich.edu>
Chuck Lever <cel@citi.umich.edu> writes:
> in the man page for git-diff-index (posted here):
>
> http://www.kernel.org/pub/software/scm/git/docs/git-diff-tree.html
You mean git-diff-index.html, not diff-tree.html, I suppose.
> there are several references to "git-diff-tree" where it seems like
> "git-diff-index" is really meant.
Non-cached Mode
---------------
The "non-cached" mode takes a different approach, and is potentially
the more useful of the two in that what it does can't be emulated with
a "git-write-tree" + "git-diff-tree". Thus that's the default mode.
...
The non-cached version asks the question:
show me the differences between HEAD and the currently checked out
tree - index contents _and_ files that aren't up-to-date
which is obviously a very useful question too, since that tells you what
you *could* commit. Again, the output matches the "git-diff-tree -r"
output to a tee, but with a twist.
Linus does mean diff-tree here.
We had diff-files and diff-tree back then, but diff-index came
much later under the name diff-cache. He is explaining what
git-diff-index does in terms of git-diff-tree in this paragraph.
He could have said:
You *could* emulate it with first copying the index file
into a temporary file, git-update-index all the modified
paths in the working tree into that temporary index file and
git-write-tree that, and then run git-diff-tree.
but that is not practical.
> also, git-diff-index supports a "-r" option, but that doesn't seem to be
> documented on this page.
What Chris Shoemaker said is right.
But we could do this instead if you want. I am neutral myself.
-- >8 --
[PATCH] Documentation: mention -r for all commands from the diff family.
We did not mention 'git-diff-index' and friends take '-r' but
silently ignore it, because they always operate on the whole tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 6b496ed..7299903 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -58,5 +58,11 @@
Swap two inputs; that is, show differences from index or
on-disk file to tree contents.
+-r::
+ Recurse into sub-trees. Note that this makes difference
+ only with `git-diff-tree`. Other commands in the `git-diff-\*`
+ family always operate on the whole project tree and this
+ option is a no-op to them.
+
For more detailed explanation on these common options, see also
link:diffcore.html[diffcore documentation].
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 9a2947e..8f66119 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -33,9 +33,6 @@ include::diff-options.txt[]
Note that this parameter does not provide any wildcard or regexp
features.
--r::
- recurse into sub-trees
-
-t::
show tree entry itself as well as subtrees. Implies -r.
^ permalink raw reply related
* Re: git-ls-tree: add "-t" option to always show the tree entries
From: Junio C Hamano @ 2005-12-01 21:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Fredrik Kuivinen, git
In-Reply-To: <Pine.LNX.4.64.0512011022520.3099@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> NOTE! This also means that it will show all trees leading up to that tree.
... which is logical but slightly unexpected. Also I noticed we
lost '-d' but still accept it as an option, so...
-- >8 --
[PATCH]: ls-tree: resurrect '-d' to mean 'show trees only'
With this:
git-ls-tree -d HEAD -- drivers/net/
shows only immediate subtrees of drivers/net.
git-ls-tree -d -t HEAD -- drivers/net/
shows drivers, drivers/net and immediate subtrees of
drivers/net.
git-ls-tree -d -r HEAD -- drivers/net/
shows drivers, drivers/net and all subtrees of drivers/net (but
not blobs).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* The practical value of this patch is dubious, and we might
want to simply remove '-d' from the options. But the output
from this looks kind-of nice. Thoughts?
diff --git a/ls-tree.c b/ls-tree.c
index a2a5eb0..07db863 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -61,6 +61,8 @@ static int show_tree(unsigned char *sha1
}
type = "tree";
}
+ else if (ls_options & LS_TREE_ONLY)
+ return 0;
printf("%06o %s %s\t", mode, type, sha1_to_hex(sha1));
write_name_quoted(base, baselen, pathname, line_termination, stdout);
@@ -95,6 +97,10 @@ int main(int argc, const char **argv)
}
argc--; argv++;
}
+ /* -d -r should imply -t, but -d by itself should not have to. */
+ if ( (LS_TREE_ONLY|LS_RECURSIVE) ==
+ ((LS_TREE_ONLY|LS_RECURSIVE) & ls_options))
+ ls_options |= LS_SHOW_TREES;
if (argc < 2)
usage(ls_tree_usage);
^ permalink raw reply related
* Re: [PATCH 6/7] Add a "--clone" option to "stg branch"
From: Catalin Marinas @ 2005-12-01 21:05 UTC (permalink / raw)
To: Chuck Lever; +Cc: git
In-Reply-To: <20051129220949.9885.51533.stgit@dexter.citi.umich.edu>
On 29/11/05, Chuck Lever <cel@netapp.com> wrote:
> Cloning a branch means creating a new branch and copying all of the
> original branch's patches and its base to it. Like creating a tag,
> but this also preserves all the StGIT patches as well.
[...]
> --- a/stgit/commands/branch.py
> +++ b/stgit/commands/branch.py
[...]
> + print 'Cloning current branch to "%s"...' % clone
I would put a comma after this line and add sys.stdout.flush(). So
that 'done' is shown on the same line.
[...]
> --- a/stgit/stack.py
> +++ b/stgit/stack.py
[...]
> + def clone(self, target_series):
> + """Clones a series
> + """
Wouldn't it be easier to do a recursive copy at the directory level
(.git/patches/<branch> into .git/patches/<clone> and
.git/refs/bases/<branch> into .git/refs/bases/<clone>)? Is there
anything that could go wrong if we do this?
--
Catalin
^ permalink raw reply
* Re: [Question] Fetching a new branch from remote
From: Jon Loeliger @ 2005-12-01 20:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Baldwin, Git List
In-Reply-To: <7vk6eoinqa.fsf@assigned-by-dhcp.cox.net>
On Thu, 2005-12-01 at 14:09, Junio C Hamano wrote:
>
> I just found out that the documentation for '-f' flag is simply
> missing. I'd propose to add the following. Thanks for noticing.
Hmm. Apologies. I had mentioned it back here, but
didn't know what it did and so didn't document it:
From: Jon Loeliger <jdl@freescale.com>
To: git@vger.kernel.org
Subject: [PATCH] Add --tags documentation, scraped from JC mail.
Date: Mon, 7 Nov 2005 07:03:30 -0700
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Thin territory here for me. Feel free to alter if not right! :-)
Also notice the lonely --force option still...
^ permalink raw reply
* Re: documentation issues
From: Chris Shoemaker @ 2005-12-01 20:34 UTC (permalink / raw)
To: Chuck Lever; +Cc: git
In-Reply-To: <438F5D05.4080101@citi.umich.edu>
On Thu, Dec 01, 2005 at 03:28:53PM -0500, Chuck Lever wrote:
> also, git-diff-index supports a "-r" option, but that doesn't seem to be
> documented on this page.
I think it is "supported" in the sense that git-diff-index won't
complain about "-r" argument, but it doesn't actually do anything, so
it shouldn't be documented.
-chris
^ permalink raw reply
* Re: [RFC/PATCH 1/3] git-find-git: a new helper.
From: Josef Weidendorfer @ 2005-12-01 20:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr78wirj7.fsf@assigned-by-dhcp.cox.net>
On Thursday 01 December 2005 19:46, you wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
> > can we revive this idea?
>
> I forgot git-rev-parse had --show-prefix and git-rev-parse --git-dir
> already when I did that one.
Ah, thanks.
By the way, the documentation ofr --git-dir is missing.
It would be nice to have some docu about "How to write a porcelain", and
this should go under the section "Making commands work in subdirs of
a working copy"...
Josef
^ permalink raw reply
* documentation issues
From: Chuck Lever @ 2005-12-01 20:28 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 393 bytes --]
i'd fix these myself, but i don't know what the right answers are.
in the man page for git-diff-index (posted here):
http://www.kernel.org/pub/software/scm/git/docs/git-diff-tree.html
there are several references to "git-diff-tree" where it seems like
"git-diff-index" is really meant.
also, git-diff-index supports a "-r" option, but that doesn't seem to be
documented on this page.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 445 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: [Question] Fetching a new branch from remote
From: Junio C Hamano @ 2005-12-01 20:09 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20051128163356.GA8300@hpsvcnb.fc.hp.com>
Carl Baldwin <cnb@fc.hp.com> writes:
> I would expect this to do it:
>
> % git fetch -f <url> new-branch
>
> But, it doesn't.
>
> Actually, I just noticed that this accomplishes the desired result...
>
> % git fetch <url> new-branch:new-branch
First, '-f' means "allow overriding the fast-forward check when
updating an existing branch". This can be done per refspec by
saying "+rbranch:lbranch" but if you are fetching more than one
remote branches at once (especially through "remotes" shorthand)
the option can be used to allow override of all of them.
A single token <refspec> defaults to "<refspec>:" (meaning,
"fetch but do not muck with our branches") is deliberate. When
I get a pull request "please pull from git://u/r/l/ send2junio branch",
I do not "git pull git://u/r/l/ send2junio" right away, but do
"git fetch git://u/r/l/ send2junio" and inspect FETCH_HEAD with
various combinations of "git diff master..FETCH_HEAD" and
friends. I do _not_ want it to create send2junio branch in my
repository with that. Also "git pull git://u/r/l/ send2junio"
would internally run "git fetch git://u/r/l/ send2junio" and
then runs merge, and I do not want that to create send2junio
branch in my repository either. The latter could be prevented by
adding an extra flag to git-fetch to tell it not to default
a single token <refspec> to "<refspec>:<refspec>" and pass that
flag from git-pull, though.
I just found out that the documentation for '-f' flag is simply
missing. I'd propose to add the following. Thanks for noticing.
-- >8 --
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index a25d04a..200c9b2 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -4,6 +4,11 @@
option old data in `.git/FETCH_HEAD` will be overwritten.
-f, \--force::
+ When `git-fetch` is used with `<rbranch>:<lbranch>`
+ refspec, it refuses to update the local branch
+ `<lbranch>` unless the remote branch `<rbranch>` it
+ fetches is a descendant of `<lbranch>`. This option
+ overrides that check.
-t, \--tags::
By default, the git core utilities will not fetch and store
^ permalink raw reply related
* Segmentation fault in git-shell & symlink instead of script post-update in git repository
From: Majkls @ 2005-12-01 19:17 UTC (permalink / raw)
To: git
Hello,
when I tried to install git, I found some bug in git-shell (shell.c). If
you don't give two parameters in argv[2], program ends by segfault.
There is a problem solution.
*** shell.c 2005-11-26 01:35:20.000000000 +0100
--- shell.c.new 2005-12-01 19:42:29.000000000 +0100
*************** int main(int argc, char **argv)
*** 42,48 ****
char *arg;
if (strncmp(cmd->name, prog, len))
continue;
! arg = NULL;
switch (prog[len]) {
case '\0':
arg = NULL;
--- 42,48 ----
char *arg;
if (strncmp(cmd->name, prog, len))
continue;
! arg = "";
switch (prog[len]) {
case '\0':
arg = NULL;
I have /home/scm mounted as noexec. I had a problem with post-update. I
remove it and replaced with symlink to current program. So that works.
--
Miloslav "Majkls" Semler
^ permalink raw reply
* Re: unexpected EOF?
From: Linus Torvalds @ 2005-12-01 18:40 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EhohG-0001iZ-IB@jdl.com>
On Thu, 1 Dec 2005, Jon Loeliger wrote:
>
> I thought I had imagined this last time, but now
> that it has happened twice, I'm not so sure what
> is going on. First pull attempt garners an
> unexpected EOF message; immediately pull again
> seems to work.
>
> jdl@ubuntu:/usr/src/git-core$ git pull origin
> fatal: unexpected EOF
> Fetch failure: git://git.kernel.org/pub/scm/git/git.git/
> jdl@ubuntu:/usr/src/git-core$ git pull origin
> Unpacking 17 objects
The public kernel.org machines are actually _two_ different machines, and
have two different addresses:
Non-authoritative answer:
git.kernel.org canonical name = zeus-pub.kernel.org.
Name: zeus-pub.kernel.org
Address: 204.152.191.5
Name: zeus-pub.kernel.org
Address: 204.152.191.37
so with a round-robin kind of DNS resolution, you'd get alternate
machines. Maybe one of them isn't up-to-date due to mirroring problems?
You can test by using the IP addresses explicitly, of course.
In particular, if the directory doesn't exist at all, or if the directory
doesn't have the "git-daemon-export-ok" flag, the git daemon on the other
end will just close the connection and refuse to talk to you (I thought
that was preferable to give any indication of why it fails: from a
security standpoint, you do _not_ want to be able to test if a random
directory exists by looking at the return value of git-daemon).
Linus
^ permalink raw reply
* git-ls-tree: add "-t" option to always show the tree entries
From: Linus Torvalds @ 2005-12-01 18:35 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Junio C Hamano, git
In-Reply-To: <20051201085433.GA7866@c165.ib.student.liu.se>
The old (new) behaviour was that it only shows trees if the object is
specified exactly, and recursive is not set. That makes sense, because
there is obviously nothing else it can show for that case.
However, with the new "-t" option, it will show the tree even with "-r",
as it traverses down into it.
NOTE! This also means that it will show all trees leading up to that tree.
For example, if you do a
git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist
it will show the trees that lead up to the files that do not exist:
[torvalds@g5 linux]$ git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist
040000 tree 9cb687b77dcd64bf82e9a73214db467c964c1266 drivers
040000 tree 298e2fadf0ff3867d1ef49936fd2c7bf6ce1eb66 drivers/char
[torvalds@g5 linux]$
and note how this is true even though I didn't specify "-r": the fact that
I supplied a pathspec automatically implies "enough recursion" for that
particular pathspec.
I think the code is cleaner and easier to understand too: the patch looks
bigger, but it's really just splitting up the "should we recurse into this
tree" into a function of its own.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
This obviously means that to fix merge-recursive, we should add that "-t"
flag to it, but then hopefully everything should be ok? Do you have a
test-case, and perhaps something we could add to "make test".
Talking about "make test", this doesn't break any (since it doesn't change
behaviour without the "-t" flag), but maybe it should add some. But I'm
lazy.
On Thu, 1 Dec 2005, Fredrik Kuivinen wrote:
>
> It turns out that this change breaks the directory/file conflict
> handling in git-merge-recursive. Right now merge-recursive uses
>
> git-ls-tree -r -z <tree SHA1>
>
> to get a listing of every blob object (which corresponds to files) and
> every tree object (which corresponds to directories) in the tree
> designated by the SHA1.
diff --git a/ls-tree.c b/ls-tree.c
index d4b6219..a2a5eb0 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -11,39 +11,53 @@
static int line_termination = '\n';
#define LS_RECURSIVE 1
#define LS_TREE_ONLY 2
+#define LS_SHOW_TREES 4
static int ls_options = 0;
const char **pathspec;
static const char ls_tree_usage[] =
- "git-ls-tree [-d] [-r] [-z] <tree-ish> [path...]";
+ "git-ls-tree [-d] [-r] [-t] [-z] <tree-ish> [path...]";
+
+static int show_recursive(const char *base, int baselen, const char *pathname)
+{
+ const char **s;
+
+ if (ls_options & LS_RECURSIVE)
+ return 1;
+
+ s = pathspec;
+ if (!s)
+ return 0;
+
+ for (;;) {
+ const char *spec = *s++;
+ int len, speclen;
+
+ if (!spec)
+ return 0;
+ if (strncmp(base, spec, baselen))
+ continue;
+ len = strlen(pathname);
+ spec += baselen;
+ speclen = strlen(spec);
+ if (speclen <= len)
+ continue;
+ if (memcmp(pathname, spec, len))
+ continue;
+ return 1;
+ }
+}
static int show_tree(unsigned char *sha1, const char *base, int baselen, const char *pathname, unsigned mode, int stage)
{
+ int retval = 0;
const char *type = "blob";
if (S_ISDIR(mode)) {
- const char **s;
- if (ls_options & LS_RECURSIVE)
- return READ_TREE_RECURSIVE;
- s = pathspec;
- if (s) {
- for (;;) {
- const char *spec = *s++;
- int len, speclen;
-
- if (!spec)
- break;
- if (strncmp(base, spec, baselen))
- continue;
- len = strlen(pathname);
- spec += baselen;
- speclen = strlen(spec);
- if (speclen <= len)
- continue;
- if (memcmp(pathname, spec, len))
- continue;
- return READ_TREE_RECURSIVE;
- }
+ if (show_recursive(base, baselen, pathname)) {
+ retval = READ_TREE_RECURSIVE;
+ if (!(ls_options & LS_SHOW_TREES))
+ return retval;
}
type = "tree";
}
@@ -51,7 +65,7 @@ static int show_tree(unsigned char *sha1
printf("%06o %s %s\t", mode, type, sha1_to_hex(sha1));
write_name_quoted(base, baselen, pathname, line_termination, stdout);
putchar(line_termination);
- return 0;
+ return retval;
}
int main(int argc, const char **argv)
@@ -73,6 +87,9 @@ int main(int argc, const char **argv)
case 'd':
ls_options |= LS_TREE_ONLY;
break;
+ case 't':
+ ls_options |= LS_SHOW_TREES;
+ break;
default:
usage(ls_tree_usage);
}
^ permalink raw reply related
* Re: [PATCH 7/9] Add the accurate changeset applyer
From: Martin Langhoff @ 2005-12-01 17:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git list, Martin Langhoff
In-Reply-To: <20051124075504.GH4789@mail.yhbt.net>
Eric,
My test results are a bit of a mixed bag. On one hand, I'm satisfied
that both fast and correct imports reach the same tree (minus file
modes) for the same commit with the arch repos I imported.
On the other hand, with my "moodle" repo, the 'correct' import seems
to have stop importing a lot earlier than it should have. I am
re-running it now to try to continue from where it left off, but it's
unclear why it abandoned -- I didn't see any error. How widely have
you tested this method?
cheers,
martin
^ permalink raw reply
* HELP: How to setup git on the system
From: Ju, Seokmann @ 2005-12-01 16:48 UTC (permalink / raw)
To: 'git@vger.kernel.org'; +Cc: Ju, Seokmann
Hi,
I'm trying to get clone image of 2.6 kernel throgh git and getting following
message during cloning.
[root@dhcp root]# git clone
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
linux-2.6
defaulting to local storage area
rsync: failed to connect to rsync.kernel.org:Connection timed out (110)
rsync error : error in socket IO (code 10) at clientserver.c(94)
I've RHEL 4 U2 on IA32 platform.
The platform has network configured with DHCP (with no firwall enabled).
Any comment would be appreciated.
Thank you,
Seokmann
^ permalink raw reply
* How to set-up git on my system
From: Ju, Seokmann @ 2005-12-01 15:42 UTC (permalink / raw)
To: 'git@vger.kernel.org'
Hi,
I'm trying to use git and in the middle of installing it on the RHEL4 U2.
I have following modules in hand.
- git-core-0.99.7-1.i386.rpm
- cogito-0.15.1-1.noarch.rpm
During 'git-core-0.99.7-1.i386.rpm' installation, I'm getting following
error message,
[root@dhcp root]# rpm-ihv git-core-0.99.7-1.i386.rpm
error: Failed dependencies:
perl(String::ShellQuote) is needed by git-core-0.99.7-1.i386
python >= 2.4 is needed by git-core-0.99.7-1.i386
Where can I find those modules?
Also, please point out if you see any further obstacles along the way to
move forward.
Any feedback would be appreciated.
Regards,
Seokmann
^ permalink raw reply
* Re: [RFC] Using sticky directories to control access to branches.
From: Carl Baldwin @ 2005-12-01 15:42 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <20051121180133.GA28171@hpsvcnb.fc.hp.com>
I have tweaked the script a little. I thought I'd send to the list in
case anyone was following this. If not, then safely ignore this.
#!/bin/bash
umask 002
# If you are having trouble with this access control hook script you can try
# setting this to true. It will tell you exactly why a user is being
# allowed/denied access.
verbose=false
# Default shell globbing messes things up downstream
GLOBIGNORE=*
function grant {
$verbose && echo >&2 "-Grant- $1"
echo grant
exit 0
}
function deny {
$verbose && echo >&2 "-Deny- $1"
echo deny
exit 1
}
function info {
$verbose && echo >&2 "-Info- $1"
}
# Implement generic branch and tag policies.
# - Tags should not be updated once created.
# - Branches should only be fast-forwarded.
case "$1" in
refs/tags/*)
[ -f "$GIT_DIR/$1" ] && deny >/dev/null "You can't overwrite an existing tag"
;;
refs/heads/*)
# No rebasing or rewinding
if expr "$2" : '0*$' >/dev/null; then
info "The branch '$1' is new..."
else
# updating -- make sure it is a fast forward
mb=$(git-merge-base "$2" "$3")
case "$mb,$2" in
"$2,$mb") info "Update is fast-forward" ;;
*) deny >/dev/null "This is not a fast-forward update." ;;
esac
fi
;;
*)
deny >/dev/null "Branch is not under refs/heads or refs/tags. What are you trying to do?"
;;
esac
# Implement per-branch controls based on username
allowed_users_file=$GIT_DIR/info/allowed-users
username=$(id -u -n)
info "The user is: '$username'"
if [ -f "$allowed_users_file" ]; then
rc=$(cat $allowed_users_file | grep -v '^#' | grep -v '^$' |
while read head_pattern user_patterns; do
matchlen=$(expr "$1" : "$head_pattern")
if [ "$matchlen" == "${#1}" ]; then
info "Found matching head pattern: '$head_pattern'"
for user_pattern in $user_patterns; do
info "Checking user: '$username' against pattern: '$user_pattern'"
matchlen=$(expr "$username" : "$user_pattern")
if [ "$matchlen" == "${#username}" ]; then
grant "Allowing user: '$username' with pattern: '$user_pattern'"
fi
done
deny "The user is not in the access list for this branch"
fi
done
)
case "$rc" in
grant) grant >/dev/null "Granting access based on $allowed_users_file" ;;
deny) deny >/dev/null "Denying access based on $allowed_users_file" ;;
*) ;;
esac
fi
allowed_groups_file=$GIT_DIR/info/allowed-groups
groups=$(id -G -n)
info "The user belongs to the following groups:"
info "'$groups'"
if [ -f "$allowed_groups_file" ]; then
rc=$(cat $allowed_groups_file | grep -v '^#' | grep -v '^$' |
while read head_pattern group_patterns; do
matchlen=$(expr "$1" : "$head_pattern")
if [ "$matchlen" == "${#1}" ]; then
info "Found matching head pattern: '$head_pattern'"
for group_pattern in $group_patterns; do
for groupname in $groups; do
info "Checking group: '$groupname' against pattern: '$group_pattern'"
matchlen=$(expr "$groupname" : "$group_pattern")
if [ "$matchlen" == "${#groupname}" ]; then
grant "Allowing group: '$groupname' with pattern: '$group_pattern'"
fi
done
done
deny "None of the user's groups are in the access list for this branch"
fi
done
)
case "$rc" in
grant) grant >/dev/null "Granting access based on $allowed_groups_file" ;;
deny) deny >/dev/null "Denying access based on $allowed_groups_file" ;;
*) ;;
esac
fi
deny >/dev/null "There are no more rules to check. Denying access"
On Mon, Nov 21, 2005 at 11:01:33AM -0700, Carl Baldwin wrote:
> OK,
>
> To follow-up on this. Here is a final version of this script that was
> started by Junio. I polished it and made it work the way I want it.
> Hopefully, someone on the list will find it useful.
>
> Here is a basic description. There are two files:
> .git/info/allowed-users
> .git/info/allowed-groups
>
> The users file is checked, line by line, followed by the groups file.
> The first line matching the ref to be updated is used. Each line has
> one regular expression to match the ref followed by one or more regular
> expressions to match user (or group). Space is the delimeter so the RE
> cannot contain a space.
>
> If no line matches the ref then access is denied. For this reason I
> tend to include the following line as the last line of allowed-groups as
> the default since it will match any ref and any group.
>
> .* .*
>
> Here is the hook script... Thanks to Junio for getting me started. I
> rewrote the whole thing using my own style but much of the code is based
> on his.
>
> #!/bin/bash
>
> umask 002
>
> verbose=no
>
> # Default shell globbing messes things up later
> GLOBIGNORE=*
>
> function grant {
> [ "yes" == "$verbose" ] && echo >&2 "-Grant- $1"
> exit 0
> }
>
> function deny {
> [ "yes" == "$verbose" ] && echo >&2 "-Deny- $1"
> exit 1
> }
>
> function info {
> [ "yes" == "$verbose" ] && echo >&2 "-Info- $1"
> }
>
> # Implement generic branch and tag policies.
> # - Tags should not be updated once created.
> # - Branches should only be fast-forwarded.
> case "$1" in
> refs/tags/*)
> [ -f "$GIT_DIR/$1" ] && deny "You can't overwrite an existing tag"
> ;;
> refs/heads/*)
> # No rebasing or rewinding
> if expr "$2" : '0*$' >/dev/null; then
> info "The branch '$1' is new..."
> else
> # updating -- make sure it is a fast forward
> mb=$(git-merge-base "$2" "$3")
> case "$mb,$2" in
> "$2,$mb") info "Update is fast-forward" ;;
> *) deny "This is not a fast-forward update." ;;
> esac
> fi
> ;;
> *)
> deny "Branch is not under refs/heads or refs/tags. What are you trying to do?"
> ;;
> esac
>
> # Implement per-branch controls based on username
> allowed_users_file=$GIT_DIR/info/allowed-users
> username=$(id -u -n)
> info "The user is: '$username'"
>
> if [ -f "$allowed_users_file" ]; then
> 3<$allowed_users_file
> while read -u 3 head_pattern user_patterns; do
> matchlen=$(expr "$1" : "$head_pattern")
> if [ "$matchlen" == "${#1}" ]; then
> info "Found matching head pattern: '$head_pattern'"
> for user_pattern in $user_patterns; do
> info "Checking user: '$username' against pattern: '$user_pattern'"
> matchlen=$(expr "$username" : "$user_pattern")
> if [ "$matchlen" == "${#username}" ]; then
> grant "Allowing user: '$username' with pattern: '$user_pattern'"
> fi
> done
> deny "The user is not in the access list for this branch"
> fi
> done
> fi
>
> allowed_groups_file=$GIT_DIR/info/allowed-groups
> groups=$(id -G -n)
> info "The user belongs to the following groups:"
> info "'$groups'"
>
> if [ -f "$allowed_groups_file" ]; then
> 4<$allowed_groups_file
> while read -u 4 head_pattern group_patterns; do
> matchlen=$(expr "$1" : "$head_pattern")
> if [ "$matchlen" == "${#1}" ]; then
> info "Found matching head pattern: '$head_pattern'"
> for group_pattern in $group_patterns; do
> for groupname in $groups; do
> info "Checking group: '$groupname' against pattern: '$group_pattern'"
> matchlen=$(expr "$groupname" : "$group_pattern")
> if [ "$matchlen" == "${#groupname}" ]; then
> grant "Allowing group: '$groupname' with pattern: '$group_pattern'"
> fi
> done
> done
> deny "None of the user's groups are in the access list for this branch"
> fi
> done
> fi
>
> deny "There are no more rules to check. Denying access"
> # End script here
>
> Carl
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Carl Baldwin Systems VLSI Laboratory
> Hewlett Packard Company
> MS 88 work: 970 898-1523
> 3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
> Fort Collins, CO 80525 home: Carl@ecBaldwin.net
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> -
> 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
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: [RFC/PATCH 1/3] git-find-git: a new helper.
From: Josef Weidendorfer @ 2005-12-01 14:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzjuzphl.fsf@assigned-by-dhcp.cox.net>
On Thursday 24 November 2005 04:36, you wrote:
> GIT_DIR_PREFIX is a string to be prepended to cwd relative
> paths to make them repository relative.
>
> GIT_DIR_UPLEVEL is a string (e.g. "../") for the command to
> use to cd to the top-level of repository.
Hi,
can we revive this idea?
I thought about how to make work
$top/Documentation> git-mv ../file .
and also detection of trying to move to the outside.
Requirements IMHO:
(1) helper which is also useful from PERL
(2) git-mv checks against version controlled files via git-ls-files.
Thus, I need to run git-ls-files from the toplevel, to be able to
see $top/file.
(3) translation of cwd relative into toplevel relative paths.
Or is there already a way to do this with current git?
Josef
^ permalink raw reply
* Re: minor problems in git.c
From: Alex Riesen @ 2005-12-01 14:02 UTC (permalink / raw)
To: skimo; +Cc: Robert Watson, git, Junio C Hamano
In-Reply-To: <20051201135113.GW8383MdfPADPa@greensroom.kotnet.org>
On 12/1/05, Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Thu, Dec 01, 2005 at 01:48:35PM +0100, Alex Riesen wrote:
> > @@ -283,16 +283,15 @@ int main(int argc, char **argv, char **e
> > len = strlen(git_command);
> > prepend_to_path(git_command, len);
> >
> > - strncat(&git_command[len], "/git-", sizeof(git_command) - len);
> > - len += 5;
> > - strncat(&git_command[len], argv[i], sizeof(git_command) - len);
> > + snprintf(git_command + len, sizeof(git_command) - len, "/git-%s",
> > + argv[i]);
>
> Shouldn't you check the return value of snprintf
Probably. For the case where length of a git-command-name +
--exec-prefix together are longer than PATH_MAX.
> > if (access(git_command, X_OK))
> > usage(exec_path, "'%s' is not a git-command", argv[i]);
>
> or use the (possibly) truncated version of the command in the error message ?
argv[i] is the command name, already as truncated as it can possibly
be: ls-files, ls-tree, etc. Besides, the second path removes this
access check altogether:
- if (access(git_command, X_OK))
- usage(exec_path, "'%s' is not a git-command", argv[i]);
-
/* execve() can only ever return if it fails */
execve(git_command, &argv[i], envp);
- fprintf(stderr, "git: '%s': %s\n", git_command, strerror(errno));
+ if ( ENOENT == errno )
+ usage(exec_path, "'%s' is not a git-command", argv[i]);
+ else
+ fprintf(stderr, "git: '%s': %s\n", git_command, strerror(errno));
It still has the call to usage, though.
^ permalink raw reply
* Re: minor problems in git.c
From: Sven Verdoolaege @ 2005-12-01 13:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: Robert Watson, git, Junio C Hamano
In-Reply-To: <81b0412b0512010448u7fcdddacnd7de5df217ab3ca@mail.gmail.com>
On Thu, Dec 01, 2005 at 01:48:35PM +0100, Alex Riesen wrote:
> @@ -283,16 +283,15 @@ int main(int argc, char **argv, char **e
> len = strlen(git_command);
> prepend_to_path(git_command, len);
>
> - strncat(&git_command[len], "/git-", sizeof(git_command) - len);
> - len += 5;
> - strncat(&git_command[len], argv[i], sizeof(git_command) - len);
> + snprintf(git_command + len, sizeof(git_command) - len, "/git-%s",
> + argv[i]);
Shouldn't you check the return value of snprintf
> if (access(git_command, X_OK))
> usage(exec_path, "'%s' is not a git-command", argv[i]);
or use the (possibly) truncated version of the command in the error message ?
skimo
^ 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