On Fri, May 16, 2014 at 8:22 AM, Andy Hardy <a...@hardyfamily.org.uk> wrote:
> On 15/05/2014 23:39, Magnus Therning wrote:
>> On Thu, May 15, 2014 at 11:21:25PM +0100, Andy Hardy wrote:
>>> On 15/05/2014 22:48, Magnus Therning wrote:
>>>> - version: doesn't make sense in git, would it be the hash?
>>>> what does that tell me?
>>> I find an identifier useful when investigating problems and
>>> wanting to confirm what files are involved.
>> What kind of identifier?
> Something that I can then use to identify the same file in the
> repository and check it's log history, etc.
>> What kind of problems and where?
>> Is the file in a clone or in a deployment, i.e. you can't rely on a
>> VCS to tell you what you have?
> It's in the deployment, generally of on-site fixes. Deployment
> involves a largeish number of files. Files are not intrinsically
> dependent upon one another but may interact.
> For a 'release' we'd send the customer a complete set of files, but
> often a fix only requires one or two files to be modified which we ask
> the customer to install. When a dealing with a later fault, we'd like to
> have a method of knowing which files the customer did actually install!
So, this is just the same situation as Thomas was talking about. It
boils down to, only slightly simplified, relying on VCS keyword
substitution in order to avoid having to create proper releases which
can be recorded upon install. It arguably shouldn't be done in the
first place, but I can see that some situations call for it. It can
however be done just about as easily in other ways, hash, diff, ...
Magnus Therning OpenPGP: 0xAB4DFBA4
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.