AW: AW: fast-import fails with case sensitive tags due to case insensitive lock files
- From
- Wendeborn, Jonathan <jonathan.wendeborn@bruker.com>
- Date
- Mar 5, 2019, 06:25 UTC
- Message-ID
- <b8976ee7d99547649cdded5a80ab118d@bruexc101.brumgt.local>
- In-Reply-To
- <nycvar.QRO.7.76.6.1903041627230.45@tvgsbejvaqbjf.bet>
Hi Johannes,
>> One thing I still would like to encourage to is to improve the error >> message which is really misleading in this case.
> Well, that is at least something you could do. After all, you use a volunteer-driven project, so you could at least volunteer a little time to improving it yourself.
That's true :)
Thank you! Jonathan
-----Ursprüngliche Nachricht----- Von: Johannes Schindelin <Johannes.Schindelin@gmx.de> Gesendet: Montag, 4. März 2019 16:29 An: Wendeborn, Jonathan <Jonathan.Wendeborn@bruker.com> Cc: brian m. carlson <sandals@crustytoothpaste.net>; git@vger.kernel.org Betreff: Re: AW: fast-import fails with case sensitive tags due to case insensitive lock files
Hi Jonathan,
On Mon, 4 Mar 2019, Wendeborn, Jonathan wrote:
Show 17 quoted lines
> > Right now, you have some choices: > > • Volunteer to implement reftable. > > • Since you're on Windows 10, set your Git repository directory as > > case-sensitive. > > • Use Windows Subsystem for Linux, which is case sensitive and > > creates > > directories with that flag (even on NTFS), to do your import. > > • If you control the fast-export output, adjust the arguments you > > pass > > such that the output does not contain one of the offending tags. > > Hi Brian, > > Thank you very much for your answer! > > Unfortunately I am stuck with Windows 10 1703 which neither supports > case-sensitivity nor any Linux subsystem from the Microsoft Store :(
Too bad.
> Also, my employer unfortunately doesn’t allow me to invest the time to > implement reftable,
Even worse!
> so I guess I go with manually leaving out the one conflicting label I > found and tagging it manually afterward.
That is a valid workaround.
> One thing I still would like to encourage to is to improve the error > message which is really misleading in this case.
Well, that is at least something you could do. After all, you use a volunteer-driven project, so you could at least volunteer a little time to improving it yourself.
Ciao, Johannes