Subject: Re: Rebase problems

From: Maaartin-1 <[email-masked]>
Date: Mon, 08 Nov 2010 20:59:52 +0100

On 10-11-08 19:33, Wincent Colaiuta wrote:
> On 08/11/2010, at 19:19, Maaartin wrote:
> 
>> I'm using git for a project I'm working on alone (and I really like it), so I 
>> could rebase a lot, if I hadn't the following problems.
>>
>> There's a file containing the timestamp which gets compiled in, so the 
>> executable can show it's version. Sometimes, I need to set it couple of times a 
>> day, sometimes only once a week. For each such timestamp I create a tag, so I 
>> can track it to the source easily. The timestamp is an important piece of 
>> information, so I put the containing file under version control. The downside is 
>> that I often get a conflict in this file halting my rebase. Is there a way how 
>> to ignore or automatically resolve all conflicts in this file (any resolution 
>> strategy is fine, as it will be overwritten anyway).
> 
> Rhetorical questions follow; no need for you to answer:

However, I will. I've asked myself some of them already.

Addendum: It looks like your question were the right ones, the problem
seems to be solved now in a very easy way.

> - Why is the timestamp an "important" piece of information?

I need the timestamp (or something else) in order to match the
problematic version to the source.

> - Have you considered that, for versioning purposes (ie. knowing _what_ source code was compiled to produce the product), the commit hash or the output of "git describe" may be much more useful than a disconnected timestamp?

Sure, I have considered it and I haven't ruled it out (I'm quite new to
git). The timestamp is something the customer can understand better and
has got used to during the past 5 yeas. It gets also stored in some
database columns, whose type I had to change. Using tags I can relate
the timestamp to the commit.

In any case I need to embed the information in the executable, which was
impossible for a hash in a committed file. However, I don't want to
commit it, anyway... so probably it's the way to go.

The output of git describe is quite unusable for this purpose, since the
customer would happily drop the hash which can lead to ambiguities.
Giving him only the SHA-1 would be safer.

> - Regardless of whether you use a timestamp, a commit hash, or the output of "git describe", why can't it be inserted at compile time rather than stored in the repo?

I could do it using an untracked file, which would eliminate my problem.
The downside is that then--assuming using the timestamp--I'd have to
rely on the tags or some logfile. No, there's no downside as I see after
having read your next line.

> - If you are really enamored of timestamps, would extracting the latest commit timestamp out of the repo be enough?

Sure it would, I was mostly ignoring the commit timestamp until now, and
didn't notice that I'm using a different timestamp for the executable
without any reason. Now I need just trivial changes.

> - Do these repeated merge conflicts set off "code smell" alarm bells for you (really, "process smell"), and make you suspect that there might be something wrong with what you are trying to do?

Partly, starting using the timestamp was a huge improvement many years
ago and I was quite happy with it until now. OTOH, git is new to me so I
was thinking about changing what I'm doing with git or finding some new
option there instead.

Now, I can have my timestamp and eat it, thank you.