{"thread":{"id":"31782","subject":"A basic question","startedAt":"2012-10-10T18:03:23Z","lastAt":"2012-10-12T15:56:30Z","messageCount":9,"participants":["Jim Vahl","Drew Northup","James Nylen","Dov Grobgeld","Enrico Weigelt","Sitaram Chamarty","PJ Weisberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"200933","messageId":"001501cda711$8ab6f0a0$a024d1e0$@com","threadId":"31782","inReplyTo":null,"subject":"A basic question","fromName":"Jim Vahl","fromEmail":"jv@wmdb.com","sentAt":"2012-10-10T18:03:23Z","receivedAt":"2012-10-10T18:03:23Z","isPatch":false,"sender":{"key":"jv@wmdb.com","avatar":null},"body":"All,\n\nOur company is researching version control software, something which we have\nnot used previously.  I have a very basic question about git which I have\nnot been able to answer from reading.  As I understand it, a git repository\ncan be a mixture of files which are under development, staged or committed.\nIf we make a new build of our product we will obviously only want to include\nthe committed (tested) files.  \n\nThe question is this: what is the usual procedure to retrieve a set of\ncommitted  files only from the repository to place into a distribution or\n\"ready to build\" folder.  The same question goes for tagging a release: how\ndoes the user get the tag to reference the committed files only and not the\nmost recent files which may be under development or undergoing testing.\n\nThanks,\n\nJim Vahl\n"},{"id":"200942","messageId":"1349897794.32696.15.camel@drew-northup.unet.maine.edu","threadId":"31782","inReplyTo":"001501cda711$8ab6f0a0$a024d1e0$@com","subject":"Re: A basic question","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2012-10-10T19:36:34Z","receivedAt":"2012-10-10T19:36:34Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"On Wed, 2012-10-10 at 11:03 -0700, Jim Vahl wrote:\n> All,\n> \n> Our company is researching version control software, something which we have\n> not used previously.  I have a very basic question about git which I have\n> not been able to answer from reading.  As I understand it, a git repository\n> can be a mixture of files which are under development, staged or committed.\n> If we make a new build of our product we will obviously only want to include\n> the committed (tested) files.  \n> \n> The question is this: what is the usual procedure to retrieve a set of\n> committed  files only from the repository to place into a distribution or\n> \"ready to build\" folder.  The same question goes for tagging a release: how\n> does the user get the tag to reference the committed files only and not the\n> most recent files which may be under development or undergoing testing.\n> \n> Thanks,\n> \n> Jim Vahl\n\nJim,\nHave you looked at http://git-scm.com/book yet? It sounds to me like you\nhave some misconceptions about how Git works. (If so, did it leave you\nmore or less confused?)\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"201009","messageId":"002801cda7d7$4792c260$d6b84720$@com","threadId":"31782","inReplyTo":"1349897794.32696.15.camel@drew-northup.unet.maine.edu","subject":"RE: A basic question","fromName":"Jim Vahl","fromEmail":"jv@wmdb.com","sentAt":"2012-10-11T17:38:49Z","receivedAt":"2012-10-11T17:38:49Z","isPatch":false,"sender":{"key":"jv@wmdb.com","avatar":null},"body":"Drew, \n\nThanks for responding to my email!\n\nYes, I did read most of the Book, although I admit that I skimmed over some\nof the more technical parts.  There is still a key part of how git is used\nin a commercial environment which I don't understand.\n\nWhen we release a new version of our product, it is comprised of over a\nhundred files.  Some of these files have not changed for years, and some\nhave been revised/fixed/updated quite recently.  But what is key is that all\nof these components have passed a review and testing process.  A very\nimportant piece of information is what revision of each file made it into\nthe release.\n\nI know that git takes snapshots of the repository as changes are made and\nthat it is possible to reconstruct the file set at any point in time.  But\nunless rules or conventions are established, at any time the repository can\ncontain files which are in the process of being modified and thus have not\npassed the testing process.  For the purpose of planning a release, we're\ninterested only in the \"most recently tested and approved\" files.\n\nFor the sake of argument, I'll assume that a committing a change implies\nthat the file has passed the testing process.  So my questions are:\n\n1) Does git have a built-in way to get a list of all of the \"most recently\ncommitted\" files only at a given point in time, thus automatically recording\nthe revisions of all of the component files of a release?   This implies\nthat for files which are being modified or which have been staged but not\ncommitted, that git would go back to find the \"predecessor\" file which had\nbeen committed.\n\n 2) Does git have a way of creating and exporting a list of the \"most\nrecently committed\" files only?\n\n3) If the answer to the above questions is \"No\", then what is the normal way\nfor a programming shop which is using git to extract/assemble the list of\napproved files for building a release? \n\nThank you.\n\nJim Vahl\n\n-----Original Message-----\nFrom: Drew Northup [mailto:drew.northup@maine.edu] \nSent: Wednesday, October 10, 2012 12:37 PM\nTo: Jim Vahl\nCc: git@vger.kernel.org; 'Skot Davis'\nSubject: Re: A basic question\n\nOn Wed, 2012-10-10 at 11:03 -0700, Jim Vahl wrote:\n> All,\n> \n> Our company is researching version control software, something which \n> we have not used previously.  I have a very basic question about git \n> which I have not been able to answer from reading.  As I understand \n> it, a git repository can be a mixture of files which are under\ndevelopment, staged or committed.\n> If we make a new build of our product we will obviously only want to \n> include the committed (tested) files.\n> \n> The question is this: what is the usual procedure to retrieve a set of \n> committed  files only from the repository to place into a distribution \n> or \"ready to build\" folder.  The same question goes for tagging a \n> release: how does the user get the tag to reference the committed \n> files only and not the most recent files which may be under development or\nundergoing testing.\n> \n> Thanks,\n> \n> Jim Vahl\n\nJim,\nHave you looked at http://git-scm.com/book yet? It sounds to me like you\nhave some misconceptions about how Git works. (If so, did it leave you more\nor less confused?)\n\n--\n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"201013","messageId":"507712AC.7090801@gmail.com","threadId":"31782","inReplyTo":"002801cda7d7$4792c260$d6b84720$@com","subject":"Re: A basic question","fromName":"James Nylen","fromEmail":"jnylen@gmail.com","sentAt":"2012-10-11T18:40:44Z","receivedAt":"2012-10-11T18:40:44Z","isPatch":false,"sender":{"key":"jnylen@gmail.com","avatar":"https://gravatar.com/avatar/96804ac655933f5b6380e992610d6ff9029c6d04db1042d4bec381312ff7ff1b?d=mp&s=160"},"body":"\nOn 10/11/2012 1:38 PM, Jim Vahl wrote:\n> For the sake of argument, I'll assume that a committing a change implies\n> that the file has passed the testing process.  So my questions are:\nYou should not assume this.  You / your developers should commit far \nmore frequently than you test and release versions.  For example, I \nusually try to commit after a day's work at most.\n\nInstead, you should mark a tested version using tags (the git tag \ncommand). Here is a workflow that seems like it would work well for you:\n\n1. Commit 1\n2. Commit 2\n3. Commit 3 - TAGGED as release-v0.1\n4. Commit 4\n5. Commit 5 - TAGGED as release-v0.2\n6. Commit 6\n7. Commit 7\n\nIn this scenario, you reviewed the code after Commit 3 was entered and \nit passed your tests.  You then tagged this version of the code as \nversion 0.1.  Tagging is just a convenient way to associate a name (for \nexample, \"release-v0.1\") with the code tree as of a certain commit.  \nSimilarly with Commit 5 and version 0.2.\n\nCommits 6 and 7 represent changes made to the code for features that are \nin progress, bug fixes, etc.  They have not been reviewed yet.  For the \npurpose of releasing versions, you don't care about these commits.\n\nFor the purpose of releasing versions, you also don't care about the \nstate of files in the git repository (whether they are modified, or some \nor all changes are staged).  These features exist to help you prepare \ncommits and understand what changes you are committing, not as a way of \nmanaging versions of the software.\n\nMany people use git in more complex ways that involve non-linear \ndevelopment histories (branches).  For example, you can have multiple \ndevelopers working on different features simultaneously, each committing \ntheir own changes, and you can use git to help you reconcile the changes \nlater.  You can also have a \"release\" branch which stores only the \nreleased versions, and separate \"development\" branches where code \nchanges occur.  These workflows are harder to wrap your head around, though.\n\n> 1) Does git have a built-in way to get a list of all of the \"most recently\n> committed\" files only at a given point in time, thus automatically recording\n> the revisions of all of the component files of a release?   This implies\n> that for files which are being modified or which have been staged but not\n> committed, that git would go back to find the \"predecessor\" file which had\n> been committed.\nLet's replace \"committed\" with \"tagged as a released version\". Then \nyes.  The person who wants to release a version would do:\n\ngit checkout release-v0.1\n\nAt this point their working folder will contain all of the files for the \nv0.1 release.  You can run tests, run the build process and generate \nexecutables, or whatever other kind of deployment process needs to be done.\n\nAnother option is to create a zip file containing all the code as of \nversion 0.1:\n\ngit archive release-v0.1 -o release-v0.1.zip\n\n>   2) Does git have a way of creating and exporting a list of the \"most\n> recently committed\" files only?\nThere are many ways to list and manipulate the files stored in the \nrepository, as of any commit that you want.\n\n> 3) If the answer to the above questions is \"No\", then what is the normal way\n> for a programming shop which is using git to extract/assemble the list of\n> approved files for building a release?\n\nThe first step, which git will help you with, is to ensure that you are \nworking with the right version of the code and development files (the \nversion you tested, that you intend to release).  From there, extracting \nand deploying the files necessary for a release is up to you.\n"},{"id":"201014","messageId":"CA++fsGFsNgNeRbd76OFnNhD2=hi6edz720u=m8ZK-eorir5dow@mail.gmail.com","threadId":"31782","inReplyTo":"CA++fsGFruWFauX3XkynwcRLqK9H16frW86of3Y3ScgzGFmz=dg@mail.gmail.com","subject":"Re: A basic question","fromName":"Dov Grobgeld","fromEmail":"dov.grobgeld@gmail.com","sentAt":"2012-10-11T18:46:46Z","receivedAt":"2012-10-11T18:46:46Z","isPatch":false,"sender":{"key":"dov.grobgeld@gmail.com","avatar":"https://gravatar.com/avatar/b74b57a9ce04ef5f356927856e125f1e70e7ce38772c5b8793b854b830f0fe6c?d=mp&s=160"},"body":"The way you typically work with git (and with most other version\ncontrol systems) is that you have a fast changing trunk (in git often\ncalled the master), where development is done. Once you want to\nrelease you create a release branch off the trunk, and in that branch\nyou do regression testing and stability testing, and once you are\nconvinced that stability has been achieved, you make your release.\n\nIn parallel, and without in any way influencing your release branch,\nyour programmers happily commit to the trunk.\n\nSee e.g. the following excellent description of some workflow models:\n\nhttp://nvie.com/posts/a-successful-git-branching-model/\n\nRegards,\nDov\n\n On Thu, Oct 11, 2012 at 7:38 PM, Jim Vahl <jv@wmdb.com> wrote:\n>\n> Drew,\n>\n> Thanks for responding to my email!\n>\n> Yes, I did read most of the Book, although I admit that I skimmed over some\n> of the more technical parts.  There is still a key part of how git is used\n> in a commercial environment which I don't understand.\n>\n> When we release a new version of our product, it is comprised of over a\n> hundred files.  Some of these files have not changed for years, and some\n> have been revised/fixed/updated quite recently.  But what is key is that all\n> of these components have passed a review and testing process.  A very\n> important piece of information is what revision of each file made it into\n> the release.\n>\n> I know that git takes snapshots of the repository as changes are made and\n> that it is possible to reconstruct the file set at any point in time.  But\n> unless rules or conventions are established, at any time the repository can\n> contain files which are in the process of being modified and thus have not\n> passed the testing process.  For the purpose of planning a release, we're\n> interested only in the \"most recently tested and approved\" files.\n>\n> For the sake of argument, I'll assume that a committing a change implies\n> that the file has passed the testing process.  So my questions are:\n>\n> 1) Does git have a built-in way to get a list of all of the \"most recently\n> committed\" files only at a given point in time, thus automatically recording\n> the revisions of all of the component files of a release?   This implies\n> that for files which are being modified or which have been staged but not\n> committed, that git would go back to find the \"predecessor\" file which had\n> been committed.\n>\n>  2) Does git have a way of creating and exporting a list of the \"most\n> recently committed\" files only?\n>\n> 3) If the answer to the above questions is \"No\", then what is the normal way\n> for a programming shop which is using git to extract/assemble the list of\n> approved files for building a release?\n>\n> Thank you.\n>\n> Jim Vahl\n>\n> -----Original Message-----\n> From: Drew Northup [mailto:drew.northup@maine.edu]\n> Sent: Wednesday, October 10, 2012 12:37 PM\n> To: Jim Vahl\n> Cc: git@vger.kernel.org; 'Skot Davis'\n> Subject: Re: A basic question\n>\n> On Wed, 2012-10-10 at 11:03 -0700, Jim Vahl wrote:\n> > All,\n> >\n> > Our company is researching version control software, something which\n> > we have not used previously.  I have a very basic question about git\n> > which I have not been able to answer from reading.  As I understand\n> > it, a git repository can be a mixture of files which are under\n> development, staged or committed.\n> > If we make a new build of our product we will obviously only want to\n> > include the committed (tested) files.\n> >\n> > The question is this: what is the usual procedure to retrieve a set of\n> > committed  files only from the repository to place into a distribution\n> > or \"ready to build\" folder.  The same question goes for tagging a\n> > release: how does the user get the tag to reference the committed\n> > files only and not the most recent files which may be under development or\n> undergoing testing.\n> >\n> > Thanks,\n> >\n> > Jim Vahl\n>\n> Jim,\n> Have you looked at http://git-scm.com/book yet? It sounds to me like you\n> have some misconceptions about how Git works. (If so, did it leave you more\n> or less confused?)\n>\n> --\n> -Drew Northup\n> ________________________________________________\n> \"As opposed to vegetable or mineral error?\"\n> -John Pescatore, SANS NewsBites Vol. 12 Num. 59\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"},{"id":"201015","messageId":"d89615b8-d153-41c9-963d-127a614321cb@zcs","threadId":"31782","inReplyTo":"002801cda7d7$4792c260$d6b84720$@com","subject":"Re: A basic question","fromName":"Enrico Weigelt","fromEmail":"enrico.weigelt@vnc.biz","sentAt":"2012-10-11T18:51:45Z","receivedAt":"2012-10-11T18:51:45Z","isPatch":false,"sender":{"key":"enrico.weigelt@vnc.biz","avatar":"https://gravatar.com/avatar/15479654ea5be5109582e0713a8ab4bb258846099c516dd320dc686ef70a8a3e?d=mp&s=160"},"body":"\n> 1) Does git have a built-in way to get a list of all of the \"most\n> recently\n> committed\" files only at a given point in time, thus automatically\n> recording\n> the revisions of all of the component files of a release?  \n\nThere is no concept of per-file revisions in git.\nBut you can check which ones are changed in multiple ways, eg:\n\n* per commit, commit-range or per-branch level -> see git-log manpage\n* between arbitratry commints -> see git-diff manpage\n\n> This implies that for files which are being modified or which have\n> been staged but not committed, that git would go back to find the\n> \"predecessor\" file which had been committed.\n\nForget about the staging issue (index) at this point - it's just\nexisting in the _local_ clone (eg of some individual developer),\nfor your usecase you're only interested in what's actually committed\nto certain branch(es).\n\n\ncu\n-- \nMit freundlichen Grüßen / Kind regards \n\nEnrico Weigelt \nVNC - Virtual Network Consult GmbH \nHead Of Development \n\nPariser Platz 4a, D-10117 Berlin\nTel.: +49 (30) 3464615-20\nFax: +49 (30) 3464615-59\n\nenrico.weigelt@vnc.biz; www.vnc.de \n"},{"id":"201034","messageId":"CAMK1S_iMxju7Q7WSExw2nXqP0KqOEXFaYTMsmicYHMu6RAT-wA@mail.gmail.com","threadId":"31782","inReplyTo":"002801cda7d7$4792c260$d6b84720$@com","subject":"Re: A basic question","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-10-12T00:58:49Z","receivedAt":"2012-10-12T00:58:49Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Thu, Oct 11, 2012 at 11:08 PM, Jim Vahl <jv@wmdb.com> wrote:\n> Drew,\n>\n> Thanks for responding to my email!\n>\n> Yes, I did read most of the Book, although I admit that I skimmed over some\n> of the more technical parts.  There is still a key part of how git is used\n> in a commercial environment which I don't understand.\n>\n> When we release a new version of our product, it is comprised of over a\n> hundred files.  Some of these files have not changed for years, and some\n> have been revised/fixed/updated quite recently.  But what is key is that all\n> of these components have passed a review and testing process.  A very\n> important piece of information is what revision of each file made it into\n> the release.\n\nI'm afraid I don't have anything to add to what was already said but I\ncan't resist asking: are you coming from clearcase?\n"},{"id":"201036","messageId":"CAJsNXTm3k6YYFLhM9WZo2ZwKQjxWUHKbbbWvVYO_sKvCxsKD6w@mail.gmail.com","threadId":"31782","inReplyTo":"002801cda7d7$4792c260$d6b84720$@com","subject":"Re: A basic question","fromName":"PJ Weisberg","fromEmail":"pj@irregularexpressions.net","sentAt":"2012-10-12T01:08:58Z","receivedAt":"2012-10-12T01:08:58Z","isPatch":false,"sender":{"key":"pj@irregularexpressions.net","avatar":"https://gravatar.com/avatar/aa2c1edcc61b536cc5c9f37fbce084e655446e2309f9818d43f13d47304a602b?d=mp&s=160"},"body":"On Thu, Oct 11, 2012 at 10:38 AM, Jim Vahl <jv@wmdb.com> wrote:\n\n> 1) Does git have a built-in way to get a list of all of the \"most recently\n> committed\" files only at a given point in time, thus automatically recording\n> the revisions of all of the component files of a release?   This implies\n> that for files which are being modified or which have been staged but not\n> committed, that git would go back to find the \"predecessor\" file which had\n> been committed.\n\nI feel like I'm missing the point of your questions.  Why do you think\nyour central repository would contain anything that hadn't been\ncommitted?\n\n-PJ\n\nGehm's Corollary to Clark's Law: Any technology distinguishable from\nmagic is insufficiently advanced.\n"},{"id":"201060","messageId":"000001cda892$26da3a60$748eaf20$@com","threadId":"31782","inReplyTo":"CA++fsGFruWFauX3XkynwcRLqK9H16frW86of3Y3ScgzGFmz=dg@mail.gmail.com","subject":"RE: A basic question - Thanks to all responders","fromName":"Jim Vahl","fromEmail":"jv@wmdb.com","sentAt":"2012-10-12T15:56:30Z","receivedAt":"2012-10-12T15:56:30Z","isPatch":false,"sender":{"key":"jv@wmdb.com","avatar":null},"body":"Fellow developers,\n\nThanks to all who responded to my “basic question”.  I now have a much better idea (actually 2) of how releases can be documented when using git for version control.  I appreciate your taking the time to help me on the learning path.\n\nJim Vahl\n"}]}