Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

autogenerate .git/info/exclude from .hgignore when .hgignore uses syntax=glob? #219

Open
anntzer opened this issue Aug 6, 2019 · 9 comments

Comments

@anntzer
Copy link

anntzer commented Aug 6, 2019

It would be a nice usability improvement if, upon cloning a repository, git-cinnabar autogenerated .git/info/exclude (or offered an option to do so) from .hgignore, at least in the case where .hgignore uses syntax: glob (which should be straightforward to convert to a .gitignore).

@glandium
Copy link
Owner

glandium commented Aug 7, 2019

One thing that needs some extra thought is how to keep .git/info/exclude synchronized with .hgignore. A post-checkout hook?

@glandium
Copy link
Owner

glandium commented Aug 7, 2019

I guess that's way to make it optional: installing a post-checkout hook would be opt-in.

@glandium
Copy link
Owner

glandium commented Aug 7, 2019

What this also means is that this doesn't necessarily mean it needs to be part of git-cinnabar. Not that I would refuse the feature, but that means it can be developed completely independently.

@anntzer
Copy link
Author

anntzer commented Aug 7, 2019

Ah, cute idea :) Now I only need to do an exegesis of the hgignore and gitignore man pages to check whether there's any subtle difference in semantics...

@anntzer
Copy link
Author

anntzer commented Aug 20, 2019

Looks like the following post-commit hook does the trick (error handling could easily add more messages for the failing cases). I'm personally happy to just copy-paste it as needed, and don't know much about how it could be integrated with git-cinnabar, but feel free to adopt it.

#!/bin/sh
git cinnabar python <<EOF
from __future__ import print_function
import subprocess
import warnings
import mercurial.match
if subprocess.check_output(["git", "ls-files", ".gitignore"]):
    # There's already a tracked gitignore in the repo, don't overwrite it.
    sys.exit()
try:
    pats = mercurial.match.readpatternfile(".hgignore", warn=warnings.warn)
except IOError:
    sys.exit()
with open(".gitignore", "w") as file:
    print("# This file is autogenerated by .git/hooks/post-checkout.", file=file)
    print(".gitignore", file=file)
    for pat in pats:
        if pat.startswith("relglob:"):
            print(pat[len("relglob:"):], file=file)
        # We can't handle other patterns, so just skip them.
EOF
# vim: ft=python

@glandium
Copy link
Owner

glandium commented Oct 8, 2019

Sorry for the late reply. Somehow this got off my radar.

Why did you use .gitignore rather than .git/info/exclude?

@anntzer
Copy link
Author

anntzer commented Oct 8, 2019

IIRC I was thinking something like "if an hg repo already has a gitignore then the repo owner must be intending it for dual use and so we shouldn't bother doing anything if a gitignore is already there" but that just seems overthinking it, so probably using .git/info/exclude is just fine.

@glandium
Copy link
Owner

glandium commented Oct 8, 2019

You could still avoid doing anything when there's already a .gitignore file...

@anntzer
Copy link
Author

anntzer commented Oct 8, 2019

Certainly that would work too, my point was just that I wrote this a couple of weeks ago and only vaguely remember what was the rationale for the exact design I chose (which I'm not particularly wedded to).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants