> 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
Linus TorvaldsOn Sun, 29 Jul 2007, Matthew L Foster wrote:
> > > 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
--- Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 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
On Sun, 29 Jul 2007, Matthew L Foster wrote:
> --- Linus Torvalds <torvalds@linux-foundation.org> wrote: > >> 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
--- 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/
On Mon, 30 Jul 2007, Matthew L Foster wrote:
> --- 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?
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/ >
--- david@lang.hm wrote:
> On Mon, 30 Jul 2007, Matthew L Foster wrote: > > 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
On Mon, 30 Jul 2007, Matthew L Foster wrote:
> --- david@lang.hm wrote: > >> On Mon, 30 Jul 2007, Matthew L Foster wrote: >>> 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?
if you have reflogs enabled on your copy of the git repository then you can look at when things were merged into your copy.
David Lang
Robin Rosenbergmåndag 30 juli 2007 skrev Matthew L Foster:
> > --- david@lang.hm wrote: > > > On Mon, 30 Jul 2007, Matthew L Foster wrote: > > > 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