# Rebase problems 5 messages from 2010-11-08 to 2010-11-12. Participants: Maaartin, Wincent Colaiuta, Andreas Schwab, Maaartin-1. Thread: https://gitlist.dev/t/25678 ## Maaartin, 2010-11-08 18:19 Subject: Rebase problems Message-ID: URL: https://gitlist.dev/e/loom.20101108T190513-206%40post.gmane.org ``` 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). The second problem is problem of cygwin. While most of the operations git run in fractions of seconds, the most trivial rebase may take one minute or alike. Any idea what different things rebase do? ``` ## Wincent Colaiuta, 2010-11-08 18:33 Subject: Re: Rebase problems Message-ID: URL: https://gitlist.dev/e/FA37BC66-64CF-4A62-80E9-EC45EAE392C4%40wincent.com In-Reply-To: ``` 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: - 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 ``` ## Andreas Schwab, 2010-11-08 19:30 Subject: Re: Rebase problems Message-ID: URL: https://gitlist.dev/e/m2vd47iper.fsf%40igel.home In-Reply-To: ``` Maaartin writes: > 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). If you already have a tag for every timestamp, why not autogenerate the timestamp from the tag? Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ``` ## Maaartin-1, 2010-11-08 19:59 Subject: Re: Rebase problems Message-ID: <4CD856B8.7030305@seznam.cz> URL: https://gitlist.dev/e/4CD856B8.7030305%40seznam.cz In-Reply-To: ``` 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. ``` ## Maaartin, 2010-11-12 00:07 Subject: Re: Rebase problems Message-ID: URL: https://gitlist.dev/e/loom.20101112T005610-259%40post.gmane.org In-Reply-To: <4CD856B8.7030305@seznam.cz> ``` Maaartin-1 seznam.cz> writes: > On 10-11-08 19:33, Wincent Colaiuta wrote: > > - 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. Time to comment on myself: It works nice, but there's a small problem. I can't take the author date since it gets preserved across rebases, so I could get non-unique dates. The committer date corresponds with the time I actually create the executable, and I really not going to produce more than one executable per second, so it works nicely. Except for rebase, which can create a lot of commits with the same committer date quickly. Currently I'm using cygwin and rebase is slow like hell, but when I switch to Linux, I'll need something to ensure that there'll be no two commits with the same committer date. I think even a one second sleep could do for me, but can I arrange for it easily? ```