git todo-list ?

Junio C Hamano wrote:

I wonder if git has a "git-todo" page somewhere, either in its docs, on on web somewhere.

The reason I ask about "git-todo" is becase I contributed couple of patches to vim in the past, and that's because vim has the todo-page (vim->:help todo). So when I had free cycles, I looked into vim-todo, picked an item that I could do, wrote a pacth, and sent it in. (Only the main maintainer of vim puts things into todo list).

In the earlier days, omissions were seen on surface. Now that git matured, things to add or fix are not obvious. The todo doc is great place to have requested-fixes/wishes recorded. That's because those people who hit the problems do not necessarily have time/desire to fix them, and someone who has free cycles to write code might not hit himself the problem that others hit.

Another usefulness [of todo doc] is that it allows to clearly label 'not implemented yet, but it is in the todo' things (for example -- ability to keep empty dirs in the tree).

The todo list works by giving directions to those who have time to write patches.

Does git have todo-list ?

Yakov

"Yakov Lerner" <iler.ml@gmail.com> writes:

We could start with one with an entry:

	- create a initial set of to-do-list and find a
          volunteer to maintain it.

perhaps at wiki.or.cz/

Junio C Hamano wrote:

There is both ToDo and Wishlist pages on Git Wiki:
  http://git.or.cz/gitwiki/ToDo
  http://git.or.cz/gitwiki/Wishlist
 
There exists TODO file in todo branch of git.git repository:
  http://git.kernel.org/?p=git/git.git;a=tree;hb=todo
  http://git.kernel.org/?p=git/git.git;a=blob;hb=todo;f=TODO

And of course "Getting Involved" section on FrontPage of Git Wiki.

Junio C Hamano <junkio@cox.net> writes:

Arrgh.  The url is http://git.or.cz/gitwiki

By the way, I see on that wiki that somebody attempted to have a list of Wishlist (http://git.or.cz/gitwiki/Wishlist). I think many of them are now irrelevant, or stale, or have been rejected. It even includes tongue-in-cheek suggestions made as counterarguments as if they are serious proposals. I just have done a minimum clean-up but many of them that I did not touch are not necessarily there because I agree they are good suggestions, but because I did not understand what they are talking about.

As with any "tracking" list, wanting to have one and starting is the easy part. Unless kept up to date, such a list becomes quickly useless, or even worse than not having one, leading to wasted wild goose chase if people look at it without knowing how stale it is.

And keeping any such list up-to-date takes a lot of effort. Anybody who attempts it needs to have a lot of time and enough knowledge to sift through both the list traffic to note not just the initial issue-raising, but how the issues have been resolved (or unresolved). I sometimes do that and send out "Unresolved issues" message to the list myself every once in a while, but as the maintainer my attention tends to be more on the big-picture issues and not minor details, and I do not think there are any unresolved issue at the big-picture level that I haven't talked about in recent "What's in / What's cooking" messages.

On Tuesday 2007 April 24 01:54, Junio C Hamano wrote:

I get the blame for that. I think I originally added it, and then you made exactly the point you make below about it being an unreliable method for keeping track of outstanding items and I found I couldn't disagree.

My own recommendation for this page - or in fact any similar list - is don't bother - let's delete it or replace it with a link to Junio's email.

The way to get new features into git seems to be either
 a. Do it yourself
 b. Mention it (but not excessively) on the mailing list, if one of the guru's
    is interested enough to do it (their choice not yours), then you're in.  
    Otherwise - see (a).

I thought I'd included only serious suggestions. Perhaps my humour-detector was a bit faulty that day.

Andy

Andy Parkins <andyparkins@gmail.com> writes:

I wouldn't dismiss it that fast. Replacing it with a notice that says the community is looking for a volunteer (or group of volunteers) who is willing to invest the time and effort to keep it up to date would be very good, though.

I miss "kernel traffic" and its cousen "git traffic" (which we saw only the first issue of, unfortunately). FWIW, until very recently, your "niggles" list $gmane/34244 was still kept in my box as 'ticked'. I recently unticked it as many of the issues there have been resolved and some have been made irrelevant.

If somebody sent such a list (maybe starting with only his own "niggles" list) and posted it to the list bi-weekly (with a good maintenance -- removing stale items from such a list is often much more important than adding newly raised issues to keep it useful), that would be a great contribution to the community. Interested people could even take turns to be the list editor.

I would say that is true for almost any project in the free software world. Also I would not state b. with word "guru". You either do it yourself, or find people who can, and tempt them do it for you. And "people who can" do not have to be necessarily gurus.

A good strategy to do b. is to demonstrate the need in concrete terms; post your attempt at the problem, even though it may not be elegant or inclusion quality, and explain what you are trying to achieve. Code, sample output, or even imaginary transcript is worth thousands words to explain what you are trying to do. Then, describe how much your attempt solves and what you find lacking in it (iow what more is needed in the output from your failed attempt to make you happy).

This has three possible outcome. (1) Somebody might do it; (2) Somebody might do it better than you imagined possible; (3) Somebody might explain why it is a bad approach to do the way you described, make you realize that what you initially thought was "the need" was merely one possible approach (and not optimal one) to solve a higher level problem you were ultimately trying to solve, and teach you a better way to solve that problem.

On the other hand, a poor strategy is to say things like these:

 - Other system X does it.

   (If you are content with system X, we are happy.  We won't
   force you to use git and suffer from the lack of that
   feature.)

 - You would want more users, wouldn't you?

   (Not necessarily.  World domination might happen as a side
   effect of being the best system in the field, but it is not
   our goal by itself.)

 - Our project cannot use git unless you have this and that.

   (Tough.)       

without saying "if we had this, git can be more useful in such and such scenario, and it is applicable not only this situation but here and there."

On Tuesday 2007 April 24, Junio C Hamano wrote:

Wow - I feel useful now :-) my current "niggles" list is so small that it's not worth writing down - is git approaching perfection?

Coincidentally, I was reading through my git-versus-svn post, and found that similarly an awful lot of the issues for git had gone away. I found it remarkable that it had happened so fast.

It actually makes it harder for a potential reporter to keep up - git moves forward so quickly, that if you blink you've missed five new features going in.

Andy

Hi,

On Tue, 24 Apr 2007, Andy Parkins wrote:

Wow. Now that's a wow, isn't it?

Could you post what is left on your list? And maybe - just for my personal amusement - the ticked-off list?

Ciao, Dscho

Hi,

On Mon, 23 Apr 2007, Junio C Hamano wrote:

I used to issue `git log -p todo -- TODO` quite a lot; thank you!

And I miss kernel and git cousins, too...

Ciao, Dscho

On Tue, 24 Apr 2007, Johannes Schindelin wrote:

Why not have the TODO list in the source branches, listing features that ought to be in that version but aren't? That way, people can submit feature requests as patches that add to the todo list (and the requested feature can be discussed in response), and patches that implement features can simultaneously remove them from the todo list. Anyone considering working on adding desired features would need an up-to-date repository anyway.

	-Daniel
*This .sig left intentionally blank*

Hi,

On Tue, 24 Apr 2007, Daniel Barkalow wrote:

Like Junio said, it is not starting it, but maintaining. (BTW Andy, I am still waiting for that list...)

Judging from my own failings in updating the documentation when doing patches, I have no doubt I would miss out on the TODO, too.

Ciao, Dscho

On Tuesday 2007, April 24, Johannes Schindelin wrote:

Ask and ye shall receive. I had to make it look pretty first didn't I? Couldn't just send you any old rubbish.

The only remaining things are hardly worth worrying about or weren't accepted any way.

Enjoy.

---------------------------------------------------------- ADP niggle list ===============

 * git-revert should be called git-invert.  It doesn't remove a change
   from history, it simply applies another commit that does the
   opposite of whatever commit you are "revert"ing.  That's an inversion.
 * git-branch is not verbose enough when creating a new branch, for a new user
   a little reassurance that what they meant to happen has happened would be
   nice.
 * git-fetch output is confusing:
    remote: Generating pack...
    remote: Done counting 189146 objects.
    remote: Result has 186566 objects.
    remote: Deltifying 186566 objects.
    remote:  100% (186566/186566) done
    Unpacking 186566 objects
    24% (44792/186566) done
   Some questions from the point of view of a newbie: what is a pack?  what is
   an object? Why is the remote counting them?  Which remote am I reading
   from?  What am I fetching?  What is "Deltifying"?  How much data do I have
   to download (number of objects doesn't tell me).  How long has this taken?
   How long is left to go?
 * Similar things can be said about git-clone
 * Similar things can be said about git-push
 * git-show-branch output is cryptic.

Not accepted by list --------------------

 * git-apply output is horrible.  It says a few things about whitespace on
   stdin then just finishes.  When it succeeds.   When it fails, it just says
   failed, it doesn't say why a particular hunk failed.
 * git-rebase/git-cherry-pick/git-reset/etc should all tell the user that they
   need to run git-prune to tidy up after themselves.
 * git-add has no output, whether it works or not
 * git-cat-file is badly named.  git-cat-object would be slightly
   better.
 * In general the principle for messages should be the same as for
   presentations:
    - say what you're going to do
    - do it
    - say what you did
   So for example, "git-branch newbranch existingbranch" would say
    Branching at "existingbranch", hash XXXXXXXXXXXXXXXXXX
     - created branch "newbranch"
     - your working branch is "existingbranch"
   Rather than the nothing that it currently outputs.

Accepted but unimplemented --------------------------

 * git-rebase --skip requires that the offending file be clean with
     git-checkout HEAD file
   before the skip will work.  Why?  The fact of the skip is enough
   knowledge for rebase to know that I don't care if the merge is lost

Fixed -----

 * Apart from a little convenience of being able to add trees, I'm not
   really sure that git-add is different from git-update-index --add

   git-add is now more powerful and can replace update-index

 * We should never have to see git-update-index; instead git-rm, git-mv
   and git-add would take its place.  git-add would get new functionality
   where it can be used on already tracked files and hence would be renamed
   to, say git-prepare.

   git-add is now more powerful and can replace update-index.

 * git-fetch has to be in working root.  If I can do git-push from anywhere in
   my tree, why can't I do git-fetch?

 * git-reset has to be in working root.  If you typically sit in, say "src/",
   it's annoying to have to change directory to do a reset.

 * git-verify-tag would be nicer as a switch to git-tag

 * git-commit doesn't (generally) have output - after a commit, it's difficult
   to know if anything happened.  Get users used to the idea of hashes to
   identify commits by telling them which one they just made.  Tell them if
   they made a branch as well, which branch they are now on.

 * git-init-db says "defaulting to local storage area", as if that is
   meant to be a helpful message.

 * git-commit without "-a" and without an "update-index" says "nothing
   to commit", which isn't an adequate message to help a user who hasn't
   realised they need to update the index

 * git-merge output is horrible - this affects git-pull, git-rebase,
   and git-cherry-pick.  Issuing "fatal" errors and then carrying on is very
   confusing.  Errors in merges appear multiple times.  The files upon which
   which there is a conflict are spread throughout the output.  Most of the
   output is not relevant to an average user.

 * It would be really nice to be able to do an arbitrary checkout, rather than
   having to make a branch for it.  Then I could do
    git-checkout remotes/origin/master && make
   (obviously committing with a non-branch HEAD would be prevented).
   I think this is going to be a pre-requisite for submodule support

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I took another look of my todo:TODO list, and realized that actually it is not too bad.

I pushed out an update with recent items.