Re: Rebase problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Maaartin-1 <grajcar1 <at> 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?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]