This is not meant to be an exhaustive list, and I probably will
change my mind after I sleep on them, but before I go to bed,
here are a handful of glitches I think are worth fixing.

* Bare repository.

We have a heuristic to determine bareness and change our
behaviour (albeit slightly) based on it.  The heuristic is not
perfect, but the intent is to avoid things that are undesirable
for bare repository when we know (or guess) it is one, and allow
the repository owner to override if we guessed wrong.  Currently
the only such "undesirable thing" is the use of reflog even when
core.logallrefupdates is not set, but we have an RFC patch
floating around to forbid working-tree operations in a bare
repository to prevent accidents from happening.  I think at that
point it may be prudent to also give users a way to mark a bare
repository explicitly as such, say, with "core.bare = true".
Repository creation by init-db and clone with --bare option can
automatically set this, so adding this should not be too painful
for the users.

* Packed refs.

'git-pack-refs --all' leaves heads/ unpacked because they are
expected to change often, but it packs remotes/.  This does not
make any sense (it is another fallout from "separate remote"
layout that many people pushed, even though I was mildly against
it and mostly uninterested in it, and in the retrospect I think
they did not know about or knew but did not tell me about issues
like this, which makes me somewhat unhappy X-<).  I'd like to
change the command not to pack anything but tags/ hierarchy.
This keeps bases/ used by StGIT unpacked, which makes a lot of
sense -- the hierarchy is even more volatile than heads/.

'git-pack-refs' should default to --prune.  There is no point
not to, really.

'git-pack-refs' should probably learn how to unpack, although
there is no real need for it.

* Remote management.

I pushed out 'git-remote' in 'next' tonight, but as I said, I
think it does very limited things it should do in the ...
[ message continues ]

Maybe we should at least mention another cygwin quirk:
cygwin (or is it its bash?) treats .exe files and +x-files without
extension somehow stupid: it prefers the file without extension
to the .exe. For example, after installation of git-merge-recursive
you have the old python script and git-merge-recursive.exe in
the same directory. Guess which one is used... Right, the old
python script. Same for count-objects and other recently
rewritten scripts.
-

[ message continues ]

Hi,


I just sent out a patch in my mail "[PATCH] Makefile: add 
clean-obsolete-scripts target" which should help.

It might be necessary (under obscure circumstances) to remake all and make 
clean-obsolete-scripts again, to remove the correct files. But in general, 
it should be fine to be called just once.

Ciao,
Dscho

-

[ message continues ]

Well, you also have to give people at least notice _when_ the
target should be called. It can take long time until the victim
notices that he has git-branch (from .sh) and git-branch(.exe).
And that in two places: in the installation target directory and
in the build directory (because in windows it is not fcking

Don't think so. We still have candidates for conversion
into C (git-checkout and git-commit being my favorites).
-

[ message continues ]

Hi,


Okay. Fair enough. So maybe this is the wrong approach: maybe the "all" 
target should look for _all_ executables if there is a script of the same 
name, and in that case remove it; and the "install" target should do the 

I was referring to

	make clean-obsolete-scripts; make; make clean-obsolete-scripts

being necessary, because the script somehow got a newer time stamp than 
the executable.

But yes, I think there are way more candidates, my pet peeves being 
git-ls-remote and git-fetch.

Ciao,
Dscho

-

[ message continues ]

...but unless they're in the index and the build directory is a git repo.
It's going to far. I suggest just giving a word of warning on cygwin at
at the end of build. It is the only platform broken in such a stupid way.
-

[ message continues ]

Hi,


I do not have time to follow up on my earlier attempts to teach git-log 
about traversing reflogs instead of the commit parents. But Shawn had a 
working proposal, didn't he?

Ciao,
Dscho
-

[ message continues ]

Yes, but my proposal added a lot of code.  Junio's comment is that
he would prefer one that doesn't, such as by reusing as much of the
revision listing machinary as possible.  Which you had looked into
doing.

I myself am also severly lacking in time right now.  *if* I get
any more Git time in the next week its going to be to finish out
some patches on the bash-completion, so I can try to sneak them
into the v1.5.0 release (if possible).  Its unlikely I'll be able
to look at a `reflog show` anytime soon.

-- 
Shawn.
-

[ message continues ]

Hi,


Did you have any chance to look at the patch I posted? It adds 
"--walk-reflogs" option to the revision walker, and as long as there is 
reflog information, traverses the commits in that order. It also shows the 
reflog data just below the "commit" line.

Ciao,
Dscho

-

[ message continues ]

Junio C Hamano writes:
 > * Handling paths that are unknown to the index.
 > 
 > I sent out patches tonight to teach "git reset <tree> -- <path>"
 > to restore the absense of path in the index from the tree
 > tonight.  There was another one recently brought up on the list:
 > "git commit -- <path>" for path that is no longer known to the
 > index.  While jumping the index is a practice I particularly do
 > not want to encourage by extending git to support it, we already
 > have support for most of the cases, so I think it makes sense to
 > do this for consistency.  I haven't thought about the necessary
 > changes yet, so people can beat me if they want to.  My vague
 > idea is to check HEAD to see if <path> exists and if so refrain
 > from complaining.

This looks like a job for your para-walk topic. For this git-commit
case we just need a

  git-ls --no-workdir --error-unmatch HEAD -- <pattern>...

to replace git-ls-files. To my untrained eyes it looks like this is
mostly there (AFAICS it doesn't do pattern matching and the
--error-unmatch thingy).

-

[ message continues ]