Junio C Hamano <junkio@xxxxxxx> wrote:
> Shawn Pearce <spearce@xxxxxxxxxxx> writes:
>
> > I find it useful to track what I've sent to you just in case I
> > screw up some ref somewhere. I like knowing that if I perform a
> > bad update-ref call (which I'm prone to do sometimes) that I can
> > recover quickly as the log exists.
>
> I find it interesting to be able to say:
>
> $ git log next@{yesterday}..next
>
> I often find myself getting curious to see:
>
> $ git reflog next
> Wed May 31 14:23:58 2006 -0700
> 62b693a... Merge branch 'master' into next
> ...
Hmm, looks like nobody has actually implemented that - at least not
in 'next'. :-)
Is that a serious feature request? If so I'll do it. BTW: we're
also still lacking reflog during receive-pack. Much of the update()
function in receive-pack.c can be replaced with the new locking
functions, except that if reflog is enabled on the target ref then
GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL need to be set for the
update to succeed.
I've been busy at work but I really have been wanting to put
some time into this GIT Eclipse plugin that I've been neglecting.
Some folks at work are starting to become more interested in it.
I have gotten the really core functionality done; all that is
left is the hard stuff (directory synchronization, push, fetch,
non-delta pack generation for push[1], tree diff).
*1* Generating a simple pack with only deflate compression on the
objects should be trivial. Since this is 100% pure Java code nobody
should be expecting great performance out of it from day 1 anyway.
Sure its not an optimal transport but if you were that worried about
the transfer byte costs to push then you probably would just prefer
to use the native tools code tools anyway.
--
Shawn.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html