Unresolved issues

Here are some issues recently raised on the list, some of them with patches, that have not been resolved satisfactory.

 [gmane=http://thread.gmane.org/gmane.comp.version-control.git]

* "git status" is not a read-only operation.

  It needs to do enough lstat(2) to run "update-index --refresh" to come
  up with the information it needs to give.  We could do so internally
  without writing out the result to the index (there is a patch to do
  this) even if a repository is not writable.

	$gmane/39205
        $gmane/39206

  However, a big downside of this approach is that doing so
  unconditionally would mean the expensive lstat(2) is wasted
  afterwards.

	$gmane/39246

  Currently an workaround is to run git-runstatus and live with the fact
  that otherwise unmodified but stat-dirty paths to show up in the
  output.  I think (iff somebody feels strongly about it) a possible
  compromise would be to see if we can update the index, and do what the
  current code does if we can, and otherwise fall back on the new code
  that does the internal "update-index --refresh".

* "git -p status" does not honor color.

  The problem is that when git-runstatus is run, it already runs as an
  upstream process of a pipe and git_config_colorbool() would say "oh,
  our output is not a terminal, and we did not start pager ourselves".

	$gmane/39919

  A patch was proposed to propagate pager_in_use as an environment down
  to subprocesses,

	$gmane/39936

  but I think this would have unintended side effects when scripts want
  to run commands and redirect their output internally for their own use
  (they will get colorized output from lower level in their temporary
  files or v=$(cmd) redirect).

* "git log -r --raw -z -- path | grep -z SHA-1" is not very useful.  

  We would need a separate -Z option that means "output records are
  separated with NUL, but output fields are not".

	$gmane/39207

  This would help to solve "someone mails me a blob, git please tell me
  what it is" problem.

	$gmane/39925

* "git fetch" between repositories with hundreds of refs.

	$gmane/39330

  There are partial rewrite of the most expensive parts of git-fetch in
  C parked in 'pu'.  It might be good enough for public consumption
  without going the whole nine yards.  I dunno.  I am not very keen on
  rewriting all of "git fetch" in C right now, as people seem to be
  still interested in touching it (including "git bundle" topic).

* core.autocrlf

  Linus and I laid out most of the infrastructure and the basic things
  already seem to work.  We even added some tests ;-)

        commit 6716027108f426c83038b05baf3f20ceefe6fbd1
        commit 634ede32ae7d4c76e96e88f9cd5c1b3a70ea08ac
        commit d7f4633405acf3dc09798a759463c616c7c49dfd
        commit 6c510bee2013022fbce52f4b0ec0cc593fc0cc48

  What's still missing is support for .gitignore like "these files are
  text" information.

  One thing that might be tricky is what should be done while making a
  merge or checking out from a tree.  Ideally, the information should be
  read from the tree that is being extracted, but that would make the
  code structure a little bit, eh, "interesting".

* Use update-ref in cvsserver.

  It currently does it by hand, which is racy and does not leave traces
  in reflog.

	$gmane/39541

* Dissociating a repository from its alternates

  I sent out a rather elaborate changes in the binary, but what Johannes
  suggests is much easier to implement.

	$gmane/39834

  Volunteers?

* User-wide ignore list

	$gmane/39809

  I am not really sure if this is even a desirable feature, but assuming
  it is, one possible solution would be to do this:

	$gmane/39820

  But I am not going to do this myself; I suspect that it would be
  fairly simple and straightforward that some git-hacker-hopeful should
  be able to.

* git-diff2

  It somehow feels a tad ugly that this is a separate command from
  git-diff, but I do not feel strongly enough to fix it myself.
  Currently parked in 'pu'.