RE: A basic question - Thanks to all responders
Fellow developers, Thanks 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. Jim Vahl -- 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 basic question
On Thu, Oct 11, 2012 at 10:38 AM, Jim Vahl wrote: > 1) Does git have a built-in way to get a list of all of the "most recently > committed" files only at a given point in time, thus automatically recording > the revisions of all of the component files of a release? This implies > that for files which are being modified or which have been staged but not > committed, that git would go back to find the "predecessor" file which had > been committed. I feel like I'm missing the point of your questions. Why do you think your central repository would contain anything that hadn't been committed? -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- 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 basic question
On Thu, Oct 11, 2012 at 11:08 PM, Jim Vahl wrote: > Drew, > > Thanks for responding to my email! > > Yes, I did read most of the Book, although I admit that I skimmed over some > of the more technical parts. There is still a key part of how git is used > in a commercial environment which I don't understand. > > When we release a new version of our product, it is comprised of over a > hundred files. Some of these files have not changed for years, and some > have been revised/fixed/updated quite recently. But what is key is that all > of these components have passed a review and testing process. A very > important piece of information is what revision of each file made it into > the release. I'm afraid I don't have anything to add to what was already said but I can't resist asking: are you coming from clearcase? -- 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 basic question
> 1) Does git have a built-in way to get a list of all of the "most > recently > committed" files only at a given point in time, thus automatically > recording > the revisions of all of the component files of a release? There is no concept of per-file revisions in git. But you can check which ones are changed in multiple ways, eg: * per commit, commit-range or per-branch level -> see git-log manpage * between arbitratry commints -> see git-diff manpage > This implies that for files which are being modified or which have > been staged but not committed, that git would go back to find the > "predecessor" file which had been committed. Forget about the staging issue (index) at this point - it's just existing in the _local_ clone (eg of some individual developer), for your usecase you're only interested in what's actually committed to certain branch(es). cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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 basic question
The way you typically work with git (and with most other version control systems) is that you have a fast changing trunk (in git often called the master), where development is done. Once you want to release you create a release branch off the trunk, and in that branch you do regression testing and stability testing, and once you are convinced that stability has been achieved, you make your release. In parallel, and without in any way influencing your release branch, your programmers happily commit to the trunk. See e.g. the following excellent description of some workflow models: http://nvie.com/posts/a-successful-git-branching-model/ Regards, Dov On Thu, Oct 11, 2012 at 7:38 PM, Jim Vahl wrote: > > Drew, > > Thanks for responding to my email! > > Yes, I did read most of the Book, although I admit that I skimmed over some > of the more technical parts. There is still a key part of how git is used > in a commercial environment which I don't understand. > > When we release a new version of our product, it is comprised of over a > hundred files. Some of these files have not changed for years, and some > have been revised/fixed/updated quite recently. But what is key is that all > of these components have passed a review and testing process. A very > important piece of information is what revision of each file made it into > the release. > > I know that git takes snapshots of the repository as changes are made and > that it is possible to reconstruct the file set at any point in time. But > unless rules or conventions are established, at any time the repository can > contain files which are in the process of being modified and thus have not > passed the testing process. For the purpose of planning a release, we're > interested only in the "most recently tested and approved" files. > > For the sake of argument, I'll assume that a committing a change implies > that the file has passed the testing process. So my questions are: > > 1) Does git have a built-in way to get a list of all of the "most recently > committed" files only at a given point in time, thus automatically recording > the revisions of all of the component files of a release? This implies > that for files which are being modified or which have been staged but not > committed, that git would go back to find the "predecessor" file which had > been committed. > > 2) Does git have a way of creating and exporting a list of the "most > recently committed" files only? > > 3) If the answer to the above questions is "No", then what is the normal way > for a programming shop which is using git to extract/assemble the list of > approved files for building a release? > > Thank you. > > Jim Vahl > > -----Original Message- > From: Drew Northup [mailto:drew.nort...@maine.edu] > Sent: Wednesday, October 10, 2012 12:37 PM > To: Jim Vahl > Cc: git@vger.kernel.org; 'Skot Davis' > Subject: Re: A basic question > > On Wed, 2012-10-10 at 11:03 -0700, Jim Vahl wrote: > > All, > > > > Our company is researching version control software, something which > > we have not used previously. I have a very basic question about git > > which I have not been able to answer from reading. As I understand > > it, a git repository can be a mixture of files which are under > development, staged or committed. > > If we make a new build of our product we will obviously only want to > > include the committed (tested) files. > > > > The question is this: what is the usual procedure to retrieve a set of > > committed files only from the repository to place into a distribution > > or "ready to build" folder. The same question goes for tagging a > > release: how does the user get the tag to reference the committed > > files only and not the most recent files which may be under development or > undergoing testing. > > > > Thanks, > > > > Jim Vahl > > Jim, > Have you looked at http://git-scm.com/book yet? It sounds to me like you > have some misconceptions about how Git works. (If so, did it leave you more > or less confused?) > > -- > -Drew Northup > > "As opposed to vegetable or mineral error?" > -John Pescatore, SANS NewsBites Vol. 12 Num. 59 > > > -- > 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 -- 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 basic question
On 10/11/2012 1:38 PM, Jim Vahl wrote: For the sake of argument, I'll assume that a committing a change implies that the file has passed the testing process. So my questions are: You should not assume this. You / your developers should commit far more frequently than you test and release versions. For example, I usually try to commit after a day's work at most. Instead, you should mark a tested version using tags (the git tag command). Here is a workflow that seems like it would work well for you: 1. Commit 1 2. Commit 2 3. Commit 3 - TAGGED as release-v0.1 4. Commit 4 5. Commit 5 - TAGGED as release-v0.2 6. Commit 6 7. Commit 7 In this scenario, you reviewed the code after Commit 3 was entered and it passed your tests. You then tagged this version of the code as version 0.1. Tagging is just a convenient way to associate a name (for example, "release-v0.1") with the code tree as of a certain commit. Similarly with Commit 5 and version 0.2. Commits 6 and 7 represent changes made to the code for features that are in progress, bug fixes, etc. They have not been reviewed yet. For the purpose of releasing versions, you don't care about these commits. For the purpose of releasing versions, you also don't care about the state of files in the git repository (whether they are modified, or some or all changes are staged). These features exist to help you prepare commits and understand what changes you are committing, not as a way of managing versions of the software. Many people use git in more complex ways that involve non-linear development histories (branches). For example, you can have multiple developers working on different features simultaneously, each committing their own changes, and you can use git to help you reconcile the changes later. You can also have a "release" branch which stores only the released versions, and separate "development" branches where code changes occur. These workflows are harder to wrap your head around, though. 1) Does git have a built-in way to get a list of all of the "most recently committed" files only at a given point in time, thus automatically recording the revisions of all of the component files of a release? This implies that for files which are being modified or which have been staged but not committed, that git would go back to find the "predecessor" file which had been committed. Let's replace "committed" with "tagged as a released version". Then yes. The person who wants to release a version would do: git checkout release-v0.1 At this point their working folder will contain all of the files for the v0.1 release. You can run tests, run the build process and generate executables, or whatever other kind of deployment process needs to be done. Another option is to create a zip file containing all the code as of version 0.1: git archive release-v0.1 -o release-v0.1.zip 2) Does git have a way of creating and exporting a list of the "most recently committed" files only? There are many ways to list and manipulate the files stored in the repository, as of any commit that you want. 3) If the answer to the above questions is "No", then what is the normal way for a programming shop which is using git to extract/assemble the list of approved files for building a release? The first step, which git will help you with, is to ensure that you are working with the right version of the code and development files (the version you tested, that you intend to release). From there, extracting and deploying the files necessary for a release is up to you. -- 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 basic question
Drew, Thanks for responding to my email! Yes, I did read most of the Book, although I admit that I skimmed over some of the more technical parts. There is still a key part of how git is used in a commercial environment which I don't understand. When we release a new version of our product, it is comprised of over a hundred files. Some of these files have not changed for years, and some have been revised/fixed/updated quite recently. But what is key is that all of these components have passed a review and testing process. A very important piece of information is what revision of each file made it into the release. I know that git takes snapshots of the repository as changes are made and that it is possible to reconstruct the file set at any point in time. But unless rules or conventions are established, at any time the repository can contain files which are in the process of being modified and thus have not passed the testing process. For the purpose of planning a release, we're interested only in the "most recently tested and approved" files. For the sake of argument, I'll assume that a committing a change implies that the file has passed the testing process. So my questions are: 1) Does git have a built-in way to get a list of all of the "most recently committed" files only at a given point in time, thus automatically recording the revisions of all of the component files of a release? This implies that for files which are being modified or which have been staged but not committed, that git would go back to find the "predecessor" file which had been committed. 2) Does git have a way of creating and exporting a list of the "most recently committed" files only? 3) If the answer to the above questions is "No", then what is the normal way for a programming shop which is using git to extract/assemble the list of approved files for building a release? Thank you. Jim Vahl -Original Message- From: Drew Northup [mailto:drew.nort...@maine.edu] Sent: Wednesday, October 10, 2012 12:37 PM To: Jim Vahl Cc: git@vger.kernel.org; 'Skot Davis' Subject: Re: A basic question On Wed, 2012-10-10 at 11:03 -0700, Jim Vahl wrote: > All, > > Our company is researching version control software, something which > we have not used previously. I have a very basic question about git > which I have not been able to answer from reading. As I understand > it, a git repository can be a mixture of files which are under development, staged or committed. > If we make a new build of our product we will obviously only want to > include the committed (tested) files. > > The question is this: what is the usual procedure to retrieve a set of > committed files only from the repository to place into a distribution > or "ready to build" folder. The same question goes for tagging a > release: how does the user get the tag to reference the committed > files only and not the most recent files which may be under development or undergoing testing. > > Thanks, > > Jim Vahl Jim, Have you looked at http://git-scm.com/book yet? It sounds to me like you have some misconceptions about how Git works. (If so, did it leave you more or less confused?) -- -Drew Northup "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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 basic question
On Wed, 2012-10-10 at 11:03 -0700, Jim Vahl wrote: > All, > > Our company is researching version control software, something which we have > not used previously. I have a very basic question about git which I have > not been able to answer from reading. As I understand it, a git repository > can be a mixture of files which are under development, staged or committed. > If we make a new build of our product we will obviously only want to include > the committed (tested) files. > > The question is this: what is the usual procedure to retrieve a set of > committed files only from the repository to place into a distribution or > "ready to build" folder. The same question goes for tagging a release: how > does the user get the tag to reference the committed files only and not the > most recent files which may be under development or undergoing testing. > > Thanks, > > Jim Vahl Jim, Have you looked at http://git-scm.com/book yet? It sounds to me like you have some misconceptions about how Git works. (If so, did it leave you more or less confused?) -- -Drew Northup "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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 basic question
All, Our company is researching version control software, something which we have not used previously. I have a very basic question about git which I have not been able to answer from reading. As I understand it, a git repository can be a mixture of files which are under development, staged or committed. If we make a new build of our product we will obviously only want to include the committed (tested) files. The question is this: what is the usual procedure to retrieve a set of committed files only from the repository to place into a distribution or "ready to build" folder. The same question goes for tagging a release: how does the user get the tag to reference the committed files only and not the most recent files which may be under development or undergoing testing. Thanks, Jim Vahl -- 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