A basic question

A basic question

[Jim Vahl]

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

Re: A basic question

[Drew Northup]

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

RE: A basic question

[Jim Vahl]

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.northup@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

Re: A basic question

[James Nylen]

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.

Re: A basic question

[Dov Grobgeld]

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 <jv@wmdb.com> 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.northup@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: A basic question - Thanks to all responders

[Jim Vahl]

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

Re: A basic question

[Enrico Weigelt]

> 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.weigelt@vnc.biz; www.vnc.de 

Re: A basic question

[Sitaram Chamarty]

On Thu, Oct 11, 2012 at 11:08 PM, Jim Vahl <jv@wmdb.com> 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?

Re: A basic question

[PJ Weisberg]

On Thu, Oct 11, 2012 at 10:38 AM, Jim Vahl <jv@wmdb.com> 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.