Hin-Tak Leung <ht...@users.sourceforge.net> wrote: > That's quite straight-forward, I think - except for the recent burst (I am > essentially > adapting the git 2.1.0 release shipped by the upcoming fedora 21 scheduled > for christmas) > I tend to update to the latest fedora release about a week or two after > release; > fedora 17 was shipped in May 2012 and only just enter Alpha in 22 Feb 2012. > and I tracked R at least as frequently as weekly around then; > So I would be using what ever version of git was shipping with fedora 16 > around late > Feb 2012. > > On fedora's build farm, git-1.7.7.5 was bult in dec 2011 and git-1.7.7.6 was > built > on 2012-01-19 . Depending on how soon > 1.7.7.6 filtered down to update, and when I update my git and also tracked R, > (all three of these events probably happened around 22 Feb), I could be > using either 1.7.7.5 or 1.7.7.6. I still have the system software update log > around > (the repo was cloned on a now-dead system, then moved over when it died), > and presumably I can get git log to show me the fetch date (?), I might > be able to tell whether it is 17.7.5 or 1.7.7.6 if you really want to know.
I tried a full clone on 1.7.7.6 (no git-svn difference from 1.7.7.5). Even with that old git, I was able to reproduce the same merge behavior as current (Junio's) master as well as our recent patches. So I believe r58454, r46925, and r46906 in the R repo are all handled correctly and no mergeinfo-handling regressions are introduced in the latest round of git-svn changes. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
