* Re: [PATCH 6/8] ls-tree: work from subdirectory.
From: Junio C Hamano @ 2005-11-28 1:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511271049090.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 27 Nov 2005, Petr Baudis wrote:
>> Ugh. That's really weird. Wouldn't a better approach be to fix
>> git-ls-files to behave more sanely? (That is, listing the entry for
>> drivers/char instead of drivers?)
It behaves sanely, just not in the way you are expecting.
> Well, it's not actually confusing if you see a path spec for
> what it is: it's not a filename, it's a _pattern_.
Well, that is confusing, although it may be sane.
> So you should always do
>
> git-ls-tree -r pattern
>
> (and yes, we could even hardcode "-r", because git-ls-tree without it
> really is a pretty strange thing).
If you mean "in the presense of pathspec, default to -r", I
*might* agree, but I am not convinced yet.
Without pathspec, ls-tree is a pretty-printing version of
"git-cat-file tree", and that is how the command is used by the
git browsers like gitweb. I have never looked at qgit source,
but I'd be surprised if it did not depend on the single-level
behaviour of ls-tree for that purpose.
It *is* "/bin/ls" after all, and you _would_ get annoyed if your
/bin/ls always recursed if you gave an argument. Imagine going
to the kernel source and try "/bin/ls arch" with your version of
/bin/ls that always recurses, when you only wanted to get the
list of architectures you are supporting ;-).
> The _real_ strangeness in "git-ls-tree" is that it shows the tree nodes at
> all, which no other git tool does when it recurses.
Very true. I do not think even git browsers need that but I may
be mistaken.
Having said all of the above, I do understand why we would
_also_ want the behaviour parallel to ls-files, not /bin/ls
behaviour. Maybe we should have both? Either rename the
current ls-tree to browse-tree, and make the one that parallels
ls-files the new ls-tree?
^ permalink raw reply
* Re: Perl version support (was Re: [PATCH] git-mv is not able to handle big directories)
From: Ryan Anderson @ 2005-11-28 1:46 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git
In-Reply-To: <86mzjvphhj.fsf_-_@blue.stonehenge.com>
[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]
Randal L. Schwartz wrote:
>>>>>>"Ryan" == Ryan Anderson <ryan@michonline.com> writes:
> Ryan> For the kernel, requiring 5.8 shouldn't be a big issue. I suspect it's
> Ryan> really only the commercial Unixes where requiring 5.8 would be annoying.
>
> Ryan> Randal, is my guess even remotely accurate?
>
> I'd say that 50% of the Perl-using population is at 5.6, with 25% each
> at 5.5 and 5.8. Those on 5.5 are generally unable to upgrade Perl
> for corporate reasons.
>
> Targetting Perl 5.6 would assist broad acceptance of git for the
> typical commercial end user. Targetting 5.5 where possible would
> ensure practical success for everyone.
>
> However, I have not seen the "target market" of git discussed yet
> (I came late to the party), so if support for 5.6 (or 5.5) is not chosen,
> it merely limits the market.
Well, I think the general target market[1] for Linux probably applies
here, as well. On the other hand, the users limited to Perl 5.5 for
corporate reasons are probably also prevented from installing new tools
for general use, so the difference may not matter very much.
[1] - "World domination", of course.
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: [PATCH 6/8] ls-tree: work from subdirectory.
From: Linus Torvalds @ 2005-11-28 1:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <7vveyd37ic.fsf@assigned-by-dhcp.cox.net>
On Sun, 27 Nov 2005, Junio C Hamano wrote:
>
> Without pathspec, ls-tree is a pretty-printing version of
> "git-cat-file tree", and that is how the command is used by the
> git browsers like gitweb. I have never looked at qgit source,
> but I'd be surprised if it did not depend on the single-level
> behaviour of ls-tree for that purpose.
You're right, we need to keep the "-r" behaviour.
> Having said all of the above, I do understand why we would
> _also_ want the behaviour parallel to ls-files, not /bin/ls
> behaviour. Maybe we should have both? Either rename the
> current ls-tree to browse-tree, and make the one that parallels
> ls-files the new ls-tree?
If you take my last patch and make "ls_flags" default to 0 again, it
should work correctly.
The way to traverse into directories (a la qgit/webgit) is to just give
the SHA1 name of the directory. Ie
git-ls-tree HEAD
gives us a single level, we see:
...
040000 tree b2d1264f85148d18c5ae9864d73d65737b0a1734 t
...
and then we can just do
git-ls-tree b2d1264f85148d18c5ae9864d73d65737b0a1734
to get that level. I assume that that is what qgit/webgit already does (I
sure hope so, otherwise they're just wasting time, making the tools
re-parse the trees over and over again for no gain).
Linus
^ permalink raw reply
* [PATCH] bisect: quote pathnames for eval safety.
From: Junio C Hamano @ 2005-11-28 1:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Timo Hirvonen, git
In-Reply-To: <Pine.LNX.4.64.0511271106360.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Almost totally untested, and I guarantee that if your pathnames have
> spaces in them (or your GIT_DIR has spaces in it) this won't work. I don't
> know how to fix that, my shell programming isn't good enough.
Like this? I've placed the bisect patch with this in the
proposed updates.
---
git-bisect.sh | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
applies-to: 7da44ab45773e0a424c1e08c838c1f6deeb6ceb2
82c8f5bed2ae61f1f368cfca84f6b0194b1ad208
diff --git a/git-bisect.sh b/git-bisect.sh
index 2455f00..d4196f9 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,9 +1,16 @@
#!/bin/sh
. git-sh-setup
+sq() {
+ for x
+ do
+ echo "$x" | sed -e "s/'/'\\\\''/g" -e "s/^/'/" -e "s/\$/'/"
+ done
+}
+
usage() {
echo >&2 'usage: git bisect [start|bad|good|next|reset|visualize]
-git bisect start reset bisect state and start bisection.
+git bisect start [<pathspec>] reset bisect state and start bisection.
git bisect bad [<rev>] mark <rev> a known-bad revision.
git bisect good [<rev>...] mark <rev>... known-good revisions.
git bisect next find next bisection to test and check it out.
@@ -56,8 +63,8 @@ bisect_start() {
rm -f "$GIT_DIR/refs/heads/bisect"
rm -rf "$GIT_DIR/refs/bisect/"
mkdir "$GIT_DIR/refs/bisect"
- echo "git-bisect start $@" >"$GIT_DIR/BISECT_LOG"
- echo "$@" > "$GIT_DIR/BISECT_NAMES"
+ sq git-bisect start "$@" >"$GIT_DIR/BISECT_LOG"
+ sq "$@" >"$GIT_DIR/BISECT_NAMES"
}
bisect_bad() {
@@ -142,7 +149,8 @@ bisect_next() {
bisect_visualize() {
bisect_next_check fail
- gitk bisect/bad --not `cd "$GIT_DIR/refs" && echo bisect/good-*` -- $(cat $GIT_DIR/BISECT_NAMES)
+ not=`cd "$GIT_DIR/refs" && echo bisect/good-*`
+ eval gitk bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES")
}
bisect_reset() {
---
0.99.9.GIT
^ permalink raw reply related
* Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
From: Johannes Schindelin @ 2005-11-28 1:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051127125945.GD22159@pasky.or.cz>
Hi,
On Sun, 27 Nov 2005, Petr Baudis wrote:
> I've tried to explain that branches and remotes are different concepts,
Well, no. They aren't. The "branches" concept is a proper special case of
the "remotes" concept.
But what the heck, I don't care what you eventually use.
I only realized that we -- in the good tradition of UNIX -- have many
different formats for different configurations: Some configurations are in
.gitignore, some are in .git/branches/, some in .git/remotes/, some in
.git/config, and even some in environment variables!
If everybody says that this should stay so, I'll just shut up.
Hth,
Dscho
^ permalink raw reply
* lost again on syntax change - local repository?
From: Randal L. Schwartz @ 2005-11-28 2:01 UTC (permalink / raw)
To: git
OK, something that I understood broke again. :)
Repeating the steps from my previous attempt to understand repositories,
knowing that cg-push has been updated:
localhost:~/Projects/Git/Play % cg-admin-setuprepo remote.git
localhost:~/Projects/Git/Play % mkdir local.git
localhost:~/Projects/Git/Play % cd local.git
localhost:..Git/Play/local.git % cg-init -minitial .
defaulting to local storage area
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committed as 6b9850a86bbe2d07bbdaa0c5595c8f4c0423b13c.
localhost:..Git/Play/local.git % cg-branch-add origin "$(cd ..; pwd)/remote.git#master"
localhost:..Git/Play/local.git % cg-branch-ls
origin /Users/merlyn/Projects/Git/Play/remote.git#master
localhost:..Git/Play/local.git %
At this point, I'm where I was before. And this next step worked,
although I had to say "origin":
localhost:..Git/Play/local.git % cg-push
WARNING: I guessed the host:path syntax was used and fell back to the git+ssh protocol.
WARNING: The host:path syntax is evil because it is implicit. Please just use a URI.
ssh: \033]2;[zsh] localhost: No address associated with nodename
fatal: unexpected EOF
Uh, say what? /some/file/foo.git#branch is no longer legal syntax?
Help!
How do I say /some/file on the local filesystem? (I also tried
file:/some/file, and that didn't work either.)
--
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: [PATCH] bisect: quote pathnames for eval safety.
From: Junio C Hamano @ 2005-11-28 2:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Timo Hirvonen, git
In-Reply-To: <7vmzjp35gk.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> Almost totally untested, and I guarantee that if your pathnames have
>> spaces in them (or your GIT_DIR has spaces in it) this won't work. I don't
>> know how to fix that, my shell programming isn't good enough.
>
> Like this? I've placed the bisect patch with this in the
> proposed updates.
Not like that ;-). Fixed one is in pu.
^ permalink raw reply
* Re: lost again on syntax change - local repository?
From: Junio C Hamano @ 2005-11-28 5:11 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <861x118r9t.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> At this point, I'm where I was before. And this next step worked,
> although I had to say "origin":
>
> localhost:..Git/Play/local.git % cg-push
> WARNING: I guessed the host:path syntax was used and fell back to the git+ssh protocol.
> WARNING: The host:path syntax is evil because it is implicit. Please just use a URI.
> ssh: \033]2;[zsh] localhost: No address associated with nodename
> fatal: unexpected EOF
>
> Uh, say what? /some/file/foo.git#branch is no longer legal syntax?
> Help!
If it is not absolutely necessary that you need to use Cogito,
IOW, if git barebone Porcelains are good enough for your use,
the following may be adequate.
$ echo >.git/remotes/origin <<EOF
URL: /path/to/remote.git/
Push: master
Pull: master:origin
EOF
$ git push origin
I said "may be" because I do not understand the sequence before
"At this point"; how your local.git is initially set up to
relate to the remoge.git. I do not see local.git being created
by cloning remote.git. But modulo that the above should work
fine; I do that as a cheap backup on my local machine.
^ permalink raw reply
* Re: [PATCH 6/8] ls-tree: work from subdirectory.
From: Junio C Hamano @ 2005-11-28 6:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511271742520.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> You're right, we need to keep the "-r" behaviour.
> If you take my last patch and make "ls_flags" default to 0 again, it
> should work correctly.
Maybe making "-r" the default and resurrecting "-d" to turn it
off would be the approach of least impact (-r becomes a
noiseword), if we take this "ls-tree should parallel ls-files"
idea.
The merge-recursive strategy uses ls-tree without -r with path
specifier to grab the sha1/mode of the three trees involved.
git-cvsexportcommit has the same assumption on how ls-tree
works. It extracts a single SHA1 for the blob from the commit
object by "ls-tree $commit $blob_path".
With your two patches, they need to do this with "-r".
git-checkout and git-reset use -r to grab the whole tree, so
they are fine either way. git-svnimport uses -r to read from a
tree (potentially a subtree) all the way down, so this one is
also fine.
So it probably is safer to default ls_options to LS_RECURSIVE,
and use "-d" to restrict it not to recurse.
But after seeing some more examples, I tend to think the current
one that models after how "/bin/ls -a" works in a way that is a
lot easier to understand. For example, with your two patches
(defaulting to recursive)
git-ls-tree HEAD
shows everything from the tree. In order to get prettyprint of
HEAD tree (i.e. single level listing):
git-ls-tree -d HEAD
is needed. But there is no way to get the single level with
pathspec with these patches, so:
cd Documentation && git-ls-tree -d HEAD
would not show the single level of Documentation tree, but just
a single line "tree" object of Documentation tree. Which means
the way it works from the top and the way it works in a
subdirectory is quite different.
I'll throw in your two patches to the proposed updates branch so
that Porcelain/Browser people can play with it and decide. I
really love the decrease of number of lines of code, but I am
afraid this would end up breaking things without real merit.
^ permalink raw reply
* Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
From: Junio C Hamano @ 2005-11-28 6:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511280248020.12343@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I only realized that we -- in the good tradition of UNIX -- have many
> different formats for different configurations: Some configurations are in
> .gitignore, some are in .git/branches/, some in .git/remotes/, some in
> .git/config, and even some in environment variables!
Can you live with something like this?
- we will add new ones to config, now we have it;
- we will not deprecate existing ones outside of config for some time;
- we will not duplicate/move existing ones into config at least
for now to keep our work less complicated;
- we would revisit deprecating things outside config file
sometime later after 1.0 stabilizes, and that's when we will
talk about moving these things into config.
^ permalink raw reply
* Re: [PATCH 2/3] mailinfo: allow -u to fall back on latin1 to utf8 conversion.
From: H. Peter Anvin @ 2005-11-28 6:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v7jat61xq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> When the message body does not identify what encoding it is in,
> -u assumes it is in latin-1 and converts it to utf8, which is
> the recommended encoding for git commit log messages.
>
> With -u=<encoding>, the conversion is made into the specified
> one, instead of utf8, to allow project-local policies.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
-u= is very odd syntax. Typically you see "-u argument" (sometimes you
have "-u" and "-U argument" as a pair); --foo=argument is used for long
options, although even there "--foo argument" tends to be used at least
when the argument is required.
Incidentally, any reason we're not using getopt_long() for command-line
parsing?
-hpa
^ permalink raw reply
* Re: lost again on syntax change - local repository?
From: Alecs King @ 2005-11-28 6:36 UTC (permalink / raw)
To: git
In-Reply-To: <7v7jat2w6u.fsf@assigned-by-dhcp.cox.net>
On Sun, Nov 27, 2005 at 09:11:37PM -0800, Junio C Hamano wrote:
> $ echo >.git/remotes/origin <<EOF
^^^^ you probably meant 'cat'. :)
> URL: /path/to/remote.git/
> Push: master
> Pull: master:origin
> EOF
> $ git push origin
--
Alecs King
^ permalink raw reply
* Re: [PATCH 6/8] ls-tree: work from subdirectory.
From: Linus Torvalds @ 2005-11-28 6:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsol1ett.fsf@assigned-by-dhcp.cox.net>
On Sun, 27 Nov 2005, Junio C Hamano wrote:
>
> So it probably is safer to default ls_options to LS_RECURSIVE,
> and use "-d" to restrict it not to recurse.
I have a patch that solves all the problems, I think.
It modifies the selection a bit, so that a pathspec that is a superset of
a particular tree path will always cause it to recurse into that tree.
As an example, let's say that we do
git-ls-tree HEAD drivers/char
_without_ the "-r". What will happen is that it will start out doing all
the base tree, and for "drivers" it will notice that it's a proper subset
of "drivers/char", so it will always recurse into _that_ tree (but not
into other trees).
Then, it will not match anything else than "char" in that subdirectory,
and because that's not a proper superset (it's an exact match), it will
_not_ recurse into it, so you get:
[torvalds@g5 linux]$ ~/git/git-ls-tree HEAD drivers/char
040000 tree 9568cda453aae205bb58983747fa73b9696d9d51 drivers/char
which is what you got with the old git-ls-tree too.
But interestingly, if you add the slash, it will become a proper superset
and it will recurse into _that_ subdirectory (but no deeper: so if you
want all subdirectories _below_ drivers/char/, you still need to give
"-r"):
[torvalds@g5 linux]$ ~/git/git-ls-tree HEAD drivers/char/
100644 blob 2b6b1d772ed776fff87927fc34adc2e40500218e drivers/char/.gitignore
100644 blob 56b8a2e76ab10a5c21787cb7068a846075cbaffd drivers/char/ChangeLog
100644 blob 970f70d498f4c814e1cf3362e33d7e23ac53c299 drivers/char/Kconfig
...
See? This is on top of the previous two diffs, holler if you want a whole
new "everything combined" version..
It hasn't gotten lots of testing, but it should work.
BTW! It fails a few of the tests, but it does so because now, with "-r",
it will never show the tree entries, and because of the difference between
git-ls-tree $tree path
and
git-ls-tree $tree path/
that it didn't use to have (oh, and if you give multiple paths, it will
now always consider them a "union pathspec", not an "iteration of paths").
But I _think_ the new behaviour is pretty useful and while not the same as
"ls", it's perhaps still intuitive enough..
Linus
---
diff --git a/ls-tree.c b/ls-tree.c
index cf0dbbc..4df5830 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -11,7 +11,8 @@
static int line_termination = '\n';
#define LS_RECURSIVE 1
#define LS_TREE_ONLY 2
-static int ls_options = LS_RECURSIVE;
+static int ls_options = 0;
+const char **pathspec;
static const char ls_tree_usage[] =
"git-ls-tree [-d] [-r] [-z] <tree-ish> [path...]";
@@ -21,8 +22,29 @@ static int show_tree(unsigned char *sha1
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;
+ }
+ }
type = "tree";
}
@@ -32,7 +54,7 @@ static int show_tree(unsigned char *sha1
int main(int argc, const char **argv)
{
- const char **path, *prefix;
+ const char *prefix;
unsigned char sha1[20];
char *buf;
unsigned long size;
@@ -60,11 +82,11 @@ int main(int argc, const char **argv)
if (get_sha1(argv[1], sha1) < 0)
usage(ls_tree_usage);
- path = get_pathspec(prefix, argv + 2);
+ pathspec = get_pathspec(prefix, argv + 2);
buf = read_object_with_reference(sha1, "tree", &size, NULL);
if (!buf)
die("not a tree object");
- read_tree_recursive(buf, size, "", 0, 0, path, show_tree);
+ read_tree_recursive(buf, size, "", 0, 0, pathspec, show_tree);
return 0;
}
^ permalink raw reply related
* keeping remote repo checked out?
From: James Cloos @ 2005-11-28 7:13 UTC (permalink / raw)
To: git
I am testing git as a replacement for how I was using bk to manage web
sites. As such, I created a new git repo on the server, populated it
with the old data (ignoring history; there wasn't much relevant on
that site) and cloned that to the laptop.
Editing on the server works well. I can add, checking and a
subsequent pull on the laptop grabs the changes.
But any edits on the laptop's copy are not checked out when I push
them to the server.
Is it possible to arrange that a push does a checkout on the remote
the same way a pull does on the local?
-JimC
--
James H. Cloos, Jr. <cloos@jhcloos.com>
^ permalink raw reply
* Re: git-mv: fully detect 'directory moved into itself'
From: Matthias Urlichs @ 2005-11-28 6:54 UTC (permalink / raw)
To: git
In-Reply-To: <200511272206.43113.Josef.Weidendorfer@gmx.de>
Hi, Josef Weidendorfer wrote:
> + if (($bad eq "") && ($dst =~ /^$src\//)) {
That should be
> + if (($bad eq "") && ($dst =~ /^\Q$src\E\//)) {
otherwise you will mistakenly match "foo-bar" with "foo.bar".
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
If people drank ink instead of Schlitz, they'd be better off.
-- Edward E. Hippensteel
[What brand of ink? Ed.]
^ permalink raw reply
* use binmode(STDOUT) in git-status
From: Alex Riesen @ 2005-11-28 7:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 178 bytes --]
Activision's Perl generates CRLF unless STDOUT is binmoded, which is
inconsistent with other output of git-status.
---
I assume none _sane_ can want CRLF as line-ending...
[-- Attachment #2: 0001-use-binmode-on-STDOUT-to-avoid-generation-of-CRLF-by-activision-perl.txt --]
[-- Type: text/plain, Size: 778 bytes --]
Subject: [PATCH] use binmode on STDOUT to avoid generation of CRLF by activision perl
Signed-off-by: Alex Riesen <fork0@gmail.com>
---
git-status.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
applies-to: c64901fa1a7f5fa19d025a315bcd1e5d5eae5d93
0fc9f4bdb41725d2b2b54e70ff4740bdb826bdea
diff --git a/git-status.sh b/git-status.sh
index b90ffc1..2fc7595 100755
--- a/git-status.sh
+++ b/git-status.sh
@@ -82,13 +82,14 @@ else
--exclude-per-directory=.gitignore
fi |
perl -e '$/ = "\0";
+ binmode(STDOUT);
my $shown = 0;
while (<>) {
chomp;
s|\\|\\\\|g;
s|\t|\\t|g;
s|\n|\\n|g;
- s/^/# /;
+ s/^/#\t/;
if (!$shown) {
print "#\n# Untracked files:\n";
print "# (use \"git add\" to add to commit)\n#\n";
---
0.99.9.GIT
^ permalink raw reply related
* Re: keeping remote repo checked out?
From: Junio C Hamano @ 2005-11-28 7:48 UTC (permalink / raw)
To: James Cloos; +Cc: git
In-Reply-To: <m3k6et9rdw.fsf@lugabout.cloos.reno.nv.us>
James Cloos <cloos@jhcloos.com> writes:
> Is it possible to arrange that a push does a checkout on the remote
> the same way a pull does on the local?
Creative use of hooks/post-update would solve that.
However, you should be very careful if you sometimes edit on
server and sometimes push from other machine to the server on
the same branch on the server.
^ permalink raw reply
* Re: [PATCH 6/8] ls-tree: work from subdirectory.
From: Junio C Hamano @ 2005-11-28 8:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511272219420.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> BTW! It fails a few of the tests, but it does so because now, with "-r",
> it will never show the tree entries, and because of the difference between
>
> git-ls-tree $tree path
>
> and
>
> git-ls-tree $tree path/
>
> that it didn't use to have (oh, and if you give multiple paths, it will
> now always consider them a "union pathspec", not an "iteration of paths").
> But I _think_ the new behaviour is pretty useful and while not the same as
> "ls", it's perhaps still intuitive enough..
The difference between path and path/ is very cute ;-). I do
not do Porcelain myself, so I am OK with this change, but this
would involve some changes to the Porcelain.
So let's cook this for a while and have Porcelain people holler
if they find something lacking. I'll put this in the proposed
updates tonight, and we will plan to push everything in the
proposed updates branch to the master branch on Wednesday, with
any fixes and updates necessary.
^ permalink raw reply
* Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
From: Andreas Ericsson @ 2005-11-28 8:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vfyph1ebq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>
>>I only realized that we -- in the good tradition of UNIX -- have many
>>different formats for different configurations: Some configurations are in
>>.gitignore, some are in .git/branches/, some in .git/remotes/, some in
>>.git/config, and even some in environment variables!
>
>
> Can you live with something like this?
>
> - we will add new ones to config, now we have it;
>
I'd still like to see git-repo-config and git-user-config. Otherwise
we'll need to continue having user-based environment variables
(GIT_COMMITTER_IDENT and friends).
>
> - we would revisit deprecating things outside config file
> sometime later after 1.0 stabilizes, and that's when we will
> talk about moving these things into config.
>
GIT_DIR and GIT_OBJECT_DIR must remain environment variables (or command
line arguments) more or less indefinitely. It doesn't make sense to keep
them any other way.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Perl version support (was Re: [PATCH] git-mv is not able to handle big directories)
From: Andreas Ericsson @ 2005-11-28 8:49 UTC (permalink / raw)
To: git
In-Reply-To: <438A6175.2020705@michonline.com>
Ryan Anderson wrote:
> Randal L. Schwartz wrote:
>
>>However, I have not seen the "target market" of git discussed yet
>>(I came late to the party), so if support for 5.6 (or 5.5) is not chosen,
>>it merely limits the market.
>
>
> Well, I think the general target market[1] for Linux probably applies
> here, as well. On the other hand, the users limited to Perl 5.5 for
> corporate reasons are probably also prevented from installing new tools
> for general use, so the difference may not matter very much.
>
> [1] - "World domination", of course.
>
Servers with software installation restrictions are rarely used for
development either and the server side part of git is all C. So long as
that's true I don't think we need to bother very much with staying
backwards compatible. It's nice if we manage it, but we shouldn't, imho,
bend over backwards for the sake of perl 5.5 (or even 5.6).
Just my two öre. :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-send-mail in sh
From: Andreas Ericsson @ 2005-11-28 9:02 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <438A5401.3070008@michonline.com>
Ryan Anderson wrote:
> Andreas Ericsson wrote:
>
>>When I try to install Email::Valid (using apt) it wants an additional
>>two modules. Mail::Sendmail wants one other, so that's Data::Dumper, the
>>two actually used and the three those two use. Six, for short.
>
>
> Can I ask why you aren't willing to install packages, such as those? I
> can understand a reluctance to install modules directly from CPAN, on an
> otherwise package-managed system, but I'm afraid I must confess to
> puzzlement over a reluctance to use pre-packaged modules.
>
I don't like having lots of junk installed. Besides, I do a lot of
development work for the Openwall distro which tries fairly hard to get
away without installing lots of cruft. I'd rather not taint it with
packages from other vendors since I do a fair amount of RPM building and
testing on it but I still want to be able to use git on it.
> The major flaw in git-send-email, from my perspective, was a lack of
> support for SMTP AUTH, for situations like Junio's, where the local MTA
> (and thus "mail" as well) are not configured to handle SMTP AUTH. Moving
> to a purely shell based replacement seems to make this an even harder
> feature to support. (Though, admittedly, I haven't even made an attempt
> to add it to the Perl version yet.)
>
By "local" do you mean "local on Junio's laptop" or "local at cox.net"?
"mail" uses the "local on Junio's laptop" SMTP server so he can
configure it any way he wants.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
From: Junio C Hamano @ 2005-11-28 9:14 UTC (permalink / raw)
To: git
In-Reply-To: <438AC32E.5010100@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> I'd still like to see git-repo-config and git-user-config. Otherwise
> we'll need to continue having user-based environment variables
> (GIT_COMMITTER_IDENT and friends).
Since .git/config is not shared across repositories even on
clone (and is deliberately so), "git-repo-config user.name" is
for you to set *your* name.
Having said that, GIT_COMMITTER_IDENT and friends are there to
stay, because that is how you override what you get from the
config file per commit, which is needed for people playing the
integrator role. When one is playing an individual developer
role, user.name or even not having any and relying on GECOS is
often good enough.
^ permalink raw reply
* [PATCH] git-mv: fully detect 'directory moved into itself'
From: Josef Weidendorfer @ 2005-11-28 9:15 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <pan.2005.11.28.06.54.32.809941@smurf.noris.de>
This gives a better error message when trying to move a directory
into some subdirectory of itself; ie. no real bug fix: renaming
already failed before, but with a strange "invalid argument".
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
This is a corrected version.
On Monday 28 November 2005 07:54, Matthias Urlichs wrote:
> Hi, Josef Weidendorfer wrote:
>
> > + if (($bad eq "") && ($dst =~ /^$src\//)) {
>
> That should be
>
> > + if (($bad eq "") && ($dst =~ /^\Q$src\E\//)) {
>
> otherwise you will mistakenly match "foo-bar" with "foo.bar".
>
Ah, thanks.
You never end learning.
Josef
git-mv.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 5d83477de7a407ab0ef183c6676114e1a507cf86
3c1ed8adaff3f7492ef2afdb5585ae7412a02817
diff --git a/git-mv.perl b/git-mv.perl
index ac19876..bfe3c29 100755
--- a/git-mv.perl
+++ b/git-mv.perl
@@ -108,7 +108,7 @@ while(scalar @srcArgs > 0) {
}
}
- if (($bad eq "") && ($src eq $dstDir)) {
+ if (($bad eq "") && ($dst =~ /^\Q$src\E\//)) {
$bad = "can not move directory '$src' into itself";
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH 2/3] mailinfo: allow -u to fall back on latin1 to utf8 conversion.
From: Junio C Hamano @ 2005-11-28 9:21 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <438AA48B.8000808@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Junio C Hamano wrote:
>> When the message body does not identify what encoding it is in,
>> -u assumes it is in latin-1 and converts it to utf8, which is
>> the recommended encoding for git commit log messages.
>> With -u=<encoding>, the conversion is made into the specified
>> one, instead of utf8, to allow project-local policies.
>> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> -u= is very odd syntax.
Fair enough. "--encoding=<encoding>" then.
> Incidentally, any reason we're not using getopt_long() for command-line
> parsing?
There was a talk about using popt a while back but we never got
around to it, primarily because we were running too fast for
parties interested in command line parsing clean-ups to catch
up. I think we are almost done and immediately post 1.0 when
things stabilize may be a good time to do it if somebody wants
to go wild, but not before please.
^ permalink raw reply
* Re: [PATCH] git-mv: fully detect 'directory moved into itself'
From: Junio C Hamano @ 2005-11-28 9:24 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511281015.15188.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> This is a corrected version.
>
> On Monday 28 November 2005 07:54, Matthias Urlichs wrote:
>> Hi, Josef Weidendorfer wrote:
>>
>> > + if (($bad eq "") && ($dst =~ /^$src\//)) {
>>
>> That should be
>>
>> > + if (($bad eq "") && ($dst =~ /^\Q$src\E\//)) {
>>
>> otherwise you will mistakenly match "foo-bar" with "foo.bar".
>
> Ah, thanks.
> You never end learning.
Why not use $safesrc you already have for this exact purpose?
^ 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