git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Jim Vahl" <jv@wmdb.com>
To: "'Drew Northup'" <drew.northup@maine.edu>
Cc: "'Skot Davis'" <skotd122@gmail.com>, <git@vger.kernel.org>
Subject: RE: A basic question
Date: Thu, 11 Oct 2012 10:38:49 -0700	[thread overview]
Message-ID: <002801cda7d7$4792c260$d6b84720$@com> (raw)
In-Reply-To: <1349897794.32696.15.camel@drew-northup.unet.maine.edu>

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

  reply	other threads:[~2012-10-11 17:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-10 18:03 A basic question Jim Vahl
2012-10-10 19:36 ` Drew Northup
2012-10-11 17:38   ` Jim Vahl [this message]
2012-10-11 18:40     ` James Nylen
2012-10-11 18:51     ` Enrico Weigelt
2012-10-12  0:58     ` Sitaram Chamarty
2012-10-12  1:08     ` PJ Weisberg
     [not found]     ` <CA++fsGFruWFauX3XkynwcRLqK9H16frW86of3Y3ScgzGFmz=dg@mail.gmail.com>
2012-10-11 18:46       ` Dov Grobgeld
2012-10-12 15:56       ` A basic question - Thanks to all responders Jim Vahl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='002801cda7d7$4792c260$d6b84720$@com' \
    --to=jv@wmdb.com \
    --cc=drew.northup@maine.edu \
    --cc=git@vger.kernel.org \
    --cc=skotd122@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).