Re: A good Git technique for referring back to original files
Paul Campbell pcampbell at kemitix.net writes: Hi Mike, I think git-cvsimport and git-subtree could help you here. That looks very interesting, had not considered git subtree and it looks like the right kind of method. Thanks. Mike Hope that helps. -- Paul ... Super-Snip ... -- Paul [W] Campbell -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A good Git technique for referring back to original files
MikeW mw_phil at yahoo.co.uk writes: Paul Campbell pcampbell at kemitix.net writes: Hi Mike, I think git-cvsimport and git-subtree could help you here. That looks very interesting, had not considered git subtree and it looks like the right kind of method. Thanks. Mike The only alternative I can think of is to scan through Working_SDK and replace the files there with symlinks back to the matching files within the original subprojects - such scripts exist ! Then any changes in Working_SDK will update the (baselined) originals in-place. But then no explicit use of git except for tracking work prior to pushing back to CVS. Oh well, thanks for ideas, will see which work best. Mike -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
A good Git technique for referring back to original files
Hi, I have a client with an SDK product. Normally the SDK is used in its unpackaged form by the end-user, and that is the directory structure and set of files in which development work on the SDK functionality is performed. However the SDK directory and content is generated from a packager which first runs on numerous other version controlled projects (currently CVS projects - this is unlikely to change). This means that once changes to the unpackaged SDK have been tested, they have to be cross-referred back to the original projects and the changes ported back. I have found it most convenient to control my in-SDK changes with git. However it's still a royal pain to cross-refer and diff the changes back to the originals, especially since duplicate file names exist across the original projects which get filtered down to one relevant instance by the packager. 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. Failing a method using git 'normally', perhaps building a script on top of the git file system might be a possibility - if that is feasible ... Thanks, MikeW -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A good Git technique for referring back to original files
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
