From: Petr Baudis <pasky@suse.cz>
To: Junio C Hamano <junkio@cox.net>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
git@vger.kernel.org, linux-kernel@vger.kernel.org,
barkalow@iabervon.org
Subject: Re: [ANNOUNCE] GIT 0.99.9g
Date: Thu, 10 Nov 2005 19:03:11 +0100 [thread overview]
Message-ID: <20051110180311.GR30496@pasky.or.cz> (raw)
In-Reply-To: <7v4q6k1jp0.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Nov 10, 2005 at 06:44:43PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
> > May I *STRONGLY* urge you to name that something different.
> > "lost+found" is a name with special properties in Unix; for example,
> > many backup solutions will ignore a directory with that name.
>
> Yeah, the original proposal (in TODO list) explicitly stated why
> I chose lost-found instead of lost+found back then, and somebody
> on the list (could have been Pasky but I may be mistaken) said
> not to worry.
It was the Large Angry SCM. I share your concern.
> In any case, if we go the route Daniel suggests, we would not be
> storing anything on the filesystem ourselves so this would be a
> non-issue.
I like Daniel's route as well, for the separate command. But it would be
nice to also have a way to tell git-fsck-cache to save the lost+found
refs as it goes, much like the filesystem fsck. So if it reports some
unreachable refs, you will not need to tell it to do the same job
_another_ time to find out the refs and pass them to gitk. Then again,
if we do this, the utility of a separate command will be questionable.
--
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.
next prev parent reply other threads:[~2005-11-10 18:03 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-10 8:14 [ANNOUNCE] GIT 0.99.9g Junio C Hamano
2005-11-10 9:09 ` Jeff Garzik
2005-11-10 17:13 ` H. Peter Anvin
2005-11-10 18:34 ` Andreas Ericsson
2005-11-11 21:17 ` H. Peter Anvin
2005-11-12 11:37 ` Andreas Ericsson
2005-11-11 18:37 ` Junio C Hamano
2005-11-12 12:17 ` Andreas Ericsson
2005-11-14 7:46 ` Junio C Hamano
2005-11-14 9:23 ` Andreas Ericsson
2005-11-14 21:15 ` Junio C Hamano
2005-11-14 9:32 ` Petr Baudis
2005-11-10 9:54 ` Yaacov Akiba Slama
2005-11-10 19:55 ` Junio C Hamano
2005-11-10 17:09 ` H. Peter Anvin
2005-11-10 17:44 ` Junio C Hamano
2005-11-10 18:03 ` Petr Baudis [this message]
2005-11-10 18:31 ` Daniel Barkalow
2005-11-10 19:04 ` Junio C Hamano
2005-11-10 19:09 ` Daniel Barkalow
2005-11-10 19:32 ` Linus Torvalds
2005-11-10 19:43 ` Linus Torvalds
2005-11-11 21:18 ` H. Peter Anvin
2005-11-11 14:19 ` Johannes Schindelin
2005-11-11 17:46 ` H. Peter Anvin
2005-11-10 18:54 ` Jim Radford
2005-11-10 20:30 ` Andreas Ericsson
2005-11-10 20:48 ` Junio C Hamano
2005-11-11 18:23 ` Jim Radford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051110180311.GR30496@pasky.or.cz \
--to=pasky@suse.cz \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=hpa@zytor.com \
--cc=junkio@cox.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).