Junio C HamanoThis 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 current shape. What it involves is just scripting and requires no deep core knowledge, so it might be a good project to enhance on for new people.
Often people suggest "git checkout -b next origin/next" to add branch.next.remote = origin and branch.next.merge = refs/heads/next.
I do not think it should be the default, but I do understand why people would want this (what I mean is that I do not think -b does not imply you would want to keep tracking and merging from there for almost all the time -- rather I would suspect it would be 50:50 thing), so I am not opposed to add an easy way to ask for these two variables to be set up when the new branch is made. Perhaps "git checkout -B"?
* 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.
* Detached HEAD.
You've seen an experimental patch, discussion, and a few follow-up patches, all in 'pu'. I'm not actively looking at this right now.
* Reflogs.
'git reflog show' needs to be done -- and preferrably in a way that does not add too much code.
After rebasing a huge series, you need to know that N patches were involved and have to say HEAD@{N}, instead of HEAD@{1}. This is unfortunate --- we might want to find a way to make the reflog's recording granularity match the user operation granularity better. But this is probably a fairly intrusive change we would not want right now.
* Misconfigured "tracking branch" refspecs.
There is a special hack in git-pull that passes --update-head-ok to git-fetch. This is a workaround for a case where underlying git-fetch is told to update the current branch that is also used as a tracking branch. This can happen either because the user misconfigured "Pull: refs/heads/master:refs/heads/master", or the user checked out a tracking branch to take a peek, and forgot he was on such a branch and issued "git pull". Both are much less likely to happen in the separate remote layout, and I think we should deprecate both --update-head-ok flag in git-fetch and support for this situation in git-pull.
Instead, we should unconditionally allow fetching into the current branch for bare repositories.
The reason we should not allow fetching into the current branch for a repository with a working tree is that allowing so will make the index and working tree useless. Such a fetch updates the value of HEAD, and after that happens the old value of HEAD is lost and, there is no way to even run a 3-way merge between the (old) HEAD, index and the working tree. Even if the old value of HEAD is kept somewhere before the fetch happens (which is what --update-head-ok code allows git-pull to do), the difference between old HEAD and HEAD needs to be propagated to both index and the working tree separately, so it involves two 3-way merges, which is way complicated than it is really worth.
* Topic management.
In 'todo' branch there is a git-topic script I use to generate the "What's cooking" messages. Although the script in its current form is probably too specific to my workflow (which has one baseline with two development branches, and names topics in certain ways -- the latter is customizable from the command line), I think something like that may be useful for people who need to manage multiple topic branches.
