fast-export to refrain from writing 'C' when it has
> already written a modification command for a file.
>
> An existing test in t9350-fast-export is also fixed in this patch. The
> existing line "C file6 file7" copies the wrong version of file6, but it
> has coinc
Hi, did anyone manage to take a look at this bug? Friendly ping.
Juraj
On Fri, Sep 15, 2017 at 12:01 AM, Juraj Oršulić wrote:
> The commands should be self explanatory. 0.2.0~20 is the first commit
> where the reconstructed repository diverges, that commit had a
> simultaneous copy an
The commands should be self explanatory. 0.2.0~20 is the first commit
where the reconstructed repository diverges, that commit had a
simultaneous copy and edit of one file. It seems that copy/rename
detection, enabled with -M -C is confused by this. I reproduced it
with git 2.14 next @ 8fa685d.
gi
Hi Igor! Thanks on for thoroughly searching the mailing list and on
your suggestions. I hope that someone will come up with a fix that
both preserves the author details and date correctly.
Regards,
Juraj
On Thu, Mar 23, 2017 at 11:54 PM, Igor Djordjevic
wrote:
> Hi Juraj,
>
> On 23/0
ef24b133dda6c18b8ef01b1a38f9e049d87f2021
Author: Juraj Oršulić
I open git gui again, click "Amend Last Commit", press "Commit", and I
get this in git log:
commit 6e09ff9edcef863d92f02cf86e0307c27171aec0
Author: Juraj OrÅ¡uliÄ
Does anyone have any idea what could be the cause?
I t
g.
Thanks,
Juraj
I've just noticed that amending a commit from git-gui uses the time of
amending as the new timestamp of the commit, whereas git commit
--amend preserves the original timestamp. Maybe the two should work
the same, whatever it is decided to be the standard behavior.
Juraj
7 matches
Mail list logo
