Re: Users of git-check-files?
Hi, On Thu, 4 Aug 2005, Junio C Hamano wrote: I will keep git-rev-list; used in Jeff's git-changes-script and some parts of Cogito as well. According to my grep's, these files use git-rev-list: git-bisect-script git-cherry git-format-patch-script git-log-script git-repack-script git-whatchanged gitk send-pack.c upload-pack.c So better keep it :-) Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
Linus Torvalds <[EMAIL PROTECTED]> writes: > On Tue, 2 Aug 2005, Junio C Hamano wrote: >> >> How about git-rev-tree? Does anybody care? > > Yeah, probably not. git-rev-list does so much more than git-rev-tree ever > did. I will keep git-rev-list; used in Jeff's git-changes-script and some parts of Cogito as well. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
Hi,
On Wed, 3 Aug 2005, Linus Torvalds wrote:
On Wed, 3 Aug 2005, Johannes Schindelin wrote:
I try to write a "git annotate" based on the output of git-whatchanged.
You can't. It's fundamentally not doable, because you lose the merge
information.
That's why I said I need git-rev-tree. In the meantime I discovered, that
git-rev-list has a "--parents" option which suits me just fine. Therefore
I'd say: kill git-rev-tree.
So you need to use a combination of git-rev-list _and_ git-whatchanged.
I tried to do without the ugly "script is calling script is calling
program" idiom. That is why my attempt at git-annotate (see attached) is
so slow.
I have been thinking of adding a "follow this file" mode to git-rev-list,
which just ignores all children of merges that used the file directly from
one of the other children. Exactly because then you could have a
git-rev-list that prunes based on filename, and would potentially be a lot
more efficient (not follow the "uninteresting" side of a merge).
Let's sit and see if people pick it up at all. If yes, I'd rather rewrite
the whole thing in C eventually (it is in perl now and uses hashes quite
extensively...).
P.S.: My only unsolved problem is that git-whatchanged sometimes shows
the diffs in the wrong order (clock-skew problem?)
Nope, this is a direct result of two branches modifying the same file in
parallel. There is no "right" or "wrong" order.
Exactly. But there is a "you probably meant that": the branch in which it
was modified last (not counting merges, of course).
Notes:
- You can either annotate by commit (this is the default), or show
some other informations with the "-f" flag: Try "-f author,commit:8".
- If you don't specify any files, it assumes you mean all files
(Attention: slow).
- You can start at a commit instead of the current state by specifying
"-c other_commit".
- The list of commits is traversed as output by git-rev-list, i.e.
chronologically. Each line is marked with the commit whose parent does not
contain that line.
- I am not at all sure if my handling of merges is sane. The logic is like
this: If the commit is parent to more than one commit (i.e. a merge), then
the touched lines are tentatively marked as changed in that commit, but
are possibly overridden at a later stage.
Ciao,
Dscho
#!/usr/bin/perl
use Getopt::Std;
sub usage() {
print STDERR 'Usage: ${\basename $0} [-s] [-f format] [-c commit]
[files...]
-s only look at first parent in case of a merge
-f format revision format (e.g. "author,commit:8")
-c commit start looking at this commit
';
exit(1);
}
getopts("hsf:c:") or usage();
$opt_h && usage();
$first_parent_only=$opt_s;
sub read_file ($) {
my $file=$_[0];
open IN, $file || return 1;
$orig_line_count=0;
@lines=();
@line_handled=();
@revisions=();
while() {
$orig_line_count++;
$lines[$orig_line_count]=$_;
}
close IN;
$orig_line_count>0 || return 2;
@mapping[1..$orig_line_count]=(1..$orig_line_count);
return 0;
}
sub init_file($$) {
my $file=$_[0];
my $head=$_[1];
if($head eq "") {
# read current file
my $ret=read_file("<".$file);
$ret==0 || return $ret;
$current_revision="*"x($revision_string_length-1).";";
handle_diff("git-diff-files -p ".$file."|",1);
} else {
if(`git-ls-tree $head $file`=~/^\S+\s+\S+\s+(\S+)/) {
$sha1=$1;
my $ret=read_file("git-cat-file blob ".$sha1."|");
$ret==0 || return $ret;
} else {
usage();
}
}
$file_version=0;
return 0;
}
# mark all lines still unaccounted for
sub mark_all ($) {
my $mark_lines_as_handled=$_[0];
foreach $line (@mapping) {
if($line_handled{$line}==undef) {
$revisions[$line]=get_revision();
if($mark_lines_as_handled) {
$line_handled{$line}=1;
}
}
}
if($mark_lines_as_handled) {
$orig_line_count=0;
@mapping=();
}
}
# this sub only handles unified diffs
sub handle_diff($$) {
my $diff=$_[0];
my $mark_lines_as_handled=$_[1];
open DIFF, $diff;
my @new_mapping=();
my $current_line_nr_minus=1;
my $current_line_nr_plus=1;
while() {
if(/^@@ -(\d+),(\d+) \+(\d+),(\d+) @@/) {
$empty_diff=0;
$start_minus=$1;
$count_minus=$2;
$start_plus=$3;
$count_plus=$4;
Re: Users of git-check-files?
On Wednesday 03 August 2005 20:07, Junio C Hamano wrote: > Josef, could you give it a try please? Perfect. Thanks. Josef - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
On Wed, 3 Aug 2005, Josef Weidendorfer wrote: > > But my example shows that the error happens even with 2 branches totally > unrelated to each other: if branch1 got a new commit, you can not push to > branch2 from another clone. Sure you can. git-send-pack remote branch2 and you've just done so. The shorthand of "no branches listed" expands to _all_ branches, and if you try to send all branches, then you're trying to update "branch1" with something you don't have. That's your usage error. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
On Wed, 3 Aug 2005, Josef Weidendorfer wrote: > > Yes it is. To reproduce: > Create a repository with 2 branches. > Make 2 clones of the 2 branches via SSH. > Make a commit on one clone and push. > Make another commit on the other clone and push => ERROR This works perfectly fine, you just have to make sure that you update the right head. If you try to update a head that is ahead of you, that is driver error. Admittedly one that could have nicer error messages ;) This is why git-send-pack takes the name of the branch to update.. The real problem with git-send-pack is that the local and remote names have to be the same, which is a bug, really. It _should_ be perfectly fine to do something like git-send-pack ..dest.. localname:remotename which would push the local "localname" branch to the remote "remotename" branch. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
This patch seems to fix the problem.
* If the original value of remote ref refers to an object we do
not have, and if the ref is one of the branches we are trying
to push, we refuse to update it.
* Otherwise, we do not attempt to use such an value when
computing what objects to put in pack, since rev-list would
fail.
I've tested Josef's two-branches case, one repo updates one
branch and pushes to the central repo, another repo updates the
other branch and pushed to the central repo. The old code
barfed when invoking rev-list, but this does not seem to.
Josef, could you give it a try please?
---
cd /opt/packrat/playpen/public/in-place/git/git.junio/
jit-diff
# - master: git-send-email-script: minimum whitespace cleanup.
# + (working tree)
diff --git a/send-pack.c b/send-pack.c
--- a/send-pack.c
+++ b/send-pack.c
@@ -43,7 +43,8 @@ static void exec_rev_list(struct ref *re
char *buf = malloc(100);
if (i > 900)
die("git-rev-list environment overflow");
- if (!is_zero_sha1(refs->old_sha1)) {
+ if (!is_zero_sha1(refs->old_sha1) &&
+ has_sha1_file(refs->old_sha1)) {
args[i++] = buf;
snprintf(buf, 50, "^%s", sha1_to_hex(refs->old_sha1));
buf += 50;
@@ -208,6 +209,12 @@ static int send_pack(int in, int out, in
continue;
}
+ if (!has_sha1_file(ref->old_sha1)) {
+ error("remote '%s' object %s does not exist on local",
+ name, sha1_to_hex(ref->old_sha1));
+ continue;
+ }
+
/* Ok, mark it for update */
memcpy(ref->new_sha1, new_sha1, 20);
}
Compilation finished at Wed Aug 3 11:02:15
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
On Wed, 3 Aug 2005, Johannes Schindelin wrote: > > On Wed, 3 Aug 2005, Linus Torvalds wrote: > > > Are you sure you have a good git version on master? I've never seen > > anything like that, and I push all the time.. > > Call him Zaphod: he has two heads (master and pu). You don't. Oh, but I most definitely do. I update several heads at a time when I create a new tag etc. What I don't do is to rewrite my history, though.. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
On Wed, 3 Aug 2005, Johannes Schindelin wrote: > > I try to write a "git annotate" based on the output of git-whatchanged. You can't. It's fundamentally not doable, because you lose the merge information. So you need to use a combination of git-rev-list _and_ git-whatchanged. Use the "--parents" flag to git-rev-list to get the parents output for doing your own graph, if you want to. I have been thinking of adding a "follow this file" mode to git-rev-list, which just ignores all children of merges that used the file directly from one of the other children. Exactly because then you could have a git-rev-list that prunes based on filename, and would potentially be a lot more efficient (not follow the "uninteresting" side of a merge). I haven't gotten around to it, partly because I wonder if it would be better as a separate program - even if that would mean that you'd lose all the cool features of git-rev-list (the ability to limit it to certain versions, and the ability to sort the output in relevant orders). Partly because I'm just too friggin lazy. > P.S.: My only unsolved problem is that git-whatchanged sometimes shows > the diffs in the wrong order (clock-skew problem?) Nope, this is a direct result of two branches modifying the same file in parallel. There is no "right" or "wrong" order. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
On Wed, 3 Aug 2005, Junio C Hamano wrote: > > I think in addition to the existing ref_newer() check, which > makes sure you are advancing the remote head, not just replacing > with something unrelated, making sure that we have objects > referenced by ref->old_sha1 we obtained from the remote on our > end for all branches involved would be the only thing needed. Yes. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
On Wednesday 03 August 2005 19:08, you wrote: > Yes it is. To reproduce: You do not need 2 clones. It is enough to have one clone with a branch, and you make a commit in the original repository. Afterwards, pushing a new commit from the clone gives the error. After pulling the missing commit from the original rep, the push works. Josef - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
On Wednesday 03 August 2005 19:37, you wrote: > Linus Torvalds <[EMAIL PROTECTED]> writes: > > I started out to make the "-f" flag to send-file work around it, but I > > never finished that, partly because it really ends up being the same > > thing as "git-fetch-pack" in reverse, which was against the whole point > > of git-send-pack. Send-pack is meant to be an "update remote tree" thing, > > with the assumption that the remote tree is a subset - and exactly that > > assumption is what makes send-pack much cheaper than fetch-pack. > > I think in addition to the existing ref_newer() check, which > makes sure you are advancing the remote head, not just replacing > with something unrelated, making sure that we have objects > referenced by ref->old_sha1 we obtained from the remote on our > end for all branches involved would be the only thing needed. > The latter the users should not even be able to override with > the --force flag, of course, but we would remind them to pull > from the other end first. But my example shows that the error happens even with 2 branches totally unrelated to each other: if branch1 got a new commit, you can not push to branch2 from another clone. Why is it not enough to have all the history of a remote branch in the local clone to be able to push to this branch? Josef - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
Linus Torvalds <[EMAIL PROTECTED]> writes: > I started out to make the "-f" flag to send-file work around it, but I > never finished that, partly because it really ends up being the same thing > as "git-fetch-pack" in reverse, which was against the whole point of > git-send-pack. Send-pack is meant to be an "update remote tree" thing, > with the assumption that the remote tree is a subset - and exactly that > assumption is what makes send-pack much cheaper than fetch-pack. I think in addition to the existing ref_newer() check, which makes sure you are advancing the remote head, not just replacing with something unrelated, making sure that we have objects referenced by ref->old_sha1 we obtained from the remote on our end for all branches involved would be the only thing needed. The latter the users should not even be able to override with the --force flag, of course, but we would remind them to pull from the other end first. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
Josef Weidendorfer <[EMAIL PROTECTED]> writes: > ~/tmp/git/clone2> cg-push > 'refs/heads/branch2': updating from 80e4d426dd4c865b943cc1121b580a946eee921d > to 8196067677e3415ce404ea5bc35731ac7d56115d > fatal: bad object f7e944b036fd00af656b262140c1dc93ceffadb1 > Packing 0 objects > Unpacking 0 objects A. Yes, we read from the remote and use old->sha1 when doing the pack generation. If we do not have that object (in Josef's example because it is not something we have pulled yet), then rev-list has no way to create the necessary pack. I have a feeling this explains what I've been seeing as well. The first thing I do before I push is to fetch (but not merge-pull) from kernel.org, but this happens against www.kernel.org (to make sure people are seeing what I want them to see), not against master. So if I happen to do my push cycle twice before the things propagate from master to www.kernel.org, _and_ if I happened to have run git prune in my private repository just before the second cycle, I may end up not having the objects referenced by "pu" branch there in my private repository. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
On Wed, 3 Aug 2005, Junio C Hamano wrote: > > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > Are you sure you have a good git version on master? I've never seen > > anything like that, and I push all the time.. > > I have been esuspecting that it happens only because I rewind > and rebase "pu", which you never do. The thing is, even though > I rewind "pu" all the time, it happens only occasionally. Oh, that would do it. You need to prune back the remote tree you send to, so that it is a real subset of what you are sending from (at least as far as the branch you send is concerned - other branches may be ahead of you, of course). Unlike "git-fetch-pack", the send-pack interface does not do any common commit discovery, so if you have state on the other end that isn't on your local end, that's setting yourself up for problems: you are basically misusing the interfaces. I started out to make the "-f" flag to send-file work around it, but I never finished that, partly because it really ends up being the same thing as "git-fetch-pack" in reverse, which was against the whole point of git-send-pack. Send-pack is meant to be an "update remote tree" thing, with the assumption that the remote tree is a subset - and exactly that assumption is what makes send-pack much cheaper than fetch-pack. (Actually, to me it's not the "cheaper" that matters, but exactly the fact that send-pack is so safe - if somebody has changed something at the other end that I don't have in mine, I _want_ errors, because that would be a serious problem). Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
On Wednesday 03 August 2005 18:50, you wrote: > Hi, > > On Wed, 3 Aug 2005, Linus Torvalds wrote: > > Are you sure you have a good git version on master? I've never seen > > anything like that, and I push all the time.. > > Call him Zaphod: he has two heads (master and pu). You don't. As I said in > another mail, this could be very well related to Junio's problems. Yes it is. To reproduce: Create a repository with 2 branches. Make 2 clones of the 2 branches via SSH. Make a commit on one clone and push. Make another commit on the other clone and push => ERROR A log of this last push: = ~/tmp/git/clone2> cg-push 'refs/heads/branch2': updating from 80e4d426dd4c865b943cc1121b580a946eee921d to 8196067677e3415ce404ea5bc35731ac7d56115d fatal: bad object f7e944b036fd00af656b262140c1dc93ceffadb1 Packing 0 objects Unpacking 0 objects fatal: unpack should have generated 8196067677e3415ce404ea5bc35731ac7d56115d, but I can't find it! = f7e9... is the commit pushed from the first clone. I had the same problem yesterday. Josef - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
Linus Torvalds <[EMAIL PROTECTED]> writes: > Are you sure you have a good git version on master? I've never seen > anything like that, and I push all the time.. I have been esuspecting that it happens only because I rewind and rebase "pu", which you never do. The thing is, even though I rewind "pu" all the time, it happens only occasionally. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
Hi, On Wed, 3 Aug 2005, Linus Torvalds wrote: Are you sure you have a good git version on master? I've never seen anything like that, and I push all the time.. Call him Zaphod: he has two heads (master and pu). You don't. As I said in another mail, this could be very well related to Junio's problems. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
On Wed, 3 Aug 2005, Junio C Hamano wrote: > > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > I've lost that state. Can you explain a bit mroe.. > > Sorry, you have not lost anything. It is my bad that this is > the first time I brought it up. I've been seeing that from time > to time when I push to either my "send to master" repository > from my working repository, or from the "send to master" > repository to master.kernel.org, but I haven't figured it out if > there is any pattern. Are you sure you have a good git version on master? I've never seen anything like that, and I push all the time.. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
Hi, On Wed, 3 Aug 2005, Junio C Hamano wrote: Sorry, you have not lost anything. It is my bad that this is the first time I brought it up. I've been seeing that from time to time when I push to either my "send to master" repository from my working repository, or from the "send to master" repository to master.kernel.org, but I haven't figured it out if there is any pattern. This could be related to what I was realizing the other day: when trying to push to a repository (just one branch), but I do not have _all_ of the remote branches pulled, then it fails. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
Linus Torvalds <[EMAIL PROTECTED]> writes:
> I've lost that state. Can you explain a bit mroe..
Sorry, you have not lost anything. It is my bad that this is
the first time I brought it up. I've been seeing that from time
to time when I push to either my "send to master" repository
from my working repository, or from the "send to master"
repository to master.kernel.org, but I haven't figured it out if
there is any pattern. It's one of those "I'll try to take a
snapshot so I can have a reproduction recipe to figure it out
next time it happens" things. Unfortunately, when it happens
against master.kernel.org, I have more urgent task of making
sure that the public repository is not in any way corrupted, and
after fixing that (it typically takes removing the
git.git/refs/{master,pu} and repushing, which recovers fine), I
do not have much to start trying to reproduce it anymore X-<.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
On Wed, 3 Aug 2005, Junio C Hamano wrote: > > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > Yeah, probably not. git-rev-list does so much more than git-rev-tree ever > > did. > > Does rev-list do --edges ;-)? No, but does anybody use it? It _may_ be interesting as a git-merge-base thing, but then we should probably add it to git-merge-base (which actually _does_ do edges these days, but it just only shows the most recent one..) > BTW, I have two known bugs/problems that I haven't resolved, > which is bothering me quite a bit. Yes, it is my fault (lack of > time and concentration). One is the EINTR from the daemon.c, I actually think the new code is totally broken. If you want to listen to several sockets, you should just run several daemons. Yeah, yeah, it won't give you "global child control" etc, but I doubt we care. But I don't think it's a huge issue, since most serious users are likely to use the "--inetd" flag and use inetd as the real daemon anyway (ie the built-in daemon code is most useful for normal users just setting up their own quick thing). > and another is receive-pack failing with "unpack should have > generated but I cannot find it" when pushing. The latter is > something "I am aware of, I know it needs to be diagnosed, but I > have not looked into yet". I've lost that state. Can you explain a bit mroe.. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
Linus Torvalds <[EMAIL PROTECTED]> writes: > Yeah, probably not. git-rev-list does so much more than git-rev-tree ever > did. Does rev-list do --edges ;-)? BTW, I have two known bugs/problems that I haven't resolved, which is bothering me quite a bit. Yes, it is my fault (lack of time and concentration). One is the EINTR from the daemon.c, and another is receive-pack failing with "unpack should have generated but I cannot find it" when pushing. The latter is something "I am aware of, I know it needs to be diagnosed, but I have not looked into yet". - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
On Tue, 2 Aug 2005, Junio C Hamano wrote: > > How about git-rev-tree? Does anybody care? Yeah, probably not. git-rev-list does so much more than git-rev-tree ever did. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
Hi, On Tue, 2 Aug 2005, Junio C Hamano wrote: Linus Torvalds <[EMAIL PROTECTED]> writes: It has no point any more, all the tools check the file status on their own, and yes, the thing should probably be removed. How about git-rev-tree? Does anybody care? I try to write a "git annotate" based on the output of git-whatchanged. Since git-whatchanged only shows the commit and its parent, I need to figure out what was the last diff that led to the current commit's state. This needs git-rev-tree. Ciao, Dscho P.S.: My only unsolved problem is that git-whatchanged sometimes shows the diffs in the wrong order (clock-skew problem?) - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
Linus Torvalds <[EMAIL PROTECTED]> writes: > It has no point any more, all the tools check the file status on their > own, and yes, the thing should probably be removed. How about git-rev-tree? Does anybody care? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Users of git-check-files?
On Wed, 3 Aug 2005, Johannes Schindelin wrote: > > there's git-check-files in the repository, but AFAIK nobody uses it, not > even "git status", which would be the primary candidate. If really no > users of git-check-files exist, maybe we should remove it? Yes. It was used by the old "git-applymbox" (aka "dotest") until I got around writing "git-apply". It has no point any more, all the tools check the file status on their own, and yes, the thing should probably be removed. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
