Daniel Barkalow [off-list ref] writes:
Why have git-lost+found write to files at all? It seems to me easiest to
have the list go to standard out, and you could do "gitk `git-lost+found
-t commit`" to see lost commits, and reconnect them as desired. (Making up
command line syntax for listing only the commits.)
That is certainly cleaner. The only downside is fsck-objects
that lost+found uses tends to be expensive operation, and what
you would want to do with the information may be more than just
use it on the command line of gitk. But in any case the user
could store git-lost+found output in a file to do whatever she
wants, so it may not matter.
On Wed, 9 Nov 2005, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
Why have git-lost+found write to files at all? It seems to me easiest to
have the list go to standard out, and you could do "gitk `git-lost+found
-t commit`" to see lost commits, and reconnect them as desired. (Making up
command line syntax for listing only the commits.)
That is certainly cleaner. The only downside is fsck-objects
that lost+found uses tends to be expensive operation, and what
you would want to do with the information may be more than just
use it on the command line of gitk. But in any case the user
could store git-lost+found output in a file to do whatever she
wants, so it may not matter.
Actually, my next suggestion would be to have gitk able to write
hashes as refs, so that, having put it on the gitk command line, you could
then do the things you want from there.
-Daniel
*This .sig left intentionally blank*