does adopt work for repairing ancestry? about filetree HOT 9 CLOSED

Adopt does appear to work correctly ... at least it restores the history of the file to what I want ... we can afford to leave the handling of versions in filetree as is ...

from filetree.

Wow, nice one. Must pick the correct one to adpot. Perhaps can get some info from the git commit / version file. Very interesting

from filetree.

Ah yes, good point ... perhaps we should create an ancestor file in the repository that records the version information for the immediate ancestor of package when it is stuffed into the repository (that isn't changed over time) so that one can easily know the immediate ancestor ... I'll reopen this one and address it ...

from filetree.

1. If we really want to be faithful to the ancestry, we need to rewrite the ancestry on every commit.

YUCK!

1. If we want to allow for simple merges of non-filetree packages, we can afford to write the original ancestry and preserve the ancestry over time as suggested above...
2. If we don' t care about ever doing a Monticello merge, we might be able to get away with no ancestry ..

HOLD THE HORSES, what if we have a dirty package in the image and do a pull from git and we want to then merge the changes into our existing work in the image ... we need a common ancestor for the two packages and that may mean that we have to use option #1 all of the time ...

More thought needed...

from filetree.

1. If we really want to be faithful to the ancestry, we need to rewrite the ancestry on every commit.

YUCK!

Yes; we've got a package with > 1000 versions. When loading this
package, the bit that takes the longest is to parse the ancestry file.
Perhaps a "prune" will help.

1. If we want to allow for simple merges of non-filetree packages, we can afford to write the original ancestry and preserve the ancestry over time as suggested above...
2. If we don' t care about ever doing a Monticello merge, we might be able to get away with no ancestry ..

HOLD THE HORSES, what if we have a dirty package in the image and do a pull from git and we want to then merge the changes into our existing work in the image ... we need a common ancestor for the two packages and that may mean that we have to use option #1 all of the time ...

Currently, we don't pull the git repo with dirty packages in the
image. Our workflow is to commit local changes from the image first
(save it to the file tree) and commit it in the local git repo.
Pulling then merges and we reload into the image.

In principle, even with Monticello, we avoided merging when a local
package is dirty. It's "safer" to "snapshot" my local changes before I
merge, because I can always then compare the 2 versions. So that bit
does not bother. It is a bit painful to go from the file tree to the
image, back again, merge in git, load the merge. Takes some time.

I was thinking one could use the history available in git to determine
the ancestry. All the information is there. I'll have to explore a bit
to figure out how.

Git "3 way" merge is actually quite good.

Yes, more thinking needed

from filetree.

Otto,

Right ... that's the model that I've adopted as well (commit dirty packages to git first)...So really the only times when we need to really worry about ancestry in a package is when someone who is not used to using git ends up with a dirty package in the image and wants to merge using Monticello instead of git ...

One idea would be to make the loading of ancestry an option (on by default) that git users would just turn off, because they know what they are doing.

Combine that with the ability to reconstruct the ancestry would be cool ...

Dale

----- Original Message -----
| From: "ottobehrens" [email protected]
| To: "Dale Henrichs" [email protected]
| Sent: Thursday, February 9, 2012 11:43:30 PM
| Subject: Re: [filetree] does adopt work for repairing ancestry? (#2)
|
| > 1. If we really want to be faithful to the ancestry, we need to
| > rewrite the ancestry on every commit.
| >
| > YUCK!
|
| Yes; we've got a package with > 1000 versions. When loading this
| package, the bit that takes the longest is to parse the ancestry
| file.
| Perhaps a "prune" will help.
|
| > 2. If we want to allow for simple merges of non-filetree packages,
| > we can afford to write the original ancestry and preserve the
| > ancestry over time as suggested above...
| >
| > 3. If we don' t care about ever doing a Monticello merge, we might
| > be able to get away with no ancestry ..
| >
| > HOLD THE HORSES, what if we have a dirty package in the image and
| > do a pull from git and we want to then merge the changes into our
| > existing work in the image ... we need a common ancestor for the
| > two packages and that may mean that we have to use option #1 all
| > of the time ...
|
| Currently, we don't pull the git repo with dirty packages in the
| image. Our workflow is to commit local changes from the image first
| (save it to the file tree) and commit it in the local git repo.
| Pulling then merges and we reload into the image.
|
| In principle, even with Monticello, we avoided merging when a local
| package is dirty. It's "safer" to "snapshot" my local changes before
| I
| merge, because I can always then compare the 2 versions. So that bit
| does not bother. It is a bit painful to go from the file tree to the
| image, back again, merge in git, load the merge. Takes some time.
|
| I was thinking one could use the history available in git to
| determine
| the ancestry. All the information is there. I'll have to explore a
| bit
| to figure out how.
|
| Git "3 way" merge is actually quite good.
|
| Yes, more thinking needed
|
| ---
| Reply to this email directly or view it on GitHub:
| #2 (comment)
|

from filetree.

I'm going to restore the writing/reading of ancestry info for fileTree packages ... it's ugly right now, but I think it is the only way to make it easy for folks to migrate to using filtree/git/github. If the ancestry is preserved across package lifetimes within a filetree/git/guthub repository, the perceived cost of taking a run at using github is much much lower (no waving hands about setting flags or having to remember to adopt) ...

I agree 100% that the three way merge for git is superior ... it recognizes renames and method moves and preserves history across ...

I'm preserving ancestry so folks have fewer surprises whtn taking github for a spin ...

from filetree.

Of course when you do use git merge, you have to pick the correct ancestry for the file and when doing a git merge, there might not be a correct answer ...

from filetree.

fixed in SHA: 709545a

In the future we might make it optional to store ancestry (leverage pkg properties).

from filetree.