{"thread":{"id":"32885","subject":"A good Git technique for referring back to original files","startedAt":"2013-02-12T08:11:27Z","lastAt":"2013-02-13T12:50:42Z","messageCount":6,"participants":["MikeW","Matthieu Moy","Paul Campbell"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"209335","messageId":"loom.20130212T085620-989@post.gmane.org","threadId":"32885","inReplyTo":null,"subject":"A good Git technique for referring back to original files","fromName":"MikeW","fromEmail":"mw_phil@yahoo.co.uk","sentAt":"2013-02-12T08:11:27Z","receivedAt":"2013-02-12T08:11:27Z","isPatch":false,"sender":{"key":"mw_phil@yahoo.co.uk","avatar":null},"body":"Hi,\n\nI have a client with an SDK product. Normally the SDK is used in its unpackaged\nform by the end-user, and that is the directory structure and set of files in\nwhich development work on the SDK functionality is performed.\n\nHowever the SDK directory and content is generated from a packager which first\nruns on numerous other version controlled projects (currently CVS projects -\nthis is unlikely to change).\n\nThis means that once changes to the unpackaged SDK have been tested, they have\nto be cross-referred back to the original projects and the changes ported back.\n\nI have found it most convenient to control my in-SDK changes with git.\n\nHowever it's still a royal pain to cross-refer and diff the changes back to the\noriginals, especially since duplicate file names exist across the original\nprojects which get filtered down to one relevant instance by the packager.\n\nSince git is so good at tracking file content, I wondered whether there was any\ntechnique using git that would simplify the back-referencing task.\n\nFailing a method using git 'normally', perhaps building a script on top of the\ngit file system might be a possibility - if that is feasible ...\n\nThanks,\nMikeW\n"},{"id":"209336","messageId":"vpq1ucl9agt.fsf@grenoble-inp.fr","threadId":"32885","inReplyTo":"loom.20130212T085620-989@post.gmane.org","subject":"Re: A good Git technique for referring back to original files","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-02-12T08:56:34Z","receivedAt":"2013-02-12T08:56:34Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"MikeW <mw_phil@yahoo.co.uk> writes:\n\n> Since git is so good at tracking file content, I wondered whether there was any\n> technique using git that would simplify the back-referencing task.\n\nI'm not sure I understand the question, but if you want to add meta-data\nto Git commits (e.g. \"this Git commit is revision 42 in CVS repository\nfoo\"), then have a look at git-notes. It won't give you directly\n\"reference to other VCS\", but at least can be used as a storage\nmechanism to store these references.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"209358","messageId":"loom.20130212T110458-119@post.gmane.org","threadId":"32885","inReplyTo":"vpq1ucl9agt.fsf@grenoble-inp.fr","subject":"Re: A good Git technique for referring back to original files","fromName":"MikeW","fromEmail":"mw_phil@yahoo.co.uk","sentAt":"2013-02-12T10:19:54Z","receivedAt":"2013-02-12T10:19:54Z","isPatch":false,"sender":{"key":"mw_phil@yahoo.co.uk","avatar":null},"body":"Matthieu Moy <Matthieu.Moy <at> grenoble-inp.fr> writes:\n\n> \n> MikeW <mw_phil <at> yahoo.co.uk> writes:\n> \n> > Since git is so good at tracking file content, I wondered whether\nthere was any\n> > technique using git that would simplify the back-referencing task.\n> \n> I'm not sure I understand the question, but if you want to add meta-data\n> to Git commits (e.g. \"this Git commit is revision 42 in CVS repository\n> foo\"), then have a look at git-notes. It won't give you directly\n> \"reference to other VCS\", but at least can be used as a storage\n> mechanism to store these references.\n> \nThanks for the reply.\n\nIn my work environment both the SDK and the original files are available\n(in an enclosing directory).\n\n--SDK_content\n  |\n  SDK_subproj1-- ...\n  |            |\n  |            content\n  |\n  SDK_subproj2- ...\n  |            |\n  |            content\n  |\n  SDK_subprojN- ...\n  |            |\n  |            content\n  |\n  Working_SDK ... (under git, baseline generated from subproj1..N)\n               |\n               content derived from subproj1..N\n\n\nWhat I had in mind was something I could run over, say, SDK_content\n(alternatively, from within Working_SDK, referring back to SDK_content)\nwhich would note the changed files in Working_SDK and locate the\noriginal files in SDK_subproj1..N letting me merge the changes back.\n"},{"id":"209433","messageId":"CALeLG_nFgApPT1B+6sPy7P+jrtjB4KQOBpPO9bEd0rsWKqWi8A@mail.gmail.com","threadId":"32885","inReplyTo":"loom.20130212T110458-119@post.gmane.org","subject":"Re: A good Git technique for referring back to original files","fromName":"Paul Campbell","fromEmail":"pcampbell@kemitix.net","sentAt":"2013-02-12T23:13:07Z","receivedAt":"2013-02-12T23:13:07Z","isPatch":false,"sender":{"key":"pcampbell@kemitix.net","avatar":"https://gravatar.com/avatar/57584e05501b694929004e43fcd7308f4ad64df2eb0474cd8c7e5f93662bb0f1?d=mp&s=160"},"body":"Hi Mike,\n\nI think git-cvsimport and git-subtree could help you here.\n\nRoughly:\n\n# Create a git version of each SDK_subproj\ngit cvsimport -r upstream -d $CVSREPO1 $CVSMODULE1 -C SDK_subproj1\ngit cvsimport -r upstream -d $CVSREPO2 $CVSMODULE2 -C SDK_subproj2\n\n# Create your Working_SDK\ngit init Working_SDK\ncd Working_SDK\n\n# Import the SDK_subprojN repos\ngit subtree add --prefix=subproj1 ../SDK_subproj1 upstream/master\ngit subtree add --prefix=subproj2 ../SDK_subproj2 upstream/master\n\n# Edit and commit your files\n# N.B. when committing don't commit to more than one subproj in a single commit\n\n# Update from the upstream CVS as needed\ngit cvsimport -r upstream -d $CVSREPO1 $CVSMODULE1 -C ../SDK_subproj1\ngit subtree pull --prefix=subproj1 ../SDK_subproj1 upstream/master\ngit cvsimport -r upstream -d $CVSREPO2 $CVSMODULE2 -C ../SDK_subproj2\ngit subtree pull --prefix=subproj2 ../SDK_subproj2 upstream/master\n\n# Push your changes back to SDK_subproj repos into a branch other than master\ngit subtree push --prefix=subproj1 ../SDK_subproj1 new-branch\ngit subtree push --prefix=subproj1 ../SDK_subproj2 new-branch\n\n# Prepare patches to apply to a real CVS copy or submit upstream\n(cd ../SDK_subproj1 && git format-patch upstream/master..new-branch)\n(cd ../SDK_subproj2 && git format-patch upstream/master..new-branch)\n\nHope that helps.\n\n--\nPaul\n\nOn Tue, Feb 12, 2013 at 10:19 AM, MikeW <mw_phil@yahoo.co.uk> wrote:\n> Matthieu Moy <Matthieu.Moy <at> grenoble-inp.fr> writes:\n>\n>>\n>> MikeW <mw_phil <at> yahoo.co.uk> writes:\n>>\n>> > Since git is so good at tracking file content, I wondered whether\n> there was any\n>> > technique using git that would simplify the back-referencing task.\n>>\n>> I'm not sure I understand the question, but if you want to add meta-data\n>> to Git commits (e.g. \"this Git commit is revision 42 in CVS repository\n>> foo\"), then have a look at git-notes. It won't give you directly\n>> \"reference to other VCS\", but at least can be used as a storage\n>> mechanism to store these references.\n>>\n> Thanks for the reply.\n>\n> In my work environment both the SDK and the original files are available\n> (in an enclosing directory).\n>\n> --SDK_content\n>   |\n>   SDK_subproj1-- ...\n>   |            |\n>   |            content\n>   |\n>   SDK_subproj2- ...\n>   |            |\n>   |            content\n>   |\n>   SDK_subprojN- ...\n>   |            |\n>   |            content\n>   |\n>   Working_SDK ... (under git, baseline generated from subproj1..N)\n>                |\n>                content derived from subproj1..N\n>\n>\n> What I had in mind was something I could run over, say, SDK_content\n> (alternatively, from within Working_SDK, referring back to SDK_content)\n> which would note the changed files in Working_SDK and locate the\n> original files in SDK_subproj1..N letting me merge the changes back.\n>\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n\n\n\n--\nPaul [W] Campbell\n"},{"id":"209462","messageId":"loom.20130213T123734-484@post.gmane.org","threadId":"32885","inReplyTo":"CALeLG_nFgApPT1B+6sPy7P+jrtjB4KQOBpPO9bEd0rsWKqWi8A@mail.gmail.com","subject":"Re: A good Git technique for referring back to original files","fromName":"MikeW","fromEmail":"mw_phil@yahoo.co.uk","sentAt":"2013-02-13T11:44:45Z","receivedAt":"2013-02-13T11:44:45Z","isPatch":false,"sender":{"key":"mw_phil@yahoo.co.uk","avatar":null},"body":"Paul Campbell <pcampbell <at> kemitix.net> writes:\n\n> \n> Hi Mike,\n> \n> I think git-cvsimport and git-subtree could help you here.\n> \n\nThat looks very interesting, had not considered git subtree and it looks like\nthe right kind of method.\n\nThanks.\nMike\n\n> Hope that helps.\n> \n> --\n> Paul\n> \n... Super-Snip ...\n> \n> --\n> Paul [W] Campbell\n> \n"},{"id":"209466","messageId":"loom.20130213T134501-179@post.gmane.org","threadId":"32885","inReplyTo":"loom.20130213T123734-484@post.gmane.org","subject":"Re: A good Git technique for referring back to original files","fromName":"MikeW","fromEmail":"mw_phil@yahoo.co.uk","sentAt":"2013-02-13T12:50:42Z","receivedAt":"2013-02-13T12:50:42Z","isPatch":false,"sender":{"key":"mw_phil@yahoo.co.uk","avatar":null},"body":"MikeW <mw_phil <at> yahoo.co.uk> writes:\n\n> \n> Paul Campbell <pcampbell <at> kemitix.net> writes:\n> \n> > \n> > Hi Mike,\n> > \n> > I think git-cvsimport and git-subtree could help you here.\n> > \n> \n> That looks very interesting, had not considered git subtree and it looks like\n> the right kind of method.\n> \n> Thanks.\n> Mike\n\nThe only alternative I can think of is to scan through Working_SDK and replace\nthe files there with symlinks back to the matching files within the\noriginal subprojects - such scripts exist !\n\nThen any changes in Working_SDK will update the (baselined) originals in-place.\n\nBut then no explicit use of git except for tracking work prior to pushing\nback to CVS.\n\nOh well, thanks for ideas, will see which work best.\n\nMike\n"}]}