{"thread":{"id":"25678","subject":"Rebase problems","startedAt":"2010-11-08T18:19:09Z","lastAt":"2010-11-12T00:07:37Z","messageCount":5,"participants":["Maaartin","Wincent Colaiuta","Andreas Schwab","Maaartin-1"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"155406","messageId":"loom.20101108T190513-206@post.gmane.org","threadId":"25678","inReplyTo":null,"subject":"Rebase problems","fromName":"Maaartin","fromEmail":"grajcar1@seznam.cz","sentAt":"2010-11-08T18:19:09Z","receivedAt":"2010-11-08T18:19:09Z","isPatch":false,"sender":{"key":"grajcar1@seznam.cz","avatar":null},"body":"I'm using git for a project I'm working on alone (and I really like it), so I \ncould rebase a lot, if I hadn't the following problems.\n\nThere's a file containing the timestamp which gets compiled in, so the \nexecutable can show it's version. Sometimes, I need to set it couple of times a \nday, sometimes only once a week. For each such timestamp I create a tag, so I \ncan track it to the source easily. The timestamp is an important piece of \ninformation, so I put the containing file under version control. The downside is \nthat I often get a conflict in this file halting my rebase. Is there a way how \nto ignore or automatically resolve all conflicts in this file (any resolution \nstrategy is fine, as it will be overwritten anyway).\n\nThe second problem is problem of cygwin. While most of the operations git run in \nfractions of seconds, the most trivial rebase may take one minute or alike. Any \nidea what different things rebase do?\n"},{"id":"155410","messageId":"FA37BC66-64CF-4A62-80E9-EC45EAE392C4@wincent.com","threadId":"25678","inReplyTo":"loom.20101108T190513-206@post.gmane.org","subject":"Re: Rebase problems","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2010-11-08T18:33:27Z","receivedAt":"2010-11-08T18:33:27Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"On 08/11/2010, at 19:19, Maaartin wrote:\n\n> I'm using git for a project I'm working on alone (and I really like it), so I \n> could rebase a lot, if I hadn't the following problems.\n> \n> There's a file containing the timestamp which gets compiled in, so the \n> executable can show it's version. Sometimes, I need to set it couple of times a \n> day, sometimes only once a week. For each such timestamp I create a tag, so I \n> can track it to the source easily. The timestamp is an important piece of \n> information, so I put the containing file under version control. The downside is \n> that I often get a conflict in this file halting my rebase. Is there a way how \n> to ignore or automatically resolve all conflicts in this file (any resolution \n> strategy is fine, as it will be overwritten anyway).\n\nRhetorical questions follow; no need for you to answer:\n\n- Why is the timestamp an \"important\" piece of information?\n\n- 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?\n\n- 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?\n\n- If you are really enamored of timestamps, would extracting the latest commit timestamp out of the repo be enough?\n\n- 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?\n\nCheers,\nWincent\n"},{"id":"155416","messageId":"m2vd47iper.fsf@igel.home","threadId":"25678","inReplyTo":"loom.20101108T190513-206@post.gmane.org","subject":"Re: Rebase problems","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2010-11-08T19:30:36Z","receivedAt":"2010-11-08T19:30:36Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Maaartin <grajcar1@seznam.cz> writes:\n\n> There's a file containing the timestamp which gets compiled in, so the \n> executable can show it's version. Sometimes, I need to set it couple of times a \n> day, sometimes only once a week. For each such timestamp I create a tag, so I \n> can track it to the source easily. The timestamp is an important piece of \n> information, so I put the containing file under version control. The downside is \n> that I often get a conflict in this file halting my rebase. Is there a way how \n> to ignore or automatically resolve all conflicts in this file (any resolution \n> strategy is fine, as it will be overwritten anyway).\n\nIf you already have a tag for every timestamp, why not autogenerate the\ntimestamp from the tag?\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"155422","messageId":"4CD856B8.7030305@seznam.cz","threadId":"25678","inReplyTo":"FA37BC66-64CF-4A62-80E9-EC45EAE392C4@wincent.com","subject":"Re: Rebase problems","fromName":"Maaartin-1","fromEmail":"grajcar1@seznam.cz","sentAt":"2010-11-08T19:59:52Z","receivedAt":"2010-11-08T19:59:52Z","isPatch":false,"sender":{"key":"grajcar1@seznam.cz","avatar":null},"body":"On 10-11-08 19:33, Wincent Colaiuta wrote:\n> On 08/11/2010, at 19:19, Maaartin wrote:\n> \n>> I'm using git for a project I'm working on alone (and I really like it), so I \n>> could rebase a lot, if I hadn't the following problems.\n>>\n>> There's a file containing the timestamp which gets compiled in, so the \n>> executable can show it's version. Sometimes, I need to set it couple of times a \n>> day, sometimes only once a week. For each such timestamp I create a tag, so I \n>> can track it to the source easily. The timestamp is an important piece of \n>> information, so I put the containing file under version control. The downside is \n>> that I often get a conflict in this file halting my rebase. Is there a way how \n>> to ignore or automatically resolve all conflicts in this file (any resolution \n>> strategy is fine, as it will be overwritten anyway).\n> \n> Rhetorical questions follow; no need for you to answer:\n\nHowever, I will. I've asked myself some of them already.\n\nAddendum: It looks like your question were the right ones, the problem\nseems to be solved now in a very easy way.\n\n> - Why is the timestamp an \"important\" piece of information?\n\nI need the timestamp (or something else) in order to match the\nproblematic version to the source.\n\n> - 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?\n\nSure, I have considered it and I haven't ruled it out (I'm quite new to\ngit). The timestamp is something the customer can understand better and\nhas got used to during the past 5 yeas. It gets also stored in some\ndatabase columns, whose type I had to change. Using tags I can relate\nthe timestamp to the commit.\n\nIn any case I need to embed the information in the executable, which was\nimpossible for a hash in a committed file. However, I don't want to\ncommit it, anyway... so probably it's the way to go.\n\nThe output of git describe is quite unusable for this purpose, since the\ncustomer would happily drop the hash which can lead to ambiguities.\nGiving him only the SHA-1 would be safer.\n\n> - 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?\n\nI could do it using an untracked file, which would eliminate my problem.\nThe downside is that then--assuming using the timestamp--I'd have to\nrely on the tags or some logfile. No, there's no downside as I see after\nhaving read your next line.\n\n> - If you are really enamored of timestamps, would extracting the latest commit timestamp out of the repo be enough?\n\nSure it would, I was mostly ignoring the commit timestamp until now, and\ndidn't notice that I'm using a different timestamp for the executable\nwithout any reason. Now I need just trivial changes.\n\n> - 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?\n\nPartly, starting using the timestamp was a huge improvement many years\nago and I was quite happy with it until now. OTOH, git is new to me so I\nwas thinking about changing what I'm doing with git or finding some new\noption there instead.\n\nNow, I can have my timestamp and eat it, thank you.\n"},{"id":"155748","messageId":"loom.20101112T005610-259@post.gmane.org","threadId":"25678","inReplyTo":"4CD856B8.7030305@seznam.cz","subject":"Re: Rebase problems","fromName":"Maaartin","fromEmail":"grajcar1@seznam.cz","sentAt":"2010-11-12T00:07:37Z","receivedAt":"2010-11-12T00:07:37Z","isPatch":false,"sender":{"key":"grajcar1@seznam.cz","avatar":null},"body":"Maaartin-1 <grajcar1 <at> seznam.cz> writes:\n\n> On 10-11-08 19:33, Wincent Colaiuta wrote:\n> > - If you are really enamored of timestamps, would extracting the latest \ncommit timestamp out of the repo be enough?\n> \n> Sure it would, I was mostly ignoring the commit timestamp until now, and\n> didn't notice that I'm using a different timestamp for the executable\n> without any reason. Now I need just trivial changes.\n\nTime to comment on myself:\n\nIt works nice, but there's a small problem. I can't take the author date since \nit gets preserved across rebases, so I could get non-unique dates. The committer \ndate corresponds with the time I actually create the executable, and I really \nnot going to produce more than one executable per second, so it works nicely. \nExcept for rebase, which can create a lot of commits with the same committer \ndate quickly.\n\nCurrently I'm using cygwin and rebase is slow like hell, but when I switch to \nLinux, I'll need something to ensure that there'll be no two commits with the \nsame committer date. I think even a one second sleep could do for me, but can I \narrange for it easily?\n"}]}