From: Matthew L Foster <hidden> Date: 2016-06-15 22:43:24
but if git did what you wanted it would show every commit with the time of
the merge, and that wouldn't help you anyway.
Actually that is exactly what I want. I want to know what local time change X and Y (and all
changes) were merged locally.
-Matt
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting
but if git did what you wanted it would show every commit with the time of
the merge, and that wouldn't help you anyway.
Actually that is exactly what I want. I want to know what local time change X and Y (and all
changes) were merged locally.
You misunderstand. It would do so both for the newly merged commits *and*
for the old commits. Because _you_ think the "new" commits got merged, but
it's logically exactly equivalent to saying that the *old* commits got
merged.
So now *every* single commit would get the timestamp of the merge.
See? It would be pointless.
Linus
You misunderstand. It would do so both for the newly merged commits *and*
for the old commits. Because _you_ think the "new" commits got merged, but
it's logically exactly equivalent to saying that the *old* commits got
merged.
So now *every* single commit would get the timestamp of the merge.
See? It would be pointless.
Ok maybe I am still confused. If a repository is in state A and a merge happens changing it to
state B we can give the changes that got us to B the timestamp of the merge? Since the changes
that got us from A to B were all merged locally at the same time they should be given the same
timestamp, right? Please explain more about how changes/commits in state A would also be given the
timestamp of the merge?
When I say local time I also really mean local commit order as both should be interchangeable
unless you widly misset/change your local clock. Git/gitweb could have an option to sort/display
based on local commit order and maybe have check for if local time order is out of sync with local
commit order.
-Matt
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222
You misunderstand. It would do so both for the newly merged commits *and*
for the old commits. Because _you_ think the "new" commits got merged, but
it's logically exactly equivalent to saying that the *old* commits got
merged.
So now *every* single commit would get the timestamp of the merge.
See? It would be pointless.
Ok maybe I am still confused. If a repository is in state A and a merge happens changing it to
state B we can give the changes that got us to B the timestamp of the merge? Since the changes
that got us from A to B were all merged locally at the same time they should be given the same
timestamp, right? Please explain more about how changes/commits in state A would also be given the
timestamp of the merge?
When I say local time I also really mean local commit order as both should be interchangeable
unless you widly misset/change your local clock. Git/gitweb could have an option to sort/display
based on local commit order and maybe have check for if local time order is out of sync with local
commit order.
one feature of git (and I think of truely distributed change management
systems)
say you have tree A and I have tree B
if you clone your tree and merge from mine, and I clone my tree and merge
from yours, the result of both merges _must_ be the same there will be
trouble when we both try and merge with tree C later on.
another thing is that a given commit cannot be changed once it's created
(if it was changed it wouldn't have the same sha1 value) so you can't just
go around changeing dates on commits that took place elsewhere.
David Lang
From: Matthew L Foster <hidden> Date: 2016-06-15 22:43:25
--- david@lang.hm wrote:
if you clone your tree and merge from mine, and I clone my tree and merge
from yours, the result of both merges _must_ be the same there will be
trouble when we both try and merge with tree C later on.
another thing is that a given commit cannot be changed once it's created
(if it was changed it wouldn't have the same sha1 value) so you can't just
go around changeing dates on commits that took place elsewhere.
Local commit order is stored locally right? From looking at gitweb on kernel.org it seems all the
info is already there, a merge has a list of commits in that merge and they should be displayed in
local commit order rather than external creation time order.
-Matt
____________________________________________________________________________________Ready for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/
if you clone your tree and merge from mine, and I clone my tree and merge
from yours, the result of both merges _must_ be the same there will be
trouble when we both try and merge with tree C later on.
another thing is that a given commit cannot be changed once it's created
(if it was changed it wouldn't have the same sha1 value) so you can't just
go around changeing dates on commits that took place elsewhere.
Local commit order is stored locally right?
not normally. you could enable reflogs and then mine through the reflogs
to find the info, but it's not stored in any easy to access fashion.
David Lang
From looking at gitweb on kernel.org it seems all the
info is already there, a merge has a list of commits in that merge and they should be displayed in
local commit order rather than external creation time order.
-Matt
____________________________________________________________________________________Ready for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/
From: Matthew L Foster <hidden> Date: 2016-06-15 22:43:25
--- david@lang.hm wrote:
On Mon, 30 Jul 2007, Matthew L Foster wrote:
quoted
Local commit order is stored locally right?
not normally. you could enable reflogs and then mine through the reflogs
to find the info, but it's not stored in any easy to access fashion.
Local merge order can be extracted from git?
-Matt
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433
From: Robin Rosenberg <hidden> Date: 2016-06-15 22:43:25
måndag 30 juli 2007 skrev Matthew L Foster:
quoted hunk
--- david@lang.hm wrote:
quoted
On Mon, 30 Jul 2007, Matthew L Foster wrote:
quoted
Local commit order is stored locally right?
not normally. you could enable reflogs and then mine through the reflogs
to find the info, but it's not stored in any easy to access fashion.
Local merge order can be extracted from git?
Well.. depending on what your definition of merge. Yes, probably.
I dislike the term "merge" here, since no merges has to be involved, unless you
include any pulled commit into the terms. Normally a merge is a commit with
two or more parents. Fast forward merges are indistinguishable from normal
commits.
That aside, you *can* (usually) figure the time when a commit entered the repository by examining the
reflog if the set of branches are reasonably stable The reflog gives the local time when a head
was modified (old and new commit) so from there you can usually go backwards. *But* that road is
full of pot holes. The reflog cannot per se tell when a commit entered the local repo, it can
tell when it came into view as seen from a particular head. Looking from different heads may
(will) give you different times. If the head that was used to pull the commit into the repo is
deleted you will not be able to tell when the commit entered the repo, nor will you be able to
tell whether you can tell that or not, since the reflog for that head is gone.
The reflog doesn't list all commits, just changes to the head and it isn't necessarily linear either, ie.
it may change backward in "time" forward or even to a completely separate set of commits.
The reflog is text-only: .git/logs/<ref-name>, e.g. .git/logs/refs/heads/master so you can see for
yourself.
-- robin