Recording the date at which a change was pushed to Savannah

Recording the date at which a change was pushed to Savannah

[Glenn Morris]

If I've understood correctly, "the date that a change was applied to the
Emacs repository on Savannah" is not something that is recorded.
Neither of the two dates that git does record correspond to that
(neither of those dates seems especially useful to me).

I've seen it suggested that enabling the reflog on the server (and
disabling expiry), plus a post-receive hook to add the information to a
note, will do it. E.g.:

http://mnaoumov.wordpress.com/2013/01/31/git-get-push-date/

Is it worth implementing that, or should I give up my quaint, naive
desire to know "when did X happen"?

Re: Recording the date at which a change was pushed to Savannah

[Yuri Khan]

On Tue, Dec 2, 2014 at 8:55 AM, Glenn Morris <rgm@gnu.org> wrote:
>
> If I've understood correctly, "the date that a change was applied to the
> Emacs repository on Savannah" is not something that is recorded.
> Neither of the two dates that git does record correspond to that
> (neither of those dates seems especially useful to me).

If a single commit is made on a release branch or on master and
immediately pushed, then both its Author and Committer dates are
reasonably close to the push.

If a feature branch is rebased to the current state of a release
branch or master and then immediately pushed, then the Committer date
of each commit that changed during rebase is reasonably close to the
push.

If a feature branch is merged into a release branch or master and the
merge is immediately pushed, then both dates of the merge commit are
reasonably close to the push.

The only case when you don’t know the date some commit was pushed is
if it is one in a long series of commits which was pushed as a
fast-forward:

A:
o---o origin/master
     \
      o---o---o---o master

$ git push origin master

B:
o---o---o---o---o---o origin/master, master


To avoid this situation, you can adopt a convention that pushes to
release branches and master SHOULD be either single commits made or
non-trivially rebased immediately before the push, or explicit merges
of other branches.


To get from local state A to the desired pre-push state, one does

$ git branch my-feature
$ git reset --hard origin/master
$ git merge --no-ff my-feature
$ git push origin master
$ git branch -d my-feature

o---o---------------o origin/master, master
     \             /
      o---o---o---o


> I've seen it suggested that enabling the reflog on the server (and
> disabling expiry), plus a post-receive hook to add the information to a
> note, will do it. E.g.:
>
> http://mnaoumov.wordpress.com/2013/01/31/git-get-push-date/

In normal circumstances, reflogs are highly volatile. It looks like a
bad idea to rely on them.

Recording the date at which a change was pushed to Savannah

[Stephen J. Turnbull]

Glenn Morris writes:

 > If I've understood correctly, "the date that a change was applied to the
 > Emacs repository on Savannah" is not something that is recorded.

It can't be recorded in the commit itself; that would require creating
a new commit which would have a different SHA1.

 > Is it worth implementing that, or should I give up my quaint, naive
 > desire to know "when did X happen"?

Using a note seems like a perfectly reasonable idea to me.

Re: Recording the date at which a change was pushed to Savannah

[Stefan Monnier]

> If I've understood correctly, "the date that a change was applied to the
> Emacs repository on Savannah" is not something that is recorded.

Indeed.

> Is it worth implementing that, or should I give up my quaint, naive
> desire to know "when did X happen"?

I don't think it's worth it.  Because of the "fast-forward-only"
constraint, if you have commit C1, C2, C3, coming from unrelated people,
while we don't know exactly when each one of them was pushed we do know
that commit C2 was *pushed* before commit C3 was *created* and similarly
commit C1 was *pushed* before commit C2 was *created*.  So the "push"
can be reasonably well approximated by the commit time, tho doing it
programmatically is probably hard.


        Stefan

Re: Recording the date at which a change was pushed to Savannah

[Glenn Morris]

So what I take away from this is what I can't know when Y happened, I
can only know it was after X and before Z. Whoop.

I find the Git date fields actively misleading, especially in the case
of commits merged from another branch. Eg on master:

git log -1 --format=fuller 2fa082c00315801f0215685aa6032179615d2b55 

  AuthorDate: Wed Nov 19 20:33:17 2014 +0200
  CommitDate: Wed Nov 19 20:35:17 2014 +0200

This change was actually pushed to trunk 10 days later, on Nov 29.

Obviously the same sort of thing will apply if someone delays pushing
their local commits to Savannah. Or the next time a long-lived feature
branch gets merged to master.

I've already been confused by this once (in trying to figure out what
went on in some recent merge commits), and expect to be confused by it
again in future. Basically all I can do is ignore the Date fields
completely, or treat them as lower limits.

Re: Recording the date at which a change was pushed to Savannah

[David Kastrup]

Glenn Morris <rgm@gnu.org> writes:

> So what I take away from this is what I can't know when Y happened, I
> can only know it was after X and before Z. Whoop.

Why would that be important?  This is a distributed version control
system with a common history that does not include tracking of the
various ways it was synched.

> I've already been confused by this once (in trying to figure out what
> went on in some recent merge commits), and expect to be confused by it
> again in future. Basically all I can do is ignore the Date fields
> completely, or treat them as lower limits.

What are you trying to use them for?

-- 
David Kastrup

Re: Recording the date at which a change was pushed to Savannah

[Stephen J. Turnbull]

Glenn Morris writes:

 > Obviously the same sort of [commit date/push date lag] will apply
 > if someone delays pushing their local commits to Savannah. Or the
 > next time a long-lived feature branch gets merged to master.

As I wrote before, I think it's reasonable to want to know when a
commit was pushed.  However, since merges are *always* done locally,
they are usually done very shortly before pushing.  Similarly for
one-off commits.  If anybody pushes before you do, you *can't* push in
most common public repo configurations.

AFAICT, the merge date is therefore highly likely to be an accurate
estimate of the push date for all of its parents back to the node at
the public branch (usually master, but the release branches would work
the same way).

 > I've already been confused by this once (in trying to figure out what
 > went on in some recent merge commits), and expect to be confused by it
 > again in future. Basically all I can do is ignore the Date fields
 > completely, or treat them as lower limits.

I don't see a problem with a push hook for adding notes, but I don't
see how it will solve your "confused by commit date" issue.

FWIW, my advice is to ignore those dates, unless you're trying to
compare to "external" events like mailing list posts.  Commits on
parallel branches are *concurrent*; it's not useful to compare them by
dates.  The commits where branches fork and where they merge are
points where the timelines are synchronized, but the interim commits
are not.

If you want commits linearly ordered, you need to rebase.  This is
precisely why many people who favor rebasing workflows like those
workflows.

I suppose if you create your push hook, you will be able to order the
log by push date, and thus create groups of commits that were pushed
at the same time.  But the relevant information for full understanding
of "what happened" in a merge is already present in the DAG, and you
will likely lose some relevant information by grouping by push date.
YMMV; grouping by push date may well be sufficient for your use case.

Regards,

Re: Recording the date at which a change was pushed to Savannah

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Glenn Morris writes:
>
>  > Obviously the same sort of [commit date/push date lag] will apply
>  > if someone delays pushing their local commits to Savannah. Or the
>  > next time a long-lived feature branch gets merged to master.
>
> As I wrote before, I think it's reasonable to want to know when a
> commit was pushed.

This is a distributed version control system.  I can push a branch from
my own repository to repository C, make a pull request for the owner of
repository D, they merge their own branches into the respective results
and push to different branches in the "main" repository where the
branches are eventually merged.

So when was that commit pushed into the upstream repository?  You are
likely looking for something akin to the file creation date of the
object blob in the "upstream" repository.  That's sort of the thing one
might expect to be stored in the ephemeral reflog but it turns out it
isn't.

It's also a very shaky piece of information and must not be part of the
commit itself because then it would change the commit id.  And it really
makes only sense repository-locally.  And it's not like one can access
the reflog of a remote repository either.

So "when a commit was pushed" rather than "committed/created" is
information that cannot sensibly be maintained in distributed version
control systems and workflows with a commit identity in some readily
available form since it is, by its nature, repository-local and thus not
available for anybody not having local access to the main repository.

-- 
David Kastrup

Re: Recording the date at which a change was pushed to Savannah

[Stephen J. Turnbull]

David Kastrup writes:

 > This is a distributed version control system.

IIUC, Glenn isn't interested in the "many repositories" sharing the
common history.  He's interested in the "official" repository
(actually, his local mirror of that, but that's a distinction that
makes no difference to his use case).  From that point of view, it
makes perfect sense to talk about when a commit was pushed to a
particular repository.

 > So when was that commit pushed into the upstream repository?  You are
 > likely looking for something akin to the file creation date of the
 > object blob in the "upstream" repository.

I don't know what Glenn is looking for, aside from the push dates of
each of a set of objects to some repo on Savannah.  I suspect that
creation date of certain files would indeed give a sufficiently
accurate estimate, but of course with packs the blobs don't remain in
the file system and so don't retain a blob creation date in git.

I believe (and tried to explain briefly) that you are correct, that
knowing such push dates won't help him much in understanding "what
happened" in a particular merge.  However, there is some use case that
evidently is quite obvious to him that we may be missing; I don't
think it's useful to speculate about what it is until he tells us more
about it.

Re: Recording the date at which a change was pushed to Savannah

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > This is a distributed version control system.
>
> IIUC, Glenn isn't interested in the "many repositories" sharing the
> common history.  He's interested in the "official" repository
> (actually, his local mirror of that, but that's a distinction that
> makes no difference to his use case).  From that point of view, it
> makes perfect sense to talk about when a commit was pushed to a
> particular repository.

But that does not tell you what made it part of which history in which
branch.

There is
<URL:https://developer.atlassian.com/blog/2014/12/git-2-2-0-released/#signed-pushes>
arrived just now.

This puts a signature not on the act of creating an object but rather of
moving a reference (branch HEAD or tag).  For some workflows, that might
be interesting.  I doubt that it is what Glenn had in mind.

-- 
David Kastrup

Re: Recording the date at which a change was pushed to Savannah

[Stefan Monnier]

> So "when a commit was pushed" rather than "committed/created" is

I think the fundamental thing missing is the "mainline": In Bzr, when
you look at the DAG of the `trunk', you know which commits are on the
mainline and which commits were made on a branch and later merged
onto the mainline.

In Git, you don't know that because you only have the DAG and the
parents of a merge are "unordered".  So the only place that records
something akin to the "mainline" would be the reflog of the master
branch in the git.sv.gnu.org repository but this is transient (and
inaccessible) info.

I guess one of the use case is when trying to reconstruct a ChangeLog
where the dates should be "the date at which this change appeared on the
mainline".

For most other use cases that come to mind, there are ways to get the
same info by analyzing the DAG rather than the dates (e.g. figure out if
a particular commit was present in release NN.MM).


        Stefan

Re: Recording the date at which a change was pushed to Savannah

[Yuri Khan]

On Wed, Dec 3, 2014 at 8:18 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I think the fundamental thing missing is the "mainline": In Bzr, when
> you look at the DAG of the `trunk', you know which commits are on the
> mainline and which commits were made on a branch and later merged
> onto the mainline.
>
> In Git, you don't know that because you only have the DAG and the
> parents of a merge are "unordered".

Parents are in fact ordered; you can find out each merge’s parents by
addressing them as <rev>^1 for first parent, <rev>^2 etc.

This makes it possible to devise workflows that make it possible to
determine the mainline history. For example, agree that when feature
branches are merged into master, the previous master has to be the
first parent and branches have to be the second and subsequent
parents. Then the mainline is the transitive closure found by starting
at current master and following only the first parents of each commit.

Re: Recording the date at which a change was pushed to Savannah

[Stefan Monnier]

> This makes it possible to devise workflows that make it possible to
> determine the mainline history.

It is not realistic to expect we'll be able to make all Emacs committers
to follow such rules.  It's hard enough to get them to write proper
commit message.


        Stefan

Re: Recording the date at which a change was pushed to Savannah

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 03 Dec 2014 09:18:42 -0500
> Cc: emacs-devel@gnu.org
> 
> > So "when a commit was pushed" rather than "committed/created" is
> 
> I think the fundamental thing missing is the "mainline": In Bzr, when
> you look at the DAG of the `trunk', you know which commits are on the
> mainline and which commits were made on a branch and later merged
> onto the mainline.
> 
> In Git, you don't know that because you only have the DAG and the
> parents of a merge are "unordered".

You can see the "mainline" in Git with "log --graph" or in Emacs with
"C-x v L".

Re: Recording the date at which a change was pushed to Savannah

[Stefan Monnier]

> You can see the "mainline" in Git with "log --graph" or in Emacs with
> "C-x v L".

No, that's *a* mainline.  It won't always agree with your idea of what
is *the* mainline.


        Stefan

Re: Recording the date at which a change was pushed to Savannah

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dak@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 03 Dec 2014 14:00:56 -0500
> 
> > You can see the "mainline" in Git with "log --graph" or in Emacs with
> > "C-x v L".
> 
> No, that's *a* mainline.  It won't always agree with your idea of what
> is *the* mainline.

In what way and under which circumstances might that happen?

Re: Recording the date at which a change was pushed to Savannah

[Stefan Monnier]

>> > You can see the "mainline" in Git with "log --graph" or in Emacs with
>> > "C-x v L".
>> No, that's *a* mainline.  It won't always agree with your idea of what
>> is *the* mainline.
> In what way and under which circumstances might that happen?

IIRC when you do:

    git commit
    git pull
    <merge&commit>
    git push

The merge commit will put what was previously "the mainline" in the
"second" position, while your "git commit" will now appear as being on
"the mainline".


        Stefan

Re: Recording the date at which a change was pushed to Savannah

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dak@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 03 Dec 2014 14:34:13 -0500
> 
> >> > You can see the "mainline" in Git with "log --graph" or in Emacs with
> >> > "C-x v L".
> >> No, that's *a* mainline.  It won't always agree with your idea of what
> >> is *the* mainline.
> > In what way and under which circumstances might that happen?
> 
> IIRC when you do:
> 
>     git commit
>     git pull
>     <merge&commit>
>     git push
> 
> The merge commit will put what was previously "the mainline" in the
> "second" position, while your "git commit" will now appear as being on
> "the mainline".

That's why we recommend "git pull --rebase" in this case (and I
actually pull.rebase = preserve in my .gitconfig).

But in any case, no matter how the mainline became one, it is still
_the_ mainline, right?

Re: Recording the date at which a change was pushed to Savannah

[Stefan Monnier]

>> IIRC when you do:
>> 
>> git commit
>> git pull
>> <merge&commit>
>> git push
>> 
>> The merge commit will put what was previously "the mainline" in the
>> "second" position, while your "git commit" will now appear as being on
>> "the mainline".

> That's why we recommend "git pull --rebase" in this case (and I
> actually pull.rebase = preserve in my .gitconfig).

There might also be a way to ask Git to generate the "merge commit" with
its two parent swapped.

> But in any case, no matter how the mainline became one, it is still
> _the_ mainline, right?

No, in the above example, the commit that was the head of the remote
branch before the "git push" (and was hence obviously on "the" mainline)
is not in "the" mainline after the "git push".


        Stefan

Re: Recording the date at which a change was pushed to Savannah

[Yuri Khan]

On Thu, Dec 4, 2014 at 3:10 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>>> git commit
>>> git pull
>>> <merge&commit>
>>> git push

Assuming you’re doing this on local master and the pull brings in new
commits from the remote master, this, indeed, introduces a backwards
merge.

>> That's why we recommend "git pull --rebase" in this case (and I
>> actually pull.rebase = preserve in my .gitconfig).

+1.

> There might also be a way to ask Git to generate the "merge commit" with
> its two parent swapped.

Yes and it’s called $ git branch temp; git checkout master; A: git
fetch; git reset --hard origin/master; git merge temp; git push origin
master || goto A; git branch --delete temp (retroactively create a
local feature branch and merge that into fully up-to-date master).

Re: Recording the date at which a change was pushed to Savannah

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dak@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 03 Dec 2014 16:10:30 -0500
> 
> > But in any case, no matter how the mainline became one, it is still
> > _the_ mainline, right?
> 
> No, in the above example, the commit that was the head of the remote
> branch before the "git push" (and was hence obviously on "the" mainline)
> is not in "the" mainline after the "git push".

Yes, but that's just means the mainline moved.  It will still be shown
the same to you and me, right?

Re: Recording the date at which a change was pushed to Savannah

[Glenn Morris]

Stefan Monnier wrote:

> So the only place that records something akin to the "mainline" would
> be the reflog of the master branch in the git.sv.gnu.org repository
> but this is transient (and inaccessible) info.

IIUC, I did suggest making it permanent and accessible (via notes).

I'm not sure I'll bother, but would anyone actively object if I were to
spend my own time on that? Does it impact on the server performance
or somesuch?

Re: Recording the date at which a change was pushed to Savannah

[Stefan Monnier]

>> So the only place that records something akin to the "mainline" would
>> be the reflog of the master branch in the git.sv.gnu.org repository
>> but this is transient (and inaccessible) info.
> IIUC, I did suggest making it permanent and accessible (via notes).

Indeed.

> I'm not sure I'll bother, but would anyone actively object if I were to
> spend my own time on that?

Of course not.

> Does it impact on the server performance or somesuch?

I wouldn't think so, no,


        Stefan