Re: A good Git technique for referring back to original files

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

 



Hi Mike,

I think git-cvsimport and git-subtree could help you here.

Roughly:

# Create a git version of each SDK_subproj
git cvsimport -r upstream -d $CVSREPO1 $CVSMODULE1 -C SDK_subproj1
git cvsimport -r upstream -d $CVSREPO2 $CVSMODULE2 -C SDK_subproj2

# Create your Working_SDK
git init Working_SDK
cd Working_SDK

# Import the SDK_subprojN repos
git subtree add --prefix=subproj1 ../SDK_subproj1 upstream/master
git subtree add --prefix=subproj2 ../SDK_subproj2 upstream/master

# Edit and commit your files
# N.B. when committing don't commit to more than one subproj in a single commit

# Update from the upstream CVS as needed
git cvsimport -r upstream -d $CVSREPO1 $CVSMODULE1 -C ../SDK_subproj1
git subtree pull --prefix=subproj1 ../SDK_subproj1 upstream/master
git cvsimport -r upstream -d $CVSREPO2 $CVSMODULE2 -C ../SDK_subproj2
git subtree pull --prefix=subproj2 ../SDK_subproj2 upstream/master

# Push your changes back to SDK_subproj repos into a branch other than master
git subtree push --prefix=subproj1 ../SDK_subproj1 new-branch
git subtree push --prefix=subproj1 ../SDK_subproj2 new-branch

# Prepare patches to apply to a real CVS copy or submit upstream
(cd ../SDK_subproj1 && git format-patch upstream/master..new-branch)
(cd ../SDK_subproj2 && git format-patch upstream/master..new-branch)

Hope that helps.

--
Paul

On Tue, Feb 12, 2013 at 10:19 AM, MikeW <mw_phil@xxxxxxxxxxx> wrote:
> Matthieu Moy <Matthieu.Moy <at> grenoble-inp.fr> writes:
>
>>
>> MikeW <mw_phil <at> yahoo.co.uk> writes:
>>
>> > Since git is so good at tracking file content, I wondered whether
> there was any
>> > technique using git that would simplify the back-referencing task.
>>
>> I'm not sure I understand the question, but if you want to add meta-data
>> to Git commits (e.g. "this Git commit is revision 42 in CVS repository
>> foo"), then have a look at git-notes. It won't give you directly
>> "reference to other VCS", but at least can be used as a storage
>> mechanism to store these references.
>>
> Thanks for the reply.
>
> In my work environment both the SDK and the original files are available
> (in an enclosing directory).
>
> --SDK_content
>   |
>   SDK_subproj1-- ...
>   |            |
>   |            content
>   |
>   SDK_subproj2- ...
>   |            |
>   |            content
>   |
>   SDK_subprojN- ...
>   |            |
>   |            content
>   |
>   Working_SDK ... (under git, baseline generated from subproj1..N)
>                |
>                content derived from subproj1..N
>
>
> What I had in mind was something I could run over, say, SDK_content
> (alternatively, from within Working_SDK, referring back to SDK_content)
> which would note the changed files in Working_SDK and locate the
> original files in SDK_subproj1..N letting me merge the changes back.
>
>
> --
> 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



--
Paul [W] Campbell
--
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]