On 11.12.2013 00:04, Edward Diener wrote:
On 12/10/2013 11:42 AM, Vladimir Prus wrote:
On 10.12.2013 20:36, Mathias Gaunard wrote:
On 10/12/13 16:45, Vladimir Prus wrote:
As I've said on Boost.Build mailing list, such a policy or mechanism shall only be in effect after everybody reviews results of the conversion for real, and is happy with them. The conversion was, to a degree, rushed, so we need a time to fix issues before we declare we're really done with the transition to git and start playing by git rules.
Isn't that period over according to the planning? There was a period for library authors to review the history migrated to git.
FWIW, during that period, I did express a preference for 'build' repository to have everything at top level, as opposed to 'v2' subdir.
Why can't you move it to the top level rather than have it at 'v2', then commit the changes and push to develop ? Do you mean that your history is lost in git for a file if you move it to another place in the repository ? Being a git novice that's hard to believe.
After this change, git log file will output a single commit. You can kinda fix this by passing --follow, but you need to do this every time, there's no documented way to have it as default. Further, gitk does not appear to handle this at all, it just shows a single revision (e.g. if run like 'gitk build/virtual-target.jam'). Then, printing past becomes inconvenient: $ git show 5a0d9820ac6bd4068a1fa3075d45904ed5341675:build/virtual-target.jam fatal: Path 'build/virtual-target.jam' exists on disk, but not in '5a0d9820ac6bd4068a1fa3075d45904ed5341675' It is possible to use v2/build/virtual-target.jam in this case, but it's becoming not funny. And, importantly, given that a few people said that rename should "just work", which is demonstrably false, I suspect that there are further gotchas beyond the above immediate ones. - Volodya