On 3/9/2012 1:47 PM, Corinna Vinschen wrote:
On Mar 9 19:22, Christian Franke wrote:
Christopher Faylor wrote:
On Fri, Mar 09, 2012 at 09:43:07AM +0100, Corinna Vinschen wrote:
On Mar 8 21:37, Christian Franke wrote:
I'm not so sure this option would make a lot of sense. An option not
used
On Fri, Mar 09, 2012 at 09:09:41PM +0100, Corinna Vinschen wrote:
>On Mar 9 14:55, Christopher Faylor wrote:
>> On Fri, Mar 09, 2012 at 08:47:33PM +0100, Corinna Vinschen wrote:
>> >On Mar 9 19:22, Christian Franke wrote:
>> >> Christopher Faylor wrote:
>> >> >I don't think the default should cha
On Mar 9 14:55, Christopher Faylor wrote:
> On Fri, Mar 09, 2012 at 08:47:33PM +0100, Corinna Vinschen wrote:
> >On Mar 9 19:22, Christian Franke wrote:
> >> Christopher Faylor wrote:
> >> >I don't think the default should change but maybe an option could be
> >> >added for people who want to see
Corinna Vinschen wrote:
On Mar 9 19:22, Christian Franke wrote:
Christopher Faylor wrote:
On Fri, Mar 09, 2012 at 09:43:07AM +0100, Corinna Vinschen wrote:
On Mar 8 21:37, Christian Franke wrote:
rebase does not explicitly (re)set the timestamp after rebasing. Is
this by design?
Well, let
On Fri, Mar 09, 2012 at 08:47:33PM +0100, Corinna Vinschen wrote:
>On Mar 9 19:22, Christian Franke wrote:
>> Christopher Faylor wrote:
>> >On Fri, Mar 09, 2012 at 09:43:07AM +0100, Corinna Vinschen wrote:
>> >>On Mar 8 21:37, Christian Franke wrote:
>> >>>rebase does not explicitly (re)set the t
On Mar 9 19:22, Christian Franke wrote:
> Christopher Faylor wrote:
> >On Fri, Mar 09, 2012 at 09:43:07AM +0100, Corinna Vinschen wrote:
> >>On Mar 8 21:37, Christian Franke wrote:
> >>>rebase does not explicitly (re)set the timestamp after rebasing. Is
> >>>this by design?
> >>>
> >>Well, let me
Christopher Faylor wrote:
On Fri, Mar 09, 2012 at 09:43:07AM +0100, Corinna Vinschen wrote:
On Mar 8 21:37, Christian Franke wrote:
Corinna Vinschen wrote:
On Mar 7 23:07, Christian Franke wrote:
The rebase tool does not change last modification timestamp of each
DLL even if its data has ch
On Fri, Mar 09, 2012 at 09:43:07AM +0100, Corinna Vinschen wrote:
>On Mar 8 21:37, Christian Franke wrote:
>> Corinna Vinschen wrote:
>> >On Mar 7 23:07, Christian Franke wrote:
>> >>The rebase tool does not change last modification timestamp of each
>> >>DLL even if its data has changed. This is
On Mar 8 21:37, Christian Franke wrote:
> Corinna Vinschen wrote:
> >On Mar 7 23:07, Christian Franke wrote:
> >>The rebase tool does not change last modification timestamp of each
> >>DLL even if its data has changed. This is likely because Windows
> >>"may" not update the timestamp for files wr
Corinna Vinschen wrote:
On Mar 7 23:07, Christian Franke wrote:
The rebase tool does not change last modification timestamp of each
DLL even if its data has changed. This is likely because Windows
"may" not update the timestamp for files written through a memory
mapped view.
Is this an intende
On Mar 7 23:07, Christian Franke wrote:
> The rebase tool does not change last modification timestamp of each
> DLL even if its data has changed. This is likely because Windows
> "may" not update the timestamp for files written through a memory
> mapped view.
>
> Is this an intended behavior of r
What happens when you `touch` the DLL?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
The rebase tool does not change last modification timestamp of each DLL
even if its data has changed. This is likely because Windows "may" not
update the timestamp for files written through a memory mapped view.
Is this an intended behavior of rebase?
Christian
--
Problem reports: http
13 matches
Mail list logo