Re: How to deal with historic tar-balls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "Philip Oakley" <philipoakley@xxxxxxx> Sent: Sunday, January 01, 2012 6:30 PM
From: "Tomas Carnecky" <tom@xxxxxxxxxxxxx> Sent: Sunday, January 01, 2012
12:27 AM
On 12/31/11 8:04 PM, nn6eumtr wrote:
I have a number of older projects that I want to bring into a git
repository. They predate a lot of the popular scm systems, so they are
primarily a collection of tarballs today.
I'm doing a similar thing with a set of zip files. I grouped mine into
batches for easier checking and putting on to separate branches. Planning
your branch requirements is probably the biggest task, and will depend on
how you hope to use the new repo.

<snip>
There is a script which will import sources from multiple tarballs,
creating a commit with the contents of each tarball. It's in the git
repository under contrib/fast-import/import-tars.perl.
I wasn't aware of those scripts. I'll be having a look at the zip import
script for my needs.

Is there a mechanism for either having fast-import respect a .gitignore,
or determining if a given file/path should be ignored?
My zips contain a lot of compile by-products that should be excluded from the repo.

My extra problem is that almost all my zips have an extra top level
directory that changes its name for every zip (but some don't..). The TLD
changes confuses the git rename detection if I don't remove them before
committing. Fortunately it's an internal development project with no formal
releases so creating the history is a bit of a personal project which
doesn't affect ongoing development (which is the crunch question for
fidelity of the repo you create).

tom
Philip

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]