Nicolas Pitre [off-list ref] writes:
What I think you want and what you should talk about is that you're
interested into the "local appearance time" for a given commit and not
"local commit time". Using that terminology is probably much less
confusing in the GIT world.
To do so you'll need a GIT command that doesn'T exist yet. Let's call
it git-local-arrival. It could be defined as follows:
SYNOPSIS
git-local-arrival <committish>
DESCRIPTION
The command displays the time when given commit appeared in the
local repository.
This should be certainly doable, but local-arrival may not be
interesting if the repository has more than one branches. Maybe
git-local-arrival <committish> [<branch>]
which defaults to the current branch?
On Wed, 27 Sep 2006, Junio C Hamano wrote:
Nicolas Pitre [off-list ref] writes:
quoted
SYNOPSIS
git-local-arrival <committish>
DESCRIPTION
The command displays the time when given commit appeared in the
local repository.
This should be certainly doable, but local-arrival may not be
interesting if the repository has more than one branches. Maybe
git-local-arrival <committish> [<branch>]
which defaults to the current branch?
Indeed. I didn't mention it initially because it is really easy to do
once you have it working for the current branch. The technical
challenge is about making it efficient to find out which reflog entry
with a path to given commit is the oldest.
Nicolas
Nicolas Pitre [off-list ref] writes:
On Wed, 27 Sep 2006, Junio C Hamano wrote:
quoted
Nicolas Pitre [off-list ref] writes:
quoted
SYNOPSIS
git-local-arrival <committish>
DESCRIPTION
The command displays the time when given commit appeared in the
local repository.
This should be certainly doable, but local-arrival may not be
interesting if the repository has more than one branches. Maybe
git-local-arrival <committish> [<branch>]
which defaults to the current branch?
Indeed. I didn't mention it initially because it is really easy to do
once you have it working for the current branch. The technical
challenge is about making it efficient to find out which reflog entry
with a path to given commit is the oldest.
The more I think about this, if we were to add yet another
command, I think it should be a command that lets us inspect
ref-log. We do not have an UI other than @{time} syntax to
interact with it right now.
What are the things we would want? Here is a strawman.
- List when and how a branch was changed.
git ref-log --list --type=merge next (when did I merge into my 'next'?)
git ref-log --list --type=merge (ditto but any branches)
git ref-log --list next (any changes not just 'merge')
I expect the output would give timestamp and reason comment;
in addition the branch name when no branch is specified.
Type does not have to be a concrete thing -- it could just be
a substring match in the reason comment string.
Also we would limit output with -n <limit>. The output
should be sorted by the timestamp of ref-log entry -- we are
talking about a particular repository's ref-log, so its
timestamp has more sane meaning than in distributed case.
- Find which branches currently contains a commit, and find the
earliest time that the commit became part of each of them.
git ref-log $commit next master (when did it enter 'next' and
when did it graduate to 'master'?)
git ref-log $commit (ditto but any branches)
I expect the output to be the timestamp and reason comment;
in addition the branch name when no branch is specified.
Also for a shared repository, the person who made the change
would be a reasonable thing to report.
So for consistency, in all cases we could make the output
format like this:
branch SP time-and-zone SP name SP email SP reason-comment LF
where time-and-zone is human-readable timestamp as we see in
git-log output.
Junio C Hamano [off-list ref] wrote:
The more I think about this, if we were to add yet another
command, I think it should be a command that lets us inspect
ref-log. We do not have an UI other than @{time} syntax to
interact with it right now.
Agreed. I've been missing such a command and have wanted to add
one but it wasn't important enough to me to actually code it. :)
What are the things we would want? Here is a strawman.
- List when and how a branch was changed.
git ref-log --list --type=merge next (when did I merge into my 'next'?)
git ref-log --list --type=merge (ditto but any branches)
git ref-log --list next (any changes not just 'merge')
I expect the output would give timestamp and reason comment;
in addition the branch name when no branch is specified.
Type does not have to be a concrete thing -- it could just be
a substring match in the reason comment string.
What about --grep=pat instead of --type?
You are talking about essentially the same behavior as
`git log --grep=pat` except applying it to the message
in the reflog rather than to message in the commits.
Also I think that this should be the default behavior
and thus --list shouldn't be an option. This matches
git-log's default behavior to just show whatever is
in the named branches.
Also we would limit output with -n <limit>.
I'd limit with "--max-count=<n>" like we do with git-log.
The output
should be sorted by the timestamp of ref-log entry -- we are
talking about a particular repository's ref-log, so its
timestamp has more sane meaning than in distributed case.
Agreed, sorting newest -> oldest so newest displays first, much as
git-log does. This way its order of operation, much as git-log is
order of operation.
If multiple branches are specified we really should interleave the
various reflogs according to timestamps, to show the "global picture"
of what happened in this repository.
- Find which branches currently contains a commit, and find the
earliest time that the commit became part of each of them.
git ref-log $commit next master (when did it enter 'next' and
when did it graduate to 'master'?)
git ref-log $commit (ditto but any branches)
Since I'm suggesting above that this behavior not be the default
what about:
git ref-log --arrive=$commit next master
git ref-log --arrive=$commit
?
I expect the output to be the timestamp and reason comment;
in addition the branch name when no branch is specified.
Agreed.
Also for a shared repository, the person who made the change
would be a reasonable thing to report.
I think that should be shown no matter what; even if
core.sharedRepository is false.
So for consistency, in all cases we could make the output
format like this:
branch SP time-and-zone SP name SP email SP reason-comment LF
That's too long of a line with most reason-comments in the ref-log.
Especially ones that come from git-commit, and especially if they
were human written commit messages.
I'd like to see the output be more like git-log. Allow a --pretty
option with a few useful formats:
--pretty=full:
branch branchname LF
from old
to new
Modifier: name SP email
Date: time-and-zone
reason-comment
--pretty=oneline:
branchname SP time-and-zone SP name SP email SP reason-comment LF
--pretty=raw is obviously the exact line in the reflog but with
the branch name preceeding it if more than one branch was specified
or none were specified.
And --pretty=full should be the default, much as --pretty=medium
is with git-log.
--
Shawn.