Re: Rebase problems

From: Wincent Colaiuta <win@wincent.com>
Date: Nov 8, 2010, 18:33 UTC
Message-ID: <FA37BC66-64CF-4A62-80E9-EC45EAE392C4@wincent.com>
In-Reply-To: <loom.20101108T190513-206@post.gmane.org>

On 08/11/2010, at 19:19, Maaartin wrote:

Show 11 quoted lines

> 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:

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

- 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?

- 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?

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

- 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?

Cheers, Wincent