Re: Rebase problems
On 10-11-08 19:33, Wincent Colaiuta wrote:
Show 15 quoted lines
> 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.
