git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Daniel Barkalow <barkalow@iabervon.org>,
	Junio C Hamano <junkio@cox.net>, Yakov Lerner <iler.ml@gmail.com>
Subject: Re: git todo-list ?
Date: Tue, 24 Apr 2007 20:24:22 +0100	[thread overview]
Message-ID: <200704242024.28010.andyparkins@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0704242028350.6954@racer.site>

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

  reply	other threads:[~2007-04-24 19:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-23 22:44 git todo-list ? Yakov Lerner
2007-04-23 22:48 ` Junio C Hamano
2007-04-24  0:19   ` Jakub Narebski
2007-04-24  0:54   ` Junio C Hamano
2007-04-24  7:22     ` Andy Parkins
2007-04-24 10:33       ` Junio C Hamano
2007-04-24 11:10         ` Andy Parkins
2007-04-24 14:54           ` Johannes Schindelin
2007-04-24 15:02     ` Johannes Schindelin
2007-04-24 17:21       ` Daniel Barkalow
2007-04-24 18:29         ` Johannes Schindelin
2007-04-24 19:24           ` Andy Parkins [this message]
2007-04-24 20:05       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200704242024.28010.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=iler.ml@gmail.com \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).