* [PATCH 2/3] ls-files --others --directory: give trailing slash
From: Junio C Hamano @ 2006-01-07 22:31 UTC (permalink / raw)
To: git, Darrin Thompson
This adds a trailing slash to directory names in the output
when "--others --directory" option shows only untracked
directories and not their contents, to make them stand out.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Likes, dislikes? This suits better for *my* purpose of
calling this from git-status, but it might be undesirable for
your Porcelain.
ls-files.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
02e90a13cce6041263ec90da77f2ba929055b448
diff --git a/ls-files.c b/ls-files.c
index cc5b32e..7e2fdea 100644
--- a/ls-files.c
+++ b/ls-files.c
@@ -294,8 +294,10 @@ static void read_directory(const char *p
case DT_DIR:
memcpy(fullname + baselen + len, "/", 2);
if (show_other_directories &&
- !dir_exists(fullname, baselen + len + 1))
+ !dir_exists(fullname, baselen + len + 1)) {
+ len++;
break;
+ }
read_directory(fullname, fullname,
baselen + len + 1);
continue;
--
1.0.7-g0263
^ permalink raw reply related
* [PATCH] Lower priority of Cogito's default exclude patterns
From: Karl Hasselström @ 2006-01-07 22:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Put the default exclude patterns in a file referenced with
--exclude-from, instead of on the command line with --exclude. (The
existing behavior was bad since --exclude has higher priority than
--exclude-from and --exclude-per-directory, which made it impossible
for the user to override the default patterns.)
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Makefile | 15 +++++++++++++--
cg-Xlib | 6 +++++-
cg-default-exclude | 6 ++++++
3 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 700491f..9ec9d07 100644
--- a/Makefile
+++ b/Makefile
@@ -3,6 +3,7 @@ prefix=$(HOME)
bindir=$(prefix)/bin
libdir=$(prefix)/lib/cogito
+sharedir=$(prefix)/share/cogito
INSTALL?=install
@@ -25,6 +26,8 @@ GEN_SCRIPT= cg-version
VERSION= VERSION
+SHARE_FILES= cg-default-exclude
+
### Build rules
@@ -62,6 +65,7 @@ test: all
### Installation rules
sedlibdir=$(shell echo $(libdir) | sed 's/\//\\\//g')
+sedsharedir=$(shell echo $(sharedir) | sed 's/\//\\\//g')
.PHONY: install install-cogito install-doc
install: install-cogito
@@ -83,14 +87,20 @@ install-cogito: $(SCRIPT) $(LIB_SCRIPT)
$(INSTALL) $(LIB_SCRIPT) $(DESTDIR)$(libdir)
cd $(DESTDIR)$(bindir); \
for file in $(SCRIPT) $(GEN_SCRIPT); do \
- sed -e 's/\$${COGITO_LIB}/"\$${COGITO_LIB:-$(sedlibdir)\/}"/g' $$file > $$file.new; \
+ sed -e 's/\$${COGITO_LIB}/"\$${COGITO_LIB:-$(sedlibdir)\/}"/g' $$file \
+ | sed -e 's/\$${COGITO_SHARE}/"\$${COGITO_SHARE:-$(sedsharedir)\/}"/g' \
+ > $$file.new; \
cat $$file.new > $$file; rm $$file.new; \
done
cd $(DESTDIR)$(libdir); \
for file in $(LIB_SCRIPT); do \
- sed -e 's/\$${COGITO_LIB}/"\$${COGITO_LIB:-$(sedlibdir)\/}"/g' $$file > $$file.new; \
+ sed -e 's/\$${COGITO_LIB}/"\$${COGITO_LIB:-$(sedlibdir)\/}"/g' $$file \
+ | sed -e 's/\$${COGITO_SHARE}/"\$${COGITO_SHARE:-$(sedsharedir)\/}"/g' \
+ > $$file.new; \
cat $$file.new > $$file; rm $$file.new; \
done
+ $(INSTALL) -m755 -d $(DESTDIR)$(sharedir)
+ $(INSTALL) -m644 $(SHARE_FILES) $(DESTDIR)$(sharedir)
install-doc:
$(MAKE) -C Documentation install
@@ -98,6 +108,7 @@ install-doc:
uninstall:
cd $(DESTDIR)$(bindir) && rm -f $(SCRIPT) $(GEN_SCRIPT)
cd $(DESTDIR)$(libdir) && rm -f $(LIB_SCRIPT)
+ cd $(DESTDIR)$(sharedir) && rm -f $(SHARE_FILES)
diff --git a/cg-Xlib b/cg-Xlib
index 46a8a73..b1d1561 100755
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -190,9 +190,13 @@ list_untracked_files()
excludeflag="$1"; shift
EXCLUDE=()
if [ "$excludeflag" != "no" -a "$excludeflag" != "noexclude" ]; then
- for excl in '*.[ao]' '.*' '!.gitignore' tags '*~' '#*' "$@"; do
+ for excl in "$@"; do
EXCLUDE[${#EXCLUDE[@]}]="--exclude=$excl"
done
+ EXCLUDEFILE="${COGITO_SHARE}cg-default-exclude"
+ if [ -f "$EXCLUDEFILE" ]; then
+ EXCLUDE[${#EXCLUDE[@]}]="--exclude-from=$EXCLUDEFILE"
+ fi
EXCLUDEFILE="$_git/info/exclude"
if [ -f "$EXCLUDEFILE" ]; then
EXCLUDE[${#EXCLUDE[@]}]="--exclude-from=$EXCLUDEFILE"
diff --git a/cg-default-exclude b/cg-default-exclude
new file mode 100644
index 0000000..f24dad6
--- /dev/null
+++ b/cg-default-exclude
@@ -0,0 +1,6 @@
+*.[ao]
+.*
+!.gitignore
+tags
+*~
+#*
^ permalink raw reply related
* Re: [PATCH] debian/ directory
From: Junio C Hamano @ 2006-01-07 22:05 UTC (permalink / raw)
To: Yann Dirson; +Cc: Gerrit Pape, git
In-Reply-To: <20060107111948.GC32585@nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> Well, it's probably still a quick way to produce snapshot packages
> when needed. An alternative could be to have Norbert's tree
> accessible, and possibly advertized in the docs, so a simple merge
> would be sufficient to build a snapshot package.
I took a brief look at backports.org and git-core_$V.diff there.
It is my understanding that Norbert's tree is essentially a copy
of Gerrit's, with inevitable differences in debian/changelog.
If we _were_ to replace it with something else, I'd rather get
patches fed from Gerrit.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.7
From: H. Peter Anvin @ 2006-01-07 21:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkxreo9e.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>
>>Any reason to not just do:
>>
>> struct frotz {
>> int xyzzy;
>> char nitfol[1]; /* more */
>> };
>>
>>... which should work on all compilers?
>
> Laziness, especially to avoid having to deal with comments like
> "your xmalloc(sizeof(struct frotz) + strlen(nitfol) + 1) should be
> xmalloc(sizeof(struct frotz) + strlen(nitfol)), because you
> have already one byte for nitfol element."
>
In the case of strings, that's probably a blessing (already accounted
for the null byte).
-hpa
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.7
From: Junio C Hamano @ 2006-01-07 21:12 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43C028CA.8090702@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Any reason to not just do:
>
> struct frotz {
> int xyzzy;
> char nitfol[1]; /* more */
> };
>
> ... which should work on all compilers?
Laziness, especially to avoid having to deal with comments like
"your xmalloc(sizeof(struct frotz) + strlen(nitfol) + 1) should be
xmalloc(sizeof(struct frotz) + strlen(nitfol)), because you
have already one byte for nitfol element."
^ permalink raw reply
* Re: needs merge
From: Junio C Hamano @ 2006-01-07 21:06 UTC (permalink / raw)
To: Brown, Len; +Cc: git, Daniel Barkalow
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005A1336F@hdsmsx401.amr.corp.intel.com>
"Brown, Len" <len.brown@intel.com> writes:
> yes, it did the right thing to the source.
>
> as a user, "cute" isn't the first word that comes to mind:-)
Fair enough. I agree that it is rather unnerving from the
user's point of view, especially because the "recursive merging
of the ancestors" part is not trivially obvious why it works.
The issue it tries to address (and the other merge strategy,
"resolve", addresses a bit differently) is to detect when two
sides of criss-cross merged branches resolved the same conflicts
differently in the past. When merging E and F in this ancestry
graph:
A----C---E----?
/ \ / /
/ \/ /
/ /\ /
/ / \ /
O----B----D---F
suppose that A and B made conflicting modifications on path P, C
and D resolved the conflicts by taking its own side, and E and F
further made independent changes to the path.
When we try to merge E and F, if we happen to pick B as the
merge base, normal three-way merge between E and F using B as
base would say that E has change between B and C while F's
version stayed the same in the area that change touches, and you
would end up with merge result that is diff(D,F) on top of E.
If we used A, then the result would be diff(C,E) on top of F.
Doing either of these silently is not desirable [*1*].
When we use a tree that is an automerge (with conflict markers)
between A and B as the merge base for E and F, what happens is
that the three-way merge notices the part with conflict markers
as a whole is rewritten to one version in E and to another in F,
removes the original (which is the conflicting merge between A
and B) and replaces that with conflicts between E and F with its
own conflict markers, so decision to resolve the conflicting
merge between A and B which C and D resolved differently is
given to the user who tries to merge E and F.
If C and D resolved the conflicting merge the same way, the
"phantom conflict" you observed still happens while merging A
and B to come up with the merge base tree, but the part will be
rewritten the same way in both E and F, so the result will merge
cleanly.
[Footnote]
*1* While I was trying out the above scenario, I noticed that
resolve strategy does not notice this and ended up picking one
ancestor at random. I think this is because case #16 covers
only the case where the path P is not changed between C and E
and D and F, and case #11 must pick an ancestor and picks one at
random. Daniel, any thoughts on this?
-- >8 --
#!/bin/sh
unset GIT_DIR GIT_OBJECT_DIRECTORY
test -d .git || {
echo Run this in a newly created empty directory please.
exit 1
}
: <<\EOF
Criss Cross Merge
A----C---E----?
/ \ / /
/ \/ /
/ /\ /
/ / \ /
O----B----D---F
EOF
git init-db
for l in a b c d e f g h i j k l m n o p q r s t u v w x y z
do
echo $l
done >testfile
git add testfile
git commit -m 'Initial'
git tag O
git branch bottom
git checkout -b top
cp testfile testfile.orig
tr 'm-p' 'M-P' <testfile.orig >testfile
git update-index testfile
git commit -m A
git tag A
git checkout bottom
tr 'm-p' 'A-D' <testfile.orig >testfile
git update-index testfile
git commit -m B
git tag B
git merge -s ours 'D=A+B=B' HEAD A
git tag D
git checkout top
git merge -s ours 'C=A+B=A' HEAD B
git tag C
mv testfile j; tr 'a' 'A' <j >testfile; rm -f j
git update-index testfile
git commit -m E
git tag E
git checkout bottom
mv testfile j; tr 'z' 'Z' <j >testfile; rm -f j
git update-index testfile
git commit -m F
git tag F
rm -f testfile.orig
git checkout master
git reset --hard A
git merge -s resolve V HEAD B
git update-index testfile
git commit -m 'V'
git tag V
git show-branch
git checkout top
echo "** RECURSIVE **"
git merge -s recursive recursive HEAD F
echo theirs
git diff --theirs
echo ours
git diff --ours
git reset --hard
echo "** RESOLVE **"
git merge -s resolve resolve HEAD F
echo theirs
git diff HEAD^2
echo ours
git diff HEAD^
^ permalink raw reply
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Junio C Hamano @ 2006-01-07 21:04 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Alex Riesen, git
In-Reply-To: <86sls0498w.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>> Being as I'm a *bit* familiar with Perl, I'd write that as:
>>>
>>> print H "$_\0" for @deletedfiles;
>
> ... It was added for Perl 5.5, first released on 22 July 1998.
BTW, I never understood the usefulness of Statement Modifiers.
Even reading the examples in perlsyn.pod:
print "Basset hounds got long ears" if length $ear >= 10;
go_outside() and play() unless $is_raining;
seeing "do these things" upfront and then realize "ah, but that
is done only when this holds true", interrupts the flow of
understanding while reading a program by somebody else [*1*].
It is worse if the Statement Modifier is a loop control.
(flamebait) Compound Statements take BLOCK and people who want
to do a one-liner could not do so without braces. I've always
thought Statement Modifies as a lame workaround for that
problem.
[Footnote]
*1* This is true even for me; my mother language is Japanese,
which tends to hang negation at the tail of the sentence, and
double negation is not unusual. This makes it impossible to
know what a sentence states before reading it to the end, so I
am used to that "coming back to the main part after reading
through the sentence", but I do not welcome that when I am
reading programs.
^ permalink raw reply
* Re: Does git belong in root's $PATH?
From: H. Peter Anvin @ 2006-01-07 20:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: walt, Sam Ravnborg, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601071023250.3169@g5.osdl.org>
Linus Torvalds wrote:
>
> Maybe it would be best to remove the "vmlinux" dependency from "make
> install" (so that "make install" will do exactly that: just install). I
> think all the documentation already tells you to do a "make" and then a
> "make install".
>
I would very much agree with this change; it's a nuisance that "make
install" can't be cleanly run as root without leaving root turds in the
build directory.
(Speaking as the person who did the original "make install" patch about
12 years ago.)
-hpa
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.7
From: H. Peter Anvin @ 2006-01-07 20:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: YOSHIFUJI Hideaki / 吉藤英明, git
In-Reply-To: <7vmzi8mkdi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Here is what I am planning to merge into the master/maint. The
> patch is for maint which does not ship with describe, but the
> problematic path[] can be updated to path[FLEX_ARRAY] as others
> when merging it to the master branch.
>
> -- >8 --
> Subject: [PATCH] Compilation: zero-length array declaration.
>
> ISO C99 (and GCC 3.x or later) lets you write a flexible array
> at the end of a structure, like this:
>
> struct frotz {
> int xyzzy;
> char nitfol[]; /* more */
> };
>
> GCC 2.95 lets you to do this with "char nitfol[0]";
> unfortunately this is not allowed by ISO C90.
>
> This declares such construct like this:
>
> struct frotz {
> int xyzzy;
> char nitfol[FLEX_ARRAY]; /* more */
> };
>
> and git-compat-util.h defines FLEX_ARRAY to 0 for gcc 2.95 and
> empty for others.
>
> Although I have not tried this myself, if you are using a C90 C
> compiler, you should be able to override this with
> CFLAGS=-DFLEX_ARRAY=1 from the command line of "make".
>
Any reason to not just do:
struct frotz {
int xyzzy;
char nitfol[1]; /* more */
};
... which should work on all compilers?
-hpa
^ permalink raw reply
* Re: Does git belong in root's $PATH?
From: H. Peter Anvin @ 2006-01-07 20:40 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: walt, git
In-Reply-To: <43C0025A.9080406@op5.se>
Andreas Ericsson wrote:
>
> Not including /usr/local/{bin,sbin} in root's path is considered wise,
> since, historically, that's where users would install their own versions
> of programs that the system doesn't provide. This use has largely been
> obsoleted by $HOME/bin as the default for user-specific programs, mainly
> because of disks getting larger and cheaper.
>
Hmmm... I think that was /usr/bin (hence the eventual migration of the
meaning of /usr from what was originally the equivalent of /home.)
Today /usr/local is strictly a location for site-local things; a place
that won't conflict with the distribution.
-hpa
^ permalink raw reply
* Re: git-ls-files -o no recurse?
From: Linus Torvalds @ 2006-01-07 19:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Darrin Thompson, Git Mailing List
In-Reply-To: <7vace7khbi.fsf@assigned-by-dhcp.cox.net>
On Sat, 7 Jan 2006, Junio C Hamano wrote:
>
> I have been unsure about the name "--directory", like you said.
Well, I didn't like "--directory" either, but couldn't come up with
anything better. How about just "--no-recurse", which is not technically
accurate (we always recurse into directories we know about), but might be
more understandable.
The reason I called it "--directory" was that it would talk about
directories that it doesn't know about (as opposed to individual files it
doesn't know about). So "--other --directory" kind of makes sense if you
read it that way ("show files and directories we don't know about").
But yeah, it's not a great name.
Linus
^ permalink raw reply
* Re: git format-patch shell quoting bug
From: Kyle McMartin @ 2006-01-07 19:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd8gpxt3.fsf@assigned-by-dhcp.cox.net>
On Fri, Jan 06, 2006 at 06:38:16PM -0800, Junio C Hamano wrote:
> commit aa66c7ec77d474b737da607d6cb2d07f56628def
> Author: Junio C Hamano <junkio@cox.net>
> Date: Thu Jan 5 19:50:37 2006 -0800
>
> format-patch/commit: Quote single quote in the author name properly.
>
> Noticed by Kyle McMartin.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> The bug was present ever since format-patch started picking up
> the original authorship information from the commits, done on
> July 22nd last year, between v0.99.1 and v0.99.2.
>
Awesome. Thanks very much for fixing this!
Cheers,
Kyle
^ permalink raw reply
* Re: git-ls-files -o no recurse?
From: Junio C Hamano @ 2006-01-07 18:45 UTC (permalink / raw)
To: Darrin Thompson; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <1136658207.6141.4.camel@localhost.localdomain>
Darrin Thompson <darrint@progeny.com> writes:
> Here's a rejiggered version of the original Linus patch. The names have
> been changed a little.
>
> Enjoy.
>
> It prevents git from recursing into "other" directories when used with
> the -o option.
Looks same to what I have in the proposed updates branch, so we
are on the same page. Thanks.
I have been unsure about the name "--directory", like you said.
The most accurate one I thought of so far is:
--dont-recurse-into-directories-without-tracked-files
but it is way too long. We cannot even say "untracked
directories" (we do not track directories) to shorten it a bit.
^ permalink raw reply
* Re: Does git belong in root's $PATH?
From: Linus Torvalds @ 2006-01-07 18:31 UTC (permalink / raw)
To: walt, Sam Ravnborg; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601070838470.6317@x2.ybpnyarg>
On Sat, 7 Jan 2006, walt wrote:
>
> When updated my kernel this morning, the same way I've been doing
> it for many months, I noticed that the -gxxxxxxx localversion
> string was missing from the new kernel's name.
>
> I finally figured out that this happened because /usr/local/bin
> is not in my root's $PATH, and the setlocalversion script depends
> on git. (The only thing I do as root is 'make install').
Ok, sounds like a build buglet to me. If you've done a "make" as a regular
user, and just do a "make install" as root, I'd argue that the "make
install" should do as little as humanly possible, and literally just
install the kernel. If it starts changing the version, that sounds a bit
fishy.
Sam, anything we can do?
That said:
> I suppose I'm asking a philosophical question here: do you
> guys install git where root can find it (as a system tool)?
I don't, but I don't use "make install" anyway, I just do "make
modules_install". I install the kernel by hand, I always have.
Of course, that's partly because I've always felt that "make install" does
too much (I think "make modules_install" is better - it really only
installs the already-built modules).
Maybe it would be best to remove the "vmlinux" dependency from "make
install" (so that "make install" will do exactly that: just install). I
think all the documentation already tells you to do a "make" and then a
"make install".
The other make targets really _are_ different: "make fdimage" depends on
vmlinux, but that's because it literally just builds the image. "make
install" is special.
Sam, what say you? I forget what the kbuild mailing list is, but maybe
you can forward this suggestion there..
Linus
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.7
From: Junio C Hamano @ 2006-01-07 18:27 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git
In-Reply-To: <20060107151244.762e628f.vsu@altlinux.ru>
Sergey Vlasov <vsu@altlinux.ru> writes:
> There is also gcc 2.96, which also does not understand the C99 syntax.
> So we should use something like this instead:
>
> #if defined(__GNUC__) && (__GNUC__ < 3)
> #define FLEX_ARRAY 0
> #else
> #define FLEX_ARRAY /* empty */
> #endif
>
> (and be prepared to get complaints from users of other compilers).
Thanks.
^ permalink raw reply
* Re: git-ls-files -o no recurse?
From: Darrin Thompson @ 2006-01-07 18:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <7vk6ddq8x2.fsf@assigned-by-dhcp.cox.net>
Here's a rejiggered version of the original Linus patch. The names have
been changed a little.
Enjoy.
It prevents git from recursing into "other" directories when used with
the -o option.
---
ls-files.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
applies-to: 4e7e791ecc24975530de1f2855cf5f17f112140b
741ec8ad5b7f3717bb462c2becfd00974da7ec16
diff --git a/ls-files.c b/ls-files.c
index 5e9ac71..cba8ca1 100644
--- a/ls-files.c
+++ b/ls-files.c
@@ -19,6 +19,7 @@ static int show_stage = 0;
static int show_unmerged = 0;
static int show_modified = 0;
static int show_killed = 0;
+static int show_other_directories = 0;
static int line_terminator = '\n';
static int prefix_len = 0, prefix_offset = 0;
@@ -233,6 +234,19 @@ static void add_name(const char *pathnam
dir[nr_dir++] = ent;
}
+static int dir_exists(const char *dirname, int len)
+{
+ int pos = cache_name_pos(dirname, len);
+ if (pos >= 0)
+ return 1;
+ pos = -pos-1;
+ if (pos >= active_nr)
+ return 0;
+ if (strncmp(active_cache[pos]->name, dirname, len))
+ return 0;
+ return active_cache[pos]->name[len] == '/';
+}
+
/*
* Read a directory tree. We currently ignore anything but
* directories, regular files and symlinks. That's because git
@@ -280,6 +294,10 @@ static void read_directory(const char *p
continue;
/* fallthrough */
case DT_DIR:
+ if (show_other_directories) {
+ if (!dir_exists(fullname, baselen + len))
+ break;
+ }
memcpy(fullname + baselen + len, "/", 2);
read_directory(fullname, fullname,
baselen + len + 1);
@@ -622,6 +640,10 @@ int main(int argc, const char **argv)
show_killed = 1;
continue;
}
+ if (!strcmp(arg, "--directory")) {
+ show_other_directories = 1;
+ continue;
+ }
if (!strcmp(arg, "-u") || !strcmp(arg, "--unmerged")) {
/* There's no point in showing unmerged unless
* you also show the stage information.
---
0.99.9i
^ permalink raw reply related
* Re: git-ls-files -o no recurse?
From: Darrin Thompson @ 2006-01-07 18:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <7vk6ddq8x2.fsf@assigned-by-dhcp.cox.net>
This adds a test a test for the --directory option to git-ls-files.
Is '--directory' really what we want?
t/t3003-ls-files-others-directory.sh | 38
++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
create mode 100644 t/t3003-ls-files-others-directory.sh
applies-to: 5001806332081159b00c35291d6aea232ed7e909
d484a8477d430a5fb2cefd2cf7008a5973d1fea5
diff --git a/t/t3003-ls-files-others-directory.sh
b/t/t3003-ls-files-others-directory.sh
new file mode 100644
index 0000000..d1d3d86
--- /dev/null
+++ b/t/t3003-ls-files-others-directory.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Darrin Thompson
+# Based on an earlier test by Junio C Hamano
+#
+
+test_description='git-ls-files test (--others --directory)
+
+This test runs git-ls-files --others --directory with the following on
+the filesystem.
+
+ path0 - a file
+ path1 - a symlink
+ path2/file2 - a file in a directory
+
+The --directory option should cause path2 to be in the listing, but
+not path2/file2.
+'
+. ./test-lib.sh
+
+date >path0
+ln -s xyzzy path1
+mkdir path2
+date >path2/file2
+test_expect_success \
+ 'git-ls-files --directory --others to show output.' \
+ 'git-ls-files --directory --others >output'
+cat >expected <<EOF
+output
+path0
+path1
+path2
+EOF
+
+test_expect_success \
+ 'git-ls-files --directory --others should not pick up dir
contents.' \
+ 'diff output expected'
+test_done
---
0.99.9i
^ permalink raw reply related
* Re: Does git belong in root's $PATH?
From: Andreas Ericsson @ 2006-01-07 18:03 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0601070838470.6317@x2.ybpnyarg>
walt wrote:
> When updated my kernel this morning, the same way I've been doing
> it for many months, I noticed that the -gxxxxxxx localversion
> string was missing from the new kernel's name.
>
> I finally figured out that this happened because /usr/local/bin
> is not in my root's $PATH, and the setlocalversion script depends
> on git. (The only thing I do as root is 'make install').
>
> I suppose I'm asking a philosophical question here: do you
> guys install git where root can find it (as a system tool)?
I install it in /usr/bin. I don't *use* the git-tools as root though, so
I don't feel there's anything to worry about (well, at least no more
than for the other 2847 programs living in my $PATH).
> Does it really matter?
Theoretically, yes, but only if someone can trick you to, as root, doing
something with git which triggers some yet undiscovered bug and makes it
run code it was never meant to.
> (The linux distribution I use is very
> picky about what it includes in root's path...)
>
Not including /usr/local/{bin,sbin} in root's path is considered wise,
since, historically, that's where users would install their own versions
of programs that the system doesn't provide. This use has largely been
obsoleted by $HOME/bin as the default for user-specific programs, mainly
because of disks getting larger and cheaper.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Does git belong in root's $PATH?
From: walt @ 2006-01-07 17:21 UTC (permalink / raw)
To: git
When updated my kernel this morning, the same way I've been doing
it for many months, I noticed that the -gxxxxxxx localversion
string was missing from the new kernel's name.
I finally figured out that this happened because /usr/local/bin
is not in my root's $PATH, and the setlocalversion script depends
on git. (The only thing I do as root is 'make install').
I suppose I'm asking a philosophical question here: do you
guys install git where root can find it (as a system tool)?
Does it really matter? (The linux distribution I use is very
picky about what it includes in root's path...)
Thanks!
^ permalink raw reply
* Re: manual merge/fixup question
From: Luben Tuikov @ 2006-01-07 17:01 UTC (permalink / raw)
To: git
In-Reply-To: <20060107165506.67640.qmail@web31812.mail.mud.yahoo.com>
Ok, I think it does all of them...
Luben
--- Luben Tuikov <ltuikov@yahoo.com> wrote:
> git resolve or git merge fails, complaining
> about file(s) having conflicts. I go ahead and fix up
> those files and then update the index.
>
> Can I assume now that I can go ahead and do git commit,
> or is there any more/other files which need fixing?
>
> I.e. does git resolve/merge fail on the first file
> which needs fixing or would it go through all of them,
> and then report the ones which need fixing?
>
> Thanks,
> Luben
>
> -
> 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
>
^ permalink raw reply
* manual merge/fixup question
From: Luben Tuikov @ 2006-01-07 16:55 UTC (permalink / raw)
To: git
git resolve or git merge fails, complaining
about file(s) having conflicts. I go ahead and fix up
those files and then update the index.
Can I assume now that I can go ahead and do git commit,
or is there any more/other files which need fixing?
I.e. does git resolve/merge fail on the first file
which needs fixing or would it go through all of them,
and then report the ones which need fixing?
Thanks,
Luben
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.7
From: Sergey Vlasov @ 2006-01-07 12:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: YOSHIFUJI Hideaki, git
In-Reply-To: <7vmzi8mkdi.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
On Sat, 07 Jan 2006 01:56:41 -0800 Junio C Hamano wrote:
> +#if (__GNUC__ == 2) && (__GNUC_MINOR__ == 95)
> +#define FLEX_ARRAY 0
> +#else
> +#define FLEX_ARRAY /* empty */
> +#endif
There is also gcc 2.96, which also does not understand the C99 syntax.
So we should use something like this instead:
#if defined(__GNUC__) && (__GNUC__ < 3)
#define FLEX_ARRAY 0
#else
#define FLEX_ARRAY /* empty */
#endif
(and be prepared to get complaints from users of other compilers).
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH] Stgit - gitmergeonefile.py: handle removal vs. changes
From: Catalin Marinas @ 2006-01-07 11:23 UTC (permalink / raw)
To: Blaisorblade; +Cc: git
In-Reply-To: <200512301859.51000.blaisorblade@yahoo.it>
Blaisorblade wrote:
>The original patch hasn't been merged, nor (for what I see) anything else to
>fix this problem has been done.
>
>
Indeed, I forgot about it.
>I assume the patch was lost waiting for the discussion to settle down, but the
>patch can be merged, even changing the default choices in any way (see
>below).
>
>
I merged it as it is. I will think about the default options once I get
some time to fix the .local, .older and .remote extensions (give them
some meaningful names).
>Also, another note: I just found Bruce Eckel mentioning pychecker, which is a
>static code checker for Python (to perform the checks a compiler would
>normally do). I've not the time to investigate more myself, but I hope it can
>be useful to you.
>
>
Thanks. I'll give it a try.
Catalin
^ permalink raw reply
* Re: [PATCH] debian/ directory
From: Yann Dirson @ 2006-01-07 11:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, git
In-Reply-To: <7vzmm9rnj7.fsf@assigned-by-dhcp.cox.net>
On Fri, Jan 06, 2006 at 02:37:16PM -0800, Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> writes:
>
> > Thanks to Norbert Tretkowski, the git* and cogito packages are now
> > available for Debian sarge through http://backports.org/.
>
> Good to hear. Does that mean nobody would suffer if I drop
> debian/ subdirectory along with deb target in the main Makefile
> anymore? If so I would.
Well, it's probably still a quick way to produce snapshot packages
when needed. An alternative could be to have Norbert's tree
accessible, and possibly advertized in the docs, so a simple merge
would be sufficient to build a snapshot package.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: trivial: remove the dots at the end of file names
From: Junio C Hamano @ 2006-01-07 10:35 UTC (permalink / raw)
To: git
In-Reply-To: <20060107103202.GC5536@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> I hope so. Don't you ever use mouse copy-pasting?!
Not mouse, but I always work inside "screen" and use
copy&paste.
^ 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