Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.

Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-12-10 22:19:30

On 12/10/2013 7:32 PM, Gavin Lambert wrote:
> 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 sounded like in git one must continuously specify --follow after the 
move with each commit in order to preserve history, or was the person 
who said that mistaken ?

Intuitively to me once one uses a command to tell git that a file in a 
repository is being moved/renamed to something else in the repository 
and that the previous history should follow that file, then one should 
always be able to see the full history of that file both before ane 
after the move/rename.

>
> 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.)

I do not think that one should ever have to know some abstruse commit 
number in order to see the history of a file in a repository.