Loss of all package history following the recipe rename.

Loss of all package history following the recipe rename.

[John Willis]

People,

Am I right in assuming that the decision to drop history for all packages
was really an unintentional side effect of this change? 

Unless I am going totally nuts the ONLY history for a given package now is
the 'git mv' commit.

i.e. on GIT HEAD

git log recipes/abiword/abiword-plugins_2.5.2.bb
commit 709c4d66e0b107ca606941b988bad717c0b45d9b
Author: Denys Dmytriyenko <denis@denix.org>
<snip, only the only commit logged>

On an old tree I keep for reference.

git log packages/abiword/abiword-plugins_2.5.2.bb
<snip, page after page of commits logged>

I just checked and the behavior of 'git mv' and it seems it's really just
'git rm && git add' under the hood, a few local experiments seem to confirm
that is the by design behavior (seems totally insane for a source control
system to do that however :-o) and after the 'git rm' the history is toast
as your then creating a new object with the same content as the removed one
:(.

I am not sure what we can do about this without resorting to a revert but it
looks like we may wish to look into something like 'git-filter-branch' (and
several other tools) to redo the move with something like the history
intact. 

That said, 'git-filter-branch' is a little scary and is proving to be more
then I really planned to be messing with on a sunny afternoon and I am not
totally sure if it will even do what is needed.

Does anyone have any other ideas or comment? Or have I completely lost the
plot and there is not really any problem other then in my local trees?

Regards,

John

--

> What is a grue?

The grue is a sinister, lurking presence in the dark places of the earth.
Its favourite diet is adventurers, but its insatiable appetite is tempered
by its fear of light. No grue has ever been seen by the light of day, and
few have survived its fearsome jaws to tell the tale.

Re: Loss of all package history following the recipe rename.

[John Willis]

<snip>

After kergoth took the time to point out that I was just looking at this
'the wrong way' and not 'the GIT way' I think the mail can safely be
disregarded ;-). 

It still does not change the fact that the behavior of 'git log' gave me a
real panic moment but at least nothing is lost if your happy to dig (or
rather use git log --follow, ok, next time I promise to read the man page
before panicking ;-), I am just used to --follow functionality being a
default behavior).

Regards,

John

Re: Loss of all package history following the recipe rename.

[Koen Kooi]

On 18-03-09 16:23, John Willis wrote:

> That said, 'git-filter-branch' is a little scary

We can't run that anymore on OE, since git changed the behaviour of the 
crud() function since we migrated and will change author names (no 
trailing '.' allowed anymore).

regards,

Koen

Re: Loss of all package history following the recipe rename.

[Chris Larson]

On Wed, Mar 18, 2009 at 8:38 AM, John Willis
<John.Willis@distant-earth.com> wrote:
> <snip>
>
> After kergoth took the time to point out that I was just looking at this
> 'the wrong way' and not 'the GIT way' I think the mail can safely be
> disregarded ;-).
>
> It still does not change the fact that the behavior of 'git log' gave me a
> real panic moment but at least nothing is lost if your happy to dig (or
> rather use git log --follow, ok, next time I promise to read the man page
> before panicking ;-), I am just used to --follow functionality being a
> default behavior).

Re: default behavior, I'm not entirely certain, but the 'diff.renames'
git config parameter seems promising.  Try running:
git config diff.renames true

I'm not sure if git log --follow is the same thing as git diff-tree
-M, but it probably is, since git log is essentially git rev-list |
git diff-tree.
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.

Re: Loss of all package history following the recipe rename.

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]

Chris Larson wrote:
> On Wed, Mar 18, 2009 at 8:38 AM, John Willis
> <John.Willis@distant-earth.com> wrote:
>> <snip>
>>
>> After kergoth took the time to point out that I was just looking at this
>> 'the wrong way' and not 'the GIT way' I think the mail can safely be
>> disregarded ;-).
>>
>> It still does not change the fact that the behavior of 'git log' gave me a
>> real panic moment but at least nothing is lost if your happy to dig (or
>> rather use git log --follow, ok, next time I promise to read the man page
>> before panicking ;-), I am just used to --follow functionality being a
>> default behavior).
> 
> Re: default behavior, I'm not entirely certain, but the 'diff.renames'
> git config parameter seems promising.  Try running:
> git config diff.renames true
> 
> I'm not sure if git log --follow is the same thing as git diff-tree
> -M, but it probably is, since git log is essentially git rev-list |
> git diff-tree.

A friend of mine pointed me at this article:

http://markmail.org/message/x7ubgl6wanubwa3g#query:git%20mv%20lost%20history+page:1+mid:pl3pbiuhzu2excg7+state:results

Hopefully, this makes more send to the git gurus.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Loss of all package history following the recipe rename.

[Chris Larson]

2009/3/18 Philip Balister <philip@balister.org>:
> Chris Larson wrote:
>>
>> On Wed, Mar 18, 2009 at 8:38 AM, John Willis
>> <John.Willis@distant-earth.com> wrote:
>>>
>>> <snip>
>>>
>>> After kergoth took the time to point out that I was just looking at this
>>> 'the wrong way' and not 'the GIT way' I think the mail can safely be
>>> disregarded ;-).
>>>
>>> It still does not change the fact that the behavior of 'git log' gave me
>>> a
>>> real panic moment but at least nothing is lost if your happy to dig (or
>>> rather use git log --follow, ok, next time I promise to read the man page
>>> before panicking ;-), I am just used to --follow functionality being a
>>> default behavior).
>>
>> Re: default behavior, I'm not entirely certain, but the 'diff.renames'
>> git config parameter seems promising.  Try running:
>> git config diff.renames true
>>
>> I'm not sure if git log --follow is the same thing as git diff-tree
>> -M, but it probably is, since git log is essentially git rev-list |
>> git diff-tree.
>
> A friend of mine pointed me at this article:
>
> http://markmail.org/message/x7ubgl6wanubwa3g#query:git%20mv%20lost%20history+page:1+mid:pl3pbiuhzu2excg7+state:results
>
> Hopefully, this makes more send to the git gurus.

Aye, it seems that doing 'git log .' inside the renamed directory
won't show the history across the rename boundary, only if you look at
the log without specifying a path, or if you specify a single file and
use --follow.  That's somewhat annoying :\

Side note: if you're doing a git log -p, you probably want to do git
log -M -p, so you don't see the add/remove of every file in the diffs
for the renames.
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.