Re: What's in git.git (stable)

We have a handful fixes on 'maint'; I will be cutting v1.4.4.3 by the end of the week.

On the 'master' front, this round has many topics (most of which have been cooking in the 'next' branch) merged since the last announcement.

 - Johannes Schindelin's built-in shortlog is in.

 - Johannes Schindelin's built-in 'RCS merge replacement' is
   in.  Hopefully this would make merge-recursive more portable
   and faster.

 - Shawn Pearce and Johannes Schindelin spotted and fixed a few
   corner cases in merge-recursive.

 - Updates to gitk from Paul Mackerras to fix longstanding menu
   issues on Mac OS X.

 - Eric Wong fixed use of rerere in many places.

 - Eric also has quite a few fixes to git-svn.

 - Nico updated 'git-add' to really mean 'add contents', not
   'add to the set of tracked paths'.  Also updated was the
   documentation for 'git commit' to make it easier to teach new
   people after a long discussion.

 - Lars Hjemli taught 'git-branch' to rename branches.

 - Andy Parkins taught 'git-branch' to be colorful.

 - Robin Rosenberg improved cvsexportcommit for unusual
   pathnames.

 - 'git push $URL :refs/tags/that' (notice the colon) can be
   used to delete 'that' tag from the remote repository; this
   needs the latest git on both ends.

 - branch."master".{remote,merge} configuration items are set up
   by 'git-clone', thanks to Andy Parkins.

 - 'git-commit' gives 'diff --summary' output to remind mode
   changes and added/deleted files.

 - 'git-diff --numstat' matches 'git-apply --numstat' when
   talking about binary changes.

 - 'git-merge' is now a first class UI, not just a mere driver
   for strategies.

I am hoping that we can start a stabilization cycle for v1.5.0 based on what we have in 'master'. The theme is "usability and teachability".

Things that need to be done to complete what have been merged to 'master' are:

 - 'git-rm' needs to be fixed up as Linus outlined; remove
   working tree file and index entry but have a sanity check to
   make sure the working tree file match the index and HEAD.

 - 'git-branch' may need to be taught about renaming the
   matching per-branch configuration at the same time.

 - 'git-merge-file' needs to be documented and linked from
   git.txt.

 - 'git-clone' probably should be updated to use wild-card in
   remote.origin.fetch, instead of listing all the branches it
   found when the clone was made.

 - tutorials and other Porcelain documentation pages need to be
   updated to match the updated 'git-add' and 'git-rm' (to be
   updated), and their description should be made much less
   about implementation; they should talk in terms of end-user
   workflows.  I will send a draft for 'git diff' out later, but
   somebody needs a full sweep on Porcelain-ish documentation.

 - 'git diff --index' patch should be reverted (already done in
   'next'), although we may have to come up with a better
   wording for --cached.

----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.4.4.2.

   Alex Riesen (1):
      Clarify fetch error for missing objects.

   Brian Gernhardt (1):
      Move Fink and Ports check to after config file

   Chris Wright (1):
      no need to install manpages as executable

   Eric Wong (2):
      git-svn: exit with status 1 for test failures
      git-svn: correctly display fatal() error messages

   Jim Meyering (1):
      Don't use memcpy when source and dest. buffers may overlap

   Martin Langhoff (1):
      cvsserver: Avoid miscounting bytes in Perl v5.8.x

   Shawn O. Pearce (1):
      Make sure the empty tree exists when needed in merge-recursive.

* The 'master' branch has these since the last announcement.

   Alex Riesen (3):
      git-blame: fix rev parameter handling.
      Make perl/ build procedure ActiveState friendly.
      Clarify fetch error for missing objects.

   Andreas Ericsson (2):
      ls-files: Give hints when errors happen.
      git-diff: Introduce --index and deprecate --cached.

   Andy Parkins (6):
      Use .git/config for storing "origin" shortcut repository
      Document git-repo-config --bool/--int options.
      De-emphasise the symbolic link documentation.
      Explicitly add the default "git pull" behaviour to .git/config on clone
      Colourise git-branch output
      Allow subcommand.color and color.subcommand color configuration

   Brian Gernhardt (1):
      Move Fink and Ports check to after config file

   Chris Wright (1):
      no need to install manpages as executable

   David Miller (1):
      Pass -M to diff in request-pull

   Eric Wong (21):
      git-svn: use ~/.subversion config files when using SVN:: libraries
      git-svn: enable delta transfers during fetches when using SVN:: libs
      git-svn: update tests for recent changes
      git-svn: error out when the SVN connection fails during a fetch
      git-svn: fix output reporting from the delta fetcher
      git-svn: color support for the log command
      git-svn: documentation updates
      git-svn: fix multi-init
      git-svn: avoid fetching files twice in the same revision
      git-svn: avoid network timeouts for long-running fetches
      git-svn: extra error check to ensure we open a file correctly
      git-svn: use do_switch for --follow-parent if the SVN library supports it
      rerere: add clear, diff, and status commands
      rerere: record (or avoid misrecording) resolved, skipped or aborted rebase/am
      git-svn: enable logging of information not supported by git
      git-svn: allow dcommit to take an alternate head
      git-svn: correctly display fatal() error messages
      git-svn: correctly handle packed-refs in refs/remotes/
      git-svn: exit with status 1 for test failures
      git-svn: correctly display fatal() error messages
      git-svn: correctly handle "(no author)" when using an authors file

   Han-Wen Nienhuys (1):
      ident.c: Trim hint printed when gecos is empty.

   J. Bruce Fields (4):
      cvs-migration: improved section titles, better push/commit explanation
      Documentation: reorganize cvs-migration.txt
      Documentation: update git-clone man page with new behavior
      Documentation: simpler shared repository creation

   Jakub Narebski (4):
      gitweb: Fix Atom feed <logo>: it is $logo, not $logo_url
      git-clone: Rename --use-immingled-remote option to --no-separate-remote
      Document git-diff whitespace flags -b and -w
      gitweb: Allow PNG, GIF, JPEG images to be displayed in "blob" view

   Jeff King (1):
      shortlog: fix segfault on empty authorname

   Jim Meyering (2):
      Set permissions of each new file before "cvs add"ing it.
      Don't use memcpy when source and dest. buffers may overlap

   Johannes Schindelin (18):
      Build in shortlog
      shortlog: do not crash on parsing "[PATCH"
      shortlog: read mailmap from ./.mailmap again
      shortlog: handle email addresses case-insensitively
      shortlog: fix "-n"
      shortlog: use pager
      sha1_object_info(): be consistent with read_sha1_file()
      xdiff: add xdl_merge()
      xdl_merge(): fix an off-by-one bug
      xdl_merge(): fix thinko
      git-mv: search more precisely for source directory in index
      diff -b: ignore whitespace at end of line
      xdl_merge(): fix and simplify conflict handling
      cvs-migration document: make the need for "push" more obvious
      Add builtin merge-file, a minimal replacement for RCS merge
      merge-file: support -p and -q; fix compile warnings
      Get rid of the dependency on RCS' merge program
      merge-recursive: add/add really is modify/modify with an empty base

   Josef Weidendorfer (1):
      Add branch.*.merge warning and documentation update

   Junio C Hamano (45):
      Store peeled refs in packed-refs file.
      remove merge-recursive-old
      git-merge: make it usable as the first class UI
      merge: allow merging into a yet-to-be-born branch.
      Store peeled refs in packed-refs (take 2).
      git-fetch: reuse ls-remote result.
      git-fetch: fix dumb protocol transport to fetch from pack-pruned ref
      git-fetch: allow glob pattern in refspec
      Allow git push to delete remote ref.
      git-shortlog: fix common repository prefix abbreviation.
      git-shortlog: make common repository prefix configurable with .mailmap
      git-commit: show --summary after successful commit.
      git-fetch: allow forcing glob pattern in refspec
      fetch-pack: do not barf when duplicate re patterns are given
      git-merge: tighten error checking.
      git-merge: do not leak rev-parse output used for checking internally.
      cvsimport: style fixup.
      git blame -C: fix output format tweaks when crossing file boundary.
      tutorial: talk about user.name early and don't start with commit -a
      git-merge: fix confusion between tag and branch
      xmerge: make return value from xdl_merge() more usable.
      merge-recursive: use xdl_merge().
      receive-pack: do not insist on fast-forward outside refs/heads/
      unpack-trees: make sure "df_conflict_entry.name" is NUL terminated.
      read-tree: further loosen "working file will be lost" check.
      Loosen "working file will be lost" check in Porcelain-ish
      read-tree: document --exclude-per-directory
      git-reset to remove "$GIT_DIR/MERGE_MSG"
      git-merge: squelch needless error message.
      git-merge: fix "fix confusion between tag and branch" for real
      Fix perl/ build.
      git-rerere: add 'gc' command.
      Documentation/git-commit: rewrite to make it more end-user friendly.
      git-commit: allow --only to lose what was staged earlier.
      shortlog: remove "[PATCH]" prefix from shortlog output
      shortlog: fix segfault on empty authorname
      diff --numstat: show binary with '-' to match "apply --numstat"
      add test case for recursive merge
      git-push: document removal of remote ref with :<dst> pathspec
      git merge: reword failure message.
      spurious .sp in manpages
      git-push: accept tag <tag> as advertised.
      send-pack: tighten checks for remote names
      branch --color: change default color selection.
      config documentation: group color items together.

   Lars Hjemli (3):
      git-branch: add options and tests for branch renaming
      rename_ref: use lstat(2) when testing for symlink
      git-branch: let caller specify logmsg

   Martin Langhoff (1):
      cvsserver: Avoid miscounting bytes in Perl v5.8.x

   Michael Loeffler (1):
      git-fetch: ignore dereferenced tags in expand_refs_wildcard

   Nicolas Pitre (4):
      builtin git-shortlog is broken
      pack-objects: remove redundent status information
      make 'git add' a first class user friendly interface to the index
      change the unpack limit treshold to a saner value

   Paul Mackerras (1):
      gitk: Fix enabling/disabling of menu items on Mac OS X

   René Scharfe (1):
      shortlog: remove range check

   Robin Rosenberg (1):
      Make cvsexportcommit work with filenames with spaces and non-ascii characters.

   Sean Estabrooks (1):
      Update documentation to remove incorrect GIT_DIFF_OPTS example.

   Shawn O. Pearce (17):
      Teach git-completion.bash how to complete git-merge.
      Hide plumbing/transport commands from bash completion.
      Teach bash how to complete options for git-name-rev.
      Add current branch in PS1 support to git-completion.bash.
      Teach bash how to complete git-format-patch.
      Teach bash how to complete git-cherry-pick.
      Teach bash how to complete git-rebase.
      Teach bash about git log/show/whatchanged options.
      Support bash completion of refs/remote.
      Teach bash about git-repo-config.
      Support --strategy=x completion in addition to --strategy x.
      Cache the list of merge strategies and available commands during load.
      Teach bash about git-am/git-apply and their whitespace options.
      Teach bash how to complete long options for git-commit.
      Fix broken bash completion of local refs.
      Make sure the empty tree exists when needed in merge-recursive.
      Remove uncontested renamed files during merge.

   Uwe Zeisberger (1):
      Fix documentation copy&paste typo

On Wednesday 2006, December 13 21:35, Junio C Hamano wrote:

This is what I have in my "niggles" list. These are surface level things that I think are easy to fix. A large part of the scariness is (I think) git's unfriendly output. Too many messages require understanding of git internals.

The major barrier to implementing these sorts of changes is, I think, worries about users of the output of these commands in scripts. I say: screw them, porcelain is there for the breaking :-)

 * 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-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-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-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.
 * 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-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-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-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
 * 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.
 * 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.
 * 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.
 * 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)
 * git-verify-tag would be nicer as a switch to git-tag

Andy

Andy Parkins wrote:

Nice list, although I'd rather add extra output only if command is used with -v/--verbose (or -V/--verbose) option; if not, then add -q/--quiet (or -s/--silent) option to be used in scripts. I'm partial to --verbose solution, as advanced users are not interested in any output; they know the commands, and want them to be fast. C.f GNU tar: it outputs something only with -v/--verbose option.

On Wednesday 2006 December 13 22:48, Jakub Narebski wrote:

I'd rather have the scripts requiring "--quiet"; because otherwise it's another switch for a newbie to guess at. However, I don't think that switches is the answer. Output for these porcelain-level commands is not structured enough to be used in scripts anyway (e.g. git-pull), but what it does output is a confusing lump.

tar is doing a considerably less complicated sequence of operations than many of git's commands, so I don't think that's a fair comparison.

Also; I don't think "experts" should care about the extra output - I can't imagine that an extra few lines of text is going to slow git down. Further, I think the problem in most cases is that git outputs _too much_. Also, I'm not imagining that "git-add ." would list every file that it added - who is that going to help? It should say "added X files to index" or similar. You surely can't be arguing that that slows down your expert workflow?

I believe that a good set of output will be useful to both newbies and experts alike. The idea that experts don't like to know what's going on is simply not true. The idea that newbies want to see every file listed and every operation described is simply not true.

Andy

Andy Parkins <andyparkins@gmail.com> wrote:

git-commit-tree's "committing initial tree" and git-init-db's "defaulting to local storage area" are both probably too verbose and should just get removed.

The progress meters in git-pack-objects that you see during clone, repack, fetch and push at least keep the user amused. I do read the output of repack every so often, but in general I don't care about the output of clone, fetch or push - all I care about is that my objects got to the remote system and were accepted, or not. Which means that at least for me the output could be reduced down to just the bandwidth transfer meter, for really slow links.

But I'm not sure that git-add should output anything. Last I checked the 'mv' command in Linux doesn't say "Move 5 files" when I move 5 files into a directory. Likewise I don't think that knowing that 6781 files were added is useful, what if it should have really been 6782 files? I'm unlikely to know, care, or realize it.

Your niggle list (is that what you called it) has been useful fodder for discussion. I'm glad you took the time to write it up, and to argue it so well on the list. There's a number of items on it that I'd like to see happen too; enough that I may code some of them if nobody beats me to it.

On Thursday 2006 December 14 09:36, Shawn Pearce wrote:

That's a very particular example you've picked out there. Of course the user won't know if it should be 6781 or 6782; they might know if it should have been 2 or 10 though; 0 or 100. In your example, output like "about six and a half thousand", would probably be perfectly useful, but why not just output the number?

I'm glad it was useful. I never know how many disclaimers to put on these things. I always feel that every message I write should begin with "I love git and use it every day, so please don't take this the wrong way, but..."

Andy

On Thu, 14 Dec 2006, Shawn Pearce wrote:

git-add -v does output added files already.

Nicolas Pitre wrote:

Ha! Now only get it to accept --verbose as long alternative to -v option, and add -v/--verbose option to other similar commands (git-mv for example).

Andy Parkins <andyparkins@gmail.com> writes:

I like that ;-).

Thanks for the list. I'll comment only on no brainers. Things I cannot decide to agree or disagree are not mentioned in this message.

True and true and true; let's make them happen.

I am moderately against making a command verbosely report when it did exactly what it was told to do, _unless_ the command is expected to take longer than other commands in git suite, or it is something the user rarely runs.

The same comment applies here.  

However, perhaps you could make lack of "[user] expert = true" in ~/.gitconfig to trigger more verbose messages that say "yes sir I did what I was told to do".

Not interested in implementing that myself at all, though.

I think you are talking about "checkout -b" not commit here; this might be a borderline (branch creation is less often done and it might warrant assuring feedback), but I think it still falls into the "doing exactly what it was told to do" category.

It probably used to be back when the original tutorial Linus wrote was still called tutorial.txt; but I agree that the message is not helpful anymore.

Yes.

No. It either says patch is corrupt, or a hunk at this line does not apply. I do not see what more would you would want to ask it to say.

Perhaps.

"\n(hint: 'git add' to stage your changes, or 'git commit --all')\n" in wt-status.c under "[user] expert = false" mode?

As long as your solution does not accidentally lose local, unrelated changes, changing "git-rebase --skip" to do the needed clean-up itself for the user would be Ok (I think we would want to loosen the requirement for starting in a totally clean working tree in the future).

While I agree the users need to be taught about 'prune', I do think immediately after running the above commands is exactly the wrong point to run 'prune'. 'prune' should not be run while you are busily munging the tip of the branch with rebase and reset to come up with something that you can call "oh, I am done with this series for now." Otherwise even lost-found would not be able to help you.

Also, this sequence creates crufts that need to be pruned:

	edit hello.c
	git add hello.c
        edit hello.c
        git add hello.c

I do not think we would want to suggest 'git prune' upon every 'git add'.

"git add no-such-file" complains, and I think that is adequate. Now with Nico's 'add means adding contents, not path' change is in, we _might_ want to differentiate adding a path that was untracked before and updating the contents, but I think this again falls into "doing exactly as told" category.

Not a Porcelain.

We might want to add a pair of built-in internal aliases though:

	[alias]
        	cat = cat-file -p
                less = -p cat-file -p

or have these as samples in template .git/config file.

In general the principle ought to be not to say anything if the command does exactly what it was told to do successfully, unless the operation is expected to take longer than other normal commands in the git suite, or something that is rarely used.

Perhaps under "[user] expert" control.

Yes. checkout -b works. But only _if_ you have read the manpage. Someone thinking about branching at the current commit would just have

	git branch

in mind (so would I). Its not obvious to say

	git checkout -b <newbranchname> oldbranch

becouse checkout implies to advance to another version.

-Peter

Hi,

On Wed, 13 Dec 2006, Junio C Hamano wrote:

I sent a patch which makes "git show" have that functionality, and frankly, I disagree "less" would be a good name for it. It uses the _pager_, which is not always "less", and besides, what it does is to show that particular blob. So obviously, I think my patch is the best approach.

BTW if you now say "git show master:README" it will show _nothing_, not even an error message.

Ciao,

On Thu, 14 Dec 2006, Johannes Schindelin wrote:

I think your approach is pretty sensible too.

Nicolas Pitre <nico@cam.org> writes:

I think so too for a few reasons.

 * cat-file is a very low level plumbing.  Giving it -p was a
   mistake made by somebody lazy long time ago back when we were
   not all that hot about "user friendliness in Porcelain-ish"
   (the option -p was not originally even meant to be the user
   level; it was merely a helper feature for verify-tag).

 * If we were to call something 'cat' and make a user-level
   command, adding the feature to 'show' is a lot more sensible
   than cat-file; the former takes more than one args already.
   People expect 'cat' to concatenate the arguments.  cat-file
   doesn't.

 * Throwing ls-tree output is the most sensible thing to do at
   'cat-file -p <tree-ish>' level, but not at the UI level (Andy
   compared ls-tree with 'svn list' today).  With 'git show', it
   would be more natural to show ls-tree --name-only by default
   for tree-ish objects, and control the verbosity level with
   command line option.

One minor issue we may need to decide is what to do when show is given a tag object. Personally I think the current behaviour of dereferencing it to commit is fine (people who want to see the tag can always do 'git-verify-tag -v').

Hi,

On Wed, 13 Dec 2006, Junio C Hamano wrote:

How about adding the command line option "--tag" to git-show, which makes it only show that tag. I'd also vote for a "--verbose|-v" flag to show the contents of the tag _before_ showing the referenced object.

Ciao, Dscho

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

Sounds sensible.  Please make it so.

Hi,

On Thu, 14 Dec 2006, Junio C Hamano wrote:

Actually, I rethought it. A tag _without_ what it tags makes no sense. See my upcoming patch. And git-show really is as Porcelain as it gets, so it should Do What I Mean.

Ciao, Dscho

Junio C Hamano wrote:

Well, it should really let the user know if it fails. I for one would like to know that. I wasn't aware of the fact that it was silent even in those situations (perhaps because I've never run across it).

The errors that need to be reported are, afaics: Content in 'path/to/file' is ignored according to path/to/.gitignore. System error X happened while attempting Y. Hash collisions.

Hash collisions wouldn't be too bad to check for in git add, because it only has to compare a single object, although I agree that it probably isn't necessary.

Andreas Ericsson wrote:

This is not an error, just a warning. Sometimes user want's to add a file which is otherwise ignored (e.g. due to glob), sometimes user adds ignored file by mistake.

On Wednesday 2006 December 13 23:31, Junio C Hamano wrote:

I'm not sure "verbose" is the word for one extra line of output:

$ git commit Revision XXXXXXXXXXXXXXXXXX successfully added.

I'd actually argue that git-commit is a particular problem because it's too fast. You quit editing your commit message and bang, you're back at the command line. Then you run git-log to make sure it really was committed.

In the specific case of commit I really think the hash that was added needs to be printed. I often do a series of git-commits on separate files; to find out the hash of one of those recent commits I then hop over to qgit to look. If it were right there on my terminal I wouldn't need to have qgit open all the time.

Right back at you. "what it was told to do", is not a clear cut thing. Bear in mind that users make mistakes (I certainly do), so what I told it to do was not necessarily what I wanted it to do. With no output to tell me what actually happened, it makes it harder to go back and see what you did wrong.

I've always thought that programs that needed an expert/beginner split were badly designed.

I'm not sure you're characterising the messages correctly with "yes sir I did what I was told to do". That sort of output would truly be useless. However, going back to my git-commit example, I didn't say "commit and give this the hash XXXXXXXX", I said "commit". git makes up the hash for me, and so should really tell me that hash.

I've gotten a far more positive response than I'd expected, so it doesn't surprise me.

You're right, I was.  The reason I think feedback is useful is because of the 
two ways of making a new branch:
 - git-branch XYZ
   This makes a new branch but DOESN'T leave me on XYZ
 - git-commit -b XYZ
   This makes a new branch and switches to XYZ
I can't tell you the number of times I get this wrong.  It's not because I 
don't know if I stop to think, it's because I'm thinking about the project, 
not the VCS.

I've been building a repository that contains every kernel release since v1.0.0; I did it by downloading every patch and "git-apply"ing them one at a time. Along the way, I had a few occasions where the patch didn't apply. I would get the "hunk didn't apply" message. (e.g. v1.1/patch54.bz2 if you're interested)

Now - it /should/ apply, this is a published patch; I investigated each one, and it was always down to a whitespace problem. The current version didn't have the same whitespace as the patch was expecting; often part of a much larger patch which mostly applied. git-apply could have told me...

While applying hunk #17, the following update would not apply to the file this/that/theother.c -#endif +#endif

Instead I had to git-checkout HEAD; bzcat patch | git-apply --reject; find . -name "*.rej"; vim; git update-index; blah, blah blah.

Of course; never discarding data always takes precedence.

Absolutely; I wasn't suggesting that the message should say "now run git-prune"; otherwise we might as well run git-prune ourselves. I don't really know that the solution is; but I do think we need one.

git is its own worst enemy here I think. I still have doubts that something actually happened when I run commands because they return so quickly.

I think the problem with that is going to be that there will be disagreement about which commands should output what in which mode. "I like git-commit to tell me what it committed, but don't want git-add to list files" sorts of thing.

Andy

Andy Parkins <andyparkins@gmail.com> writes:

You keep repeating that you want to know the object name of the newly created commit. I would very strongly agree with you that it would be a fatal UI bug of git-commit if that information were vital for the end user after making each commit.

But you never communicate with your own git repository using the SHA-1 object names when talking about commits you made recently (you would have the SHA-1 output from your updated version of 'git commit' command on the screen or in your scrollbuffer for them -- you would need to refer to commits older than what your scrollbuffer has in different way anyway). Git gives branch~<n> notation, and commands like "git log --pretty=short" and friends would show them which you can easily cut&paste. When people talk about object names on the mailing list, they do so by asking "git log" and friends to find them out -- it is pretty much "on demand" type of thing and I do not think continually mentioning SHA-1 object names buys us anything.

In other words, the following transcript would be possible but not realistic:

	$ git commit
        Revision deadbeef0000 created.
        : now what did I do?
        $ git show deadbeef0000
        : oops, that is wrong
        $ git reset --hard deadbeef0000^

So I do not think "git commit" is a valid example. I also agree with Shawn that "git add" that says 6781 files were added is pointless.

There probably is a truth in that. Let's not add verbosity unnecessarily.

I agree with you that making some commands with progress indication less chatty would be a good clean-up.

On Thursday 2006 December 14 10:21, Junio C Hamano wrote:

Oh dear, you're right; I am terribly repetative. Sorry. Oh dear, you're right; I am terribly repetative. Sorry.

;-)

How's this then:

$ git commit $ git commit $ git commit $ git reset HEAD^^^

"AGGGHHHHHH!  I meant HEAD^^"

At this point I start running "git-prune -n | grep commit" and some liberal use of git-show to try and find the hash of the object so I can do

$ git reset --hard HASH_OF_OBJECT_I_STUPIDLY_ORPHANED

Okay.

My habit is always to be overly verbose in program output; however, I realise that not everybody likes that. None of these things cause me any difficulty in my use of git. However, my Dad also is an engineer, but he's not so comfortable with VCS; for him almost every part of git is a mystery. Commands that run and don't say anything are confusing because he didn't really know what they were /meant/ to do; he's just got a set of recipes that he knows to type. He's probably an extreme case, and not a good model for typical user - on the other hand, I would say that if he can use it, then it is officially newbie-friendly. :-)

These are actually the ones I feel more strongly about. Too much output just drowns out the information that people really need.

Andy

Andy Parkins <andyparkins@gmail.com> wrote:

At this point I usually try to politely suggest that users do:

  git repo-config --global core.logAllRefUpdates true

and in the future do something like:

  $ git reset HEAD@{4}

should give you what

  $ git reset HEAD^^

would have given had you not added the extra ^.  :-)
 

On Thu, 14 Dec 2006 06:45:46 -0500, Shawn Pearce wrote:

This when-you-first-learn-you-want-them-it's-too-late-to-get-them aspect of ref logs is really annoying. It sets up an unkind trap for users.

I know several people have suggested they be enabled by default. What's the status of that suggestion? Rejected? Just awaiting a patch?

-Carl

Carl Worth <cworth@cworth.org> wrote:

Yes.  Which is why its in my ~/.gitconfig.  :-(
 

Its been suggested and discussed.

But the problem raised is that there are many types of repositories, and not all should always have reflogs enabled, and its hard to tell which one should and which shouldn't by default, and its even worse to force it into a user's ~/.gitconfig as then repositories which should not have reflogs are getting them anyway.

 * Normal working repository (wants reflogs);
 * Bare private (backup) repository (wants reflogs);
 * Bare shared repository (probably doesn't want reflogs);
 * Import generated repository (probably doesn't want reflogs);

...

Find a way to make git-init-db know the difference magically and you'll probably see a patch emerge quickly afterwards. But right now I don't think anyone really has a great solution to the problem.

I know Junio wrote something on this not too long ago (and it was a good writeup too) but I can never find threads in gmane's archives, so I'm just going to leave that to someone else...

Hi,

On Thu, 14 Dec 2006, Shawn Pearce wrote:

In contrast, I think that reflogs make lots of sense for shared repos, and less sense for bare (non-shared) ones...

So, I'd say: enable reflog by default, unless it is bare _and_ not shared. But then, cmd_init_db() no longer knows if it was called with "--bare" or not.

Ciao, Dscho

On Thu, 14 Dec 2006, Shawn Pearce wrote:

Thank you for reminding me the reasons why.

However I'd argue that the lack of reflog data is much much worse than needlessly having it.

It is therefore much saner to disable it in the config and remove the unwanted reflog files than being sorry because it wasn't enabled when you would have needed it.

And what would be the actual problem if reflog was enabled (i.e. was not explicitly disabled if enabled by default) in those last two cases?

I'd say screw that.  The solution should really be this patch:

Nicolas Pitre <nico@cam.org> writes:

That changes what the command does to existing repositories, which is somewhat impolite.

I am not opposed too much to an updated version of the tool that sets the configuration on by default for newly created repositories, though.

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

Yes, but users are forgetting to enable them. They will work in a new repository having that feature, move to an older one and not have it, but expect it to be there.

As I recall the primary objection to enabling them by default when I first introduced them was that core.logAllRefUpdates=true meant that refs/tags/<name> were also being logged. This was not a great idea as tags generally did not change once they were created. You fixed that and now it just makes sense to enable it for branch heads all of the time.

I almost did that in my patch - but decided against it for the reason I just noted above.

Does anyone on the mailing list really have an objection to having reflogs on by default?

About the only trouble that can cause is a failed push when git-receive-pack needs to generate the reflog entry but cannot get the user's committer data because their gecos information doesn't exist.

On Thu, 14 Dec 2006, Shawn Pearce wrote:

I concur entirely.

I certainly don't.

Shawn Pearce wrote:

In that case, it would be best if it let the commit go through using only the username. Reflogs are fixable afterwards, so there's no real harm done.

Andreas Ericsson <ae@op5.se> writes:

This sounds sensible, regardless of the current discussion on the default 'logallrefupdates' setting.

Volunteers?

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

Its a good idea.  I'll do it later tonight, after dinner.

On Thu, 14 Dec 2006, Junio C Hamano wrote:

You must be kidding, aren't you?

Just in case you really are serious, let's pretend that being impolite for something that has the potential of saving people's arses is certainly worth it, much more that the little inconvenience of having log files mysteriously appear and make no harm otherwise.

Hmmm....

Well it is just that I strongly believe users with existing repos have no really valid reason to not have this feature enabled. But making it on in a default config file at repo creation time is better than nothing.

Nicolas Pitre <nico@cam.org> writes:

I am dead serious. I do not have _any_ issue on existing repositories with a working tree, but I care deeply about public distribution points. See my other message.

New and experienced Git users alike are finding out too late that they forgot to enable reflogs in the current repository, and cannot use the information stored within it to recover from an incorrectly entered command such as `git reset --hard HEAD^^^` when they really meant HEAD^^ (aka HEAD~2).

So enable reflogs by default in all future versions of Git, unless the user specifically disables it with:

  [core]
    logAllRefUpdates = false

in their .git/config or ~/.gitconfig.

Documentation was also updated to indicate the new default behavior. We probably should start to teach usuing the reflog to recover from mistakes in some of the tutorial material, as new users are likely to make a few along the way and will feel better knowing they can recover from them quickly and easily, without fsck-objects' lost+found features.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 Documentation/config.txt |    3 ++-
 environment.c            |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

On Thu, 14 Dec 2006, Shawn Pearce wrote:

And this is where I politely say that this option should be true by default for everybody.

I don't recall why it isn't so yet.

Shawn Pearce <spearce@spearce.org> writes:

Correct but a bad example that does not demonstrate the real power of reflog. Andy's AGGGHHHHHH can be recovered with a simple:

	$ git reset ORIG_HEAD

The real beauty of reflog is that you can usually count number of commands (not just commit) the way you did and recover with the @{n} syntax. With one caveat -- a porcelain might implement what it does as more than one transaction on the ref, in which case counting commands does not help. You need to first make sure the value of n in @{n} you thought is appropriate is really the one you want; you would always run "git show -s HEAD@{4}" before doing the recovering reset in practice, in other words.

And it is not very easy to view where ref was in each step with existing set of tools.

Not until the attached patch, which was very lightly tested. You would use it like this:

    $ git-show-branch --reflog next
    ! [next@{0}] Merge branch 'js/show' into next
     ! [next@{1}] Merge branch 'jc/cdup' into next
      ! [next@{2}] Merge branch 'master' into next
       ! [next@{3}] Merge branch 'jc/cdup' into next
    ----
    -    [next@{0}] Merge branch 'js/show' into next
    +    [next@{0}^2] git-show: grok blobs, trees and tags, too
    --   [next@{1}] Merge branch 'jc/cdup' into next
    ++   [next@{1}^2] git-reset [--mixed] <tree> [--] <paths>...
    ++   [next@{1}^2^] git-reset: make it work from within a subdirectory.
    ++   [next@{1}^2~2] git-fetch: make it work from within a subdirectory.
    ++   [next@{0}^2^] INSTALL: no need to have GNU diff installed
    --   [next@{0}^2~2] Merge branch 'maint'
    ++   [next@{0}^2~2^2] Bypass expensive content comparsion during...
       - [next@{3}] Merge branch 'jc/cdup' into next
       + [next@{3}^2] git-reset [--mixed] <tree> [--] <paths>...
       + [next@{3}^2^] git-reset: make it work from within a subdirectory.
       + [next@{3}^2~2] git-fetch: make it work from within a subdirectory.
       + [next@{3}^2~3] Bypass expensive content comparsion during re...
    ++ + [next@{0}^2~3] Update git-diff documentation
    -- - [next@{0}^2~4] Merge branch 'jc/diff--cached'
    ++ + [next@{0}^2~5] git-svn: allow both diff.color and color.diff
    ++ + [next@{0}^2~6] repacked packs should be read-only
    ---- [next@{2}] Merge branch 'master' into next

This shows the actual reflog from the 'next' branch on my primary repository. It shows that I did a merge of jc/cdup branch into 'next' to run tests at next@{3}, but later rewound that merge at next@{2} and merged the rebased jc/cdup again later at next@{1} [*1*].

[Footnote]

*1* Of course, I did all of the above rewinding and rebasing before pushing the result out, so the general public do not have to worry about rewinding and rebasing.

---

On Thursday 2006, December 14 21:58, Junio C Hamano wrote:

HAHA!  I knew reading this mailing list would pay off.

It amazes me that there is always an answer. It's almost becoming a pantomime - I say "well git can't do this", and you say "oh yes it can".

Andy

Andy Parkins wrote:

And it is mentioned in git-reset(1), although:

 * it would be nice to have example with ORIG_HEAD about how
   to recover from bad (wrong) git reset in EXAMPLES section.

 * it would be nice to mention that the first example can
   be now done with simply "edit; git commit -a --amend"
   instead of "git reset --soft HEAD^; edit; git commit -a -c ORIG_HEAD"
   (which can fail for merges).

Andy Parkins wrote:

By the way, could you use slightly smaller number of columns? TIA.

That is what reflog is for. By the way, is core.logAllRefUpdates set to "true" (or "heads") by default now?

Although I'm not against

  $ git commit -v
  Revision XXXXXXXXXXXXXXXXXX successfully added.
 
Notice -v/-verbose option.

And git-add has -v option (although not --verbose).

It would be nice to have some generic place in git config to specify default options to git commands (at least for interactive shell). It cannot be done using aliases. Perhaps defaults.<command> config variable?

On Fri, 15 Dec 2006, Jakub Narebski wrote:

I would say the alias facility has to be fixed then.

In bash you can alias "ls" to "ls -l" and it just works.

Nicolas Pitre wrote:

I think this is because git scripts that need a certain git command to work a certain way don't want some alias to kick in and destroy things for them. Shell-scripts would have the same problem if you alias "awk" to "grep" f.e., which is why prudent shell-scripters use the "unalias -a" thing.

Anyways, this should be largely solvable by inventing a "--no-aliases" switch to the git wrapper, or by the scripts calling the programs they need directly which, afaik, bypasses the alias logic. If it doesn't, it should.

On Fri, 15 Dec 2006, Andreas Ericsson wrote:

Wouldn't it be possible for aliases to be effective only when issued from an interactive shell? It is certainly true that aliases just make no sense in a script.

Nicolas Pitre <nico@cam.org> wrote:

Probably, but on Cygwin gitk needs to use 'git foo' to invoke a command, even if 'git-foo' exists, because 'git-foo' might be a shell script and the Cygwin wish process cannot execute shell scripts.

Worse it cannot pass down environment variables to git commands. So it may be a little hard to tell in the git wrapper we are being run from within gitk (or git-gui)...

Nicolas Pitre wrote:

Yes, but then aliases wouldn't work in one-liners, which would be a bit of a shame and pretty likely to cause some "interesting" bugreports. Perhaps an environment variable GIT_IGNORE_ALIAS=yes that git-scripts can set at the beginning of execution?

Hi,

On Fri, 15 Dec 2006, Nicolas Pitre wrote:

So, why not use bash aliases?

Frankly, what git aliases try to achieve is a little bit different from bash aliases. Bash knows exactly when a command is interactive, and has a clear advantage there. Git _cannot_ know.

Ciao, Dscho

On Thu, 14 Dec 2006, Junio C Hamano wrote:

I think this is not the point.

Of course the name of the newly created commit isn't _that_ important.

But so is the "Committing initial tree 5220388..." message.

And in the commit case, you are left with a blank screen and just a shell prompt after you quit the text editor for the log message, which is a bit worrisome. My initial reflex is not to think "ah it just did what I asked it" but rather "hmmm has it just crashed on me?"

Having a single line of feedback when a commit has completed would not be overly verbose and remove that impression of committing into a void I'd think.

Note that, as I said in another thread, I'm really not advocating for git-add to do the same. The git-add is a relatively simple and lightweight operation that has not the same impact as a commit has _conceptually_. It doesn't clear the screen for one thing so just returning to the shell prompt (unless -v is used) is plenty sufficient.

I'm following up with a patch to implement what I think should be done.

It is nicer to let the user know when a commit succeeded all the time, not only the first time. Also the commit sha1 is much more useful than the tree sha1 in this case.

This patch also introduces a -q switch to supress this message as well as the summary of created/deleted files.

Signed-off-by: Nicolas Pitre <nico@cam.org>

---

Nicolas Pitre <nico@cam.org> wrote:

I agree the commit sha1 is more useful than the tree sha1, but I'm not really sure its useful to show the commit sha1 post commit. If you want to show something the diffstat like what git merge does is better.

For one thing it confirms that git accepted the changes. For another it shows you *which* changes it accepted. Plus it responds just like git-merge or git-pull does.

Of course the meaning of the diffstat is entirely different in both cases; in the commit case its what has been recorded while in the merge case its not only what has been recorded into your current branch history but also what has been done to your working directory.

Shawn Pearce wrote:

diffstats can be huge though. I'd rather have those only with -v option.

Andreas Ericsson <ae@op5.se> wrote:

But they are on by default for pull/merge, and disabled by -n.

They are on to tell you what you just got during the pull/merge. If we want commit to confirm it did something successfully, I think having it confirm what it committed by way of diffstat makes a lot of sense.

Unfortunately -n is taken to mean --no-verify by git-commit, so we probably cannot repurpose it to mean --no-summary, like it is for merge/pull.

Shawn Pearce wrote:

Yes, but it makes sense for merges where you generally pull someone elses work or one of your topic branches because it gives a general feel for the amount of modifications and are a sort of conclusion. Commits are a different thing, because you should know what kind of changes you've just done. If you don't you have other problems. I for one run git diff quite frequently when I'm getting close to a commit to make sure I don't get only the changes I want. I imagine others do too, so getting a diffstat when issuing the actual commit would just be noisy and irritating.

Andreas Ericsson <ae@op5.se> wrote:

I do the same (diff a lot before commit) and thus find commit outputting anything at all to be noisy and irritating. Frankly the new

  git-diff-tree --summary --root --no-commit-id HEAD

that Junio put on the end is already irritating.

But it was added to help users verify that commit did what they thought it would (see 61f5cb7f). By the same token sometimes users accidentally commit files they didn't mean to, or forget to include files they meant to include. Showing a diffstat would also be a final sanity check for them.

Shawn Pearce wrote:

I could live with one line (Committed revision %d), but a diffstat is always 3 lines minimum, which might well turn out to be 2 lines more than I changed. That's way too noisy.

On Fri, 15 Dec 2006, Shawn Pearce wrote:

Make it with -v.

If the --summary is already irritating to you, imagine how a diffstat could be.

Shawn Pearce <spearce@spearce.org> writes:

The credit should go Pasky's way. Add/delete/mode are rarer events and reminding them is sensible.

We do not show the 'summary' when we are concluding a merge that conflicted. Otherwise you will be seeing other people's huge changes that was just brought in.

On Thu, 14 Dec 2006, Shawn Pearce wrote:

It is useful, even if it is not essential.

Since I believe it is a good thing to display _something_ by default (and not only with -v as suggested -- please see the reasoning I posted yesterday as to what should have some output and what shouldn't), it doesn't hurt to display the commit sha1 as well.

First it has the very desirable side effect of making the user slightly aware of how git identifies things. From the first commit a new user will notice that git doesn't use any incremental version number but a unique identifier that has nothing to do with sequence. It is not expected that people will start _using_ the information printed, but it will at least give a feel of how git works. And it is not like if the whole thing took multiple lines to be displayed.

Next it _might_ be used by people. The fact that it is there might turn to be useful. It is useful in the context of Documentation/tutorial-2.txt for one where the notion of objects and their relationship is explained based on the least amount of steps possible.

So in short I do think there should be something shown after a successful commit, and including the commit sha1 doesn't hurt.

I disagree. My patch does confirm that git accepted the change with only one line. As to which changes were accepted I think that when you do the commit you certainly have a pretty good idea already of what is going to be committed (you modified/added/removed files yourself, and by default git-commit provides you with a summary in the text editor for the commit message).

On Fri, 15 Dec 2006, Shawn Pearce wrote:

The pull/merge case is different. You are most likely to not know in advance what the overall changes will be. Of course you're supposed to know what you're pulling, but unlikely to know about the detail since what you merge is remote to your current working tree by definition, and even if you happen to be the one who did the changes in the other branch/repo, it is certainly not as fresh in your mind than the changes you did prior a commit.

And it is true that diffstat can be quite large. I wouldn't mind the diffstat to be added to the commit message summary in the text editor though. And displaying it when -v is used makes also a lot of sense. But not by default please.

Nicolas Pitre <nico@cam.org> wrote:

OK, two votes against diffstats by default in commit. Since I haven't written a patch for it yet consider it dropped. ;-)

Nicolas Pitre <nico@cam.org> writes:

I agree with everything you said in your message, including that commit object name might help as a learning aid.

We could give something like this, though, if we wanted to:

	$ git commit
        4 files changed, 17 insertions(+), 10 deletions(-)
        mode change 100755 => 100644 test.sh

On Fri, 15 Dec 2006, Junio C Hamano wrote:

Actually that would really be nice to have all the time for the diff --summary output whenever --stat is not provided. Or maybe a --shortstat option.

What about this (on top of my previous patch):

Signed-off-by: Nicolas Pitre <nico@cam.org>

---

Nicolas Pitre <nico@cam.org> writes:

Looks good.

Andy Parkins <andyparkins@gmail.com> writes:

This is interesting. You said "commit -b", were pointed out that you were talking about "checkout -b", and just after saying "yup, that is right, I was", you again say "commit -b".

Maybe the users often need this sequence (I personally don't, but others might):

	$ git checkout ;# or the previous day ended with a clean state
	$ edit edit hack
        $ git checkout -b XYZ ;# the changes are about different stuff
        $ git commit ;# commit the changes there
        $ git checkout master ;# or whatever branch you usually are on

and "git commit -b <newbranch>" might be a handy shortcut for the last three commands. I dunno.

And if we had such a variant of commit, then it is doing something unusual, so I would not oppose (actually I would probably favor) if the transcript went something like this:

	$ git commit -b XYZ -m "implement 'foo' subcommand" -a
	committed changes to newly created branch XYZ, back on 'master'.
	$ git show-branch master XYZ
        * [master] finishing touches to 'hello world'
         ! [XYZ] implement foo subcommand
        --
         + [XYZ] implement foo subcommand
        -- [master] finishing touches to 'hello world'
	$ exit

Earlier I said that the command should be silent if it did exactly what it was told to do with some 'unless'es.

 * If the command fails, we should report (no question).

 * If the command succeeds the usual way, staying silent is
   preferable, at least to me.

 * If the command can have more than one mode of successful
   outcome, stating success in which way is not a useless
   verbosity.  E.g. 'git merge' should probably tell you if it
   did a usual three-way or a fast-forward (if the difference
   matters).  Especially reporting an unusual case a bit more
   verbosely than usual is a good thing.

On Thursday 2006, December 14 21:22, Junio C Hamano wrote:

There truly is something wrong with me. Is there some sort of record for number of mistakes made in one thread? Have I won yet?

I'm not sure about your "commit -b"; is it wise to have /another/ way of making a branch? I mean - I'm clearly confused enough, have a heart :-)

Andy

Andy Parkins <andyparkins@gmail.com> writes:

I did not mean it that way. I only took it as a sign that maybe "first create and switch to a branch and then work and commit there, in separate steps", which is how git encourages things to be done, does not match people's mental model so well.

I said "commit -b <newbranch>" and deliberately avoided saying "commit -b <anybranch>", because I did not want to open another can of worms while we are discussing so many good things already, and my head can hold only a handful topics at once.

But people on the list (and #git channel) sometimes wished an easy way to help the following workflow.

 * I am in the middle of working on a new feature.  As a good
   git user, I am on a topic branch dedicated for that purpose.

 * While working on it, I find an obvious bug that I would not
   want to fix on the branch (the topic branch I am currently on
   is not about fixing that bug).

 * But I fix it in the working tree anyway, because otherwise I
   would forget.  It happens to be in an isolated file that my
   current topic does not need to modify (say, I was looking at
   a function in that file that my new feature needs to call and
   I wanted to study its calling convention. And I found a typo in
   the comment near the function).

 * The fix does not belong to the current topic, but can go to
   the 'master' branch straight.  It's a fix in the comment that
   cannot possibly break things, and I can/will test it later
   anyway.

 * So with the existing set of tools, I would go there, commit
   and then come back:

	$ git checkout [-m] master
        $ git commit -m 'fix typo in that-file' that-file
        $ git checkout [-m] topic

   But it might be faster to say:

   	$ git commit -b master -m 'fix typo in that-file' that-file

   to make a commit on the other branch and come back
   immediately afterwards.

 * In the same situation, when the 'master' is closed for some
   administrative reason (e.g. "deep freeze before a release and
   strict bugfixes and nothing else are allowed"), I would create
   a new 'typofix' branch and do the same.  I can rebase it
   later on 'master' when it reopens.

	$ git commit -b typofix -m 'fix typo in that-file' that-file

	... much later when master reopens ...
        $ git rebase --onto master topic typofix

It's just a possible typesaver, but I am likely not using it myself (my fingers are already trained to do the three command sequence dance).

I do agree that it adds one more way to do the same thing and would make the documentation noisier, potentially adding more to the confusion. So let's not go there.

On Thursday 2006 December 14 23:46, Junio C Hamano wrote:

Don't worry; I've got thicker skin than that. I was simply amazed at my lack of comprehension ability. :-)

Absolutely.  I'd agree that only <newbranch> is worth even considering.

I find myself swayed by this. This is indeed something that happens to me a lot. In certain circumstances I've been defeated by git because I couldn't switch to the other branch to make that quick commit because my local changes conflicted with that other branch. The solution I use is to commit the bug fix in the wrong branch, finish my current on-topic commit then rebase/reset/etc to put everything where it should be.

Yep. Although you've persuaded me with the above example, I think this is the correct path. It's not wise to add every bell and whistle just because we can. As long as there is /a/ way to achieve every task, that's good enough, we don't need every way to achieve every task. We might even argue that git's flexibility is what makes it harder to learn. It's similar to UNIX in that respect - hard to learn, easy to use.

Andy

So we prefer to tell users "You can do what you want with these 3 commands, since we don't want to confuse use with another option to do it with just 1"?

Andy Parkins <andyparkins@gmail.com> writes:

Just for the record, I do not necessarily agree. Committing a small and obvious change out of context to an existing branch makes just as much sense.

After all, with the example workflow in my message you responded to, after running the "commit -b typofix" (which creates a new branch) to record the first typo fix, I am sure that I would want to record the second typofix I would find while on my topic to go to the same typofix branch I previously created.

The 'can of worms' is that switching to an existing branch could fail with conflicts. Although "git checkout -m" can help sometimes, that is not something we would want to do in the middle of doing something else on a topic. That's why I do not think "commit -b <anybranch>" is a good idea.

Allowing the form for only a new branch makes an inconsistency that is hard to explain to new people, and that is why I am not in favor of having "commit -b <newbranch>" either.

One fix for this would be the idea I've proposed to have a new flag for "git checkout" to 'stash' the dirty state in the current branch before switching.

Then, there wouldn't be a problem to implement "commit -b <anybranch>" on top of the stashing checkout.

I think the only real problem with the idea of having dirty changes stashed in a branch is that git already allows dirty changes to be carried while switching to a branch, (with or without -m). And doing both of those at once would lead to an ugly new conflict situation, (where _neither_ of the conflicted states exist as exposed tree objects). Even if there were no conflict, it would mingle two different sets of local modifications, and that could be unkind as it might be hard for the user to separate them if they didn't want them mingled.

If someone were to pursue this idea, I think it would be reasonable to just make that case an error, "Cannot carry local modifications when checking out a branch with stashed modifications." That message could even suggest the user use the stash option to leave the local modifications behind when doing the checkout.

-Carl

Hi,

On Thu, 14 Dec 2006, Andy Parkins wrote:

Honestly, I do not see anything you have done wrong. After all, a good idea came from it.

I actually would _love_ that feature. Yeah, it's possible with existing git commands, but it would be _convenient_.

Ciao, Dscho

Hi,

On Wed, 13 Dec 2006, Andy Parkins wrote:

No. An inversion is the _opposite_. Not an undo.

Besides, The fact that revert _adds_ to history is a nice way to document that you reverted that change. And you can even explain in the commit message, why you did it.

IMHO it is better for a newbie to see that _something_ is happening. A newbie cannot, and does not want to, understand exactly what is going on.

So, think of it as our response to Windows' non-progress-bar: when you start up Windows, there is a progress-bar, except that it does not show progress, but a Knight Rider like movement, only indicating that it does something.

Ciao, Dscho

On Thursday 2006 December 14 00:22, Johannes Schindelin wrote:

That's what I'm saying, we are applying the opposite of the given commit - that commit is being inverted and applied again. It most certainly isn't an undo, because the original commit still exists. It's not a reversion because "reversion" is to regress to a previous time or state. In that sense git-revert is not doing what it says on the tin. A revert would be to remove all the revisions from now until the specified commit - i.e. what git-reset now does.

(Note: I don't think git-reset should be renamed, as it's possible to use git-reset to move a branch forward as well as backward).

I'm not disputing that the /operation/ is useful, I'm arguing that it is incorrectly named.

I'm not arguing that we should show nothing; I'm arguing that the something we do show should be more clear than what is now shown. The choice is therefore "show something confusing" or "show something clear".

"newbie" doesn't mean "idiot". Everybody wants to understand what is going on.

Given the choice between nothing and a non-progress "doing something" bar, I would of course pick the "doing something" bar. However, given the choice between a "doing something" bar and a progress bar, I'd rather have the progress bar.

Andy

Hi,

On Thu, 14 Dec 2006, Andy Parkins wrote:

Ahh! I get what you are thinking. I was talking about reverting a change from the _content's viewpoint_. I _never_ want to revert history (I am no politician, you know?)

I heartly disagree. I saw so many faces _begging_ me to just say _what_ to do, not _why_, and quickly, please.

If I have the choice between a "doing something" bar and a Windows Explorer "14 seconds left" bar showing the same message for two minutes, I'd rather have a Mars bar ;-)

Ciao, Dscho

On Thursday 2006 December 14 10:51, Johannes Schindelin wrote:

Gahhhhhhhhh!  Oh how I hate that window.

On this we can wholeheartedly agree. Unfortunately it's not just windows; most applications that have a progress bar go like this:

0%, ..., 0%,..., 0%,.., 1 , 2, 3, 4, 5, 6, 33%, ..., 33%, ..., 33%, 35, 36, 85%, ..., 85%, ..., 85%, ..., 99%, 100%, ..., 100%, ... (yes, I'm completely finished, but still working), ... 100%.

I reckon, unless the window with a progress bar in it has an ETA, then the progress should be an ETA itself. If it's not going to monotonically increase, then the "percentage" is meaningless.

Andy

Hi,

On Thu, 14 Dec 2006, Andy Parkins wrote:

And now you know one of the reasons we have no true progress bar.

Another reason is that it would be relatively expensive to calculate, since the total _size_ is not known beforehand (remember, the pack is calculated on the fly).

Yet another reason is that all estimates there are unstable by nature: the load of the server, the net load, the load of the client, the speed of packing and unpacking, and the luck if deltas can be reused, are all contributors to this unstability.

Ciao, Dscho

On Thursday 2006 December 14 11:27, Johannes Schindelin wrote:

Hmmm; just thinking out loud now... I used to calculate ETA's for simulations I ran that had similar problems - i.e. you don't know how long it takes until its done (it was with genetic programming function trees, and of course you don't know what operations will be in the next generations tree, so you can't estimate a time). I just showed "something" by doing a standard: how long did n/N take therefore N will take... then I plotted the error in the ETA after the simulation completed. Interestingly it was always a -exp(-x) shape. In other words it got more accurate towards the end (of course); which is exactly the sort of accuracy you would want. At the beginning you just want a broad "this will take a few hours" measure. Towards the end, you want to know "there is 1m50s remaining".

I wonder if the number of objects is a reasonable measure of progress. Let's say we're transferring 100,000 objects. Let's also say that the average size of objects is 100 bytes. Let's finally say that the object sizes are evenly distributed throughout the 100,000 objects. This would mean that the first 1,000 objects are just as representative as the last 1,000 objects; or any other randomly chosen 1,000 objects. In which case, the size of the first thousand objects would be approximately one hundredth the size of the total transfer. Volia: an estimate of the total size of the transfer.

Obviously this estimate would be continuously updated, and would become more accurate as more objects are transferred. The data rate would of course be based on only the previous X objects rather than the total transferred to take account of changing server conditions. From these ETA could be estimated.

Obviously the ETA is unstable, but it's only for giving users an idea of how long is left; not for strict accounting.

Andy

Andy Parkins <andyparkins@gmail.com> wrote:

Ah, but much like those stock scam emails, "prior performance does not predict future results"... The size of objects in the pack tends to be small up front (commits/trees) and larger in the back (blobs). The size distribution probably also gets more erratic near the back as the blob sizes may not follow a nice distribution.

E.g. I have a repository with a blob that is 23 MiB. But I also have some 5 MiB blobs, and then a very large number of relatively small blobs. That 23 MiB blob really gums up any estimate.

But as you state, its easy to refine it over time, and the closer we get to the end the more likely it is to be correct. Unless its that 23 MiB blob. As it takes up about 85% of that repository's pack.

On Thursday 2006 December 14 12:10, Shawn Pearce wrote:

Oh well; that pretty much settles it then.

I had imagined (foolishly), that most objects would be diffs, and would be similarly sized.

Scratch that.

Andy

On Thu, 14 Dec 2006, Andy Parkins wrote:

Well, people are used to say they've "reverted" a change. Although the command might appear slightly misnamed wrt its operation, it still does what most people are expecting from such a name.

On Thursday 2006, December 14 17:23, Nicolas Pitre wrote:

Actually , not only is git-revert misnamed, it doesn't match up with most other SCMs.

"svn revert" is git-reset. "bzr revert" is git-reset. "darcs revert" is git-reset. "hg revert" is git-reset. "svk revert" is git-reset. "monotone revert" is git-reset.

Most people must surely be expecting it to do what it does in every other SCM; as it doesn't my argument is that we should just drop the name "revert" and call it git-invert instead, which is more accurately named and doesn't conflict with the standard meaning.

Andy

Andy Parkins <andyparkins@gmail.com> wrote:

Agreed. I still don't know how to read its output. So I just don't use it. Ever. :-)

Shawn Pearce wrote:

And the way it uses it's options is even more cryptic, and differs from other similar commands. So I'd rather use qgit (or gitk, if gitk would correct the error with remembering wrong window size).

Jakub Narebski <jnareb@gmail.com> writes:

(Jakub, please do not drop people from cc: list; you were asked more than once).

Ok, so what's the action you guys are proposing?

 (1) show-branch output is cryptic and it does not do anything
     useful.  Drop it.

 (2) show-branch output is cryptic and I do not understand what
     it is trying to do.  Document it better.

 (3) While I agree what show-branch is trying to do is useful,
     its output is useless.  Instead of showing an example
     situation like this:

	[ picture here ]

     It should show the same situation like this:

	[ improved picture here ]

 (4) None of the above.

The same question goes for its input branch specification.

Personally, I find its input branch globbing very handy, and often wish that 'git branch' had a '--list' option that lists branches that match the glob pattern given on the command line, not just listing everything when no parameter is given.

Junio C Hamano wrote:

The problem is that I'm not subscribed to git mailing list; I usually
read it via GMane news<->mail interface, at
  nntp://news.gmane.org/gmane.comp.version-control.git
First, in this interface I have only the last author and not the full
Cc: list. Second, when I reply _both_ via email (adding authors if
necessary) and to news, people receiving my reply don't have (I guess)
git@vger.kernel.org in Cc: list, so sometimes the discussion drops off
the list. Third, if I add git mailing list address when replying via
mail, vger server blocks email from gmane stating

  Technical details of permanent failure:
  PERM_FAILURE: SMTP Error (state 9): 501 5.1.3 Path data: Had characters unsuitable for an rfc821-string

When email is sent _directly_ to me (i.e. I'm on Cc: list) I try to preserve Cc: list.

[...]

I'm just used to the way revisions are specified to other history viewers: git-log (via git-rev-list), gitk, qgit. git-show-branch is a bit odd man out here. "git-show-branch ref1 ref2 ref3" is (without --more=n) like

  git rev-list ref1 ref2 ref3 --not $(git merge-base ref1 ref2 ref3)

Which is handy for git-show-branch, but odd. Perhaps we should add --xor option to git rev list for the above, i.e.

  git rev-list A...B        == 
    == git rev-list A B --not $(git merge-base A B)
  git rev-list --xor A B C  ==
    == git rev-list A B C --not $(git merge-base A B C)   
 

 
It is odd (git branch not having --list with globbing) also because
'git tag' has globbing support.

Hi,

On Fri, 15 Dec 2006, Jakub Narebski wrote:

So subscribe. I am sure I lost quite some of your responses to my emails, _just_ because you happen to kill me from the Cc: list.

IOW if you expect answers, _please_ adher to net standards.

Ciao, Dscho

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

FWIW, I also read the list traffic through gmane news gateway.

I am subscribed and my mail filter drops the mails from the list into a dedicated mailbox, but that is purely for my own backup and I usually do not look at it otherwise.

Hi,

On Fri, 15 Dec 2006, Junio C Hamano wrote:

So, how do you tackle the problem Jakub evidently has, namely to reply to all the people who your reply refers to?

Ciao, Dscho

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

I do not "tackle".

I just tell Gnus to follow-up, which does not always do the right thing [*1*], and I just try to be careful and fix up To: and Cc: fields by hand as necessary. The time spent on that on my part is _worth_ spending than inconveniencing others.

It's just a common courtesy, not "tackling".

[Footnote]

*1* ... most likely because I haven't configured it to do the
right thing, and/or the sender or the gateway puts a wrong
Reply-To: or Mail-Followup-To: header and it ends up honoring
them.

Junio C Hamano wrote:

Interesting. I'd actually prefer people *remove* me from the CC list -- I find it annoying to get two copies of every message in threads I reply to. I'm already subscribed to the mailing list, so there's no point having me on the Cc line too. (Mind you, as annoyances go it's a pretty insignificant one.)

I can understand the case of people who aren't on the list wanting to get replies, but why does someone who *is* on the list want to be CCed? Is it just that there's no good way to tell in advance which category a given person falls into, so best to be on the safe side?

Steven Grimm <koreth@midwinter.com> writes:

There is no cheap and mechanical way to tell that for the sender, and even when the sender can tell, it is not polite to do so (see next paragraph), unless the recipient specifically ask for it. On the other hand, filtering duplicates at the recipient's end could be mechanically done without wasting the human time. And people's time tend to be a lot more expensive than machine time and the cost to send extra bits over the wire.

Some people (including me) prioritize e-mails and respond to messages that are addressed To: them first, then Cc: next, and finally the rest of the messages that came only through the mailng list. Dropping a recipient from the Cc: list, even when the sender knows that recipient is on the list, breaks this.

People can safely remove *themselves* from the CC: list when the mailing list they subscribe to are on the CC: list as well. This would interact with the prioritizing I mentioned above, but that is done as a choice by them as the recipient of the replies, so there is no problem in doing so.

Jakub Narebski <jnareb@gmail.com> writes:

I hate to sound harsh, but...

Then you do not understand show-branch at all. Not having to say the "--not merge-base" part is NOT about being handy, but is the central part of what show-branch does. The command is about showing the commits that are on only some of the branches but not on others.

Other commands you listed above are all based on rev-list logic of painting commits in two colors (either UNINTERESTING or ~UNINTERESTING) and being able to combine the set using "A..B", "^A B", and "A B --not C" notations all make sense. All combinations work as set operation -- start from union of commits reachable from positive (i.e. not prefixed with ^) refs, and subtract set of commits reachable from any negative ref.

What show-branch does cannot be expressed with that two-color logic; it needs to use N colors for N input refs. After digging from the tips deep enough, you would find the common merge-base and after that point it is not interesting to show anything anymore, and that is how it stops output.

This stops enumerating the set of branches found on the remote side when a clone was made in the configuration file. Instead, a single entry that maps each remote branch to the local tracking branch for the remote under the same name is created.

Doing it this way not only shortens the configuration file, but automatically adjusts to a new branch added on the remote side after the clone is made.

Unfortunately this cannot be done for the traditional layout, where we always need to special case the 'master' to 'origin' mapping within the local branch namespace. But that is Ok; it will be going away before v1.5.0.

We could also lose the "primary branch" mapping at the beginning, but that has to wait until we implement the "forbid 'git pull' when we do not have branch.$current.merge for the current branch" policy we earlier discussed. That should also be in v1.5.0

Signed-off-by: Junio C Hamano <junkio@cox.net>

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

 git-clone.sh |   47 ++++++++++++++++++++++++++++++-----------------
 1 files changed, 30 insertions(+), 17 deletions(-)

Everybody hated the pull behaviour of merging the first branch listed on remotes/* file (or remote.*.fetch config) into the current branch. This finally corrects that UI wart by forbidding "git pull" without an explicit branch name on the command line or branch.$current.merge for the current branch.

The matching change to git-clone was made to prepare the default branch.*.merge entry for the primary branch some time ago.

Signed-off-by: Junio C Hamano <junkio@cox.net>

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

  And this does exactly that.

 git-parse-remote.sh |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

Now we lost the "first refspec is the one that is merged by default" rule, there is no reason for clone to list the remote primary branch in the config file explicitly anymore.

We still need it for the traditional layout for other reasons, though.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 Next step will be to remove the traditional layout altogether.
 With the recent flurry of UI updates, I think it is sane to do
 that before v1.5.0; opinions?

 git-clone.sh |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

Finally.

The separate-remote layout is so much more organized than traditional and easier to work with especially when you need to deal with remote repositories with multiple branches and/or you need to deal with more than one remote repositories, and using traditional layout for new repositories simply does not make much sense.

Internally we still have code for 1:1 mappings to create a bare clone; that is a good thing and will not go away.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:

 And this drops it; modulo bugs, I think this is about it for
 v1.5.0 around this area.

 Documentation/git-clone.txt |   15 +----------
 git-clone.sh                |   58 +++++++++----------------------------------
 2 files changed, 13 insertions(+), 60 deletions(-)

On Sat, 16 Dec 2006, Junio C Hamano wrote:

Ahh, you said that yourself, and I hadn't even noticed that you already merged xdl_merge into master too.

So here's an "AOL high five": <me too>.

Hi,

On Sat, 16 Dec 2006, Junio C Hamano wrote:

Answering to all of your recent patches in this direction: I like it.

Originally, I thought that this would require more from me: I often synchronize my git repository (including topic branches) between different machines back and forth, via usb stick, and two different central machines. I use the script I sent in this mail:

http://article.gmane.org/gmane.comp.version-control.git/6956/

However, I just realized that I will not need the script anymore, what with the recent addition of wildcards to remote.<branch>.fetch. Good job!

Ciao, Dscho

On Sat, 16 Dec 2006, Junio C Hamano wrote:

Yay!

May I suggest also just merging the built-in 3-way merge, and just calling the resulting version 1.5.0?

With all the "git add" and documentation cleanups, and these kinds of fundamental changes in behaviour (not that anybody will hopefully _notice_, and if they do they'll hopefully just be grateful, but it's still conceptually a big step), I think it's definitely worth a new version number.

Maybe even "2.0", although since we're still backwards compatible in all ways that really matter, a major number might be too big a step.

Junio C Hamano wrote:

[...]

Does this deal with non-fast-forward branches like 'pu'? Does it add $head_points_at at the beginning, before glob... wait, this is not needed if there is branch.$head_points_at.merge. But perhaps it still would be better to have:

  [remote "origin"]
        url   = git://git.kernel.org/pub/scm/git/git.git
        fetch = refs/heads/master:refs/remotes/origin/master
        fetch = refs/heads/*:refs/remotes/origin/*
        fetch =+refs/heads/pu:refs/remotes/origin/pu

  [branch "master"]
        remote = origin
        merge  = refs/heads/master ;# full spec of remote branch

But this is very nice. Thanks.

I'm done with 2 out of the above six ("diff --index", and "clone") and a bit of the "documentation" item so far, and will go to bed now. Any takers for the remaining tasks while I'll be sleeping ;-)?

Most of this is derived from the documentation of RCS merge.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---

	On Sat, 16 Dec 2006, Junio C Hamano wrote:

	> >>  - 'git-merge-file' needs to be documented and linked from
	> >>    git.txt.

 Documentation/git-merge-file.txt |   92 ++++++++++++++++++++++++++++++++++++++
 Documentation/git.txt            |    3 +
 2 files changed, 95 insertions(+), 0 deletions(-)

Junio C Hamano wrote:

What about discussed but not implemented moving restriction on non-head refs from git-checkout (forbidding to checkout tags, remotes, and arbitrary commits like HEAD~n) to git-commit (allowing commiting only to heads refs)? Probably non-heads refs should be saved in HEAD as explicit sha1 of a commit; this way we wont run into situation where HEAD changed under us (because it was for example to remote branch, and we fetched since).

Jakub Narebski <jnareb@gmail.com> writes:

Did I miss a patch? ;-)

I've taken a look at it once, and it is usually easy to decide if we should allow or disallow manipulation of the HEAD at individual places that tries to look at it or modify it, but there are many places and giving reasonable error messages to all of the places we would want to disallow would be quite a lot of work. In other words, it is rather a wide-and-shallow change all over manipulators section of Porcelain. So from my point of view it is backburnered, but that does not mean I would object to a patch that does it cleanly ;-).