Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-12-10 19:32:33
On 11/12/2013 13:01, Quoth Edward Diener:
> On 12/10/2013 4:01 PM, Vladimir Prus wrote:
>> 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.
>
> I admit to being a git novice but I am truly shocked that moving a file
> to another place in a repository through some git command does not keep
> all of the previous history. Maybe someone who knows git can explain why
> this is so but it sure seems to me to be a totally erroneous way of
> treating a move.
AFAICT from discussion above, Git behaves the same as SVN, except that
SVN defaults to following moves (and --stop-on-copy disables that) and
Git defaults to not following moves (and --follow enables that).
It's just as painful in SVN to view the contents of a past file through
a copy/move/delete, until you get experienced with peg revisions or you
use an interactive repository browser to view the whole tree as it
appeared in the past.
(And, once you know a commit hash prior to the move, you can use "gitk
5a0d9820ac6bd4068a1fa3075d45904ed5341675" to view that revision and its
history, just like you can with SVN.)