git todo-list ?

git todo-list ?

[Yakov Lerner]

Junio C Hamano wrote:
> In earlier days, people
> complained about lack of features and existence of misfeatures,
> and bashed the maintainer with patches.  These days, the bashing
> is done with more words and less patches.

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

Re: git todo-list ?

[Junio C Hamano]

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

> Does git have todo-list ?

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/

Re: git todo-list ?

[Jakub Narebski]

Junio C Hamano wrote:

> "Yakov Lerner" <iler.ml@gmail.com> writes:
> 
>> Does git have todo-list ?
> 
> 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/

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.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git todo-list ?

[Junio C Hamano]

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

> "Yakov Lerner" <iler.ml@gmail.com> writes:
>
>> Does git have todo-list ?
>
> We could start one with an entry:
>
> 	- create a initial set of to-do-list and find a
>           volunteer to maintain it.
>
> perhaps at wiki.or.cz/

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.

Re: git todo-list ?

[Andy Parkins]

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

> 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

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).

> 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

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


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: git todo-list ?

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

> 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.

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.

> 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 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."

Re: git todo-list ?

[Andy Parkins]

On Tuesday 2007 April 24, Junio C Hamano wrote:

> 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.

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
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: git todo-list ?

[Johannes Schindelin]

Hi,

On Tue, 24 Apr 2007, Andy Parkins wrote:

> On Tuesday 2007 April 24, Junio C Hamano wrote:
> 
> > 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.
> 
> 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.

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

Re: git todo-list ?

[Johannes Schindelin]

Hi,

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

> 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.

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

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

Ciao,
Dscho

Re: git todo-list ?

[Daniel Barkalow]

On Tue, 24 Apr 2007, Johannes Schindelin wrote:

> Hi,
> 
> On Mon, 23 Apr 2007, Junio C Hamano wrote:
> 
> > 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.
> 
> I used to issue `git log -p todo -- TODO` quite a lot; thank you!
> 
> And I miss kernel and git cousins, too...

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*

Re: git todo-list ?

[Johannes Schindelin]

Hi,

On Tue, 24 Apr 2007, Daniel Barkalow wrote:

> On Tue, 24 Apr 2007, Johannes Schindelin wrote:
> 
> > Hi,
> > 
> > On Mon, 23 Apr 2007, Junio C Hamano wrote:
> > 
> > > 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.
> > 
> > I used to issue `git log -p todo -- TODO` quite a lot; thank you!
> > 
> > And I miss kernel and git cousins, too...
> 
> 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.

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

Re: git todo-list ?

[Andy Parkins]

On Tuesday 2007, April 24, Johannes Schindelin wrote:

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

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





-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: git todo-list ?

[Junio C Hamano]

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

> On Mon, 23 Apr 2007, Junio C Hamano wrote:
>
>> 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.
>
> I used to issue `git log -p todo -- TODO` quite a lot; thank you!

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.