On Tue, Sep 01, 2015 at 02:27:22AM -0400, Jason Merrill wrote:
> On 08/29/2015 10:58 AM, Dominique d'Humières wrote:
> >>For Jakub or anyone else wanting a key to associate a file with a commit,
> >>they can decide for themselves
> >>what date format they want to use and whether to bother with the user id. I
> >>would think that if he is only
> >>interested in commits on the trunk (and so should use log --first-parent),
> >>the timestamp is sufficient.
> >
> >I share Jakub’s concern about having access to an increasing labeling of the
> >revisions. What would be the replacement of « svn update -r xxxx »?
>
> Given git aliases:
>
> > stamp = show -s --format='%cI!%ce'
> > scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if [
> > $a != $1 ]; then arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg
> > ${1:+\"$@\"}; }; f"
> > smaster = "!f(){ git scommit \"$1\" trunk --first-parent; }; f"
> > shs = "!f(){ git show $(git smaster $1); }; f"
> > slog = "!f(){ s=$1; shift; git log $(git smaster $s) $*; }; f"
> > sco = "!f(){ git checkout $(git smaster $1); }; f"
>
> and an action stamp 2015-08-20T20:55:15Z!jason, then
>
> git sco 2015-08-20T20:55:15Z\!jason
>
> will check out the (most recent) commit with that stamp. It also works with
> just the timestamp.
Personally I'd put a pretty big danger! sign with the most recent part.
Consider for example
github.com/mozilla/gecko-dev/commit/6b54a8373b439296949c7f76f6f875b3146502e5
and
github.com/mozilla/gecko-dev/commit/6a35bb7c377620e48683f30f9ef4afde20b66ed0jj
Personally I find coppy and paste hashes to work fairly well especially
since in most cases I need to look at git log or something to know what
commit I want to check out.
if you want to be nice to readers git.git has the practice of writing
<abreiv sha1> <time> <author name> <subject> which is good for machines
that want sha1s and humans for whom the sha1 works, but can sometimes
save looking anything up if they know the commit subject.
> A timestamp gives you a simple increasing (though sparse) label, though it
> might not always be unique; when I locally rebase several patches I
> sometimes get two or three with the same timestamp, which I expect to be
> preserved if I push them upstream.
uh timestamps are most definitely not guaranteed to increase from
parent commits to their children. It happens to be the case with
git-svn because the timestamp comes from when the commit was made in
the master repo, but if you take away that master svn repo assigning
timestamps to commits then you will end up with child commits whose
date is before their parents. Since rebase updates the commiter date
but not the author one by default I guess you'd have less trouble of
this sort if you used that, but still I wouldn't be suprised if its
pretty easy to make those non monotonic. Oh actually I just noticed
you are using %cI so the commiter time which maybe makes it ok? I'll
continue to stay away, but at least its not obviously a trap.
Trev
>
> Jason
