* Re: What's in master and pu (aka when will 1.0rc4 be out)
From: Linus Torvalds @ 2005-11-27 19:32 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Junio C Hamano, git
In-Reply-To: <20051127151134.0eac7019.tihirvon@gmail.com>
On Sun, 27 Nov 2005, Timo Hirvonen wrote:
>
> Hmm.. would something like
>
> git-bisect --include drivers/char/drm/ --include include/ ...
>
> be easy to implement? That command would limit bisecting to only the
> commits that have changed files under those two directories.
Heh.
It was surprisingly easy to do.
The syntax is
git bisect start <pathspec>
followed by all the normal "git bisect good/bad" stuff.
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.
This involves small changes to make "git-rev-list --bisect" work in the
presense of a pathspec limiter, and then truly trivial (and that's the
broken part) changes to make "git bisect" save away and use the pathspec.
I tried one bisection, and a "git bisect visualize", and it all looked
correct. But hey, don't be surprised if it has problems.
Linus
---
diff --git a/git-bisect.sh b/git-bisect.sh
index d92993b..2455f00 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -33,7 +33,6 @@ bisect_autostart() {
}
bisect_start() {
- case "$#" in 0) ;; *) usage ;; esac
#
# Verify HEAD. If we were bisecting before this, reset to the
# top-of-line master first!
@@ -57,7 +56,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-bisect start $@" >"$GIT_DIR/BISECT_LOG"
+ echo "$@" > "$GIT_DIR/BISECT_NAMES"
}
bisect_bad() {
@@ -121,7 +121,7 @@ bisect_next() {
bad=$(git-rev-parse --verify refs/bisect/bad) &&
good=$(git-rev-parse --sq --revs-only --not \
$(cd "$GIT_DIR" && ls refs/bisect/good-*)) &&
- rev=$(eval "git-rev-list --bisect $good $bad") || exit
+ rev=$(eval "git-rev-list --bisect $good $bad -- $(cat $GIT_DIR/BISECT_NAMES)") || exit
if [ -z "$rev" ]; then
echo "$bad was both good and bad"
exit 1
@@ -131,7 +131,7 @@ bisect_next() {
git-diff-tree --pretty $rev
exit 0
fi
- nr=$(eval "git-rev-list $rev $good" | wc -l) || exit
+ nr=$(eval "git-rev-list $rev $good -- $(cat $GIT_DIR/BISECT_NAMES)" | wc -l) || exit
echo "Bisecting: $nr revisions left to test after this"
echo "$rev" > "$GIT_DIR/refs/heads/new-bisect"
git checkout new-bisect || exit
@@ -142,7 +142,7 @@ bisect_next() {
bisect_visualize() {
bisect_next_check fail
- gitk bisect/bad --not `cd "$GIT_DIR/refs" && echo bisect/good-*`
+ gitk bisect/bad --not `cd "$GIT_DIR/refs" && echo bisect/good-*` -- $(cat $GIT_DIR/BISECT_NAMES)
}
bisect_reset() {
diff --git a/rev-list.c b/rev-list.c
index e17f928..8020d97 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -350,7 +350,8 @@ static int count_distance(struct commit_
if (commit->object.flags & (UNINTERESTING | COUNTED))
break;
- nr++;
+ if (!paths || (commit->object.flags & TREECHANGE))
+ nr++;
commit->object.flags |= COUNTED;
p = commit->parents;
entry = p;
@@ -362,6 +363,7 @@ static int count_distance(struct commit_
}
}
}
+
return nr;
}
@@ -382,15 +384,20 @@ static struct commit_list *find_bisectio
nr = 0;
p = list;
while (p) {
- nr++;
+ if (!paths || (p->item->object.flags & TREECHANGE))
+ nr++;
p = p->next;
}
closest = 0;
best = list;
- p = list;
- while (p) {
- int distance = count_distance(p);
+ for (p = list; p; p = p->next) {
+ int distance;
+
+ if (paths && !(p->item->object.flags & TREECHANGE))
+ continue;
+
+ distance = count_distance(p);
clear_distance(list);
if (nr - distance < distance)
distance = nr - distance;
@@ -398,7 +405,6 @@ static struct commit_list *find_bisectio
best = p;
closest = distance;
}
- p = p->next;
}
if (best)
best->next = NULL;
^ permalink raw reply related
* Re: [PATCH 6/8] ls-tree: work from subdirectory.
From: Linus Torvalds @ 2005-11-27 19:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20051127182244.GK22159@pasky.or.cz>
On Sun, 27 Nov 2005, Petr Baudis wrote:
> Dear diary, on Sun, Nov 27, 2005 at 07:01:37PM CET, I got a letter
> where Linus Torvalds <torvalds@osdl.org> said that...
> > If you use "-r", it acts the way you'd expect. If you _don't_ use "-r", it
> > acts strangely, but very consistently with git-diff-tree: it only ever
> > shows the _first_ part of a pathname. So
> >
> > git-ls-tree HEAD drivers/char/
> >
> > should show just one entry: "drivers". While adding a "-r" should show all
> > files under drivers (and the trees leading up to it).
> >
> > And yes, you're right. That's a much bigger change by my suggested diff,
> > and more likely to cause confusion.
>
> 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?)
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_.
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).
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.
To get more a "git-ls-files" approach, this trivial patch (on top of my
previous one) enables recursion (and right now you can't disable it any
way), and doesn't show partial trees.
I could make it work much more like git-ls-files, in that it could accept
wildcards. Something like
git-ls-tree HEAD '*.c'
would show all C files (recursively), the same way git-ls-files does for
the index.
Hmm?
Linus
----
diff --git a/ls-tree.c b/ls-tree.c
index 598b729..cf0dbbc 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -11,7 +11,7 @@
static int line_termination = '\n';
#define LS_RECURSIVE 1
#define LS_TREE_ONLY 2
-static int ls_options = 0;
+static int ls_options = LS_RECURSIVE;
static const char ls_tree_usage[] =
"git-ls-tree [-d] [-r] [-z] <tree-ish> [path...]";
@@ -19,16 +19,15 @@ static const char ls_tree_usage[] =
static int show_tree(unsigned char *sha1, const char *base, int baselen, const char *pathname, unsigned mode, int stage)
{
const char *type = "blob";
- int retval = 0;
if (S_ISDIR(mode)) {
- type = "tree";
if (ls_options & LS_RECURSIVE)
- retval = READ_TREE_RECURSIVE;
+ return READ_TREE_RECURSIVE;
+ type = "tree";
}
printf("%06o %s %s\t%.*s%s%c", mode, type, sha1_to_hex(sha1), baselen, base, pathname, line_termination);
- return retval;
+ return 0;
}
int main(int argc, const char **argv)
^ permalink raw reply related
* Re: [PATCH 6/8] ls-tree: work from subdirectory.
From: Petr Baudis @ 2005-11-27 18:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511270949540.13959@g5.osdl.org>
Dear diary, on Sun, Nov 27, 2005 at 07:01:37PM CET, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> If you use "-r", it acts the way you'd expect. If you _don't_ use "-r", it
> acts strangely, but very consistently with git-diff-tree: it only ever
> shows the _first_ part of a pathname. So
>
> git-ls-tree HEAD drivers/char/
>
> should show just one entry: "drivers". While adding a "-r" should show all
> files under drivers (and the trees leading up to it).
>
> And yes, you're right. That's a much bigger change by my suggested diff,
> and more likely to cause confusion.
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?)
--
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/8] ls-tree: work from subdirectory.
From: Linus Torvalds @ 2005-11-27 18:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <7vr792fnta.fsf@assigned-by-dhcp.cox.net>
On Sun, 27 Nov 2005, Junio C Hamano wrote:
>
> True; that is more or less deliberate. The behaviour is
> modelled after what "/bin/ls -a" does.
Yes, I did realize, and maybe it's fine. It's just that right now,
git-ls-tree doesn't work like git-ls-files, which is kind of sad.
I suspect not a lot of people use git-ls-tree, and that's probably why it
never was updated to match anything else.
It would be nice (I think) if git-ls-tree matched git-ls-files the same
way git-diff-tree matches git-diff-files: exact same behaviour, except one
works on a tree and another on the index. And like the git-diff-*, the
index would always default to "-r", while for the tree version you would
have to specify it.
(Yeah, there are differences. git-ls-files has the "--others" etc logic,
but I think there are more similarities than differences).
> However, this patch changes its behaviour in another way, and
> that could impact Porcelains more than the removal of the "-d"
> option. Currently, "git-ls-tree <tree> $dir" shows what
> "/bin/ls -a -1 $dir" would show --- the tree for $dir itself and
> its immediate children. This patch changes it to show the tree
> for $dir and nothing else. In effect, "-d" becomes the default
> that you cannot turn off, except using "-r" to allow it go all
> the way down.
No, actually, it's even stranger than that.
If you use "-r", it acts the way you'd expect. If you _don't_ use "-r", it
acts strangely, but very consistently with git-diff-tree: it only ever
shows the _first_ part of a pathname. So
git-ls-tree HEAD drivers/char/
should show just one entry: "drivers". While adding a "-r" should show all
files under drivers (and the trees leading up to it).
And yes, you're right. That's a much bigger change by my suggested diff,
and more likely to cause confusion.
Linus
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Kay Sievers @ 2005-11-27 16:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vfypioi83.fsf@assigned-by-dhcp.cox.net>
On Sat, Nov 26, 2005 at 07:57:48PM -0800, Junio C Hamano wrote:
> Kay Sievers <kay.sievers@vrfy.org> writes:
> > On Sat, Nov 19, 2005 at 09:52:34AM -0800, Linus Torvalds wrote:
> >> On Sat, 19 Nov 2005, Junio C Hamano wrote:
> >> >
> >> > Well, some people on the list seem to think UTF-8 is the one and
> >> > only right encoding, so for them if the message does not
> >> > identify what it is in, assuming UTF-8 and not doing any
> >> > conversion is probably the right thing ;-).
> >>
> >> If you replace "assume" with "verify", then I agree.
> > I found some test code I did a while ago for validation of
> > filesystem labels, cause D-BUS diconnects your session, if you
> > send an invalid utf-8 string to the bus. :)
>
> Thanks. I take it that you are licensing this code to use in
> git when we doing what Linus suggests?
Sure, it's free to use under any version of the GPL git uses itself.
Thanks,
Kay
^ permalink raw reply
* [PATCH] cg-Xlib: use git-rev-parse to locate .git dir and set relpath
From: Jonas Fonseca @ 2005-11-27 15:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
diff --git a/cg-Xlib b/cg-Xlib
index dedbb62..e3c365f 100755
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -502,16 +502,10 @@ fi
_git=${GIT_DIR:-.git}
if [ ! "$_git_repo_unneeded" ] && [ ! "$GIT_DIR" ] && [ ! -d $_git ]; then
- rootpath=.
- # while not /
- while [ ! -d $rootpath/.git ] && [ "$(stat -c %i $rootpath)" != "$(stat -c %i $rootpath/..)" ]; do
- rootpath=../$rootpath
- done
- if [ -d $rootpath/.git ]; then
- mainpath="$(echo "$(pwd)/$rootpath" | normpath)"
- _git_relpath=$(pwd)/
- export _git_relpath=${_git_relpath:$((${#mainpath}+1))}
- cd "$rootpath"
+ _git_abs_path="$(git-rev-parse --git-dir 2>/dev/null)"
+ if [ -d "$_git_abs_path" ]; then
+ export _git_relpath="$(git-rev-parse --show-prefix)"
+ cd "$_git_abs_path/.."
fi
fi
_git_objects="${GIT_OBJECT_DIRECTORY:-$_git/objects}"
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] Cogito documentation updates
From: Petr Baudis @ 2005-11-27 15:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randal L. Schwartz, Jonas Fonseca, git
In-Reply-To: <Pine.LNX.4.64.0511230923131.13959@g5.osdl.org>
Dear diary, on Wed, Nov 23, 2005 at 06:29:34PM CET, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
>
>
> On Wed, 23 Nov 2005, Randal L. Schwartz wrote:
> >
> > Delete the -d switch, or explain to me why it is there, and let's work
> > out a POSIX workaround.
>
> It's
>
> -d: same as --no-dereference --preserve=link
>
> --no-dereference
> never follow symbolic links
>
> --preserve[=ATTR_LIST]
> preserve the specified attributes (default: mode,owner-
> ship,timestamps) and security contexts, if possible additional
> attributes: links, all
>
> so it's basically making sure that the copy copies the _link_, not the
> file it points to.
>
> I think you may have to use "cpio -p" instead of "cp" to be portable.
> Something like
>
> cpio -plmu $src $dst
>
> might do it.
Well, but -l links the files instead of copying them, right? That's
certainly not what I want, I want to really _copy_ the files. Also, does
cpio preserve the hardlinks between the copied files? If not, then what
you wrote is equivalent to
cp -pRP
which should be even POSIX, hopefully. That's what I changed the -dpR to
now.
--
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: [BUG] cg-mkpatch uses non-portable "tac" command
From: Petr Baudis @ 2005-11-27 15:08 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86r79ayobj.fsf@blue.stonehenge.com>
Dear diary, on Mon, Nov 21, 2005 at 05:10:08PM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> cg-mkpatch uses "tac" to reverse some lines. This is not a POSIX command.
Thanks, fixed.
--
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: still unclear on setting up a repository
From: Petr Baudis @ 2005-11-27 14:50 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Andreas Ericsson, git
In-Reply-To: <86y83k6ry0.fsf@blue.stonehenge.com>
Dear diary, on Sun, Nov 20, 2005 at 02:14:47AM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> >>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
>
> Andreas> Randal L. Schwartz wrote:
> >> And then, another "go-boom" problem:
> >> % cg-fetch
> >> Hard links don't work - using copy
> >> Fetching head...
> >> cp: illegal option -- d
>
>
> Andreas> I think this was resolved some weeks ago. Perhaps you could try the
> Andreas> latest cogito from git://git.kernel.org/pub/scm/cogito/cogito.git ?
>
> I'm grabbing nearly hourly.
>
> localhost:~/MIRROR/cogito-GIT % cg-status
> Heads:
> >master 22ff47e9b3c5fc8aa2efbc5ac8690b06b868ef6f
> R origin 22ff47e9b3c5fc8aa2efbc5ac8690b06b868ef6f
>
> Error with this version.
Hmm, right. I changed the -d to -P, which is basically equivalent for
our situation, and -P is supposed to be POSIX. Thanks.
> Andreas> On a side-note, could you please turn off your spamvertising
> Andreas> auto-reply? It sends me some info about your perl-expertise and
> Andreas> contact-numbers every now and then. It's getting a bit annoying.
>
> If you email me directly, you'll get that note no more than once per
> month. Some day, I'll create a system to whitelist people that never
> want to see it again. Damn TUIT shortage. :)
If you don't want to receive mailing list traffic related to your mails
directly, you can setup your mailer to adjust the 'mail-followup-to'
header appropriately and you should stop getting it twice.
--
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 1/8] git-apply: work from subdirectory.
From: Lars Magne Ingebrigtsen @ 2005-11-27 14:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q5yohta.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I read git list via new.gmane.org NNTP server (running fetchnews
> locally to slurp from there) and noticed droppage on my end ---
> whose cause turns out to be that gmane NNTP server chops References:
> entries in the middle and fetchnews rejects such messages, and I am
> sure I am _not_ going to see this message on my local machine.
No, news.gmane.org doesn't chop any references. But if you happen to
use a news reader that takes rfc1036bis and rfc2822 seriously (like,
ahem, Gnus), it'll chop the References header to get the size under
1024 octets.
If this gives fetchnews problems, then, er, fetchnews has problems.
Serious problems.
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply
* Re: cg-commit doesn't like new repository
From: Petr Baudis @ 2005-11-27 14:20 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200511192243.10815.alan@chandlerfamily.org.uk>
Dear diary, on Sat, Nov 19, 2005 at 11:43:10PM CET, I got a letter
where Alan Chandler <alan@chandlerfamily.org.uk> said that...
> I just decided to make a repository of /etc, but because I didn't want to load
> in all the files, I used git-init-db to create the repository rather than
> cg-init-db
cg-init -I ? Its help message would also explain to you how to make the
initial commit manually. ;-)
> I presume there is something that cg-init-db does which makes it suitable for
> cogito - but what
cg-commit will try to determine the list of files to commit by diffing
against the previous commit, but there is no previous commit. You need
to pass cg-commit the -C option in order to make the initial commit.
> and shouldn't cg-commit notice and either do it automatically or give
> a different error message?
Good point. cg-commit will now print out friendly error message and
suggest you to use -C.
Thanks,
--
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: What's in master and pu (aka when will 1.0rc4 be out)
From: Timo Hirvonen @ 2005-11-27 13:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek52e4ve.fsf@assigned-by-dhcp.cox.net>
On Sun, 27 Nov 2005 02:56:21 -0800
Junio C Hamano <junkio@cox.net> wrote:
> *1* Bisecting only in a subdirectory might be an interesting
> thing to do, hunting down a bug in a subsystem, but usually a
> subsystem has at least two relevant subdirectories (source and
> include file trees) ;-).
Hmm.. would something like
git-bisect --include drivers/char/drm/ --include include/ ...
be easy to implement? That command would limit bisecting to only the
commits that have changed files under those two directories.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: Question about handling of heterogeneous repositories
From: Petr Baudis @ 2005-11-27 13:11 UTC (permalink / raw)
To: Alex Riesen; +Cc: Andreas Ericsson, git
In-Reply-To: <20051122232228.GB2916@steel.home>
Dear diary, on Wed, Nov 23, 2005 at 12:22:28AM CET, I got a letter
where Alex Riesen <raa.lkml@gmail.com> said that...
> Andreas Ericsson, Tue, Nov 22, 2005 20:40:50 +0100:
> > >it is sometimes the case that a project consists of parts which are
> > >unrelated to each other, and only thing in common between them is that
> > >they all are used in that particular project. For example a program
> > >uses some library and the developer(s) of that program would like to
> > >have the source of that library somewhere close. Well, for this simple
> > >example one could just use two repositories, laid close to each other
> > >in a directory, like project/lib and project/prog.
> > >Now, if I make the example a bit more complex and say, that the
> > >developers of the program are the developers in that project and
> > >change everything under project/ directory, including
> > >project/library/. They are also good people and ready to give the
> > >changes to the library upstream.
> > >
> > >How do they achieve that, without sending project/ and project/program/?
> > >
> > >For everyone who have an experience with ClearCase or Perforce (I'm
> > >sorry for mentioning it) it is what the "mappings" are often used for:
> > >a project is build together from different parts, which can be worked
> > >on separately.
> > >
> > >I'm trying to introduce git at work, but have to prepare myself for
> > >possible questions first, and this is one of them :)
This is something e.g. Cogito wants to support, but does not yet.
Patches welcome.
> > It would certainly be nicer to have git ignore directories that have the
> > ".git" directory (so long as it's not the top of the repo, that is), but
> > I haven't had the energy to fix that when there's already a solution
> > that's simple enough and quite adequate.
>
> BTW, will something like "*/.git/*" in info/exclude work? IOW, does *
> match a "/"?
Nope, but try just '.git' - in case it is not a pathname but just a
filename (or dirname, for that matter), it will recursively apply to all
the subtrees.
--
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: strange cg-add problem
From: Petr Baudis @ 2005-11-27 13:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nico -telmich- Schottelius, git
In-Reply-To: <7vbr0cfwqd.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Nov 22, 2005 at 05:55:38PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Nico -telmich- Schottelius <nico-linux-git@schottelius.org> writes:
>
> > srwali01:/home/server/backup/db# ~/db-dump.sh
> > /home/server/backup/db//2005-11-22/13:26 does not exist or is not a regular file
> > cg-add: warning: not all files could be added
> > cg-commit: Nothing to commit
>
> I do not use cogito, but I suspect it would work if you change
> your script to avoid double slash between db and 2005-11-22.
Did it work? That would have to be GIT's thing, though. Also, GIT does
not seem to like absolute paths being passed to git-update-index.
--
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: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
From: Petr Baudis @ 2005-11-27 12:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511211455120.13775@wbgn013.biozentrum.uni-wuerzburg.de>
Dear diary, on Mon, Nov 21, 2005 at 02:56:41PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> With this patch, git automatically extracts the information from
> .git/branches and .git/remotes, puts it into .git/config, and renames the
> directories to .git/branches.old and .git/remotes.old, respectively.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Please don't do so for .git/branches, that is primarily Cogito thing
and you will make it impossible to use GIT and Cogito on the same
repository - the moment the user uses git-pull on the repository, his
Cogito configuration is trashed and he has even no reliable undo
mechanism.
And in another thread (we have too many threads for this subject ;-)
I've tried to explain that branches and remotes are different concepts,
which live in different namespaces and have different semantics, so
rewriting branches to remotes is a bad idea anyway.
--
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: [RFC 1/2] Use remote information in .git/config
From: Petr Baudis @ 2005-11-27 12:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ben Clifford, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0511250208110.28437@wbgn013.biozentrum.uni-wuerzburg.de>
Dear diary, on Fri, Nov 25, 2005 at 02:08:46AM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Fri, 25 Nov 2005, Ben Clifford wrote:
>
> > On 22 Nov 2005, at 05:29, Junio C Hamano wrote:
> >
> > > Personally I do not mind moving remotes/branches information
> > > there, except that I suspect the git-config-set interface makes
> > > it cumbersome to (1) find out what remotes I defined (i.e. an
> > > equivalent of "ls .git/remotes")
> >
> > (1) is useful to be able to do in a very lightweight way when doing tab
> > completion on remotes. Having heads, tags, remotes in nicely named separate
> > files makes that pretty straightforward; I don't know if using a git-config-
> > accessor would make this noticeably worse, though, as I haven't tried anything
> > out there yet.
>
> git-var -l | sed -n "s/^remote\.\([A-Za-z0-9]*\)\.url=.*$/\1/p"
All right, I've asked about this functionality in the other thread, and
something like this seems to cut it (although I would just /\([^.=]*\)/
instead of restricting the remote name).
However, it's a nice example of horrible interface. And confusing one
at it, too.
Why git-var -l?! That makes no sense to me. git-var's function is to
"print the git users identity" (no matter that it is grammatically
wrong, that's what the synopsis says). This is something totally else,
and I can't see what bussiness does this have in the git-var command.
This should belong into git-repo-config, which manages the rest of the
config-related stuff.
C'mon people, git's interface is inconsistent enough as it is now,
no need to make it even worse. ;-)
--
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] Reference technical/trivial-merge.txt in git-read-tree documentation
From: Petr Baudis @ 2005-11-27 12:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20051111205140.5719.68724.stgit@machine.or.cz>
Dear diary, on Fri, Nov 11, 2005 at 09:51:40PM CET, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> That file, with the so valuable (and so confusing) tables describing
> the precise resolution rules git-read-tree follows, silently sat in
> the corner and almost noone knew about it (well, I didn't, at least).
> This references it from the git-read-tree documentation, so that there
> is some chance that interested people will find it.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
Any gripes, or just forgotten?
--
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/8] ls-tree: work from subdirectory.
From: Petr Baudis @ 2005-11-27 11:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vr792fnta.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Nov 27, 2005 at 10:21:53AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> - cg-admin-cat may want to use -r for the first one (${ARGS[@]}
> may name a directory), but that also would change the
> behaviour. The current one shows only one level, instead of
> going all the way down.
I think the current behaviour is nonsensical, since it cats all the
files in the subdirectory, instead of just listing it. Didn't
git-ls-tree already have the -d implicit sometime in the past? At any
rate, the change to git-ls-tree would fix this. :-)
> - cg-log:117 uses ls-tree without -r, but I have a feeling that
> it might be just a bug, even with the current ls-tree; I
> suspect the user would not see things in subdirectories.
> This is only for the initial commit so it may or may not
> matter much.
Thanks, fixed. It uses -r now.
--
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
* What's in master and pu (aka when will 1.0rc4 be out)
From: Junio C Hamano @ 2005-11-27 10:56 UTC (permalink / raw)
To: git
In-Reply-To: <7voe48gqg9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> This series is what I've been cooking for the past several days,
> partly based on patch from Martin Atukunda but with hopefully
> smaller impact.
>
> [PATCH 1/4] Repository format version check.
> [PATCH 2/4] Check repository format version in enter_repo().
> [PATCH 3/4] init-db: check template and repository format.
> [PATCH 4/4] setup_git_directory(): check repository format version.
And they are now in the master branch, along with a couple of
bugfixes I received in the last couple of days. I've given them
some testing and believe they are in good enough shape for 1.0
futureproofing. Bug reports with reproduction recipe and/or
patch are most welcomed.
Cooking in the proposed updates branch is the 8-series "work
from subdirectory" patch I posted yesterday, with some polishing
based on suggestion from Linus. The ls-tree rework is not
included at this point, neither is the git-sh-setup, both of
which unfortunately have wider impact than I feel comfortable to
swallow in one day.
I am hoping to base the next "maint" branch update, probably on
Wednesday, on what is in "pu" tonight, with safer updates I will
receive from the list (Documentation fixes and updates, and
archimport updates from Eric and Martin are the candidates).
That will be tagged as 1.0rc4 and hopefully be the last 1.0rc,
which means no more major feature/semantics changes after that
until 1.0 --- famous last words.
So I anticipate that many of the barebone Porcelain commands
that insist on running from the toplevel will ship the way they
are in 1.0. If you run "git grep git-sh-setup 'git*sh'", you
will notice that most of them are whole-tree operations anyway,
so not much is lost [*1*].
[Footnote]
*1* Bisecting only in a subdirectory might be an interesting
thing to do, hunting down a bug in a subsystem, but usually a
subsystem has at least two relevant subdirectories (source and
include file trees) ;-).
I suspect that it would be trivial to convert whole-repository
operations such as count-objects, prune, and repack to work from
subdirectory, although the value of that is dubious.
^ permalink raw reply
* Re: [PATCH 6/8] ls-tree: work from subdirectory.
From: Junio C Hamano @ 2005-11-27 9:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511251953081.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And this is just ugly.
>
> git-ls-tree should be rewritten to use a pathspec the same way everybody
> else does. Right now it's the odd man out: if you do
>
> git-ls-tree HEAD divers/char drivers/
>
> it will show the same files _twice_, which is not how pathspecs in general
> work.
True; that is more or less deliberate. The behaviour is
modelled after what "/bin/ls -a" does.
> How about this patch? It breaks some of the git-ls-tree tests, but it
> makes git-ls-tree work a lot more like other git pathspec commands, and it
> removes more than 150 lines by re-using the recursive tree traversal (but
> the "-d" flag is gone for good, so I'm not pushing this too hard).
I am all for it if it were just me, and all the more so for its
cleanup value. I do not think anybody uses "-d" (none of
Cogito, StGIT nor gitweb seems to use it, and I have not seen
Jason McMullan, who wanted to have a way in ls-tree to see just
the object name of a subtree, on the list for a while); I
suspect that nobody would miss that option.
However, this patch changes its behaviour in another way, and
that could impact Porcelains more than the removal of the "-d"
option. Currently, "git-ls-tree <tree> $dir" shows what
"/bin/ls -a -1 $dir" would show --- the tree for $dir itself and
its immediate children. This patch changes it to show the tree
for $dir and nothing else. In effect, "-d" becomes the default
that you cannot turn off, except using "-r" to allow it go all
the way down.
I do not think StGIT is affected; it does not use ls-tree at all.
gitweb is not affected either. It does not use paths specifier.
Cogito might need a slight adjustment.
- cg-admin-cat may want to use -r for the first one (${ARGS[@]}
may name a directory), but that also would change the
behaviour. The current one shows only one level, instead of
going all the way down.
- cg-log:117 uses ls-tree without -r, but I have a feeling that
it might be just a bug, even with the current ls-tree; I
suspect the user would not see things in subdirectories.
This is only for the initial commit so it may or may not
matter much.
- cg-restore already uses ls-tree -r so that would not be
affected.
^ permalink raw reply
* Re: [PATCH 7/9] Add the accurate changeset applyer
From: Eric Wong @ 2005-11-27 5:43 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git list, Martin Langhoff
In-Reply-To: <46a038f90511262024g4eca7dc2oa42d1f72febf9e27@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 11/24/05, Eric Wong <normalperson@yhbt.net> wrote:
> > And make it the default.
>
> Cheeky, but right ;-)
>
> Would it be a good idea to read the log entry and decide what kind of
> smarts do we need to apply the changeset? If the log entry looks
> plain, use process_patchset_fast(), else invoke $TLA?
This could work. For it to work efficiently, process_patchset_fast()
should probably be modified to work on real Arch trees and rsync with
the git one. Basically, we can replace the bulk of the tla replay calls
with your fast changeset applier. Once the fast mode hits a changeset
it can't handle, it can do a tla replay on a single changeset instead of
having to do a slow get/apply-delta on an out-of-date tree.
process_patchset_fast() must understand how to handle permissions
changes, though, as Arch log entries are completely useless for that.
Unfortunately, doing this right and fast probably still requires more
time than it's worth. Let's face it, trees with 12k files are extremely
rare in the Arch world (as are trees constantly reorganized by
obsessive-compulsives :), but many trees do get a small handful of
directory renames in their lifetime.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 7/9] Add the accurate changeset applyer
From: Martin Langhoff @ 2005-11-27 4:24 UTC (permalink / raw)
To: Eric Wong; +Cc: git list, Martin Langhoff
In-Reply-To: <20051124075504.GH4789@mail.yhbt.net>
On 11/24/05, Eric Wong <normalperson@yhbt.net> wrote:
> And make it the default.
Cheeky, but right ;-)
Would it be a good idea to read the log entry and decide what kind of
smarts do we need to apply the changeset? If the log entry looks
plain, use process_patchset_fast(), else invoke $TLA?
cheers,
martin
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Linus Torvalds @ 2005-11-27 4:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kay Sievers, git
In-Reply-To: <7vfypioi83.fsf@assigned-by-dhcp.cox.net>
On Sat, 26 Nov 2005, Junio C Hamano wrote:
> Kay Sievers <kay.sievers@vrfy.org> writes:
> >>
> >> If you replace "assume" with "verify", then I agree.
>
> One problem I have that approach is what to do if it does not
> verify. Reject and ask them to re-run the program with another
> option --binary-log-message?
We could do that. With perhaps an option to just do the trivial
"latin1->utf8" translation, which will be correct in most of the western
world (and, perhaps more importantly - the places it won't be correct in
will almost universally have an explicit locale setting or similar, since
otherwise nothing would work).
In other words, in the absense of locale settings, we can pretty much
assume any 8-bit data is latin1 if it isn't already utf-8. That's what a
lot of tools do already (eg, gitk automatically does the right thing,
exactly because it will assume non-proper utf-8 being in latin1).
I'd suggest that the current "-u" flag do the latin1->utf8 autoconversion,
and _without_ the "-u" flag, you'd just commit it as binary data..
Linus
^ permalink raw reply
* Re: [PATCH 1/8] git-apply: work from subdirectory.
From: Junio C Hamano @ 2005-11-27 4:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, larsi+gmane
In-Reply-To: <Pine.LNX.4.64.0511260932080.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This breaks git-apply when used to just do a "diffstat", or
> when used on a non-git repository.
You are right. Something like this?
An off-topic note (that's why this message is CC'd to larsi).
People may notice messages in this thread have accumulated a
modest number of References: entries. I read git list via
new.gmane.org NNTP server (running fetchnews locally to slurp
from there) and noticed droppage on my end --- whose cause turns
out to be that gmane NNTP server chops References: entries in
the middle and fetchnews rejects such messages, and I am sure I
am _not_ going to see this message on my local machine. Has
anybody else noticed this problem?
-- >8 --
[PATCH] apply: only do GIT_DIR discovery when running with --index.
It does not have to be run in git repository unless we are
applying or checking the patch to the index file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/apply.c b/apply.c
index ae06d41..1742ab2 100644
--- a/apply.c
+++ b/apply.c
@@ -17,7 +17,7 @@
// --index-info shows the old and new index info for paths if available.
//
static const char *prefix;
-static int prefix_length;
+static int prefix_length = -1;
static int allow_binary_replacement = 0;
static int check_index = 0;
@@ -1709,7 +1709,7 @@ static int use_patch(struct patch *p)
return 0;
x = x->next;
}
- if (prefix && *prefix) {
+ if (0 < prefix_length) {
int pathlen = strlen(pathname);
if (pathlen <= prefix_length ||
memcmp(prefix, pathname, prefix_length))
@@ -1793,10 +1793,6 @@ int main(int argc, char **argv)
int i;
int read_stdin = 1;
- prefix = setup_git_directory();
- prefix_length = prefix ? strlen(prefix) : 0;
- git_config(git_default_config);
-
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
int fd;
@@ -1858,7 +1854,14 @@ int main(int argc, char **argv)
line_termination = 0;
continue;
}
- arg = prefix_filename(prefix, prefix_length, arg);
+
+ if (check_index && prefix_length < 0) {
+ prefix = setup_git_directory();
+ prefix_length = prefix ? strlen(prefix) : 0;
+ git_config(git_default_config);
+ }
+ if (0 < prefix_length)
+ arg = prefix_filename(prefix, prefix_length, arg);
fd = open(arg, O_RDONLY);
if (fd < 0)
^ permalink raw reply related
* Re: Rss produced by git is not valid xml?
From: Junio C Hamano @ 2005-11-27 3:57 UTC (permalink / raw)
To: Kay Sievers; +Cc: Linus Torvalds, git
In-Reply-To: <20051127025249.GA12286@vrfy.org>
Kay Sievers <kay.sievers@vrfy.org> writes:
> On Sat, Nov 19, 2005 at 09:52:34AM -0800, Linus Torvalds wrote:
>>
>> On Sat, 19 Nov 2005, Junio C Hamano wrote:
>> >
>> > Well, some people on the list seem to think UTF-8 is the one and
>> > only right encoding, so for them if the message does not
>> > identify what it is in, assuming UTF-8 and not doing any
>> > conversion is probably the right thing ;-).
>>
>> If you replace "assume" with "verify", then I agree.
One problem I have that approach is what to do if it does not
verify. Reject and ask them to re-run the program with another
option --binary-log-message?
> I found some test code I did a while ago for validation of
> filesystem labels, cause D-BUS diconnects your session, if you
> send an invalid utf-8 string to the bus. :)
>
> Kay
Thanks. I take it that you are licensing this code to use in
git when we doing what Linus suggests?
^ 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