Jeff King writes:
> I'm not entirely convinced it's worth all of this effort, but I think it
> would be _possible_ at least.
I thought that the original poster wants to have a knob that the
project can ask its participants to enable in their clones of the
repository that wars
I’m not git expert but, from a user point of view, the following would make
sense. When adding a file, git could check whether a different file is already
in the repository with the same name (case-insensitive check). Then simply
report that this may be a mistake and request to use ‘git add -f’
On Tue, Feb 06, 2018 at 02:24:25PM +0100, Ævar Arnfjörð Bjarmason wrote:
> 3) Such hooks slow down pushes, especially on big repos, you can
> optimize things a bit (e.g. only look in the same directories), but
> pathologically you end up needing to compare the cross-product of
>
On Tue, Feb 06 2018, Filip Jorissen jotted:
> Hi all,
>
> Thank you for your quick responses. I was able to resolve the problem based
> on your feedback!
>
> Based on this experience, I would like to suggest that git is somehow able to
> avoid these problems by doing a case check itself rather
On Tue, Feb 6, 2018 at 8:09 PM, Filip Jorissen
wrote:
> Hi all,
>
> Thank you for your quick responses. I was able to resolve the problem based
> on your feedback!
>
> Based on this experience, I would like to suggest that git is somehow able to
> avoid these
Hi all,
Thank you for your quick responses. I was able to resolve the problem based on
your feedback!
Based on this experience, I would like to suggest that git is somehow able to
avoid these problems by doing a case check itself rather than relying on the
host OS for this?
Kind regards!
On Sat, Jan 27, 2018 at 07:35:49PM +, Filip Jorissen wrote:
> I think our git repository is bugged. The reason why I say this is the
> following. When cloning the repository, the newly cloned repository
> immediately has file changes. Steps to reproduce and illustration is at the
> end of
On Sat, Jan 27, 2018 at 08:59:50PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Jan 27 2018, Filip Jorissen jotted:
>
> > I think our git repository is bugged. The reason why I say this is the
> > following. When cloning the repository, the newly cloned repository
> > immediately has file
On Sat, Jan 27 2018, Filip Jorissen jotted:
> I think our git repository is bugged. The reason why I say this is the
> following. When cloning the repository, the newly cloned repository
> immediately has file changes[...].
If you run this:
git ls-files | tr '[:upper:]' '[:lower:]' | sort
Dear all,
I think our git repository is bugged. The reason why I say this is the
following. When cloning the repository, the newly cloned repository immediately
has file changes. Steps to reproduce and illustration is at the end of this
email. Git checkout does not work to remove the file
10 matches
Mail list logo