Re: Joining cg-*-id
From: Petr Baudis <hidden>
Date: 2016-06-15 22:42:06
Dear diary, on Tue, Sep 20, 2005 at 02:50:21AM CEST, I got a letter where Linus Torvalds [off-list ref] told me that...
On Tue, 20 Sep 2005, Petr Baudis wrote:quoted
But that semantics sucks, and I wouldn't mind changing it at all. I think taking the previous commit works for everything but the start of cg-log range, and it is how CVS behaves.The thing is, it may have sensible behaviour for CVS, but only because CVS doesn't have any notion of concurrent development (even a branch isn't concurrent - it's totally separate, and when you merge it, it becomes just one big diff at the time of the merge). So I'd love to have git diff yesterday.. but the fact is, there's no sensible semantics for it. _which_ yesterday? There might be five different points that are "close to 24 hours ago", along five different paths backwards in the history.
A well-defined meaning for this from Cogito standpoint would be "the last commit on our HEAD before the date and all commits committed and merged to the HEAD". In Cogito, you don't merge two branches _together_, you merge one branch _into_ another (represented by the parents order), so this would be sensible. But we would have to sort the log in merge order for this to be possible (and probably teach git-rev-list about it anyway). I would absolutely *love* to have cg-log in merge order instead of date order - longer I see it the more I believe that it's evil and you should really want merge order instead. The trouble is that cg-log would be no longer incremental and would have to load the whole history first, a no-go for any measurably long history. By the way, did I understand it right that the only difference between the results of merge ordering and topo ordering is the order commits with regard to the order of parents? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't.