> Try:
> LESS=-inqMSFXx4
> in your environment (or a suitable subset), it solves that problem.

More precisely, -F is the relevant flag. Unfortunately it doesn't work
with -c. I've bug reported that. Still I think I'd prefer to configure
git status to not use the pager at all.

> It's not quite the same as -l because it *does* recurse.

Yep, that's the problem.

> "man gitattributes", crlf attribute.

Thanks for the tip about attributes. The svn solution for it, where
the properties are directly associated with the files themselves, is
still more elegant imo. Anyway, .gitattributes files are not any worse
than things like .cvsignore. It's workable.

> "man gitattributes", ident attribute.

Ok, good. I think this should be turned on by default in the git repo
so that all those $Id$ get back in business again.

> git-svn keeps a lot of state in memory, maybe even has memory leaks,
> don't know for sure.  What helps, everytime, is simply killing and
> restarting git-svn.  Git-svn is *very* good at restarting and picking up
> right where it left off.

Tried that, didn't help the speed at all. It also gc'd by itself every
once in a while, and doing an extra gc didn't improve things either.
    • ... Martin Bähr
      • ... Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum
        • ... Martin Baehr
          • ... Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum
            • ... Stephen R. van den Berg
      • ... Martin Stjernholm, Roxen IS @ Pike developers forum
        • ... Martin Baehr
          • ... Martin Stjernholm, Roxen IS @ Pike developers forum
            • ... Stephen R. van den Berg
        • ... Stephen R. van den Berg
          • ... Martin Stjernholm, Roxen IS @ Pike developers forum
            • ... Stephen R. van den Berg
            • ... Stephen R. van den Berg
              • ... Martin Stjernholm, Roxen IS @ Pike developers forum
              • ... Stephen R. van den Berg
              • ... Martin Stjernholm, Roxen IS @ Pike developers forum
    • ... Stephen R. van den Berg
      • ... Peter Bortas @ Pike developers forum
        • ... Stephen R. van den Berg
  • Re:... Mirar @ Pike developers forum

Reply via email to