* Recording the date at which a change was pushed to Savannah
@ 2014-12-02 2:55 Glenn Morris
2014-12-02 4:55 ` Yuri Khan
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Glenn Morris @ 2014-12-02 2:55 UTC (permalink / raw
To: emacs-devel
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"?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-02 2:55 Recording the date at which a change was pushed to Savannah Glenn Morris
@ 2014-12-02 4:55 ` Yuri Khan
2014-12-02 5:05 ` Stephen J. Turnbull
2014-12-02 13:48 ` Stefan Monnier
2 siblings, 0 replies; 23+ messages in thread
From: Yuri Khan @ 2014-12-02 4:55 UTC (permalink / raw
To: Glenn Morris; +Cc: Emacs developers
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Recording the date at which a change was pushed to Savannah
2014-12-02 2:55 Recording the date at which a change was pushed to Savannah Glenn Morris
2014-12-02 4:55 ` Yuri Khan
@ 2014-12-02 5:05 ` Stephen J. Turnbull
2014-12-02 13:48 ` Stefan Monnier
2 siblings, 0 replies; 23+ messages in thread
From: Stephen J. Turnbull @ 2014-12-02 5:05 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-02 2:55 Recording the date at which a change was pushed to Savannah Glenn Morris
2014-12-02 4:55 ` Yuri Khan
2014-12-02 5:05 ` Stephen J. Turnbull
@ 2014-12-02 13:48 ` Stefan Monnier
2014-12-03 6:22 ` Glenn Morris
2 siblings, 1 reply; 23+ messages in thread
From: Stefan Monnier @ 2014-12-02 13:48 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-02 13:48 ` Stefan Monnier
@ 2014-12-03 6:22 ` Glenn Morris
2014-12-03 6:47 ` David Kastrup
2014-12-03 7:51 ` Stephen J. Turnbull
0 siblings, 2 replies; 23+ messages in thread
From: Glenn Morris @ 2014-12-03 6:22 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 6:22 ` Glenn Morris
@ 2014-12-03 6:47 ` David Kastrup
2014-12-03 7:51 ` Stephen J. Turnbull
1 sibling, 0 replies; 23+ messages in thread
From: David Kastrup @ 2014-12-03 6:47 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 6:22 ` Glenn Morris
2014-12-03 6:47 ` David Kastrup
@ 2014-12-03 7:51 ` Stephen J. Turnbull
2014-12-03 8:35 ` David Kastrup
1 sibling, 1 reply; 23+ messages in thread
From: Stephen J. Turnbull @ 2014-12-03 7:51 UTC (permalink / raw
To: Glenn Morris; +Cc: Stefan Monnier, emacs-devel
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,
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 7:51 ` Stephen J. Turnbull
@ 2014-12-03 8:35 ` David Kastrup
2014-12-03 9:50 ` Stephen J. Turnbull
2014-12-03 14:18 ` Stefan Monnier
0 siblings, 2 replies; 23+ messages in thread
From: David Kastrup @ 2014-12-03 8:35 UTC (permalink / raw
To: emacs-devel
"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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 8:35 ` David Kastrup
@ 2014-12-03 9:50 ` Stephen J. Turnbull
2014-12-03 10:04 ` David Kastrup
2014-12-03 14:18 ` Stefan Monnier
1 sibling, 1 reply; 23+ messages in thread
From: Stephen J. Turnbull @ 2014-12-03 9:50 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 9:50 ` Stephen J. Turnbull
@ 2014-12-03 10:04 ` David Kastrup
0 siblings, 0 replies; 23+ messages in thread
From: David Kastrup @ 2014-12-03 10:04 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: emacs-devel
"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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 8:35 ` David Kastrup
2014-12-03 9:50 ` Stephen J. Turnbull
@ 2014-12-03 14:18 ` Stefan Monnier
2014-12-03 16:19 ` Yuri Khan
` (2 more replies)
1 sibling, 3 replies; 23+ messages in thread
From: Stefan Monnier @ 2014-12-03 14:18 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 14:18 ` Stefan Monnier
@ 2014-12-03 16:19 ` Yuri Khan
2014-12-03 18:59 ` Stefan Monnier
2014-12-03 18:02 ` Eli Zaretskii
2014-12-04 2:58 ` Glenn Morris
2 siblings, 1 reply; 23+ messages in thread
From: Yuri Khan @ 2014-12-03 16:19 UTC (permalink / raw
To: Stefan Monnier; +Cc: David Kastrup, Emacs developers
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 14:18 ` Stefan Monnier
2014-12-03 16:19 ` Yuri Khan
@ 2014-12-03 18:02 ` Eli Zaretskii
2014-12-03 19:00 ` Stefan Monnier
2014-12-04 2:58 ` Glenn Morris
2 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2014-12-03 18:02 UTC (permalink / raw
To: Stefan Monnier; +Cc: dak, emacs-devel
> 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".
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 16:19 ` Yuri Khan
@ 2014-12-03 18:59 ` Stefan Monnier
0 siblings, 0 replies; 23+ messages in thread
From: Stefan Monnier @ 2014-12-03 18:59 UTC (permalink / raw
To: Yuri Khan; +Cc: David Kastrup, Emacs developers
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 18:02 ` Eli Zaretskii
@ 2014-12-03 19:00 ` Stefan Monnier
2014-12-03 19:06 ` Eli Zaretskii
0 siblings, 1 reply; 23+ messages in thread
From: Stefan Monnier @ 2014-12-03 19:00 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dak, emacs-devel
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 19:00 ` Stefan Monnier
@ 2014-12-03 19:06 ` Eli Zaretskii
2014-12-03 19:34 ` Stefan Monnier
0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2014-12-03 19:06 UTC (permalink / raw
To: Stefan Monnier; +Cc: dak, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 19:06 ` Eli Zaretskii
@ 2014-12-03 19:34 ` Stefan Monnier
2014-12-03 20:24 ` Eli Zaretskii
0 siblings, 1 reply; 23+ messages in thread
From: Stefan Monnier @ 2014-12-03 19:34 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dak, emacs-devel
>> > 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 19:34 ` Stefan Monnier
@ 2014-12-03 20:24 ` Eli Zaretskii
2014-12-03 21:10 ` Stefan Monnier
0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2014-12-03 20:24 UTC (permalink / raw
To: Stefan Monnier; +Cc: dak, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 20:24 ` Eli Zaretskii
@ 2014-12-03 21:10 ` Stefan Monnier
2014-12-04 2:52 ` Yuri Khan
2014-12-04 6:17 ` Eli Zaretskii
0 siblings, 2 replies; 23+ messages in thread
From: Stefan Monnier @ 2014-12-03 21:10 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dak, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 21:10 ` Stefan Monnier
@ 2014-12-04 2:52 ` Yuri Khan
2014-12-04 6:17 ` Eli Zaretskii
1 sibling, 0 replies; 23+ messages in thread
From: Yuri Khan @ 2014-12-04 2:52 UTC (permalink / raw
To: Stefan Monnier; +Cc: Eli Zaretskii, David Kastrup, Emacs developers
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).
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 14:18 ` Stefan Monnier
2014-12-03 16:19 ` Yuri Khan
2014-12-03 18:02 ` Eli Zaretskii
@ 2014-12-04 2:58 ` Glenn Morris
2014-12-04 3:57 ` Stefan Monnier
2 siblings, 1 reply; 23+ messages in thread
From: Glenn Morris @ 2014-12-04 2:58 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-04 2:58 ` Glenn Morris
@ 2014-12-04 3:57 ` Stefan Monnier
0 siblings, 0 replies; 23+ messages in thread
From: Stefan Monnier @ 2014-12-04 3:57 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Recording the date at which a change was pushed to Savannah
2014-12-03 21:10 ` Stefan Monnier
2014-12-04 2:52 ` Yuri Khan
@ 2014-12-04 6:17 ` Eli Zaretskii
1 sibling, 0 replies; 23+ messages in thread
From: Eli Zaretskii @ 2014-12-04 6:17 UTC (permalink / raw
To: Stefan Monnier; +Cc: dak, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2014-12-04 6:17 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-02 2:55 Recording the date at which a change was pushed to Savannah Glenn Morris
2014-12-02 4:55 ` Yuri Khan
2014-12-02 5:05 ` Stephen J. Turnbull
2014-12-02 13:48 ` Stefan Monnier
2014-12-03 6:22 ` Glenn Morris
2014-12-03 6:47 ` David Kastrup
2014-12-03 7:51 ` Stephen J. Turnbull
2014-12-03 8:35 ` David Kastrup
2014-12-03 9:50 ` Stephen J. Turnbull
2014-12-03 10:04 ` David Kastrup
2014-12-03 14:18 ` Stefan Monnier
2014-12-03 16:19 ` Yuri Khan
2014-12-03 18:59 ` Stefan Monnier
2014-12-03 18:02 ` Eli Zaretskii
2014-12-03 19:00 ` Stefan Monnier
2014-12-03 19:06 ` Eli Zaretskii
2014-12-03 19:34 ` Stefan Monnier
2014-12-03 20:24 ` Eli Zaretskii
2014-12-03 21:10 ` Stefan Monnier
2014-12-04 2:52 ` Yuri Khan
2014-12-04 6:17 ` Eli Zaretskii
2014-12-04 2:58 ` Glenn Morris
2014-12-04 3:57 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.