git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Git 1.0 Synopis (Draft v2)
@ 2005-07-27 10:01 Ryan Anderson
  2005-07-27 22:13 ` Junio C Hamano
  2005-07-29  8:29 ` Git 1.0 Synopis (Draft v3 Ryan Anderson
  0 siblings, 2 replies; 601+ messages in thread
From: Ryan Anderson @ 2005-07-27 10:01 UTC (permalink / raw)
  To: git

[This is still a draft, but I think I incorporated the suggestons from
the last attempt.]

Source Code Management with Git

Git, sometimes called "global information tracker", is a "directory
content manager".  Git has been designed to handle absolutely massive
projects with speed and efficiency, and the release of the 2.6.12 and
(soon) the 2.6.13 version of the Linux kernel would indicate that it
does this task well.

Git falls into the category of distributed source code management tools,
similar to Arch or Darcs (or, in the commercial world, BitKeeper).  Every Git
working directory is a full-fledged repository with full revision tracking
capabilities, not dependent on network access to a central server.

Git uses the SHA1 hash algorithm to provide a content-addressable pseudo
filesystem, complete with its own version of fsck.
  o Speed of use, both for the project maintainer, and the end-users, is
    a key development principle.
  o The history is stored as a directed acyclic graph, making long-lived
    branches and repeated merging simple.
  o A collection of related projects are building on the core Git project,
    either to provide an easier to use interface on top (StGit, Cogito, qgit,
    gitk, gitweb), or to take some of the underlying concepts and reimplement
    them directly into another system (Arch 2.0, Darcs-git).
  o Two, interchangeable, on-disk formats are used:
    o An efficient, packed format that saves spaced and network
      bandwidth.
    o An unpacked format, optimized for fast writes and incremental
      work.

To get a copy of Git:
	Daily snapshots are available at:
	http://www.codemonkey.org.uk/projects/git-snapshots/git/
	(Thanks to Dave Jones)

	Source tarballs and RPMs at:
	http://www.kernel.org/pub/software/scm/git/

	Deb packages at:
	<insert url here>

	Or via Git itself:
	git clone http://www.kernel.org/pub/scm/git/git.git/
	git clone rsync://rsync.kernel.org/pub/scm/git/git.git/
	(rsync is generally faster for an initial pull)

Git distributions contain a tutorial in the Documentation subdirectory.
Additionally, the Kernel-Hacker's Git Tutorial at
http://linux.yyz.us/git-howto.html may be useful.  (Thanks to Jeff Garzik for
that document)

Git development takes place on the Git mailing list.  To subscribe, send an
email with just "subscribe git" in the body to majordomo@vger.kernel.org.
Mailing list archives are available at http://marc.theaimsgroup.com/?l=git

Git results from the inspiration and frustration of Linus Torvalds, and
the enthusiastic help of over 300 participants on the development
mailing list.[1]  It is maintained by Junio C Hamano <junkio@cox.net>.

1 - Generated with the following, in a maildir folder:
        find . -type f | xargs grep -h "^From:" | perl -ne \
        'tr#A-Z#a-z#; m#<(.*)># && print $1,"\n";' | sort -u | wc -l

(This summary written by Ryan Anderson <ryan@michonline.com>.  Please bug him
with any corrections or complaints.)




-- 

Ryan Anderson
  sometimes Pug Majere

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v2)
  2005-07-27 10:01 Git 1.0 Synopis (Draft v2) Ryan Anderson
@ 2005-07-27 22:13 ` Junio C Hamano
  2005-07-29  8:27   ` Ryan Anderson
  2005-07-29  8:29 ` Git 1.0 Synopis (Draft v3 Ryan Anderson
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2005-07-27 22:13 UTC (permalink / raw)
  To: Ryan Anderson; +Cc: git

Ryan Anderson <ryan@michonline.com> writes:

> Source Code Management with Git

Thanks for doing this.  Generally looks excellent.

>   o Two, interchangeable, on-disk formats are used:
>     o An efficient, packed format that saves spaced and network
>       bandwidth.

??? "spaced" ???

> 	Or via Git itself:
> 	git clone http://www.kernel.org/pub/scm/git/git.git/
> 	git clone rsync://rsync.kernel.org/pub/scm/git/git.git/
> 	(rsync is generally faster for an initial pull)

These need a target directory name to create, like this:

    git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ $new_dir
    git clone http://www.kernel.org/pub/scm/git/git.git/ $new_dir

> Git results from the inspiration and frustration of Linus Torvalds, and
> the enthusiastic help of over 300 participants on the development
> mailing list.[1]  It is maintained by Junio C Hamano <junkio@cox.net>.

Please drop the e-mail address here; you mention nobody else's.

Well, dropping "the current maintainer" information altogether
might be even better; the above to a casual reader sounds like
Linus was frustrated and I wrote it for him, which is definitely
not what we would like to say.  I suspect it still has more code
by Linus than anybody else (I stopped counting some time ago).

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v2)
  2005-07-27 22:13 ` Junio C Hamano
@ 2005-07-29  8:27   ` Ryan Anderson
  0 siblings, 0 replies; 601+ messages in thread
From: Ryan Anderson @ 2005-07-29  8:27 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wed, Jul 27, 2005 at 03:13:18PM -0700, Junio C Hamano wrote:
> > Git results from the inspiration and frustration of Linus Torvalds, and
> > the enthusiastic help of over 300 participants on the development
> > mailing list.[1]  It is maintained by Junio C Hamano <junkio@cox.net>.
> 
> Please drop the e-mail address here; you mention nobody else's.
> 
> Well, dropping "the current maintainer" information altogether
> might be even better; the above to a casual reader sounds like
> Linus was frustrated and I wrote it for him, which is definitely
> not what we would like to say.  I suspect it still has more code
> by Linus than anybody else (I stopped counting some time ago).

Ok.  I was thinking I could add "current" into that description.  Or,
something like, "Linus has since returned his focus to the kernel, and
passed maintainership to ...".

-- 

Ryan Anderson
  sometimes Pug Majere

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Git 1.0 Synopis (Draft v3
  2005-07-27 10:01 Git 1.0 Synopis (Draft v2) Ryan Anderson
  2005-07-27 22:13 ` Junio C Hamano
@ 2005-07-29  8:29 ` Ryan Anderson
  2005-07-29 10:58   ` Johannes Schindelin
                     ` (2 more replies)
  1 sibling, 3 replies; 601+ messages in thread
From: Ryan Anderson @ 2005-07-29  8:29 UTC (permalink / raw)
  To: git


Source Code Management with Git

"git" can mean anything, depending on your mood.

 - random three-letter combination that is pronounceable, and not
   actually used by any common UNIX command.  The fact that it is a
   mispronunciation of "get" may or may not be relevant.
 - stupid. contemptible and despicable. simple. Take your pick from the
   dictionary of slang.
 - "global information tracker": you're in a good mood, and it actually
   works for you. Angels sing, and a light suddenly fills the room. 
 - "goddamn idiotic truckload of sh*t": when it breaks

Git is a "directory content manager".  Git has been designed to handle
absolutely massive projects with speed and efficiency, and the release of the
2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it
does this task well.

Git falls into the category of distributed source code management tools,
similar to Arch or Darcs (or, in the commercial world, BitKeeper).  Every Git
working directory is a full-fledged repository with full revision tracking
capabilities, not dependent on network access to a central server.

Git provides a content-addressable pseudo filesystem, complete with its own
version of fsck.

  o Speed of use, both for the project maintainer, and the end-users, is
    a key development principle.

  o The history is stored as a directed acyclic graph, making long-lived
    branches and repeated merging simple.

  o The core Git project considers itself to provide "plumbing" for other
     projects, as well as to serve to arbitrate for compatibility between them.
     The project built on top of the core Git are referred to as "porcelain".
     StGit, Cogito, qgit, gitk and gitweb are all building upon the core Git
     tools, and providing an easy to use interface to various pieces of
     functionality.

  o Some other projects have taken the concepts from the core Git project, and
    are either porting an existing toolset to use the Git tools, or
    reimplementing the concepts internally, to benefit from the performance
     improvements.  This includes both Arch 2.0, and Darcs-git.
  
  o Two, interchangeable, on-disk formats are used:
    o An efficient, packed format that saves space and network
      bandwidth.
    o An unpacked format, optimized for fast writes and incremental
      work.

To get a copy of Git:
	Daily snapshots are available at:
	http://www.codemonkey.org.uk/projects/git-snapshots/git/
	(Thanks to Dave Jones)

	Source tarballs and RPMs at:
	http://www.kernel.org/pub/software/scm/git/

	Deb packages at:
	<insert url here>

	Or via Git itself:
	git clone http://www.kernel.org/pub/scm/git/git.git/ <local directory>
	git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ <local directory>

	(rsync is generally faster for an initial clone, you can switch later
	by editing .git/branches/origin and changing the url)

To get the 'Porcelain' tools mentioned above:
	SCM Interface layers:
	cogito - http://www.kernel.org/pub/software/scm/cogito/
	StGIT - http://www.procode.org/stgit/

	History Visualization:
	gitk - http://ozlabs.org/~paulus/gitk/
	gitweb - http://www.kernel.org/pub/software/scm/gitweb/
	qgit - http://sourceforge.net/projects/qgit


Git distributions contain a tutorial in the Documentation subdirectory.
Additionally, the Kernel-Hacker's Git Tutorial at
http://linux.yyz.us/git-howto.html may be useful.  (Thanks to Jeff Garzik for
that document)

Git development takes place on the Git mailing list.  To subscribe, send an
email with just "subscribe git" in the body to majordomo@vger.kernel.org.
Mailing list archives are available at http://marc.theaimsgroup.com/?l=git

(This summary written by Ryan Anderson <ryan@michonline.com>.  Please bug him
with any corrections or complaints.)

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v3
  2005-07-29  8:29 ` Git 1.0 Synopis (Draft v3 Ryan Anderson
@ 2005-07-29 10:58   ` Johannes Schindelin
  2005-07-29 21:26   ` Sam Ravnborg
  2005-07-31 22:15   ` Horst von Brand
  2 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2005-07-29 10:58 UTC (permalink / raw)
  To: Ryan Anderson; +Cc: git

I like it!

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v3
  2005-07-29  8:29 ` Git 1.0 Synopis (Draft v3 Ryan Anderson
  2005-07-29 10:58   ` Johannes Schindelin
@ 2005-07-29 21:26   ` Sam Ravnborg
  2005-07-31 22:18     ` Horst von Brand
  2005-07-31 22:15   ` Horst von Brand
  2 siblings, 1 reply; 601+ messages in thread
From: Sam Ravnborg @ 2005-07-29 21:26 UTC (permalink / raw)
  To: Ryan Anderson; +Cc: git

On Fri, Jul 29, 2005 at 04:29:41AM -0400, Ryan Anderson wrote:
> Source Code Management with Git
....

The article should include a HOWTO part alos. So people can see how to
edit a file, pull from a remote repository etc.
Since you have introduced core and porcelains it would be most logical
to use one of the porcelains in these examples, maybe accompanied by the
raw git commands being executed.

	Sam

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v3
  2005-07-29  8:29 ` Git 1.0 Synopis (Draft v3 Ryan Anderson
  2005-07-29 10:58   ` Johannes Schindelin
  2005-07-29 21:26   ` Sam Ravnborg
@ 2005-07-31 22:15   ` Horst von Brand
  2005-08-01 13:21     ` Horst von Brand
  2005-08-15  4:55     ` Git 1.0 Synopis (Draft v4) Ryan Anderson
  2 siblings, 2 replies; 601+ messages in thread
From: Horst von Brand @ 2005-07-31 22:15 UTC (permalink / raw)
  To: Ryan Anderson; +Cc: git

Ryan Anderson <ryan@michonline.com> wrote:
> Source Code Management with Git

More bugging...

- Either stay with your idea of "Git is the idea, git the implementation"
  (iff blessed by the Git Powers That Be) and be consistent about it, or
  just use "git" throughout.

- Attribute the meaning appropiately, say by:

In Linus' own words as the inventor of git:

> "git" can mean anything, depending on your mood.
> 
>  - random three-letter combination that is pronounceable, and not
>    actually used by any common UNIX command.  The fact that it is a
>    mispronunciation of "get" may or may not be relevant.
>  - stupid. contemptible and despicable. simple. Take your pick from the
>    dictionary of slang.
>  - "global information tracker": you're in a good mood, and it actually
>    works for you. Angels sing, and a light suddenly fills the room. 
>  - "goddamn idiotic truckload of sh*t": when it breaks
[...]

> To get a copy of Git:
> 	Daily snapshots are available at:
> 	http://www.codemonkey.org.uk/projects/git-snapshots/git/
> 	(Thanks to Dave Jones)
> 
> 	Source tarballs and RPMs at:
> 	http://www.kernel.org/pub/software/scm/git/
> 
> 	Deb packages at:
> 	<insert url here>
> 
> 	Or via Git itself:
> 	git clone http://www.kernel.org/pub/scm/git/git.git/ <local directory>
> 	git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ <local directory>
> 
> 	(rsync is generally faster for an initial clone, you can switch later
> 	by editing .git/branches/origin and changing the url)
> 
> To get the 'Porcelain' tools mentioned above:
> 	SCM Interface layers:
> 	cogito - http://www.kernel.org/pub/software/scm/cogito/
> 	StGIT - http://www.procode.org/stgit/

At least cogito includes a (slightly old) version of git. Dunno about
StGIT. And git and cogito have a gitk inside too. This should be mentioned,
i.e., look at the package(s) you are interested and see what else they
carry or require and keep in mind that (for now?) getting git as part of
one package is /not/ guaranteed to be compatible with another or standard
git.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v3
  2005-07-29 21:26   ` Sam Ravnborg
@ 2005-07-31 22:18     ` Horst von Brand
  0 siblings, 0 replies; 601+ messages in thread
From: Horst von Brand @ 2005-07-31 22:18 UTC (permalink / raw)
  To: Sam Ravnborg; +Cc: Ryan Anderson, git

Sam Ravnborg <sam@ravnborg.org> wrote:
> On Fri, Jul 29, 2005 at 04:29:41AM -0400, Ryan Anderson wrote:
> > Source Code Management with Git
> ....

> The article should include a HOWTO part alos.

I'd vote for a separate file.

>                                               So people can see how to
> edit a file, pull from a remote repository etc.

Exactly.

> Since you have introduced core and porcelains it would be most logical
> to use one of the porcelains in these examples, maybe accompanied by the
> raw git commands being executed.

Better leave the Porcelain-HOWTO to individual Porcelain. Perhaps the
Plumbing-HOWTO should include a section on interfacing to Porcelain (or it
should be yet another file).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v3
  2005-07-31 22:15   ` Horst von Brand
@ 2005-08-01 13:21     ` Horst von Brand
  2005-08-15  4:55     ` Git 1.0 Synopis (Draft v4) Ryan Anderson
  1 sibling, 0 replies; 601+ messages in thread
From: Horst von Brand @ 2005-08-01 13:21 UTC (permalink / raw)
  To: Horst von Brand; +Cc: Ryan Anderson, git

[Yes, I know it is considered odd when you speak to yourself in public...]

Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> Ryan Anderson <ryan@michonline.com> wrote:
> > Source Code Management with Git

> More bugging...

And then some.

> > To get the 'Porcelain' tools mentioned above:
> > 	SCM Interface layers:
> > 	cogito - http://www.kernel.org/pub/software/scm/cogito/
> > 	StGIT - http://www.procode.org/stgit/
> 
> At least cogito includes a (slightly old) version of git. Dunno about
> StGIT. And git and cogito have a gitk inside too. This should be mentioned,
> i.e., look at the package(s) you are interested and see what else they
> carry or require and keep in mind that (for now?) getting git as part of
> one package is /not/ guaranteed to be compatible with another or standard
> git.

Also note that StGIT is /not/ a SCM (as cogito is), it is a tool to shuffle
patches that uses git as a backend/target.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Git 1.0 Synopis (Draft v4)
  2005-07-31 22:15   ` Horst von Brand
  2005-08-01 13:21     ` Horst von Brand
@ 2005-08-15  4:55     ` Ryan Anderson
  2005-08-15  5:09       ` Ryan Anderson
  2005-08-15  5:19       ` Junio C Hamano
  1 sibling, 2 replies; 601+ messages in thread
From: Ryan Anderson @ 2005-08-15  4:55 UTC (permalink / raw)
  To: Horst von Brand; +Cc: git, Junio C Hamano

On Sun, Jul 31, 2005 at 06:15:40PM -0400, Horst von Brand wrote:
> Ryan Anderson <ryan@michonline.com> wrote:
> > Source Code Management with Git
> 
> More bugging...

Ok, I think I've got all this addressed (plus the other email).

It just took me a lot longer to get to it than I planned.

Junio, do you want to pull this into the git tree?  (I'll reply with a
patch)

==========

Source Code Management with git

In Linus's own words as the creator of git:
"git" can mean anything, depending on your mood.

 - random three-letter combination that is pronounceable, and not
   actually used by any common UNIX command.  The fact that it is a
   mispronunciation of "get" may or may not be relevant.
 - stupid. contemptible and despicable. simple. Take your pick from the
   dictionary of slang.
 - "global information tracker": you're in a good mood, and it actually
   works for you. Angels sing, and a light suddenly fills the room. 
 - "goddamn idiotic truckload of sh*t": when it breaks

git is a "directory content manager".  git has been designed to handle
absolutely massive projects with speed and efficiency, and the release of the
2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it
does this task well.

git falls into the category of distributed source code management tools,
similar to Arch or Darcs (or, in the commercial world, BitKeeper).  Every git
working directory is a full-fledged repository with full revision tracking
capabilities, not dependent on network access to a central server.

git provides a content-addressable pseudo filesystem, complete with its own
version of fsck.

  o Speed of use, both for the project maintainer, and the end-users, is
    a key development principle.

  o The history is stored as a directed acyclic graph, making long-lived
    branches and repeated merging simple.

  o The core git project considers itself to provide "plumbing" for other
     projects, as well as to serve to arbitrate for compatibility between them.
     The project built on top of the core git are referred to as "porcelain".
     Stgit, Cogito, qgit, gitk and gitweb are all building upon the core git
     tools, and providing an easy to use interface to various pieces of
     functionality.

  o Some other projects have taken the concepts from the core git project, and
    are either porting an existing toolset to use the git tools, or
    reimplementing the concepts internally, to benefit from the performance
     improvements.  This includes both Arch 2.0, and Darcs-git.
  
  o Two, interchangeable, on-disk formats are used:
    o An efficient, packed format that saves space and network
      bandwidth.
    o An unpacked format, optimized for fast writes and incremental
      work.

To get a copy of git:
	Daily snapshots are available at:
	http://www.codemonkey.org.uk/projects/git-snapshots/git/
	(Thanks to Dave Jones)

	Source tarballs and RPMs at:
	http://www.kernel.org/pub/software/scm/git/

	Debian packages should be availabe in unstable (sid) as "git-core"

	Or via git itself:
	git clone http://www.kernel.org/pub/scm/git/git.git/ <local directory>
	git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ <local directory>

	(rsync is generally faster for an initial clone, you can switch later
	by editing .git/branches/origin and changing the url)

To get the 'Porcelain' tools mentioned above:
	SCM Interface layers:
	cogito - http://www.kernel.org/pub/software/scm/cogito/

	Patch Management (similar to Quilt):
	StGIT - http://www.procode.org/stgit/

	History Visualization:
	gitk - http://ozlabs.org/~paulus/gitk/ (Included in the standard git
		distribution)
	gitweb - http://www.kernel.org/pub/software/scm/gitweb/
	qgit - http://sourceforge.net/projects/qgit


git distributions contain a tutorial in the Documentation subdirectory.
Additionally, the Kernel-Hacker's git Tutorial at
http://linux.yyz.us/git-howto.html may be useful.  (Thanks to Jeff Garzik for
that document)

git development takes place on the git mailing list.  To subscribe, send an
email with just "subscribe git" in the body to majordomo@vger.kernel.org.
Mailing list archives are available at http://marc.theaimsgroup.com/?l=git

(This summary written by Ryan Anderson <ryan@michonline.com>.  Please bug him
with any corrections or complaints.)


-- 

Ryan Anderson
  sometimes Pug Majere

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-15  4:55     ` Git 1.0 Synopis (Draft v4) Ryan Anderson
@ 2005-08-15  5:09       ` Ryan Anderson
  2005-08-15  5:19       ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Ryan Anderson @ 2005-08-15  5:09 UTC (permalink / raw)
  To: Horst von Brand; +Cc: git, Junio C Hamano


Add a SYNOPSIS/release summary to the tree.

Signed-off-by: Ryan Anderson <ryan@michonline.com>

diff --git a/SYNOPSIS b/SYNOPSIS
new file mode 100644
--- /dev/null
+++ b/SYNOPSIS
@@ -0,0 +1,93 @@
+Source Code Management with git
+
+In Linus's own words as the creator of git:
+"git" can mean anything, depending on your mood.
+
+ - random three-letter combination that is pronounceable, and not
+   actually used by any common UNIX command.  The fact that it is a
+   mispronunciation of "get" may or may not be relevant.
+ - stupid. contemptible and despicable. simple. Take your pick from the
+   dictionary of slang.
+ - "global information tracker": you're in a good mood, and it actually
+   works for you. Angels sing, and a light suddenly fills the room. 
+ - "goddamn idiotic truckload of sh*t": when it breaks
+
+git is a "directory content manager".  git has been designed to handle
+absolutely massive projects with speed and efficiency, and the release of the
+2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it
+does this task well.
+
+git falls into the category of distributed source code management tools,
+similar to Arch or Darcs (or, in the commercial world, BitKeeper).  Every git
+working directory is a full-fledged repository with full revision tracking
+capabilities, not dependent on network access to a central server.
+
+git provides a content-addressable pseudo filesystem, complete with its own
+version of fsck.
+
+  o Speed of use, both for the project maintainer, and the end-users, is
+    a key development principle.
+
+  o The history is stored as a directed acyclic graph, making long-lived
+    branches and repeated merging simple.
+
+  o The core git project considers itself to provide "plumbing" for other
+     projects, as well as to serve to arbitrate for compatibility between them.
+     The project built on top of the core git are referred to as "porcelain".
+     Stgit, Cogito, qgit, gitk and gitweb are all building upon the core git
+     tools, and providing an easy to use interface to various pieces of
+     functionality.
+
+  o Some other projects have taken the concepts from the core git project, and
+    are either porting an existing toolset to use the git tools, or
+    reimplementing the concepts internally, to benefit from the performance
+     improvements.  This includes both Arch 2.0, and Darcs-git.
+  
+  o Two, interchangeable, on-disk formats are used:
+    o An efficient, packed format that saves space and network
+      bandwidth.
+    o An unpacked format, optimized for fast writes and incremental
+      work.
+
+To get a copy of git:
+	Daily snapshots are available at:
+	http://www.codemonkey.org.uk/projects/git-snapshots/git/
+	(Thanks to Dave Jones)
+
+	Source tarballs and RPMs at:
+	http://www.kernel.org/pub/software/scm/git/
+
+	Debian packages should be availabe in unstable (sid) as "git-core"
+
+	Or via git itself:
+	git clone http://www.kernel.org/pub/scm/git/git.git/ <local directory>
+	git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ <local directory>
+
+	(rsync is generally faster for an initial clone, you can switch later
+	by editing .git/branches/origin and changing the url)
+
+To get the 'Porcelain' tools mentioned above:
+	SCM Interface layers:
+	cogito - http://www.kernel.org/pub/software/scm/cogito/
+
+	Patch Management (similar to Quilt):
+	StGIT - http://www.procode.org/stgit/
+
+	History Visualization:
+	gitk - http://ozlabs.org/~paulus/gitk/ (Included in the standard git
+		distribution)
+	gitweb - http://www.kernel.org/pub/software/scm/gitweb/
+	qgit - http://sourceforge.net/projects/qgit
+
+
+git distributions contain a tutorial in the Documentation subdirectory.
+Additionally, the Kernel-Hacker's git Tutorial at
+http://linux.yyz.us/git-howto.html may be useful.  (Thanks to Jeff Garzik for
+that document)
+
+git development takes place on the git mailing list.  To subscribe, send an
+email with just "subscribe git" in the body to majordomo@vger.kernel.org.
+Mailing list archives are available at http://marc.theaimsgroup.com/?l=git
+
+(This summary written by Ryan Anderson <ryan@michonline.com>.  Please bug him
+with any corrections or complaints.)

-- 

Ryan Anderson
  sometimes Pug Majere

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-15  4:55     ` Git 1.0 Synopis (Draft v4) Ryan Anderson
  2005-08-15  5:09       ` Ryan Anderson
@ 2005-08-15  5:19       ` Junio C Hamano
  2005-08-15  6:58         ` Ryan Anderson
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2005-08-15  5:19 UTC (permalink / raw)
  To: Ryan Anderson; +Cc: git

Ryan Anderson <ryan@michonline.com> writes:

> Junio, do you want to pull this into the git tree?

Yes, but I have been wondering where it should go.  Should it go
under Documentation/ and made into html via asciidoc along with
other tools?

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-15  5:19       ` Junio C Hamano
@ 2005-08-15  6:58         ` Ryan Anderson
  2005-08-15  7:17           ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Ryan Anderson @ 2005-08-15  6:58 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sun, Aug 14, 2005 at 10:19:18PM -0700, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
> 
> > Junio, do you want to pull this into the git tree?
> 
> Yes, but I have been wondering where it should go.  Should it go
> under Documentation/ and made into html via asciidoc along with
> other tools?

I was somewhat thinking it should go in the main directory, and be a
useful introduction to the project for people.... but it's not really
aimed at that very well, now that I think about it.

To be fair, it's not really aimed well at being documentation for people
that already have git, either.  I've been writing it with the idea of
"something to send to LWN when 1.0 happens so they can post it mostly
verbatim."

I guess this means, "I dunno, either place works for me."

-- 

Ryan Anderson
  sometimes Pug Majere

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-15  6:58         ` Ryan Anderson
@ 2005-08-15  7:17           ` Junio C Hamano
  2005-08-15  8:02             ` Ryan Anderson
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2005-08-15  7:17 UTC (permalink / raw)
  To: Ryan Anderson; +Cc: git

Ryan Anderson <ryan@michonline.com> writes:

> I guess this means, "I dunno, either place works for me."

I was hoping it means to "Oh, come to think of it, maybe I
should send this to corbet@lwn.net" ;-).

I agree with you that this may be a lot more suitable for people
_before_ they get the git sources, which is to say it may make
more sense not to include in core-git tarball but is made into a
patch to Pasky's introduction website.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-15  7:17           ` Junio C Hamano
@ 2005-08-15  8:02             ` Ryan Anderson
  2005-08-15  8:17               ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Ryan Anderson @ 2005-08-15  8:02 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Mon, Aug 15, 2005 at 12:17:46AM -0700, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
> 
> > I guess this means, "I dunno, either place works for me."
> 
> I was hoping it means to "Oh, come to think of it, maybe I
> should send this to corbet@lwn.net" ;-).

I was waiting until you said, "Ok, 1.00 tomorrow morning"

> I agree with you that this may be a lot more suitable for people
> _before_ they get the git sources, which is to say it may make
> more sense not to include in core-git tarball but is made into a
> patch to Pasky's introduction website.

Good point.

It's already there (now that I found the site.)

-- 

Ryan Anderson
  sometimes Pug Majere

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-15  8:02             ` Ryan Anderson
@ 2005-08-15  8:17               ` Junio C Hamano
  2005-08-15 18:59                 ` Daniel Barkalow
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2005-08-15  8:17 UTC (permalink / raw)
  To: Ryan Anderson; +Cc: git

Ryan Anderson <ryan@michonline.com> writes:

> I was waiting until you said, "Ok, 1.00 tomorrow morning"

Makes sense.  There would be some weeks until that happens I am
afraid.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-15  8:17               ` Junio C Hamano
@ 2005-08-15 18:59                 ` Daniel Barkalow
  2005-08-16  7:28                   ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Daniel Barkalow @ 2005-08-15 18:59 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Ryan Anderson, git

On Mon, 15 Aug 2005, Junio C Hamano wrote:

> Ryan Anderson <ryan@michonline.com> writes:
> 
> > I was waiting until you said, "Ok, 1.00 tomorrow morning"
> 
> Makes sense.  There would be some weeks until that happens I am
> afraid.

It might be worth putting the list of things left to do before 1.0 in the 
tree (since they clearly covary), and it would be useful to know what 
you're thinking of as preventing the release at any particular stage.

	-Daniel
*This .sig left intentionally blank*

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-15 18:59                 ` Daniel Barkalow
@ 2005-08-16  7:28                   ` Junio C Hamano
  2005-08-16 10:03                     ` Johannes Schindelin
                                       ` (3 more replies)
  0 siblings, 4 replies; 601+ messages in thread
From: Junio C Hamano @ 2005-08-16  7:28 UTC (permalink / raw)
  To: Daniel Barkalow; +Cc: Ryan Anderson, git

Daniel Barkalow <barkalow@iabervon.org> writes:

> It might be worth putting the list of things left to do before 1.0 in the 
> tree (since they clearly covary), and it would be useful to know what 
> you're thinking of as preventing the release at any particular stage.

Yeah, yeah.  Call me lazy.

Excerpts from my "last mile to 1.0", my Itchlist, and pieces from
random other messages since then.

- Documentation. [I really need help here --- among ~7000 lines
  there, I've written around 2500 lines, David Greaves another
  2500, and Linus 1400.  And it is not very easy to proofread
  what you wrote yourself.]

  - Are all the core commands described in Documentation/
    directory?

  - Many files under Documentation/ directory have become stale.
    I've tried to do one pass of full sweep recently [and
    another since I wrote the original "last mile" message], but
    I'd like somebody else to make another pass to make sure
    that the usage strings in programs, what the programs do,
    and what Documentation says they do match.  Also, the
    spelling and grammar fixes, which I am very bad at and have
    not done any attempt, needs to be done.

    Volunteers?

  - Are all the files in Documentation/ reachable from git(7)
    or otherwise made into a standalone document using asciidoc
    by the Makefile?  I haven't looked into documentation
    generation myself (I use only the text files as they are);
    help to update the Makefile by somebody handy with asciidoc
    suite is greatly appreciated here.

    Volunteers?

  - We may want to describe more Best Current Practices, along
    the lines of "Working with Others" section in the tutorial.
    Please write on your faviorite topic and send patches in
    ;-)) [ryan started collecting Documentation/howto which
    would greatly help in this area].

  - Glossary documentation Johannes Schindelin is working on.

    I think coming up with the concensus of terms would come
    fairly quickly on the list.  Updating docs to match the
    concensus may take some time.  Help is greatly appreciated.

  - Maybe doing another pass at tutorial.  Could somebody run
    (or preferably, find a friend who has never touched git and
    have her run) the tutorial examples from the beginning to
    the end, and find rooms of improvements?  Does the order of
    materials presented make sense?  Do we talk about things
    assuming that the user knows something else that we have not
    talked about?  Have we introduced better way of doing the
    same thing since the tutorial was written?

    I've done that once with the text that is currently in the
    head of the master branch, but that is getting rather stale,
    and also I did that myself so I am sure I've sidestepped
    pitfalls without even realizing.

The above does not have to be all there in 0.99.5, but I
consider that lack of any of the above to block 1.0.

- Commit walker downloading from packed repository is finally
  complete.  Thanks, Daniel!

- Teach fetch-pack reference renaming.

  On the push side, send-pack now knows updating arbitrary
  remote references from local references.  We need something
  similar for fetching [since then I outlined the design of the
  new shorthand file format and semantics but have not got
  around to actually do it.  Maybe on my next GIT day...].  This
  is scheduled for 0.99.5.

- commit template filler discussed with Pasky some time ago,
  with perhaps pre-commit and post-commit hooks.  Somehow the
  discussion died out but that does not mean _I_ forgot about
  it.

- Binary packaging.  Should _I_ worry about "/usr/bin/git" stay
  there myself --- I think not.  But I _do_ want to help Debian
  packaging folks if that path is causing problems in their
  effort to push git-core into the official Debian archive.

  As Linus mentioned earlier, this seems to be a Debian specific
  problem, and will not block 1.0 --- if Debian heavyweights do
  not want to stay compatible with the rest of the world, so be
  it.

- I have not heard from Darwin or BSD people for some time.  Is
  your portfile up to date?  Do you have updates you want me to
  include?  Have we introduced non-Linux non-GNU
  incompatibilities lately that you want to see fixed and/or
  worked around?

  Again, I consider binary packaging issue independent from our
  release schedule; it is a distribution local issue, so this
  would not block 1.0 in any way.  But I _am_ willing to help
  them.

- Oh, another itch I did not list in the previous message.  Is
  anybody interested in doing an Emacs VC back-end for GIT?

- git prune and git fsck-cache; think about their interactions
  with an object database that borrows from another.  This
  includes the case where .git/objects itself is symlinked to
  somewhere else (i.e. running "git prune" that somewhere else
  without consulting this repository would lose objects), and
  alternates pointing at somewhere else (i.e. ditto).

  My personal feeling is that we should just warn users about
  doing .git/objects symlinking and/or alternates pointing ---
  do not do it unless you have an off-line arrangement with the
  owner of the repository you are borrowing from.  Even if that
  would become our official position to take, it needs to be
  documented clearly before we declare this issue to have been
  "dealt with".

I am sure I am forgetting something, but the above would be a
good start.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-16  7:28                   ` Junio C Hamano
@ 2005-08-16 10:03                     ` Johannes Schindelin
  2005-08-16 10:14                       ` Dongsheng Song
  2005-08-16 10:17                       ` about git server & permissions Dongsheng Song
  2005-08-16 15:31                     ` Git 1.0 Synopis (Draft v4) Johannes Schindelin
                                       ` (2 subsequent siblings)
  3 siblings, 2 replies; 601+ messages in thread
From: Johannes Schindelin @ 2005-08-16 10:03 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Daniel Barkalow, Ryan Anderson, git

[-- Attachment #1: Type: TEXT/PLAIN, Size: 978 bytes --]

Hi,

On Tue, 16 Aug 2005, Junio C Hamano wrote:

>   - Glossary documentation Johannes Schindelin is working on.

Yeah, yeah. Call _me_ lazy :-) I'll try to come up with a discussable item 
today.

> - git prune and git fsck-cache; think about their interactions
>   with an object database that borrows from another.  This
>   includes the case where .git/objects itself is symlinked to
>   somewhere else (i.e. running "git prune" that somewhere else
>   without consulting this repository would lose objects), and
>   alternates pointing at somewhere else (i.e. ditto).

I don´t see how git could help in the case you are pruning a repository 
which another repository points to. After all, the first repository 
doesn´t know about being used by the second.

> I am sure I am forgetting something, but the above would be a
> good start.

Maybe your $GIT_DIR/remotes idea? Along with a "--store <remotename>" flag 
to git-pull-script?

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-16 10:03                     ` Johannes Schindelin
@ 2005-08-16 10:14                       ` Dongsheng Song
  2005-08-16 10:17                       ` about git server & permissions Dongsheng Song
  1 sibling, 0 replies; 601+ messages in thread
From: Dongsheng Song @ 2005-08-16 10:14 UTC (permalink / raw)
  To: git

Hi,

Is there any guide or advise for deploy git server ? 

How do I set repository permissions correctly?

cauchy

^ permalink raw reply	[flat|nested] 601+ messages in thread

* about git server & permissions
  2005-08-16 10:03                     ` Johannes Schindelin
  2005-08-16 10:14                       ` Dongsheng Song
@ 2005-08-16 10:17                       ` Dongsheng Song
  1 sibling, 0 replies; 601+ messages in thread
From: Dongsheng Song @ 2005-08-16 10:17 UTC (permalink / raw)
  To: git

Hi,

Is there any guide or advise for deploy git server ? Especially
http/https/ssh server.

How do I set repository permissions correctly?

cauchy

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-16  7:28                   ` Junio C Hamano
  2005-08-16 10:03                     ` Johannes Schindelin
@ 2005-08-16 15:31                     ` Johannes Schindelin
  2005-08-16 15:47                       ` Daniel Barkalow
  2005-08-16 15:39                     ` Daniel Barkalow
  2005-08-16 19:41                     ` Horst von Brand
  3 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2005-08-16 15:31 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Daniel Barkalow, Ryan Anderson, git

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1072 bytes --]

Hi,

On Tue, 16 Aug 2005, Junio C Hamano wrote:

>   - Are all the files in Documentation/ reachable from git(7)
>     or otherwise made into a standalone document using asciidoc
>     by the Makefile?  I haven't looked into documentation
>     generation myself (I use only the text files as they are);
>     help to update the Makefile by somebody handy with asciidoc
>     suite is greatly appreciated here.
> 
>     Volunteers?

The attached script reveals:

git-unpack-objects.txt is not reachable from git.txt
git-cvsimport-script.txt is not reachable from git.txt
git-send-email-script.txt is not reachable from git.txt
git-rename-script.txt is not reachable from git.txt
tutorial.txt is not reachable from git.txt
git-show-index.txt is not reachable from git.txt
cvs-migration.txt is not reachable from git.txt
diffcore.txt is not reachable from git.txt
git-ls-remote-script.txt is not reachable from git.txt
git-apply.txt is not reachable from git.txt
git-diff-stages.txt is not reachable from git.txt
pack-protocol.txt is not reachable from git.txt

Ciao,
Dscho

[-- Attachment #2: Type: APPLICATION/x-perl, Size: 1215 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-16  7:28                   ` Junio C Hamano
  2005-08-16 10:03                     ` Johannes Schindelin
  2005-08-16 15:31                     ` Git 1.0 Synopis (Draft v4) Johannes Schindelin
@ 2005-08-16 15:39                     ` Daniel Barkalow
  2005-08-16 19:41                     ` Horst von Brand
  3 siblings, 0 replies; 601+ messages in thread
From: Daniel Barkalow @ 2005-08-16 15:39 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Ryan Anderson, git

On Tue, 16 Aug 2005, Junio C Hamano wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > It might be worth putting the list of things left to do before 1.0 in the
> > tree (since they clearly covary), and it would be useful to know what
> > you're thinking of as preventing the release at any particular stage.
>
> Yeah, yeah.  Call me lazy.
>
> Excerpts from my "last mile to 1.0", my Itchlist, and pieces from
> random other messages since then.
>
> - Documentation. [I really need help here --- among ~7000 lines
>   there, I've written around 2500 lines, David Greaves another
>   2500, and Linus 1400.  And it is not very easy to proofread
>   what you wrote yourself.]

I'm not sure how done this can actually get before some sort of feature
freeze; the best ways to do things keeps changing as more convenient ways
are added. Once the new stuff is diverted to post-1.0, I'd be interested
in going through it.

> - git prune and git fsck-cache; think about their interactions
>   with an object database that borrows from another.  This
>   includes the case where .git/objects itself is symlinked to
>   somewhere else (i.e. running "git prune" that somewhere else
>   without consulting this repository would lose objects), and
>   alternates pointing at somewhere else (i.e. ditto).

It should be fine, but only if .git/refs is symlinked to the matching
place; this gives you the same repository with multiple working trees.
Having refs/ and objects/ directories that aren't always together would be
much less safe.

	-Daniel
*This .sig left intentionally blank*

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-16 15:31                     ` Git 1.0 Synopis (Draft v4) Johannes Schindelin
@ 2005-08-16 15:47                       ` Daniel Barkalow
  0 siblings, 0 replies; 601+ messages in thread
From: Daniel Barkalow @ 2005-08-16 15:47 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, Ryan Anderson, git

On Tue, 16 Aug 2005, Johannes Schindelin wrote:

> Hi,
>
> On Tue, 16 Aug 2005, Junio C Hamano wrote:
>
> >   - Are all the files in Documentation/ reachable from git(7)
> >     or otherwise made into a standalone document using asciidoc
> >     by the Makefile?  I haven't looked into documentation
> >     generation myself (I use only the text files as they are);
> >     help to update the Makefile by somebody handy with asciidoc
> >     suite is greatly appreciated here.
> >
> >     Volunteers?
>
> The attached script reveals:
>
> git-unpack-objects.txt is not reachable from git.txt
> git-cvsimport-script.txt is not reachable from git.txt
> git-send-email-script.txt is not reachable from git.txt
> git-rename-script.txt is not reachable from git.txt
> tutorial.txt is not reachable from git.txt
> git-show-index.txt is not reachable from git.txt
> cvs-migration.txt is not reachable from git.txt
> diffcore.txt is not reachable from git.txt
> git-ls-remote-script.txt is not reachable from git.txt
> git-apply.txt is not reachable from git.txt
> git-diff-stages.txt is not reachable from git.txt
> pack-protocol.txt is not reachable from git.txt

The ones that don't start with git probably don't belong in the same set;
perhaps there should be a "technical" (or something similar but shorter)
subdirectory for developer documentation instead of user documentation?
(And tutorial and cvs-migration can move to howto)

	-Daniel
*This .sig left intentionally blank*

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-16  7:28                   ` Junio C Hamano
                                       ` (2 preceding siblings ...)
  2005-08-16 15:39                     ` Daniel Barkalow
@ 2005-08-16 19:41                     ` Horst von Brand
  2005-08-16 20:41                       ` Johannes Schindelin
  2005-08-18  9:27                       ` Matthias Urlichs
  3 siblings, 2 replies; 601+ messages in thread
From: Horst von Brand @ 2005-08-16 19:41 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Daniel Barkalow, Ryan Anderson, git

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

[...]

> - Oh, another itch I did not list in the previous message.  Is
>   anybody interested in doing an Emacs VC back-end for GIT?

And teach make(1) about checking out files from git... or just create a
co(1) command for git.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-16 19:41                     ` Horst von Brand
@ 2005-08-16 20:41                       ` Johannes Schindelin
  2005-08-18  9:27                       ` Matthias Urlichs
  1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2005-08-16 20:41 UTC (permalink / raw)
  To: Horst von Brand; +Cc: Junio C Hamano, Daniel Barkalow, Ryan Anderson, git

Hi,

On Tue, 16 Aug 2005, Horst von Brand wrote:

> And teach make(1) about checking out files from git... or just create a
> co(1) command for git.

How about "git-checkout-script", optionally with the "-f" flag to ignore 
changes since the last checkout/checkin?

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Git 1.0 Synopis (Draft v4)
  2005-08-16 19:41                     ` Horst von Brand
  2005-08-16 20:41                       ` Johannes Schindelin
@ 2005-08-18  9:27                       ` Matthias Urlichs
  1 sibling, 0 replies; 601+ messages in thread
From: Matthias Urlichs @ 2005-08-18  9:27 UTC (permalink / raw)
  To: git

Hi, Horst von Brand wrote:

> And teach make(1) about checking out files from git... or just create a
> co(1) command for git.

Ummm... why?

make's SCCS support depends on the presence of a SCCS/s.<name> file
for each <name>. We don't have that. Teaching make about git would be
equivalent to teaching it about parsing the index file.

Technically, that would require a stable libgit.so or so.
In reality, however, I don't know when I last had a tree which wasn't
fully populated, but it's been a while, and it's something that can be
readily fixed by "git-checkout-cache -a".

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
One possible reason that things aren't going according to plan
is that there never was a plan in the first place.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* [PATCH] commit: Steer new users toward "git commit -a" rather than update-index
@ 2006-11-14 16:42 Carl Worth
  2006-11-14 18:55 ` Andy Whitcroft
  0 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-14 16:42 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

As has been discussed recently, update-index isn't intended as a
"porcelain" command so the mention of it in the output of git-commit
does lead to some user confusion.
---
 wt-status.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index 7dd6857..4edabcd 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -126,7 +126,7 @@ static void wt_status_print_changed_cb(s
 	int i;
 	if (q->nr)
 		wt_status_print_header("Changed but not updated",
-				"use git-update-index to mark for commit");
+				"use \"git commit <files>\" to commit or \"git commit -a\" for all");
 	for (i = 0; i < q->nr; i++)
 		wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
 	if (q->nr)
--
1.4.3.3.gf040


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: [PATCH] commit: Steer new users toward "git commit -a" rather than update-index
  2006-11-14 16:42 [PATCH] commit: Steer new users toward "git commit -a" rather than update-index Carl Worth
@ 2006-11-14 18:55 ` Andy Whitcroft
  2006-11-14 19:22   ` Cleaning up git user-interface warts Carl Worth
  2006-11-14 23:30   ` [PATCH] commit: Steer new users toward "git commit -a" rather than update-index Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Andy Whitcroft @ 2006-11-14 18:55 UTC (permalink / raw)
  To: Carl Worth; +Cc: Junio C Hamano, git

Carl Worth wrote:
> As has been discussed recently, update-index isn't intended as a
> "porcelain" command so the mention of it in the output of git-commit
> does lead to some user confusion.
> ---
>  wt-status.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/wt-status.c b/wt-status.c
> index 7dd6857..4edabcd 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -126,7 +126,7 @@ static void wt_status_print_changed_cb(s
>  	int i;
>  	if (q->nr)
>  		wt_status_print_header("Changed but not updated",
> -				"use git-update-index to mark for commit");
> +				"use \"git commit <files>\" to commit or \"git commit -a\" for all");
>  	for (i = 0; i < q->nr; i++)
>  		wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
>  	if (q->nr)
> --
> 1.4.3.3.gf040

Are we sure this isn't porcelain-ish?  We need to use it in merge
conflict correction and the like?  You can't use git-commit there as a
replacement.  I'd expect it to be 'git update-index' rather than
'git-update-index' of course.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Cleaning up git user-interface warts
  2006-11-14 18:55 ` Andy Whitcroft
@ 2006-11-14 19:22   ` Carl Worth
  2006-11-14 19:29     ` Shawn Pearce
                       ` (3 more replies)
  2006-11-14 23:30   ` [PATCH] commit: Steer new users toward "git commit -a" rather than update-index Junio C Hamano
  1 sibling, 4 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-14 19:22 UTC (permalink / raw)
  To: Andy Whitcroft; +Cc: Junio C Hamano, git

[-- Attachment #1: Type: text/plain, Size: 3070 bytes --]

On Tue, 14 Nov 2006 18:55:51 +0000, Andy Whitcroft wrote:
> Carl Worth wrote:
> > As has been discussed recently, update-index isn't intended as a
> > "porcelain" command so the mention of it in the output of git-commit
> > does lead to some user confusion.
>
> Are we sure this isn't porcelain-ish?  We need to use it in merge
> conflict correction and the like?  You can't use git-commit there as a
> replacement.  I'd expect it to be 'git update-index' rather than
> 'git-update-index' of course.

It was Junio that recently said update-index is plumbing, not
porcelain.

So, the fact that conflict resolution still requires the use of
update-index would just be the next thing to fix. A name for a
replacement to use there could be "git resolve <paths>", (since the
old git-resolve is now officially deprecated). That's a name that
matches what hg uses in this situation, (another option is "resolved"
which is what stg uses, but I think verbs for commands work better in
general).

It would be really nice if none of the "common" commands had a hyphen
in them, for example.

And then, the next phase of my evil plan would be to introduce a -i
option for git-commit making it commit the state in the index. Then
git-commit with no options could work like "git-commit -a" does now,
(with the additional protection of not committing any unmerged
files---that is the new "git resolve" would be required before "git
commit" would work after a conflict). Users who really, really like
the current behavior of git-commit could use the new alias support to
pass the new -i option in order to maintain compatible behavior.

Then, the last thing I'd really like to fix is to allow a usage of
"git merge <branch>" instead of the awkward "git pull . <branch>".

With that, most of the user-interface warts that I regularly run into
with git would be solved. Oh, except it would also be nice to
eliminate the "plumbing" commands in a couple of places:

 1) From the "man git" man page

 2) From git-<TAB>, (maybe the solution for this is to make
    "git <TAB>" work and only do tab-completion for the commands
    blessed enough to appear in "git --help"? Also push the tab
    completion stuff out as a standard part of packages.

Anyway, now I've just gone and blown all my secret plans for changing
git in ways to make it less intimidating for new users.

For reference, the latest potential batch of new users that I'm
dealing with is the set of Fedora package maintainers who are looking
at replacing CVS for their tree of package-building scripts. They are
currently evaluating systems and liking the interface of hg. Here's
the top of the current thread:

https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00030.html

Here's the report about "git commit -a" confusion that led to my patch
above:

https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00141.html

And here's my reply where I suggest that git UI might still be
improved in these areas:

https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00149.html

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 19:22   ` Cleaning up git user-interface warts Carl Worth
@ 2006-11-14 19:29     ` Shawn Pearce
  2006-11-14 19:59       ` Carl Worth
  2006-11-14 19:47     ` Petr Baudis
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-14 19:29 UTC (permalink / raw)
  To: Carl Worth; +Cc: Andy Whitcroft, Junio C Hamano, git

Carl Worth <cworth@cworth.org> wrote:
>  2) From git-<TAB>, (maybe the solution for this is to make
>     "git <TAB>" work and only do tab-completion for the commands
>     blessed enough to appear in "git --help"? Also push the tab
>     completion stuff out as a standard part of packages.

Uh, see contrib/completion/git-completion.bash.

"git <TAB>" completes commands.  It offers too many completions
for your taste it sounds like, as it also offers plumbing... but
that's fixable.  :-)

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 19:22   ` Cleaning up git user-interface warts Carl Worth
  2006-11-14 19:29     ` Shawn Pearce
@ 2006-11-14 19:47     ` Petr Baudis
  2006-11-14 20:56       ` Carl Worth
  2006-11-14 20:46     ` Karl Hasselström
  2006-11-14 20:52     ` Nicolas Pitre
  3 siblings, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-14 19:47 UTC (permalink / raw)
  To: Carl Worth; +Cc: Andy Whitcroft, Junio C Hamano, git

On Tue, Nov 14, 2006 at 08:22:39PM CET, Carl Worth wrote:
> For reference, the latest potential batch of new users that I'm
> dealing with is the set of Fedora package maintainers who are looking
> at replacing CVS for their tree of package-building scripts. They are
> currently evaluating systems and liking the interface of hg. Here's
> the top of the current thread:
> 
> https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00030.html
> 
> Here's the report about "git commit -a" confusion that led to my patch
> above:
> 
> https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00141.html
> 
> And here's my reply where I suggest that git UI might still be
> improved in these areas:
> 
> https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00149.html

Hmm, did they (not) consider Cogito? They wouldn't have those issues.
;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 19:29     ` Shawn Pearce
@ 2006-11-14 19:59       ` Carl Worth
  0 siblings, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-14 19:59 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Andy Whitcroft, Junio C Hamano, git

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

On Tue, 14 Nov 2006 14:29:14 -0500, Shawn Pearce wrote:
> Uh, see contrib/completion/git-completion.bash.

Oops. I had seen this and thought I had installed it properly a while
ago, (copied it to /etc/bash_completion.d/git), but I hadn't realized
it wasn't active in the shell I used to test while composing that
email.

> "git <TAB>" completes commands.  It offers too many completions
> for your taste it sounds like, as it also offers plumbing... but
> that's fixable.  :-)

Yes, I think we'd all be better off if we could designate some subset
of the current git commands as not being intended for users to type on
the command line and pulled them out of the completion scripts.

It is tough though. Looking through what's available in the short list
from "git --help" I notice that update-index isn't there, and that's
currently still required, (as we've been discussing here). But even
things as "core plumbing" as git rev-list I find extremely useful on
the command like with simple pipelines.

On the other hand, there are definitely some commands I've never
typed, and are not intended to be typed by the user. Here are a few I
see as fairly obvious just from skimming the list:

	merge-*
	http-*
	ssh-*
	upload-*
	mktag
	mktree
	check-ref-format
	...

There are a bunch of others as well. Maybe it would be easier to start
with the list in git --help and see what should be added to that.

The documentation for some of the above commands have phrases such as
"Invoked by <other command>" and "usually not invoked by the end user"
which does make the distinction quite clear. So it would be nice if
git could keep these away from the user more.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 19:22   ` Cleaning up git user-interface warts Carl Worth
  2006-11-14 19:29     ` Shawn Pearce
  2006-11-14 19:47     ` Petr Baudis
@ 2006-11-14 20:46     ` Karl Hasselström
  2006-11-14 20:52     ` Nicolas Pitre
  3 siblings, 0 replies; 601+ messages in thread
From: Karl Hasselström @ 2006-11-14 20:46 UTC (permalink / raw)
  To: Carl Worth; +Cc: Andy Whitcroft, Junio C Hamano, git

On 2006-11-14 11:22:39 -0800, Carl Worth wrote:

> So, the fact that conflict resolution still requires the use of
> update-index would just be the next thing to fix. A name for a
> replacement to use there could be "git resolve <paths>", (since the
> old git-resolve is now officially deprecated). That's a name that
> matches what hg uses in this situation, (another option is
> "resolved" which is what stg uses, but I think verbs for commands
> work better in general).

Yes, "resolve" sounds better than "resolved". The latter is arguably
more correct, since you're telling git that you have already resolved
the file and not asking it to resolve it for you, but I still prefer
"resolve".

> And then, the next phase of my evil plan would be to introduce a -i
> option for git-commit making it commit the state in the index. Then
> git-commit with no options could work like "git-commit -a" does now,
> (with the additional protection of not committing any unmerged
> files---that is the new "git resolve" would be required before "git
> commit" would work after a conflict). Users who really, really like
> the current behavior of git-commit could use the new alias support
> to pass the new -i option in order to maintain compatible behavior.

Seems very sane. Default to simple behavior, and provide a switch to
get more complicated behavior.

> Then, the last thing I'd really like to fix is to allow a usage of
> "git merge <branch>" instead of the awkward "git pull . <branch>".

This should reduce newbie confusion a lot.

-- 
Karl Hasselström, kha@treskal.com

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 19:22   ` Cleaning up git user-interface warts Carl Worth
                       ` (2 preceding siblings ...)
  2006-11-14 20:46     ` Karl Hasselström
@ 2006-11-14 20:52     ` Nicolas Pitre
  2006-11-14 21:01       ` Jakub Narebski
  2006-11-14 21:10       ` Carl Worth
  3 siblings, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-14 20:52 UTC (permalink / raw)
  To: Carl Worth; +Cc: Andy Whitcroft, Junio C Hamano, git

On Tue, 14 Nov 2006, Carl Worth wrote:

> Anyway, now I've just gone and blown all my secret plans for changing
> git in ways to make it less intimidating for new users.

I just cannot do otherwise than cheer this with applause.

Even if I have a clear preference for GIT's _technology_, I still think 
that the HG user interface is more convivial.  I even been thinking 
about writing something like an hg-like frontend to GIT from time to 
time just so that GIT could then be better compared to (and actually 
just used like) HG.

I still think that the GIT user interface sucks in many ways.  The 
confusion between pull, fetch and push is still my favorite, along with 
the locale vs remote branch issue.  Maybe we'll better handle the branch 
issue eventually, but it would be so much intuitive to split branch 
merging out of git-pull, and make git-pull be the same as git-fetch 
(maybe deprecating git-fetch in the process) so push and pull are really 
_only_ opposite of each other.

If the fetch+merge behavior (which I think should really be refered as 
pull+merge) is still desirable, then it should be called git-update and 
be no more than a single shell script line such as

	git_pull && git_merge"

This is really what most people expect from such a command name based 
on obvious historical reasons.  The lack of any branch argument to 
git-pull and git-merge could be defined as using the first defined 
remote branch by default.  But having git-pull performing merges is IMHO 
overloading the word and goes against most people's expectations.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 19:47     ` Petr Baudis
@ 2006-11-14 20:56       ` Carl Worth
  2006-11-15  0:31         ` Junio C Hamano
  2006-11-17 20:30         ` Steven Grimm
  0 siblings, 2 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-14 20:56 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Andy Whitcroft, Junio C Hamano, git

[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]

On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:
> Hmm, did they (not) consider Cogito? They wouldn't have those issues.

I didn't ask.

Frankly, I don't see a lot of value in the git/cogito split right now.

When I first learned git and cogito (January 2006) and switched cairo
from cvs to git (the repository storage), I recommended cogito to
cairo programmers as a "more cvs-like" way to work with the new
repository.

Since then, having worked with git (the command-line program)
exclusively for my own work, and having introduced it to dozens of new
users, I don't bother recommending cogito anymore. It's just not that
hard to learn git itself, so there's not that much value in learning
cogito instead.

And this is particularly true since there's quite a large cost to
having to learn cogito _in addition to_ git. And I think that's what
most people would have to do anyway. For example, cogito doesn't wrap
all git commands. So users have to dip down into git for things like
git-bisect or else miss out an important functionality.

And for something like the Fedora transition, where I'm working with
the people who will be training the community in the new tools, the
trainers would have to learn both if they want to support a community
using both git and cogito. These trainers are already complaining
about the ~140 git commands, so adding 40 more cogito commands as well
doesn't make the story better.

It's great that git is written in a script-friendly way so that new
interfaces can be built on top of it. And I think the benefits of new
user interfaces are clear when they work in fundamentally different
ways, (say, being operated through a GUI). But where git and cogito
are both command-line utilities and have the same basic functionality,
I don't see how its helpful to maintain both tools. (Certainly some of
my attitude here is due to the timing of my introduction to git
contrasted with the timing of the inception of cogito. I'm sure git
improved a lot between those two events.)

There are some things that cogito does that git does not that I would
like to have in git. One is having a "commit" command that commits
everything by default without an extra command-line option. Another
(that I _think_ cogito has) is a way to switch away from a branch with
dirty changes to a clean branch, do work there, and come back to the
original branch with the dirty stuff still there.

I don't see any defining difference that justifies cogito's
existence ("hide the index" maybe? let's just hide it a tiny bit more
in git). And I would like to help work to get the remaining good
stuff that has been proven in cogito---to get it pushed down into git
itself.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 20:52     ` Nicolas Pitre
@ 2006-11-14 21:01       ` Jakub Narebski
  2006-11-14 21:32         ` Nicolas Pitre
  2006-11-14 21:10       ` Carl Worth
  1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-14 21:01 UTC (permalink / raw)
  To: git

Nicolas Pitre wrote:

> If the fetch+merge behavior (which I think should really be refered as 
> pull+merge) is still desirable, then it should be called git-update and 
> be no more than a single shell script line such as
> 
>         git_pull && git_merge"
> 
> This is really what most people expect from such a command name based 
> on obvious historical reasons.  The lack of any branch argument to 
> git-pull and git-merge could be defined as using the first defined 
> remote branch by default.  But having git-pull performing merges is IMHO 
> overloading the word and goes against most people's expectations.

By the way, is anyone doing _remote_ octopus pull (true pull, not with . as
repository)?

We can always have --merge arguments to git-pull, and --fetch argument to
git-merge.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 20:52     ` Nicolas Pitre
  2006-11-14 21:01       ` Jakub Narebski
@ 2006-11-14 21:10       ` Carl Worth
  2006-11-14 21:30         ` Jakub Narebski
  2006-11-14 22:36         ` Junio C Hamano
  1 sibling, 2 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-14 21:10 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Andy Whitcroft, Junio C Hamano, git

[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]

On Tue, 14 Nov 2006 15:52:47 -0500 (EST), Nicolas Pitre wrote:
> Even if I have a clear preference for GIT's _technology_, I still think
> that the HG user interface is more convivial.  I even been thinking
> about writing something like an hg-like frontend to GIT from time to
> time just so that GIT could then be better compared to (and actually
> just used like) HG.

I've actually been tempted to do the same myself. I really think that
the technology is a more important criterion than the UI so the
imagined hg-on-git interface would be an attempt to get people to look
past the interface differences and look at the technology when
deciding.

But, then, I'd be guilty of creating another cogito, and I just argued
against its existence in a separate thread. So I think we're better
off just fixing the git interface.

> I still think that the GIT user interface sucks in many ways.  The
> confusion between pull, fetch and push is still my favorite, along with
> the locale vs remote branch issue.  Maybe we'll better handle the branch
> issue eventually,

The --use-separate-remotes thing is technology in the right direction
here. But I think it's another example of very useful stuff being
improperly hidden behind another command-line option. Getting rid of
the "remote-tracking branches" as user-visible branches possible for
committing should be a priority. And that should be the default for
everyone, not just people who happen to clone with this obscure
option.

Similarly, the reflog stuff was often trumpeted in the recent git
vs. bzr debate. Why is that very useful functionality buried in a
config file option and not just stored by default?

> This is really what most people expect from such a command name based
> on obvious historical reasons.  The lack of any branch argument to
> git-pull and git-merge could be defined as using the first defined
> remote branch by default.

Once again, there's lots of useful work on "branch configuration" that
allows for commands to be able to get the "right" default repository
for push and pull. I hope that that stuff can be enabled by default
and not require --use-separate-remotes or manual configuration for
people to benefit from it.

I apologize if I sound like I'm ranting here. I love to see the many
good improvements being made to git. It's just that there seems to be
a sort of shyness about new features, (perhaps a fear of changing
existing behavior?). When it improves the user experience, let's make
the improvement the default and not add any more

	--make-this-command-do-what-it-really-should-have-always-done

options.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 21:10       ` Carl Worth
@ 2006-11-14 21:30         ` Jakub Narebski
  2006-11-14 21:34           ` Nicolas Pitre
  2006-11-14 22:36         ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-14 21:30 UTC (permalink / raw)
  To: git

The git interface refactoring should be I think the cause for git 2.0.0
release...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 21:01       ` Jakub Narebski
@ 2006-11-14 21:32         ` Nicolas Pitre
  2006-11-14 22:04           ` Jakub Narebski
  0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-14 21:32 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1241 bytes --]

On Tue, 14 Nov 2006, Jakub Narebski wrote:

> Nicolas Pitre wrote:
> 
> > If the fetch+merge behavior (which I think should really be refered as 
> > pull+merge) is still desirable, then it should be called git-update and 
> > be no more than a single shell script line such as
> > 
> >         git_pull && git_merge"
> > 
> > This is really what most people expect from such a command name based 
> > on obvious historical reasons.  The lack of any branch argument to 
> > git-pull and git-merge could be defined as using the first defined 
> > remote branch by default.  But having git-pull performing merges is IMHO 
> > overloading the word and goes against most people's expectations.
> 
> By the way, is anyone doing _remote_ octopus pull (true pull, not with . as
> repository)?
> 
> We can always have --merge arguments to git-pull, and --fetch argument to
> git-merge.

That would be a complete abomination if you want my opinion.

Please let git-pull actually pull stuff from a remote place, and 
git-merge actually merge stuff only.  Let's keep simple concepts mapped 
to simple commands please.  Nothing prevents _you_ from scripting more 
involved operations with a single command of your liking afterwards.


Nicolas

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 21:30         ` Jakub Narebski
@ 2006-11-14 21:34           ` Nicolas Pitre
  2006-11-14 22:56             ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-14 21:34 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

On Tue, 14 Nov 2006, Jakub Narebski wrote:

> The git interface refactoring should be I think the cause for git 2.0.0
> release...

Good idea indeed.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 21:32         ` Nicolas Pitre
@ 2006-11-14 22:04           ` Jakub Narebski
  2006-11-14 22:29             ` Nicolas Pitre
  0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-14 22:04 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git

Nicolas Pitre wrote:
> On Tue, 14 Nov 2006, Jakub Narebski wrote:

>> We can always have --merge arguments to git-pull, and --fetch argument to
>> git-merge.
> 
> That would be a complete abomination if you want my opinion.
> 
> Please let git-pull actually pull stuff from a remote place, and 
> git-merge actually merge stuff only.  Let's keep simple concepts mapped 
> to simple commands please.  Nothing prevents _you_ from scripting more 
> involved operations with a single command of your liking afterwards.

Do we want to abandon completely "single-branch" workflow, where you
don't use tracking branch, only merge directly into your working branch?
That is the cause to (unused by most) future git-merge (replacement for
git-pull .) --fetch=<remote>[#<branch>] option.

I'm not that sure about --merge option, but it could be useful, at least
to have current automatic "Merge branch '<branch>' of <URL>" commit message.
-- 
Jakub Narebski

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 22:04           ` Jakub Narebski
@ 2006-11-14 22:29             ` Nicolas Pitre
  0 siblings, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-14 22:29 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

On Tue, 14 Nov 2006, Jakub Narebski wrote:

> Nicolas Pitre wrote:
> > On Tue, 14 Nov 2006, Jakub Narebski wrote:
> 
> >> We can always have --merge arguments to git-pull, and --fetch argument to
> >> git-merge.
> > 
> > That would be a complete abomination if you want my opinion.
> > 
> > Please let git-pull actually pull stuff from a remote place, and 
> > git-merge actually merge stuff only.  Let's keep simple concepts mapped 
> > to simple commands please.  Nothing prevents _you_ from scripting more 
> > involved operations with a single command of your liking afterwards.
> 
> Do we want to abandon completely "single-branch" workflow, where you
> don't use tracking branch, only merge directly into your working branch?

I really think we should.  Let's admit it: such a work flow has nothing 
to do with the tool.  It would certainly be much easier to teach new 
users about "this is a read-only view of the remote content that you can 
merge into your working branch" than trying to explain why the tool is 
so weird for the sake of supporting different work flows directly.

Again I think it is easier to grasp two simple commands than a single 
but complex one with multiple ramifications.

> That is the cause to (unused by most) future git-merge (replacement for
> git-pull .) --fetch=<remote>[#<branch>] option.
> 
> I'm not that sure about --merge option, but it could be useful, at least
> to have current automatic "Merge branch '<branch>' of <URL>" commit message.

A "remote" branch should obviously have a corresponding URL.  So if you 
do "git-merge remote" then you may as well prepare a commit message with 
that URL given the local name for that branch if you want.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 21:10       ` Carl Worth
  2006-11-14 21:30         ` Jakub Narebski
@ 2006-11-14 22:36         ` Junio C Hamano
  2006-11-14 22:50           ` Junio C Hamano
                             ` (2 more replies)
  1 sibling, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-14 22:36 UTC (permalink / raw)
  To: Carl Worth; +Cc: git, Andy Whitcroft, Nicolas Pitre

Carl Worth <cworth@cworth.org> writes:

> On Tue, 14 Nov 2006 15:52:47 -0500 (EST), Nicolas Pitre wrote:
>> Even if I have a clear preference for GIT's _technology_, I still think
>> that the HG user interface is more convivial.  I even been thinking
>> about writing something like an hg-like frontend to GIT from time to
>> time just so that GIT could then be better compared to (and actually
>> just used like) HG.
>
> I've actually been tempted to do the same myself. I really think that
> the technology is a more important criterion than the UI so the
> imagined hg-on-git interface would be an attempt to get people to look
> past the interface differences and look at the technology when
> deciding.
>...
>> I still think that the GIT user interface sucks in many ways.  The
>...

I've actually been tempted to do that too, and my earlier "if I
were to redo git from scratch" message was the beginning of it
to summarize my preference about some of the issues raised in
this thread.

Commenting on the messages in this thread:

 - "resolve / resolved" are both confusing, when you are talking
   about "mark-resolved" operation.

 - "pull/push/fetch" have undesired confusion depending on where
   people learned the term.  I'd perhaps vote for replacing
   fetch with download and push with upload.

 - I think it would be sensible to make remote tracking branches
   less visible.  For example:

	git diff origin

   where origin is the shorthand for your upstream (e.g. you
   have .git/remotes/origin that records the URL and the branch
   you are tracking) should be easier to understand than

   	git diff remotes/origin/HEAD

   The latter is an implementation detail.  I could imagine we
   might even want to allow

	git diff origin#next

   to name the branch of the remote repository.  The notion of
   "where the tips of remote repository's branches are" is
   probably be updated by "git download" (in other words, the
   above "git diff" does not automatically initiate network
   transfer).

 - "git merge" to merge another branch into the current would
   make sense.  "git pull . remotes/origin/next" is showing too
   much implementation detail.  It should just be:

	git merge origin#next

And I agree with Pasky that fixing UI is hard unless you are
willing to get rid of historical warts.  Syntax of the command
line arguments the current set of Porcelain-ish takes are
sometimes just horrible.  It may not be a bad idea to start
building the fixed UI from scratch, using different prefix than
"git" (say "gu" that stands for "git UI" or "gh" that stands for
"git for humans").

Of course, it could even be "cg" ;-).


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 22:36         ` Junio C Hamano
@ 2006-11-14 22:50           ` Junio C Hamano
  2006-11-15  4:32             ` Nicolas Pitre
  2006-11-16  5:12           ` Petr Baudis
  2006-11-18  7:59           ` Alan Chandler
  2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-14 22:50 UTC (permalink / raw)
  To: git, Andy Whitcroft, Nicolas Pitre, Carl Worth

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

>  - I think it would be sensible to make remote tracking branches
>    less visible.  For example:
>...
>  - "git merge" to merge another branch into the current would
>    make sense.  "git pull . remotes/origin/next" is showing too
>    much implementation detail.  It should just be:
>
> 	git merge origin#next

This and other examples in "making remote tracking branches less
visible" are hard to read because I used the word "origin" in
two different sense.  So here is a needed clarification.

If you have remotes/upstream that says:

	URL: git://git.xz/repo.git
        Pull: refs/heads/master:remotes/origin/master
        Pull: refs/heads/next:remotes/origin/next

Then, currently the users need to say:

	git diff remotes/origin/master
        git merge remotes/origin/next

By "making tracking branches less visible", what I mean is to
let the users say this instead:

	git diff upstream
        git merge upstream#next




^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 21:34           ` Nicolas Pitre
@ 2006-11-14 22:56             ` Junio C Hamano
  2006-11-15  1:48               ` Nicolas Pitre
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-14 22:56 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git

Nicolas Pitre <nico@cam.org> writes:

> On Tue, 14 Nov 2006, Jakub Narebski wrote:
>
>> The git interface refactoring should be I think the cause for git 2.0.0
>> release...
>
> Good idea indeed.

We need to avoid user confusion, so making a command that used
to do one thing to suddenly do something completely different is
a no-no.  However, I do not think it needs to wait for 2.0.0.
We can start with a separate namespace (or even a separate
"Improved git UI project") and introduce the "improved UI set"
in 1.5.0 timeframe.

If managed properly, the "improved git UI" can coexist with the
current set of tools and over time we can give an option not to
even install the older Porcelain-ish commands.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] commit: Steer new users toward "git commit -a" rather than update-index
  2006-11-14 18:55 ` Andy Whitcroft
  2006-11-14 19:22   ` Cleaning up git user-interface warts Carl Worth
@ 2006-11-14 23:30   ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-14 23:30 UTC (permalink / raw)
  To: Andy Whitcroft; +Cc: git, Carl Worth

Andy Whitcroft <apw@shadowen.org> writes:

> Are we sure this isn't porcelain-ish?  We need to use it in merge
> conflict correction and the like?  You can't use git-commit there as a
> replacement.  I'd expect it to be 'git update-index' rather than
> 'git-update-index' of course.

I think status should be taken as Porcelain-ish so it should
notice more about the environment to see why the user has
changed but not updated files and recommend the possible action
depending on the context.

For that, you would need to enumerate what kind of 'context'
there could be with the current set of tools.  Here is a
strawman.

 1. None of the below.
 2. A merge was attempted and resulted in a conflict.
 3. An am or rebase without --merge was attempted and
    resulted in a conflict or patch rejection.
 4. A "rebase --merge was attempted and resulted in a conflict.

In the normal case, the next user action would be:

 1-1. The user wants that change in the next commit, and should
      run "git update-index $that_path" to prepare the index for
      partial commit, or "git commit -a" to commit all the
      changes made to the working tree so far.  Carl's patch
      helps the user in this case.

 1-2. The user realizes that the some of the changes in the
      working tree were not desirable, and "git checkout --
      $that_path" to revert them before continuing.  Before
      deciding to revert, the user may want to check what the
      difference is by running "git diff -- $that_path" so
      suggesting these two might also be helpful.

 1-3. The user wants to keep that change a strictly local change
      in the working tree (this is often very useful and making
      "commit -a" the default will not be acceptable unless
      there is a very compelling reason to do so).  This means
      the suggestion we would make should clearly be
      _suggestion_.

The earlier wording was bad in that it suggested to use a
Plumbing command update-index, but was attempting to convey that
it was merely a conditional suggestion by saying "use it TO MARK
FOR COMMIT", implying that if the user does not want to mark
them for commit, it is Ok not to use update-index.

When a merge is in progress, we would have .git/MERGE_HEAD and
that would be the way to tell case 2.  In that case, the next
user action would be:

 2-1. The user resolves conflicts and marks them as resolved,
      with update-index (or "git mark-resolved"), to prepare the
      index for the merge commit.  But this is not done for
      "Changed but not updated" files but "unmerged" files.  We
      should strongly suggest not to do _anything_ to "Changed
      but not updated" files here.

 2-2. The user decides this conflict is too much to handle right
      now, and abandones the change by "git reset --hard".  This
      would lose the local changes ("Changed but not updated"),
      so we should suggest to save the change before doing so.

	If you are going to abandone this merge with "reset
	--hard", your changes to these files will be lost.  You
	can save them with "git diff HEAD -- $this_path
	$that_path..."

      which is probably too long for that part of the output but
      that is what we would want to say if we want to be
      helpful.

When either rebase without --merge or am is in progress, there
would be .dotest/ directory (whose name could be changed but I
think this was a mistake and we would be better off using fixed
names for this kind of application) for git-status to notice.
The next user action would be:

 3-1. The user resolves the conflict or manually apply the
      patch, update-index the paths involved and proceeds with
      "rebase --continue" or "am --resolved".  "Changed but not
      updated" paths should not be touched in this case,
      similarly to 2-1.

 3-2. The user gives up.  Same as 2-2.

Designing for the "rebase --merge" case and coming up with other
cases are left as exercise to the list for further discussion.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 20:56       ` Carl Worth
@ 2006-11-15  0:31         ` Junio C Hamano
  2006-11-15  4:08           ` Petr Baudis
  2006-11-15 20:51           ` Carl Worth
  2006-11-17 20:30         ` Steven Grimm
  1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15  0:31 UTC (permalink / raw)
  To: Carl Worth; +Cc: git, Andy Whitcroft, Petr Baudis

Carl Worth <cworth@cworth.org> writes:

> On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:
>> Hmm, did they (not) consider Cogito? They wouldn't have those issues.
>
> I didn't ask.
>
> Frankly, I don't see a lot of value in the git/cogito split right now.
> ...
> It's great that git is written in a script-friendly way so that new
> interfaces can be built on top of it. And I think the benefits of new
> user interfaces are clear when they work in fundamentally different
> ways, (say, being operated through a GUI). But where git and cogito
> are both command-line utilities and have the same basic functionality,
> ...
> There are some things that cogito does that git does not that I would
> like to have in git.
> ...
> I don't see any defining difference that justifies cogito's
> existence ("hide the index" maybe? let's just hide it a tiny bit more
> in git). And I would like to help work to get the remaining good
> stuff that has been proven in cogito---to get it pushed down into git
> itself.

I am of two minds here.

I do not think the Porcelain-ish UI that is shipped with git
should be taken with the same degree of "authority" as git
Plumbing.  The plumbing needed to have something that worked for
one particular workflow (namely, workflow of the people in the
integrator role of kernel-style project) and that is where the
current set of Porcelain-ish originates.  Linus works primarily
as an integrator so the toolsets he did tend to be more pleasant
to use for integrators and less so for contributors.  I started
as a contributor and added some commands like format-patch and
rebase that Linus never would have felt the need for.  I think
single isolated developers, contributors and CVS style shared
repository usage could be a lot improved because neither of us
were concentrating in their workflows.  This needs somebody
motivated enough to improve things in that area.  For example,
StGIT with its 'float' command is a great improvement over what
rebase does for people in the contributor role.

By now, perhaps git may be good enough for the kernel folks,
even for those not in the integrator role, but I have no doubt
that they have many dislikes to the way some commands work.
They and X.org folks are using git primarily because Linus and
Keith forced them to ;-), and being interoperable is more
important than having to tolerate sucky UI here and there.
Everybody knows that git Porcelain-ish sucks, and making it more
usable is a worthy goal.

But making it more usable for whom is a big question.  

Quite frankly, I do not think there can be _the_ single UI that
would satisfy different types of workflows for some of the
commands.  The commands related to software archaeology, in
which my main interest and strength lie, would easily be usable
across workflows, but commands to build commits locally and
propagate them to and from other repositories would be affected
by the workflow.

For example, fetching and merging from many places without
necessarily having corresponding tracking branches is a great
thing for people in the integrator role.  On the other hand, for
people doing CVS-style centralized repository interaction, it is
often more useful to have tracking branches.  You could support
both but it has been painful.

For another example, having a commit command to commit
everything by default is disastrous for people who allow their
workflows to often be interrupted.  When I respond to a message
from the list with an example patch, my repository is often in
the middle of doing something completely unrelated, and I edit
and make diff to send the message out and I do not necessarily
revert that change afterwards immediately.  For more organized
people it may not be a problem so you either support both types
of workflows or do a specialized toolset.

It is not just command line syntax and the defaults, but
concepts as well.  People in the integrator role often need to
deal with merges and you would need to be aware of the role of
the index and need to be able to manipulate the index, a lot
more often than people in the contributor role.  To satisify
both kinds of workflows, you would either have switches, or do a
specialized toolset, like Cogito, that tries to hide the index.

A Porcelain that does a very similar thing in slightly different
way is obviously a waste, but otherwise I do not think it is a
problem to have different Porcelains.  StGIT does not compete
with the "sucky" Porcelain-ish shipped with git but makes the
user's life a lot more pleasant by complementing what the sucky
one does not do well.  It is not very useful while I am playing
the integrator role, but when I am doing my own thing it is a
great addition to my toolchest.

I am from the camp that does _not_ want to hide the index, so
obviously I do not see any value in its effort to hide the
index.  But other aspects of it, most notably being friendly to
simpler workflows, is a very good thing.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 22:56             ` Junio C Hamano
@ 2006-11-15  1:48               ` Nicolas Pitre
  2006-11-15  2:10                 ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15  1:48 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Tue, 14 Nov 2006, Junio C Hamano wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > On Tue, 14 Nov 2006, Jakub Narebski wrote:
> >
> >> The git interface refactoring should be I think the cause for git 2.0.0
> >> release...
> >
> > Good idea indeed.
> 
> We need to avoid user confusion, so making a command that used
> to do one thing to suddenly do something completely different is
> a no-no.  However, I do not think it needs to wait for 2.0.0.
> We can start with a separate namespace (or even a separate
> "Improved git UI project") and introduce the "improved UI set"
> in 1.5.0 timeframe.

Dunno.  I feel this is a bit overboard.  Actually the naming problem is 
rather localized to one command, namely git-pull.  In my opinion going 
with yet another namespace which would rather add to the confusion not 
clear it.

The best way to avoid user confusion is to remove the source of the 
confusion not let it live.  In other words I think we should _fix_ 
git-pull instead of replacing it.  People are already confused about it 
so simply fixing this command will have a net confusion reduction.  Yet 
we're not talking about "suddenly doing something completely different" 
either.  If git-pull doesn't merge automatically anymore it is easy to 
tell people to use git-merge after a pull.

"You pull the remote changes with 'git-pull upstream,, then you can 
merge them in your current branch with 'git-merge upstream'."

Isn't it much simpler to understand (and to teach) that way?

Also I don't think using git-upload and git-download is much better.  
This adds yet more commands that do almost the same as existing ones but 
with a different name which is yet not necessarily fully adequate.  I 
for example would think that "download" is more like git-clone than 
git-fetch or git-pull.

Let's face it: HG got it right with pull and push and newbies have much 
less difficulty grokking it.  We screwed it by not using the most 
intuitive semantic of a pull and locking the word "pull" away is not the 
better solution given all considerations. Why just not admit it and 
avoid being different than HG just for the sake of it?



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  1:48               ` Nicolas Pitre
@ 2006-11-15  2:10                 ` Junio C Hamano
  2006-11-15  2:27                   ` Michael K. Edwards
                                     ` (2 more replies)
  0 siblings, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15  2:10 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git

Nicolas Pitre <nico@cam.org> writes:

> "You pull the remote changes with 'git-pull upstream,, then you can 
> merge them in your current branch with 'git-merge upstream'."
>
> Isn't it much simpler to understand (and to teach) that way?

If it were "you download the remote changes with 'git download
upstream' and then merge with 'git merge'", then perhaps, but if
you used the word "pull" or "fetch", I do not think so.

I would be all for changing the semantics of "pull" from one
thing to another, if the new semantics were (1) what everybody
welcomed, (2) what "pull" traditionally meant everywhere else.
In that case, we have been misusing it to be confusing to
outsiders and I agree it makes a lot of sense to remove the
source of confusion.  But I do not think CVS nor SVN ever used
the term, and I was told that BK was what introduced the term,
and the word meant something different from what you are
proposing.

You have to admit both pull and fetch have been contaminated
with loaded meanings from different backgrounds. I was talking
about killing the source of confusion in the longer term by
removing fetch/pull/push, so we are still on the same page.

That's where my "you download from the upstream and merge" comes
from.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  2:10                 ` Junio C Hamano
@ 2006-11-15  2:27                   ` Michael K. Edwards
  2006-11-15  4:20                   ` Nicolas Pitre
  2006-11-15 20:12                   ` Petr Baudis
  2 siblings, 0 replies; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-15  2:27 UTC (permalink / raw)
  To: git

I would kind of like to see "git poll" -- visit all remote branches,
fetching objects and tags into the local repository, so that I can
inspect changes off-line and merge, cherry-pick, etc. to my heart's
content.  That would fit the platform integrator's workflow nicely --
"git poll" into a tracking tree, do some merges there (such as
backporting a subsystem to a "stable" base kernel), then merge this
backport branch to each platform working copy and cherry-pick other
changes as necessary.

Cheers,

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  0:31         ` Junio C Hamano
@ 2006-11-15  4:08           ` Petr Baudis
  2006-11-15  4:33             ` Junio C Hamano
  2006-11-15 10:05             ` Jakub Narebski
  2006-11-15 20:51           ` Carl Worth
  1 sibling, 2 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-15  4:08 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Carl Worth, git, Andy Whitcroft

On Wed, Nov 15, 2006 at 01:31:50AM CET, Junio C Hamano wrote:
> Carl Worth <cworth@cworth.org> writes:
> 
> > On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:
> >> Hmm, did they (not) consider Cogito? They wouldn't have those issues.
> >
> > I didn't ask.
> >
> > Frankly, I don't see a lot of value in the git/cogito split right now.
> > ...
> > It's great that git is written in a script-friendly way so that new
> > interfaces can be built on top of it. And I think the benefits of new
> > user interfaces are clear when they work in fundamentally different
> > ways, (say, being operated through a GUI). But where git and cogito
> > are both command-line utilities and have the same basic functionality,
> > ...
> > There are some things that cogito does that git does not that I would
> > like to have in git.
> > ...
> > I don't see any defining difference that justifies cogito's
> > existence ("hide the index" maybe? let's just hide it a tiny bit more
> > in git). And I would like to help work to get the remaining good
> > stuff that has been proven in cogito---to get it pushed down into git
> > itself.
> 
> I am of two minds here.
> 
> I do not think the Porcelain-ish UI that is shipped with git
> should be taken with the same degree of "authority" as git
> Plumbing.
..snip passage about workflows..

Controversy's fun, so...

<Cogito maintainer hat _off_> (But yeah, it still looks silly that I'm
saying this.)

 From the current perspective, I think it has been a mistake that the
porcelain and plumbing was not kept separate in independent packages,
and perhaps even maintained separately (and perhaps not; at least having
a single tree with plumbing/ and porcelain/ directories and separate
packages in distributions might already help something), so that "git"
would be kept as a kind of library and then there would be a separate
package providing an interface to it. Or you could select one of several
packages. Not only would that make Cogito prevail in the world and bring
me a flood of marriage proposals, but look at how would it help the
general public:

  (i) Clearly divided porcelain/plumbing interface, so that you can
really isolate the two UI-wise; endless confusion reigns there now. Is
git-update-index porcelain or plumbing? _You_ call git-merge a proper
porcelain? From my perspective, git-update-ref is as plumbing as it
gets, but it's classified as porcelain. Etc, etc. This would be by far
the most important advantage.

  (ii) The plumbing and porcelain would not share the same namespace,
leading to clearer UI. (I'm just inflating (i).)

  (iii) The documentation would not be a strange mix of porcelain and
plumbing. (More (i) inflation.)

  (iv) (i) is troublesome because I have a feeling that Junio declared
several times that he doesn't care that much about stable API for
porcelain compared to the plumbing. But with the current mix it's
desirable to use some porcelain even in other porcelains and in scripts.

  (v) Git would be properly libified by now. If you wanted to convert
bits of porcelain to C, it would be at least much higher priority.

  (vi) You wouldn't need to make the gruesome choice on what is the
canonical workflow the _the_ Git porcelain supports (see the snipped
passage). Or you would, but it would have less impact.

  (vii) The world would be a happier place.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  2:10                 ` Junio C Hamano
  2006-11-15  2:27                   ` Michael K. Edwards
@ 2006-11-15  4:20                   ` Nicolas Pitre
  2006-11-15  4:58                     ` Junio C Hamano
  2006-11-15 18:03                     ` Linus Torvalds
  2006-11-15 20:12                   ` Petr Baudis
  2 siblings, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15  4:20 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Tue, 14 Nov 2006, Junio C Hamano wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > "You pull the remote changes with 'git-pull upstream,, then you can 
> > merge them in your current branch with 'git-merge upstream'."
> >
> > Isn't it much simpler to understand (and to teach) that way?
> 
> If it were "you download the remote changes with 'git download
> upstream' and then merge with 'git merge'", then perhaps, but if
> you used the word "pull" or "fetch", I do not think so.
> 
> I would be all for changing the semantics of "pull" from one
> thing to another, if the new semantics were (1) what everybody
> welcomed, (2) what "pull" traditionally meant everywhere else.
> In that case, we have been misusing it to be confusing to
> outsiders and I agree it makes a lot of sense to remove the
> source of confusion.  But I do not think CVS nor SVN ever used
> the term, and I was told that BK was what introduced the term,
> and the word meant something different from what you are
> proposing.
> 
> You have to admit both pull and fetch have been contaminated
> with loaded meanings from different backgrounds. I was talking
> about killing the source of confusion in the longer term by
> removing fetch/pull/push, so we are still on the same page.
> 
> That's where my "you download from the upstream and merge" comes
> from.

But the fact is that HG (which has a growing crowd of happy campers, 
maybe even larger than the BK crowd now) did work with and got used to a 
sensible definition of what a "pull" is.  This means that their 
definition is becoming rather more relevant with time than what it used 
to, and because it is a saner definition than what GIT has for the same 
word which HG users really have no issue with, I think we really should 
leverage the "common wisdom" and consider aligning ourselves with them 
in this case rather than trying to go into a totally different 
direction.  We simply won't gain anything trying to teach people "a pull 
in HG is a download in GIT".  If a pull becomes the same thing for both 
then it's one less oddball in the GIT interface.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 22:50           ` Junio C Hamano
@ 2006-11-15  4:32             ` Nicolas Pitre
  2006-11-15  5:35               ` Junio C Hamano
                                 ` (3 more replies)
  0 siblings, 4 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15  4:32 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Andy Whitcroft, Carl Worth

On Tue, 14 Nov 2006, Junio C Hamano wrote:

> Junio C Hamano <junkio@cox.net> writes:
> 
> >  - I think it would be sensible to make remote tracking branches
> >    less visible.  For example:
> >...
> >  - "git merge" to merge another branch into the current would
> >    make sense.  "git pull . remotes/origin/next" is showing too
> >    much implementation detail.  It should just be:
> >
> > 	git merge origin#next
> 
> This and other examples in "making remote tracking branches less
> visible" are hard to read because I used the word "origin" in
> two different sense.  So here is a needed clarification.
> 
> If you have remotes/upstream that says:
> 
> 	URL: git://git.xz/repo.git
>         Pull: refs/heads/master:remotes/origin/master
>         Pull: refs/heads/next:remotes/origin/next
> 
> Then, currently the users need to say:
> 
> 	git diff remotes/origin/master
>         git merge remotes/origin/next
> 
> By "making tracking branches less visible", what I mean is to
> let the users say this instead:
> 
> 	git diff upstream
>         git merge upstream#next

What is the point of hiding tracking branches?  Why just not making them 
easier to use instead?  There are currently so many ways to specify 
remote branches that even I get confused.

OK..... let's pretend this is my follow-up to your "If I were redoing 
git from scratch" query.  Actually I would not redo it from scratch 
since the vast majority of it is rather sane already.  But here's some 
changes that I would do:

1) make "git init" an alias for "git init-db".

What's the point of "-db"?  Sure we're initializing the GIT database.  
But who cares?  The user doesn't care if GIT uses a "database" or 
whatever.  And according to some people's definition of a "database" it 
could be argued that GIT doesn't use a database at all in the purist 
sense of it. What the user wants is to get started and "init" (without 
the "-db" is so much more to the point. Doesn't matter if incidentally 
it happens to be the same keyword HG uses for the same operation because 
we are not afflicted by the NIH disease, right? And it has 3 chars less 
to type which is for sure a premium improvement to the very first GIT 
user experience!

2) "pull" and "push" should be symmetrical operations

They are symmetrical in the dictionary and in people's mind.  OK but what 
if I merge content from another _local_ branch into the current one?  
Isn't that kind of a pull as well?  Answer: NO IT IS NOT!  Reason: 
because we already have "merge" for that very operation for damn sake!  
And because "merging" isn't a synonym for "pulling" at all, we cannot 
pretend it should sort of become more true if taken the other way 
around.

Actually, if we _merge_ stuff together, we certainly have to /pull/ some 
of it, meaning that "merge" might imply a "pull", even in real life 
situations outside of the GIT context (think merging Vodka and Kahlua in 
a glass where you might have to pull the Vodka bottle out of the freezer 
before you can merge it). And thankfully we got it right with git-merge 
which can take either a branch or an URL as argument which in the later 
case will perform a pull implicitly (OK currently a fetch but you know 
what I mean).

But trying to put in people's head that "pulling" implies a "merge"?  No 
that doesn't work really well.  OK if you pull too hard on the Vodka 
bottle that might imply a merge at some point but it would certainly be 
accidental.  And it is not without coincidence that some people had 
accidental GIT merges by using git-pull.

Conclusion:  git-pull must not perform any merge.  It is the symmetrical 
operation of a push meaning that it pulls content from a remote branch 
and does no more.  People understands that pretty well, .  This makes 
git-fetch redundant (or an alias to git-pull) in that case, and again we 
don't mind it becoming similar to in HG because we admit HG was right 
about it.

3) remote branch handling should become more straight forward.

OK! Now that we've solved the pull issue and that everybody agrees with 
me (how can't you all agree with me anyway) let's have a look at remote 
branches.  It should be simple:

a)	git-pull git://repo.com/time_machine.git

This pulls every branches from the time_machine.git repository and 
create identically named branches locally, except for the remote 
master becoming origin locally.  All those branches are marked read-only 
(i.e. cannot commit to them) and _each_ of those branches get an URL 
associated to them somehow (the association is an implementation 
detail).

If then you do:

b)	git-pull origin

Then it will pull the git://repo.com/time_machine.git:master branch into 
the local "origin" branch.  IOW, local tracking branches becomes 
synonyms for their remote URLs after they've been pulled once.  If the 
remote branch "next" became a local "next" with the first pull (because 
it didn't specify any branch meaning that they were all pulled), doing 
a:

c)	git-pull next

would actually be the same as:

d)	git-pull git://repo.com/time_machine.git:next

Now to have different remote and local names for those tracking 
branches:

e)	git-pull git://repo.com/time_machine.git:master upstream

would be a variation where a remote branch gets a different local name. 
This pulls the remote master branch but calls it "upstream" locally.  
If that "upstream" branch does exist locally already then fail with 
appropriate error message, unless the local branch happens to have the 
same URL attribute already.  You then have two local branches tracking 
the same remote branch which is weird but still fine if someone wants
to have different views (today's pull and yesterday's pull).  This is 
not necessarily something to encourage but only a fallout of the branch 
semantic.  And again a simple:

f)	git-pull upstream

would update the "upstream" branch from the remote master branch.

I think the concept of "branch group" should be preserved too.  So if 
you create a group called "warp", then add "origin", "next", and 
"upstream" to it, then:

g)	git-pull warp

would pull all the included branches.  One way to create a branch group 
with the initial pull is not to specify the remote branch but only the 
repository URL, like:

h)	git-pull git://repo.com/time_machine.git warp

Because no specific branch in the remote repository was specified just 
like in (a) then all branches are pulled, but because a local name was 
provided then this becomes a branch group.

Branch groups could be used to extend the branch namespace as well to 
avoid clashes with different remote repositories.  In this case the 
branch groups could be a way to arrange branches in a hierarchy so 
"warp" refer to all branches included in the warp group while 
"warp/upstream" refer to only one branch. In this case "upstream" and 
"warp/upstream" would be the same branch if "upstream" was effectively 
added to the "warp" group, but it doesn't need to be so.  And branches 
in a group don't have to come from the same remote repository either 
since the source of each branch (the URL) is a per branch attribute.

To make it "easy" on the user, I think that any branch (or tag) down the 
hierarchy should be used without the "path" leading to it if there is no 
conflict.  We already do that with heads and tags, So if for example the 
"warp" group contained a branch named "lightspeed" but no such branch 
(or tag) existed anywhere else then it could be referenced with simply 
"lightspeed" or "warp/lightspeed".

Then you don't need any strange scheme for diff and merge.  Just using 
"git-diff upstream" or "git-merge origin next" suffice.  Oh and I don't 
think it would be a good idea to have a completely separate namespace 
for local vs remote aka tracking branches.  Maybe in .git/refs/ they 
should be separate to distinguish which ones are read-only remote 
tracking ones and which ones are local, but that must not be forced on 
the UI.

Thinking about it some more, maybe (a) should create a default branch 
group if the remote repository has more than one branches, say "origin".  
This way, git-pull without any argument would be the same as 
"git-pull origin" by default.  If "origin" is a single branch then 
(git-pull" would pull only one branch, but if "origin" is a branch group 
then all included branches would be pulled.

This becomes formalized as:

	git_pull [<URL>] [<local_name>]

If <URL> includes a branch name then <local_name> is a single branch 
name.  If <URL> doesn't include any branch name then <local_name> 
becomes a local branch group name containing all branches in the remote 
repository. If <URL> is specified but not <local_name> then <local_name> 
is set to "origin" by default, unless it already exists in which case it 
is an error and the pull fails.  If <URL> is not specified then the URL 
attribute to the specified branch(es) is used.  If nothing is specified 
then "origin" is used for <local_name> by default and URL attribute of 
the origin branch or the origin branch group is/are used.

*****

OK I think this is enough for now. I know that parts of what I've said 
can already be found in GIT, but I wanted the explanation to be 
complete and therefore tentatively coherent.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  4:08           ` Petr Baudis
@ 2006-11-15  4:33             ` Junio C Hamano
  2006-11-15  4:46               ` Nicolas Pitre
  2006-11-15 20:39               ` Petr Baudis
  2006-11-15 10:05             ` Jakub Narebski
  1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15  4:33 UTC (permalink / raw)
  To: Petr Baudis; +Cc: git

Petr Baudis <pasky@suse.cz> writes:

> On Wed, Nov 15, 2006 at 01:31:50AM CET, Junio C Hamano wrote:
>> 
>> I am of two minds here.
>> 
>> I do not think the Porcelain-ish UI that is shipped with git
>> should be taken with the same degree of "authority" as git
>> Plumbing.
> ..snip passage about workflows..
>
> Controversy's fun, so...
>
> <Cogito maintainer hat _off_> (But yeah, it still looks silly that I'm
> saying this.)

It appears that you are not grumpy as you were anymore ;-).  I
mostly agree with what you said in your message.

> (i) Clearly divided porcelain/plumbing interface, so that you can
> really isolate the two UI-wise; endless confusion reigns there now. Is
> git-update-index porcelain or plumbing? _You_ call git-merge a proper
> porcelain? From my perspective, git-update-ref is as plumbing as it
> gets, but it's classified as porcelain. Etc, etc. This would be by far
> the most important advantage.

Yes.  The current "merge" started its life as Linus's porcelain
(we did not have fetch and pull infrastructure back then) but
quickly has become just a helper for pull to produce a merge
commit.  If anybody thinks its UI is good as a general end-user
level command, there is a need for "head examination".

As you say, update-ref is as plumbing as it gets and it should
not be listed as Porcelain; I am a bit surprised that it is
labelled as such myself.

No disagreement here, nor (ii) nor (iii).

>   (ii) The plumbing and porcelain would not share the same namespace,
> leading to clearer UI. (I'm just inflating (i).)
>
>   (iii) The documentation would not be a strange mix of porcelain and
> plumbing. (More (i) inflation.)
>
>   (iv) (i) is troublesome because I have a feeling that Junio declared
> several times that he doesn't care that much about stable API for
> porcelain compared to the plumbing. But with the current mix it's
> desirable to use some porcelain even in other porcelains and in scripts.

This is true and it is a problem.

While we encourage Porcelain writers to use plumbing in order to
give git Porcelain-ish more freedom to evolve to give better UI
for humans, not having a clear distinction between the two makes
it harder.

>   (v) Git would be properly libified by now. If you wanted to convert
> bits of porcelain to C, it would be at least much higher priority.

I am not sure about "libified" part and I do not know what bits
of porcelain wants to become C right now.  But I do not think
this point is important part of your list.

>   (vi) You wouldn't need to make the gruesome choice on what is the
> canonical workflow the _the_ Git porcelain supports (see the snipped
> passage). Or you would, but it would have less impact.

Yes.  This is really important.

Linus and me having done Porcelain-ish that supports integrator
role workflow better than other workflows such as contributor
role should not discourage people from working on alternative or
complementary Porcelains to help other workflows better (see the
snipped passage).

StGIT sets a great example, and efforts like it is encoraged
more.

I think both Linus and myself tried to make it clear that the
purpose of Porcelain-ish that comes with core git is 50% to make
plumbing (perhaps minimally) usable and the other 50% to serve
as an example for Porcelain writers to learn how to use the
plumbing, but we should probably have stressed the latter
better.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  4:33             ` Junio C Hamano
@ 2006-11-15  4:46               ` Nicolas Pitre
  2006-11-15 10:09                 ` Jakub Narebski
  2006-11-15 20:39               ` Petr Baudis
  1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15  4:46 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Petr Baudis, git

On Tue, 14 Nov 2006, Junio C Hamano wrote:

> Yes.  The current "merge" started its life as Linus's porcelain
> (we did not have fetch and pull infrastructure back then) but
> quickly has become just a helper for pull to produce a merge
> commit.  If anybody thinks its UI is good as a general end-user
> level command, there is a need for "head examination".

If you mean "git merge" it sure needs to be brought forward.  It can't 
be clearer than:

	git-merge the_other_branch

or

	git-merge git://repo.com/time_machine.git

to instantaneously understand what is going on.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  4:20                   ` Nicolas Pitre
@ 2006-11-15  4:58                     ` Junio C Hamano
  2006-11-15 18:03                     ` Linus Torvalds
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15  4:58 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git

Nicolas Pitre <nico@cam.org> writes:

> ...  We simply won't gain anything trying to teach people "a pull 
> in HG is a download in GIT".  If a pull becomes the same thing for both 
> then it's one less oddball in the GIT interface.

I personally do not have any issue with that, as long as you
would help us convert existing users that what was known as pull
is not available and new pull means fetching only.

If I recall correctly in this thread, you also advocated to
always have tracking branches.  I am a bit worried about losing
the promiscuous pull usage, which can easily become a regression
for people like Linus in the integrator role unless done with an
escape hatch.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  4:32             ` Nicolas Pitre
@ 2006-11-15  5:35               ` Junio C Hamano
  2006-11-15  6:18                 ` Shawn Pearce
  2006-11-15 14:01                 ` Johannes Schindelin
  2006-11-15  9:17               ` Andy Parkins
                                 ` (2 subsequent siblings)
  3 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15  5:35 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git, Andy Whitcroft, Carl Worth

Nicolas Pitre <nico@cam.org> writes:

> What is the point of hiding tracking branches?  Why just not making them 
> easier to use instead?  There are currently so many ways to specify 
> remote branches that even I get confused.

Ok, I think in essence we are saying the same thing except I
went overboard by suggsting to extend sha1_name to also look at
.git/remotes/$name which is not necessary, because we already
have the .git/refs/remotes/%s/HEAD magic there.  Consider the
suggestion of "upstream#next" syntax retracted, please.

> 1) make "git init" an alias for "git init-db".

Or even better, have "gh init".

> 2) "pull" and "push" should be symmetrical operations

I think that makes a lot of sense to have "gh pull" and "gh
push" as symmetric operations, and make "gh merge" do the
fast-forward and 3-way merge magic done in the current "git
pull".  These three words would have a lot saner meaning.

> 3) remote branch handling should become more straight forward.
>
> OK! Now that we've solved the pull issue and that everybody agrees with 
> me (how can't you all agree with me anyway) let's have a look at remote 
> branches.

I would probably prefer making the default namespace under
.git/refs/remotes/remote-name for the tracking branches this
proposal creates, but other than that I agree with the general
direction this proposal is taking us, including branch groups.
We have .git/refs/remotes/%s/HEAD magic so I do not think we
even need to treat one branch repository any specially as you
suggsted.

The reason I am suggsting "gh" instead of "git" is primarily to
deal with stale documentation people would find googling.  I can
easily see people get confused by reading "pull = fetch + merge"
from either mailing list archive or Git cheat sheet various
projects seem to have developed.

It does not mean we need to redo _all_ UI.  I think most of the
archaeology commands have sane UI so during the transition
period (git 1.99) we can have "git log" and "gh log" which are
one and the same program, and perhaps git 2.0 can be shipped
with clear distinction between plumbing (i.e. git-update-index
and friends) and porcelain (e.g. "gh pull" that only fetches but
with the user friendliness you outlined here), with backward
compatibility wart to help old timers (e.g. "git pull" that
still does "git fetch" followed by "git merge").


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  5:35               ` Junio C Hamano
@ 2006-11-15  6:18                 ` Shawn Pearce
  2006-11-15  6:30                   ` Junio C Hamano
  2006-11-15 14:01                 ` Johannes Schindelin
  1 sibling, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-15  6:18 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nicolas Pitre, git, Andy Whitcroft, Carl Worth

Junio C Hamano <junkio@cox.net> wrote:
> Or even better, have "gh init".

Why gh?  Is Git just Mercurial backwards?  :)

I'm all in favor of this discussion, and in particular of just
breaking the entire UI in 2.0 by using a new frontend command.
I'm just not sure that "Mercurial backwards" describes Git well.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  6:18                 ` Shawn Pearce
@ 2006-11-15  6:30                   ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15  6:30 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: git

Shawn Pearce <spearce@spearce.org> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> Or even better, have "gh init".
>
> Why gh?  Is Git just Mercurial backwards?  :)
>
> I'm all in favor of this discussion, and in particular of just
> breaking the entire UI in 2.0 by using a new frontend command.
> I'm just not sure that "Mercurial backwards" describes Git well.

I do not have any obsession to any name as long as it is
different from "git" to avoid confusion coming from older
documents that would be found by googling.  gh was just
shorthand for "git for humans" (and easy to type with index
fingers).  I think I listed a few other possibilities in my
previous message.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  4:32             ` Nicolas Pitre
  2006-11-15  5:35               ` Junio C Hamano
@ 2006-11-15  9:17               ` Andy Parkins
  2006-11-15  9:59                 ` Jakub Narebski
                                   ` (3 more replies)
  2006-11-15 12:15               ` Andreas Ericsson
  2006-11-16 13:58               ` Petr Baudis
  3 siblings, 4 replies; 601+ messages in thread
From: Andy Parkins @ 2006-11-15  9:17 UTC (permalink / raw)
  To: git

On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:

> OK..... let's pretend this is my follow-up to your "If I were redoing

Personally, I agree with almost everything in this email.  Except the 
implementation of point 3.

> 3) remote branch handling should become more straight forward.

I was completely confused by this origin/master/clone stuff when I started 
with git.  In hindsight, now I understand git a bit more, this is what I 
would have liked:

 * Don't use the name "origin" twice.  In fact, don't use it at all.  In a 
distributed system there is no such thing as a true origin.

 * .git/remotes/origin should be ".git/remotes/default".   "origin" is only 
special because it is the default to push and pull - it's very nice to have a 
default, but it should therefore be /called/ "default".

 * Whatever git-clone calls the remote, it should be matched by a directory 
in .git/refs/remotes.  So .git/remotes/$name contains "Pull"s to get all the 
remote branches to .git/refs/remotes/$name/*.   This implies that 
git /always/ does --use-separate-remote in clone.  If a branch is practically 
read-only it should be technically read-only too.

 * If clone really wants to have a non-read-only master, then that should 
be .git/refs/heads/master and will initialise 
to .git/refs/remotes/$name/master after cloning.  Personally I think this is 
dangerous because it assumes there is a "master" upstream - which git doesn't 
mandate at all.  Maybe it would be better to take the upstream HEAD and 
create a local branch for /that/ branch rather than require that it is 
called "master".

 * Ensuring we have /all/ upstream branches at a later date is hard, and not 
automatic.  Here is the .git/remotes/default file that should be possible:
    URL: git://host/project.git
    Pull: refs/heads/*:refs/remotes/default/*
   Now, every git-pull would check for new upstream branch refs and sync them 
into the local remotes list.  These are read-only so it'd be perfectly safe 
to delete any locally that no longer exist upstream.

 * git-clone should really just be a small wrapper around
    - git-init-db
    - create .git/remotes/default
    - maybe create specific .git/config
    - git-fetch default
   If git-clone does anything that can't be done with settings in the config 
and the remotes/default file then it's wrong.  The reason I say this is that 
as soon as git-clone has special capabilities (like --shared, --local 
and --reference) then you are prevented from doing magic with existing 
repositories.  For example; how do you create a repository that contains 
branches from two other local repositories that have the objects hard linked?

While I'm writing wishes, I'd like to jump on Junio's integration with other 
fetch-backends wish.  I use git-svn, and it would be fantastic if I could 
replace:

git-svn init --id upstream/trunk svn://host/path/trunk
git-svn fetch --id upstream/trunk
git-svn init --id upstream/stable svn://host/path/branches/stable
git-svn fetch --id upstream/stable

With a .git/remotes/svn
 SVN-URL: svn://host/path
 Pull: trunk:refs/remotes/upstream/trunk
 Pull: branches/stable:refs/remotes/upstream/stable
and
 git fetch svn

Obviously, the syntax is just made up; but you get the idea.  Even better, 
would be if it could cope with my "*" syntax suggested above:
 SVN-URL: svn://host/path
 Pull: trunk:refs/remotes/upstream/trunk
 Pull: branches/*:refs/remotes/upstream/*


There have been lots of "wishlist" posts lately; would it be useful if I tried 
to collect all these suggestions from various people into one place to try 
and get a picture of any consensus?



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  9:17               ` Andy Parkins
@ 2006-11-15  9:59                 ` Jakub Narebski
  2006-11-15 10:33                   ` Andy Parkins
  2006-11-15 15:41                 ` Nicolas Pitre
                                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15  9:59 UTC (permalink / raw)
  To: git

Andy Parkins wrote:

>  * Don't use the name "origin" twice.  In fact, don't use it at all.  In a 
> distributed system there is no such thing as a true origin.

The remote 'origin' is true origin of the repository: it is repository
we cloned this repository from.

I agree that having branch 'origin', at least in most common multi-branch
(multi-head) repository, is just confusing.

>  * Ensuring we have /all/ upstream branches at a later date is hard, and not 
> automatic.  Here is the .git/remotes/default file that should be possible:
>     URL: git://host/project.git
>     Pull: refs/heads/*:refs/remotes/default/*
>    Now, every git-pull would check for new upstream branch refs and sync them 
> into the local remotes list.  These are read-only so it'd be perfectly safe 
> to delete any locally that no longer exist upstream.

Very nice idea.
 
>  * git-clone should really just be a small wrapper around
>     - git-init-db
>     - create .git/remotes/default
>     - maybe create specific .git/config

I'm not sure about "create .git/remotes/default" part. Isn't git moving from
remotes file to having information about remotes (and branches) in config?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  4:08           ` Petr Baudis
  2006-11-15  4:33             ` Junio C Hamano
@ 2006-11-15 10:05             ` Jakub Narebski
  2006-11-15 10:25               ` Karl Hasselström
  1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15 10:05 UTC (permalink / raw)
  To: git

Petr Baudis wrote:

>   (i) Clearly divided porcelain/plumbing interface, so that you can
> really isolate the two UI-wise; endless confusion reigns there now. Is
> git-update-index porcelain or plumbing? _You_ call git-merge a proper
> porcelain? From my perspective, git-update-ref is as plumbing as it
> gets, but it's classified as porcelain. Etc, etc. This would be by far
> the most important advantage.

The problem is that one man's plumbing is another man porcelain.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  4:46               ` Nicolas Pitre
@ 2006-11-15 10:09                 ` Jakub Narebski
  2006-11-15 10:15                   ` Santi Béjar
  2006-11-15 14:56                   ` Nicolas Pitre
  0 siblings, 2 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15 10:09 UTC (permalink / raw)
  To: git

Nicolas Pitre wrote:

> On Tue, 14 Nov 2006, Junio C Hamano wrote:
> 
>> Yes.  The current "merge" started its life as Linus's porcelain
>> (we did not have fetch and pull infrastructure back then) but
>> quickly has become just a helper for pull to produce a merge
>> commit.  If anybody thinks its UI is good as a general end-user
>> level command, there is a need for "head examination".
> 
> If you mean "git merge" it sure needs to be brought forward.  It can't 
> be clearer than:
> 
>       git-merge the_other_branch
> 
> or
> 
>       git-merge git://repo.com/time_machine.git
> 
> to instantaneously understand what is going on.

You mean

      git merge git://repo.com/time_machine.git#branch

don't you (perhaps with 'master' as default branch)?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 10:09                 ` Jakub Narebski
@ 2006-11-15 10:15                   ` Santi Béjar
  2006-11-15 10:28                     ` Jakub Narebski
  2006-11-15 14:56                   ` Nicolas Pitre
  1 sibling, 1 reply; 601+ messages in thread
From: Santi Béjar @ 2006-11-15 10:15 UTC (permalink / raw)
  To: git

On 11/15/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Nicolas Pitre wrote:
>
> > On Tue, 14 Nov 2006, Junio C Hamano wrote:
> >
> >> Yes.  The current "merge" started its life as Linus's porcelain
> >> (we did not have fetch and pull infrastructure back then) but
> >> quickly has become just a helper for pull to produce a merge
> >> commit.  If anybody thinks its UI is good as a general end-user
> >> level command, there is a need for "head examination".
> >
> > If you mean "git merge" it sure needs to be brought forward.  It can't
> > be clearer than:
> >
> >       git-merge the_other_branch
> >
> > or
> >
> >       git-merge git://repo.com/time_machine.git
> >
> > to instantaneously understand what is going on.
>
> You mean
>
>       git merge git://repo.com/time_machine.git#branch
>
> don't you (perhaps with 'master' as default branch)?

perhaps with remote 'HEAD' as default branch?


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 10:05             ` Jakub Narebski
@ 2006-11-15 10:25               ` Karl Hasselström
  0 siblings, 0 replies; 601+ messages in thread
From: Karl Hasselström @ 2006-11-15 10:25 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

On 2006-11-15 11:05:26 +0100, Jakub Narebski wrote:

> The problem is that one man's plumbing is another man porcelain.

No; that way lies insanitation.

-- 
Karl Hasselström, kha@treskal.com

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 10:15                   ` Santi Béjar
@ 2006-11-15 10:28                     ` Jakub Narebski
  2006-11-16  2:43                       ` Petr Baudis
  0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15 10:28 UTC (permalink / raw)
  To: git

Santi Béjar wrote:

> On 11/15/06, Jakub Narebski <jnareb@gmail.com> wrote:

>> You mean
>>
>>       git merge git://repo.com/time_machine.git#branch
>>
>> don't you (perhaps with 'master' as default branch)?
> 
> perhaps with remote 'HEAD' as default branch?

No! HEAD might change without your notice, and you want to know
which branch you merge. With remotes the default could be first
branch in the pull/fetch list, but with bare URL...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  9:59                 ` Jakub Narebski
@ 2006-11-15 10:33                   ` Andy Parkins
  2006-11-15 10:48                     ` Karl Hasselström
  0 siblings, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2006-11-15 10:33 UTC (permalink / raw)
  To: git

On Wednesday 2006 November 15 09:59, Jakub Narebski wrote:

> >  * Don't use the name "origin" twice.  In fact, don't use it at all.  In
> > a distributed system there is no such thing as a true origin.
>
> The remote 'origin' is true origin of the repository: it is repository
> we cloned this repository from.

But that is not necessarily /the/ original, and "origin" is the absolute 
reference in maths.  It doesn't bother me that much I suppose, it's just that 
as far as unambiguous names go, I'm not wild about it - it's got too 
many "central repository" connotations, which is of course anathema to git.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 10:33                   ` Andy Parkins
@ 2006-11-15 10:48                     ` Karl Hasselström
  2006-11-15 11:28                       ` Andy Parkins
  0 siblings, 1 reply; 601+ messages in thread
From: Karl Hasselström @ 2006-11-15 10:48 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

On 2006-11-15 11:33:55 +0100, Andy Parkins wrote:

> But that is not necessarily /the/ original, and "origin" is the
> absolute reference in maths. It doesn't bother me that much I
> suppose, it's just that as far as unambiguous names go, I'm not wild
> about it - it's got too many "central repository" connotations,
> which is of course anathema to git.

To me, "origin" just means "where <whatever we're talking about>
originated". If you think of it that way, it's perfectly obvious that
each repository can have its own origin.

-- 
Karl Hasselström, kha@treskal.com

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 10:48                     ` Karl Hasselström
@ 2006-11-15 11:28                       ` Andy Parkins
  0 siblings, 0 replies; 601+ messages in thread
From: Andy Parkins @ 2006-11-15 11:28 UTC (permalink / raw)
  To: git

On Wednesday 2006 November 15 10:48, Karl Hasselström wrote:

> To me, "origin" just means "where <whatever we're talking about>
> originated". If you think of it that way, it's perfectly obvious that
> each repository can have its own origin.

Of course.  I wasn't saying that I didn't understand why origin was chosen.  
It's not a completely crazy name - it does have /a/ meaning.  However, it's 
not an unambiguous meaning.  What if the repository I clone was itself a 
clone?  What if the repository it cloned was pulling from three other 
repositories?  What if those three repositories pull/push from/to each other?

  * -- * -- *
   \   |   / \
    \  |  /  /
     \ | /  / 
       *   /
       |  / 
       | /
       * <--- "origin"
       |
       * <--- cloned repository

The name "origin" is too close to having an "ultimate source" feel to it IMO.  
In a distributed system, it's not the right idea to be pushing.  After the 
clone is complete, the "origin" is no more special than any other repository, 
and if you felt like it you could change the URL for "origin" and it would 
make very little difference to you.

In short: I don't think "origin" is wrong, I just think it's not right.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  4:32             ` Nicolas Pitre
  2006-11-15  5:35               ` Junio C Hamano
  2006-11-15  9:17               ` Andy Parkins
@ 2006-11-15 12:15               ` Andreas Ericsson
  2006-11-15 12:31                 ` Jakub Narebski
  2006-11-16 13:58               ` Petr Baudis
  3 siblings, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-11-15 12:15 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Junio C Hamano, git, Andy Whitcroft, Carl Worth

Nicolas Pitre wrote:

[ axed a lot of stuff that I didn't fully grok ]

> 
> This becomes formalized as:
> 
> 	git_pull [<URL>] [<local_name>]
> 
> If <URL> includes a branch name then <local_name> is a single branch 
> name.  If <URL> doesn't include any branch name then <local_name> 
> becomes a local branch group name containing all branches in the remote 
> repository.

I would change that so "local_name" is always a branch group name, but 
branch group names can be used as refs. That is,

git pull startrek.com/kirk.git:master kirk

would always create the branch-head .git/refs/remote/kirk/master which 
for short can be referenced as just "kirk" (barring clashes ofc), so 
long as it only has one branch tracked.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 12:15               ` Andreas Ericsson
@ 2006-11-15 12:31                 ` Jakub Narebski
  0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15 12:31 UTC (permalink / raw)
  To: git

Andreas Ericsson wrote:

> Nicolas Pitre wrote:
> 
> [ axed a lot of stuff that I didn't fully grok ]
> 
>> 
>> This becomes formalized as:
>> 
>>      git_pull [<URL>] [<local_name>]
>> 
>> If <URL> includes a branch name then <local_name> is a single branch 
>> name.  If <URL> doesn't include any branch name then <local_name> 
>> becomes a local branch group name containing all branches in the remote 
>> repository.
> 
> I would change that so "local_name" is always a branch group name, but 
> branch group names can be used as refs. That is,
> 
> git pull startrek.com/kirk.git:master kirk

I'd rather use Cogito (not gitweb) notation startrek.com/kirk.git#master
This way we can change the name of local branch
   startrek.com/kirk.git#master:kirk
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  5:35               ` Junio C Hamano
  2006-11-15  6:18                 ` Shawn Pearce
@ 2006-11-15 14:01                 ` Johannes Schindelin
  2006-11-15 15:03                   ` Sean
  2006-11-15 15:10                   ` Nicolas Pitre
  1 sibling, 2 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-15 14:01 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nicolas Pitre, git, Andy Whitcroft, Carl Worth

Hi,

On Tue, 14 Nov 2006, Junio C Hamano wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > 1) make "git init" an alias for "git init-db".
> 
> Or even better, have "gh init".

Please no. It only makes things even more confusing. "git init" is perfect 
as it is. We can always have internal aliases from "init-db" to "init" to 
account for older usages.

> > 2) "pull" and "push" should be symmetrical operations
> 
> I think that makes a lot of sense to have "gh pull" and "gh
> push" as symmetric operations, and make "gh merge" do the
> fast-forward and 3-way merge magic done in the current "git
> pull".  These three words would have a lot saner meaning.

I am really opposed to do "gh pull". Not only because of "gh" being 
completely confusing (we already _have_ "git", and for porcelains 
different TLAs), but "pull" _really_ is confusing by now. And Mercurial 
did not help one wit by insisting on their own interpretation.

Why not do something like "get/put" instead? It is

- easier to remember
- not bogus (AFAICT the meaning is not used in diametrical senses)
- shorter to type than download/upload

As for "git merge": Just by the number of arguments you can discern 
between the original usage and the new usage, so I am all in favour of 
replacing "git pull <blabla>" by "git merge <blabla>". Where "<blabla>" 
can be a branch or a remote or a URL (with cogito style #branchname).

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 10:09                 ` Jakub Narebski
  2006-11-15 10:15                   ` Santi Béjar
@ 2006-11-15 14:56                   ` Nicolas Pitre
  1 sibling, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 14:56 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

On Wed, 15 Nov 2006, Jakub Narebski wrote:

> Nicolas Pitre wrote:
> 
> > On Tue, 14 Nov 2006, Junio C Hamano wrote:
> > 
> >> Yes.  The current "merge" started its life as Linus's porcelain
> >> (we did not have fetch and pull infrastructure back then) but
> >> quickly has become just a helper for pull to produce a merge
> >> commit.  If anybody thinks its UI is good as a general end-user
> >> level command, there is a need for "head examination".
> > 
> > If you mean "git merge" it sure needs to be brought forward.  It can't 
> > be clearer than:
> > 
> >       git-merge the_other_branch
> > 
> > or
> > 
> >       git-merge git://repo.com/time_machine.git
> > 
> > to instantaneously understand what is going on.
> 
> You mean
> 
>       git merge git://repo.com/time_machine.git#branch
> 
> don't you (perhaps with 'master' as default branch)?

Something like that.  I wantee to enphasize on the "merge" command that 
should deal with, hey, merges.

I don't know if # is a good choice for branch indicator though.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 14:01                 ` Johannes Schindelin
@ 2006-11-15 15:03                   ` Sean
  2006-11-15 15:10                   ` Nicolas Pitre
  1 sibling, 0 replies; 601+ messages in thread
From: Sean @ 2006-11-15 15:03 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Junio C Hamano, Nicolas Pitre, git, Andy Whitcroft, Carl Worth

On Wed, 15 Nov 2006 15:01:47 +0100 (CET)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> I am really opposed to do "gh pull". Not only because of "gh" being 
> completely confusing (we already _have_ "git", and for porcelains 
> different TLAs), but "pull" _really_ is confusing by now. And Mercurial 
> did not help one wit by insisting on their own interpretation.

This makes a lot of sense.  The "git" command isn't damaged so bad
that it can't be saved in a backward compatible way, at least for
a transition period.  Adding a new command name seems like a step
backward.
 
> Why not do something like "get/put" instead? It is
> 
> - easier to remember
> - not bogus (AFAICT the meaning is not used in diametrical senses)
> - shorter to type than download/upload
> 
> As for "git merge": Just by the number of arguments you can discern 
> between the original usage and the new usage, so I am all in favour of 
> replacing "git pull <blabla>" by "git merge <blabla>". Where "<blabla>" 
> can be a branch or a remote or a URL (with cogito style #branchname).

Both these ideas sound like a step in the right direction too.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 14:01                 ` Johannes Schindelin
  2006-11-15 15:03                   ` Sean
@ 2006-11-15 15:10                   ` Nicolas Pitre
  2006-11-15 18:16                     ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 15:10 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git, Andy Whitcroft, Carl Worth

On Wed, 15 Nov 2006, Johannes Schindelin wrote:

> On Tue, 14 Nov 2006, Junio C Hamano wrote:
> 
> > Nicolas Pitre <nico@cam.org> writes:
> > 
> > > 2) "pull" and "push" should be symmetrical operations
> > 
> > I think that makes a lot of sense to have "gh pull" and "gh
> > push" as symmetric operations, and make "gh merge" do the
> > fast-forward and 3-way merge magic done in the current "git
> > pull".  These three words would have a lot saner meaning.
> 
> I am really opposed to do "gh pull". Not only because of "gh" being 
> completely confusing (we already _have_ "git", and for porcelains 
> different TLAs), but "pull" _really_ is confusing by now. And Mercurial 
> did not help one wit by insisting on their own interpretation.

I completely agree that creating yet another command prefix for 
basically the same tools would be a disaster.  We have "git" already so 
let's stick to it and make its usage just more sane.

> Why not do something like "get/put" instead? It is
> 
> - easier to remember
> - not bogus (AFAICT the meaning is not used in diametrical senses)
> - shorter to type than download/upload

Well, of all compromizes this is probably the best one so far.  I would 
have prefered to bite the bullet and fix "pull" instead of adding yet 
more commands.  But if the consensus is that there is no way on earth 
that "pull" can be salvaged then get/put is probably more enjoyable than 
download/upload.  This way pull/fetch/push could still be available 
(albeit burried somewhere out of sight).



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  9:17               ` Andy Parkins
  2006-11-15  9:59                 ` Jakub Narebski
@ 2006-11-15 15:41                 ` Nicolas Pitre
  2006-11-15 17:59                   ` Junio C Hamano
  2006-11-18 11:09                   ` Alan Chandler
  2006-11-15 17:55                 ` Junio C Hamano
  2006-11-16  3:53                 ` Petr Baudis
  3 siblings, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 15:41 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

On Wed, 15 Nov 2006, Andy Parkins wrote:

> On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:
> 
> > OK..... let's pretend this is my follow-up to your "If I were redoing
> 
> Personally, I agree with almost everything in this email.  Except the 
> implementation of point 3.
> 
> > 3) remote branch handling should become more straight forward.
> 
> I was completely confused by this origin/master/clone stuff when I started 
> with git.  In hindsight, now I understand git a bit more, this is what I 
> would have liked:
> 
>  * Don't use the name "origin" twice.  In fact, don't use it at all.  In a 
> distributed system there is no such thing as a true origin.

I agree, sort of.  Not because"origin" is ambigous as a name.  But 
rather because there is a magic translation from "master" to "origin", 
and I think this is wrong to do that.

As mentioned elsewhere (and let's start using "get" instead of "pull" as 
suggested by Johannes), a "get" should probably always create a branch 
group even if it contains only one branch.  This way the remote branch 
called "master" will still be called "master" locally, under the branch 
group used to represent the remote repository.  And if a local name is 
not provided then let's just call it "default".  This way, amongst the 
remote references, there would be a "default/master" that would be used 
when nothing else is provided by the user. So...

	git get repo.com/time_machine.git

would create a local branch named "remotes/default/master" if the remote 
repo has only a master branch.

Then, a simple:

	git merge

could be the same as

	git merge default

which would be equivalent to

	git merge default/master

Afterwards, because the "default" remote already exists, then:

	git get

would be the same as

	git get default

to get changes for all branches in the "default" remote branches, of 
which "master" might be the only one in the simple case.

But again I think it is important that the URL to use must be a per 
branch attribute i.e. attached to "default/master" and not just 
"default".  This way someone could add all branches of interest into the 
"default" group even if they're from different repositories, and a 
simple  get without any argument would get them all.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  9:17               ` Andy Parkins
  2006-11-15  9:59                 ` Jakub Narebski
  2006-11-15 15:41                 ` Nicolas Pitre
@ 2006-11-15 17:55                 ` Junio C Hamano
  2006-11-15 19:14                   ` Andy Parkins
  2006-11-16  3:53                 ` Petr Baudis
  3 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 17:55 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Andy Parkins <andyparkins@gmail.com> writes:

>> 3) remote branch handling should become more straight forward.
>
> I was completely confused by this origin/master/clone stuff when I started 
> with git.  In hindsight, now I understand git a bit more, this is what I 
> would have liked:
>
>  * Don't use the name "origin" twice.  In fact, don't use it at all.  In a 
> distributed system there is no such thing as a true origin.
>
>  * .git/remotes/origin should be ".git/remotes/default".   "origin" is only 
> special because it is the default to push and pull - it's very nice to have a 
> default, but it should therefore be /called/ "default".

I think the naming is just a minor detail and can be overridden
with "clone --origin" already.  Renaming it to default is just
like making separate-remote the default to me -- it is fine as
long as it does not break people's expectations.

>  * If clone really wants to have a non-read-only master, then that should 
> be .git/refs/heads/master and will initialise 
> to .git/refs/remotes/$name/master after cloning.  Personally I think this is 
> dangerous because it assumes there is a "master" upstream - which git doesn't 
> mandate at all.  Maybe it would be better to take the upstream HEAD and 
> create a local branch for /that/ branch rather than require that it is 
> called "master".

I think the latter is what clone has done always; take remote's
HEAD and use that to initialize local master (there is no
confusion coming from multiple peer repositories because you
clone from only one place to initialize the repository -- that
one _is_ the origin), and we even keep the HEAD pointing at the
remote's master or whatever it points at at the remote.  Using
"$name" as an object name uses .git/refs/remotes/$name/HEAD.

>  * git-clone should really just be a small wrapper around
>...
> If git-clone does anything that can't be done with settings in the config 
> and the remotes/default file then it's wrong.  The reason I say this is that 
> as soon as git-clone has special capabilities (like --shared, --local 
> and --reference) then you are prevented from doing magic with existing 
> repositories.

That is not entirely true.  clone has convenience because people
asked.  It does not have to mean you are not allowed to give
similar convenience to other commands.  Patches?

> branches from two other local repositories that have the objects hard linked?

fetch by second local repository with git-local-fetch perhaps.

> There have been lots of "wishlist" posts lately; would it be
> useful if I tried to collect all these suggestions from
> various people into one place to try and get a picture of any
> consensus?

A list of common things wished by people certainly is a handy
thing to have.

A consensus would not write code and it generally does not take
technology into account to tell what is realistic and what is
not, so the result needs to be take with a grain of salt,
though.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 15:41                 ` Nicolas Pitre
@ 2006-11-15 17:59                   ` Junio C Hamano
  2006-11-15 18:11                     ` Nicolas Pitre
  2006-11-18 11:09                   ` Alan Chandler
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 17:59 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git

Nicolas Pitre <nico@cam.org> writes:

> But again I think it is important that the URL to use must be a per 
> branch attribute i.e. attached to "default/master" and not just 
> "default".  This way someone could add all branches of interest into the 
> "default" group even if they're from different repositories, and a 
> simple  get without any argument would get them all.

I think the "one group per one remote repository" model is a lot
easier to explain.  At least when I read your first "branch
group" proposal that was I thought was going on and I found it
quite sensible (and it maps more or less straightforwardly to
the way existing .git/refs/remotes is set up by default).

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  4:20                   ` Nicolas Pitre
  2006-11-15  4:58                     ` Junio C Hamano
@ 2006-11-15 18:03                     ` Linus Torvalds
  2006-11-15 18:28                       ` Jakub Narebski
                                         ` (5 more replies)
  1 sibling, 6 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 18:03 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Junio C Hamano, git



On Tue, 14 Nov 2006, Nicolas Pitre wrote:
> 
> But the fact is that HG (which has a growing crowd of happy campers, 
> maybe even larger than the BK crowd now) did work with and got used to a 
> sensible definition of what a "pull" is.

Guys, before you start thinking this way, the fact is, there's a lot of 
happy git users. 

So the reason for using "git pull" is

 - bk did it that way, and like it or not, bk was the first usable 
   distributed system. hg is totally uninteresting.

 - git itself has now done it that way for the last 18 months, and the 
   fact is, the people _complaining_ are a small subset of the people who 
   actually use git on a daily basis and don't complain.

So don't fall for the classic "second system syndrome". The classic reason 
for getting the second system wrong is because you focus on the issues 
people complain about, and not on the issues that work well (because the 
issues that work fine are obviously not getting a lot of attention).

If you think "pull" is confusing, I can guarantee you that _changing_ the 
name is a hell of a lot more confusing. In fact, I think a lot of the 
confusion comes from cogito, not from git - the fact that cogito used 
different names and different syntax was a mistake, I think.

And that '#' for branch naming in particular was (and is) total 
braindamage. The native git branch naming convention is just fundamentally 
much better, and allows you to very naturally fetch multiple branches at 
once, in a way that cogito's syntax does not.

So when I see suggestions of using that brain-damaged cogito syntax as an 
"improvement", I know for a fact that somebody hasn't thought things 
through, and only thinks it's a better syntax beause of totally bogus 
reasons.

I do agree that we probably could/should re-use the "git merge" name. The 
current "git merge" is an esoteric internal routine, and I doubt a lot of 
people use it as-is. I don't think it would be a mistake to make "git 
merge" basically be an alias for "git pull", for example, and I doubt many 
people would really even notice.

But the fact is, git isn't really that hard to work out, and the commands 
aren't that complicated. There's no reason to rename them. We do have 
other problems:

 - default branch selection for merging is broken (it should definitely 
   take the current branch into account). When I do "git pull" with no 
   branch specification, and I happen to be on a branch that is associated 
   with something else than "master" in the remote, I shouldn't merge with 
   master.

 - I agree that having to create temporary branches to just look at a tag 
   that you don't want to actually develop on is just unnecessarily 
   bothersome.

But trying to rename "pull" (or the "git" name itself) is just going to 
cause more confusion than you fix.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 17:59                   ` Junio C Hamano
@ 2006-11-15 18:11                     ` Nicolas Pitre
  2006-11-16 13:21                       ` Karl Hasselström
  0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 18:11 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wed, 15 Nov 2006, Junio C Hamano wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > But again I think it is important that the URL to use must be a per 
> > branch attribute i.e. attached to "default/master" and not just 
> > "default".  This way someone could add all branches of interest into the 
> > "default" group even if they're from different repositories, and a 
> > simple  get without any argument would get them all.
> 
> I think the "one group per one remote repository" model is a lot
> easier to explain.  At least when I read your first "branch
> group" proposal that was I thought was going on and I found it
> quite sensible (and it maps more or less straightforwardly to
> the way existing .git/refs/remotes is set up by default).

I think one group per remote repo is how things should be by default 
too.  But we should not limit it to that if possible.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 15:10                   ` Nicolas Pitre
@ 2006-11-15 18:16                     ` Junio C Hamano
  2006-11-15 19:02                       ` Andy Parkins
  2006-11-16  0:23                       ` Han-Wen Nienhuys
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 18:16 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git

Nicolas Pitre <nico@cam.org> writes:

>> Why not do something like "get/put" instead? It is
>> 
>> - easier to remember
>> - not bogus (AFAICT the meaning is not used in diametrical senses)
>> - shorter to type than download/upload
>
> Well, of all compromizes this is probably the best one so far.  I would 
> have prefered to bite the bullet and fix "pull" instead of adding yet 
> more commands.  But if the consensus is that there is no way on earth 
> that "pull" can be salvaged then get/put is probably more enjoyable than 
> download/upload.  This way pull/fetch/push could still be available 
> (albeit burried somewhere out of sight).

I still think in the long run you would be better off giving
separate names to Porcelains because I am sure you are going to
find the next command to "fix", you cannot suddenly change the
semantics of the command, and you soon run out of alternative
ways to name the action and you in addition have to explain the
differences between fetch and get to new users.  At least, with
"ig pull", you can dismiss all the broken git-x Porcelain-ish by
saying "Oh, git-x user-level commands had inconsistent semantics
and broken UI so do not use them anymore -- they are still there
only to help old timers transition.  The user level commands are
now called ig-x and ig stands for improved git".

But that's a very minor detail and can be fixed when we hit the
wall, so let's wait and see what happens.  Please consider my
gh/gu/cg/whatever dropped.

I think get/put is much better than suddenly changing what pull
means and is shorter to type than x-load; I am Ok with them.
Although I think these words are tainted by SCCS, I do not think
anybody cares.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:03                     ` Linus Torvalds
@ 2006-11-15 18:28                       ` Jakub Narebski
  2006-11-15 20:31                         ` Josef Weidendorfer
  2006-11-15 18:43                       ` Nicolas Pitre
                                         ` (4 subsequent siblings)
  5 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15 18:28 UTC (permalink / raw)
  To: git

Linus Torvalds wrote:

> But the fact is, git isn't really that hard to work out, and the commands 
> aren't that complicated. There's no reason to rename them. We do have 
> other problems:
> 
>  - default branch selection for merging is broken (it should definitely 
>    take the current branch into account). When I do "git pull" with no 
>    branch specification, and I happen to be on a branch that is associated 
>    with something else than "master" in the remote, I shouldn't merge with 
>    master.

This problem is _slightly_ migitated by branch.<name>.merge config variable.
Slightly because you have to specify branch to merge, instead of forbidding
merge if you are not on specific branch (and you don't override it).

>  - I agree that having to create temporary branches to just look at a tag 
>    that you don't want to actually develop on is just unnecessarily 
>    bothersome.

Agreed.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:03                     ` Linus Torvalds
  2006-11-15 18:28                       ` Jakub Narebski
@ 2006-11-15 18:43                       ` Nicolas Pitre
  2006-11-15 18:49                         ` Shawn Pearce
  2006-11-15 18:58                       ` Andy Parkins
                                         ` (3 subsequent siblings)
  5 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 18:43 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Junio C Hamano, git

On Wed, 15 Nov 2006, Linus Torvalds wrote:

> 
> 
> On Tue, 14 Nov 2006, Nicolas Pitre wrote:
> > 
> > But the fact is that HG (which has a growing crowd of happy campers, 
> > maybe even larger than the BK crowd now) did work with and got used to a 
> > sensible definition of what a "pull" is.
> 
> Guys, before you start thinking this way, the fact is, there's a lot of 
> happy git users. 
> 
> So the reason for using "git pull" is
> 
>  - bk did it that way, and like it or not, bk was the first usable 
>    distributed system. hg is totally uninteresting.
> 
>  - git itself has now done it that way for the last 18 months, and the 
>    fact is, the people _complaining_ are a small subset of the people who 
>    actually use git on a daily basis and don't complain.

Those arguments are somewhat flawed.  If we stick to "BK did it that way 
and it was first", then following that logic we would also carry a lot 
of CVS baggage because "CVS did it that way, and it was the most 
successful of its kind".  Still, we decided not to follow CVS nor BK in 
many ways already.

As for the fraction of people complaining being a small fraction of 
current GIT users: that is easily explainable by the fact that most 
people who would have grown the complainers group are simply not GIT 
users anymore since they were turned away by GIT's current user 
interface issues.  The only complainers remaining are those who see 
value in the GIT technology but who would like to bring more 
intuitiveness to the GIT interface instead of going for the alternative 
technology.  And those kind of people are always few.

> So don't fall for the classic "second system syndrome". The classic reason 
> for getting the second system wrong is because you focus on the issues 
> people complain about, and not on the issues that work well (because the 
> issues that work fine are obviously not getting a lot of attention).

The counter part of that is the possibility to fall for the "ivory tower 
syndrome" where seasoned GIT users feel they are well satisfied with 
what is currently available and unwilling to consider changes that would 
reduce the barrier to entry for new users... simply because they are so 
used to the way things work that they can't see why others have problems 
with it.

> If you think "pull" is confusing, I can guarantee you that _changing_ the 
> name is a hell of a lot more confusing.

Agreed.  This is why the current discussion led to a proposition that 
allows for "pull" to remain as is but to have a "get" version that would 
be the alternate (saner) version.

> In fact, I think a lot of the 
> confusion comes from cogito, not from git - the fact that cogito used 
> different names and different syntax was a mistake, I think.
> 
> And that '#' for branch naming in particular was (and is) total 
> braindamage. The native git branch naming convention is just fundamentally 
> much better, and allows you to very naturally fetch multiple branches at 
> once, in a way that cogito's syntax does not.
> 
> So when I see suggestions of using that brain-damaged cogito syntax as an 
> "improvement", I know for a fact that somebody hasn't thought things 
> through, and only thinks it's a better syntax beause of totally bogus 
> reasons.

Do you have comments on my proposed syntax (that would be implemented 
with a git-get command) which I think doesn't really look like cogito?

> I do agree that we probably could/should re-use the "git merge" name. The 
> current "git merge" is an esoteric internal routine, and I doubt a lot of 
> people use it as-is. I don't think it would be a mistake to make "git 
> merge" basically be an alias for "git pull", for example, and I doubt many 
> people would really even notice.

Agreed.

> But the fact is, git isn't really that hard to work out, and the commands 
> aren't that complicated.

I agree with you in general, except for the "pull" behavior which is 
really really odd.  Maybe it made sense in the BK context, maybe it is 
fine _once_ you get used to it, but otherwise it is really overloaded.

> But trying to rename "pull" (or the "git" name itself) is just going to 
> cause more confusion than you fix.

Agreed again.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:43                       ` Nicolas Pitre
@ 2006-11-15 18:49                         ` Shawn Pearce
  2006-11-15 19:05                           ` Marko Macek
  0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-15 18:49 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Linus Torvalds, Junio C Hamano, git

Nicolas Pitre <nico@cam.org> wrote:
> As for the fraction of people complaining being a small fraction of 
> current GIT users: that is easily explainable by the fact that most 
> people who would have grown the complainers group are simply not GIT 
> users anymore since they were turned away by GIT's current user 
> interface issues.  The only complainers remaining are those who see 
> value in the GIT technology but who would like to bring more 
> intuitiveness to the GIT interface instead of going for the alternative 
> technology.  And those kind of people are always few.

Or they are by proxy.

*I* don't see that much of a problem with git pull; I can use it
without trouble at this point.  But I find it difficult to teach
to others.

My complaints about git pull/fetch/push are by proxy for about 10
other users who aren't on the mailing list but whom I interact with
through Git.  They don't like pull/fetch/push very much.

So count my complaints 10 times.  :)

Ok, that's still a drop in the bucket of current Git users.
But still, I'm sure there are others.  I think Carl was recently
talking about complaints from some Fedora folks...

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:03                     ` Linus Torvalds
  2006-11-15 18:28                       ` Jakub Narebski
  2006-11-15 18:43                       ` Nicolas Pitre
@ 2006-11-15 18:58                       ` Andy Parkins
  2006-11-15 19:18                         ` Linus Torvalds
  2006-11-15 19:32                         ` Junio C Hamano
  2006-11-16  1:14                       ` Theodore Tso
                                         ` (2 subsequent siblings)
  5 siblings, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2006-11-15 18:58 UTC (permalink / raw)
  To: git

On Wednesday 2006, November 15 18:03, Linus Torvalds wrote:

> Guys, before you start thinking this way, the fact is, there's a lot of
> happy git users.

I'm a happy user, doesn't mean I wouldn't like changes.  In fact, by that 
argument, that there are happy users means that there is no need to ever make 
changes.

>  - git itself has now done it that way for the last 18 months, and the
>    fact is, the people _complaining_ are a small subset of the people who
>    actually use git on a daily basis and don't complain.

That's awfully like the argument I hear off my bank whenever I complain to 
them too - "well lots of other people don't complain so we must be right".  
The people who complain are a subset of the people who have complaints.  I 
don't think never changing is a good argument - leaving aside the actual 
changes under discussion - in another 18 months lets say there are double the 
number of git users, and 18 months after that double again - in that case the 
potential new users needs outweigh the current users needs.

> If you think "pull" is confusing, I can guarantee you that _changing_ the
> name is a hell of a lot more confusing. In fact, I think a lot of the

> But the fact is, git isn't really that hard to work out, and the commands

On the one hand you're arguing that git syntax is easy to learn, and on the 
other that no one will be able to learn a new syntax just as easily.

> aren't that complicated. There's no reason to rename them. We do have
> other problems:

That there are other problems doesn't negate these problems.

> But trying to rename "pull" (or the "git" name itself) is just going to
> cause more confusion than you fix.

I don't think so.  Mainly because the proposed new git pull would be a subset 
of the existing git pull.  It's not changing function, it's just reducing in 
function.


Andy
-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:16                     ` Junio C Hamano
@ 2006-11-15 19:02                       ` Andy Parkins
  2006-11-15 19:41                         ` Junio C Hamano
  2006-11-16  0:23                       ` Han-Wen Nienhuys
  1 sibling, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2006-11-15 19:02 UTC (permalink / raw)
  To: git

On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:

> I still think in the long run you would be better off giving
> separate names to Porcelains because I am sure you are going to

The problem I think with that is that the line between plumbing and porcelain 
is not clear.  If you have two names then for the ambiguous ones you are just 
making it more confusing because there is yet another variable to try before 
you get the function you want.



Andy

-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:49                         ` Shawn Pearce
@ 2006-11-15 19:05                           ` Marko Macek
  2006-11-15 20:41                             ` Junio C Hamano
                                               ` (2 more replies)
  0 siblings, 3 replies; 601+ messages in thread
From: Marko Macek @ 2006-11-15 19:05 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Linus Torvalds, Junio C Hamano, git, cworth, pasky

Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
>> As for the fraction of people complaining being a small fraction of 
>> current GIT users: that is easily explainable by the fact that most 
>> people who would have grown the complainers group are simply not GIT 
>> users anymore since they were turned away by GIT's current user 
>> interface issues.  The only complainers remaining are those who see 
>> value in the GIT technology but who would like to bring more 
>> intuitiveness to the GIT interface instead of going for the alternative 
>> technology.  And those kind of people are always few.
> 
> Or they are by proxy.
> 
> *I* don't see that much of a problem with git pull; I can use it
> without trouble at this point.  But I find it difficult to teach
> to others.
> 
> My complaints about git pull/fetch/push are by proxy for about 10
> other users who aren't on the mailing list but whom I interact with
> through Git.  They don't like pull/fetch/push very much.
> 
> So count my complaints 10 times.  :)
> 
> Ok, that's still a drop in the bucket of current Git users.
> But still, I'm sure there are others.  I think Carl was recently
> talking about complaints from some Fedora folks...

Agreed. Personally, the first thing that I notice when trying to switch
 from Subversion to git is the behavior of 'index', mainly in git-diff, git-status and 
git-commit.

For people switching from CVS and SVN it would be much better if the index was hidden 
behind the scenes by using different defaults:

git-commit -a
git-status -a
git-diff HEAD

BTW, currently there's a minor bug: git-diff HEAD doesn't work before you 
make the first commit. Perhaps this should be special cased.

I could personally get used to this, but I'd surely get blank 
stares from people when teaching them the difference.

I guess this is the reason that the GIT Tutorial for CVS/SVN users is talking about _cogito_ instead.
(which is very confusing for someone coming to _git_ home page, trying to learn git).


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 17:55                 ` Junio C Hamano
@ 2006-11-15 19:14                   ` Andy Parkins
  0 siblings, 0 replies; 601+ messages in thread
From: Andy Parkins @ 2006-11-15 19:14 UTC (permalink / raw)
  To: git

On Wednesday 2006, November 15 17:55, Junio C Hamano wrote:

> I think the latter is what clone has done always; take remote's
> HEAD and use that to initialize local master (there is no

It's this sort of thing that is confusing though - the remote HEAD branch 
could be anything, and yet that is made to be origin locally as a tracking 
branch and then master as the writable branch.  What if upstream /has/ a 
master but "next" is its HEAD?  You'd then get

 next:remotes/origin
 master:remotes/master

Then a local master which is actually upstream next!  Oh dear.

I may well have misunderstood what you've said above above clone always 
initialising master from remote's HEAD; if so please disregard what I'm 
saying.

> > that as soon as git-clone has special capabilities (like --shared,
> > --local and --reference) then you are prevented from doing magic with
> > existing repositories.
>
> That is not entirely true.  clone has convenience because people
> asked.  It does not have to mean you are not allowed to give
> similar convenience to other commands.  Patches?

Absolutely, that was why I said clone shouldn't have special abilities.  In 
fact, if you're willing you don't need clone at all; you just need 
git-init-db and to write the correct remotes file.  

> > branches from two other local repositories that have the objects hard
> > linked?
>
> fetch by second local repository with git-local-fetch perhaps.

Is that not plumbing?  I thought this was about porcelain.

> A consensus would not write code and it generally does not take
> technology into account to tell what is realistic and what is
> not, so the result needs to be take with a grain of salt,
> though.

Of course, I only suggested it because the same suggestions were popping up 
multiple times.  Anyway; I put it in the GitWiki at 
http://git.or.cz/gitwiki/Wishlist

Andy

-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:58                       ` Andy Parkins
@ 2006-11-15 19:18                         ` Linus Torvalds
  2006-11-15 19:39                           ` Michael K. Edwards
  2006-11-16  1:40                           ` Anand Kumria
  2006-11-15 19:32                         ` Junio C Hamano
  1 sibling, 2 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 19:18 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git



On Wed, 15 Nov 2006, Andy Parkins wrote:
>
> On the one hand you're arguing that git syntax is easy to learn, and on the 
> other that no one will be able to learn a new syntax just as easily.

I'm saying that people who are new to git will _have_ to learn new 
concepts ANYWAY.

I don't think the naming is the hard part. 

The fact is, git is one of the very few (essentially _only_) SCM's that 
make it very clear that all real operations are local and that if you want 
to work with other repositories, you have to "fetch" those into local 
branches first. The fact that "pull" exists at all is really just 
shorthand.

If people have trouble explaining this to others, and have trouble 
grasping "pull", then I will bet that the _real_ issue has nothing at all 
to do with naming at all, and the real issue is that people are being 
_taught_ the concepts in the wrong order.

Before you learn "pull", you should learn "fetch". Don't even _mention_ 
"pull" until the person got what "fetch" means. Because the fact is, 
"fetch" is really the much more fundamental operation, and once you 
really understand what "fetch" does, "pull" is obvious.

So I'll argue that the problem isn't naming, the "problem" is really that 
git has a few fundamnetal concepts that people aren't used to. The most 
fundamnetal of those is the notion of the local branch-space. EVERY other 
(broken) SCM has branches as being some kind of totally idiotic separate 
subdirectories, or doesn't really support branches at all (ie neither BK 
nor CVS really support "branches" - even if a concept of that name exists 
in CVS, it has nothing at all in common with the git model of branches).

But once you understand branches, and understand "fetch" (and it really 
isn't _that_ complicated: fetch really does exactly what the name says, so 
if you understand local branches, you will understand "fetch"), then it's 
a much smaller step to explain "pull = fetch + merge".

But I bet people don't teach it that way. They _start_ by teaching "pull". 
Right?


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:58                       ` Andy Parkins
  2006-11-15 19:18                         ` Linus Torvalds
@ 2006-11-15 19:32                         ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 19:32 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Andy Parkins <andyparkins@gmail.com> writes:

>> But trying to rename "pull" (or the "git" name itself) is just going to
>> cause more confusion than you fix.
>
> I don't think so.  Mainly because the proposed new git pull would be a subset 
> of the existing git pull.  It's not changing function, it's just reducing in 
> function.

We usually use the word "regression" to refer to that kind of
change.

I think it makes a lot of sense having command x that does
essentially the same thing as the current fetch but with more
usability enhancements and more convention as built-in defaults,
and another command y that does what the current 'pull .' does
but with more usability enhancements and more convention as
built-in defaults.  I agree that kind of UI improvements would
make it easier to explain to new people.  Calling x "pull",
however, breaks the existing users and documents, and causes
confusion.  I really do not think you can argue with that.

That's why we are talking about using an uncontaminated word
"get".  I think it is a good effort.

>> aren't that complicated. There's no reason to rename them. We do have
>> other problems:
>
> That there are other problems doesn't negate these problems.

And I think Linus is right in pointing out that there are other
problems that are equally or even more pressing than _renaming_
to break things for existing users.

I personally do not think the current fetch/pull confusing, and
I do see real downside in _renaming_ them, but I am open to the
current get/put discussion because I think the new commands'
semantics may be designed to match newcomers' expectation better
(it's to match tools to newcomers instead of teaching them the
new language of the land) and I do not think that approach would
break existing users and documents.

For some things "matching tools to newcomers" would not really
work, though.  For example, I do not think you can get away with
hiding index forever if you want your users to do real work in a
workflow that involves merging and cherry picking.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 19:18                         ` Linus Torvalds
@ 2006-11-15 19:39                           ` Michael K. Edwards
  2006-11-15 20:09                             ` Linus Torvalds
  2006-11-16  1:40                           ` Anand Kumria
  1 sibling, 1 reply; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-15 19:39 UTC (permalink / raw)
  To: git

On 11/15/06, Linus Torvalds <torvalds@osdl.org> wrote:
> But once you understand branches, and understand "fetch" (and it really
> isn't _that_ complicated: fetch really does exactly what the name says, so
> if you understand local branches, you will understand "fetch"), then it's
> a much smaller step to explain "pull = fetch + merge".
>
> But I bet people don't teach it that way. They _start_ by teaching "pull".
> Right?

"git fetch" is certainly the right thing for the platform integration
role, in which one is trying to maintain a series of integration
branches which track the bleeding edge of some subsystems while
keeping the core stable on each branch.  This is not as impossible as
people make it out to be, but there certainly isn't much place for
automatic merges to _persistent_ branches.

It's fundamentally a backporting and cherry-picking effort, and the
git workflow puts it where it belongs: in the local repository, where
_transient_ branches can and should be created and destroyed casually
to track exploratory efforts.  These may include automatic merges and
even cruder techniques (git diff, hack on patch, apply patch).  Once
you figure out which bits you actually want to backport, you go back
to a fresh branch and cherry-pick the same bits with the tool instead
of manually, so that there is less noise in future merges.  When
you've tested a little, you merge this branch to the persistent branch
that other repositories track.

Cheers,

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 19:02                       ` Andy Parkins
@ 2006-11-15 19:41                         ` Junio C Hamano
  2006-11-15 20:15                           ` Nicolas Pitre
  2006-11-15 20:19                           ` Carl Worth
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 19:41 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Andy Parkins <andyparkins@gmail.com> writes:

> On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:
>
>> I still think in the long run you would be better off giving
>> separate names to Porcelains because I am sure you are going to
>
> The problem I think with that is that the line between plumbing and porcelain 
> is not clear.

This is moot because we (at least tentatively) agreed not to do
"gh" or "ig" or whatever, but I do not understand why you feel
so.

If we had a separate Porcelain namespace (say "ng" for "new
git") you would know "ng-commit" is not a Plumbing and when you
are writing a Porcelain script you would stay away from using it
in your script.

In the longer term, when the new Porcelain UI Nico and friends
are designing matures, and if it makes everybody (including
existing users who learned git-* Porcelain-ish during 18-months
process) happy, we could gradually deprecate and eventually
remove the git-* Porcelain-ish over time, at that point we would
have a very clear line between plumbing and porcelain.

But that would not be a flag-day change.  During the transition
period you cannot mechanically tell if git-foo is a plumbing or
a porcelain just like you cannot do so now.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 19:39                           ` Michael K. Edwards
@ 2006-11-15 20:09                             ` Linus Torvalds
  2006-11-15 20:21                               ` Nicolas Pitre
  0 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 20:09 UTC (permalink / raw)
  To: Michael K. Edwards; +Cc: git



On Wed, 15 Nov 2006, Michael K. Edwards wrote:
> > 
> > But I bet people don't teach it that way. They _start_ by teaching "pull".
> > Right?
> 
> "git fetch" is certainly the right thing for the platform integration
> role

I'm saying that even if you _never_ end up using "git fetch" ever again 
(because in practice you always want to do a "fetch + merge == pull"), 
people who teach others the concepts and usage of git should probably 
start by talking about "git fetch".

Then, when the user says (and he obviously will say this) "but I don't 
want to just fetch the other persons work into some local branch, I want 
to actually get it into _my_ branch", you say "Ahhah!" and talk about how 
"pull" is a shorthand for first fetching and then merging the result into 
the current branch.

See? Once you explain "fetch" to somebody, I can pretty much guarantee 
that they'll explain "pull" to themselves without you having to even work 
at it. And then they'll probably happily use "pull" ever after, and never 
worry about fetch, but now they'll understand the _concepts_.

It's only if you start the other way around that "pull" vs "fetch" vs 
"push" become confusing. If you _start_ by explaining branches (and you 
might use "gitk --all" on a small project as a visualization tool), 
suddenly the concepts aren't all that complicated.

Sure, then you have to remember two words ("pull" vs "fetch"), but I'm 
pretty sure that the thing that makes people confused is not the words 
themselves, but their lack of understanding of the concepts behind them.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  2:10                 ` Junio C Hamano
  2006-11-15  2:27                   ` Michael K. Edwards
  2006-11-15  4:20                   ` Nicolas Pitre
@ 2006-11-15 20:12                   ` Petr Baudis
  2006-11-15 20:26                     ` Nicolas Pitre
  2 siblings, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-15 20:12 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nicolas Pitre, git

On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:
> You have to admit both pull and fetch have been contaminated
> with loaded meanings from different backgrounds. I was talking
> about killing the source of confusion in the longer term by
> removing fetch/pull/push, so we are still on the same page.

How was/is fetch contaminated?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 19:41                         ` Junio C Hamano
@ 2006-11-15 20:15                           ` Nicolas Pitre
  2006-11-15 20:19                           ` Carl Worth
  1 sibling, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 20:15 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Andy Parkins, git

On Wed, 15 Nov 2006, Junio C Hamano wrote:

> If we had a separate Porcelain namespace (say "ng" for "new
> git") you would know "ng-commit" is not a Plumbing and when you
> are writing a Porcelain script you would stay away from using it
> in your script.

There is merit in trying to segregate porcelain vs plumbing... at least 
in theory.  In practice though I don't think this is something we should 
absolutely strive for.

Why? Because something is always going to fail the categorization.  
Sure there are commands that are pure plumbing like git-commit-tree, 
etc.  Some are pure porcelain like git-commit or git-log.  Yet we use 
git-log's output for git-shortlog.  Does it mean that git-log is 
plumbing? Also I have a script here that uses git-commit directly 
because it is so much convenient rather than futzing with the really 
bare plumbing.  I don't think git-commit should be prevented from being 
used within another script even if it is classified as porcelain.

So we have that notion of plumbing vs porcelain but in practice there is 
a whole spectrum between those two poles and I think it is a good thing.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 19:41                         ` Junio C Hamano
  2006-11-15 20:15                           ` Nicolas Pitre
@ 2006-11-15 20:19                           ` Carl Worth
  2006-11-15 21:13                             ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-15 20:19 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Andy Parkins, git

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

On Wed, 15 Nov 2006 11:41:20 -0800, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
> > On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:
> >
> >> I still think in the long run you would be better off giving
> >> separate names to Porcelains because I am sure you are going to
> >
> > The problem I think with that is that the line between plumbing and porcelain
> > is not clear.
>
> This is moot because we (at least tentatively) agreed not to do
> "gh" or "ig" or whatever, but I do not understand why you feel
> so.

I'm not the original poster, but I feel the same way about the line
being unclear.

Here's a real-world example from last week.

For cairo I wrote a little script that two revspecs, (or one in
which case its first parent is used), and it goes off and checks out
both versions, builds each, runs a performance test on each, and then
generates a report showing the performance impact.

So now I can do things like:

	# What's the performance impact of my latest change:
	cairo-perf-diff HEAD

	# Have my last few changes helped as much as I'd hoped:
	cairo-perf-diff HEAD~3 HEAD

	# How has performance changed since our last stable release:
	cairo-perf-diff 1.2.6 HEAD

Anyway, when I announced this I also mentioned how easily someone
might generate an entire series of reports for a series of
commits. The command I gave as an example is:

	for rev in $(git rev-list 1.2.6..HEAD); do
	    cairo-perf-diff $rev
	done

I think that's a perfectly legitimate one-liner for users to use, and
it really shows off the easy-scriptability of git. But certainly, no
"new porcelain" author is going to consider rev-list to be porcelain
rather than plumbing, right? So as soon as I start teaching people to
do useful stuff like this, they might have to reach down into the
"scary" git interface.

I think we're much better off just having one "git" namespace for the
standard command-line interface, and then making it as easy to use as
possible.

-Carl


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:09                             ` Linus Torvalds
@ 2006-11-15 20:21                               ` Nicolas Pitre
  2006-11-15 20:40                                 ` Linus Torvalds
  0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 20:21 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Michael K. Edwards, git

On Wed, 15 Nov 2006, Linus Torvalds wrote:

> I'm saying that even if you _never_ end up using "git fetch" ever again 
> (because in practice you always want to do a "fetch + merge == pull"), 
> people who teach others the concepts and usage of git should probably 
> start by talking about "git fetch".
> 
> Then, when the user says (and he obviously will say this) "but I don't 
> want to just fetch the other persons work into some local branch, I want 
> to actually get it into _my_ branch", you say "Ahhah!" and talk about how 
> "pull" is a shorthand for first fetching and then merging the result into 
> the current branch.

Actually I believe it would make things even clearer if "merge" was 
taught at that point.  Only when the user is comfortable with the 
separate notions of fetching and merging might the pull shorthand 
possibly be mentioned.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:12                   ` Petr Baudis
@ 2006-11-15 20:26                     ` Nicolas Pitre
  2006-11-15 20:50                       ` Linus Torvalds
  2006-11-16  1:51                       ` Anand Kumria
  0 siblings, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 20:26 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Junio C Hamano, git

On Wed, 15 Nov 2006, Petr Baudis wrote:

> On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:
> > You have to admit both pull and fetch have been contaminated
> > with loaded meanings from different backgrounds. I was talking
> > about killing the source of confusion in the longer term by
> > removing fetch/pull/push, so we are still on the same page.
> 
> How was/is fetch contaminated?

I think "fetch" is sane.  Its only problem is a missing symetrical 
counterpart verb, like "get" and "put".



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:28                       ` Jakub Narebski
@ 2006-11-15 20:31                         ` Josef Weidendorfer
  2006-11-15 20:35                           ` Petr Baudis
  0 siblings, 1 reply; 601+ messages in thread
From: Josef Weidendorfer @ 2006-11-15 20:31 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git, Linus Torvalds, Nicolas Pitre, Junio C Hamano

On Wednesday 15 November 2006 19:28, you wrote:
> Linus Torvalds wrote:
> 
> > But the fact is, git isn't really that hard to work out, and the commands 
> > aren't that complicated. There's no reason to rename them. We do have 
> > other problems:
> > 
> >  - default branch selection for merging is broken (it should definitely 
> >    take the current branch into account). When I do "git pull" with no 
> >    branch specification, and I happen to be on a branch that is associated 
> >    with something else than "master" in the remote, I shouldn't merge with 
> >    master.
> 
> This problem is _slightly_ migitated by branch.<name>.merge config variable.
> Slightly because you have to specify branch to merge, instead of forbidding
> merge if you are not on specific branch (and you don't override it).

We should change this.

The problem is that whatever is the first Pull line in remotes config gets
merged by default into current branch, which most often is not the right
thing to do.

Often, I find myself doing "git branch" just to make sure that I am on
"master", so that a following pull does not do a bogus merge.

Can we please disable this behavior, e.g. by allowing a fake first
Pull line like "Pull: (not-for-merge)" to prohibit any merge?

This even could be written by default in git-clone somewhere in the future,
and we suddenly get the behavior of pull being symmetric to push - at least
by default. And still, it is fully compatible to existing repositories.

To make pull do the right thing, we _have_ to configure branch.<name>.merge
whenever we create a new branch (which matters for git-clone, too).

Josef

> 
> >  - I agree that having to create temporary branches to just look at a tag 
> >    that you don't want to actually develop on is just unnecessarily 
> >    bothersome.
> 
> Agreed.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:31                         ` Josef Weidendorfer
@ 2006-11-15 20:35                           ` Petr Baudis
  2006-11-15 21:12                             ` Josef Weidendorfer
  0 siblings, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-15 20:35 UTC (permalink / raw)
  To: Josef Weidendorfer
  Cc: Jakub Narebski, git, Linus Torvalds, Nicolas Pitre, Junio C Hamano

On Wed, Nov 15, 2006 at 09:31:13PM CET, Josef Weidendorfer wrote:
> Often, I find myself doing "git branch" just to make sure that I am on
> "master", so that a following pull does not do a bogus merge.
> 
> Can we please disable this behavior, e.g. by allowing a fake first
> Pull line like "Pull: (not-for-merge)" to prohibit any merge?

Wait, if you don't want pull to merge, why do you pull and not fetch?

(Disclaimer: I'm not intimately familiar with git pull/fetch and I
didn't read the whole thread yet.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  4:33             ` Junio C Hamano
  2006-11-15  4:46               ` Nicolas Pitre
@ 2006-11-15 20:39               ` Petr Baudis
  1 sibling, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-15 20:39 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wed, Nov 15, 2006 at 05:33:03AM CET, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
> >   (v) Git would be properly libified by now. If you wanted to convert
> > bits of porcelain to C, it would be at least much higher priority.
> 
> I am not sure about "libified" part and I do not know what bits
> of porcelain wants to become C right now.  But I do not think
> this point is important part of your list.

Merge strategies. Or wait, is that already plumbing?

Or git-status. git-add. Plenty more.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:21                               ` Nicolas Pitre
@ 2006-11-15 20:40                                 ` Linus Torvalds
  2006-11-15 21:08                                   ` Carl Worth
  2006-11-16  4:26                                   ` Theodore Tso
  0 siblings, 2 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 20:40 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Michael K. Edwards, git



On Wed, 15 Nov 2006, Nicolas Pitre wrote:
> 
> Actually I believe it would make things even clearer if "merge" was 
> taught at that point.  Only when the user is comfortable with the 
> separate notions of fetching and merging might the pull shorthand 
> possibly be mentioned.

I agree. I just expect that "merge" is such a simple concept that it 
doesn't really need a whole lot of explaining. 

People kind of expect merging to be hard, but I think it's because CVS et 
al have tought people that merging is _painful_. I don't think it's a very 
complicated concept per se, especially if you have explained branches with 
gitk already.

But yes, the order should be:

 (a) explain what "branches" mean in git (and in that situation, "fetch" 
     is very natural - I think fetching itself is probably easier to 
     explain than "branches" are).
 (b) once you've explained branches, the notion of "merge" comes next, and 
     I _think_ that is very obvious. This is where UI issues come in, 
     because "git merge" is really a totally internal program with a 
     pretty horrid UI, but I think we could fix the syntax, and even with 
     the current syntax you can really just gloss it over, because nobody 
     is really going to care.
 (c) once "fetching branches" and "merging" have been explained, "pull" is 
     really pretty damn trivial, and in fact, if you then explain that 
     it's just easier to do "git pull . branchname" than to use "git 
     merge", I think people may just even agree with you.

I think I saw that particular discussion on #git: somebody didn't expect 
"git pull . branch" to be the way to merge. And again, I think it's 
not _really_ because "pull" is hard to understand, it's because people 
haven't been walked through the thing in this way.

Once you understand local branches, fetching and merging, it's actually 
_easier_ to explain why we merge even local branches with "git pull .": 
you just tell them that this way you can use the same command regardless 
of whether you're merging something local or something remote. Again, if 
it's explained that way, I bet a lot of people react with "ahh, that's 
clever", and _like_ the fact that they only really need to learn _one_ 
command, instead of learning two.

See? Explain it that way: "pull" really is simple. By using "pull", you 
don't have to learn about "merge" syntax. You -can- use "merge" as a 
separate program if you want to, but the syntax isn't very nice, exactly 
because you're not really expected to.

But the real issue here is to explain local branches. I will happily admit 
that local branches are very VERY different from just about any other SCM, 
but I also claim that git is just much BETTER than other SCM's in this 
respect.

And yes, this is why you should NOT try to use the same naming as "hg", 
for example. Last I saw, hg still didn't even have local branches, To 
mercurial, repository == branch, and that's it. It was what I came from 
too, and I used to argue for using git that way too. I've since seen the 
error of my ways, and git is simply BETTER. 

And the concept of local branches is exactly _why_ you have to have 
separate "fetch" and "pull", but why you do _not_ need a separate "merge" 
(because "pull ." does it for you).

If you don't understand local branches, you'll never understand git usage. 
And once you _do_ understand local branches, "fetch" vs "pull" actually is 
rather simple.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 19:05                           ` Marko Macek
@ 2006-11-15 20:41                             ` Junio C Hamano
  2006-11-15 22:07                               ` Shawn Pearce
  2006-11-16  6:07                               ` Marko Macek
  2006-11-15 22:28                             ` Sean
       [not found]                             ` <20061115172834.0a328154.seanlkml@sympatico.ca>
  2 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 20:41 UTC (permalink / raw)
  To: Marko Macek; +Cc: Shawn Pearce, Linus Torvalds, git, cworth, pasky

Marko Macek <marko.macek@gmx.net> writes:

> For people switching from CVS and SVN it would be much better if the
> index was hidden behind the scenes by using different defaults:
>
> git-commit -a
> git-status -a
> git-diff HEAD
>
> BTW, currently there's a minor bug: git-diff HEAD doesn't work before
> you make the first commit. Perhaps this should be special cased.

That's only a _bug_ in your implementation of the synonym for
"svn diff" which blindly used "git diff HEAD".

"git diff HEAD" is not a synonym for "svn diff" when HEAD does
not exist yet, because you are asking "please give me a diff
between the tree in the HEAD commit and my working tree files
through the index".  So if you are doing "git-svnish-diff"
Porcelain script, it should notice that HEAD does not exist yet
and take an appropriate action.  We do something similar in
git-status; the porcelain notices and acts differently when HEAD
is not there yet.

This "there is no HEAD yet" is not related to the index, but I
am skeptical about trying to hide the index from the end user.

You can make some things map more naturally to systems like SVN
and CVS than other things.  For example, Nico's proposal to
always use remote tracking branches and defaulting to use
refs/remotes/ would be a way to match UI of pull/push to another
existing system and that would work well (I am not agreeing to
the change to make 'pull' not to do the merge which would break
existing users -- I am just saying that the result would be self
consistent).  But things that have difference at the concept
level, I suspect no clever mapping to hide the differences would
work well.

The index is quite central to the way git works at the concept
level, and I think it is doing disservice to the end user to try
hiding it forever from them and failing to do so, rather than
being honest and teaching them the concept upfront.

But me thinking so does not necessarily mean you are forbidden
from trying.  Your efforts may result in a system where the
index is totally invisible and the end user never has to know
about it.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:26                     ` Nicolas Pitre
@ 2006-11-15 20:50                       ` Linus Torvalds
  2006-11-15 21:18                         ` Nicolas Pitre
  2006-11-16  1:51                       ` Anand Kumria
  1 sibling, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 20:50 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Petr Baudis, Junio C Hamano, git



On Wed, 15 Nov 2006, Nicolas Pitre wrote:
> 
> I think "fetch" is sane.  Its only problem is a missing symetrical 
> counterpart verb, like "get" and "put".

If you're a dog owner, the obvious counterpart for "fetch" is "throw" ;)

I think "get" and "put" would be bad, just because of confusion with 
"sccs get" (ie it has that "get this file" connotations).

Maybe "fetch" and "push" aren't totally diametrically opposite, but 
really, I don't think they are that hard to understand either. We do have 
the BK legacy of "pull" implying a merge, and that's fairly fundamental. 

It's also true that in a lot of usage schenarios, what people actually 
_use_ is "pull" and "push", and no, they aren't mirror images (since push 
will _not_ do the merge), but at the same time, from a _usage_ standpoint 
they really _are_ each others opposites. 

You "pull" to get other peoples data into your branch (and once you've 
internalized local branches and the merge thing, you know what this 
means), and you "push" to push your changes out. It really _is_ the usage 
schenario, and using "opposite" words really _does_ make sense.

It's true that _technically_ "fetch" is the opposite of "push", but at the 
same time, that really is about technology, not about usage models. You 
normally wouldn't do a "git fetch + git push" pair. You _can_ do so, but 
it's not the natural way to work - unless you're just doing a mirror 
service.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  0:31         ` Junio C Hamano
  2006-11-15  4:08           ` Petr Baudis
@ 2006-11-15 20:51           ` Carl Worth
  2006-11-15 20:57             ` Jakub Narebski
  1 sibling, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-15 20:51 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Andy Whitcroft, Petr Baudis

[-- Attachment #1: Type: text/plain, Size: 6788 bytes --]

On Tue, 14 Nov 2006 16:31:50 -0800, Junio C Hamano wrote:
> I do not think the Porcelain-ish UI that is shipped with git
> should be taken with the same degree of "authority" as git
> Plumbing.

I think we should fix this. "This is great technology with a crap
interface on top" really isn't a good story. I don't actually agree
with that---I don't think the git interface is really all that bad,
it's just got a few little things that tend to trip up new users in my
experience.

And what git does really well, (history exploring, allowing for
pipeline on-liners to iterate over revisions in A..B), are things that
don't even exist in other tools, nor even in the "alternate"
porcelains for git. This stuff is where git's interface is really
fantastic, and it would be a shame to write it off.

>                                                        I think
> single isolated developers, contributors and CVS style shared
> repository usage could be a lot improved because neither of us
> were concentrating in their workflows.  This needs somebody
> motivated enough to improve things in that area.  For example,
> StGIT with its 'float' command is a great improvement over what
> rebase does for people in the contributor role.

Yes, there are some specific workflow-oriented operations that git
doesn't handle as well as it could. Things like commit --amend are
certainly improvements. One that is still totally broken is "follow
all the development in another repository" where clone followed by
repeated fetch doesn't do the job as soon as the remote adds or
deletes a branch.

> But making it more usable for whom is a big question.
>
> Quite frankly, I do not think there can be _the_ single UI that
> would satisfy different types of workflows for some of the
> commands.

I strongly disagree. Or at least, I don't think we've tried hard
enough yet that we should give up on this.

I do agree that people in different roles will have different lists of
"most used operations" and that some operations won't appear on some
users lists at all, (someone who's just "watching" development won't
commit or merge, for example---[or so they thing when they start]).

But I really don't think that for any given operation that different
roles impose a different desire on the behavior of the operation. We
have different people with different background and disagreement on
names and silly things like that, but I don't think that's related to
the roles in which they are working with the tool.

> For example, fetching and merging from many places without
> necessarily having corresponding tracking branches is a great
...

I don't think we've ever had this right in git. The new
--use-separate-remotes stuff or similar will start to help as it
becomes the default. I don't see how this won't benefit everybody.

> For another example, having a commit command to commit
> everything by default is disastrous for people who allow their
> workflows to often be interrupted.

Workflow-interruption is an important thing to support, but separating
update-index and commit really doesn't address it nearly as much as I
would like. The lack of really good workflow-interruption support has
been one of my longest-running annoyances with git, (perhaps because I
have a problem with trying to do too many things at once). Git can
create and change branches fast enough that it really should be able
to help me better with this. The only missing piece is being able to
stash the dirty stuff on the current branch, to be able to come back
to it later. I've talked a bit about what I would like in this area
before, and I really just need to code it up.

> It is not just command line syntax and the defaults, but
> concepts as well.  People in the integrator role often need to
> deal with merges and you would need to be aware of the role of
> the index and need to be able to manipulate the index, ...

Again, I think it's more that the specific operations bring in
concepts, (merge bringing in the index here). As such, someone never
doing a merge could easily get by not having to understand the index.

> A Porcelain that does a very similar thing in slightly different
> way is obviously a waste, but otherwise I do not think it is a
> problem to have different Porcelains.  StGIT does not compete
> with the "sucky" Porcelain-ish shipped with git but makes the
> user's life a lot more pleasant by complementing what the sucky
> one does not do well.  It is not very useful while I am playing
> the integrator role, but when I am doing my own thing it is a
> great addition to my toolchest.

But even here, there's a bunch of waste in StGit. For example, there
are a lot of commands in StGit whose only purpose is to translate back
and forth between the StGit and non-StGit views of the world, (init,
assimilate, commit, uncommit). Those could all be discarded if the
functionality of StGit were brought down into git itself. Then there
are a myriad of StGit commands which are basically just the same as
their git counterparts.

Now, StGit is a great tool, and I know that it works really well for
some people in the role of just maintaining a stack of changes against
some upstream, and can use StGit alone and never touch "git" the
command-line.

But for someone like me who already uses git regularly, and
occasionally just wants to pop back a few commits, amend it, and then
push again, StGit is not helpful, (the series of init, assimilate, and
uncommits just to get started is prohibitive compared to just working
out the awkward steps needed to make a temporary branch and
rebase). So I'd love to see just a couple of commands added to "git"
to support these kinds of operations more smoothly.

> I am from the camp that does _not_ want to hide the index, so
> obviously I do not see any value in its effort to hide the
> index.  But other aspects of it, most notably being friendly to
> simpler workflows, is a very good thing.

I don't think "hide or not-to-hide" is the right way to frame the
discussion about the index. I regularly use update-index to stage
partial commits, and I find that very useful. And obviously the index
is involved in resolving merge conflicts.

But I don't think the user-interface for either of those operations
(partial commit, resolve conflicts), is ideal, and the current
requirement to use either "update-index <paths>" or "commit -a" after
modifying a file for the first time is demonstrably a hangup for a lot
of new users. So I really think it's possible to address both of these
at once.

Anyone, that's enough generic rambling from me without any specific
content. I'll try to keep future messages focused on specific
desirable operations that have problematic interfaces in git right
now, along with proposals for improving them.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:51           ` Carl Worth
@ 2006-11-15 20:57             ` Jakub Narebski
  2006-11-15 22:00               ` Shawn Pearce
  0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15 20:57 UTC (permalink / raw)
  To: git

Carl Worth wrote:
>On Tue, 14 Nov 2006 16:31:50 -0800, Junio C Hamano wrote:
>>
>> For another example, having a commit command to commit
>> everything by default is disastrous for people who allow their
>> workflows to often be interrupted.
> 
> Workflow-interruption is an important thing to support, but separating
> update-index and commit really doesn't address it nearly as much as I
> would like. The lack of really good workflow-interruption support has
> been one of my longest-running annoyances with git, (perhaps because I
> have a problem with trying to do too many things at once). Git can
> create and change branches fast enough that it really should be able
> to help me better with this. The only missing piece is being able to
> stash the dirty stuff on the current branch, to be able to come back
> to it later. I've talked a bit about what I would like in this area
> before, and I really just need to code it up.

There is git-stash/git-unstash floating somewhere in the archive.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:40                                 ` Linus Torvalds
@ 2006-11-15 21:08                                   ` Carl Worth
  2006-11-15 21:31                                     ` Junio C Hamano
                                                       ` (2 more replies)
  2006-11-16  4:26                                   ` Theodore Tso
  1 sibling, 3 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-15 21:08 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Nicolas Pitre, Michael K. Edwards, git

[-- Attachment #1: Type: text/plain, Size: 3521 bytes --]

On Wed, 15 Nov 2006 12:40:43 -0800 (PST), Linus Torvalds wrote:
> On Wed, 15 Nov 2006, Nicolas Pitre wrote:
> >
> > Actually I believe it would make things even clearer if "merge" was
> > taught at that point.  Only when the user is comfortable with the
> > separate notions of fetching and merging might the pull shorthand
> > possibly be mentioned.
>
> I agree. I just expect that "merge" is such a simple concept that it
> doesn't really need a whole lot of explaining.

Well, one of the problems is that with current git I can teach, (and I
have), that there's a conceptual:

	pull = fetch + merge

But then shortly after I have to teach an interface notion:

	merge = pull .

So there's this goofy circular notion that people end up with
mentally. If we fix it so that a local merge really is performed with
"git merge <branch>" instead of "git pull . <branch>" then teaching
pull=fetch+merge really is a lot easier.

In the meantime, pull would still be useless to me, I think. But maybe
that's just the "default branch to merge" selection being broken. If
that were fixed, maybe I would start using pull.

>  (a) explain what "branches" mean in git (and in that situation, "fetch"
>      is very natural - I think fetching itself is probably easier to
>      explain than "branches" are).

There's a piece missing here, namely the mapping between remote and
local branch names and any notion of "tracking branches". I think a
sane story for that is still being invented, (or if it exists now, I
haven't seen it yet).

>  (c) once "fetching branches" and "merging" have been explained, "pull" is
>      really pretty damn trivial, and in fact, if you then explain that
>      it's just easier to do "git pull . branchname" than to use "git
>      merge", I think people may just even agree with you.

Well, they get pretty darn confused at this point, in my experience.

> Once you understand local branches, fetching and merging, it's actually
> _easier_ to explain why we merge even local branches with "git pull .":
> you just tell them that this way you can use the same command regardless
> of whether you're merging something local or something remote. Again, if
> it's explained that way, I bet a lot of people react with "ahh, that's
> clever", and _like_ the fact that they only really need to learn _one_
> command, instead of learning two.

No. It's really, really broken to use "pull ." for local merging. Not
a feature at all. We just got done establishing that pull is a
shorthand for doing fetch+merge, so reusing it when there is _no_
fetch at all is insane.

You just established quite clearly hat git has a huge advantge over
all other systems by having a model that everything is fetched in
and then worked with locally. I agree that this is a major
selling-point of git, and I'm also baffled that systems like bzr and
hg try so hard to push every branch into a separate repository.

But I think that git's "work with everything locally" story is undercut
a bit by regular usage being to use a transfer-inducing command like
"pull" for a totally local merge.

Anyway, I think we all agree that we'd really rather have "git merge
<branch>" be usable for local merges, so let's get that in place and
users can pick whichever they like.

> But the real issue here is to explain local branches. I will happily admit
> that local branches are very VERY different from just about any other SCM,
> but I also claim that git is just much BETTER than other SCM's in this
> respect.

Totally agree.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:35                           ` Petr Baudis
@ 2006-11-15 21:12                             ` Josef Weidendorfer
  2006-11-15 21:31                               ` Linus Torvalds
  0 siblings, 1 reply; 601+ messages in thread
From: Josef Weidendorfer @ 2006-11-15 21:12 UTC (permalink / raw)
  To: Petr Baudis
  Cc: Jakub Narebski, git, Linus Torvalds, Nicolas Pitre, Junio C Hamano

On Wednesday 15 November 2006 21:35, Petr Baudis wrote:
> On Wed, Nov 15, 2006 at 09:31:13PM CET, Josef Weidendorfer wrote:
> > Often, I find myself doing "git branch" just to make sure that I am on
> > "master", so that a following pull does not do a bogus merge.
> > 
> > Can we please disable this behavior, e.g. by allowing a fake first
> > Pull line like "Pull: (not-for-merge)" to prohibit any merge?
> 
> Wait, if you don't want pull to merge, why do you pull and not fetch?

I am not really opposed to pull doing a merge. It only should work in
a useful way: ie. only do the merge of updated origin branch when
current branch is master (given "Pull: master:origin").

I want "git pull" being harmless if I find myself accidently on a
branch != master. I always can do "git checkout master; git pull . origin"
afterwards.

For this to work, I currently need to specify a "branch.<name>.merge"
config for _every_ branch I have, as otherwise I get this bogus pull
merge behavior. This is not needed if there was a way to configure no
merge at all as default pull behavior.

I just noted that allowing such a config option would be kind of a
working compromise for all the people which want
pull to be the opposite of push.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:19                           ` Carl Worth
@ 2006-11-15 21:13                             ` Junio C Hamano
  2006-11-15 22:36                               ` Carl Worth
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 21:13 UTC (permalink / raw)
  To: Carl Worth; +Cc: Andy Parkins, git

Carl Worth <cworth@cworth.org> writes:

> I'm not the original poster, but I feel the same way about the line
> being unclear.
>
> Here's a real-world example from last week.
>...
> Anyway, when I announced this I also mentioned how easily someone
> might generate an entire series of reports for a series of
> commits. The command I gave as an example is:
>
> 	for rev in $(git rev-list 1.2.6..HEAD); do
> 	    cairo-perf-diff $rev
> 	done
>
> I think that's a perfectly legitimate one-liner for users to use, and
> it really shows off the easy-scriptability of git. But certainly, no
> "new porcelain" author is going to consider rev-list to be porcelain
> rather than plumbing, right? So as soon as I start teaching people to
> do useful stuff like this, they might have to reach down into the
> "scary" git interface.

That is a very fine example, but I do not see why it is a
problem.  I do not think the goal of Porcelain is to make it
totally unnecessary for users to know about the plumbing.

The one-liner is essentially a new Porcelain command that is
useful in the cairo developers' workflow, and implementing it
with a plumbing command makes perfect sense.  The whole point of
git plumbing is to be friendly for scripted use.  If the user
who learns that one-liner from you gets curious why and how that
one-liner works, that would be a good gentle introduction to the
plumbing, but otherwise the user is not forced to know about it.

Also I do not see a problem if some plumbing commands happen to
be also useful by themselves ("[alias] less = -p cat-file -p"
comes to mind for example).

Some plumbing commands may be too deep magic and users do not
have to directly deal with them every day.  Some other plumbing
commands are so low-level and needs combination with others to
be any useful, and it is cumbersome to type the combination
every day.  For the latter kind, we have Porcelain commands that
implement the frequently used combination and the end users do
not have to know about them.

So it is true that by having a rich and usable set of Porcelain,
there is less need for the users to know about all the plumbing
details, but I consider that is a happy consequence.  It does
not have to be the goal of having a good Porcelain to hide the
whole plumbing.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:50                       ` Linus Torvalds
@ 2006-11-15 21:18                         ` Nicolas Pitre
  0 siblings, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 21:18 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Petr Baudis, Junio C Hamano, git

On Wed, 15 Nov 2006, Linus Torvalds wrote:

> 
> 
> On Wed, 15 Nov 2006, Nicolas Pitre wrote:
> > 
> > I think "fetch" is sane.  Its only problem is a missing symetrical 
> > counterpart verb, like "get" and "put".
> 
> If you're a dog owner, the obvious counterpart for "fetch" is "throw" ;)

Yeah.  You could always throw a branch to your dog.

Or maybe we should introduce the concept of "bones" to GIT in place of 
branches?  ;-)

> I think "get" and "put" would be bad, just because of confusion with 
> "sccs get" (ie it has that "get this file" connotations).

Has SCCS really had a similar level of influence than BK or CVS in that 
matter?

> Maybe "fetch" and "push" aren't totally diametrically opposite, but 
> really, I don't think they are that hard to understand either. We do have 
> the BK legacy of "pull" implying a merge, and that's fairly fundamental. 
> 
> It's also true that in a lot of usage schenarios, what people actually 
> _use_ is "pull" and "push", and no, they aren't mirror images (since push 
> will _not_ do the merge), but at the same time, from a _usage_ standpoint 
> they really _are_ each others opposites. 

The problem is the "usage standpoint" distinction that has to be made.  
Exactly because in GIT it is a bit distorted from what most people 
expect from other standpoints.

> You "pull" to get other peoples data into your branch (and once you've 
> internalized local branches and the merge thing, you know what this 
> means), and you "push" to push your changes out. It really _is_ the usage 
> schenario, and using "opposite" words really _does_ make sense.

But that's exactly why newbies have problems.  Instead of simply 
understanding the bare operation (fetch data in a branch _then_ merge 
it) they sort of need to abstract the concept of branch away because a 
"pull" does it all automagically.  Which is fine as long as you're 
willing to ignore branch concepts altogether.  But once branches are 
back in the picture for more involved operations then the "pull" word 
simply feels odd.  Even more so with the local merge syntax.

When I say to someone "just merge branch weezee with your current 
branch" the most intuitive command would be:

	git merge weezee

But because "pull" mixes two concepts together this makes the thing more 
esoteric.  Unless, of course, you get used to the mental model you 
outlined above, but IMHO simply needing a mental model to explain the 
tool is a sign that something is mapped wrong.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 21:08                                   ` Carl Worth
@ 2006-11-15 21:31                                     ` Junio C Hamano
  2006-11-15 21:40                                       ` Nicolas Pitre
  2006-11-15 21:45                                     ` Linus Torvalds
  2006-11-21 13:25                                     ` Jerome Lovy
  2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 21:31 UTC (permalink / raw)
  To: Carl Worth; +Cc: Nicolas Pitre, Michael K. Edwards, Linus Torvalds, git

Carl Worth <cworth@cworth.org> writes:

> So there's this goofy circular notion that people end up with
> If we fix it so that a local merge really is performed with
> "git merge <branch>" instead of "git pull . <branch>" then teaching
> pull=fetch+merge really is a lot easier.

I am wondering if that could be "git merge <committish>..."
instead.  I do not care too much about the ... part (i.e. an
Octopus), but I often find myself doing:

	git checkout next
        git merge "Merge early part of branch 'foo'" HEAD foo~3

when earlier part of "foo" topic are worthy to be in 'next' but
not the later ones.

> In the meantime, pull would still be useless to me, I think. But maybe
> that's just the "default branch to merge" selection being broken.

Have you looked into per-branch configuration for default merge
source recently?  It might not be documented well enough,
though, because I do not use it myself, but you should be able
to improve on that (meaning both documentation and setting up
the defaults upon cloning and fetching).

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 21:12                             ` Josef Weidendorfer
@ 2006-11-15 21:31                               ` Linus Torvalds
  0 siblings, 0 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 21:31 UTC (permalink / raw)
  To: Josef Weidendorfer
  Cc: Petr Baudis, Jakub Narebski, git, Nicolas Pitre, Junio C Hamano



On Wed, 15 Nov 2006, Josef Weidendorfer wrote:
> 
> I am not really opposed to pull doing a merge. It only should work in
> a useful way: ie. only do the merge of updated origin branch when
> current branch is master (given "Pull: master:origin").

I absolutely agree.

We should _only_ use the default head when pulling from the default head 
("master"). If we don't pull from within the default branch, we should 
either require an explicit head _or_ we should require that an explicit 
mapping has been set up in .git/config or in .git/remotes/..

So doing a "git pull" from any other branch than "master" should probably 
by default say "which branch do you want to pull from today"?


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 21:31                                     ` Junio C Hamano
@ 2006-11-15 21:40                                       ` Nicolas Pitre
  2006-11-15 21:52                                         ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 21:40 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Carl Worth, Michael K. Edwards, Linus Torvalds, git

On Wed, 15 Nov 2006, Junio C Hamano wrote:

> I am wondering if that could be "git merge <committish>..."
> instead.  I do not care too much about the ... part (i.e. an
> Octopus), but I often find myself doing:
> 
> 	git checkout next
>         git merge "Merge early part of branch 'foo'" HEAD foo~3
> 
> when earlier part of "foo" topic are worthy to be in 'next' but
> not the later ones.

Indeed !



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 21:08                                   ` Carl Worth
  2006-11-15 21:31                                     ` Junio C Hamano
@ 2006-11-15 21:45                                     ` Linus Torvalds
  2006-11-15 22:52                                       ` Carl Worth
  2006-11-21 13:25                                     ` Jerome Lovy
  2 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 21:45 UTC (permalink / raw)
  To: Carl Worth; +Cc: Nicolas Pitre, Michael K. Edwards, git



On Wed, 15 Nov 2006, Carl Worth wrote:
> 
> Well, one of the problems is that with current git I can teach, (and I
> have), that there's a conceptual:
> 
> 	pull = fetch + merge
> 
> But then shortly after I have to teach an interface notion:
> 
> 	merge = pull .

This is why I would suggest teaching the _concept_ of the "merge", and not 
the actual command.

I don't think you should basically ever use the "git merge" command 
itself, not in teaching, and not in real life. So after talking about 
branches and having taught people to use "git fetch", the next stage is 
not so much to teach people to use "git merge", but to explain to them the 
_concept_ of merging. 

I really think that's a fairly quick thing, partly exactly _because_ you 
shouldn't at that point need to worry about syntax or details or anything 
like that at all. You just tell them that there's a notion of "merging" 
two branches by joining them together and havign the result have the 
changes from both branches. So it's a _conceptual_ issue, and that's why I 
said I think you should just totally gloss over the whole issue of "git 
merge" syntax.

Once you've explained the _concept_ of merging, you then introduce the 
command to actually _execute_ the merge: it's "git pull".

See? No circular thinking at all. One is a _concept_ ("join two branches 
together by including both in the result") and the other is a command 
("pull will fetch the remote data if any, and merge it into the current 
branch").

If you explain it that way, then _obviously_ if you don't need to fetch 
any remote data, doing "git pull . xyzzy" will merge the local branch 
"xyzzy" into the current branch.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 21:40                                       ` Nicolas Pitre
@ 2006-11-15 21:52                                         ` Junio C Hamano
  2006-11-15 21:59                                           ` Nicolas Pitre
  2006-11-17 12:20                                           ` Karl Hasselström
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 21:52 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git

Nicolas Pitre <nico@cam.org> writes:

> On Wed, 15 Nov 2006, Junio C Hamano wrote:
>
>> I am wondering if that could be "git merge <committish>..."
>> instead.  I do not care too much about the ... part (i.e. an
>> Octopus), but I often find myself doing:
>> 
>> 	git checkout next
>>         git merge "Merge early part of branch 'foo'" HEAD foo~3
>> 
>> when earlier part of "foo" topic are worthy to be in 'next' but
>> not the later ones.
>
> Indeed !

Indeed, what?

That means that updated "git merge" (not the current one) would
not be able to assume it's parameter is a branch name, and still
has to come up with the merge message "Merge <branch>".

Merging only within the local branch namespace already has the
problem you need to solve to come up with a nicely formatted
"Merge <branch> of <remote repository>" some way.  I am not
saying that this is unsolvable (you can look at remotes/ files
to see what remote tracking branch the branch is about), but
something you need to keep in mind when implementing the
improved "git merge".

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 21:52                                         ` Junio C Hamano
@ 2006-11-15 21:59                                           ` Nicolas Pitre
  2006-11-17 12:20                                           ` Karl Hasselström
  1 sibling, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 21:59 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wed, 15 Nov 2006, Junio C Hamano wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > On Wed, 15 Nov 2006, Junio C Hamano wrote:
> >
> >> I am wondering if that could be "git merge <committish>..."
> >> instead.  I do not care too much about the ... part (i.e. an
> >> Octopus), but I often find myself doing:
> >> 
> >> 	git checkout next
> >>         git merge "Merge early part of branch 'foo'" HEAD foo~3
> >> 
> >> when earlier part of "foo" topic are worthy to be in 'next' but
> >> not the later ones.
> >
> > Indeed !
> 
> Indeed, what?

What you propose would be excellent indeed.

> That means that updated "git merge" (not the current one) would
> not be able to assume it's parameter is a branch name, and still
> has to come up with the merge message "Merge <branch>".
> 
> Merging only within the local branch namespace already has the
> problem you need to solve to come up with a nicely formatted
> "Merge <branch> of <remote repository>" some way.  I am not
> saying that this is unsolvable (you can look at remotes/ files
> to see what remote tracking branch the branch is about), but
> something you need to keep in mind when implementing the
> improved "git merge".

Right.  But that is an _implementation_ detail, not a usability issue.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:57             ` Jakub Narebski
@ 2006-11-15 22:00               ` Shawn Pearce
  2006-11-15 22:17                 ` Carl Worth
  0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-15 22:00 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

Jakub Narebski <jnareb@gmail.com> wrote:
> Carl Worth wrote:
> >On Tue, 14 Nov 2006 16:31:50 -0800, Junio C Hamano wrote:
> >>
> >> For another example, having a commit command to commit
> >> everything by default is disastrous for people who allow their
> >> workflows to often be interrupted.
> > 
> > Workflow-interruption is an important thing to support, but separating
> > update-index and commit really doesn't address it nearly as much as I
> > would like. The lack of really good workflow-interruption support has
> > been one of my longest-running annoyances with git, (perhaps because I
> > have a problem with trying to do too many things at once). Git can
> > create and change branches fast enough that it really should be able
> > to help me better with this. The only missing piece is being able to
> > stash the dirty stuff on the current branch, to be able to come back
> > to it later. I've talked a bit about what I would like in this area
> > before, and I really just need to code it up.
> 
> There is git-stash/git-unstash floating somewhere in the archive.

I find that a "git commit -a -m parked; git checkout -b ..." works
well to stash my current stuff off.  Then I just amend the commit
when I come back to that branch.


The problem I just ran into today was "git checkout" doesn't double
check the file stat data against the index before switching branches.
If the file is unchanged between the two branches there's no error.
So I switched branches with dirty files that I forgot to park on
the old branch.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:41                             ` Junio C Hamano
@ 2006-11-15 22:07                               ` Shawn Pearce
  2006-11-16  6:07                               ` Marko Macek
  1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-11-15 22:07 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Marko Macek, Linus Torvalds, git, cworth, pasky

Junio C Hamano <junkio@cox.net> wrote:
> The index is quite central to the way git works at the concept
> level, and I think it is doing disservice to the end user to try
> hiding it forever from them and failing to do so, rather than
> being honest and teaching them the concept upfront.
> 
> But me thinking so does not necessarily mean you are forbidden
> from trying.  Your efforts may result in a system where the
> index is totally invisible and the end user never has to know
> about it.

I agree with what you are saying about the index.

But in git-gui I found myself writing code on Monday which tries to
hide the index from the user unless he/she requested that the index
be made visible.

The reason is there are some users who I'd like to give git-gui to
who I'm not sure I trust to make sure their index is in sync with
their working directory before they commit.  In some cases I'm lucky
that the user even knows what directory their file is stored in.  :-(
Yes, there really are computer users who are afraid of directories
and command lines.

I probably could try to teach them to make sure the final file
is included in the index before committing, but I think that for
most of them they would find this to be just another couple of
mouse clicks they have to perform before every commit, meaning its
something that the #$@!*@!*@$# tool should just do for them.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 22:00               ` Shawn Pearce
@ 2006-11-15 22:17                 ` Carl Worth
  0 siblings, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-15 22:17 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Jakub Narebski, git

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

On Wed, 15 Nov 2006 17:00:54 -0500, Shawn Pearce wrote:
> > There is git-stash/git-unstash floating somewhere in the archive.

Yes, I did write those once upon a time. ;-)

It's the manual stash/unstash that I don't want though. I want to be
able to make this happen automatically when switching branches.

> I find that a "git commit -a -m parked; git checkout -b ..." works
> well to stash my current stuff off.  Then I just amend the commit
> when I come back to that branch.

Yes, I do stuff like that as well. And often "reset HEAD~" instead of
amend, (always with a moment's pause as reset justly deserves).

> The problem I just ran into today was "git checkout" doesn't double
> check the file stat data against the index before switching branches.
> If the file is unchanged between the two branches there's no error.
> So I switched branches with dirty files that I forgot to park on
> the old branch.

Right, so that's just more evidence that this approach is a little
awkward.

Anyway, the stashing thing I want is a minor thing that should be easy
to fix in git, (as is everything we're talking about here I think).

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 19:05                           ` Marko Macek
  2006-11-15 20:41                             ` Junio C Hamano
@ 2006-11-15 22:28                             ` Sean
       [not found]                             ` <20061115172834.0a328154.seanlkml@sympatico.ca>
  2 siblings, 0 replies; 601+ messages in thread
From: Sean @ 2006-11-15 22:28 UTC (permalink / raw)
  To: Marko Macek
  Cc: Shawn Pearce, Linus Torvalds, Junio C Hamano, git, cworth, pasky

On Wed, 15 Nov 2006 20:05:27 +0100
Marko Macek <marko.macek@gmx.net> wrote:

> I guess this is the reason that the GIT Tutorial for CVS/SVN users is talking about _cogito_ instead.
> (which is very confusing for someone coming to _git_ home page, trying to learn git).

IMHO this is really bad.  Pasky runs the Git web site and feels
that Cogito comes hand in hand with Git.  When I asked him about
it he mentioned that Junio had approved.  But it's very confusing
to click a link that purports to show you how to use Git and get
shown a bunch of Cogito stuff.

Git is confusing enough for new users without "Git" and "Cogito"
being mixed without comment on the Git webpage.  At the very
least, the links should be changed to "Cogito for CVS/SVN users".


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 21:13                             ` Junio C Hamano
@ 2006-11-15 22:36                               ` Carl Worth
  2006-11-16  3:21                                 ` Petr Baudis
  0 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-15 22:36 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Andy Parkins, git

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

On Wed, 15 Nov 2006 13:13:11 -0800, Junio C Hamano wrote:
> That is a very fine example, but I do not see why it is a
> problem.  I do not think the goal of Porcelain is to make it
> totally unnecessary for users to know about the plumbing.

If not, then the promise of the porcelain fails. If cogito offers
"Here are 40 commands so you don't have to learn git's 140" and then
next says "Oh, and you'll still want to learn all those git commands
too", then its existence only makes the "too much stuff to learn"
problem worse, not better.

But I think you agree with me (for now) that fixing the git UI should
not involve creating a new primary command to replace "git".

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 21:45                                     ` Linus Torvalds
@ 2006-11-15 22:52                                       ` Carl Worth
  2006-11-15 23:02                                         ` Shawn Pearce
                                                           ` (2 more replies)
  0 siblings, 3 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-15 22:52 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Nicolas Pitre, Michael K. Edwards, git

[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]

On Wed, 15 Nov 2006 13:45:58 -0800 (PST), Linus Torvalds wrote:
> On Wed, 15 Nov 2006, Carl Worth wrote:
> >
> > Well, one of the problems is that with current git I can teach, (and I
> > have), that there's a conceptual:
> >
> > 	pull = fetch + merge
> >
> > But then shortly after I have to teach an interface notion:
> >
> > 	merge = pull .
>
> This is why I would suggest teaching the _concept_ of the "merge", and not
> the actual command.
>
> I don't think you should basically ever use the "git merge" command
> itself, not in teaching, and not in real life.

I think that's just and accident of git-merge having such a bad
syntax, (requiring a merge message, not using -m for that, requiring
two heads instead of defaulting to current, etc.). So the result is
accepting another bad syntax "pull ." for an operation that really is
merge.

> Once you've explained the _concept_ of merging, you then introduce the
> command to actually _execute_ the merge: it's "git pull".

I think we'll be doing better when there is a stronger correlation
between the concepts of the operations and the command names for
carrying them out.

Plus, when I'm teaching "fetch everything first, then manipulate it
locally", (which is what I teach, since that's the only way I use
git), then the "." looks really out of place when I teach the 'merge'
command. I end up saying, "Oh, that's there because you could do the
fetch and merge all in one step if you really wanted, but I never do
that.".

And that's because I _do_ teach fetch first, as you've suggested.

> changes from both branches. So it's a _conceptual_ issue, and that's why I
> said I think you should just totally gloss over the whole issue of "git
> merge" syntax.

That doesn't work. I know I went looking at the git-merge
documentation when I started to learn git. "It can't really be this
hard, can it?" was my reaction to it. And then only after attending a
tutorial did I learn that "pull ." is the way it's really done.

That's nothing more than a user-interface trap for new users, plain
and simple.

The real fix is to stop glossing over git-merge and just give it a
usable syntax.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 22:52                                       ` Carl Worth
@ 2006-11-15 23:02                                         ` Shawn Pearce
  2006-11-15 23:33                                           ` Linus Torvalds
  2006-11-15 23:07                                         ` Sean
       [not found]                                         ` <20061115180722.83ff8990.seanlkml@sympatico.ca>
  2 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-15 23:02 UTC (permalink / raw)
  To: Carl Worth; +Cc: Linus Torvalds, Nicolas Pitre, Michael K. Edwards, git

Carl Worth <cworth@cworth.org> wrote:
> Plus, when I'm teaching "fetch everything first, then manipulate it
> locally", (which is what I teach, since that's the only way I use
> git), then the "." looks really out of place when I teach the 'merge'
> command. I end up saying, "Oh, that's there because you could do the
> fetch and merge all in one step if you really wanted, but I never do
> that.".
> 
> And that's because I _do_ teach fetch first, as you've suggested.

Ditto.  In every way.

I've taught the same fetch first, then merge strategy.  Nobody I
know in meat-space pulls from a remote URL and merges in one shot;
they always fetch locally, look at the incoming changes, decide if
its worthwhile/ok, *then* merge with "git pull . branch".

The "." looks out of place for everyone...

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 22:52                                       ` Carl Worth
  2006-11-15 23:02                                         ` Shawn Pearce
@ 2006-11-15 23:07                                         ` Sean
       [not found]                                         ` <20061115180722.83ff8990.seanlkml@sympatico.ca>
  2 siblings, 0 replies; 601+ messages in thread
From: Sean @ 2006-11-15 23:07 UTC (permalink / raw)
  To: Carl Worth; +Cc: Linus Torvalds, Nicolas Pitre, Michael K. Edwards, git

On Wed, 15 Nov 2006 14:52:32 -0800
Carl Worth <cworth@cworth.org> wrote:

> The real fix is to stop glossing over git-merge and just give it a
> usable syntax.

Agreed 100%   There's just no good reason to hide the user level
merge command inside of pull.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
       [not found]                                         ` <20061115180722.83ff8990.seanlkml@sympatico.ca>
@ 2006-11-15 23:15                                           ` Shawn Pearce
  2006-11-16  7:51                                             ` Richard CURNOW
  0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-15 23:15 UTC (permalink / raw)
  To: Sean; +Cc: Carl Worth, Linus Torvalds, Nicolas Pitre, Michael K. Edwards, git

Sean <seanlkml@sympatico.ca> wrote:
> On Wed, 15 Nov 2006 14:52:32 -0800
> Carl Worth <cworth@cworth.org> wrote:
> 
> > The real fix is to stop glossing over git-merge and just give it a
> > usable syntax.
> 
> Agreed 100%   There's just no good reason to hide the user level
> merge command inside of pull.

So what about making git-merge take a -m "msg" argument to supply
the commit message, in which case it does the current behavior
(and thus git-pull needs to change to supply -m); and then make
git-merge without any -m parameter invoke "git pull . $@" ?

A minor tweak to both apps, a minor breakage to git-merge, but one
that I think anyone who invokes it by hand today would find sane
(using -m like we do elsewhere) and since the vintage of both
git-pull and git-merge should always match shouldn't break anyone
who uses git-pull today.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 23:02                                         ` Shawn Pearce
@ 2006-11-15 23:33                                           ` Linus Torvalds
  2006-11-16  0:08                                             ` Nicolas Pitre
                                                               ` (2 more replies)
  0 siblings, 3 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 23:33 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Carl Worth, Nicolas Pitre, Michael K. Edwards, git



On Wed, 15 Nov 2006, Shawn Pearce wrote:
> 
> I've taught the same fetch first, then merge strategy.  Nobody I
> know in meat-space pulls from a remote URL and merges in one shot;

Actually, with different people involved it's _much_ better to do it in 
one shot.

Why? Because doing a separate "fetch to local space" + "merge from local 
space" actually loses the information on what you are merging.

It's a lot more useful to have a merge message like

	Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6

than one like

	Merge branch 'for-linus'

which is what you get if you fetched it first.

Of course, in a situation like git itself, where most of the merges are 
stuff that Junio has had pending in his own tree ('maint' branch etc), 
things are different. But in a system where people actually use separate 
trees, there really is an advantage to consider the fundamental operation 
to be the "pull", not the "merge".

Again, the kernel really is more distributed than most projects, but this 
is another thing people should recognize: git has been designed for "true 
distributed development". Not the "fake" kind. Not the "I merge mainly my 
own branches" kind of thing. Truly distributed.

And in a truly distributed situation, "pull" is strictly more powerful 
than a separate "fetch" + separate "merge".

In other words, an SCM that does "pull" is _better_ than an SCM that does 
"merge". You can implement "merge" as a special case of "pull" (which we 
do), but you cannot conveniently do it the other way around without having 
to tie them together some other way (ie you could have a "remember the 
last place we fetched this branch from in order to tie the fetch and the 
merge together" - but please realize that that is exactly what "pull" 
_is_).

So I will generally do a "git pull" (possibly followed by a "git reset 
--hard ORIG_HEAD" if I decided it wasn't good) over a "git fetch" + "git 
merge". Exactly because the "pull" operation is actually more powerful.

Maybe people who aren't in my position don't always appreciate the _power_ 
of git. The reason "merge" is a second-class citizen is simply because IT 
SHOULD BE.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 23:33                                           ` Linus Torvalds
@ 2006-11-16  0:08                                             ` Nicolas Pitre
  2006-11-16  3:07                                               ` Linus Torvalds
  2006-11-16  3:02                                             ` Michael K. Edwards
  2006-11-16 16:37                                             ` Carl Worth
  2 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-16  0:08 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Shawn Pearce, Carl Worth, Michael K. Edwards, git

On Wed, 15 Nov 2006, Linus Torvalds wrote:

> 
> 
> On Wed, 15 Nov 2006, Shawn Pearce wrote:
> > 
> > I've taught the same fetch first, then merge strategy.  Nobody I
> > know in meat-space pulls from a remote URL and merges in one shot;
> 
> Actually, with different people involved it's _much_ better to do it in 
> one shot.
> 
> Why? Because doing a separate "fetch to local space" + "merge from local 
> space" actually loses the information on what you are merging.
> 
> It's a lot more useful to have a merge message like
> 
> 	Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
> 
> than one like
> 
> 	Merge branch 'for-linus'

That is an implementation detail that should be easily overcome once the 
notion of tracking branch with URL attribute is implemented.  Then it 
will be really easy to notice whether the branch argument is a local 
branch or a tracking branch with remote reference.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:16                     ` Junio C Hamano
  2006-11-15 19:02                       ` Andy Parkins
@ 2006-11-16  0:23                       ` Han-Wen Nienhuys
  1 sibling, 0 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16  0:23 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano escreveu:
> I still think in the long run you would be better off giving
> separate names to Porcelains because I am sure you are going to
> find the next command to "fix", you cannot suddenly change the

 > "ig pull", you can dismiss all the broken git-x Porcelain-ish by
 > saying "Oh, git-x user-level commands had inconsistent semantics
 > and broken UI so do not use them anymore -- they are still there
 > only to help old timers transition.  The user level commands are
 > now called ig-x and ig stands for improved git".


I think it would be good if there were different commands for 
porcelains. Not because fixing the current commands is too much work, 
but rather because it would clarify the structure of git.  GIT is a 
3-layer approach:

  - index+workdir+refs over
  - a DAG of commits over
  - a file based SHA1 database

at first sight it is difficult to tell for each command on which layer 
it operates. It would help understanding GIT a lot if each layer got 
it's own command, eg.

   git - sha1 content db
   gic - sequences of commits
   giu - UI

(Of course, these names are completely silly, but you get the idea)


> I think get/put is much better than suddenly changing what pull
> means and is shorter to type than x-load; I am Ok with them.
> Although I think these words are tainted by SCCS, I do not think
> anybody cares.

they're also tainted  by darcs, but that's a minor problem, I suppose.


-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:03                     ` Linus Torvalds
                                         ` (2 preceding siblings ...)
  2006-11-15 18:58                       ` Andy Parkins
@ 2006-11-16  1:14                       ` Theodore Tso
  2006-11-16  4:21                         ` Junio C Hamano
  2006-11-16  1:20                       ` Han-Wen Nienhuys
  2006-11-16  4:30                       ` Petr Baudis
  5 siblings, 1 reply; 601+ messages in thread
From: Theodore Tso @ 2006-11-16  1:14 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, git

On Wed, Nov 15, 2006 at 10:03:18AM -0800, Linus Torvalds wrote:
> So the reason for using "git pull" is
> 
>  - bk did it that way, and like it or not, bk was the first usable 
>    distributed system. hg is totally uninteresting.

Yes, "bk pull" had an implied merge.  But, the reason why bk pull was
never really a problem with Bitkeeper is because it didn't really have
support for multiple branches active within the same repository ---
what Larry called "lines of development".  Or rather, Larry started
down the path of implementing lines of development, and then never
fully supported it, mainly because making it easy for people to use
was the tricky part.   

So with Bitkeeper, with "bk pull" there was never any question about
which branch ("line of development") you would be merging into after
doing a "bk pull", since there was only one LOD, and given that BK had
the rule that a within a LOD only one tip was allowed, a "bk pull"
_had_ to do do a merge operation.   

The moment you start supporting multiple unmerged tips in a repository
i.e., branches, it raises the question, "which branch should the pull
operation merge onto"?  And git's answer, "the current branch", is
often not the right one.  *That's* why always doing a merge isn't
always the right answer, and so in the git world, people are told, use
"git fetch" instead, and in the hg world, "hg pull" doesn't do the
merge.  IMO, it's a fundamental result of the fact that both git and
hg have chosen to support mulitple LOD's, whereas BK punted on the
concept.

If you are operating on your local development branch, the reality is
that merging is probably not the right answer in the general case,
which is why the hg world have omitted doing the merge.  And by
telling people, use "git fetch" instead, that's also an implicit
admission that merging onto the current branch is often not the Right
Thing.

The problem is that "pull" is a very evocative word, especially given
the existence "push", and so in the git world we are reduced to
telling people, "you really don't want to use pull, trust me".  

Is this a major issue?  Not really; I can think of a number of other
issues that make git hard to learn, and why hg has a more gentle
learning curve, and the "don't use pull" is probably a relatively
minor annoyance in the grand scheme of things.

If people are looking for a simple way out, maybe it would be enough
to have an option where if "git pull" is called from an interactive
terminal, and the "novice user" option is enabled, "git pull" returns
a warning message, "You probably want to use 'git fetch' instead; are
you sure?"  If people are saying that we shouldn't be teaching "git
pull" until fairly late in the game, maybe we should have a way of
discouraging novices from using, simply because they they are used to
seeing "pull" from other distributed SCM's.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:03                     ` Linus Torvalds
                                         ` (3 preceding siblings ...)
  2006-11-16  1:14                       ` Theodore Tso
@ 2006-11-16  1:20                       ` Han-Wen Nienhuys
  2006-11-16  1:53                         ` Jakub Narebski
                                           ` (2 more replies)
  2006-11-16  4:30                       ` Petr Baudis
  5 siblings, 3 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16  1:20 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Junio C Hamano, git

Linus Torvalds escreveu:
>  - git itself has now done it that way for the last 18 months, and the 
>    fact is, the people _complaining_ are a small subset of the people who 
>    actually use git on a daily basis and don't complain.


that's not a good argument; the set of git users is a small subset of 
those that looked at git, and dismissed it because they couldn't wrap 
their heads around it.   It's worth trying to get those on board by 
fixing the annoying little issues that have popped up in this thread. 
The technical base for GIT is excellent, and the only reason for not 
using it is its arcane interface.

A version control system is often only tangentially related to the real 
work that needs to be done, so the incentive to learn it well is small, 
   and a steep learning curve only makes it worse.

FWIW, I regularly mess up with the differences between fetching, pulling 
and merging.  In particular, having to do a two step process to get 
remote changes in,

   git pull url-to-server master:master
      ..error message about not being a fast-forward..

   git pull --update-head-ok url-to-server master:master
      ..still an error message about update not being a fast-forward..

       (sigh)

   git pull url-to-server master:scrap-branch

   git pull . scrap-branch:my-current-branch

       (make mental note of deleting scrap-branch)


-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 19:18                         ` Linus Torvalds
  2006-11-15 19:39                           ` Michael K. Edwards
@ 2006-11-16  1:40                           ` Anand Kumria
  1 sibling, 0 replies; 601+ messages in thread
From: Anand Kumria @ 2006-11-16  1:40 UTC (permalink / raw)
  To: git

On Wed, 15 Nov 2006 11:18:36 -0800, Linus Torvalds wrote:

> On Wed, 15 Nov 2006, Andy Parkins wrote:
>>
>> On the one hand you're arguing that git syntax is easy to learn, and on the 
>> other that no one will be able to learn a new syntax just as easily.
> 
> I'm saying that people who are new to git will _have_ to learn new 
> concepts ANYWAY.
> 
> I don't think the naming is the hard part. 

It isn't - the unexpectedness of what happens is.

I've started by teaching how to do stuff locally, then "pushing" it out to
others (me).  All the while being able to point out how this is either all
local, or sends stuff (without any local modifications) to others.

Come up to 'pull' and ere you have to point out that not only will you get
the remote changes but they are also merged into your repository. On the
wrong branch?

Too bad.

The problem with git-pull behaving illogically drove me to look at cogito
(an aside, perhaps cg-throw should be the corrollary to cg-fetch?)
instead. Alas it has problems with a cogito branch not being something you
can mentally map back to a git branch.

> But I bet people don't teach it that way. They _start_ by teaching "pull". 
> Right?

Nope.

Anand

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:26                     ` Nicolas Pitre
  2006-11-15 20:50                       ` Linus Torvalds
@ 2006-11-16  1:51                       ` Anand Kumria
  1 sibling, 0 replies; 601+ messages in thread
From: Anand Kumria @ 2006-11-16  1:51 UTC (permalink / raw)
  To: git

On Wed, 15 Nov 2006 15:26:44 -0500, Nicolas Pitre wrote:

> On Wed, 15 Nov 2006, Petr Baudis wrote:
> 
>> On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:
>> > You have to admit both pull and fetch have been contaminated
>> > with loaded meanings from different backgrounds. I was talking
>> > about killing the source of confusion in the longer term by
>> > removing fetch/pull/push, so we are still on the same page.
>> 
>> How was/is fetch contaminated?
> 
> I think "fetch" is sane.  Its only problem is a missing symetrical 
> counterpart verb, like "get" and "put".

"throw" ?

But I think "I'll just 'throw' this set of patches at you" is a lot
harshers sounding than "I'll just 'push' this set of patches at you".

Anand

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  1:20                       ` Han-Wen Nienhuys
@ 2006-11-16  1:53                         ` Jakub Narebski
  2006-11-16  2:03                         ` Junio C Hamano
  2006-11-16  3:12                         ` Linus Torvalds
  2 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-16  1:53 UTC (permalink / raw)
  To: git

Han-Wen Nienhuys wrote:

> FWIW, I regularly mess up with the differences between fetching, pulling 
> and merging.  In particular, having to do a two step process to get 
> remote changes in,
> 
>    git pull url-to-server master:master
>       ..error message about not being a fast-forward..
> 
>    git pull --update-head-ok url-to-server master:master
>       ..still an error message about update not being a fast-forward..

What about:

     git pull --update-head-ok url-to-server +master:master

(or --force, but be careful with that one)?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  1:20                       ` Han-Wen Nienhuys
  2006-11-16  1:53                         ` Jakub Narebski
@ 2006-11-16  2:03                         ` Junio C Hamano
  2006-11-16  2:30                           ` Han-Wen Nienhuys
  2006-11-16  3:12                         ` Linus Torvalds
  2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16  2:03 UTC (permalink / raw)
  To: hanwen; +Cc: git

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> FWIW, I regularly mess up with the differences between fetching,
> pulling and merging.  In particular, having to do a two step process
> to get remote changes in,
>
>   git pull url-to-server master:master
>      ..error message about not being a fast-forward..
>
>   git pull --update-head-ok url-to-server master:master
>      ..still an error message about update not being a fast-forward..
>
>       (sigh)

Sigh indeed.

Why don't you do the simple and obvious

	git pull url master

or "git pull url" if you already know the master is the branch
you are interested in.

The more advanced form of using tracking branches are there and
documentation talks about them for completeness but that does
not mean you have to use it.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  2:03                         ` Junio C Hamano
@ 2006-11-16  2:30                           ` Han-Wen Nienhuys
  2006-11-16  3:27                             ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16  2:30 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano escreveu:
>> FWIW, I regularly mess up with the differences between fetching,
>> pulling and merging.  In particular, having to do a two step process
>> to get remote changes in,
>>
>>   git pull url-to-server master:master
>>      ..error message about not being a fast-forward..
>>
>>   git pull --update-head-ok url-to-server master:master
>>      ..still an error message about update not being a fast-forward..
>>
>>       (sigh)
> 
> Sigh indeed.
> 
> Why don't you do the simple and obvious
> 
> 	git pull url master

It is not all evident from the git-pull man-page that this is the 
obvious and most common usage.

> or "git pull url" if you already know the master is the branch
> you are interested in.

Because I usually replace verbose commands with shortcuts only when I 
understand exactly what the shortcut is.

To me it's very unlogical that

   master:current-branch

doesn't work, but

   master:

does work, and does what I'd expect

   master:current-branch

to do. Interestingly, doing

   pull ..url.. master:HEAD

also doesn't merge into the current branch, but rather creates a bogus 
refs/heads/HEAD

I use the remote:local syntax, because I started using GIT in scripted 
compiles from copied branches of remote repositories. There the explicit 
remote:local statements are necessary because there is no default branch.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 10:28                     ` Jakub Narebski
@ 2006-11-16  2:43                       ` Petr Baudis
  0 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16  2:43 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

On Wed, Nov 15, 2006 at 11:28:27AM CET, Jakub Narebski wrote:
> Santi Béjar wrote:
> 
> > On 11/15/06, Jakub Narebski <jnareb@gmail.com> wrote:
> 
> >> You mean
> >>
> >>       git merge git://repo.com/time_machine.git#branch
> >>
> >> don't you (perhaps with 'master' as default branch)?
> > 
> > perhaps with remote 'HEAD' as default branch?
> 
> No! HEAD might change without your notice, and you want to know
> which branch you merge. With remotes the default could be first
> branch in the pull/fetch list, but with bare URL...

No! If HEAD changed without your notice, it means that the remote
repository admin _wants_ you to start fetching another branch now.
Imagine a setup of these branches:

	phooey-1.2	legacy lineage
	phooey-2.0	last stable
	phooey-3.0	current development (no releases yet)
	phooey-4.0	stash for futuristic functionality, heavily
			experimental

In this case, HEAD now points to phooey-3.0 but when it becomes stable,
it would change to phooey-4.0.

The common practice of having 'master' pointing on whatever you
currently have now and and "cutting out" the branches from it at random
times is something heavily influenced by CVS where this is the only sane
way of branching (the cutting out even hardcoded in numbering scheme).
In more advanced systems, you may want to be much more flexible wrt. this
(note that I'm not saying you necessarily _should_ be).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 23:33                                           ` Linus Torvalds
  2006-11-16  0:08                                             ` Nicolas Pitre
@ 2006-11-16  3:02                                             ` Michael K. Edwards
  2006-11-16 11:35                                               ` Andreas Ericsson
  2006-11-16 16:37                                             ` Carl Worth
  2 siblings, 1 reply; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-16  3:02 UTC (permalink / raw)
  To: git

On 11/15/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Actually, with different people involved it's _much_ better to do it in
> one shot.
>
> Why? Because doing a separate "fetch to local space" + "merge from local
> space" actually loses the information on what you are merging.
>
> It's a lot more useful to have a merge message like
>
>         Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
>
> than one like
>
>         Merge branch 'for-linus'
>
> which is what you get if you fetched it first.

Full ACK from a platform integrator's perspective.  Local merge is
great for trial runs but the history in a persistent branch should be
as self-contained and self-explanatory as possible.  It shouldn't
depend on what I name local tracking branches, which are just a
convenience so that I can still do trial runs when my connectivity is
broken.

I don't have to manually log the _mechanical_origin_ of a given delta;
git does that for me, and mostly just DTRT when the same delta arrives
via several paths.  When I use git pull from a remote branch (with or
without an entry in remotes/heads, which for this purpose is just
shorthand), I don't have to manually log what conflicts I have and
haven't resolved, either; I must have assimilated whatever I cared
about in the remote branch's history up to that point, because as long
as there are things in that remote branch that I haven't decided how
to handle, I stick to cherry-picking.

Obviously, fetch to local space is great (especially when you spend
some of your working hours behind a firewall that blocks outbound TCP
9418).  Fetch from local space is also great, when the local space you
are fetching from reflects local work (such as a sync point and
reconciliation of several upstream sources, which then needs to be
ported forward or back to the chosen core version for each platform).
Fetch from a local space that is just a tracker for remote work is not
great, because it doesn't capture the editorial decision implied by a
remote pull:  I looked at what the remote branch had to offer as of
this date, systematically decided which bits did and didn't belong in
the branch to which I was pulling, and pulled.

The record of that pull becomes a first-class object because it's
attached to an actual content delta in the target branch.  So it
propagates into branches that pull from it.  Pulling this delta into
another branch is different from cherry-picking a feature delta; it
implies acceptance of the reconciliation and editorial work associated
with the merge in the source branch.

Coming from me, this is all rather theoretical, as I haven't been
using this particular tool for the purpose long enough to have an
independent opinion.  But for what it's worth, the workflow Linus
describes isn't just for the guy at the top of the pyramid.

Cheers,

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  0:08                                             ` Nicolas Pitre
@ 2006-11-16  3:07                                               ` Linus Torvalds
  2006-11-16  3:43                                                 ` Nicolas Pitre
  0 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16  3:07 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Shawn Pearce, Carl Worth, Michael K. Edwards, git



On Wed, 15 Nov 2006, Nicolas Pitre wrote:
> 
> That is an implementation detail that should be easily overcome once the 
> notion of tracking branch with URL attribute is implemented.

Nope.

I simply don't _have_ those branches.

Why? Because the kernel is _distributed_. There is no central place 
(certainly not my repository) that tracks all the possible branches that 
might get merged.

In other words, I repeat: in a TRULY DISTRIBUTED ENVIRONMENT it makes more 
sense to have a "pull" that fetches and merges, over something that 
fetches separately and then merges. Because in a truly distributed 
environment, you simply DO NOT HAVE static branches that you can associate 
with particular sources.

See?

And the thing is, I think the git design should be geared towards true 
distribution. It should NOT be geared toward a fairly static set of 
branches that all have a fairly static set of other repositories 
associated with them. Can you see the difference?

I'm personally convinced that one of the reasons people tend to use git in 
a centralized manner is just a mental disease that has its roots in how 
they used _other_ SCM's. I don't want git design to be polluted by such a 
centralized notion.

So to repeat: you can always make "pull" boil down to "pull from myself" 
(aka just "merge"), but you can _not_ make "fetch + merge" boil down to 
"pull" without meking up extra state to track separately. In other words, 
"pull" really is the strictly more powerful operation.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
       [not found]                             ` <20061115172834.0a328154.seanlkml@sympatico.ca>
@ 2006-11-16  3:07                               ` Petr Baudis
  0 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16  3:07 UTC (permalink / raw)
  To: Sean
  Cc: Marko Macek, Shawn Pearce, Linus Torvalds, Junio C Hamano, git, cworth

On Wed, Nov 15, 2006 at 11:28:34PM CET, Sean wrote:
> Git is confusing enough for new users without "Git" and "Cogito"
> being mixed without comment on the Git webpage.  At the very
> least, the links should be changed to "Cogito for CVS/SVN users".

It's not being mixed without comment, in the very first paragraph I'm
trying to explain what the difference is and why is Cogito used for
introduction to Git. I've tried to clear it up even more now.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  1:20                       ` Han-Wen Nienhuys
  2006-11-16  1:53                         ` Jakub Narebski
  2006-11-16  2:03                         ` Junio C Hamano
@ 2006-11-16  3:12                         ` Linus Torvalds
  2006-11-16 10:31                           ` Junio C Hamano
                                             ` (2 more replies)
  2 siblings, 3 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16  3:12 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git



On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:

> Linus Torvalds escreveu:
> >  - git itself has now done it that way for the last 18 months, and the
> > fact is, the people _complaining_ are a small subset of the people who
> > actually use git on a daily basis and don't complain.
> 
> 
> that's not a good argument; the set of git users is a small subset of those
> that looked at git, and dismissed it because they couldn't wrap their heads
> around it. 

And I've said this again, and I'll say it once more: that has basically 
_nothing_ to do with whether you spell "pull" as "pull" or "merge".

The reason people have trouble wrapping their heads around git is because 
they have been braindamaged by CVS and SVN, and just don't understand the 
fairly fundamental new concepts and workflow.

That's totally different from then arguing about stupid naming issues.

Peopel seem to believe that changign a few names or doing other totally 
_minimal_ UI changes would somehow magically make things understandable. I 
claim that isn't so at all. The fact is, git is different from CVS and 
SVN, and git _has_ to be different from CVS and SVN. It has to be 
different because the whole model of CVS and SVN is simpyl fundamentally 
BROKEN.

> It's worth trying to get those on board by fixing the annoying
> little issues that have popped up in this thread.

I claim that those "annoying little issues" are totally made up by people 
who had trouble wrapping their minds about git, and then make up reasons 
that have nothing to do with reality for why that might be so.

Let's face it, you could just alias "merge" to "pull", and it wouldn't 
really change ANYTHING. You'd still have to learn the new model. 


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 22:36                               ` Carl Worth
@ 2006-11-16  3:21                                 ` Petr Baudis
  2006-11-16 10:09                                   ` Robin Rosenberg
  0 siblings, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-16  3:21 UTC (permalink / raw)
  To: Carl Worth; +Cc: Junio C Hamano, Andy Parkins, git

On Wed, Nov 15, 2006 at 11:36:21PM CET, Carl Worth wrote:
> On Wed, 15 Nov 2006 13:13:11 -0800, Junio C Hamano wrote:
> > That is a very fine example, but I do not see why it is a
> > problem.  I do not think the goal of Porcelain is to make it
> > totally unnecessary for users to know about the plumbing.
> 
> If not, then the promise of the porcelain fails. If cogito offers
> "Here are 40 commands so you don't have to learn git's 140" and then
> next says "Oh, and you'll still want to learn all those git commands
> too", then its existence only makes the "too much stuff to learn"
> problem worse, not better.

I didn't get this argument before either - why do you need to learn "all
those git commands" too? You'll never have to learn "git add" or even
"git commit". If you want to pick specific git commands later (like "git
bisect", which even seeks in a Cogito-compatible way), that's fine, go
ahead! But you by no means have to learn _other_ commands than those you
need. If you want to bisect, you have to learn no other Git commands
than "git bisect".

Another point is, if using _just_ _git_ requires you to learn "all those
git commands too" from git-commit-tree up (yes it does! if you want your
authorship information to be correct), something is wrong.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  2:30                           ` Han-Wen Nienhuys
@ 2006-11-16  3:27                             ` Junio C Hamano
  2006-11-16  3:35                               ` Junio C Hamano
  2006-11-16  4:07                               ` Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16  3:27 UTC (permalink / raw)
  To: hanwen; +Cc: git

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> Junio C Hamano escreveu:
>>...
>> Sigh indeed.
>>
>> Why don't you do the simple and obvious
>>
>> 	git pull url master
>
> It is not all evident from the git-pull man-page that this is the
> obvious and most common usage.

In the git user poll a few months ago, many people recommended
"everyday git" as a good cheat sheet, and indeed it does not
talk anything about directing the underlying git-fetch to
manipulate tracking branches by giving explicit refspec pairs to
git pull.  You are obviously tripped by both the overeager
manpage (but manpage should strive to be complete so you cannot
really blame it) and less than optimally organized tutorial
style documents.

I myself do prefer, when learning a new tool, to use longhand
until I understand the shorthand, but that attitude requires a
true commitment to learn the tool, and most people do not go
that route.  Tutorial style documents tend to give the commonly
used shorthand first for that exact reason.

Shorthand to give only the branch name to fetch and merge
immediately without using a tracking branch is equivalent to
longhand "branch:" as you found out, so if that was what was
desired then people with the attitude "before understanding what
longhand does I prefer using shorthand" like myself and you
would have liked to learn "git pull url branch:" notation from
Tutorial.  But I think we _are_ minority.  People would not want
to see that seemingly useless colon there.

> To me it's very unlogical that
>
>   master:current-branch
>
> doesn't work,

That shows that you did not understand what fetch does.  Maybe
you do now, but a very natural consequence of directing fetch to
update tracking branches with the colon notation is:

 - "pull url master:master", while on master, is almost always
   wrong and not something you would want to do, ever.

   "fetch --update-head-ok url +master:master; reset --hard HEAD"

   may make sense but never "pull".

> I use the remote:local syntax, because I started using GIT in scripted
> compiles from copied branches of remote repositories. There the
> explicit remote:local statements are necessary because there is no
> default branch.

If you perhaps wanted to ask "is there a better way to do what
I've been doing?", then I am willing to think with you to come
up with an answer.  Unfortunately, however, I do not understand
the above paragraph, so I'd refrain from commenting on it in
this response.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  3:27                             ` Junio C Hamano
@ 2006-11-16  3:35                               ` Junio C Hamano
  2006-11-16  4:07                               ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16  3:35 UTC (permalink / raw)
  To: hanwen; +Cc: git

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

(not changing what I said but editorial)
> I myself do prefer, when learning a new tool, to use longhand
> until I understand the shorthand, but that attitude requires a
> true commitment to learn the tool, and most people do not go
> that route.  Tutorial style documents tend to give the commonly
> used shorthand first for that exact reason.

Eh, sorry, "prefer to use longhand until I understand what is
going on before using the shorthand" is what I wanted to say.

> Shorthand to give only the branch name to fetch and merge
> immediately without using a tracking branch is equivalent to
> longhand "branch:" as you found out, so if that was what was
> desired then people with the attitude "before understanding what
> longhand does I prefer using shorthand" like myself and you

"prefer not using shorthand", sorry again.

> would have liked to learn "git pull url branch:" notation from
> Tutorial.  But I think we _are_ minority.  People would not want
> to see that seemingly useless colon there.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  3:07                                               ` Linus Torvalds
@ 2006-11-16  3:43                                                 ` Nicolas Pitre
  0 siblings, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-16  3:43 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Shawn Pearce, Carl Worth, Michael K. Edwards, git

On Wed, 15 Nov 2006, Linus Torvalds wrote:

> 
> 
> On Wed, 15 Nov 2006, Nicolas Pitre wrote:
> > 
> > That is an implementation detail that should be easily overcome once the 
> > notion of tracking branch with URL attribute is implemented.
> 
> Nope.
> 
> I simply don't _have_ those branches.
> 
> Why? Because the kernel is _distributed_. There is no central place 
> (certainly not my repository) that tracks all the possible branches that 
> might get merged.
> 
> In other words, I repeat: in a TRULY DISTRIBUTED ENVIRONMENT it makes more 
> sense to have a "pull" that fetches and merges, over something that 
> fetches separately and then merges.
[...]

OK fine.  git-pull is there to stay and let's make sure it remains the 
same.

Let's see if, for example, git-merge can be made more useful in the mean 
time for those evidently inferior people that would prefer an interface 
that maps more closely to the actual operation that is being performed.  
And although I do understand what "pull" does, I think I should qualify 
myself as one of those inferior people nevertheless since /pull . blah" 
really irritates me.  OK I must be really dumb to let myself being 
disturbed by such an insignificant detail... but apparently I'm not 
alone.

But I promise to never change the "pull" behavior if I ever attempt to 
fix the "merge" command for the inferior mortals as myself.  All power 
to those with superior minds shall never be removed.

;-)



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  9:17               ` Andy Parkins
                                   ` (2 preceding siblings ...)
  2006-11-15 17:55                 ` Junio C Hamano
@ 2006-11-16  3:53                 ` Petr Baudis
  3 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16  3:53 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

On Wed, Nov 15, 2006 at 10:17:22AM CET, Andy Parkins wrote:
> On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:
> 
> > 3) remote branch handling should become more straight forward.
> 
> I was completely confused by this origin/master/clone stuff when I started 
> with git.  In hindsight, now I understand git a bit more, this is what I 
> would have liked:
> 
>  * Don't use the name "origin" twice.  In fact, don't use it at all.  In a 
> distributed system there is no such thing as a true origin.
> 
>  * .git/remotes/origin should be ".git/remotes/default".   "origin" is only 
> special because it is the default to push and pull - it's very nice to have a 
> default, but it should therefore be /called/ "default".

  But "default" is way too generic a name, it's much more confusing I
think. As the one guilty of inventing master and origin, I agree that
they are somewhat silly, but if I would have to pick which one to
replace with something "better", I'd much rather pick master.

  Yes, Git can operate in a completely distributed manner. People do use
it as it. And there are also people that have no origin branch in their
repository. But the vast (overwhelming!) majority of people _does_ work
in some kind of hierarchical setup, and for them origin does have a
meaning. And origin URL can even change over time!

>  * git-clone should really just be a small wrapper around
>     - git-init-db
>     - create .git/remotes/default
>     - maybe create specific .git/config
>     - git-fetch default
>    If git-clone does anything that can't be done with settings in the config 
> and the remotes/default file then it's wrong.  The reason I say this is that 
> as soon as git-clone has special capabilities (like --shared, --local 
> and --reference) then you are prevented from doing magic with existing 
> repositories.  For example; how do you create a repository that contains 
> branches from two other local repositories that have the objects hard linked?

  Here I think that modulo the lack of remotes support (which is not a
fundamental thing here), the general setup of how Cogito does stuff is
much more saner than the current Git mess. It does basically exactly
what you've said above, and even the fetching itself is IMHO written
much more cleanly than in Git. In an ideal world, Git would just take
Cogito's code here. :-)

> While I'm writing wishes, I'd like to jump on Junio's integration with other 
> fetch-backends wish.  I use git-svn, and it would be fantastic if I could 
> replace:
> 
> git-svn init --id upstream/trunk svn://host/path/trunk
> git-svn fetch --id upstream/trunk
> git-svn init --id upstream/stable svn://host/path/branches/stable
> git-svn fetch --id upstream/stable
> 
> With a .git/remotes/svn
>  SVN-URL: svn://host/path
>  Pull: trunk:refs/remotes/upstream/trunk
>  Pull: branches/stable:refs/remotes/upstream/stable
> and
>  git fetch svn
> 
> Obviously, the syntax is just made up; but you get the idea.  Even better, 
> would be if it could cope with my "*" syntax suggested above:
>  SVN-URL: svn://host/path
>  Pull: trunk:refs/remotes/upstream/trunk
>  Pull: branches/*:refs/remotes/upstream/*

  It shouldn't be hard to do at all. Have the porcelain call "protocol
drivers" based on protocol in some generic way, like
/usr/lib/git/protocol/$proto.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  3:27                             ` Junio C Hamano
  2006-11-16  3:35                               ` Junio C Hamano
@ 2006-11-16  4:07                               ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16  4:07 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: git

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

> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
>> Junio C Hamano escreveu:
>>>...
>>> Sigh indeed.
>>>
>>> Why don't you do the simple and obvious
>>>
>>> 	git pull url master
>>
>> It is not all evident from the git-pull man-page that this is the
>> obvious and most common usage.
>
> In the git user poll a few months ago, many people recommended
> "everyday git" as a good cheat sheet, and indeed it does not
> talk anything about ...

Sorry, I must have been very grumpy mood when I wrote the
message (cf. Pasky's utterance on #git a few days ago).  What I
wrote was a bit incoherent, so here is an attempt to clarify.

I should point out that the colon separated refspec pairs you
can give to "pull" was designed with considerable thought; it is
not a convenience hack that we give them to "pull" that "fetches
and merges".  Linus's and Michael's other messages in this
thread may seem to be saying that using tracking branches is not
a kosher way to use git, but I do not think that is a correct
interpretation of their messages.

The workflow that does not use any tracking branches is the
simplest and truly distributed way as Linus says.  The command
recommended in "everyday git" document:

	git pull $url $branchname

is the most natural way to express it, and simplest variant that
you do not have to say anything "colon" in it.

However that does not mean it is a bad practice to use tracking
branches.  Sometimes it is handy to be able to refer to what you
fetched from the remote the last time, possibly which is what
you merged into your branch if that last fetch was done via "git
pull", so that you can later examine its history without your
own development.  For that purpose, you need to store what you
fetched in your local refs/ namespace, and that is what tracking
branches are.

The workflow that fetches to tracking branches and then merges
within local repository as two separate steps loses the true
origin information ("Merge branch 'foo'" vs "Merge branch 'foo'
of git://git.bar.xz/foo.git").  That's the reason why not just
"git fetch" but also "git pull" take the colon separated refspec
pairs to direct git to update the tracking branches when "pull"
happenes.  The longhands are cumbersome to type all the time,
and we have shorthand, both to store URL: and Pull: lines in
remotes/ hierarchy, and also $branchname alone is a shorthand
for saying "${branchname}:", meaning "do not use a tracking
branch to store this".

So you have options to use or not to use tracking branches.
After cloning we happen to default to track all remote branches
with corresponding local tracking branches, but that is only
because may people on the list wanted to make life easier to CVS
migrants where following mostly static set of branches is the
norm ("set" is the static part: I do not mean the branches stay
still) and we wanted to make it easier for them.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  1:14                       ` Theodore Tso
@ 2006-11-16  4:21                         ` Junio C Hamano
  2006-11-16 11:34                           ` Alexandre Julliard
  2006-11-16 16:07                           ` Theodore Tso
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16  4:21 UTC (permalink / raw)
  To: Theodore Tso; +Cc: git, Nicolas Pitre, Linus Torvalds

Theodore Tso <tytso@mit.edu> writes:

> So with Bitkeeper, with "bk pull" there was never any question about
> which branch ("line of development") you would be merging into after
> doing a "bk pull", since there was only one LOD, and given that BK had
> the rule that a within a LOD only one tip was allowed, a "bk pull"
> _had_ to do do a merge operation.   

I've never used Bk and I really appreciate your comments here.

> If you are operating on your local development branch, the reality is
> that merging is probably not the right answer in the general case,

I agree, but I wonder why you are pulling/fetching (with or
without merge) if you are operating on your local development
branch (implying that you are in the middle of something else).

> ...  And by
> telling people, use "git fetch" instead, that's also an implicit
> admission that merging onto the current branch is often not the Right
> Thing.
>
> The problem is that "pull" is a very evocative word, especially given
> the existence "push", and so in the git world we are reduced to
> telling people, "you really don't want to use pull, trust me".  

I would rather say "use 'git branch' to make sure if you are
ready to merge".  Who teaches not to use "git pull"?

> If people are looking for a simple way out, maybe it would be enough
> to have an option where if "git pull" is called from an interactive
> terminal, and the "novice user" option is enabled, "git pull" returns
> a warning message,

I have to disagree with this.  In the simplest CVS-like central
repository with single branch setup in which many "novice users"
start out with, there is almost no need for "git fetch" nor
tracking branch.  You pull, resolve conflicts, attempt to push
back, perhaps gets "oh, no fast forward somebody pushed first",
pull again, then push back.  So I am not sure where "you really
do not want to use pull.  trust me" comes from.

It is a different story for people who _know_ git enough to know
what is going on.  They may be using multiple branches and
interacting with multiple remote branches, and there are times
you would want fetch and there are other times you would want
pull.  But for them, I do think the suggestion would never end
with "trust me" -- they would understand what the differences
are.




^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:40                                 ` Linus Torvalds
  2006-11-15 21:08                                   ` Carl Worth
@ 2006-11-16  4:26                                   ` Theodore Tso
  2006-11-16 11:50                                     ` Andreas Ericsson
  1 sibling, 1 reply; 601+ messages in thread
From: Theodore Tso @ 2006-11-16  4:26 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Nicolas Pitre, Michael K. Edwards, git

On Wed, Nov 15, 2006 at 12:40:43PM -0800, Linus Torvalds wrote:
> And yes, this is why you should NOT try to use the same naming as "hg", 
> for example. Last I saw, hg still didn't even have local branches, To 
> mercurial, repository == branch, and that's it. It was what I came from 
> too, and I used to argue for using git that way too. I've since seen the 
> error of my ways, and git is simply BETTER. 

Actually, that's not true.  Mercurial has local branches, just as git
does.  Some people choose not to *use* this particular feature, and
use the BK style repository == branch, but that's mainly because it's
conceptually easy for them, and a number of BK refugees are very
happily using Hg.  

It's probably because of the BK refugee population that after you do
an hg pull, it will warn you that you need to do an "hg update" in
order to merge the working directory up to the latest version that was
just pulled --- and this change was made precisely because Hg supports
local branches, and merging with the current branch isn't always the
right thing, unlike with BK.

> And the concept of local branches is exactly _why_ you have to have 
> separate "fetch" and "pull", but why you do _not_ need a separate "merge" 
> (because "pull ." does it for you).

It's just that the semantics are different, and many developers have
to use multiple DSCM's, depending on what project they happen to be
developing on.  So the reality is that there are people who have to
use bzr, git, and hg, all at the same time.  And while eventually
newbies will figure out and remember that "git pull ." == "merge", the
naming is simply confusing, that's all.  (What does "pull" have to do
with "merge"?  It's not at all obvious.)  

For somoene who uses git full-time, and to the exclusion of all other
systems, I'm sure it's not a problem at all.
	

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:03                     ` Linus Torvalds
                                         ` (4 preceding siblings ...)
  2006-11-16  1:20                       ` Han-Wen Nienhuys
@ 2006-11-16  4:30                       ` Petr Baudis
  5 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16  4:30 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, git

On Wed, Nov 15, 2006 at 07:03:18PM CET, Linus Torvalds wrote:
> If you think "pull" is confusing, I can guarantee you that _changing_ the 
> name is a hell of a lot more confusing. In fact, I think a lot of the 
> confusion comes from cogito, not from git - the fact that cogito used 
> different names and different syntax was a mistake, I think.

  I would agree that having "pull" mean something different in Cogito
than in Git was a bad idea (explanation: historically, for some period
of time Cogito had cg-pull which meant the same as cg-fetch or hg pull;
later it got renamed to cg-fetch). But I'm also happy that Cogito just
does not use the "pull" expression at all currently: "updating" seems to
be a clear and unloaded enough concept for new people. Pull is really
_very_ confusing, with it meaning something different (but not different
enough) in _all_ other systems but BK (which is basically irrelevant
nowadays).

  That said, I agree with your argument that changing it in Git now
might just result in more confusion. I'm just trying to explain Cogito's
choice here, and I believe it does no good nor harm to Core Git if it
just uses different name for the concept and avoids the original name at
all (except explaining in the docs that updating in Cogito is what
pulling is in Git).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 22:36         ` Junio C Hamano
  2006-11-14 22:50           ` Junio C Hamano
@ 2006-11-16  5:12           ` Petr Baudis
  2006-11-16 10:45             ` Junio C Hamano
                               ` (2 more replies)
  2006-11-18  7:59           ` Alan Chandler
  2 siblings, 3 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16  5:12 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre

On Tue, Nov 14, 2006 at 11:36:19PM CET, Junio C Hamano wrote:
> Commenting on the messages in this thread:
> 
>  - "resolve / resolved" are both confusing, when you are talking
>    about "mark-resolved" operation.

Well that's what "resolved" is saying. But speaking of which, it took me
_weeks_ of regular (though not extensive) usage to train my fingers to
write "stg resolved" and not "stg resolve".

>  - "pull/push/fetch" have undesired confusion depending on where
>    people learned the term.  I'd perhaps vote for replacing
>    fetch with download and push with upload.

It's too long. :-(

I think if some people have a real problem with something it's "pull",
not push or fetch. Without "pull" name, there's no confusion about
merging or not merging; and without it, there's also no confusion about
"push" and the fetch/push duality. I'm not saying that this is enough an
argument to ditch pull from Git at this point.

>  - I think it would be sensible to make remote tracking branches
>    less visible.  For example:
> 
> 	git diff origin
> 
>    where origin is the shorthand for your upstream (e.g. you
>    have .git/remotes/origin that records the URL and the branch
>    you are tracking) should be easier to understand than
> 
>    	git diff remotes/origin/HEAD
> 
>    The latter is an implementation detail.

Hmm, wait. I didn't start using refs/remotes/ yet for obvious reasons,
but wasn't it generally agreed when implementing them that what you
wrote above would work? (That a ref not found in refs/{heads,tags}/ is
looked up in remotes and if it's a directory, /HEAD is appended.) So it
doesn't for some reason?

>    I could imagine we might even want to allow
> 
> 	git diff origin#next
> 
>    to name the branch of the remote repository.  The notion of
>    "where the tips of remote repository's branches are" is
>    probably be updated by "git download" (in other words, the
>    above "git diff" does not automatically initiate network
>    transfer).

Yes, that little syntax extension would be cute to have.

> Of course, it could even be "cg" ;-).

So, here is an arbitrary list of random reasons why cg commands are not
part of git yet:

(i) Naming issues. Example: "pull" vs. "update".

(ii) Namespace issues. Big selling point of Cogito is that it's
_simple_. A very important part of that is that your command set is
limited, so that even someone who wants to fully grok Cogito is not
overwhelmed and has just few commands in front of him. I think we're
doing pretty good here, and I very carefully weight adding another
command to the set (I'm actually pondering removing some now). The
similar applies to actual commands' usage, though certainly not so
heavily; and there are few warts here.

But overally, I think this point is pretty much unsolvable and this is
where I actually think the main "incompatibleness" of Cogito and Git
with its free mix of high- and mid- and low- level commands lies. I
don't think the thread provided any solution to this either.

(ii) Behaviour issues. Example: Cogito tries to deal with uncommitted
local changes in your repository when doing stuff. It didn't shine at it
before recent improvements (post-v0.18), but it tried to preserve your
local uncommitted changes during various operations (merging,
fast-forwarding, switching branches, seeking, ...). I think historically
Git's stance to this was negative (it'd rather block the operation), I'm
not sure what the current situation is, though.

(iii) Output format issues. Example: "status" in Git and Cogito
has a completely different format in both. I'm a die-hard fan of
Cogito's format but there're surely die-hard fans of Git's.

(iv) Control issues. I'm reluctant to give up a final word on how the UI
looks like, mostly for the reason of enforcing (ii) and proper
documentation. But this is not a blocker point.

(v) Library issues. Cogito has a pretty neat shell library which it
prices; but that could be carried around. Also, Cogito requires
/bin/bash, but mostly for performance reasons (using builtins instead of
forking for external commands at some points); Git has the advantage of
simply putting that part in C, which is though something I should've
been doing more frequently too.

(vi) Coding issues. This is probably very subjective, but a blocker for
me. I have no issues about C here, but about the shell part of Git.
Well, how to say it... It's just fundamentally incompatible with me. I
*could* do things in/with it, but it's certainly something I wouldn't
_enjoy_ doing _at all_, on a deep level. I think the current shell code
is really hard to read, the ancient constructs are frequently strange at
best, etc. It's surely fine code at functional level and there'll be
people who hate _my_ style of coding and my shell code which isn't
perfect either, but it's just how it is with me.


Now, it would be absolutely awesome if we could start to bridge at least
some of these points, shuffle some functionality around and overally
reduce the code duplication, increase features count and improve general
level of world happiness.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 20:41                             ` Junio C Hamano
  2006-11-15 22:07                               ` Shawn Pearce
@ 2006-11-16  6:07                               ` Marko Macek
  2006-11-16 10:36                                 ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Marko Macek @ 2006-11-16  6:07 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Shawn Pearce, Linus Torvalds, git, cworth, pasky

Junio C Hamano wrote:
> Marko Macek <marko.macek@gmx.net> writes:
> 
>> For people switching from CVS and SVN it would be much better if the
>> index was hidden behind the scenes by using different defaults:
>>
>> git-commit -a
>> git-status -a
>> git-diff HEAD
>>
>> BTW, currently there's a minor bug: git-diff HEAD doesn't work before
>> you make the first commit. Perhaps this should be special cased.
> 
> That's only a _bug_ in your implementation of the synonym for
> "svn diff" which blindly used "git diff HEAD".


My "implementation" is taken from git-diff man page. It seems obvious
that the situation before the first commit is just a special case if 
we consider git-diff to be Porcelain (which I do).

 
> This "there is no HEAD yet" is not related to the index, but I

I agree, this is a separate issue.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 23:15                                           ` Shawn Pearce
@ 2006-11-16  7:51                                             ` Richard CURNOW
  2006-11-16 23:01                                               ` Johannes Schindelin
  0 siblings, 1 reply; 601+ messages in thread
From: Richard CURNOW @ 2006-11-16  7:51 UTC (permalink / raw)
  To: git
  Cc: Shawn Pearce, Sean, Carl Worth, Linus Torvalds, Nicolas Pitre,
	Michael K. Edwards

* Shawn Pearce <spearce@spearce.org> [2006-11-15]:
> 
> So what about making git-merge take a -m "msg" argument to supply
> the commit message, in which case it does the current behavior
> (and thus git-pull needs to change to supply -m); and then make
> git-merge without any -m parameter invoke "git pull . $@" ?

Sounds good to me.

When I'm merging in my own projects, I currently always use merge
(possibly preceded by fetch) rather than pull.  Why?  Because I don't
want my history full of commit messages like

Merge branch "trial_hack" from "../scratch_dir_with_silly_name"

In contrast to Linus's case of wanting to record where the remote merge
came from, I expressly don't want to record that - I want the merge
commit to describe conceptually what was being merged with what.

OK, I could use probably use pull with --no-commit, but I've already
trained my fingers to type out the merge syntax.  They'd be happier with
'git merge -m "Merge feature foo with fixes for bar" bar" though.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  3:21                                 ` Petr Baudis
@ 2006-11-16 10:09                                   ` Robin Rosenberg
  2006-11-16 13:46                                     ` Petr Baudis
  0 siblings, 1 reply; 601+ messages in thread
From: Robin Rosenberg @ 2006-11-16 10:09 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Carl Worth, Junio C Hamano, Andy Parkins, git

torsdag 16 november 2006 04:21 skrev Petr Baudis:
> Another point is, if using _just_ _git_ requires you to learn "all those
> git commands too" from git-commit-tree up (yes it does! if you want your
> authorship information to be correct), something is wrong.

When/why do I need git-commit-tree? Isn't git-commit enough?


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  3:12                         ` Linus Torvalds
@ 2006-11-16 10:31                           ` Junio C Hamano
  2006-11-16 10:45                           ` Han-Wen Nienhuys
  2006-11-16 23:00                           ` Johannes Schindelin
  2 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 10:31 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: git, Han-Wen Nienhuys

Linus Torvalds <torvalds@osdl.org> writes:

> And I've said this again, and I'll say it once more: that has basically 
> _nothing_ to do with whether you spell "pull" as "pull" or "merge".
>
> The reason people have trouble wrapping their heads around git is because 
> they have been braindamaged by CVS and SVN, and just don't understand the 
> fairly fundamental new concepts and workflow.
> ...
> Let's face it, you could just alias "merge" to "pull", and it wouldn't 
> really change ANYTHING. You'd still have to learn the new model. 

I had a bit different feeling about yesterday's discussion
myself.

If somebody uses git like you do in "truly distributed way", the
current pull behaviour and pull being an operational mirror to
push are natural consequence of the model and concepts, and
there is nothing to fix (modulo "the default merge source per
branch" should be made easier to use).  Renaming the pull to
merge would not make it any easier to use unless the underlying
model is understood, and I fully agree with you on that.

But for people working in a project organized around central
repository in the CVS/SVN fashion, the workflow is quite
different.  CVS does not even let you "fetch" without either
merging (co) or throwing away your work (co -C), and we already
do support that model with:

	git clone
        git pull
        work work work; git commit
        git push
        : oops not fast forward?
        git pull
        resolve work; git commit
	git push

without ever using a local branch, any tracking branch, nor
use of git-fetch.  So we do support both extremes ("truly
distributed" and "not distributed at all") reasonably well.

The trouble starts when the users hear about this wonderful
"distributed" stuff git offers, and try to use it without
understanding the key concepts.  People tend to learn by doing
and there is a leap the user need to make because now they need
to understand branched development, branches and fetching like
you explained if they want to use git the same way as you do.
Once they understand them, then the current set of tools offer
them a simple and very straightforward user interface (the tools
directly reflect the concepts and it is straightforward only
because we are talking about users who understood the concepts).

But we have to admit that this leap may rather be difficult for
people who are used to other models.  Telling them that our
model is different and it is different for a good reason does
not change the fact that the more different something is, the
more difficult to learn it.

I suspect that there could be a way to use git, not like you or
I do.  Our workflows are already quite different (e.g. you
almost never do topic branch merge yourself in your repository,
but I have abundance of them).  There is no reason to think
there won't be other workflows that are suitable for other
people.  Some workflows might be classified less distributed and
inferiour compared to the "truly git way" from "truly
distributed is the point of git" point of view, but nevertheless
could be "good enough" for those people.  In other words, a
workflow that is a bit more advanced than just a single trunk
CVS/SVN usage could still take advantage of some of the features
to support distributed development model git has, while not
taking full advantage of truly distributed nature of git.

I think the complaints in the yesterday's discussion are mostly
about frustration that, while we have a reasonable support for
the both extremes, we do not either know what that middle ground
workflow is, or even if we know what that is, we do not support
it very well.

And I am not opposed to people exploring what that different
workflow would be, and while they do so if they come up with a
set of commands (get/put perhaps) to suppor that slightly
different workflow, that would be a very good thing.

Add foreign SCM importers in the mix and the situation becomes
more difficult and interesting.  cvsimport mostly works and
quacks like git-fetch with set of tracking branches, which I
think is the right model for the importers, and would integrate
well with the current set of tools.  I believe svnimport is the
same way.  But I do not know about git-svn.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  6:07                               ` Marko Macek
@ 2006-11-16 10:36                                 ` Junio C Hamano
  2006-11-17 13:45                                   ` Jakub Narebski
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 10:36 UTC (permalink / raw)
  To: Marko Macek; +Cc: git

Marko Macek <marko.macek@gmx.net> writes:

>>> BTW, currently there's a minor bug: git-diff HEAD doesn't work before
>>> you make the first commit. Perhaps this should be special cased.
>>
>> That's only a _bug_ in your implementation of the synonym for
>> "svn diff" which blindly used "git diff HEAD".
>
> My "implementation" is taken from git-diff man page. It seems obvious
> that the situation before the first commit is just a special case if
> we consider git-diff to be Porcelain (which I do).

Yes, "git diff" is a Porcelain.  No question about it.

I do not consider the current behaviour of "git diff HEAD" that
complains instead of giving runs of "foo is a new file and no
diff is available for it" a bug; you asked for diff from some
commit but the commit you gave was bogus (does not exist yet).
But if you feel strongly about it, it should be trivial to
special case the yet-to-be-born HEAD case and run the
equilvalent of:

	git ls-files | sed -e 's/$/ is a new file, no diff is available./'

in such a case.  Or you could even go fancier and do an
equivalent of:

	git ls-files |
        while read path
        do
		l=`wc -l <"$path"`
        	echo "diff --git a/$path b/$path"
                echo "--- a/$path"
                echo "--- b/$path"
                echo "@@ -0,0 +1,$l @@"
                sed -e 's/^/+/' <"$path"
	done

and you can claim that it makes it consistent with the case
where you already have commits.

But I happen to think that consistency is only of academic
interest.  After all, how often would one create a true "root"
commit?  We are not talking about creating a new repository that
starts its life as a clone of something else, but a truly empty
one in which the initial commit is made.  And how often would
one want to view "diff" from void while preparing for that
initial commit?  Both that low frequency _and_ general
uselessness of the output from either of the above shell
scripts, would it be worth "fixing" it?

I do not think it adds any real practical value, and does not
even have much to do with being user friendly.  I would put it
in the "when somebody is really bored and has nothing better to
do, then this _could_ be done" category.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  3:12                         ` Linus Torvalds
  2006-11-16 10:31                           ` Junio C Hamano
@ 2006-11-16 10:45                           ` Han-Wen Nienhuys
  2006-11-16 11:11                             ` Junio C Hamano
  2006-11-16 16:23                             ` Cleaning up git user-interface warts Linus Torvalds
  2006-11-16 23:00                           ` Johannes Schindelin
  2 siblings, 2 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 10:45 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, git

Linus Torvalds escreveu:
>>>  - git itself has now done it that way for the last 18 months, and the
>>> fact is, the people _complaining_ are a small subset of the people who
>>> actually use git on a daily basis and don't complain.
>>
>> that's not a good argument; the set of git users is a small subset of those
>> that looked at git, and dismissed it because they couldn't wrap their heads
>> around it. 
> 
> And I've said this again, and I'll say it once more: that has basically 
> _nothing_ to do with whether you spell "pull" as "pull" or "merge".
> 
> The reason people have trouble wrapping their heads around git is because 
> they have been braindamaged by CVS and SVN, and just don't understand the 
> fairly fundamental new concepts and workflow.

 > I claim that those "annoying little issues" are totally made up by
 > people
 > who had trouble wrapping their minds about git, and then make up
 > reasons
 > that have nothing to do with reality for why that might be so.

Let me put this more personally: I continue to be bitten by stupid 
naming issues, and the myriad of little mostly non-orthogonal commands.
My head is doing just fine otherwise, and has no problems wrapping it 
around the core of GIT.  I've also used Darcs for almost a year. Darcs, 
which is much less overwhelming.

This is not about CVS or SVN, so don't put them up as a strawman.
If you want to argue that my brain is warped, use other distributed VCs 
as an example.

The following

   mkdir x y
   cd x
   hg init
   echo hoi > bla
   hg add
   hg commit -m 'yes, I am also too stupid to refuse explicit empty 
commit messages'
   cd ../y
   hg init
   hg pull ../x

pretty much works the same in Darcs, bzr and mercurial.

With GIT, this is what happens

[hanwen@haring y]$ git pull ../x
fatal: Needed a single revision
Pulling into a black hole?

[hanwen@haring y]$ git fetch ../x
warning: no common commits
remote: Generating pack...
Done counting 3 objects.
Deltifying 3 objects.
  100% (3/3) done
Total 3, wremote: ritten 3 (delta 0), reused 0 (delta 0)
Unpacking 3 objects
  100% (3/3) done

[hanwen@haring y]$ git checkout
fatal: ambiguous argument 'HEAD': unknown revision or path not in the 
working tree.
Use '--' to separate paths from revisions
fatal: Not a valid object name HEAD

[hanwen@haring y]$ git branch master
fatal: Needed a single revision

at this point, I resort to adding a bogus commit and/or editing 
.git/HEAD by hand. I'm sure there is a saner way of doing it, but I 
still haven't found out what it is.

This might not be typical GIT use, but it does show the typical GIT user 
experience, at least mine.

If you want to have another example of how not to design a 
user-interface, try the above on Monotone.

> That's totally different from then arguing about stupid naming issues.
> 
> Peopel seem to believe that changign a few names or doing other totally 
> _minimal_ UI changes would somehow magically make things understandable. I 
> claim that isn't so at all. The fact is, git is different from CVS and 
> SVN, and git _has_ to be different from CVS and SVN. It has to be 
> different because the whole model of CVS and SVN is simpyl fundamentally 
> BROKEN.
> 
>> It's worth trying to get those on board by fixing the annoying
>> little issues that have popped up in this thread.
> 
> 
> Let's face it, you could just alias "merge" to "pull", and it wouldn't 
> really change ANYTHING.

I don't want ANYTHING to really change, I just want a sane interface to it.


-- 
  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  5:12           ` Petr Baudis
@ 2006-11-16 10:45             ` Junio C Hamano
  2006-11-16 13:43               ` Petr Baudis
  2006-11-16 21:49             ` Junio C Hamano
  2006-11-17  0:11             ` Han-Wen Nienhuys
  2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 10:45 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre

Petr Baudis <pasky@suse.cz> writes:

> (v) Library issues...
> Git has the advantage of
> simply putting that part in C, which is though something I should've
> been doing more frequently too.

It should be stressed that git-core plumbing written in C is not
just for git Porcelain-ish, and it will continue to be shared
service.  We would add core support for what Porcelains need and
we would try hard to keep them generic enough so that other
Porcelains can use them.  Keeping the core and Porcelain-ish in
the same project has made it easier to keep them in sync and to
find and add missing features that would benefit Porcelains (not
limited to git Porcelain-ish).  But that should not be mistaken
as plumbing somehow belongs more to git Porcelain-ish than to
Cogito or others.

I also think you should take credit for some core improvements
you did yourself (e.g "ls-files -t" format was originally added
for the sole purpose of helping Cogito, but now others use it,
too).

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 10:45                           ` Han-Wen Nienhuys
@ 2006-11-16 11:11                             ` Junio C Hamano
  2006-11-16 11:47                               ` Junio C Hamano
  2006-11-16 13:03                               ` Han-Wen Nienhuys
  2006-11-16 16:23                             ` Cleaning up git user-interface warts Linus Torvalds
  1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 11:11 UTC (permalink / raw)
  To: hanwen; +Cc: git

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

You claim it is _an interface_ issue but it is not.

> With GIT, this is what happens
>
> [hanwen@haring y]$ git pull ../x
> fatal: Needed a single revision
> Pulling into a black hole?

You asked it to fetch from the neighbour repository and merge it
into your current branch which does not exist (I presume that
you omitted to describe what you did in directory y/ and I am
assuming you did "mkdir y && cd y && git initdb" and nothing
else).  You are pulling into a black hole.

> [hanwen@haring y]$ git fetch ../x
>...
> [hanwen@haring y]$ git checkout

You fetched without telling it in which tracking branch to store
what you fetched, and as a result your HEAD is not updated, so
your current branch still does not exist.  A failure from
checking out nothingness is not an interface issue; expectation
for it to work is a concept level issue.

> [hanwen@haring y]$ git branch master
> fatal: Needed a single revision

You are not at any commit yet and you try to create a branch?

Of course, the "right" (in some sense of the word) thing is to
do "git clone x y" in the parent directory, without creating y
upfront.

If you have an empty y to begin with, then you can do this:

	$ git fetch ../x :origin
        $ git reset --hard origin

which would mirror a part of what "git clone" would have done
for you.  It copies from the other repository, stores the tip in
your tracking branch called "origin", and make your HEAD to be
the same as origin.  After these two commands, you would have
two branches, origin and master, and you will be on master.

You can name 'origin' any way you want.  You might want to name
it 'x' to make it clear (to yourself) that it is used to track
what will happen in the neighboring repository 'x'.  Also, you
would most likely be fetching and merging from the same ../x
from now on, so it might be handy to set up the remotes for it:

	$ cat >.git/remotes/x <<EOF
        URL: ../x
        Pull: master:origin
	EOF

Then subsequent work of yours would be done on 'master' branch
(you have only two branches, and origin is a tracking branch so
you will never make commits on it, which means the above is a
logical consequence), and from time to time you would sync with
whoever is working in ../x

	$ git pull x

Here, 'x' is just a shorthand which looks up the URL: and Pull: line
through .git/remotes/x.  If your .git/remotes/ file was named origin
(not x), you could even have written:

	$ git pull

because pull defaults to 'origin' (without any other configuration).

>> Let's face it, you could just alias "merge" to "pull", and it
>> wouldn't really change ANYTHING.
>
> I don't want ANYTHING to really change, I just want a sane interface to it.

I agree that you do not want to change anything.  You just
needed a bit of handholding, because you deviated from the
cookbook usage, to correct your course.




^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  4:21                         ` Junio C Hamano
@ 2006-11-16 11:34                           ` Alexandre Julliard
  2006-11-16 14:01                             ` Petr Baudis
  2006-11-17 13:32                             ` Jakub Narebski
  2006-11-16 16:07                           ` Theodore Tso
  1 sibling, 2 replies; 601+ messages in thread
From: Alexandre Julliard @ 2006-11-16 11:34 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Theodore Tso, git, Nicolas Pitre, Linus Torvalds

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

> I would rather say "use 'git branch' to make sure if you are
> ready to merge".  Who teaches not to use "git pull"?

We do that for Wine. The problem is that we recommend using git-rebase
to make it easier for occasional developers to keep a clean history,
and rebase and pull interfere badly.

The result is that we recommend always using fetch+rebase to keep up
to date, but this is confusing many people too, because git-fetch
appears to do a lot of work yet leaves the working tree completely
unchanged, and git-rebase doesn't do anything (since in most cases
they don't have commits to rebase) but has an apparently magical
side-effect of updating the working tree.

Ideally it should be possible to have git-rebase do the right thing
even if the branch has been merged into; then we could tell people to
always use git-pull, and when they get confused by seeing merges in
their history have them do a git-rebase to clean things up.

-- 
Alexandre Julliard

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  3:02                                             ` Michael K. Edwards
@ 2006-11-16 11:35                                               ` Andreas Ericsson
  0 siblings, 0 replies; 601+ messages in thread
From: Andreas Ericsson @ 2006-11-16 11:35 UTC (permalink / raw)
  To: Michael K. Edwards; +Cc: git

Michael K. Edwards wrote:
> On 11/15/06, Linus Torvalds <torvalds@osdl.org> wrote:
>> Actually, with different people involved it's _much_ better to do it in
>> one shot.
>>
>> Why? Because doing a separate "fetch to local space" + "merge from local
>> space" actually loses the information on what you are merging.
>>
>> It's a lot more useful to have a merge message like
>>
>>         Merge branch 'for-linus' of 
>> git://one.firstfloor.org/home/andi/git/linux-2.6
>>
>> than one like
>>
>>         Merge branch 'for-linus'
>>
>> which is what you get if you fetched it first.
> 
> Full ACK from a platform integrator's perspective.  Local merge is
> great for trial runs but the history in a persistent branch should be
> as self-contained and self-explanatory as possible.  It shouldn't
> depend on what I name local tracking branches, which are just a
> convenience so that I can still do trial runs when my connectivity is
> broken.
> 

[...]

> 
> Coming from me, this is all rather theoretical, as I haven't been
> using this particular tool for the purpose long enough to have an
> independent opinion.  But for what it's worth, the workflow Linus
> describes isn't just for the guy at the top of the pyramid.
> 

I think it's unfortunate that git was originally written by Linus, since 
he so obviously is "the guy at the top of the pyramid" in many more 
senses than just "Linus said this and that patch was OK to commit", 
since git was designed to work like king Arthur's round table; "Linus is 
in the same circle as me, so ofcourse we help each other out".

All suggestions I've been reading about tracking branches, 
separate-remotes and whatnot have their merit. If any of it gets 
implemented, I'd still like to be able to do one-shot pulls from remote 
repos *without* creating specific tracking branches for it. It's 
extremely useful to fetch other peoples topic-branches into my own 
"master" (or topic-branch) when I trust their changes to be good. Please 
consider that when you're hacking away on whatever changes to do.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 11:11                             ` Junio C Hamano
@ 2006-11-16 11:47                               ` Junio C Hamano
  2006-11-20 19:44                                 ` Horst H. von Brand
  2006-11-16 13:03                               ` Han-Wen Nienhuys
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 11:47 UTC (permalink / raw)
  To: hanwen; +Cc: git

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

> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
>> [hanwen@haring y]$ git pull ../x
>> fatal: Needed a single revision
>> Pulling into a black hole?

Having said all that, I happen to think that this particular
case of pulling into void could deserve to be special cased to
pretend it is a fast forward (after all, nothingness is an
ancestor of anything), if only to make new people's first
experience more pleasant.

Working from nothingness is something not usually done in
everyday work, so from practical and technical point of view it
does not add much _real_ value to the people who actually uses
the system, but nevertheless, new people typically start
learning the system from either cloned repository (which I
believe is covered by the existing tools fairly well) or
emptiness (which bitten us here in a bad way), and making the
first experience more pleasnt to new people have a positive
value of flattening the learning curve.

So please consider that this is classified as a bug.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  4:26                                   ` Theodore Tso
@ 2006-11-16 11:50                                     ` Andreas Ericsson
  2006-11-16 16:30                                       ` Linus Torvalds
  0 siblings, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-11-16 11:50 UTC (permalink / raw)
  To: Theodore Tso; +Cc: Linus Torvalds, Nicolas Pitre, Michael K. Edwards, git

Theodore Tso wrote:
> On Wed, Nov 15, 2006 at 12:40:43PM -0800, Linus Torvalds wrote:
>> And yes, this is why you should NOT try to use the same naming as "hg", 
>> for example. Last I saw, hg still didn't even have local branches, To 
>> mercurial, repository == branch, and that's it. It was what I came from 
>> too, and I used to argue for using git that way too. I've since seen the 
>> error of my ways, and git is simply BETTER. 
> 
> Actually, that's not true.  Mercurial has local branches, just as git
> does.  Some people choose not to *use* this particular feature, and
> use the BK style repository == branch, but that's mainly because it's
> conceptually easy for them, and a number of BK refugees are very
> happily using Hg.  
> 
> It's probably because of the BK refugee population that after you do
> an hg pull, it will warn you that you need to do an "hg update" in
> order to merge the working directory up to the latest version that was
> just pulled --- and this change was made precisely because Hg supports
> local branches, and merging with the current branch isn't always the
> right thing, unlike with BK.
> 
>> And the concept of local branches is exactly _why_ you have to have 
>> separate "fetch" and "pull", but why you do _not_ need a separate "merge" 
>> (because "pull ." does it for you).
> 
> It's just that the semantics are different, and many developers have
> to use multiple DSCM's, depending on what project they happen to be
> developing on.  So the reality is that there are people who have to
> use bzr, git, and hg, all at the same time.  And while eventually
> newbies will figure out and remember that "git pull ." == "merge", the
> naming is simply confusing, that's all.  (What does "pull" have to do
> with "merge"?  It's not at all obvious.)  
> 
> For somoene who uses git full-time, and to the exclusion of all other
> systems, I'm sure it's not a problem at all.


It seems we should, cheaply, be able to avoid a large part of the 
confusion by

* Mentioning git-fetch before git-pull in all documentation newborn 
gitizens are likely to come across. Most git-users aren't Linus, and for 
every successful project the maintainers are outnumbered 100 to 1 by the 
contributors. Those projects successful *because* maintainers are 
heavily outnumbered so we should make it easier for contributors by 
teaching them the right things from the start and possibly have a 
separate man-page for maintainer (git-{maintainer,developer} man-pages, 
anyone?).
* Creating "git update" which might possibly be an internal alias to 
"git pull", except that it should read .git/remotes/* by default unless 
a specific remotes-file is specified.
* Renaming git-merge to git-merge-driver
* Implementing a git-merge that actually does what its name implies, 
possibly by making it an internal alias to pull, but with these differences:
   - It always merges into your current branch.
   - It understands "git merge branch" as well as "git merge . branch".

This is just the very low-hanging fruit. If we take these steps and let 
things cool down a bit, it would probably be proper to take a fresh look 
at this in a couple of months.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 11:11                             ` Junio C Hamano
  2006-11-16 11:47                               ` Junio C Hamano
@ 2006-11-16 13:03                               ` Han-Wen Nienhuys
  2006-11-16 13:11                                 ` Han-Wen Nienhuys
  2006-11-17 13:25                                 ` Jakub Narebski
  1 sibling, 2 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 13:03 UTC (permalink / raw)
  To: git; +Cc: git

Junio C Hamano escreveu:
> You claim it is _an interface_ issue but it is not.

 >> I don't want ANYTHING to really change, I just want a sane interface 
 >> to it.
 >
 > I agree that you do not want to change anything.  You just
 > needed a bit of handholding, because you deviated from the
 > cookbook usage, to correct your course.

Users (well, I do at least) start fiddling with systems to find out how 
they work.   Reading the manual is usually done as a last resort. I 
think this is pretty well documented in usability research.

I'm trying to show how GIT is badly suited to this. Your response is to 
explain to me what I should have done. That's nice, but that approach 
doesn't scale, because you don't reach the dozens of users out there who 
try the same, fail and give up.

If you really want to find out the weaknesses, you'd have to sit someone 
new to git in front of a computer, and let him figure how to operate it, 
while videotaping everything.

Writing a manual for newbies is also an effective (and simpler and 
cheaper) approach of figuring out what needs to be changed.



As another example:  annoyances regarding program invocation

  - option handling: -x -f -z != -xfz , "--max-count 1" doesn't work, 
but needs an '='

  - git --help lists an unordered set, which is too long scan quickly. 
I'd expect that list to either contain everything or the minimum set for 
daily use. I.e. the set introduced in a first tutorial.  Why are merge, 
prune, verify-tag there?

Try "bzr help" for comparison.

  - --pretty option with wholly uninformative options full, medium, 
short, raw.  It's not even documented what each option does.


I can go on with listing idiosyncrasies, but my point is not to get help 
from you, but rather to show how git can be improved.


>> With GIT, this is what happens
>>
>> [hanwen@haring y]$ git pull ../x
>> fatal: Needed a single revision
>> Pulling into a black hole?
> 
> You asked it to fetch from the neighbour repository and merge it
> into your current branch which does not exist (I presume that
> you omitted to describe what you did in directory y/ and I am
> assuming you did "mkdir y && cd y && git initdb" and nothing
> else).  You are pulling into a black hole.

as you remark in the other reply, there is IMO no reason for not having 
an empty 'master' branch. If master + HEAD gets created on the first 
commit, it might as well be created on the init-db.

-- 
  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 13:03                               ` Han-Wen Nienhuys
@ 2006-11-16 13:11                                 ` Han-Wen Nienhuys
  2006-11-17 13:25                                 ` Jakub Narebski
  1 sibling, 0 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 13:11 UTC (permalink / raw)
  To: git

Han-Wen Nienhuys escreveu:

> I can go on with listing idiosyncrasies, but my point is not to get help 
> from you, but rather to show how git can be improved.

oh, and another annoying one: git's insistence on firing up a pager if 
there is nothing to page, eg. try

   git-log je-n-existe-pas

-- 
  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 18:11                     ` Nicolas Pitre
@ 2006-11-16 13:21                       ` Karl Hasselström
  0 siblings, 0 replies; 601+ messages in thread
From: Karl Hasselström @ 2006-11-16 13:21 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Junio C Hamano, git

On 2006-11-15 13:11:36 -0500, Nicolas Pitre wrote:

> On Wed, 15 Nov 2006, Junio C Hamano wrote:
>
> > Nicolas Pitre <nico@cam.org> writes:
> >
> > > But again I think it is important that the URL to use must be a
> > > per branch attribute i.e. attached to "default/master" and not
> > > just "default". This way someone could add all branches of
> > > interest into the "default" group even if they're from different
> > > repositories, and a simple get without any argument would get
> > > them all.
> >
> > I think the "one group per one remote repository" model is a lot
> > easier to explain. At least when I read your first "branch group"
> > proposal that was I thought was going on and I found it quite
> > sensible (and it maps more or less straightforwardly to the way
> > existing .git/refs/remotes is set up by default).
>
> I think one group per remote repo is how things should be by default
> too. But we should not limit it to that if possible.

Without the limitation, we risk name collisions when getting all
branches from the remote repository (that is, including any new
branches we previously didn't know about).

-- 
Karl Hasselström, kha@treskal.com

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 10:45             ` Junio C Hamano
@ 2006-11-16 13:43               ` Petr Baudis
  0 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 13:43 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre

On Thu, Nov 16, 2006 at 11:45:46AM CET, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
> 
> > (v) Library issues...
> > Git has the advantage of
> > simply putting that part in C, which is though something I should've
> > been doing more frequently too.
> 
> It should be stressed that git-core plumbing written in C is not
> just for git Porcelain-ish, and it will continue to be shared
> service.  We would add core support for what Porcelains need and
> we would try hard to keep them generic enough so that other
> Porcelains can use them.  Keeping the core and Porcelain-ish in
> the same project has made it easier to keep them in sync and to
> find and add missing features that would benefit Porcelains (not
> limited to git Porcelain-ish).  But that should not be mistaken
> as plumbing somehow belongs more to git Porcelain-ish than to
> Cogito or others.

  Of course, I didn't mean to say that. I should do more often things
like adding --stdin to the fetchers. From one part, I'm used to work
with a fixed set of system tools and extending Git with the
functionality I want means changing my thinking mode and "jumping out of
the system" a bit. The other part is that I cannot use the improvements
in Cogito right away (at least not in the main branch) but I have to
wait for the next Git release; but this is mostly just an excuse. :-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 10:09                                   ` Robin Rosenberg
@ 2006-11-16 13:46                                     ` Petr Baudis
  0 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 13:46 UTC (permalink / raw)
  To: Robin Rosenberg; +Cc: Carl Worth, Junio C Hamano, Andy Parkins, git

On Thu, Nov 16, 2006 at 11:09:13AM CET, Robin Rosenberg wrote:
> torsdag 16 november 2006 04:21 skrev Petr Baudis:
> > Another point is, if using _just_ _git_ requires you to learn "all those
> > git commands too" from git-commit-tree up (yes it does! if you want your
> > authorship information to be correct), something is wrong.
> 
> When/why do I need git-commit-tree? Isn't git-commit enough?

As I said, when you need to find out how to setup your authorship
information. It's documented as deep as on the git-commit-tree level.
BTW, the documentation is another important part of the
plumbing/porcelain separation, it's not only about the list of commands
but also that porcelain documentation should be reasonably
self-contained and not require users to peek at plumbing docs in order
to find out many stuff. It's also a consideration I take when
maintaining Cogito documentation.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15  4:32             ` Nicolas Pitre
                                 ` (2 preceding siblings ...)
  2006-11-15 12:15               ` Andreas Ericsson
@ 2006-11-16 13:58               ` Petr Baudis
  3 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 13:58 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Junio C Hamano, git, Andy Whitcroft, Carl Worth

On Wed, Nov 15, 2006 at 05:32:06AM CET, Nicolas Pitre wrote:
> 1) make "git init" an alias for "git init-db".
> 
> What's the point of "-db"?  Sure we're initializing the GIT database.  
> But who cares?  The user doesn't care if GIT uses a "database" or 
> whatever.  And according to some people's definition of a "database" it 
> could be argued that GIT doesn't use a database at all in the purist 
> sense of it. What the user wants is to get started and "init" (without 
> the "-db" is so much more to the point. Doesn't matter if incidentally 
> it happens to be the same keyword HG uses for the same operation because 
> we are not afflicted by the NIH disease, right? And it has 3 chars less 
> to type which is for sure a premium improvement to the very first GIT 
> user experience!

(This is somewhat related to the HEAD issue, e.g.
<7v1wo3d6g4.fsf@assigned-by-dhcp.cox.net>, by virtue of basically
eliminating it.)

Let's see. If you are adding the alias, you can as well add some
porcelain stuffing in it, too.

What are the 99% of use cases when doing "init"?

(a) You are going to do an initial commit right away; the repository is
at this point basically useless for anything but initial commit. So you
might have "init" well just perform it for you right away.

(b) You are setting up a bare repository on a server and you will push
to it in a minute. Cogito has a separate cg-admin-setuprepo command for
it, which will also prepare it for usage by dumb servers and optionally
for shared usage in a group of users. Git could have something similar.


> 2) "pull" and "push" should be symmetrical operations
..snip..
> Conclusion:  git-pull must not perform any merge.  It is the symmetrical 
> operation of a push meaning that it pulls content from a remote branch 
> and does no more.  People understands that pretty well, .  This makes 
> git-fetch redundant (or an alias to git-pull) in that case, and again we 
> don't mind it becoming similar to in HG because we admit HG was right 
> about it.

If you _really_ want to do it in Git, the only sensible way to do it is
to stop using the "pull" verb for a command name altogether for at least
some rather long period of time, otherwise that's a blatant backwards
compatibility breakage.

> 3) remote branch handling should become more straight forward.
> 
> OK! Now that we've solved the pull issue and that everybody agrees with 
> me (how can't you all agree with me anyway) let's have a look at remote 
> branches.  It should be simple:
..snip..

By the way, due to the way you describe it, it's not all that clear to
me how is this (in)compatible with the current way we do it, on other
than the usage and git-pull's auto-creation magic level.

Is it that what you are describing _is_ in fact what we do support now,
with "branch groups" meaning "remotes" etc, and you are only proposing
some enhancements to automatically create remotes in git-pull, or are
there some other differences I've missed?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 11:34                           ` Alexandre Julliard
@ 2006-11-16 14:01                             ` Petr Baudis
  2006-11-16 15:48                               ` Alexandre Julliard
  2006-11-17 13:32                             ` Jakub Narebski
  1 sibling, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 14:01 UTC (permalink / raw)
  To: Alexandre Julliard
  Cc: Junio C Hamano, Theodore Tso, git, Nicolas Pitre, Linus Torvalds

On Thu, Nov 16, 2006 at 12:34:27PM CET, Alexandre Julliard wrote:
> Junio C Hamano <junkio@cox.net> writes:
> 
> > I would rather say "use 'git branch' to make sure if you are
> > ready to merge".  Who teaches not to use "git pull"?
> 
> We do that for Wine. The problem is that we recommend using git-rebase
> to make it easier for occasional developers to keep a clean history,
> and rebase and pull interfere badly.

How do those developers submit their changes? Do they push? If they do,
git-rebase can be saving one merge at most, and the merge is actually a
good thing (someone should write some nice standalone writeup about
that).

If they don't have push access and maintain their patches locally until
they get accepted, perhaps it would be far simpler for them to use
StGIT?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 14:01                             ` Petr Baudis
@ 2006-11-16 15:48                               ` Alexandre Julliard
  0 siblings, 0 replies; 601+ messages in thread
From: Alexandre Julliard @ 2006-11-16 15:48 UTC (permalink / raw)
  To: Petr Baudis
  Cc: Junio C Hamano, Theodore Tso, git, Nicolas Pitre, Linus Torvalds

Petr Baudis <pasky@suse.cz> writes:

> How do those developers submit their changes? Do they push? If they do,
> git-rebase can be saving one merge at most, and the merge is actually a
> good thing (someone should write some nice standalone writeup about
> that).

No, they use git-format-patch and mail them in.

> If they don't have push access and maintain their patches locally until
> they get accepted, perhaps it would be far simpler for them to use
> StGIT?

For regular developers, sure. But regular developers will need to
properly understand the git model anyway, and then they will able to
make sense even of the standard git commands ;-)  The problem is that
there isn't a smooth progression to that point.

At first, a user will simply want to download and build the code, and
for that git-pull works great, it's a one-stop command to update their
tree.

Then after a while the user will fix a bug here and there, and at that
point git-rebase is IMO the best tool, it's reasonably easy to use,
doesn't require learning other commands, and once the patch is
accepted upstream it nicely gets the tree back to the state that the
user is familiar with.

The problem is that rebase doesn't work with pull, so the user needs
to un-learn git-pull and start using git-fetch; it's to avoid this
that we recommend using git-fetch from the start, which is unfortunate
since it makes things harder for beginners.

-- 
Alexandre Julliard

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  4:21                         ` Junio C Hamano
  2006-11-16 11:34                           ` Alexandre Julliard
@ 2006-11-16 16:07                           ` Theodore Tso
  2006-11-16 16:49                             ` Theodore Tso
  2006-11-22 23:21                             ` Sanjoy Mahajan
  1 sibling, 2 replies; 601+ messages in thread
From: Theodore Tso @ 2006-11-16 16:07 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Nicolas Pitre, Linus Torvalds

On Wed, Nov 15, 2006 at 08:21:36PM -0800, Junio C Hamano wrote:
> Theodore Tso <tytso@mit.edu> writes:
> > So with Bitkeeper, with "bk pull" there was never any question about
> > which branch ("line of development") you would be merging into after
> > doing a "bk pull", since there was only one LOD, and given that BK had
> > the rule that a within a LOD only one tip was allowed, a "bk pull"
> > _had_ to do do a merge operation.   
> 
> I've never used Bk and I really appreciate your comments here.
> 
> > If you are operating on your local development branch, the reality is
> > that merging is probably not the right answer in the general case,
> 
> I agree, but I wonder why you are pulling/fetching (with or
> without merge) if you are operating on your local development
> branch (implying that you are in the middle of something else).

Well, when I was using BitKeeper, I never would.  Bitkeeper has what
Linus calls the broken "repository == branch" model.  So normally I
would have one repository where I would track the upstream branch, and
only do bk pull into that branch.  I would do my hacking in another
repository (i.e., branch), and periodically keep track wha was going
on in mainline by cd'ing to the mainline repository and doing the bk
pull there.  

The challenge when you put multiple branches into a single repository,
is you have to keep track of which branch you happen to be in.  In the
BK world, this was obvious because it would show up in my shell
prompt:

<tytso@candygram>       {/usr/src/linux-2.6}
2% 

(OK, obviously I'm in the Linux 2.6 upstream repository)

In a system where you need to keep track of what branch you are in via
an SCM-specific local state information, it's easy to get confused and
do a pull when you are in the "wrong" branch, or while you have local
state in your working directory.   

What I currently do (and I'm sure I'm being really horrible and need
to be say 100 "Hail, Linus"'es for penance for not adhering staying in
the one true distributed state of grace) is that I keep an entirely
separate Linux 2.6 git repository just to make sure I never get
confused about what branch I might happen to be in when I do the "git
pull" --- and yeah, I could have used "git fetch", but 3+ years of BK
usage plus Hg usage is hard to get away from.  I'm sure this is where
Linus would say that use of BK and Hg, causes permanent brain damage,
ala's Dijkstra's ofted quoted comment about use of Basic inducing
brain damage....

> I have to disagree with this.  In the simplest CVS-like central
> repository with single branch setup in which many "novice users"
> start out with, there is almost no need for "git fetch" nor
> tracking branch.  You pull, resolve conflicts, attempt to push
> back, perhaps gets "oh, no fast forward somebody pushed first",
> pull again, then push back.  So I am not sure where "you really
> do not want to use pull.  trust me" comes from.

I think the problem is the people who have had years of BK or Hg
experience.  Maybe it's more of a documentation problem; perhaps a
"git for BK" or "git for Hg" users is what's needed.  The problem
though is that while use of BK is definitely legacy, there are going
to be a lot of people who need to use both BK and Hg.   

> It is a different story for people who _know_ git enough to know
> what is going on.  They may be using multiple branches and
> interacting with multiple remote branches, and there are times
> you would want fetch and there are other times you would want
> pull.  But for them, I do think the suggestion would never end
> with "trust me" -- they would understand what the differences
> are.

Well, I think this is where git's learning curve challenges are.  Yes,
for users that are doing the stupidest, most simplistic usage models,
git is quite easy to use.  And I am willing to grant that for people
who are using the deepest, most complicated and most distributed
development, who understand multiple branches and the index, and all
of the deep git plumbing, there's also no problem.

The challenge is in between; to use a car analogy, git has a great
automatic transmision, and an extremely powerful "racing clutch".  But
for someone where the automatic transmission isn't good enough, when
as they start to learn how to use the manual transmission, git's
extremely touchy "racing clutch" is much more difficult master ---
especially in comparison to people who have learned to drive other,
more pedestrian "standard transmission" cars.  So people who try to
use git's racing clutch keep stalling out the car, and some give up in
frustration.

And maybe the problem is one that should be addressed only by lots of
training, but at the moment, that's the reason why I believe a number
of projects have chosen Hg instead of git; they need more than the
"stupid simple" git usage, but if they don't need the extreme power of
git, Hg is simpler for people to learn how to use.  The problem, of
course, comes when later on, the project finds out they really want
git's power, and now they have to deal with the repository conversion
as well as retraining their entire development community.

But hey, maybe this isn't a problem the git community wants to solve;
clearly git is optimized for the Linux kernel development, and maybe
it's too much to ask that it also work well for somewhat less
extremely distributed development models.  But in any case, that's why
I chose Hg for e2fsprogs.  At the time when I made my choice, git was
just too painful to learn how to use its more esoteric features, and
Hg was much closer to BK's model.  (Since then, Hg has added more
functionality, including better multiple branches in a repository
support, and it's gotten more complicated, but it's still much simper
to teach someone how to use Hg than git.)

Regards,


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 10:45                           ` Han-Wen Nienhuys
  2006-11-16 11:11                             ` Junio C Hamano
@ 2006-11-16 16:23                             ` Linus Torvalds
  2006-11-16 16:42                               ` Han-Wen Nienhuys
  1 sibling, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 16:23 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git



On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
> 
> This is not about CVS or SVN, so don't put them up as a strawman.
> If you want to argue that my brain is warped, use other distributed VCs as an
> example.

Your example has nothing at all to do with "pull" vs "fetch", though.

Your example is about something totally _different_, namely that under 
git, "git init-db" is _only_ for creating a _new_ project.

> The following
> 
>   mkdir x y
>   cd x
>   hg init
>   echo hoi > bla
>   hg add
>   hg commit -m 'yes, I am also too stupid to refuse explicit empty commit messages'
>   cd ../y
>   hg init
>   hg pull ../x
> 
> pretty much works the same in Darcs, bzr and mercurial.
> 
> With GIT, this is what happens
> 
> [hanwen@haring y]$ git pull ../x

Bzzt. This is where you went wrong, and you blamed "pull".

The way you do this in git is to NOT do "git init". Instead, you replace 
all the

	mkdir y
	cd ../y
	hg init
	hg pull ../x

with a simple

	git clone x y

and YOU ARE DONE.

Now, we could certainly _make_ "git pull" work on an empty git project, 
but that has _nothing_ to do with what people have been talking about.

In fact, the fact that "git fetch" kind of works is not exactly accidental 
(because "git fetch" _is_ meant to add new local branches too), but all 
the problems you have with it are due to the SAME issue. You started 
without any branch at all, because you started with an empty git repo, and 
you're simply not _supposed_ to do that.

So current rule (and this is not new, it's always been true): the ONLY 
time you use "git init-db" is when you are going to start a totally new 
project. Never _ever_ otherwise. If you want to track another project, use 
"git clone".

> This might not be typical GIT use, but it does show the typical GIT user
> experience, at least mine.

It's not that it isn't typical, it's that you are using the wrong model. 
Maybe it's not well documented, I can easily give you that, but ALL your 
problems come from that fundamental starting point: you shouldn't have 
used "git init-db" in the first place.

Somebody want to document it?

Alternatively, we certainly _could_ make "git pull" just accept an empty 
git repo, and make it basically create the current branch.

(And we probably should improve the error messahe)

> I don't want ANYTHING to really change, I just want a sane interface to it.

The sane interface _exists_. It's called "git clone".


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 11:50                                     ` Andreas Ericsson
@ 2006-11-16 16:30                                       ` Linus Torvalds
  2006-11-16 17:01                                         ` Carl Worth
  0 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 16:30 UTC (permalink / raw)
  To: Andreas Ericsson; +Cc: Theodore Tso, Nicolas Pitre, Michael K. Edwards, git



On Thu, 16 Nov 2006, Andreas Ericsson wrote:
> 
> * Mentioning git-fetch before git-pull in all documentation newborn gitizens
> are likely to come across.

However, I also think it might make sense to talk about the _simple_ form 
of "git pull" first.

The form I use is actually a lot simpler (conceptually) than the "short" 
form.

When you do

	git pull <reponame> <branchname>

there are very few things that can confuse you (although trying to do it 
without a current branch at all is apparently one such thing ;). 

There are no local branches to worry about, and there aren't any issues 
about what the default repository or branchname on the remote side would 
be either.

So in many ways, if you use this format, you simply never have to worry. 
You may have to _type_ a bit more, so it's not the short or concise 
format, but it sure is the _simple_ format. There simply isn't anything to 
be confused about.

And yes, I actually tend to use this even for project that I don't develop 
on, partly because the defaults for the short and concise formats are bad. 
For example, I follow the "modesetting" branch on the xorg intel graphics 
driver tree, and because I'm always on that branch, what I do is

	git pull origin modesetting

which works correctly (while "git pull" would _not_ have done the right 
thing: it would have picked the right repository, but it would have picked 
the "master" branch of that repository, not the "modesetting" branch).

And notice how I don't do _any_ development there, I just follow that 
branch. The "merge" will obviously always be a fast-forward, but that's 
exactly what I want. 

> Most git-users aren't Linus, and for every successful project the 
> maintainers are outnumbered 100 to 1 by the contributors.

Well, as mentioned, I think even for non-developers, doing pulls with 
explicit branchnames is actually perfectly sane.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 23:33                                           ` Linus Torvalds
  2006-11-16  0:08                                             ` Nicolas Pitre
  2006-11-16  3:02                                             ` Michael K. Edwards
@ 2006-11-16 16:37                                             ` Carl Worth
  2006-11-16 17:57                                               ` Michael K. Edwards
  2 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-16 16:37 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Shawn Pearce, Nicolas Pitre, Michael K. Edwards, git

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

On Wed, 15 Nov 2006 15:33:43 -0800 (PST), Linus Torvalds wrote:
> It's a lot more useful to have a merge message like
>
> 	Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
>
> than one like
>
> 	Merge branch 'for-linus'

There's more information in the first, sure. But I absolutely don't
accept that it's necessarily more useful, and definitely not that this
is a good argument for using pull with a remote branch instead of
fetch followed by merge with a local branch.

First, the pull may just fast-forward in which case there's no message
at all. And we've been through that topic enough recently that we all
know that no important information is lost by not doing any separate
recording in that case.

So you can't turn around and argue that the remote URL information is
suddenly important when it just so happens that it's not a fast
forward.

> And in a truly distributed situation, "pull" is strictly more powerful
> than a separate "fetch" + separate "merge".

I don't buy it. In my usage, I have several different remote
repositories I'm interested in tracking, each with any number of
branches. What I really want is an easy command that fetches all of
those branches, (even new ones that I've never heard about---but never
any of their "tracking branches" that wouldn't be of interest to
me). And I want to do that once, to get the online-access-required
part over with and get all the data into my local repository where I
can start working with it.

As for the URL from which I'm fetching all this stuff, it's really not
interesting to me at all. The URL for "Keith's stuff" keeps changing
anyway---I have no interest in recording that. But I do think it's
worth recording that the commits came from Keith's repository. I do
that right now with a keith/ prefix for his branches. It could also be
done by bringing in his .git/description during the fetch and storing
it somewhere. But I honestly don't see how storing something like that
during would make the system any less distributed in any sense.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 16:23                             ` Cleaning up git user-interface warts Linus Torvalds
@ 2006-11-16 16:42                               ` Han-Wen Nienhuys
  2006-11-16 17:17                                 ` Linus Torvalds
  0 siblings, 1 reply; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 16:42 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Junio C Hamano, git

Linus Torvalds escreveu:

> So current rule (and this is not new, it's always been true): the ONLY 
> time you use "git init-db" is when you are going to start a totally new 
> project. Never _ever_ otherwise. If you want to track another project, use 
> "git clone".

Actually, only a 2 weeks ago, you suggested that I share the website
and main source code for my project in a single repository for reasons
of organization.

In this setup I find it logical to do

  git init-db
  git pull ..url.. website/master

to wind up with just the 5mb website, instead of the complete 70mb
of packed source code with all of its branches and tags.

> It's not that it isn't typical, it's that you are using the wrong model. 
> Maybe it's not well documented, I can easily give you that, but ALL your 
> problems come from that fundamental starting point: you shouldn't have 
> used "git init-db" in the first place.
> 
> Somebody want to document it?
> 
> Alternatively, we certainly _could_ make "git pull" just accept an empty 
> git repo, and make it basically create the current branch.

Yes, I would like that.  


-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 16:07                           ` Theodore Tso
@ 2006-11-16 16:49                             ` Theodore Tso
  2006-11-22 23:21                             ` Sanjoy Mahajan
  1 sibling, 0 replies; 601+ messages in thread
From: Theodore Tso @ 2006-11-16 16:49 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Nicolas Pitre, Linus Torvalds

On Thu, Nov 16, 2006 at 11:07:00AM -0500, Theodore Tso wrote:
> I think the problem is the people who have had years of BK or Hg
> experience.  Maybe it's more of a documentation problem; perhaps a
> "git for BK" or "git for Hg" users is what's needed.  The problem
> though is that while use of BK is definitely legacy, there are going
> to be a lot of people who need to use both BK and Hg.   

Err, what I meant to say is that there are going to be a lot of people
who will need to simultaneously use both git and Hg.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 16:30                                       ` Linus Torvalds
@ 2006-11-16 17:01                                         ` Carl Worth
  2006-11-16 17:30                                           ` Linus Torvalds
  0 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-16 17:01 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andreas Ericsson, Theodore Tso, Nicolas Pitre, Michael K. Edwards, git

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

On Thu, 16 Nov 2006 08:30:55 -0800 (PST), Linus Torvalds wrote:
> The form I use is actually a lot simpler (conceptually) than the "short"
> form.
>
> When you do
>
> 	git pull <reponame> <branchname>

Yes, that's what the user almost always wants. The UI problem here is
that the conceptually simpler form is syntactically longer, (which
means users aren't likely to find it).

So if we can just get <reponame> and <branchname> to default
correctly, (based on the current branch name, and clone/fetch/pull
history), then the conceptually simple form ends up syntactically
simple as "git pull".

And I definitely don't have any problem with that. I'd love to be able
to teach that kind of simple thing to new users.

> driver tree, and because I'm always on that branch, what I do is
>
> 	git pull origin modesetting
...
> Well, as mentioned, I think even for non-developers, doing pulls with
> explicit branchnames is actually perfectly sane.

The behavior is sane, but having to always type the branch name
specifically because it never changes... that's a user-interface bug.

This is a good example of the kind of thing I wanted to hit when
starting this thread. I don't think there are any big conceptual
changes needed in git to make it easier for new users. But there are
little things that are problems that really should be fixed. Wouldn't
it be great to have the following exchange:

	User: How do I track on-going development in a branch?
	Master: Use "git pull"

Rather than:

	User: How do I track on-going development in a branch?
	Master Use "git pull origin <name-of-branch-you-are-already-on>"

?

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 16:42                               ` Han-Wen Nienhuys
@ 2006-11-16 17:17                                 ` Linus Torvalds
  2006-11-16 17:40                                   ` multi-project repos (was Re: Cleaning up git user-interface warts) Han-Wen Nienhuys
                                                     ` (2 more replies)
  0 siblings, 3 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 17:17 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git



On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
> 
> Actually, only a 2 weeks ago, you suggested that I share the website
> and main source code for my project in a single repository for reasons
> of organization.
> 
> In this setup I find it logical to do
> 
>   git init-db
>   git pull ..url.. website/master

I don't disagree per se. It should be easy to support, it's just that it's 
not traditionally been something we've ever done.

So the way you'd normally set up a single repo that contains multiple 
other existing repositories is to basically start with one ("git clone") 
and then add the other branches and "git fetch" them.

So again, instead of "git init-db" + "git pull", you'd just use "git 
clone" instead.

Note that there _is_ another difference between "git pull" and 
"fetch+merge". The difference being that "git pull" implicitly does the 
checkout for you (I say "implicitly", because that's the way the git 
merge conceptually works: we always merge in the working tree. That's not 
the only way it _could_ be done, though - for trivial merges, we could do 
them without any working tree at all, but we don't suppotr that).

And that "git pull" semantic actually means that if you want a _bare_ 
repository, I think "git --bare init-db" + "git --bare fetch" actually 
does exactly the right thing right now too. But "git pull" would not be 
the right thing to use.

Btw, another normal way to generate a central "multi-headed repo" for is 
to not use "pull" or "fetch" or "clone" at ALL, but I would likely do 
something like

	mkdir central-repo
	cd central-repo
	git --bare init-db

and that's it. You now have a central repository, and you _never_ touch it 
again in the central place except to repack it and do other "maintenance" 
(eg pruning, fsck, whatever).

Instead, from the _outside_, you'd probably just do

	git push central-repo mybranch:refs/heads/central-branch-name

(actually, you'd probably set up that branch-name translation of 
"mybranch:refs/heads/central-branch-name" in your remote description, but 
I'm writing it out in full as an example).

So there are many ways to do it. It just happens that "git init-db" 
followed by "git pull" is not one of them ;)

(And the real reason for that is simple: "git pull" simply wants to have 
something to _start_ with. It's not hugely fundamental, it's just how it 
was written).


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 17:01                                         ` Carl Worth
@ 2006-11-16 17:30                                           ` Linus Torvalds
  2006-11-16 17:44                                             ` Sean
  0 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 17:30 UTC (permalink / raw)
  To: Carl Worth
  Cc: Andreas Ericsson, Theodore Tso, Nicolas Pitre, Michael K. Edwards, git



On Thu, 16 Nov 2006, Carl Worth wrote:
>
> On Thu, 16 Nov 2006 08:30:55 -0800 (PST), Linus Torvalds wrote:
> > The form I use is actually a lot simpler (conceptually) than the "short"
> > form.
> >
> > When you do
> >
> > 	git pull <reponame> <branchname>
> 
> Yes, that's what the user almost always wants. The UI problem here is
> that the conceptually simpler form is syntactically longer, (which
> means users aren't likely to find it).

Yeah. 

And this is something I absolutely agree with. Our default branches for 
"pull" are horrible. You can "fix" it, but you can only fix it by adding 
_explicit_ branches to your .git/config file by hand, so I don't think 
that's actually a real fix at all. We should just fix the default (where 
even a "I don't know what branch you want" _error_ would be preferable 
over the current situation).

Along with the "git checkout <tag>" thing, I think these two things are 
definitely worth just fixing.

> The behavior is sane, but having to always type the branch name
> specifically because it never changes... that's a user-interface bug.

Yeah. Each branch should

 (a) have a "default source" initialized on the initial "clone"

 (b) have a way to set the source afterwards

 (c) error out if you do just a "git pull" or "git pull remotename" if 
     there is no default branch for the current local branch for that 
     remote.

We actually have (b) in a weak form right now ("weak" because it requires 
you to manually edit the config file: we've got the mechanism, but not a 
nice UI for it), but (a) and (c) are just broken.

And yeah, we should allow pulling into a branch that hasn't been 
initialized.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-16 17:17                                 ` Linus Torvalds
@ 2006-11-16 17:40                                   ` Han-Wen Nienhuys
  2006-11-16 18:21                                     ` Linus Torvalds
  2006-11-16 17:57                                   ` Cleaning up git user-interface warts Linus Torvalds
  2006-11-16 18:13                                   ` Carl Worth
  2 siblings, 1 reply; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 17:40 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, git

Linus Torvalds escreveu:
> 
> On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
>> Actually, only a 2 weeks ago, you suggested that I share the website
>> and main source code for my project in a single repository for reasons
>> of organization.
>>
>> In this setup I find it logical to do
>>
>>   git init-db
>>   git pull ..url.. website/master
> 
> I don't disagree per se. It should be easy to support, it's just that it's 
> not traditionally been something we've ever done.
> 
> So the way you'd normally set up a single repo that contains multiple 
> other existing repositories is to basically start with one ("git clone") 

You're misunderstanding me: the multi-repo is at git.sv.gnu.org is the
remote one. The example I gave was about locally creating a single
project repo from a remote multiproject repo. 

On a tangent: why is there no reverse-clone?  I have no shell access
to the machine, so when I created the remote repo, I had to push, and
ended up putting 1.2 Gb data on the server.

<looks at manpage>

is this send-pack? From UI perspective it would be nice if this could
also be done with clone,

  git clone . ssh+git://....

>And that "git pull" semantic actually means that if you want a _bare_ 
>repository, I think "git --bare init-db" + "git --bare fetch" actually

yes, this works. Two remarks:


* it needs

  website/master:master

otherwise you still don't have a branch.

* why are objects downloaded twice?  If I do

  git --bare fetch git://git.sv.gnu.org/lilypond.git web/master

it downloads stuff, but I don't get a branch. If I then do 

  git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master

it downloads the same stuff again. 

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 17:30                                           ` Linus Torvalds
@ 2006-11-16 17:44                                             ` Sean
  0 siblings, 0 replies; 601+ messages in thread
From: Sean @ 2006-11-16 17:44 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Carl Worth, Andreas Ericsson, Theodore Tso, Nicolas Pitre,
	Michael K. Edwards, git

On Thu, 16 Nov 2006 09:30:47 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:

> Yeah. Each branch should
> 
>  (a) have a "default source" initialized on the initial "clone"
>
> (b) have a way to set the source afterwards
>
> (c) error out if you do just a "git pull" or "git pull remotename" if 
>     there is no default branch for the current local branch for that 
>     remote.

This would be _great_.  You just shouldn't have to hack at the
.git/config file to get reasonable default sources after a clone.
Or even for that matter after fetching a new branch into an
existing repo.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 16:37                                             ` Carl Worth
@ 2006-11-16 17:57                                               ` Michael K. Edwards
  2006-11-16 18:23                                                 ` Carl Worth
  0 siblings, 1 reply; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-16 17:57 UTC (permalink / raw)
  To: Carl Worth; +Cc: git

On 11/16/06, Carl Worth <cworth@cworth.org> wrote:
> First, the pull may just fast-forward in which case there's no message
> at all. And we've been through that topic enough recently that we all
> know that no important information is lost by not doing any separate
> recording in that case.
>
> So you can't turn around and argue that the remote URL information is
> suddenly important when it just so happens that it's not a fast
> forward.

When it's a fast forward, the puller hasn't had to make any judgment
calls, so there's no editorial history to record.  When it's not, but
the puller chooses to retain the result on a persistent branch, that
_is_ an editorial decision (even if the result of the auto-merge is
clean); I like having that in the history.

> > And in a truly distributed situation, "pull" is strictly more powerful
> > than a separate "fetch" + separate "merge".
>
> I don't buy it. In my usage, I have several different remote
> repositories I'm interested in tracking, each with any number of
> branches. What I really want is an easy command that fetches all of
> those branches, (even new ones that I've never heard about---but never
> any of their "tracking branches" that wouldn't be of interest to
> me). And I want to do that once, to get the online-access-required
> part over with and get all the data into my local repository where I
> can start working with it.

What do you want all of those branches for?  They haven't been
published to you (that's a human interaction that doesn't go through
git), so for all you know they're just upstream experiments, and doing
things with them is probably shooting yourself in the foot.

I do agree that a robust form of "for b in .git/remotes/*; do git
fetch `basename $b`; done" would be a nice bit of porcelain.  The
entries in .git/remotes would probably need to grow a "Fetch-options:"
field so that you could choose whether or not to follow tags, etc.
Patch to follow.

Cheers,

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 17:17                                 ` Linus Torvalds
  2006-11-16 17:40                                   ` multi-project repos (was Re: Cleaning up git user-interface warts) Han-Wen Nienhuys
@ 2006-11-16 17:57                                   ` Linus Torvalds
  2006-11-16 18:27                                     ` Junio C Hamano
  2006-11-16 18:28                                     ` Linus Torvalds
  2006-11-16 18:13                                   ` Carl Worth
  2 siblings, 2 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 17:57 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git



On Thu, 16 Nov 2006, Linus Torvalds wrote:
> 
> (And the real reason for that is simple: "git pull" simply wants to have 
> something to _start_ with. It's not hugely fundamental, it's just how it 
> was written).

Here's a very lightly tested patch that allows you to use "git pull" to 
populate an empty repository.

I'm not at all sure this is necessarily the nicest way to do it, but it's 
fairly straightforward.

Junio, what do you think?

		Linus

---
diff --git a/git-pull.sh b/git-pull.sh
index ed04e7d..7e5cee2 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -44,10 +44,10 @@ do
 	shift
 done
 
-orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
+orig_head=$(git-rev-parse --verify HEAD 2> /dev/null)
 git-fetch --update-head-ok --reflog-action=pull "$@" || exit 1
 
-curr_head=$(git-rev-parse --verify HEAD)
+curr_head=$(git-rev-parse --verify HEAD 2> /dev/null)
 if test "$curr_head" != "$orig_head"
 then
 	# The fetch involved updating the current branch.
@@ -80,6 +80,11 @@ case "$merge_head" in
 	exit 0
 	;;
 ?*' '?*)
+	if test -z "$orig_head"
+	then
+		echo >&2 "Cannot merge multiple branches into empty head"
+		exit 1
+	fi
 	var=`git-repo-config --get pull.octopus`
 	if test -n "$var"
 	then
@@ -95,6 +100,12 @@ case "$merge_head" in
 	;;
 esac
 
+if test -z "$orig_head"
+then
+	git-update-ref -m "initial pull" HEAD $merge_head "" || exit 1
+	exit
+fi
+
 case "$strategy_args" in
 '')

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 17:17                                 ` Linus Torvalds
  2006-11-16 17:40                                   ` multi-project repos (was Re: Cleaning up git user-interface warts) Han-Wen Nienhuys
  2006-11-16 17:57                                   ` Cleaning up git user-interface warts Linus Torvalds
@ 2006-11-16 18:13                                   ` Carl Worth
  2 siblings, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-16 18:13 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On Thu, 16 Nov 2006 09:17:32 -0800 (PST), Linus Torvalds wrote:
> So the way you'd normally set up a single repo that contains multiple
> other existing repositories is to basically start with one ("git clone")
> and then add the other branches and "git fetch" them.

For that we'd also need a way for clone to be able to fetch just a
single branch, and not all of them as well.

There is some clone vs. fetch asymmetry here that has annoyed me for a
while, and that I don't think has been mentioned in this thread
yet. Namely:

clone: can only be executed once, fetches all branches, "remembers"
       URLs for later simplified use

fetch: can be executed many times, fetches only named branches,
       doesn't remember anything for later

I've often been in the situation where I cloned a long time ago, but
I'd like to be able to fetch everything that I would get if I were to
start a fresh clone.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-16 17:40                                   ` multi-project repos (was Re: Cleaning up git user-interface warts) Han-Wen Nienhuys
@ 2006-11-16 18:21                                     ` Linus Torvalds
  2006-11-16 18:33                                       ` multi-project repos Junio C Hamano
                                                         ` (3 more replies)
  0 siblings, 4 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 18:21 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git



On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
> 
> You're misunderstanding me: the multi-repo is at git.sv.gnu.org is the
> remote one. The example I gave was about locally creating a single
> project repo from a remote multiproject repo. 

Ahh.

Ok, try the patch I just sent out, and see if it works for you. It 
_should_ allow you to do exactly that

	mkdir new-repo
	cd new-repo
	git init-db
	git pull <remote> <onehead>

and now your "master" branch should be initialized to "onehead".

Oh, except I just realized that I forgot to do a "git checkout" in my 
patch, so you'd need to add that (or do it by hand, but you really 
shouldn't need to, since the checkout is implied by the "pull").

The downside with this is that it does NOT populate your "remotes" 
information (like "git clone" would have done), so either we'd need to 
teach "git pull" to do that too, or you just have to do it by hand (so 
that you then can do the shorthand "git pull" to update in the future).

> On a tangent: why is there no reverse-clone?  I have no shell access
> to the machine, so when I created the remote repo, I had to push, and
> ended up putting 1.2 Gb data on the server.

Yeah, you're supposed to "init-db" and "push". Right now, that tends to 
unpack everything (which is bad), although that is hopefully getting fixed 
(ie the receiving end shouldn't unpack any more if it is recent. Junio?)

> <looks at manpage>
> 
> is this send-pack?

"git push" uses send-pack internally, you shouldn't ever need to use it 
yourself.

> From UI perspective it would be nice if this could also be done with clone,
> 
>   git clone . ssh+git://....

The creation of a new archive tends to need special rights (with _real_ 
ssh access and a shell you could do it, but "ssh+git" really means "git 
protocol over a connection that was opened with ssh, but doesn't 
necessarily have a real shell at the other end").

So for most protocols, you simply cannot (and shouldn't) do it. Think 
about services like the one that Pasky has set up, that allow you to set 
up a new git repo - the setup phase really _has_ to be separate (because 
you need to set up your keys etc).

So I think the above syntax is actually not a good one, because it cannot 
work in the general case. It's much better to get used to setting up a 
repo first, and then pushing into it, and just accepting that it's a 
two-phase thing.

Also, from a bandwidth standpoint, you can often (although obviously not 
always) make the setup start with something that is _closer_ to what you 
want to do. So, for example, you'd often do something like:

 (a) ssh to central repository
 (b) create the new repository by cloning it _locally_ at the central 
     place from some other repository that is related
 (c) then, from your local (non-central) repository, do a "git push --force"
     to force your changes (which now only needs the _incremental_ thing).

An example of this is again the "forking" thing that he repos at  at 
http://git.or.cz/ already supports. 


> >And that "git pull" semantic actually means that if you want a _bare_ 
> >repository, I think "git --bare init-db" + "git --bare fetch" actually
> 
> yes, this works. Two remarks:
> 
> * it needs
> 
>   website/master:master
> 
> otherwise you still don't have a branch.

Right. In fact, you should probably do

	website/master:refs/heads/master

just to make it really explicit.

> * why are objects downloaded twice?  If I do
> 
>   git --bare fetch git://git.sv.gnu.org/lilypond.git web/master
> 
> it downloads stuff, but I don't get a branch.

A "fetch" by default won't actually generate a local branch unless you 
told it to. It just squirrels the end result into the magic FETCH_HEAD 
name, so that you can do

	# do the fetch
	git fetch git://git.sv.gnu.org/lilypond.git web/master

	# look at changes
	gitk ..FETCH_HEAD

	# If you're happy with them, merge them in
	git merge "merge new code" HEAD FETCH_HEAD

and you never actually created a real local branch at all.

If you want "git fetch" to fetch _into_ a branch, you need to tell it so, 
by using the full "src:dest" format. Otherwise it doesn't know what branch 
to fetch it into.

(And, of course, you can define that branch relationship in your remote 
configuration, so you don't actually have to say it explicitly every time)

> If I then do 
> 
>   git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master
> 
> it downloads the same stuff again. 

Right. So you can either

 (a) do it that way to begin with (because you now told it to put the 
     results in "master", so you never needed to do the second fetch in 
     the first place)

or

 (b) after you did the first fetch (into FETCH_HEAD), you could also have 
     just decided to do 

	git update-ref HEAD FETCH_HEAD ""

     (where that "" at the end is really not technically necessary, but it 
     tells "update-ref" that you _only_ want to do this if the old HEAD 
     was empty/undefined. Without it, "git update-ref" will just 
     overwrite HEAD without caring what it contained before, so it can be 
     a dangerous operation!)

See?


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 17:57                                               ` Michael K. Edwards
@ 2006-11-16 18:23                                                 ` Carl Worth
  2006-11-17  8:41                                                   ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-16 18:23 UTC (permalink / raw)
  To: Michael K. Edwards; +Cc: git

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

On Thu, 16 Nov 2006 09:57:00 -0800, "Michael K. Edwards" wrote:
> What do you want all of those branches for?  They haven't been
> published to you (that's a human interaction that doesn't go through
> git), so for all you know they're just upstream experiments, and doing
> things with them is probably shooting yourself in the foot.

The same "what do you want them all for" question could be asked of
git-clone which also fetches all available branches. I really just
want to be able to easily watch what's going on in multiple
repositories.

I want to be able to just say "git update" (or whatever) and then be
able to list and browse and explore the stuff locally.

Yes, there's still outside communication that's necessary, but with
the ability to easily track all the remote branches that communication
can be even less formal if I can easily browse and explore things
locally. For example, I might not even know the name of the branch:

Me: Have you pushed a branch for your new work on the frob-widget?
Friend: Yes

And then I can "get fetch" and see "cool-new-frob" come in without
having to be told that name. Or I could have even just fetched
without the specific communication if I was already expecting it for
some reason.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 17:57                                   ` Cleaning up git user-interface warts Linus Torvalds
@ 2006-11-16 18:27                                     ` Junio C Hamano
  2006-11-16 18:28                                     ` Linus Torvalds
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 18:27 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: git

Linus Torvalds <torvalds@osdl.org> writes:

> On Thu, 16 Nov 2006, Linus Torvalds wrote:
>> 
>> (And the real reason for that is simple: "git pull" simply wants to have 
>> something to _start_ with. It's not hugely fundamental, it's just how it 
>> was written).
>
> Here's a very lightly tested patch that allows you to use "git pull" to 
> populate an empty repository.
>
> I'm not at all sure this is necessarily the nicest way to do it, but it's 
> fairly straightforward.
>
> Junio, what do you think?

Yeah, I talked about making "merge" treat missing HEAD as a
special case of fast forward, but I like yours better.  It is a
lot cleaner and to the point.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 17:57                                   ` Cleaning up git user-interface warts Linus Torvalds
  2006-11-16 18:27                                     ` Junio C Hamano
@ 2006-11-16 18:28                                     ` Linus Torvalds
  2006-11-16 19:47                                       ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 18:28 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git



On Thu, 16 Nov 2006, Linus Torvalds wrote:
> @@ -95,6 +100,12 @@ case "$merge_head" in
>  	;;
>  esac
>  
> +if test -z "$orig_head"
> +then
> +	git-update-ref -m "initial pull" HEAD $merge_head "" || exit 1
> +	exit
> +fi
> +

So this is the place that probably wants a "git-checkout" before the 
exit, otherwise you'd (illogically) have to do it by hand for that 
particular case.

Of course, we should _not_ do it if the "--bare" flag has been set, so you 
migth want to tweak the exact logic here.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos
  2006-11-16 18:21                                     ` Linus Torvalds
@ 2006-11-16 18:33                                       ` Junio C Hamano
  2006-11-16 19:01                                       ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
                                                         ` (2 subsequent siblings)
  3 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 18:33 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: git, Han-Wen Nienhuys

Linus Torvalds <torvalds@osdl.org> writes:

> Yeah, you're supposed to "init-db" and "push". Right now, that tends to 
> unpack everything (which is bad), although that is hopefully getting fixed 
> (ie the receiving end shouldn't unpack any more if it is recent. Junio?)

Correct.

> See?
>
> 			Linus

Saw.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-16 18:21                                     ` Linus Torvalds
  2006-11-16 18:33                                       ` multi-project repos Junio C Hamano
@ 2006-11-16 19:01                                       ` Linus Torvalds
  2006-11-17 16:26                                         ` Shawn Pearce
  2006-11-16 22:21                                       ` multi-project repos (was Re: Cleaning up git user-interface warts) Johannes Schindelin
  2006-11-16 23:32                                       ` Han-Wen Nienhuys
  3 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 19:01 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git



On Thu, 16 Nov 2006, Linus Torvalds wrote:
> 
> A "fetch" by default won't actually generate a local branch unless you 
> told it to. It just squirrels the end result into the magic FETCH_HEAD 
> name [...]

Btw, the magic heads are probably not all that well documented. They do 
come up in the man-pages, but I don't think there is any central place 
talking about them. We have:

 - "HEAD" itself, which is obviously the default pointer for a lot of 
   operations, and that specifies the current branch (ie it should 
   currently always be a symref, although we've talked about relaxing 
   that)

 - "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge 
   (or some other operations, like "git rebase" and "git reset": think of 
   it as a "original head before we did some uncontrolled operation 
   where we otherwise can't use HEAD^ or similar")

   I use "gitk ORIG_HEAD.." a lot, and if I don't like something I see 
   when I do it, I end up doing "git reset --hard ORIG_HEAD" to undo a 
   pull I've done. This is important exactly because ORIG_HEAD is _not_ 
   the same as the first parent of a merge, since a merge could have been 
   just a fast-forward.

 - "FETCH_HEAD" as mentioned. Normally you'd only use this in scripting, I 
   suspect, but it's potentially useful if you prefer to do a fetch first 
   and then check out it (perhaps cherry-picking stuff instead of merging, 
   for example).

   So you could do (for example)

	git fetch some-other-repo branch
	gitk ..FETCH_HEAD
	git cherry-pick <some-particular-commit-you-picked>

 - "MERGE_HEAD" is kind of the opposite of "ORIG_HEAD" when you're in 
   the middle of a merge: it's the "other" branch that you're merging.

   It's mainly useful for merge resolution, ie

	git log -p HEAD...MERGE_HEAD -- some/file/with/conflicts

   is a great way to see what happened along both branches (note the 
   _triple_ dot: it's a symmetric difference), to see _why_ the confict 
   happened.

Most of the above are used implicitly in various cases, not just HEAD. The 
"--merge" flag to git-rev-list (and thus git log and friends) is just 
shorthand for the above "HEAD...MERGE_HEAD" behaviour (with the addition 
of also limiting the result to just conflicting files), so

	git log -p --merge

is basically exactly the same as the above (except for _all_ files that 
have conflicts in them rather than just one hand-specified one).

Anyway, maybe somebody didn't know about these, and finds them useful. 
Normally, the only one you would _really_ use is "ORIG_HEAD" (which is 
described in several of the tutorials and examples, so people hopefully 
already know about it). Most of the others tend to mostly be used 
implicitly, not by explicitly naming them - although you _can_.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 18:28                                     ` Linus Torvalds
@ 2006-11-16 19:47                                       ` Junio C Hamano
  2006-11-16 19:53                                         ` Linus Torvalds
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 19:47 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Han-Wen Nienhuys, git

Linus Torvalds <torvalds@osdl.org> writes:

> On Thu, 16 Nov 2006, Linus Torvalds wrote:
>> @@ -95,6 +100,12 @@ case "$merge_head" in
>>  	;;
>>  esac
>>  
>> +if test -z "$orig_head"
>> +then
>> +	git-update-ref -m "initial pull" HEAD $merge_head "" || exit 1
>> +	exit
>> +fi
>> +
>
> So this is the place that probably wants a "git-checkout" before the 
> exit, otherwise you'd (illogically) have to do it by hand for that 
> particular case.
>
> Of course, we should _not_ do it if the "--bare" flag has been set, so you 
> migth want to tweak the exact logic here.

As you said, pull inherently involve a merge which implies the
existence of associated working tree, so I do not think there is
any room for --bare to get in the picture.  We already do the
checkout when we recover from a fetch that is used incorrectly
and updated the current branch head underneath us.

To give the list a summary of the discussion so far, here is a
consolidated patch.

-- >8 --
From: Linus Torvalds <torvalds@osdl.org>
Subject: git-pull: allow pulling into an empty repository

We used to complain that we cannot merge anything we fetched
with a local branch that does not exist yet.  Just treat the
case as a natural extension of fast forwarding and make the
local branch'es tip point at the same commit we just fetched.
After all an empty repository without an initial commit is an
ancestor of any commit.

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

---
diff --git a/git-pull.sh b/git-pull.sh
index ed04e7d..e23beb6 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -44,10 +44,10 @@ do
 	shift
 done
 
-orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
+orig_head=$(git-rev-parse --verify HEAD 2>/dev/null)
 git-fetch --update-head-ok --reflog-action=pull "$@" || exit 1
 
-curr_head=$(git-rev-parse --verify HEAD)
+curr_head=$(git-rev-parse --verify HEAD 2>/dev/null)
 if test "$curr_head" != "$orig_head"
 then
 	# The fetch involved updating the current branch.
@@ -80,6 +80,11 @@ case "$merge_head" in
 	exit 0
 	;;
 ?*' '?*)
+	if test -z "$orig_head"
+	then
+		echo >&2 "Cannot merge multiple branches into empty head"
+		exit 1
+	fi
 	var=`git-repo-config --get pull.octopus`
 	if test -n "$var"
 	then
@@ -95,6 +100,13 @@ case "$merge_head" in
 	;;
 esac
 
+if test -z "$orig_head"
+then
+	git-update-ref -m "initial pull" HEAD $merge_head "" &&
+	git-read-tree --reset -u HEAD || exit 1
+	exit
+fi
+
 case "$strategy_args" in
 '')
 	strategy_args=$strategy_default_args

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 19:47                                       ` Junio C Hamano
@ 2006-11-16 19:53                                         ` Linus Torvalds
  0 siblings, 0 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 19:53 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Han-Wen Nienhuys, git



On Thu, 16 Nov 2006, Junio C Hamano wrote:
> 
> As you said, pull inherently involve a merge which implies the
> existence of associated working tree, so I do not think there is
> any room for --bare to get in the picture.

Fair enough. Feel free to add the signed-off-by from me too, 


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  5:12           ` Petr Baudis
  2006-11-16 10:45             ` Junio C Hamano
@ 2006-11-16 21:49             ` Junio C Hamano
  2006-11-16 22:20               ` Petr Baudis
  2006-11-17  0:11             ` Han-Wen Nienhuys
  2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 21:49 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre

Petr Baudis <pasky@suse.cz> writes:

> (vi) Coding issues. This is probably very subjective, but a blocker for
> me. I have no issues about C here, but about the shell part of Git.
> Well, how to say it... It's just fundamentally incompatible with me. I
> *could* do things in/with it, but it's certainly something I wouldn't
> _enjoy_ doing _at all_, on a deep level. I think the current shell code
> is really hard to read, the ancient constructs are frequently strange at
> best, etc. It's surely fine code at functional level and there'll be
> people who hate _my_ style of coding and my shell code which isn't
> perfect either, but it's just how it is with me.

I've been thinking about revamping the style of shell scripts in
git-core Porcelain-ish for some time, and I have a feeling that
now may be a good time to do so, after one feature release is
out and the list is discussing UI improvements.

But before mentioning the specifics, let me mention one tangent.
I recently installed an OpenBSD bochs (it was actually a qemu
image) without knowing much about the way of the land, and after
adjusting myself to necessary glitches (like "make" being called
"gmake" there), I saw git properly built and pass its selftest.
I was pleasantly surprised when I noticed there was no 'bash' on
the system after all that.

I would like to keep it that way.

I'll list things I would want to and not want to change.
Comments from the list are very appreciated.  You can say things
in two ways:

 * I guarantee that the _default_ shell on all sane platforms we
   care about handle this construct correctly, although it was
   not in the original Bourne.  There is no reason to stay away
   from it these days.

or

 * You've stayed away from this construct but now you say you
   feel it is Ok to use it.  Don't.  It would break with the
   shell on my platform (or "it is a bad practice because of
   such and such reasons").

I do not think many people can say the former with authority
unless you have a portability lab (the company I work for used
to be like that and it was an interesting experience to learn
all about irritating implementation differences).  And "POSIX
says shell should behave that way" is _not_ what I want to hear
about.

But the latter should be a lot easier to say, and would be
appreciated because it would help us avoid regressions.

Things I would want to change:

 - One indent level is one tab and the tab-width is eight
   columns.  Some of our scripts tend to use less than eight
   spaces for indentation to avoid line wrapping.

 - More use of shell functions are fine.   Especially if the
   above change makes lines too long, the logic should be
   refactored.

 - It is so 80-ish to follow certain portability and performance
   wisdom.  The following should go:

   . Use "case" when you do not have to use "if test".

   . Avoid ${parameter##word} and friends and use `expr` instead
     to pick a string apart.

   . Avoid "export name=word", write "name=word; export name"
     instead.

   . Avoid ${parameter:-word} and friends when ${parameter-word}
     would do.

Things I do not want to change:

 - The shell scripts should start with #!/bin/sh, not
   #!/bin/bash (nor even worse "#!/usr/bin/env sh").

 - Shell functions are written as "name () { ... }" without 
   "function" noiseword.

 - 'foo && bar || exit' exits with the error code of what
   failed; no need to say 'exit $?'.

 - String equality check for "test" is a single =, not ==. 

 - Do not use locals.

 - Do not use shell arrays.

 - In general, if something does not behave the same way in ksh,
   bash and dash, don't use it (that does not mean these three
   are special; it just means if something is not even portable
   across these three, it is a definite no-no).

I do not think I need to list other common-sense shell idioms in
the latter category (e.g. 'using "test z$name = zexpected" when
we do not know what $name contains' falls into that).

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 21:49             ` Junio C Hamano
@ 2006-11-16 22:20               ` Petr Baudis
  2006-11-17  1:49                 ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 22:20 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre

On Thu, Nov 16, 2006 at 10:49:36PM CET, Junio C Hamano wrote:
> I would like to keep it that way.

I agree - I certainly don't want to infect Git with bash dependency.

> And "POSIX says shell should behave that way" is _not_ what I want to
> hear about.

Actually, which sane platforms we care about have /bin/sh that is NOT
POSIX compatible?

> Things I would want to change:

What about [ instead of test? And

	if foo; then

instead of

	if foo
	then

?


Am I the only one who hates

case "$log_given" in
tt*)
        die "Only one of -c/-C/-F can be used." ;;
*tm*|*mt*)
        die "Option -m cannot be combined with -c/-C/-F." ;;
esac

instead of having this stuff in explicit variables and writing out some
explicit boolean expressions? (There _are_ few cases where the case is
cool, but they are rare.)


It would be really great if Git would have something alike the Cogito's
optparse infrastructure. I'm not sure if you can implement it in Bourne
sh with reasonable performance, though...


I think addressing these three particular points would make the scripts
hugely more coder-friendly. (And well, I usually say that coding style
is not *that* important and is frequently overemphasised. But that holds
only to a certain point. ;-)


> Things I do not want to change:
..snip all those I agree with..
>  - Do not use locals.

It's a pity. :-( Which shell doesn't support them?

It's not that huge a deal, though.

>  - Do not use shell arrays.

This is quite a larger deal, I think; but the portability concerns are
very real, I guess. :|

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-16 18:21                                     ` Linus Torvalds
  2006-11-16 18:33                                       ` multi-project repos Junio C Hamano
  2006-11-16 19:01                                       ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
@ 2006-11-16 22:21                                       ` Johannes Schindelin
  2006-11-16 22:44                                         ` multi-project repos Junio C Hamano
  2006-11-16 22:49                                         ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
  2006-11-16 23:32                                       ` Han-Wen Nienhuys
  3 siblings, 2 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-16 22:21 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git

Hi,

On Thu, 16 Nov 2006, Linus Torvalds wrote:

> On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
> > 
> > * why are objects downloaded twice?  If I do
> > 
> >   git --bare fetch git://git.sv.gnu.org/lilypond.git web/master
> > 
> > it downloads stuff, but I don't get a branch.
> 
> A "fetch" by default won't actually generate a local branch unless you 
> told it to.

This is actually a perfect example for

- a script that is porcelain as well as plumbing (you are supposed to use 
it directly, or via pull), and for

- a terrible UI.

_If_ you use git-fetch directly you virtually always want to store the 
result. I was tempted quite often to submit a patch which adds a command 
line switch --no-warn, which is passed to git-fetch by git-pull, and 
without which git-fetch complains if the branch-to-be-fetched is not 
stored right away (and refuses to go along).

_Also_, git-pull not storing the fetched branches at least temporarily 
often annoyed me: the pull did not work, and the SHA1 was so far away I 
could not even scroll to it. The result: I had to pull (and fetch!) the 
whole darned objects again. Again, I was tempted quite often to submit a 
patch which makes git-pull fetch the branches into refs/fetch-temp/* and 
only throw them away when the merge succeeded.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos
  2006-11-16 22:21                                       ` multi-project repos (was Re: Cleaning up git user-interface warts) Johannes Schindelin
@ 2006-11-16 22:44                                         ` Junio C Hamano
  2006-11-17  0:29                                           ` Johannes Schindelin
  2006-11-16 22:49                                         ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 22:44 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, Linus Torvalds

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

> _If_ you use git-fetch directly you virtually always want to store the 
> result. I was tempted quite often to submit a patch which adds a command 
> line switch --no-warn, which is passed to git-fetch by git-pull, and 
> without which git-fetch complains if the branch-to-be-fetched is not 
> stored right away (and refuses to go along).
>
> _Also_, git-pull not storing the fetched branches at least temporarily 
> often annoyed me: the pull did not work, and the SHA1 was so far away I 
> could not even scroll to it. The result: I had to pull (and fetch!) the 
> whole darned objects again. Again, I was tempted quite often to submit a 
> patch which makes git-pull fetch the branches into refs/fetch-temp/* and 
> only throw them away when the merge succeeded.

I think the earlier write-up by Linus on magic HEADs would help
documenting FETCH_HEAD better.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-16 22:21                                       ` multi-project repos (was Re: Cleaning up git user-interface warts) Johannes Schindelin
  2006-11-16 22:44                                         ` multi-project repos Junio C Hamano
@ 2006-11-16 22:49                                         ` Linus Torvalds
  2006-11-16 23:08                                           ` Linus Torvalds
                                                             ` (2 more replies)
  1 sibling, 3 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 22:49 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, Junio C Hamano, git



On Thu, 16 Nov 2006, Johannes Schindelin wrote:
>
> - a terrible UI.

Why? We _do_ have the temporary branch. It's called FETCH_HEAD.

> _Also_, git-pull not storing the fetched branches at least temporarily 
> often annoyed me: the pull did not work, and the SHA1 was so far away I 
> could not even scroll to it.

Again, why didn't you use FETCH_HEAD?

If the user doesn't give us a head to write to, we clearly MUST NOT write 
to any long-term branch. That would be a _horrible_ mistake. 

So all your complaints seem totally misplaced. The UI is both usable and 
practical, and your complaint that git pull doesn't store the fetched 
branches is just NOT TRUE.

And your "solution" is obviously totally unusable. git ABSOLUTELY MUST NOT 
overwrite any existing branches unless explicitly told to do so by the 
user.

So I really don't see your point. 

A lot of the complaints seem to not be about the interfaces, but about 
people not _understanding_ and knowing what the interfaces do. If you were 
confused about something (like not realizing that FETCH_HEAD is there and 
very much usable), how about sending in a patch to make FETCH_HEAD use 
clearer in whatever docs you looked at and didn't find it mentioned in.

Now, there is no question that some of the interfaces can get a bit 
"interesting" to use. For example, if you really don't want to re-fetch 
for some reason, FETCH_HEAD actually does contain enough information that 
you should be able to just re-do a failed merge, for example, including 
the message generation. But at that point it really _does_ get a bit 
complicated, and you end up doing something like

	git merge "$(git fmt-merge-msg < .git/FETCH_HEAD)" HEAD FETCH_HEAD

which should _work_, but I'm not going to claim that it's all that easy to 
understand.

(That said, read that one-liner a few times, and suddenly it doesn't seem 
_that_ complicated any more, now does it? You can probably even guess what 
it's really going to do, even if you don't know git all that well. It's 
not unreadable line noise, is it?)

Of course, if I had a merge that failed (the most common reason being that 
I had some uncommitted patch in a file that wanted to be updated by the 
merge), I'd never actually do the above one-liner. I'd just re-do the 
pull. But if networking was _really_ slow, and I _really_ cared, maybe I'd 
do the above.

(And no, I didn't actually test the above one-liner. Maybe it doesn't work 
for some reason. Somebody should check, just for fun).


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  3:12                         ` Linus Torvalds
  2006-11-16 10:31                           ` Junio C Hamano
  2006-11-16 10:45                           ` Han-Wen Nienhuys
@ 2006-11-16 23:00                           ` Johannes Schindelin
  2006-11-16 23:22                             ` Linus Torvalds
  2 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-16 23:00 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git

Hi,

On Wed, 15 Nov 2006, Linus Torvalds wrote:

> Peopel seem to believe that changign a few names or doing other totally 
> _minimal_ UI changes would somehow magically make things understandable. 

Never ever underestimate pet peeves. If we give many people an obvious 
reason (however trivial and bike-shed-coloured) to complain, they will 
complain.

If we pull (pun intended) that reason away under their collective 
backsides, they will have to find another reason to complain. But by the 
time they found something, they will already be happy git users!

But since you just provided a patch to make life easier on non-gitters, I 
guess you agree with that already.

And hopefully you also agree that enhancing the syntax of git-merge to 
grok "git-merge [-m message] <branch>" and "git-merge [-m message] 
<url-or-remote> <branch>" would be a lovely thing, luring even more 
people into using git.

Maybe they even start complaining about subversion and CVS calling a merge 
"update", who knows?

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  7:51                                             ` Richard CURNOW
@ 2006-11-16 23:01                                               ` Johannes Schindelin
  0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-16 23:01 UTC (permalink / raw)
  To: Richard CURNOW; +Cc: git

Hi,

On Thu, 16 Nov 2006, Richard CURNOW wrote:

> In contrast to Linus's case of wanting to record where the remote merge
> came from, I expressly don't want to record that - I want the merge
> commit to describe conceptually what was being merged with what.
> 
> OK, I could use probably use pull with --no-commit, but I've already
> trained my fingers to type out the merge syntax.  They'd be happier with
> 'git merge -m "Merge feature foo with fixes for bar" bar" though.

For the moment, if you forget --no-commit, you can always do a "git-commit 
--amend" -- even with merges.

Hth,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-16 22:49                                         ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
@ 2006-11-16 23:08                                           ` Linus Torvalds
  2006-11-16 23:36                                           ` Johannes Schindelin
  2006-11-16 23:40                                           ` Han-Wen Nienhuys
  2 siblings, 0 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 23:08 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, Junio C Hamano, git



On Thu, 16 Nov 2006, Linus Torvalds wrote:
>
> 	git merge "$(git fmt-merge-msg < .git/FETCH_HEAD)" HEAD FETCH_HEAD

Btw, I'd like to claim that this is a _great_ user interface.

Yeah, it's different from other SCM's. I don't think you'd really want to 
script a merge like this in CVS, especially not using standard UNIX 
pipelines etc. But it's an example of how a lot of git operations - even 
the "high level ones" are pretty scriptable, using very basic and very 
simple standard UNIX shell scripting.

So even though I'd not actually _do_ the above one-liner, I think it's a 
great example of how git really works, and how scriptable it can be, 
without a lot of huge problems.

So considering that "FETCH_HEAD" works pretty much everywhere, and that 
you can also use the totally non-scripting approach of doing "standard" 
SCM things like

	git diff ..FETCH_HEAD

or 

	gitk HEAD...FETCH_HEAD

to look at what got fetched (and in the latter case look at both the 
current HEAD _and_ FETCH_HEAD, and what was in one but not the other), I 
really think it's unfair to say that "git fetch" does not have a nice UI.

It's just that "git fetch" can be used two totally different ways:

 - "git fetch" to get something temporary: use FETCH_HEAD, and do _not_ 
   specify a destination branch

 - "git fetch" as a way to update the branches you already have, by either 
   using explicit branch specifiers (which would be unusual, but works), 
   or by just having the branch relationships listed in your .git/remotes/ 
   file or .git/config file.

both are actually very natural things to do.

What is probably _not_ that natural is to do the explicit branch 
specifier, ie

	git fetch somerepo remotebranch:localbranch

which obviously works, but you wouldn't want to actually do this very 
often. Either you do something once (and use FETCH_HEAD, which is actually 
nicer than a real branch in some respects: it also tells you were you 
fetched _from_, and it can contain data on merging from _multiple_ 
branches), or you set up a "real translation" in your configuration files.

So I would say that the natural thing to do is:

 - "git pull somerepo"

   This will _also_ fetch all the branches you've said you want to track, 
   of course.

 - "git fetch somerepo somebranch"

   Look at FETCH_HEAD, and be happy

 - "git fetch somerepo"

   This is kind of strange, but it can be useful if you are basically just 
   mirroring another repo, and want to fetch all the branches you've said 
   you want to track, but don't actually want to check them out.

while the "complicated" scenario like the following is something you 
should generally _avoid_, because it's just confusing and complex:

 - "git fetch somerepo branch1:mybranch1 branch2:mybranch2"

   This works, and I'm sure it's useful, and I've even used it (usually 
   with just one branch, though), but let's face it - it's too damn 
   complicated to be anything you want to do _normally_.

So git is definitely powerful, but I think some people have looked at the 
_complicated_ cases more than the simple cases (ie maybe people have 
looked too much at that last case, not realizing that there really isn't 
much reason to use it - and FETCH_HEAD is one big reason why you seldom 
need the complicated format).


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 23:00                           ` Johannes Schindelin
@ 2006-11-16 23:22                             ` Linus Torvalds
  2006-11-17  0:05                               ` Han-Wen Nienhuys
  0 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 23:22 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, Junio C Hamano, git



On Fri, 17 Nov 2006, Johannes Schindelin wrote:
> 
> Never ever underestimate pet peeves. If we give many people an obvious 
> reason (however trivial and bike-shed-coloured) to complain, they will 
> complain.

I do actually think that this discussion has been informative, partly 
because I never even realized that some people would ever think to do 
"init-db" + "pull". 

Making things like that work is easy enough, it's just that I never saw 
any point until people complained. And when they complained, the initial 
complaint wasn't actually obvious. Only when Han-Wen actually gave 
something that didn't work, was it clear that the real issue wasn't so 
much _naming_, as just expectations about the _work_flow_.

> And hopefully you also agree that enhancing the syntax of git-merge to 
> grok "git-merge [-m message] <branch>" and "git-merge [-m message] 
> <url-or-remote> <branch>" would be a lovely thing, luring even more 
> people into using git.

I definitely think we can make "git merge" have a more pleasant syntax. 
I'm just still not sure that people should actually use it ;)

My real point was/is that usually it's really not the "naming details" 
that people _really_ have problems with. The real problems tend to be in 
learning a new workflow.

We can make some of those workflows easier, but I would heartily recommend 
that people not worry about naming of "pull" vs "fetch", because that's 
almost certainly not really the issue. Instead, if you have a problem, 
rather than concentrating on the names of the programs, say:

 - what do you want to get done.

   Most likely it's _trivial_ to do with git, it's just that somebody used 
   the wrong approach, and then it didn't work at all.

 - give actual examples of a workflow that didn't work or was complex.

   (again, the "init-db" + "pull" example). 

   And yes, in many cases, it might well be a case of "sure, we can make 
   that _other_ workflow work too". But somebody like me, who has used git 
   for a year and a half, and used BK before it, probably simply uses a 
   different workflow than somebody who comes from CVS. 

For example, I suspect that your gripe with "git fetch" was just from 
using it in a really awkward manner. Maybe we could make your workflow 
work with git too, but maybe it really already (and always) did, you just 
used a particular tool in a way that made the use be really really 
painful.

Sometimes it's just a question of "ok, use it like _this_, and now it's 
actually really simple". Other times it's "ok, I didn't even realize that 
you wanted to use it like _that_, and yeah, that's incredibly 
inconvenient, and we can change it".

I just got involved in this discussion because I thought people were 
talking about all the wrong things. Command naming really can't be _that_ 
big of a deal. I really don't believe that we should have some people use 
"gh" instead of "git" just because they think "pull" should mean not to 
merge or something.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface  warts)
  2006-11-16 18:21                                     ` Linus Torvalds
                                                         ` (2 preceding siblings ...)
  2006-11-16 22:21                                       ` multi-project repos (was Re: Cleaning up git user-interface warts) Johannes Schindelin
@ 2006-11-16 23:32                                       ` Han-Wen Nienhuys
  2006-11-17 12:53                                         ` Jakub Narebski
  3 siblings, 1 reply; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 23:32 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Junio C Hamano, git


Linus Torvalds escreveu:
>> You're misunderstanding me: the multi-repo is at git.sv.gnu.org is the
>> remote one. The example I gave was about locally creating a single
>> project repo from a remote multiproject repo. 
> 
> Ahh.
> 
> Ok, try the patch I just sent out, and see if it works for you. It 
> _should_ allow you to do exactly that

I'm leaving for a short holiday tomorrow, but will do when I come back.

>> From UI perspective it would be nice if this could also be done with clone,
>>
>>   git clone . ssh+git://....
> 
> The creation of a new archive tends to need special rights (with _real_ 
> ssh access and a shell you could do it, but "ssh+git" really means "git 
> protocol over a connection that was opened with ssh, but doesn't 
> necessarily have a real shell at the other end").

What happens on savannah is that the sysadmins set up an empty GIT
repo with access, and leave it to you to push the stuff.  Of course,
if the initial import gets packed automatically, that's also ok.

> So I think the above syntax is actually not a good one, because it cannot 
> work in the general case. It's much better to get used to setting up a 
> repo first, and then pushing into it, and just accepting that it's a 
> two-phase thing.

Perhaps ; from a UI viewpoint, it would be nice though, even if it
were aliased to a simple push. (Darcs has a get command analogous to
git-clone, but also a put command to which git lacks the equivalent).

>> * why are objects downloaded twice?  If I do
>>
>>   git --bare fetch git://git.sv.gnu.org/lilypond.git web/master
>>
>> it downloads stuff, but I don't get a branch.
> [..] 
>> If I then do 
>>
>>   git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master
>>
>> it downloads the same stuff again. 
> 
> Right. So you can either
> [..]
> See?

No, I don't understand. In the fetch all the objects with their SHA1s
were already downloaded. I'd expect that the fetch with a refspec
would simply write a HEAD and a refs/heads/master, and notice that all
the actual data was already downloaded, and doesn't download it again. 


-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-16 22:49                                         ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
  2006-11-16 23:08                                           ` Linus Torvalds
@ 2006-11-16 23:36                                           ` Johannes Schindelin
  2006-11-17  0:49                                             ` Linus Torvalds
  2006-11-16 23:40                                           ` Han-Wen Nienhuys
  2 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-16 23:36 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git

Hi,

On Thu, 16 Nov 2006, Linus Torvalds wrote:

> On Thu, 16 Nov 2006, Johannes Schindelin wrote:
> >
> > - a terrible UI.
> 
> Why? We _do_ have the temporary branch. It's called FETCH_HEAD.

It is a terrible UI, because it was not that obvious to me. And I consider 
myself not a git newbie.

Besides, it is not really a temporary branch. If it was, the pull would 
_not_ download all these objects again, would it?

> > _Also_, git-pull not storing the fetched branches at least temporarily 
> > often annoyed me: the pull did not work, and the SHA1 was so far away I 
> > could not even scroll to it.
> 
> Again, why didn't you use FETCH_HEAD?

Because I am a Jar-HEAD?

> If the user doesn't give us a head to write to, we clearly MUST NOT write 
> to any long-term branch. That would be a _horrible_ mistake. 

I was _not_ suggesting a long-term branch. Just a way to do-what-i-want 
and not waste bandwidth.

> And your "solution" is obviously totally unusable. git ABSOLUTELY MUST NOT 
> overwrite any existing branches unless explicitly told to do so by the 
> user.

Guess three times why I did not post the patches.

But the real problem is not necessarily the behaviour; it is the obscure 
fashion of the behaviour. You may not understand that problem, because you 
were there from the beginning. You saw the big-bang and how all the 
quarks formed all of a sudden, and how matter and eventually planets 
and suns came into being.

But others (me included) were not there. Or they did not really watch. And 
now they see all these creatures, and plants, and bacteria, and they do 
not understand how these are all connected, because of that. And now they 
think "wow that must have been some intelligent design, and really a 
miracle, and I cannot understand how it works." But that is not true 
(the latter part of course).

There is something to be said about the simplicity of Mercurial. It's 
inner workings may suck, but people get easily attracted by it.

I do not claim we should imitate Mercurial, or even hide the index (even 
if I sometimes wonder if the index is not just a clever way to accelerate 
commits, and nothing more).

> So I really don't see your point. 
> 
> A lot of the complaints seem to not be about the interfaces, but about 
> people not _understanding_ and knowing what the interfaces do.

But the interfaces should be usable interfaces! They should _explain_ what 
they do. Other software does so, it can't be _that_ hard.

> 	git merge "$(git fmt-merge-msg < .git/FETCH_HEAD)" HEAD FETCH_HEAD

I find that quite easy to understand. Why? Because I happen to _know_ the 
syntax of -merge and -fmt-merge-msg. For similar reasons I _understand_ 
why -pull behaves like it does. But others don't; they will shudder and 
then run.

Maybe it is not important that -pull fetches all objects all over again. 
But it _is_ important to make things like merging branches (local or 
remote) trivial. It _is_ important to make the user experience be fun.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface  warts)
  2006-11-16 22:49                                         ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
  2006-11-16 23:08                                           ` Linus Torvalds
  2006-11-16 23:36                                           ` Johannes Schindelin
@ 2006-11-16 23:40                                           ` Han-Wen Nienhuys
  2 siblings, 0 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 23:40 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Junio C Hamano, git

Linus Torvalds escreveu:
> A lot of the complaints seem to not be about the interfaces, but about 
> people not _understanding_ and knowing what the interfaces do. If you were 

From the point of view of a user, there is not really a difference
between the two.  As a user, you form a mental model of how things
work by looking at the interface. If the interface is bad, the user
creates a faulty model in his head, and starts doing things that
are perfectly logical in the faulty model, but stupid and silly when
you consider the actual internals.

A nice book about this is "The Design of Everyday Things" by Donald
Norman.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 23:22                             ` Linus Torvalds
@ 2006-11-17  0:05                               ` Han-Wen Nienhuys
  2006-11-17  0:13                                 ` Junio C Hamano
                                                   ` (3 more replies)
  0 siblings, 4 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-17  0:05 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, git



Linus Torvalds escreveu:
> My real point was/is that usually it's really not the "naming details" 
> that people _really_ have problems with. The real problems tend to be in 
> learning a new workflow.

I agree that discussions on naming may cloud the issue, but "learning
the workflow" implies that people should adapt to the limitations of
their tools.  That's only a viable stance when the tools are finished
and completely perfect.

Until that time, it would be good goal to remove all idiosyncrasies,
all gratuitious asymetries and needless limitations in the commands of
git, eg.

 - clone but not a put-clone,

 - pull = merge + fetch, but no command for merge + throw

 - clone for getting all branches of a repo, but no command for
   updating all branches of a repo.  

Of course, when all warts are fixed, backward compatibility will force
us to choose some new names. At that point, a discussion on naming is
in place.


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16  5:12           ` Petr Baudis
  2006-11-16 10:45             ` Junio C Hamano
  2006-11-16 21:49             ` Junio C Hamano
@ 2006-11-17  0:11             ` Han-Wen Nienhuys
  2 siblings, 0 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-17  0:11 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre

Petr Baudis escreveu:
> (vi) Coding issues. This is probably very subjective, but a blocker for
> me. I have no issues about C here, but about the shell part of Git.
> Well, how to say it... It's just fundamentally incompatible with me. I

(on a tangent)

I concur, but probably in a different way.

some 10 years ago I vowed never to write perl code again, and some 5
years ago, I made the same pledge for shell scripts, because I spent
inordinate amounts of time debugging them.

When I see the GIT shell scripts, my hands start to itch to make a
nice object oriented Python wrapper for it.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  0:05                               ` Han-Wen Nienhuys
@ 2006-11-17  0:13                                 ` Junio C Hamano
  2006-11-17  0:27                                   ` Han-Wen Nienhuys
                                                     ` (2 more replies)
  2006-11-17  0:39                                 ` Linus Torvalds
                                                   ` (2 subsequent siblings)
  3 siblings, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17  0:13 UTC (permalink / raw)
  To: hanwen; +Cc: git

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

>  - clone but not a put-clone,

What's put-clone?  Care to explain?

>  - pull = merge + fetch, but no command for merge + throw

What's merge+throw?  Care to explain?

>  - clone for getting all branches of a repo, but no command for
>    updating all branches of a repo.  

This one I can understand, but how would you propose to "update
all branches", in other words what's your design for mapping
remote branch names to local branch namespaces?

It would be nice if the design does not straightjacket different
repository layouts different people seem to like, but I think it
would be Ok to limit ourselves only to support the straight
one-to-one mapping and support only separate-remote layout.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  0:13                                 ` Junio C Hamano
@ 2006-11-17  0:27                                   ` Han-Wen Nienhuys
  2006-11-17  0:35                                     ` Petr Baudis
  2006-11-17  0:37                                   ` Carl Worth
  2006-11-17  1:25                                   ` Carl Worth
  2 siblings, 1 reply; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-17  0:27 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano escreveu:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
>>  - clone but not a put-clone,
> 
> What's put-clone?  Care to explain?

put clone would be the putative inverse of clone, ie. make a clone of
a local repository on a remote server.

>>  - pull = merge + fetch, but no command for merge + throw
> 
> What's merge+throw?  Care to explain?

throw is the hypothetical opposite of fetch. I agree that this is
academical, because it's logical to only allow fast-forwards for
sending revisions.

>>  - clone for getting all branches of a repo, but no command for
>>    updating all branches of a repo.  
> 
> This one I can understand, but how would you propose to "update
> all branches", in other words what's your design for mapping
> remote branch names to local branch namespaces?
> 
> It would be nice if the design does not straightjacket different
> repository layouts different people seem to like, but I think it
> would be Ok to limit ourselves only to support the straight
> one-to-one mapping and support only separate-remote layout.

I think the whole clone design is a bit broken, in that the "master"
branch gets renamed or copied to "origin", but all of the other
branches remain unchanged in their names.

It's more logical for clone to either

 * leave all names unchanged

 * put all remote branches into a subdirectory.  This would also make
   it easier to track branches from multiple servers.

   At present,  I have in my build-daemon the following branches,

	cvs-head-repo.or.cz-lilypond.git
	hanwen-repo.or.cz-lilypond.git
	hwn-jcn-repo.or.cz-lilypond.git
	lilypond_1_0-repo.or.cz-lilypond.git
	lilypond_1_2-repo.or.cz-lilypond.git
	lilypond_1_4-repo.or.cz-lilypond.git
	lilypond_1_6-repo.or.cz-lilypond.git
	lilypond_1_8-repo.or.cz-lilypond.git
	lilypond_2_0-repo.or.cz-lilypond.git
	lilypond_2_2-repo.or.cz-lilypond.git
	lilypond_2_3_2b-repo.or.cz-lilypond.git
	lilypond_2_3_5b-repo.or.cz-lilypond.git
	lilypond_2_4-repo.or.cz-lilypond.git
	lilypond_2_6-repo.or.cz-lilypond.git
	lilypond_2_8-repo.or.cz-lilypond.git
	master-git.sv.gnu.org-lilypond.git
	master-hanwen
	master-repo.or.cz-lilypond.git
	origin-repo.or.cz-lilypond.git
	stable
	stable-2.10
	stable--2.10-git.sv.gnu.org-lilypond.git

  It would solve lots of problems for me if cloning and fetching would
  put branches into a subdirectory, ie.

    git clone git://repo.or.cz/lilypond.git

  leads to branches

    repo.or.cz/lilypond_2_8
    repo.or.cz/lilypond_2_6
    repo.or.cz/lilypond_2_4
    repo.or.cz/master
     (etc..)

	
-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos
  2006-11-16 22:44                                         ` multi-project repos Junio C Hamano
@ 2006-11-17  0:29                                           ` Johannes Schindelin
  0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-17  0:29 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Thu, 16 Nov 2006, Junio C Hamano wrote:

> I think the earlier write-up by Linus on magic HEADs would help 
> documenting FETCH_HEAD better.

I am not sure that documenting FETCH_HEAD better would help. As Han-Wen 
pointed out (and some colleagues of mine who would never subscribe to a 
mailing list), people do not read the manual, but rather try to wrap their 
heads around the inner workings from the interface. And FETCH_HEAD just 
does not meet _any_ expectation a sane (read: untainted) user might have.

While I'm at it: the problem I pointed out with -pull may annoy just me.

But there is another problem with "git fetch": a common work flow is 
tracking other peoples branches. And since git makes it so easy to 
have multiple branches, chances are that you track more than one 
branch per remote repository.

Now, an old gripe of mine was the lack of "git fetch --all". I wrote a 
script for that (Linus would be proud of me!), which just does "git 
ls-remote" and constructs a command line for "git fetch" from that.

But even if you agree with the common story that you should specify the 
branches you want to track: it is hard!

If I were new to git, after reading some tutorials I would _expect_ "git 
fetch" to be the tool to track branches. (I posted a patch to at least be 
able to store the current "git fetch" command line under a nick IIRC). But 
it does not.

(Of course, after reading several documentation, as a new user I would 
eventually find that I should edit .git/remotes/<nick>, or even 
edit/-repo-config the remotes information in the config, but I would fully 
expect a new user to give up before reaching that stage.)

But maybe I got it all wrong and this is not the common expectation...

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  0:27                                   ` Han-Wen Nienhuys
@ 2006-11-17  0:35                                     ` Petr Baudis
  0 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-17  0:35 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git

On Fri, Nov 17, 2006 at 01:27:53AM CET, Han-Wen Nienhuys wrote:
> put clone would be the putative inverse of clone, ie. make a clone of
> a local repository on a remote server.

So effectively to tell git push not to unpack on the remote side, and to
push all branches and relevant tags.

..snip..
> It's more logical for clone to either
> 
>  * leave all names unchanged
> 
>  * put all remote branches into a subdirectory.  This would also make
>    it easier to track branches from multiple servers.
> 
>    At present,  I have in my build-daemon the following branches,
> 
> 	cvs-head-repo.or.cz-lilypond.git
> 	hanwen-repo.or.cz-lilypond.git
> 	hwn-jcn-repo.or.cz-lilypond.git
> 	lilypond_1_0-repo.or.cz-lilypond.git
> 	lilypond_1_2-repo.or.cz-lilypond.git
> 	lilypond_1_4-repo.or.cz-lilypond.git
> 	lilypond_1_6-repo.or.cz-lilypond.git
> 	lilypond_1_8-repo.or.cz-lilypond.git
> 	lilypond_2_0-repo.or.cz-lilypond.git
> 	lilypond_2_2-repo.or.cz-lilypond.git
> 	lilypond_2_3_2b-repo.or.cz-lilypond.git
> 	lilypond_2_3_5b-repo.or.cz-lilypond.git
> 	lilypond_2_4-repo.or.cz-lilypond.git
> 	lilypond_2_6-repo.or.cz-lilypond.git
> 	lilypond_2_8-repo.or.cz-lilypond.git
> 	master-git.sv.gnu.org-lilypond.git
> 	master-hanwen
> 	master-repo.or.cz-lilypond.git
> 	origin-repo.or.cz-lilypond.git
> 	stable
> 	stable-2.10
> 	stable--2.10-git.sv.gnu.org-lilypond.git
> 
>   It would solve lots of problems for me if cloning and fetching would
>   put branches into a subdirectory, ie.
> 
>     git clone git://repo.or.cz/lilypond.git
> 
>   leads to branches
> 
>     repo.or.cz/lilypond_2_8
>     repo.or.cz/lilypond_2_6
>     repo.or.cz/lilypond_2_4
>     repo.or.cz/master
>      (etc..)

That's basically exactly what git clone --use-separate-remote should do.
Now only if it would become the default... :-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  0:13                                 ` Junio C Hamano
  2006-11-17  0:27                                   ` Han-Wen Nienhuys
@ 2006-11-17  0:37                                   ` Carl Worth
  2006-11-17  1:25                                   ` Carl Worth
  2 siblings, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-17  0:37 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: hanwen, git

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Thu, 16 Nov 2006 16:13:44 -0800, Junio C Hamano wrote:
> >  - clone for getting all branches of a repo, but no command for
> >    updating all branches of a repo.

I want this one as well.

> This one I can understand, but how would you propose to "update
> all branches", in other words what's your design for mapping
> remote branch names to local branch namespaces?

As long as its consistent with "clone" I'll be happy, (I think as part
of a separate topic we need to fix the mappings in clone, see
--use-separate-remotes as default and related).

The current case is really annoying where I have to throw use clone
into a new repository just to get everything, rather than just being
able to fetch everything into the repository I already have.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  0:05                               ` Han-Wen Nienhuys
  2006-11-17  0:13                                 ` Junio C Hamano
@ 2006-11-17  0:39                                 ` Linus Torvalds
  2006-11-17  0:52                                   ` Han-Wen Nienhuys
  2006-11-17  1:34                                 ` Michael K. Edwards
  2006-11-23  2:52                                 ` Horst H. von Brand
  3 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-17  0:39 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git



On Fri, 17 Nov 2006, Han-Wen Nienhuys wrote:
> 
> Until that time, it would be good goal to remove all idiosyncrasies,
> all gratuitious asymetries and needless limitations in the commands of
> git, eg.

Well, a lot of the assymmetries aren't actually gratuitous at all.

>  - clone but not a put-clone,

As mentioned, in order to "put-clone", you generally have to "create" 
first, so the "put-clone" really makes no sense.

The _true_ reverse is really your

 - "git init-db" on both sides

 - "git pull" (your workflow ;) on receiving

 - "git push" on sending.

The fact that we can do "git clone" on the _receiving_ side is an 
assymmetry, but it's not gratutous: when receiving we don't need any extra 
permissions or setup to create a new archive. In contrast, when sending, 
you do have to have that "get permission to create new archive" phase.

>  - pull = merge + fetch, but no command for merge + throw

Again, this is not gratuitous, and the reason is very similar: when you 
pull, you're pulling into something that _you_ control and _you_ have 
access to, namely your working directory. In order to merge you have to 
have the ability to fix up conflicts (whether automatically or manually), 
and this is something that you _fundamentally_ can only do when you own 
the repo space.

Again, when you do "push", the reason you can't merge is not a "gratuitous 
assymmetry", but a _fundamental_ assymmetry: by definition, you're pushing 
to a _remote_ thing, and as such you can't merge, because you can't fix up 
any merge problems.

See?

In many ways, if you want _symmetry_, you need to make sure that the 
_cases_ are symmetrical. If you have ssh shell access, you can often do 
that, and the "reverse" of a "git pull" is actually just another "git 
pull" from the other side:

	ssh other-side "cd repo ; git pull back"

Now they really _are_ symmetrical: "git pull" is really in many ways ITS 
OWN reverse operation. 

But "push" and "pull" _fundamentally_ aren't symmetric operations, and you 
simply cannot possibly make them symmetric. Any system that tries would be 
absolutely horrible to use, exactly because it would be either:

 - making local/remote operations totally equivalent

   This sounds like a "good" thing, but from a real user perspective it's 
   actually horribly horribly bad. Knowing the difference between local 
   and remote is what allows a lot of performance optimizations, and a lot 
   of security. Your local repo is _yours_, and nobody can take that away 
   from you, and that's a really fundamental reason for why the symmetry 
   cannot exist, and why local/remote operations MUST NOT be something 
   that you can mix without thinking about them,

 - limit local operations in a way to make them effectively unusable and 
   unscriptable.

   You'd basically have to do everything even _locally_ through some 
   server interface, and you'd not be allowed to ever touch your local 
   checked-out repository directly. Again: local repositories really _are_ 
   special, because you can touch the checked out copy. If you try to 
   suppress that, you're screwed.

>  - clone for getting all branches of a repo, but no command for
>    updating all branches of a repo.  

As in sending? Sure there is: use "git push --all". It will push out every 
branch (and tag) you have. Add "--force" if you want to make sure that it 
also pushed out branches even if the result isn't a strict superset (of 
course, the receiving end may actually end up refusing to take it, there's 
a option for the receiver to say "I will refuse any update that isn't a 
strict superset of what I had").

If you mean as in "receiving new branches", then yeah, you do have to 
script it, with some fairly trivial "git ls-remote" to make sure you get 
the new remotes.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-16 23:36                                           ` Johannes Schindelin
@ 2006-11-17  0:49                                             ` Linus Torvalds
  2006-11-17  1:08                                               ` Carl Worth
  2006-11-17  1:22                                               ` Johannes Schindelin
  0 siblings, 2 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-17  0:49 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, Junio C Hamano, git



On Fri, 17 Nov 2006, Johannes Schindelin wrote:
> > Why? We _do_ have the temporary branch. It's called FETCH_HEAD.
> 
> It is a terrible UI, because it was not that obvious to me. And I consider 
> myself not a git newbie.

Heh. The "temporary branches" are actually the _original_ branches as far 
as git is concerned. The long-term branches only came later.

So in many ways, HEAD, FETCH_HEAD, MERGE_HEAD and ORIG_HEAD are more 
fundamental than any long-term branch has ever been, and maybe they should 
be taught first as such.

So you're newbie enough that you've only seen those new-fangled "real" 
branches.

When I was young, we had to walk to school up-hill in three feet of snow 
every day. And we _liked_ our FETCH_HEAD's.

> Besides, it is not really a temporary branch. If it was, the pull would 
> _not_ download all these objects again, would it?

Well, exactly because they are temporary, we can't actually trust the 
objects they point to. They have no "real" long-term life, so no, I'm 
afraid that we always will have to re-fetch the objects, because fetching 
them is the only way to know that we still have them. 

That said, we could certainly _make_ them be honored by things like "git 
prune" and friends. But yes, they really _are_ temporary branches right 
now, and part of the meaning of that "temporary" is exactly the fact that 
git fetch will not trust that you still have the objects. 

For example, if you used one of the old-fashioned commit walkers, maybe we 
got the initial commit, but we may not have gotten the whole _chain_. See?

Temporary branch indeed.

> > Again, why didn't you use FETCH_HEAD?
> 
> Because I am a Jar-HEAD?

Well, we clearly should document them better. Anybody?


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  0:39                                 ` Linus Torvalds
@ 2006-11-17  0:52                                   ` Han-Wen Nienhuys
  0 siblings, 0 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-17  0:52 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Junio C Hamano, git

Linus Torvalds escreveu:
> The fact that we can do "git clone" on the _receiving_ side is an 
> assymmetry, but it's not gratutous: when receiving we don't need any extra 
> permissions or setup to create a new archive. In contrast, when sending, 
> you do have to have that "get permission to create new archive" phase.
> 
>>  - pull = merge + fetch, but no command for merge + throw
> 
> Again, this is not gratuitous, and the reason is very similar: when you 
> pull, you're pulling into something that _you_ control and _you_ have 

>But "push" and "pull" _fundamentally_ aren't symmetric operations, and you 
>simply cannot possibly make them symmetric. 

Point taken;  thank you. 

In that case, we're full circle with the command naming issues. Push
and pull are fundamentally asymmetric operations, but then a
consistent UI would dictate that they wouldn't be named symmetrically,
as they are now.


-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-17  0:49                                             ` Linus Torvalds
@ 2006-11-17  1:08                                               ` Carl Worth
  2006-11-17  1:22                                               ` Johannes Schindelin
  1 sibling, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-17  1:08 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Johannes Schindelin, Han-Wen Nienhuys, Junio C Hamano, git

[-- Attachment #1: Type: text/plain, Size: 2517 bytes --]

On Thu, 16 Nov 2006 16:49:29 -0800 (PST), Linus Torvalds wrote:
> So in many ways, HEAD, FETCH_HEAD, MERGE_HEAD and ORIG_HEAD are more
> fundamental than any long-term branch has ever been, and maybe they should
> be taught first as such.

Older in git's history as it developed is not a good match for more
fundamental in the concepts that git makes available today.

> > > Again, why didn't you use FETCH_HEAD?
> >
> > Because I am a Jar-HEAD?
>
> Well, we clearly should document them better. Anybody?

I for one am totally unsatisfied with this approach.

Here's an operations I'd like to be able to do:

	Given a (URL, branch) pair I'd like I'd like to be able to
	investigate that code, (say with the fancy new "read-only
	branch" concept we've been talking about).

What are my options for this operation? What might a new user's
reaction to them be?

a) git fetch URL branch
   git checkout FETCH_HEAD

   This is really ugly. A name like "FETCH_HEAD" is something a user
   should really never have to type. It's hideously hard to type and
   has no natural discoverability. Yuck, yuck, yuck.

b) vi .git/remotes/something
   git fetch something
   git checkout branch

   Also yuck. I hope it's obvious that having to edit a configuration
   for this simple operation is a non-starter.

c) git fetch URL branch:local-branch
   git checkout local-branch

   We're getting close to the desired functionality now, but the UI
   makes users cringe? "What's that : for?" Why do I need another
   name?" etc. Linus, you yourself said this is a form that users
   should generally avoid.

d) git fetch URL branch:branch
   git checkout branch

   One step closer. But there's still that goofy extra ':' and a
   doubled name in the first command. "Why is that there? Git sure is
   weird...".

What I think this operation should look like is:

	git fetch URL branch
	git checkout branch

And the fetch should just complain if there's a name clash. Or better,
the fetch should tuck the fetched branch into its own URL-specific
namespace and then the checkout command can kindly prompt if there is
any ambiguity:

	Which "branch" do you want?
		local/branch
		remote-url/branch

or whatever.

See? That's what reasonable UI should look like.

Please feel free to keep using vestiges like FETCH_HEAD as much as you
like, but please don't recommend documenting them better as a solution
for UI warts in git. (If you would only look at these warts closer,
you'd see they have some lovely locks of hair on them.)

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-17  0:49                                             ` Linus Torvalds
  2006-11-17  1:08                                               ` Carl Worth
@ 2006-11-17  1:22                                               ` Johannes Schindelin
  2006-11-17  1:52                                                 ` Petr Baudis
  1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-17  1:22 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git

Hi,

On Thu, 16 Nov 2006, Linus Torvalds wrote:

> On Fri, 17 Nov 2006, Johannes Schindelin wrote:
> 
> > Besides, it is not really a temporary branch. If it was, the pull would 
> > _not_ download all these objects again, would it?
> 
> Well, exactly because they are temporary, we can't actually trust the 
> objects they point to.

Nonono.

We made _sure_ that FETCH_HEAD is only written once _all_ the objects were 
received. So, actually, we _can_, and we _should_ trust the objects they 
point to!

Or did I miss something?

> For example, if you used one of the old-fashioned commit walkers, maybe we 
> got the initial commit, but we may not have gotten the whole _chain_. See?

Huh? I am quite certain that FETCH_HEAD is not updated in that case. If it 
is, that's a bug.

Ciao,

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  0:13                                 ` Junio C Hamano
  2006-11-17  0:27                                   ` Han-Wen Nienhuys
  2006-11-17  0:37                                   ` Carl Worth
@ 2006-11-17  1:25                                   ` Carl Worth
  2 siblings, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-17  1:25 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: hanwen, git

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

On Thu, 16 Nov 2006 16:13:44 -0800, Junio C Hamano wrote:
> This one I can understand, but how would you propose to "update
> all branches", in other words what's your design for mapping
> remote branch names to local branch namespaces?

What I want here is a command "git update" that fetches and
fast-forwards the all branches which are designated as "tracking" a
branch in some known remote repository. And git-clone would setup all
branches appropriately so that they would be updated by git-update.

Additionally, it would be nice if git-update would also create new
tracking branches for all remotes repositories that had been
designated as being tracked, (and git-clone would do this as well).

There should also be a mechanism to easily create new tracking support
for specific branches or all branches of a repository, (could be "git
fetch URL branch" or "git fetch --all URL", for example).

With this kind of setup, I would use "git update" regularly, and only
ever merge locally. And by definition merging with any local tracking
branch would have just as much information available as "pull URL
branch" so the message would be the same.

I've been using git for 10-11 months, so I think I understand the
models fairly well, and I'd be really happy with a setup like that. I
also have talked with a fair number of (non-git-using) users who think
git is confusing, but I think would find the above scenario just fine.

In this scenario, git pull would still work just fine, but it would
also be much easy to teach a workflow that didn't use pull at all, so
if there's any git-pull confusion that's an actual problem, it could
be avoided.

Junio, what do you think of a setup something like that? I really
don't want to create a command other than "git" to implement it.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  0:05                               ` Han-Wen Nienhuys
  2006-11-17  0:13                                 ` Junio C Hamano
  2006-11-17  0:39                                 ` Linus Torvalds
@ 2006-11-17  1:34                                 ` Michael K. Edwards
  2006-11-17  6:42                                   ` Michael K. Edwards
  2006-11-23  2:52                                 ` Horst H. von Brand
  3 siblings, 1 reply; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-17  1:34 UTC (permalink / raw)
  To: git

I think there's a fundamental assumption built into the design of git
that most programmers accustomed to a corporate environment don't
understand.  Namely, that each programmer owns his or her entire
"repository", and can do whatever he or she darn well pleases with it
at any time.  Go ahead and create hundreds of transient branches as
part of a scripted "merge complexity metric" calculation.  Try three
different refactoring strategies on different branches, abandon two of
them, and prune them months later.  And generally use the power of the
SCM to juggle a lot of things at once, because there's no sysadmin
gatekeeper stopping you, and the thing is designed and coded scalably
so it doesn't grind to a halt as soon as everyone has dozens of
private branches.

Even if you do find a way to push git in a direction that it doesn't
scale, it's no one's problem but your own -- people who pull from you
are pulling the _content_ on the branches they care about, not the
structure of your repository.

On 11/16/06, Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
> I agree that discussions on naming may cloud the issue, but "learning
> the workflow" implies that people should adapt to the limitations of
> their tools.  That's only a viable stance when the tools are finished
> and completely perfect.
>
> Until that time, it would be good goal to remove all idiosyncrasies,
> all gratuitious asymetries and needless limitations in the commands of
> git, eg.

One person's gratuitous asymmetry is another's minimalism.  (If the
symmetric thing doesn't make any sense or can't be implemented
scalably, leave it out.)  It is more important that git continue to
work than that it appear symmetric without reference to its function.

>  - clone but not a put-clone,

What possible use would that be?  git is not rsync.

>  - pull = merge + fetch, but no command for merge + throw

pull = fetch + merge.  It is (almost?) always followed by a judgment
call based on the merge results.  merge + throw doesn't make any sense
in terms of the job at hand, which is facilitating human judgments
about whether to accept someone else's work into one's working tree.

>  - clone for getting all branches of a repo, but no command for
>    updating all branches of a repo.

clone is shorthand for the steps involved in setting up a new
repository with content similar to an existing one.  There isn't any
merge involved, and no scope for human judgment, so it's simplest to
clone the whole state of the remote repository (including tags and
branches) and let the user blow away any branches he doesn't need.
But once the clone is done, all of those branches are _truly_ _local_
-- they don't retain any reference to the remote branches, and you can
commit to all of them.  The only entry placed in .git/remotes is the
"origin" of the new clone, which is the "master" of the remote
repository.  That's for the user's convenience, and is about the only
thing in the new clone that _isn't_ a copy of something in the remote
tree.

So the "update all" process wouldn't look anything like a clone, it
would be a fetch and replay of each remote branch onto the
corresponding local branch.  You and Carl seem to want "git clone" not
only to copy the heads of the remote branches but to populate
.git/remotes with trackers for all of those branches, and then to
start each "git update" by polling all of the remote repositories to
see if branches have been created or deleted, then pull every branch
in sight.  What do you do when "upstream" creates a branch with the
same name as a local branch you have created?  How do you deal with
branch points that don't exist in your repository because you touched
one of the "tracker" branches between pulls?

In short, if you want a local, read-only tracker for a whole remote
repository instead of a branch that's actually published to you (and
maintained accordingly), you might consider s/git/rsync/.

Cheers,

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 22:20               ` Petr Baudis
@ 2006-11-17  1:49                 ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17  1:49 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre

Petr Baudis <pasky@suse.cz> writes:

You already said this kind of details are subjective so I'd omit
the usual "I would think" and answer them without worrying about
a big style flamewar.  People, please be civil ;-).

> What about [ instead of test?

[ ] is not more readable.

> 	if foo; then
>
> instead of
>
> 	if foo
> 	then

Having "then" on the beginning of line is much more readable.

> Am I the only one who hates
>
> case "$log_given" in
> tt*)
>         die "Only one of -c/-C/-F can be used." ;;
> *tm*|*mt*)
>         die "Option -m cannot be combined with -c/-C/-F." ;;
> esac

This is much more readable without "case".  "abandon the old
rule that told us to avoid if when case would do" applies.
Although it is about multiple possibility switch (so a case can
be made that "case" is appropriate here), we should reduce the
use of "case" to cases like the outermost big "case" you find in
git-merge-one-file-script.

> It would be really great if Git would have something alike the Cogito's
> optparse infrastructure. I'm not sure if you can implement it in Bourne
> sh with reasonable performance, though...

getopt(1) is fine, unless somebody screams that it is not
available on his platform.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-17  1:22                                               ` Johannes Schindelin
@ 2006-11-17  1:52                                                 ` Petr Baudis
  2006-11-17  2:16                                                   ` Johannes Schindelin
  0 siblings, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-17  1:52 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Linus Torvalds, Han-Wen Nienhuys, Junio C Hamano, git

On Fri, Nov 17, 2006 at 02:22:35AM CET, Johannes Schindelin wrote:
> On Thu, 16 Nov 2006, Linus Torvalds wrote:
> > For example, if you used one of the old-fashioned commit walkers, maybe we 
> > got the initial commit, but we may not have gotten the whole _chain_. See?
> 
> Huh? I am quite certain that FETCH_HEAD is not updated in that case. If it 
> is, that's a bug.

It may be updated and then things may break _afterwards_. git-prune will
happily blow anything referenced by FETCH_HEAD, it's not considered by
the fsck-objects reachability analysis.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-17  1:52                                                 ` Petr Baudis
@ 2006-11-17  2:16                                                   ` Johannes Schindelin
  0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-17  2:16 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Linus Torvalds, Han-Wen Nienhuys, Junio C Hamano, git

Hi,

On Fri, 17 Nov 2006, Petr Baudis wrote:

> On Fri, Nov 17, 2006 at 02:22:35AM CET, Johannes Schindelin wrote:
> > On Thu, 16 Nov 2006, Linus Torvalds wrote:
> > > For example, if you used one of the old-fashioned commit walkers, maybe we 
> > > got the initial commit, but we may not have gotten the whole _chain_. See?
> > 
> > Huh? I am quite certain that FETCH_HEAD is not updated in that case. If it 
> > is, that's a bug.
> 
> It may be updated and then things may break _afterwards_. git-prune will
> happily blow anything referenced by FETCH_HEAD, it's not considered by
> the fsck-objects reachability analysis.

This actually underlines my point: FETCH_HEAD is no _real_ branch, not 
even a temporary one. If it was, git-prune would not lose the related 
objects.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  1:34                                 ` Michael K. Edwards
@ 2006-11-17  6:42                                   ` Michael K. Edwards
  2006-11-17  7:32                                     ` Junio C Hamano
  2006-11-17 12:25                                     ` Jakub Narebski
  0 siblings, 2 replies; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-17  6:42 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

On 11/16/06, Michael K. Edwards <medwards.linux@gmail.com> wrote
>   The only entry placed in .git/remotes is the
> "origin" of the new clone, which is the "master" of the remote
> repository.  That's for the user's convenience, and is about the only
> thing in the new clone that _isn't_ a copy of something in the remote
> tree.

Actually, this "origin" entry does contain "Pull:" lines for all of
the branches that were cloned, so that "git pull" fetches and merges
updates to all of these branches.  (If upstream is in the habit of
reverting things, you may need "git pull -f"; I just did that on the
git repo to handle a failure to fast-forward on the "pu" branch.)

Presumably "git branch -D" should inspect everything under
.git/remotes to see whether one or more Pull: lines need to be deleted
along with the branch.  Currently, it looks like "remotes" entries are
created only by "git clone" or by hand.  Junio, are there any plans to
manage the contents of "remotes" through the tool instead of by hand?

Cheers,

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  6:42                                   ` Michael K. Edwards
@ 2006-11-17  7:32                                     ` Junio C Hamano
  2006-11-18  1:24                                       ` Michael K. Edwards
  2006-11-17 12:25                                     ` Jakub Narebski
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17  7:32 UTC (permalink / raw)
  To: Michael K. Edwards; +Cc: git

"Michael K. Edwards" <medwards.linux@gmail.com> writes:

> Presumably "git branch -D" should inspect everything under
> .git/remotes to see whether one or more Pull: lines need to be
> deleted along with the branch.

I am not sure what you mean.  .git/remotes files do not describe
any relationship between local branches (and that is where one
of the problem raised in recent thread -- pull does not notice
on which branch you are on and change its behaviour depending on
it), so I do not think there is anything gained for "git branch
-D" by going through them.

> Currently, it looks like "remotes" entries are
> created only by "git clone" or by hand.  Junio, are there any plans to
> manage the contents of "remotes" through the tool instead of by hand?

I muttered something in a near-by thread

	Message-ID: <7vr6w78b4x.fsf@assigned-by-dhcp.cox.net>

I am reasonably sure a separate tool (what I tentatively called
"maint-remote" in the message) is necessary, because, while it
would be relatively easy to make "git fetch" and friends to add
new mappings in the default way under a new option, people with
different workflows would want differnt "default mappings", and
adding new mappings for _all_ remote branches is useful only for
people who work in one particular way (namely, the CVS-style
"the central distribution point is where everybody meet" model).

The tool, under "interactive" mode, would probably take one
parameter, the short name of a remote ($name), and would give
you a form to update its URL:, shows ls-remote output against
that repository and would let you:

 - update the URL: which would probably cause the ls-remote to
   be re-run;

 - remove existing mappings;

 - add mappings for a remote branch for which you do not have a
   corresponding tracking branch, with a straightforward default
   mapping:

   	refs/heads/$branch:refs/remotes/$name/$branch

But I haven't thought things through yet.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 18:23                                                 ` Carl Worth
@ 2006-11-17  8:41                                                   ` Junio C Hamano
  2006-11-17  9:18                                                     ` Carl Worth
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17  8:41 UTC (permalink / raw)
  To: Carl Worth; +Cc: Michael K. Edwards, git

Carl Worth <cworth@cworth.org> writes:

> On Thu, 16 Nov 2006 09:57:00 -0800, "Michael K. Edwards" wrote:
>> What do you want all of those branches for?  They haven't been
>> published to you (that's a human interaction that doesn't go through
>> git), so for all you know they're just upstream experiments, and doing
>> things with them is probably shooting yourself in the foot.
>
> The same "what do you want them all for" question could be asked of
> git-clone which also fetches all available branches. I really just
> want to be able to easily watch what's going on in multiple
> repositories.
>
> I want to be able to just say "git update" (or whatever) and then be
> able to list and browse and explore the stuff locally.
>...

I have no objection to this if it is done in a controlled way
that does not make life more difficult for people who work with
multiple remote repositories.

And I think "git fetch" is the tool for what you want if
enhanced properly; see Linus's message that explaind that we
already have that support in "manually configurable" form but
initializing and maintaining the configuration is currently all
manual and can be improved.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  8:41                                                   ` Junio C Hamano
@ 2006-11-17  9:18                                                     ` Carl Worth
  2006-11-17 10:11                                                       ` Johannes Schindelin
  2006-11-17 11:29                                                       ` Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-17  9:18 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Michael K. Edwards, git

[-- Attachment #1: Type: text/plain, Size: 4101 bytes --]

On Fri, 17 Nov 2006 00:41:33 -0800, Junio C Hamano wrote:
> I have no objection to this if it is done in a controlled way
> that does not make life more difficult for people who work with
> multiple remote repositories.

That's fine with me. Maybe I didn't explain this well before, but my
desire is exactly for this to work with multiple repositories.

Specifically, what we have in cairo is a "central" shared tree that
many people push to. But we only have two branches there, (one for
bug-fixes only for our stable releases, and one for ongoing
development of new features, and that only of stuff that's well
cooked).

So that tree looks and acts an awful lot like our cvs tree back in the
past. It's often very linear and often fairly boring to look at in gitk.

Meanwhile, all the really interesting stuff happens in personal
repositories where people have their own branches for stuff that is
still getting cooked. This is what's a lot more fun to watch, and
there's a lot more distributed back-and-forth that goes on here as
people collaborate on things. And it's all this kind of collaboration
that cvs never helped with at all, but git has been great.

So, what I want is both "git update" for the central tree. I said we
only have two branches, but that's really only two that are
active---the "stable" branch is actually a new branch after every
major release. It was 1.0 for a while, is 1.2 now, and will be 1.4
later. So I want "git update" to automatically pick those new branches
up as they get created.

Meanwhile, I also want to use "git update" to track everything that
people are working on in the more wild personal trees. So, yes, I do
want "git update" to be able to track lots of remote repositories in a
sane way.

What I have been doing up to this point is a little script I wrote
that does git-ls-remote on the repository I want to track and writes a
.git/remotes file to bring in all their branches. So if I want to see
what behdad is up to, I first refresh his .git/remotes file with my:

	cairo-git-setup-remotes behdad
then:
	git fetch behdad

And I end up with a bunch of branch names with "behdad-" prefixes that
I can explore or blow away if I'm no longer interested, (could have
used a "behdad/" prefix as well).

The first problem we ran into when doing that months ago was that I
don't want any tracking branches to come across this way. Or else I
end up with behdad-origin, he then gets cworth-behdad-origin, ad
nauseum. So we filtered "origin" out, but it will be nice to revisit
this if there's a sane distinction in git now to separate tracking
branches from heads.

> And I think "git fetch" is the tool for what you want if
> enhanced properly; see Linus's message that explaind that we
> already have that support in "manually configurable" form but
> initializing and maintaining the configuration is currently all
> manual and can be improved.

Yes, git-fetch is lovely, and it's the need for manual configuration
that's a problem, (and the mixing up of heads and remote tracking
branches that has been in git historically).

So, yes, I'll definitely look into improving this. I think the details
will involve:

1. Making clone do the --use-separate-remotes behavior by default

2. Taking advantage of that consistently for all branches instead of a
   special master:origin mapping in clone

3. Enhancing git-fetch (or other) to modify .git/remotes, (or was
   there a desire for some other branch-specific section in the config
   file?)

4. Making git-fetch handle the disappearance of a remote branch
   gracefully

5. Adding something like git-fetch --all to allow it to pick up all new
   branches

6. Adding a "git update" that does a fetch for all appropriately
   marked remotes.

On this last point, maybe we do something like:

	update=no|yes|all

in .git/remotes. Then git-clone would set this up with update=all for
origin so git-update would do a "fetch --all" on the origin
repository. Then step 3 above would have to provide for setting this
update option as appropriate.

Anyway, something along those lines perhaps. Any feedback?

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  9:18                                                     ` Carl Worth
@ 2006-11-17 10:11                                                       ` Johannes Schindelin
  2006-11-17 11:41                                                         ` Junio C Hamano
  2006-11-17 16:58                                                         ` Shawn Pearce
  2006-11-17 11:29                                                       ` Junio C Hamano
  1 sibling, 2 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-17 10:11 UTC (permalink / raw)
  To: Carl Worth; +Cc: Junio C Hamano, Michael K. Edwards, git

Hi,

On Fri, 17 Nov 2006, Carl Worth wrote:

> 1. Making clone do the --use-separate-remotes behavior by default

Fully agree.

> 2. Taking advantage of that consistently for all branches instead of a
>    special master:origin mapping in clone

Fully agree, too.

> 3. Enhancing git-fetch (or other) to modify .git/remotes, (or was
>    there a desire for some other branch-specific section in the config
>    file?)

I introduced the remote.<nick>.{url,fetch,push} entries into the config 
with the goal to enhance -fetch to remember the current command line with 
a setting. I was the only one to find that useful.

BTW I still would argue that it is better to write the remote information 
into the config, because you have a saner way to manipulate that from 
scripts than .git/remotes/<nick>.

> 4. Making git-fetch handle the disappearance of a remote branch
>    gracefully

I think a message like "This remote branch no longer exists. Maybe you 
want to use 'git branch -d <branch>' to remove it locally?" should 
suffice.

> 5. Adding something like git-fetch --all to allow it to pick up all new
>    branches

IIRC this idea was rejected, but I would find it useful. Especially with 
what Han-Wen said: you can store the branches you fetch with "git fetch 
--all <nick>" under .git/refs/remotes/<nick>/<branchname>.

> 6. Adding a "git update" that does a fetch for all appropriately
>    marked remotes.
> 
> On this last point, maybe we do something like:
> 
> 	update=no|yes|all
> 
> in .git/remotes. Then git-clone would set this up with update=all for
> origin so git-update would do a "fetch --all" on the origin
> repository. Then step 3 above would have to provide for setting this
> update option as appropriate.

First thought was: it is only useful if you want to track multiple 
repositories. But next thought: if you mark the correct remotes in every 
of your local repositories, you don't have to remember which nick your 
upstream has. Yeah, I like it. But maybe do it as "git fetch --update" to 
avoid more cluttering of the bindir?

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  9:18                                                     ` Carl Worth
  2006-11-17 10:11                                                       ` Johannes Schindelin
@ 2006-11-17 11:29                                                       ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 11:29 UTC (permalink / raw)
  To: Carl Worth; +Cc: Michael K. Edwards, git

Carl Worth <cworth@cworth.org> writes:

> What I have been doing up to this point is a little script I wrote
> that does git-ls-remote on the repository I want to track and writes a
> .git/remotes file to bring in all their branches. So if I want to see
> what behdad is up to, I first refresh his .git/remotes file with my:
>
> 	cairo-git-setup-remotes behdad
> then:
> 	git fetch behdad
>
> And I end up with a bunch of branch names with "behdad-" prefixes that
> I can explore or blow away if I'm no longer interested, (could have
> used a "behdad/" prefix as well).

I would suggest refs/remotes/behdad.

> So, yes, I'll definitely look into improving this. I think the details
> will involve:
>
> 1. Making clone do the --use-separate-remotes behavior by default
>
> 2. Taking advantage of that consistently for all branches instead of a
>    special master:origin mapping in clone

This already should be the case if you use separate-remote.  I
haven't run "clone --separate-remote" myself for a long time,
but the design was certainly to make it behave that way.
Specifically, map everything in refs/heads/ at remote to
refs/remotes/$origin/ with corresponding names, one-to-one.

I do not see much reason to change the mapping of master:origin
which is done for the traditional layout.  The traditional
layout is not suitable for your workflow anyway, and that is why
you prefer separate-remote layout for your project, and I fully
agree it would suit you better.

> 3. Enhancing git-fetch (or other) to modify .git/remotes, (or was
>    there a desire for some other branch-specific section in the config
>    file?)
>
> 4. Making git-fetch handle the disappearance of a remote branch
>    gracefully
>
> 5. Adding something like git-fetch --all to allow it to pick up all new
>    branches

These three are easily done for separate-remote layout but at
that point you would not want --all but more powerful --mirror
(or --update if you want to use that word), which goes the whole
nine yards of noticing disappearance of remote branch, making
matching deletion of local tracking branch, updating
.git/remotes, etc.  I've muttered something similar in a nearby
thread; see below.

> 6. Adding a "git update" that does a fetch for all appropriately
>    marked remotes.
>
> On this last point, maybe we do something like:
>
> 	update=no|yes|all
>
> in .git/remotes. Then git-clone would set this up with update=all for
> origin so git-update would do a "fetch --all" on the origin
> repository. Then step 3 above would have to provide for setting this
> update option as appropriate.

I would prefer this to be kept in contrib/; it feels like it is
filling rather very narrow need.

> Anyway, something along those lines perhaps. Any feedback?

I muttered something less elaborate in the nearby thread.

	Message-ID: <7vr6w78b4x.fsf@assigned-by-dhcp.cox.net>
	Message-ID: <7v64dev88t.fsf@assigned-by-dhcp.cox.net>

The part that deals with manual configuration (the last point in
the first message, and the second in message its entirety) is
something your workflow would not need nor want to worry about,
but I think it is necessary for different ref namespace layouts
and different workflows.  I think the automatable part (the
first two points in the "sensible thing to do" list in the first
message) is very relevant to what you talked about in your
message.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17 10:11                                                       ` Johannes Schindelin
@ 2006-11-17 11:41                                                         ` Junio C Hamano
  2006-11-17 16:58                                                         ` Shawn Pearce
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 11:41 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Carl Worth, Michael K. Edwards, git

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

>> 5. Adding something like git-fetch --all to allow it to pick up all new
>>    branches
>
> IIRC this idea was rejected, but I would find it useful. Especially with 
> what Han-Wen said: you can store the branches you fetch with "git fetch 
> --all <nick>" under .git/refs/remotes/<nick>/<branchname>.

With separate-remote layout, this can be done without risk of
tracking refname clashing with local refname, which was the
primary reason for an earlier reluctance.  

While separate-remote layout also solves Carl's "do not want to
track tracking branches remote has" problem, local branch
namespace can have both for-others (not necessarily "public" but
could be "for colleagues") and throwaway branches, so --all is
probably not the right thing to do in most cases.  But I am Ok
with the approach of seeing how well it works out in practice by
doing the simplest "--all" and giving options to restrict it
later.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 21:52                                         ` Junio C Hamano
  2006-11-15 21:59                                           ` Nicolas Pitre
@ 2006-11-17 12:20                                           ` Karl Hasselström
  1 sibling, 0 replies; 601+ messages in thread
From: Karl Hasselström @ 2006-11-17 12:20 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nicolas Pitre, git

On 2006-11-15 13:52:47 -0800, Junio C Hamano wrote:

> That means that updated "git merge" (not the current one) would not
> be able to assume it's parameter is a branch name, and still has to
> come up with the merge message "Merge <branch>".

Often, it would be a branch or a tag, so no problem there. For commits
in general, it should not be hard to compute the set of branches and
tags the commit is part of, and in the (probably) common case where
this set has exactly one element, the problem is solved. For the
remaining cases, it should not be too horrible to ask the user to
describe what is being merged.

-- 
Karl Hasselström, kha@treskal.com

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  6:42                                   ` Michael K. Edwards
  2006-11-17  7:32                                     ` Junio C Hamano
@ 2006-11-17 12:25                                     ` Jakub Narebski
  1 sibling, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-17 12:25 UTC (permalink / raw)
  To: git

Michael K. Edwards wrote:

> Currently, it looks like "remotes" entries are
> created only by "git clone" or by hand.  Junio, are there any plans to
> manage the contents of "remotes" through the tool instead of by hand?

Don't forget quite new work with managing remotes (and per-branch
configuration) in the config instead of separate remotes/ (or even older
branches/) file
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-16 23:32                                       ` Han-Wen Nienhuys
@ 2006-11-17 12:53                                         ` Jakub Narebski
  0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-17 12:53 UTC (permalink / raw)
  To: git

Han-Wen Nienhuys wrote:
> Linus Torvalds escreveu:

>>> If I then do 
>>>
>>>   git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master
>>>
>>> it downloads the same stuff again. 
>> 
>> Right. So you can either
>> [..]
>> See?
> 
> No, I don't understand. In the fetch all the objects with their SHA1s
> were already downloaded. I'd expect that the fetch with a refspec
> would simply write a HEAD and a refs/heads/master, and notice that all
> the actual data was already downloaded, and doesn't download it again. 

But how git is to know that you have this already downloaded? Git compares
_refs_ on the local and remote side to calculate what needs to be
downloaded. It does not (and should not) send all the objects IDs local
side has.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 13:03                               ` Han-Wen Nienhuys
  2006-11-16 13:11                                 ` Han-Wen Nienhuys
@ 2006-11-17 13:25                                 ` Jakub Narebski
  2006-11-24 12:26                                   ` Han-Wen Nienhuys
  1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-17 13:25 UTC (permalink / raw)
  To: git

Han-Wen Nienhuys wrote:

> As another example:  annoyances regarding program invocation
> 
>   - option handling: -x -f -z != -xfz , "--max-count 1" doesn't work, 
> but needs an '='

That's true, and the probable cause is that git tries to first, avoid
dependency on options parsers like getopt/getopt_long/argp or popt for
commands in C, getopt for commands in shell, Getopt::Std/Getopt::Long for
commands in Perl, and something for commands in Python (if there are any
left); second, existing options parsers do not deal (I think) with
distinction between arguments to wrapper and arguments to command, '--' to
separate revisions from pathnames not options from arguments, and the whole
revisions and revision list specifying syntax (where "a --not b" is not
equivalent to "--not a b").

That said, perhaps we should craft our own options parsing (or modify
existing one)...

>   - git --help lists an unordered set, which is too long scan quickly. 

It is one page of alphabetically ordered commands.

git(7) gives whole list of commands, divided into categories, by the way.

> I'd expect that list to either contain everything or the minimum set for 
> daily use. I.e. the set introduced in a first tutorial.  Why are merge, 
> prune, verify-tag there?
> 
> Try "bzr help" for comparison.

I wonder why "repack" isn't there, if "prune" is.

>   - --pretty option with wholly uninformative options full, medium, 
> short, raw.  It's not even documented what each option does.

And 'oneline' and undocumented 'email'. True, git lacks documentation (and
this one of main complaints in git survey).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 11:34                           ` Alexandre Julliard
  2006-11-16 14:01                             ` Petr Baudis
@ 2006-11-17 13:32                             ` Jakub Narebski
  2006-11-17 16:49                               ` Alexandre Julliard
  1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-17 13:32 UTC (permalink / raw)
  To: git

Alexandre Julliard wrote:

> Junio C Hamano <junkio@cox.net> writes:
> 
>> I would rather say "use 'git branch' to make sure if you are
>> ready to merge".  Who teaches not to use "git pull"?
> 
> We do that for Wine. The problem is that we recommend using git-rebase
> to make it easier for occasional developers to keep a clean history,
> and rebase and pull interfere badly.

What about proposed (and I think not accepted) merge strategy
"rebase" (formerly called "subordinate" or something like that)?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 10:36                                 ` Junio C Hamano
@ 2006-11-17 13:45                                   ` Jakub Narebski
  0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-17 13:45 UTC (permalink / raw)
  To: git

Junio C Hamano wrote:

> Marko Macek <marko.macek@gmx.net> writes:
> 
>>>> BTW, currently there's a minor bug: git-diff HEAD doesn't work before
>>>> you make the first commit. Perhaps this should be special cased.
>>>
>>> That's only a _bug_ in your implementation of the synonym for
>>> "svn diff" which blindly used "git diff HEAD".
>>
>> My "implementation" is taken from git-diff man page. It seems obvious
>> that the situation before the first commit is just a special case if
>> we consider git-diff to be Porcelain (which I do).
> 
> Yes, "git diff" is a Porcelain.  No question about it.
> 
> I do not consider the current behaviour of "git diff HEAD" that
> complains instead of giving runs of "foo is a new file and no
> diff is available for it" a bug; you asked for diff from some
> commit but the commit you gave was bogus (does not exist yet).

git diff --root HEAD, perhaps?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-16 19:01                                       ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
@ 2006-11-17 16:26                                         ` Shawn Pearce
  2006-11-17 16:45                                           ` Linus Torvalds
                                                             ` (2 more replies)
  0 siblings, 3 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-11-17 16:26 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git

Linus Torvalds <torvalds@osdl.org> wrote:
>  - "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge 
>    (or some other operations, like "git rebase" and "git reset": think of 
>    it as a "original head before we did some uncontrolled operation 
>    where we otherwise can't use HEAD^ or similar")
> 
>    I use "gitk ORIG_HEAD.." a lot, and if I don't like something I see 
>    when I do it, I end up doing "git reset --hard ORIG_HEAD" to undo a 
>    pull I've done. This is important exactly because ORIG_HEAD is _not_ 
>    the same as the first parent of a merge, since a merge could have been 
>    just a fast-forward.

Although if you have reflog enabled on your current branch there
is a 1 character shorter syntax:

	gitk HEAD@{1}..

as recent Git understands that to mean the value that HEAD just had,
which is also what is in ORIG_HEAD.  Except that unlike ORIG_HEAD
it can also show even older values (e.g. HEAD@{3}, 3 ops back)
and it works very, very well on tracking branches.  "What did I
just fetch in next?" `git log next@{1}..next`

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-17 16:26                                         ` Shawn Pearce
@ 2006-11-17 16:45                                           ` Linus Torvalds
  2006-11-17 16:51                                             ` Carl Worth
  2006-11-17 17:08                                             ` Shawn Pearce
  2006-11-17 16:46                                           ` Carl Worth
  2006-11-17 17:39                                           ` Junio C Hamano
  2 siblings, 2 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-17 16:45 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Han-Wen Nienhuys, Junio C Hamano, git

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1391 bytes --]



On Fri, 17 Nov 2006, Shawn Pearce wrote:
> 
> Although if you have reflog enabled on your current branch there
> is a 1 character shorter syntax:
> 
> 	gitk HEAD@{1}..

Heh. With a finnish keyboard, that "@" is AltGr+'2', and the '{'/'}' is 
AltGr+'7'/'0', I guarantee that it's not "1 character shorter", it's 
"three pretty complicated characters longer" and "off the normal path 
where you hold your fingers on the keyboard ;)

And that's not even mentioning that '{'/'}' is a magic sequence for 
filename expansion to the shell, so every time I see that, I have to think 
about it (and it turns out that because there is no comma in between 
there, it's ok. Otherwise you would need to quote it or escape them...)

So the reflog syntax is fine, but it's definitely not a "simple" syntax. 
I'd only use it for things where I want something that ORIG_HEAD won't 
give me ("ORIG_HEAD" you can type by just holding the shift key down all 
the time, and letting your fingers dance over the keyboard, both on a US 
and a Finnish keyboard).

And yes, I actually use a Finnish keyboard, still. Don't ask me why. I 
don't actually need the åäö characters often enough for it to matter, and 
I have used US keyboards elsewhere enough that I can switch between the 
two without thinking, but I still ended up having my sister ship me a 
keyboard from Finland when I wanted to upgrade..

			Linus

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-17 16:26                                         ` Shawn Pearce
  2006-11-17 16:45                                           ` Linus Torvalds
@ 2006-11-17 16:46                                           ` Carl Worth
  2006-11-17 17:15                                             ` Shawn Pearce
  2006-11-17 17:39                                           ` Junio C Hamano
  2 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-17 16:46 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Linus Torvalds, Han-Wen Nienhuys, Junio C Hamano, git

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On Fri, 17 Nov 2006 11:26:05 -0500, Shawn Pearce wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
> >  - "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge
...
> Although if you have reflog enabled on your current branch there
> is a 1 character shorter syntax:
>
> 	gitk HEAD@{1}..

Yes, this was my exact thought when reading what Linus
wrote. ORIG_HEAD might be fine and all, but it pales in functionality
compared to what reflog provides.

I would very much like to see reflog getting first-class citizen
support in git:

1. Be on by default

2. Get documented in all the right places, (much better than adding
   documentation for ORIG_HEAD in my opinion)

3. Tighter integration with branch manipulations. Do we already delete
   reflog when deleting a branch? We don't have a branch rename
   operation, but if we get one, renaming the reflog should go
   hand-in-hand, etc.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17 13:32                             ` Jakub Narebski
@ 2006-11-17 16:49                               ` Alexandre Julliard
  2006-11-17 17:41                                 ` Jakub Narebski
  0 siblings, 1 reply; 601+ messages in thread
From: Alexandre Julliard @ 2006-11-17 16:49 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

Jakub Narebski <jnareb@gmail.com> writes:

> Alexandre Julliard wrote:
>
>> Junio C Hamano <junkio@cox.net> writes:
>> 
>>> I would rather say "use 'git branch' to make sure if you are
>>> ready to merge".  Who teaches not to use "git pull"?
>> 
>> We do that for Wine. The problem is that we recommend using git-rebase
>> to make it easier for occasional developers to keep a clean history,
>> and rebase and pull interfere badly.
>
> What about proposed (and I think not accepted) merge strategy
> "rebase" (formerly called "subordinate" or something like that)?

That sounds very interesting. Has it ever been implemented, or only
discussed?

-- 
Alexandre Julliard

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-17 16:45                                           ` Linus Torvalds
@ 2006-11-17 16:51                                             ` Carl Worth
  2006-11-17 17:08                                             ` Shawn Pearce
  1 sibling, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-17 16:51 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Shawn Pearce, Han-Wen Nienhuys, Junio C Hamano, git

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

On Fri, 17 Nov 2006 08:45:39 -0800 (PST), Linus Torvalds wrote:
> > Although if you have reflog enabled on your current branch there
> > is a 1 character shorter syntax:
> >
> > 	gitk HEAD@{1}..
>
> Heh. With a finnish keyboard, that "@" is AltGr+'2', and the '{'/'}' is
> AltGr+'7'/'0', I guarantee that it's not "1 character shorter", it's
> "three pretty complicated characters longer" and "off the normal path
> where you hold your fingers on the keyboard ;)

It's not even all that convenient on a U.S. keyboard. My pinky suffers
a bit having to pop on and off of shift for the '{', '1', '}'. Then
again, I don't like having to hold shift down for all of ORIG_HEAD
either, (but it's definitely easier in comparison).

But since reflog does everything ORIG_HEAD does and more, shall we
just clean up the syntax somehow? Ideas anyone? And then fix the
documentation to explain that?

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17 10:11                                                       ` Johannes Schindelin
  2006-11-17 11:41                                                         ` Junio C Hamano
@ 2006-11-17 16:58                                                         ` Shawn Pearce
  1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-11-17 16:58 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Carl Worth, Junio C Hamano, Michael K. Edwards, git

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I introduced the remote.<nick>.{url,fetch,push} entries into the config 
> with the goal to enhance -fetch to remember the current command line with 
> a setting. I was the only one to find that useful.
> 
> BTW I still would argue that it is better to write the remote information 
> into the config, because you have a saner way to manipulate that from 
> scripts than .git/remotes/<nick>.

I'm *fully* in favor of the remote.<nick>.{url,fetch,push} entries
in the config file.  I've pretty much switched every repository to
that format at this point.

In writing git-gui I'm finding it much, much easier to manage
things through repo-config than to do any mucking around in the
.git/remotes directory.  Yes, the remote files have simple format,
but I can get everything in one "git repo-config --list" pull it
all into a Tcl array and work with it; using .git/remotes means I
have to open the file and read each line too.  :-(

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-17 16:45                                           ` Linus Torvalds
  2006-11-17 16:51                                             ` Carl Worth
@ 2006-11-17 17:08                                             ` Shawn Pearce
  1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-11-17 17:08 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git

Linus Torvalds <torvalds@osdl.org> wrote:
> On Fri, 17 Nov 2006, Shawn Pearce wrote:
> > 
> > Although if you have reflog enabled on your current branch there
> > is a 1 character shorter syntax:
> > 
> > 	gitk HEAD@{1}..
> 
> Heh. With a finnish keyboard, that "@" is AltGr+'2', and the '{'/'}' is 
> AltGr+'7'/'0', I guarantee that it's not "1 character shorter", it's 
> "three pretty complicated characters longer" and "off the normal path 
> where you hold your fingers on the keyboard ;)

I forgot that you use a finnish keyboard.  :-)

I agree with you; its not easier to type, for you.  Me, I'm a dumb
American who uses a Kinesis keyboard, therefore my left foot is
my shift key and its in sync with my fingers.  I have no extra
pinky load for either syntax.  And since the reflog syntax works
in a lot more contexts (e.g. after a fetch into a tracking branch)
I have just forgotten about ORIG_HEAD entirely.  Oh sure, I know
its there, but its not something I think about using...

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-17 16:46                                           ` Carl Worth
@ 2006-11-17 17:15                                             ` Shawn Pearce
  2006-11-17 17:50                                               ` Marko Macek
  0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-17 17:15 UTC (permalink / raw)
  To: Carl Worth; +Cc: Linus Torvalds, Han-Wen Nienhuys, Junio C Hamano, git

Carl Worth <cworth@cworth.org> wrote:
> Yes, this was my exact thought when reading what Linus
> wrote. ORIG_HEAD might be fine and all, but it pales in functionality
> compared to what reflog provides.
> 
> I would very much like to see reflog getting first-class citizen
> support in git:
> 
> 1. Be on by default

I have:

	git repo-config --global core.logAllRefUpdates true

especially since Junio fixed it to only create logs for heads and
not tags.  That way its on by default for me.  But I think it should
be on by default in the next version of Git.
 
> 2. Get documented in all the right places, (much better than adding
>    documentation for ORIG_HEAD in my opinion)

Agreed.  I'm not likely to do it anytime soon however, so I'm hoping
someone else will do it...  :-)
 
> 3. Tighter integration with branch manipulations. Do we already delete
>    reflog when deleting a branch? We don't have a branch rename
>    operation, but if we get one, renaming the reflog should go
>    hand-in-hand, etc.

Yes, we delete the log when we delete the branch, and we prune
back the empty directories too just like we do on the branch side,
so that new branches can be correctly created.

There was a recent discussion about that from Junio if I recall.
Several people that I work with have asked that branch rename
support be added to Git, and that if you rename the branch the
reflog follows.  Because in their mind they are simply changing
the name of the branch, any old history of that branch should
stick around.

I tried to think of an option to "git branch" to do the rename but
kept thinking that:

	git rename-branch old new

is the better syntax...  even though that's command number 133
or something like that...

We should stick a "null" event into the reflog during a branch
rename.  Make both the old and new SHA1 the current SHA1 but drop
a message in saying "renamed branch old -> new" (for example).

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos
  2006-11-17 16:26                                         ` Shawn Pearce
  2006-11-17 16:45                                           ` Linus Torvalds
  2006-11-17 16:46                                           ` Carl Worth
@ 2006-11-17 17:39                                           ` Junio C Hamano
  2006-11-18  6:02                                             ` Shawn Pearce
  2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 17:39 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Linus Torvalds, Han-Wen Nienhuys, git

Shawn Pearce <spearce@spearce.org> writes:

> Linus Torvalds <torvalds@osdl.org> wrote:
>>  - "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge 
>>    (or some other operations, like "git rebase" and "git reset": think of 
>>    it as a "original head before we did some uncontrolled operation 
>>    where we otherwise can't use HEAD^ or similar")
>> 
>>    I use "gitk ORIG_HEAD.." a lot, and if I don't like something I see 
>>    when I do it, I end up doing "git reset --hard ORIG_HEAD" to undo a 
>>    pull I've done. This is important exactly because ORIG_HEAD is _not_ 
>>    the same as the first parent of a merge, since a merge could have been 
>>    just a fast-forward.
>
> Although if you have reflog enabled on your current branch there
> is a 1 character shorter syntax:
>
> 	gitk HEAD@{1}..

Are you sure about this?  I've seen "next@{1}" to look at
history of the named branch, but never history of "HEAD".

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17 16:49                               ` Alexandre Julliard
@ 2006-11-17 17:41                                 ` Jakub Narebski
  0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-17 17:41 UTC (permalink / raw)
  To: Alexandre Julliard, Junio C Hamano; +Cc: git

Alexandre Julliard wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Alexandre Julliard wrote:
>>> Junio C Hamano <junkio@cox.net> writes:
>>> 
>>>> I would rather say "use 'git branch' to make sure if you are
>>>> ready to merge".  Who teaches not to use "git pull"?
>>> 
>>> We do that for Wine. The problem is that we recommend using git-rebase
>>> to make it easier for occasional developers to keep a clean history,
>>> and rebase and pull interfere badly.
>>
>> What about proposed (and I think not accepted) merge strategy
>> "rebase" (formerly called "subordinate" or something like that)?
> 
> That sounds very interesting. Has it ever been implemented, or only
> discussed?

There was some implementation with warts

  http://thread.gmane.org/gmane.comp.version-control.git/30068
  Message-Id: <20061025155009.GD5591@parisc-linux.org>

which didn't got corrected and resent.
-- 
Jakub Narebski

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
  2006-11-17 17:15                                             ` Shawn Pearce
@ 2006-11-17 17:50                                               ` Marko Macek
  2006-11-17 20:24                                                 ` multi-project repos Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Marko Macek @ 2006-11-17 17:50 UTC (permalink / raw)
  To: git; +Cc: junkio

Shawn Pearce wrote:
> Carl Worth <cworth@cworth.org> wrote:
>> Yes, this was my exact thought when reading what Linus
>> wrote. ORIG_HEAD might be fine and all, but it pales in functionality
>> compared to what reflog provides.
>>
>> I would very much like to see reflog getting first-class citizen
>> support in git:
>>
>> 1. Be on by default

I agree.

> I have:
> 
> 	git repo-config --global core.logAllRefUpdates true
> 
> especially since Junio fixed it to only create logs for heads and
> not tags.  That way its on by default for me.  But I think it should
> be on by default in the next version of Git.

Why is it not useful for tags for having logs? 

I also have a question:

Does git-fsck-objects/prune check the ref logs?

Mark

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos
  2006-11-17 17:50                                               ` Marko Macek
@ 2006-11-17 20:24                                                 ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 20:24 UTC (permalink / raw)
  To: Marko Macek; +Cc: git

Marko Macek <marko.macek@gmx.net> writes:

> Shawn Pearce wrote:
>...
>> I have:
>>
>> 	git repo-config --global core.logAllRefUpdates true
>>
>> especially since Junio fixed it to only create logs for heads and
>> not tags.  That way its on by default for me.  But I think it should
>> be on by default in the next version of Git.
>
> Why is it not useful for tags for having logs?

When I make a tag that says "this is the v1.2.0 release", it is
expected it won't change in the future, ever.  I _can_ make
mistake and tag a wrong commit under v1.2.0 name, in which case
I may have to replace it with another corrected tag, but
recoding that mistake does not really add value.  So most of the
time ref-log for a tag would contain only one entry per file, its
creation, but that creation time is already recorded in the tag
object itself anyway.

At times, it may be useful to have some floating tag that point
at the "latest", or "today's", but that use is a minority.  For
these minority cases, you can manually create an empty file
under .git/logs/ directory to record their updates.

The configuration mechanism only kicks in when there is no such
existing file to prime the process, and not creating ref-log for
tags by default is the sensible thing to do.

> I also have a question:
>
> Does git-fsck-objects/prune check the ref logs?

They deliberately ignore ref-log for the same reason lost-found
does not drop found refs under .git/refs hierarchy.

This only matters if you somehow rewind an existing branch in
order to lose part of its history, using "reset --hard HEAD~n"
or "rebase".  If the updates to your branch tips always build on
top of the previous (either by commiting on top of the current,
merging on top of the current, or fast-forwarding), and if you
never rewind the branch, the commits recorded in the ref-log for
the branch are always ancestors of the tip of the branch, so
checking ref-log does not give you anything other than slowing
the operation down.

However, if you rewind the tip of a branch, the story changes.
Until the next "prune", objects reachable from the ref-log of
the branch but not reachable from the tip of the branch are
still available in your object store and in a pinch you can
recover them, but after a "prune" they will be lost forever if
they do not have any other references.  So it might seem that
they should be protected from pruning.

But if you did so, you can never remove cruft from your object
store once you make a mistake.  You can clean up your history by
a reset and/or a rebase, and cleaning up to _lose_ part of the
history was the reason you rewound the branch in the first
place.

In other words, running 'prune' is a conscious act of saying "I
know I am not in the middle of something; I thought over what
I've done recently, salvaged necessary bits from what I
discarded earlier, and there is nothing that need to be salvaged
later anymore -- I have refs to what I need.  Now go clean up
the cruft from my object store".




^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 20:56       ` Carl Worth
  2006-11-15  0:31         ` Junio C Hamano
@ 2006-11-17 20:30         ` Steven Grimm
  2006-11-17 21:35           ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Steven Grimm @ 2006-11-17 20:30 UTC (permalink / raw)
  To: git

Jumping into this a day late, but:

Carl Worth wrote:
> I don't see any defining difference that justifies cogito's
> existence ("hide the index" maybe? let's just hide it a tiny bit more
> in git). And I would like to help work to get the remaining good
> stuff that has been proven in cogito---to get it pushed down into git
> itself.
>   

Agreed totally on the second point. It would be great if git natively 
supported everything people use in Cogito.

I find myself using native git commands for the most part, except for 
one Cogito command: "cg-update". It is vastly more convenient than 
git-pull in large part because it automatically merges upstream changes 
with uncommitted working-copy changes. I suppose you could classify this 
as "hide the index" in some sense.

Maybe I should give an example of what I mean. Suppose I have two child 
repositories (owned by different developers, say):

cg-clone repo child1
cg-clone repo child2

Now I go into both of them and make different (hopefull non-conflicting) 
edits to the same file.

echo foo >> child1/testfile
perl -pi -e 's/tree/shrub/' child2/testfile

I push the change from child1 into the integration repo.

cd child1
git-commit -a
git-push

Now I want to incorporate the change into child2, where I'm still doing 
work. With Cogito, I go to child2 and run:

cg-update

and afterwards, the upstream changes are merged into testfile and "git 
diff" still shows my local edits. With Git native commands, updating 
child2 if I'm not ready to commit yet is more like:

git-diff --binary > /tmp/patch
git-reset --hard
git-pull
git-apply /tmp/patch

I might have gotten that slightly wrong, but I think I have the general 
idea right; in any event, it's not nearly as convenient! The alternative 
is to commit then pull, but then when I want to look at my local edits, 
I have to remember to diff my working copy against the correct revision, 
which gets increasingly annoying if I update more than once.

Like others on this list, I'm also trying to sell an existing user base 
(in this case, they're using Subversion) on Git. The lack of a built-in 
equivalent to "svn update" is actually a pretty big UI annoyance for 
people whose workflow doesn't require git's more sophisticated feature 
set at a given point in time. Even a sophisticated user doesn't need the 
full power of the tool 100% of the time, so this isn't just a novice vs. 
expert thing in my opinion.

Absent Cogito, would the lack of a simple "svn update" equivalent be a 
deal-killing "throw your hands up in disgust and give up" thing? Maybe 
not, but it's a daily "ugh, why am I having to type extra commands to do 
something that only took one command in svn?" thing. So it's nice to 
have Cogito to paper over that particular wart.

If there is a native git equivalent to cg-update including the 
working-copy automatic merges, I'll be delighted to stand corrected!


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17 20:30         ` Steven Grimm
@ 2006-11-17 21:35           ` Junio C Hamano
  2006-11-17 22:07             ` Petr Baudis
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 21:35 UTC (permalink / raw)
  To: Steven Grimm; +Cc: git

Steven Grimm <koreth@midwinter.com> writes:

> echo foo >> child1/testfile
> perl -pi -e 's/tree/shrub/' child2/testfile
>...
> git-diff --binary > /tmp/patch
> git-reset --hard
> git-pull
> git-apply /tmp/patch
>
> I might have gotten that slightly wrong, but I think I have the
> general idea right.

stg pull would help you in such a situation as well, but I see
what you mean.

Just like we have an explicit -m option to "checkout" to allow
file-level merging of local changes, I think it is reasonable to
hav an option that allows file-level merging of local changes
when doing a pull that you _know_ will not conflict.

When there will be a conflict between your HEAD and MERGE_HEAD
even without your local changes, you somehow need to sort out
the resulting mess that come from conflicts due to the branch
diversion (i.e. log HEAD...MERGE_HEAD) and conflicts between
your local change and what the other branch did.  The resulting
merge commit obviously needs to record resolutions only to the
former and should not even record anything you did locally,
conflicted or not.  Which is a pain for the end user and giving
them a way to revert to the state before this three-and-half
way merge started also needs to be there.

Unfortunately the only way to know if there will be a file-level
conflict is to try one, and stashing away the current state just
in case it conflicted is a performance penalty, so this probably
should stay as an option just like "-m" to the "checkout".

But the basic mechanism to do this three-and-half way merge is
simple and I have no objection if somebody wanted to add such an
option to "git pull".


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17 21:35           ` Junio C Hamano
@ 2006-11-17 22:07             ` Petr Baudis
  0 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-17 22:07 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Steven Grimm, git

On Fri, Nov 17, 2006 at 10:35:04PM CET, Junio C Hamano wrote:
> Unfortunately the only way to know if there will be a file-level
> conflict is to try one, and stashing away the current state just
> in case it conflicted is a performance penalty, so this probably
> should stay as an option just like "-m" to the "checkout".

I think it would be just great if it worked at least for fast-forwarding
case; I think this is where it is actually most useful. Cogito tries to
support even the three-way case as long as the changes touch different
files, but I'm not sure if it was a good idea to begin with.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  7:32                                     ` Junio C Hamano
@ 2006-11-18  1:24                                       ` Michael K. Edwards
  0 siblings, 0 replies; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-18  1:24 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On 11/16/06, Junio C Hamano <junkio@cox.net> wrote:
> "Michael K. Edwards" <medwards.linux@gmail.com> writes:
>
> > Presumably "git branch -D" should inspect everything under
> > .git/remotes to see whether one or more Pull: lines need to be
> > deleted along with the branch.
>
> I am not sure what you mean.  .git/remotes files do not describe
> any relationship between local branches (and that is where one
> of the problem raised in recent thread -- pull does not notice
> on which branch you are on and change its behaviour depending on
> it), so I do not think there is anything gained for "git branch
> -D" by going through them.

.git/remotes/foo does contain Pull: lines which indicate the local
branch onto which to _fetch_ remote changes.  It's the subsequent
_merge_ that doesn't notice which branch you have checked out.

Cheers,

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos
  2006-11-17 17:39                                           ` Junio C Hamano
@ 2006-11-18  6:02                                             ` Shawn Pearce
  2006-11-18  7:31                                               ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-18  6:02 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Linus Torvalds, Han-Wen Nienhuys, git

Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> > Although if you have reflog enabled on your current branch there
> > is a 1 character shorter syntax:
> >
> > 	gitk HEAD@{1}..
> 
> Are you sure about this?  I've seen "next@{1}" to look at
> history of the named branch, but never history of "HEAD".
 
Yes.  :-)

If the ref name is a symref then we resolve the symref all the
way down to the real ref before we open and walk the reflog.
Therefore this works.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos
  2006-11-18  6:02                                             ` Shawn Pearce
@ 2006-11-18  7:31                                               ` Junio C Hamano
  2006-11-18  7:45                                                 ` Shawn Pearce
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-18  7:31 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Linus Torvalds, Han-Wen Nienhuys, git

Shawn Pearce <spearce@spearce.org> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> Shawn Pearce <spearce@spearce.org> writes:
>> > Although if you have reflog enabled on your current branch there
>> > is a 1 character shorter syntax:
>> >
>> > 	gitk HEAD@{1}..
>> 
>> Are you sure about this?  I've seen "next@{1}" to look at
>> history of the named branch, but never history of "HEAD".
>  
> Yes.  :-)
>
> If the ref name is a symref then we resolve the symref all the
> way down to the real ref before we open and walk the reflog.
> Therefore this works.

True, except if you did:

        $ git pull
        $ git checkout otherbranch
        $ git show HEAD@{1}

My real point was that I was wondering if it also makes sense
for ref-log to record switching branches for the symref itself.

But after sending that message I thought about it a bit more and
concluded that it is not an interesting information.  It is more
code that affects unrelated places even if we were to implement
it and without real gain, so let's not log symref itself and
keep the current implementation.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: multi-project repos
  2006-11-18  7:31                                               ` Junio C Hamano
@ 2006-11-18  7:45                                                 ` Shawn Pearce
  0 siblings, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-11-18  7:45 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Linus Torvalds, Han-Wen Nienhuys, git

Junio C Hamano <junkio@cox.net> wrote:
> True, except if you did:
> 
>         $ git pull
>         $ git checkout otherbranch
>         $ git show HEAD@{1}
> 
> My real point was that I was wondering if it also makes sense
> for ref-log to record switching branches for the symref itself.
> 
> But after sending that message I thought about it a bit more and
> concluded that it is not an interesting information.  It is more
> code that affects unrelated places even if we were to implement
> it and without real gain, so let's not log symref itself and
> keep the current implementation.

I agree completely.

I have no interest in a history of what branches I've recently
been on.  All I care about is the history of this branch.  And I
consider HEAD to be nothing but a shortcut that always points to
the current branch... so its darn useful for that.

In retrospect CURR may have been a better name for the HEAD symref
but its far too late to even consider changing that, so lets not
go down that road.  :-)

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-14 22:36         ` Junio C Hamano
  2006-11-14 22:50           ` Junio C Hamano
  2006-11-16  5:12           ` Petr Baudis
@ 2006-11-18  7:59           ` Alan Chandler
  2 siblings, 0 replies; 601+ messages in thread
From: Alan Chandler @ 2006-11-18  7:59 UTC (permalink / raw)
  To: git

On Tuesday 14 November 2006 22:36, Junio C Hamano wrote:
...
>
> And I agree with Pasky that fixing UI is hard unless you are
> willing to get rid of historical warts.  Syntax of the command
> line arguments the current set of Porcelain-ish takes are
> sometimes just horrible.  It may not be a bad idea to start
> building the fixed UI from scratch, using different prefix than
> "git" (say "gu" that stands for "git UI" or "gh" that stands for
> "git for humans").
>
> Of course, it could even be "cg" ;-).

I have been away on business last week and have been following this thread 
from the archives.  There is a comment I want to make about split of 
Porcelain and Plumbing namespaces that is not particularly an answer to this 
particular post, but it does seem an appropriate place to insert it.

I think there were three (historic) mistakes in the development of git
	- to split git and cogito so that some of the commands started git and some 
cg (aided and abetted by putting them in separate repositories).
	- to try and make the distinction between plumbing and porcelein a line in 
the sand (after all this is exactly why git and cg separated) when in 
practice it isn't that straight forward
	- for cogito to (initially) not support the internal branches, but in fact 
deal with them via cloned repositories

On the other hand, it was a good move to bring gitk and gitweb into the core 
repository.

These were not technical mistakes, but social ones.

Much of the discussion on UI warts doesn't exist in the cogito world (not that 
I use it at all anymore, despite its more user friendly interface - just 
because I didn't want to learn two parallel sets of commands and I prefered 
git's branch model so stuck with the slightly less friendly git command set) 
but if you look at any of the SCM comparison discussions that happen now, 
they are always comparing the core git with the other SCM, not git plus all 
its porcelains.

So I think it would be a mistake (which hopefully does seem to be the 
concensus reached in the list) to try and introduce new namespaces to the 
command set.
-- 
Alan Chandler

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 15:41                 ` Nicolas Pitre
  2006-11-15 17:59                   ` Junio C Hamano
@ 2006-11-18 11:09                   ` Alan Chandler
  1 sibling, 0 replies; 601+ messages in thread
From: Alan Chandler @ 2006-11-18 11:09 UTC (permalink / raw)
  To: git

On Wednesday 15 November 2006 15:41, Nicolas Pitre wrote:
> On Wed, 15 Nov 2006, Andy Parkins wrote:
> >  * Don't use the name "origin" twice.  In fact, don't use it at all.  In
> > a distributed system there is no such thing as a true origin.
>
> I agree, sort of.  Not because"origin" is ambigous as a name.  But
> rather because there is a magic translation from "master" to "origin",
> and I think this is wrong to do that.
>
> As mentioned elsewhere (and let's start using "get" instead of "pull" as
> suggested by Johannes), a "get" should probably always create a branch
> group even if it contains only one branch.  This way the remote branch
> called "master" will still be called "master" locally, under the branch
> group used to represent the remote repository.  And if a local name is
> not provided then let's just call it "default".  This way, amongst the
> remote references, there would be a "default/master" that would be used
> when nothing else is provided by the user. So...
>
> 	git get repo.com/time_machine.git
>
> would create a local branch named "remotes/default/master" if the remote
> repo has only a master branch.

Why not call it remotes/repo.com/time_machine.git/master and have a 
DEFAULT_ORIGIN that is a symref to it in the same way as HEAD is a symref to 
a local branch

-- 
Alan Chandler

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 11:47                               ` Junio C Hamano
@ 2006-11-20 19:44                                 ` Horst H. von Brand
  2006-11-20 19:46                                   ` Shawn Pearce
  2006-11-20 20:02                                   ` Jakub Narebski
  0 siblings, 2 replies; 601+ messages in thread
From: Horst H. von Brand @ 2006-11-20 19:44 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: hanwen, git

Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
> > Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> >
> >> [hanwen@haring y]$ git pull ../x
> >> fatal: Needed a single revision
> >> Pulling into a black hole?
> 
> Having said all that, I happen to think that this particular
> case of pulling into void could deserve to be special cased to
> pretend it is a fast forward (after all, nothingness is an
> ancestor of anything), if only to make new people's first
> experience more pleasant.

If you make pushing into an empty repository work also, you fix the case of
"create an empty repo for somebody, let them fill it up remotely later".

[...]

> So please consider that this is classified as a bug.

Thanks!
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-20 19:44                                 ` Horst H. von Brand
@ 2006-11-20 19:46                                   ` Shawn Pearce
  2006-11-20 20:02                                   ` Jakub Narebski
  1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-11-20 19:46 UTC (permalink / raw)
  To: Horst H. von Brand; +Cc: Junio C Hamano, hanwen, git

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote:
> If you make pushing into an empty repository work also, you fix the case of
> "create an empty repo for somebody, let them fill it up remotely later".

This seems to work just fine now.  I do it all of the time.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-20 19:44                                 ` Horst H. von Brand
  2006-11-20 19:46                                   ` Shawn Pearce
@ 2006-11-20 20:02                                   ` Jakub Narebski
  1 sibling, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-20 20:02 UTC (permalink / raw)
  To: git

Horst H. von Brand wrote:
> Junio C Hamano <junkio@cox.net> wrote:
>> Junio C Hamano <junkio@cox.net> writes:
>>> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>>>
>>>> [hanwen@haring y]$ git pull ../x
>>>> fatal: Needed a single revision
>>>> Pulling into a black hole?
>> 
>> Having said all that, I happen to think that this particular
>> case of pulling into void could deserve to be special cased to
>> pretend it is a fast forward (after all, nothingness is an
>> ancestor of anything), if only to make new people's first
>> experience more pleasant.
> 
> If you make pushing into an empty repository work also, you fix the case of
> "create an empty repo for somebody, let them fill it up remotely later".

That was only the _pull_ which didn't work in empty repo.
Fetch and push worked (and work) just fine with empty repo.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-15 21:08                                   ` Carl Worth
  2006-11-15 21:31                                     ` Junio C Hamano
  2006-11-15 21:45                                     ` Linus Torvalds
@ 2006-11-21 13:25                                     ` Jerome Lovy
  2 siblings, 0 replies; 601+ messages in thread
From: Jerome Lovy @ 2006-11-21 13:25 UTC (permalink / raw)
  To: git

On Wed, 15 Nov 2006, Carl Worth wrote:
> Well, one of the problems is that with current git I can teach, (and I
> have), that there's a conceptual:
> 
> 	pull = fetch + merge
> 
> But then shortly after I have to teach an interface notion:
> 
> 	merge = pull .
> 
> So there's this goofy circular notion that people end up with
> mentally. If we fix it so that a local merge really is performed with
> "git merge <branch>" instead of "git pull . <branch>" then teaching
> pull=fetch+merge really is a lot easier.

On a conceptual level, can we not perhaps explain that if

	pull = fetch + merge

then

	merge = pull - fetch

and that the latter (pull - fetch) happens to be expressed with the 
interface as 'git pull .' ?

My 2 cents.
Jérôme

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-16 16:07                           ` Theodore Tso
  2006-11-16 16:49                             ` Theodore Tso
@ 2006-11-22 23:21                             ` Sanjoy Mahajan
  2006-11-24 11:29                               ` Jakub Narebski
  1 sibling, 1 reply; 601+ messages in thread
From: Sanjoy Mahajan @ 2006-11-22 23:21 UTC (permalink / raw)
  To: Theodore Tso; +Cc: Junio C Hamano, git, Nicolas Pitre, Linus Torvalds

The car analogy is excellently clear.

> they need more than the "stupid simple" git usage, but if they don't
> need the extreme power of git, Hg is simpler for people to learn how
> to use.

As a 80%-hg/20%-git user, I'm curious what features of git you had in
mind, so I know where to look as I wander up the git learning curve.

My experience with the git user interface, for what it's worth, is
that I never quite get the conceptual model crystal clear enough in my
head. So it won't stay for long enough for me to progress up the
learning curve and retain the gains.  I move up a bit, but the gain
soon evaporates and I backslide, and then just hack my way through it.

I found hg's conceptual model very easy to learn, almost as if I don't
have to remember anything.  Maybe that simplicity comes at a price,
whence my question at the start about the extreme-power features of
git.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17  0:05                               ` Han-Wen Nienhuys
                                                   ` (2 preceding siblings ...)
  2006-11-17  1:34                                 ` Michael K. Edwards
@ 2006-11-23  2:52                                 ` Horst H. von Brand
  3 siblings, 0 replies; 601+ messages in thread
From: Horst H. von Brand @ 2006-11-23  2:52 UTC (permalink / raw)
  To: hanwen; +Cc: Linus Torvalds, Junio C Hamano, git

Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:

[...]

> Until that time, it would be good goal to remove all idiosyncrasies,
> all gratuitious asymetries and needless limitations in the commands of
> git, eg.
> 
>  - clone but not a put-clone,

Lost me there.

>  - pull = merge + fetch, but no command for merge + throw

throw + merge (at the remote end, that is)?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-22 23:21                             ` Sanjoy Mahajan
@ 2006-11-24 11:29                               ` Jakub Narebski
  0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-24 11:29 UTC (permalink / raw)
  To: git

Sanjoy Mahajan wrote:

> The car analogy is excellently clear.
> 
>> they need more than the "stupid simple" git usage, but if they don't
>> need the extreme power of git, Hg is simpler for people to learn how
>> to use.
> 
> As a 80%-hg/20%-git user, I'm curious what features of git you had in
> mind, so I know where to look as I wander up the git learning curve.
> 
> My experience with the git user interface, for what it's worth, is
> that I never quite get the conceptual model crystal clear enough in my
> head. So it won't stay for long enough for me to progress up the
> learning curve and retain the gains.  I move up a bit, but the gain
> soon evaporates and I backslide, and then just hack my way through it.
> 
> I found hg's conceptual model very easy to learn, almost as if I don't
> have to remember anything.  Maybe that simplicity comes at a price,
> whence my question at the start about the extreme-power features of
> git.

As I never used Mercurial (hg), only read a bit about it and discussed on
#revctrl, I cannot say what features git has that hg has not, but I can
tell what powerfull git features differ from other SCM.

First, usually in other SCM the concept of branch is closely tied to the
concept of repository, perhaps allowing to share storage between branches
on the same local filesystem (on the same machine). In git, repository
holds DAG, the graph of revisions (of versions). Branches are "only" ways
to access this graph, and to extend it of the new commits. This makes git
more powerfull, but also perhaps unnecessary complicated if you deal with
single-branch repositories, or few-branch case. Additionally this
"complication" makes very clean model of repository - but you have to
understand it...

Second, the index. One might think that it is performance hack, but it
allows for commiting changes piece by piece and, what is more important,
a place form making merge in. Cogito (alternate Git UI/porcelain) tries to
hide index. By the way, I wonder how hg does merges without index to
provide place where do merges in...

Third, explicit/on-demand packing. This allows for the most (I think)
compression of all SCMs, and for the wire format to be the same as on-disk
format (with the addition that you can send thin packs on wire). As of now
no porcelain tries to hide it, although with the latest work allowing for
historical packs it would be easy to add this without significantly
affecting preformance.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-17 13:25                                 ` Jakub Narebski
@ 2006-11-24 12:26                                   ` Han-Wen Nienhuys
  2006-11-24 12:41                                     ` Jakub Narebski
                                                       ` (2 more replies)
  0 siblings, 3 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-24 12:26 UTC (permalink / raw)
  To: git

Jakub Narebski escreveu:

>>   - --pretty option with wholly uninformative options full, medium, 
>> short, raw.  It's not even documented what each option does.
> 
> And 'oneline' and undocumented 'email'. True, git lacks documentation (and
> this one of main complaints in git survey).

The recently posted patch documenting is an improvement, but why not
add an option so you can do

  --format 'committer %c\nauthor %a\n'
  
this catches all combinations, and is easier for scripting.

Right now, I have some scripts that have to munge log output with
regular expressions to strip out the "author:"  prefixes.


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-24 12:26                                   ` Han-Wen Nienhuys
@ 2006-11-24 12:41                                     ` Jakub Narebski
  2006-12-05 22:42                                     ` Johannes Schindelin
  2007-02-23  0:35                                     ` [PATCH for "next"] pretty-formats: add 'format:<string>' Johannes Schindelin
  2 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-24 12:41 UTC (permalink / raw)
  To: git

Han-Wen Nienhuys wrote:

> Jakub Narebski escreveu:
> 
>>>   - --pretty option with wholly uninformative options full, medium, 
>>> short, raw.  It's not even documented what each option does.
>> 
>> And 'oneline' and undocumented 'email'. True, git lacks documentation (and
>> this one of main complaints in git survey).
> 
> The recently posted patch documenting is an improvement, but why not
> add an option so you can do
> 
>   --format 'committer %c\nauthor %a\n'
>   
> this catches all combinations, and is easier for scripting.
> 
> Right now, I have some scripts that have to munge log output with
> regular expressions to strip out the "author:"  prefixes.

If we ever implemented this, I'd rather to separate what is now of format
parsing in git-for-each-ref (although I'd like to make it more like rpm's
--query-format argument, with %-n{header}, %[array] etc.) into separate
module, and reuse it for git-log and friends --pretty/--format handling.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-11-24 12:26                                   ` Han-Wen Nienhuys
  2006-11-24 12:41                                     ` Jakub Narebski
@ 2006-12-05 22:42                                     ` Johannes Schindelin
  2006-12-05 22:58                                       ` Junio C Hamano
  2007-02-23  0:35                                     ` [PATCH for "next"] pretty-formats: add 'format:<string>' Johannes Schindelin
  2 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-05 22:42 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: git

Hi,

On Fri, 24 Nov 2006, Han-Wen Nienhuys wrote:

> The recently posted patch documenting is an improvement, but why not
> add an option so you can do
> 
>   --format 'committer %c\nauthor %a\n'
>   
> this catches all combinations, and is easier for scripting.

Yes, it would be easier for scripting, and it would probably be relatively 
easy, what with the addition of interpolate.[ch] to git. However, it is 
work, and I am lazy.

What information would you like, anyway? IOW can you provide me with a 
list like this:

%c	committer
%a	author
%d	committer_date
...

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: Cleaning up git user-interface warts
  2006-12-05 22:42                                     ` Johannes Schindelin
@ 2006-12-05 22:58                                       ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-05 22:58 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, Han-Wen Nienhuys

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

> On Fri, 24 Nov 2006, Han-Wen Nienhuys wrote:
>
>> The recently posted patch documenting is an improvement, but why not
>> add an option so you can do
>> 
>>   --format 'committer %c\nauthor %a\n'
>>   
>> this catches all combinations, and is easier for scripting.
>
> Yes, it would be easier for scripting, and it would probably be relatively 
> easy, what with the addition of interpolate.[ch] to git. However, it is 
> work, and I am lazy.

Lazy is good when the details should not matter.  If some people
are scripting, they are fully capable of reading raw or fuller.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2006-12-13 21:35 Junio C Hamano
  2006-12-13 22:37 ` Andy Parkins
                   ` (3 more replies)
  0 siblings, 4 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-13 21:35 UTC (permalink / raw)
  To: git; +Cc: linux-kernel

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



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-13 21:35 What's in git.git (stable) Junio C Hamano
@ 2006-12-13 22:37 ` Andy Parkins
  2006-12-13 22:48   ` Jakub Narebski
                     ` (3 more replies)
  2006-12-16  9:14 ` [PATCH] git-clone: use wildcard specification for tracking branches Junio C Hamano
                   ` (2 subsequent siblings)
  3 siblings, 4 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-13 22:37 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

On Wednesday 2006, December 13 21:35, Junio C Hamano wrote:
> 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".

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
-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-13 22:37 ` Andy Parkins
@ 2006-12-13 22:48   ` Jakub Narebski
  2006-12-14  9:27     ` Andy Parkins
  2006-12-13 23:31   ` Junio C Hamano
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-12-13 22:48 UTC (permalink / raw)
  To: git

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

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


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-13 22:37 ` Andy Parkins
  2006-12-13 22:48   ` Jakub Narebski
@ 2006-12-13 23:31   ` Junio C Hamano
  2006-12-13 23:52     ` Peter Baumann
                       ` (4 more replies)
  2006-12-14  0:22   ` Johannes Schindelin
  2006-12-14 23:03   ` Shawn Pearce
  3 siblings, 5 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-13 23:31 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Andy Parkins <andyparkins@gmail.com> writes:

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

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.

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

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

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

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.

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

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.

>  Tell them if they
>  made a branch as well, which branch they are now on.

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.

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

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.

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

Yes.

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

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.

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

Perhaps.

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

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

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

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

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 has no output, whether it works or not

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

>  * git-cat-file is badly named.  git-cat-object would be slightly
>    better.

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

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.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-13 23:31   ` Junio C Hamano
@ 2006-12-13 23:52     ` Peter Baumann
  2006-12-14  0:16     ` Johannes Schindelin
                       ` (3 subsequent siblings)
  4 siblings, 0 replies; 601+ messages in thread
From: Peter Baumann @ 2006-12-13 23:52 UTC (permalink / raw)
  To: git

>>  * 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.
>
> 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.
>
>>  Tell them if they
>>  made a branch as well, which branch they are now on.
>
> 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.
>

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-13 23:31   ` Junio C Hamano
  2006-12-13 23:52     ` Peter Baumann
@ 2006-12-14  0:16     ` Johannes Schindelin
  2006-12-14  3:32       ` Nicolas Pitre
  2006-12-14  8:28     ` Andreas Ericsson
                       ` (2 subsequent siblings)
  4 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14  0:16 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Andy Parkins, git

Hi,

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

> Andy Parkins <andyparkins@gmail.com> writes:
> 
> >  * git-cat-file is badly named.  git-cat-object would be slightly
> >    better.
> 
> 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.

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,

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-13 22:37 ` Andy Parkins
  2006-12-13 22:48   ` Jakub Narebski
  2006-12-13 23:31   ` Junio C Hamano
@ 2006-12-14  0:22   ` Johannes Schindelin
  2006-12-14 10:21     ` Andy Parkins
  2006-12-14 23:03   ` Shawn Pearce
  3 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14  0:22 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git, Junio C Hamano

Hi,

On Wed, 13 Dec 2006, Andy Parkins wrote:

> On Wednesday 2006, December 13 21:35, Junio C Hamano wrote:
>
>  * 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.

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.

>  * 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?

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14  0:16     ` Johannes Schindelin
@ 2006-12-14  3:32       ` Nicolas Pitre
  2006-12-14  6:29         ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14  3:32 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, Andy Parkins, git

On Thu, 14 Dec 2006, Johannes Schindelin wrote:

> Hi,
> 
> On Wed, 13 Dec 2006, Junio C Hamano wrote:
> 
> > 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.
> 
> 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.

I think your approach is pretty sensible too.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14  3:32       ` Nicolas Pitre
@ 2006-12-14  6:29         ` Junio C Hamano
  2006-12-14  7:59           ` git-show, was " Johannes Schindelin
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14  6:29 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git, Johannes Schindelin

Nicolas Pitre <nico@cam.org> writes:

> On Thu, 14 Dec 2006, Johannes Schindelin 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.
>
> I think your approach is pretty sensible too.

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




^ permalink raw reply	[flat|nested] 601+ messages in thread

* git-show, was Re: What's in git.git (stable)
  2006-12-14  6:29         ` Junio C Hamano
@ 2006-12-14  7:59           ` Johannes Schindelin
  2006-12-14  8:28             ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14  7:59 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nicolas Pitre, git

Hi,

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

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

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: git-show, was Re: What's in git.git (stable)
  2006-12-14  7:59           ` git-show, was " Johannes Schindelin
@ 2006-12-14  8:28             ` Junio C Hamano
  2006-12-14 10:25               ` Johannes Schindelin
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14  8:28 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Nicolas Pitre, git

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

> Hi,
>
> On Wed, 13 Dec 2006, Junio C Hamano wrote:
>
>> 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').
>
> 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.

Sounds sensible.  Please make it so.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-13 23:31   ` Junio C Hamano
  2006-12-13 23:52     ` Peter Baumann
  2006-12-14  0:16     ` Johannes Schindelin
@ 2006-12-14  8:28     ` Andreas Ericsson
  2006-12-15 14:39       ` Jakub Narebski
  2006-12-14  9:59     ` Andy Parkins
  2006-12-14 23:52     ` Horst H. von Brand
  4 siblings, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-14  8:28 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Andy Parkins, git

Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
> 
>>  * git-add has no output, whether it works or not
> 
> "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.
> 

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                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-13 22:48   ` Jakub Narebski
@ 2006-12-14  9:27     ` Andy Parkins
  2006-12-14  9:36       ` Shawn Pearce
  0 siblings, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2006-12-14  9:27 UTC (permalink / raw)
  To: git

On Wednesday 2006 December 13 22:48, Jakub Narebski 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

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.

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

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
-- 
Dr Andy Parkins, M Eng (hons), MIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14  9:27     ` Andy Parkins
@ 2006-12-14  9:36       ` Shawn Pearce
  2006-12-14 10:03         ` Andy Parkins
  2006-12-14 17:06         ` Nicolas Pitre
  0 siblings, 2 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14  9:36 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Andy Parkins <andyparkins@gmail.com> wrote:
> 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?

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.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-13 23:31   ` Junio C Hamano
                       ` (2 preceding siblings ...)
  2006-12-14  8:28     ` Andreas Ericsson
@ 2006-12-14  9:59     ` Andy Parkins
  2006-12-14 10:21       ` Junio C Hamano
  2006-12-14 21:22       ` What's in git.git (stable) Junio C Hamano
  2006-12-14 23:52     ` Horst H. von Brand
  4 siblings, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14  9:59 UTC (permalink / raw)
  To: git

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

> I am moderately against making a command verbosely report when

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.

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

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.

> >  * git-branch is not verbose enough when creating a new
> The same comment applies here.

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.

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

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.

> Not interested in implementing that myself at all, though.

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

> >  Tell them if they
> >  made a branch as well, which branch they are now on.
>
> 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.

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.

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

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.

> 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

Of course; never discarding data always takes precedence.

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

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.

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

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.

> Perhaps under "[user] expert" control.

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

-- 
Dr Andy Parkins, M Eng (hons), MIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14  9:36       ` Shawn Pearce
@ 2006-12-14 10:03         ` Andy Parkins
  2006-12-14 17:06         ` Nicolas Pitre
  1 sibling, 0 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 10:03 UTC (permalink / raw)
  To: git

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

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

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?

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

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
-- 
Dr Andy Parkins, M Eng (hons), MIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14  0:22   ` Johannes Schindelin
@ 2006-12-14 10:21     ` Andy Parkins
  2006-12-14 10:51       ` Johannes Schindelin
  2006-12-14 17:23       ` Nicolas Pitre
  0 siblings, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 10:21 UTC (permalink / raw)
  To: git

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

> >  * 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.
>
> No. An inversion is the _opposite_. Not an undo.

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

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

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

> IMHO it is better for a newbie to see that _something_ is happening. A

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 cannot, and does not want to, understand exactly what is going on.

"newbie" doesn't mean "idiot".  Everybody wants to understand 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.

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
-- 
Dr Andy Parkins, M Eng (hons), MIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14  9:59     ` Andy Parkins
@ 2006-12-14 10:21       ` Junio C Hamano
  2006-12-14 11:36         ` Andy Parkins
  2006-12-15  4:07         ` Nicolas Pitre
  2006-12-14 21:22       ` What's in git.git (stable) Junio C Hamano
  1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 10:21 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Andy Parkins <andyparkins@gmail.com> writes:

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

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.

>> 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".
>
> I've always thought that programs that needed an expert/beginner split were 
> badly designed.

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.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: git-show, was Re: What's in git.git (stable)
  2006-12-14  8:28             ` Junio C Hamano
@ 2006-12-14 10:25               ` Johannes Schindelin
  0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14 10:25 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nicolas Pitre, git

Hi,

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

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Hi,
> >
> > On Wed, 13 Dec 2006, Junio C Hamano wrote:
> >
> >> 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').
> >
> > 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.
> 
> Sounds sensible.  Please make it so.

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 10:21     ` Andy Parkins
@ 2006-12-14 10:51       ` Johannes Schindelin
  2006-12-14 11:23         ` Andy Parkins
  2006-12-15  0:15         ` Horst H. von Brand
  2006-12-14 17:23       ` Nicolas Pitre
  1 sibling, 2 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14 10:51 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Hi,

On Thu, 14 Dec 2006, Andy Parkins wrote:

> On Thursday 2006 December 14 00:22, Johannes Schindelin wrote:
> 
> > >  * 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.
> >
> > No. An inversion is the _opposite_. Not an undo.
> 
> That's what I'm saying, we are applying the opposite of the given commit 
> - that commit is being inverted and applied again.

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

> > newbie cannot, and does not want to, understand exactly what is going 
> > on.
> 
> "newbie" doesn't mean "idiot".  Everybody wants to understand what is 
> going on.

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

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

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 10:51       ` Johannes Schindelin
@ 2006-12-14 11:23         ` Andy Parkins
  2006-12-14 11:27           ` Johannes Schindelin
  2006-12-15  0:15         ` Horst H. von Brand
  1 sibling, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 11:23 UTC (permalink / raw)
  To: git

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

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

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
-- 
Dr Andy Parkins, M Eng (hons), MIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 11:23         ` Andy Parkins
@ 2006-12-14 11:27           ` Johannes Schindelin
  2006-12-14 12:00             ` Andy Parkins
  0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14 11:27 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Hi,

On Thu, 14 Dec 2006, Andy Parkins wrote:

> On Thursday 2006 December 14 10:51, Johannes Schindelin wrote:
> 
> > 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 ;-)
> 
> 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.

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 10:21       ` Junio C Hamano
@ 2006-12-14 11:36         ` Andy Parkins
  2006-12-14 11:45           ` Shawn Pearce
  2006-12-15 15:26           ` Jakub Narebski
  2006-12-15  4:07         ` Nicolas Pitre
  1 sibling, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 11:36 UTC (permalink / raw)
  To: git

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

> You keep repeating that you want to know the object name of the

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

;-)

> But you never communicate with your own git repository using the
> SHA-1 object names when talking about commits you made recently

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

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

Okay.

> > I've always thought that programs that needed an expert/beginner split
> > were badly designed.
>
> There probably is a truth in that.  Let's not add verbosity
> unnecessarily.

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

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

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


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 11:36         ` Andy Parkins
@ 2006-12-14 11:45           ` Shawn Pearce
  2006-12-14 11:58             ` Carl Worth
                               ` (2 more replies)
  2006-12-15 15:26           ` Jakub Narebski
  1 sibling, 3 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 11:45 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Andy Parkins <andyparkins@gmail.com> wrote:
> 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

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 commit         # {4}
> $ git commit         # {3}
> $ git commit         # {2}
> $ git reset HEAD^^^  # {1}
> 
> "AGGGHHHHHH!  I meant HEAD^^"

  $ git reset HEAD@{4}

should give you what

  $ git reset HEAD^^

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 11:45           ` Shawn Pearce
@ 2006-12-14 11:58             ` Carl Worth
  2006-12-14 12:05               ` Shawn Pearce
  2006-12-14 17:47             ` What's in git.git (stable) Nicolas Pitre
  2006-12-14 21:58             ` Junio C Hamano
  2 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-12-14 11:58 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Andy Parkins, git

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On Thu, 14 Dec 2006 06:45:46 -0500, Shawn Pearce 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:

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 11:27           ` Johannes Schindelin
@ 2006-12-14 12:00             ` Andy Parkins
  2006-12-14 12:10               ` Shawn Pearce
  0 siblings, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 12:00 UTC (permalink / raw)
  To: git

On Thursday 2006 December 14 11:27, Johannes Schindelin 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).

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
-- 
Dr Andy Parkins, M Eng (hons), MIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 11:58             ` Carl Worth
@ 2006-12-14 12:05               ` Shawn Pearce
  2006-12-14 14:03                 ` reflog by default?, was " Johannes Schindelin
  2006-12-14 18:06                 ` Nicolas Pitre
  0 siblings, 2 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 12:05 UTC (permalink / raw)
  To: Carl Worth; +Cc: Andy Parkins, git

Carl Worth <cworth@cworth.org> 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.

Yes.  Which is why its in my ~/.gitconfig.  :-(
 
> I know several people have suggested they be enabled by
> default. What's the status of that suggestion?  Rejected? Just
> awaiting a patch?

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

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 12:00             ` Andy Parkins
@ 2006-12-14 12:10               ` Shawn Pearce
  2006-12-14 13:20                 ` Andy Parkins
  0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 12:10 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Andy Parkins <andyparkins@gmail.com> wrote:
> 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.

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.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 12:10               ` Shawn Pearce
@ 2006-12-14 13:20                 ` Andy Parkins
  0 siblings, 0 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 13:20 UTC (permalink / raw)
  To: git

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

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

Oh well; that pretty much settles it then.

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

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

Scratch that.

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* reflog by default?, was Re: What's in git.git (stable)
  2006-12-14 12:05               ` Shawn Pearce
@ 2006-12-14 14:03                 ` Johannes Schindelin
  2006-12-14 18:06                 ` Nicolas Pitre
  1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14 14:03 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Carl Worth, Andy Parkins, git

Hi,

On Thu, 14 Dec 2006, Shawn Pearce wrote:

>  * 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);

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14  9:36       ` Shawn Pearce
  2006-12-14 10:03         ` Andy Parkins
@ 2006-12-14 17:06         ` Nicolas Pitre
  2006-12-15 14:28           ` Jakub Narebski
  1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14 17:06 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Andy Parkins, git

On Thu, 14 Dec 2006, Shawn Pearce wrote:

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

git-add -v does output added files already.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 10:21     ` Andy Parkins
  2006-12-14 10:51       ` Johannes Schindelin
@ 2006-12-14 17:23       ` Nicolas Pitre
  2006-12-14 21:02         ` Andy Parkins
  1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14 17:23 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

On Thu, 14 Dec 2006, Andy Parkins wrote:

> > 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.
> 
> I'm not disputing that the /operation/ is useful, I'm arguing that it is 
> incorrectly named.

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.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 11:45           ` Shawn Pearce
  2006-12-14 11:58             ` Carl Worth
@ 2006-12-14 17:47             ` Nicolas Pitre
  2006-12-14 21:58             ` Junio C Hamano
  2 siblings, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14 17:47 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Andy Parkins, git

On Thu, 14 Dec 2006, Shawn Pearce wrote:

> Andy Parkins <andyparkins@gmail.com> wrote:
> > 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
> 
> At this point I usually try to politely suggest that users do:
> 
>   git repo-config --global core.logAllRefUpdates true
> 

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.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 12:05               ` Shawn Pearce
  2006-12-14 14:03                 ` reflog by default?, was " Johannes Schindelin
@ 2006-12-14 18:06                 ` Nicolas Pitre
  2006-12-14 19:52                   ` Junio C Hamano
  2006-12-14 19:58                   ` [PATCH] Enable reflogs by default in all repositories Shawn O. Pearce
  1 sibling, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14 18:06 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Carl Worth, Andy Parkins, git

On Thu, 14 Dec 2006, Shawn Pearce wrote:

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

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.

>  * 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);

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?

> 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'd say screw that.  The solution should really be this patch:

diff --git a/environment.c b/environment.c
index 84d870c..98275b2 100644
--- a/environment.c
+++ b/environment.c
@@ -15,7 +15,7 @@ int use_legacy_headers = 1;
 int trust_executable_bit = 1;
 int assume_unchanged;
 int prefer_symlink_refs;
-int log_all_ref_updates;
+int log_all_ref_updates = 1;
 int warn_ambiguous_refs = 1;
 int repository_format_version;
 char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";

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

Well I must have missed it.

But unless there is real harm to have reflog enabled even when you don't 
need it I really think the default should be set to enabled.



^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 18:06                 ` Nicolas Pitre
@ 2006-12-14 19:52                   ` Junio C Hamano
  2006-12-14 20:02                     ` Shawn Pearce
  2006-12-14 20:17                     ` Nicolas Pitre
  2006-12-14 19:58                   ` [PATCH] Enable reflogs by default in all repositories Shawn O. Pearce
  1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 19:52 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git, Shawn Pearce

Nicolas Pitre <nico@cam.org> writes:

> I'd say screw that.  The solution should really be this patch:
>
> diff --git a/environment.c b/environment.c
> index 84d870c..98275b2 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -15,7 +15,7 @@ int use_legacy_headers = 1;
>  int trust_executable_bit = 1;
>  int assume_unchanged;
>  int prefer_symlink_refs;
> -int log_all_ref_updates;
> +int log_all_ref_updates = 1;
>  int warn_ambiguous_refs = 1;
>  int repository_format_version;
>  char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
>

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.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* [PATCH] Enable reflogs by default in all repositories.
  2006-12-14 18:06                 ` Nicolas Pitre
  2006-12-14 19:52                   ` Junio C Hamano
@ 2006-12-14 19:58                   ` Shawn O. Pearce
  1 sibling, 0 replies; 601+ messages in thread
From: Shawn O. Pearce @ 2006-12-14 19:58 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Nicolas Pitre, Carl Worth, Andy Parkins

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

diff --git a/Documentation/config.txt b/Documentation/config.txt
index a3587f8..e093bcd 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -80,7 +80,8 @@ core.logAllRefUpdates::
 
 	This information can be used to determine what commit
 	was the tip of a branch "2 days ago".  This value is
-	false by default (no automated creation of log files).
+	true by default to activate automated creation of log
+	files for all branch heads.
 
 core.repositoryFormatVersion::
 	Internal variable identifying the repository format and layout
diff --git a/environment.c b/environment.c
index 84d870c..98275b2 100644
--- a/environment.c
+++ b/environment.c
@@ -15,7 +15,7 @@ int use_legacy_headers = 1;
 int trust_executable_bit = 1;
 int assume_unchanged;
 int prefer_symlink_refs;
-int log_all_ref_updates;
+int log_all_ref_updates = 1;
 int warn_ambiguous_refs = 1;
 int repository_format_version;
 char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
-- 

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 19:52                   ` Junio C Hamano
@ 2006-12-14 20:02                     ` Shawn Pearce
  2006-12-14 20:22                       ` Nicolas Pitre
                                         ` (2 more replies)
  2006-12-14 20:17                     ` Nicolas Pitre
  1 sibling, 3 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 20:02 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nicolas Pitre, git

Junio C Hamano <junkio@cox.net> wrote:
> Nicolas Pitre <nico@cam.org> writes:
> 
> > I'd say screw that.  The solution should really be this patch:
> >
> > diff --git a/environment.c b/environment.c
> > index 84d870c..98275b2 100644
> > --- a/environment.c
> > +++ b/environment.c
> > @@ -15,7 +15,7 @@ int use_legacy_headers = 1;
> >  int trust_executable_bit = 1;
> >  int assume_unchanged;
> >  int prefer_symlink_refs;
> > -int log_all_ref_updates;
> > +int log_all_ref_updates = 1;
> >  int warn_ambiguous_refs = 1;
> >  int repository_format_version;
> >  char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
> >
> 
> That changes what the command does to existing repositories,
> which is somewhat impolite.

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 am not opposed too much to an updated version of the tool that
> sets the configuration on by default for newly created
> repositories, though.

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.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 19:52                   ` Junio C Hamano
  2006-12-14 20:02                     ` Shawn Pearce
@ 2006-12-14 20:17                     ` Nicolas Pitre
  2006-12-14 20:50                       ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14 20:17 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Shawn Pearce

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

> Nicolas Pitre <nico@cam.org> writes:
> 
> > I'd say screw that.  The solution should really be this patch:
> >
> > diff --git a/environment.c b/environment.c
> > index 84d870c..98275b2 100644
> > --- a/environment.c
> > +++ b/environment.c
> > @@ -15,7 +15,7 @@ int use_legacy_headers = 1;
> >  int trust_executable_bit = 1;
> >  int assume_unchanged;
> >  int prefer_symlink_refs;
> > -int log_all_ref_updates;
> > +int log_all_ref_updates = 1;
> >  int warn_ambiguous_refs = 1;
> >  int repository_format_version;
> >  char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
> >
> 
> That changes what the command does to existing repositories,
> which is somewhat impolite.

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.

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

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.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 20:02                     ` Shawn Pearce
@ 2006-12-14 20:22                       ` Nicolas Pitre
  2006-12-14 20:35                       ` Junio C Hamano
  2006-12-14 21:55                       ` Andreas Ericsson
  2 siblings, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14 20:22 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Junio C Hamano, git

On Thu, 14 Dec 2006, Shawn Pearce wrote:

> Junio C Hamano <junkio@cox.net> wrote:
> > That changes what the command does to existing repositories,
> > which is somewhat impolite.
> 
> 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.

I concur entirely.

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

I certainly don't.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 20:02                     ` Shawn Pearce
  2006-12-14 20:22                       ` Nicolas Pitre
@ 2006-12-14 20:35                       ` Junio C Hamano
  2006-12-14 22:41                         ` [PATCH] Enable reflogs by default in any repository with a working directory Shawn O. Pearce
  2006-12-14 22:44                         ` What's in git.git (stable) Shawn Pearce
  2006-12-14 21:55                       ` Andreas Ericsson
  2 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 20:35 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: git

Shawn Pearce <spearce@spearce.org> writes:

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

When you talk about potential breakage for existing users, you
should not be asking people on THIS list.  You instead should
talk with or at least think about people on linux-kernel, x.org
and wine people, and possibly others.  git is maturing, and we
cannot expect that most of the users are paying attention to
what is happening on this list anymore.

I 100% agree that it makes sense to have reflog enabled for a
repository with an associated worktree.  I would say that we do
not even need it to be conditional on the configuration variable
for such a repository.

My answer to your question is:

	kernel.org:/pub/scm/

I would REALLY be worried to have reflog enabled at a public
distribution point where the only ways the owners interact with
it daily are 'git push' and 'git pull'.  As you mentioned, there
is one extra potential receive-pack failure, and in general it
is one more thing that can go wrong, and hard to notice breakage
because it is on the other side of the connection.

Worse yet, there is no easy way to garbage collect.  Even in an
end-user repository with a worktree, the only way to garbage
collect older reflog entries is to edit the reflog files to
remove the top part.

Maybe a check to say if $GIT_DIR is ".git" or ends with "/.git"
then enable it and otherwise honor the configuration variable,
without changing the default in the code (with your patch) nor
in the default configuration ("enable for new repositories" as I
suggested) might be a workable compromise.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 20:17                     ` Nicolas Pitre
@ 2006-12-14 20:50                       ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 20:50 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git, Shawn Pearce

Nicolas Pitre <nico@cam.org> writes:

>> That changes what the command does to existing repositories,
>> which is somewhat impolite.
>
> You must be kidding, aren't you?

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.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 17:23       ` Nicolas Pitre
@ 2006-12-14 21:02         ` Andy Parkins
  0 siblings, 0 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 21:02 UTC (permalink / raw)
  To: git

On Thursday 2006, December 14 17:23, Nicolas Pitre 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.

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
-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14  9:59     ` Andy Parkins
  2006-12-14 10:21       ` Junio C Hamano
@ 2006-12-14 21:22       ` Junio C Hamano
  2006-12-14 22:55         ` Andy Parkins
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 21:22 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Andy Parkins <andyparkins@gmail.com> writes:

>> >  Tell them if they
>> >  made a branch as well, which branch they are now on.
>>
>> 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.
>
> 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.

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.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 20:02                     ` Shawn Pearce
  2006-12-14 20:22                       ` Nicolas Pitre
  2006-12-14 20:35                       ` Junio C Hamano
@ 2006-12-14 21:55                       ` Andreas Ericsson
  2006-12-15 21:55                         ` Junio C Hamano
  2 siblings, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-14 21:55 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Junio C Hamano, Nicolas Pitre, git

Shawn Pearce wrote:
> 
> 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.
> 

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                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 11:45           ` Shawn Pearce
  2006-12-14 11:58             ` Carl Worth
  2006-12-14 17:47             ` What's in git.git (stable) Nicolas Pitre
@ 2006-12-14 21:58             ` Junio C Hamano
  2006-12-14 22:50               ` Andy Parkins
  2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 21:58 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: git, Andy Parkins

Shawn Pearce <spearce@spearce.org> writes:

> Andy Parkins <andyparkins@gmail.com> wrote:
>> 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
>
> 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 commit         # {4}
>> $ git commit         # {3}
>> $ git commit         # {2}
>> $ git reset HEAD^^^  # {1}
>> 
>> "AGGGHHHHHH!  I meant HEAD^^"
>
>   $ git reset HEAD@{4}
>
> should give you what
>
>   $ git reset HEAD^^
>
> would have given had you not added the extra ^.  :-)

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.


---

diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index fb1a400..559bb18 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -6,7 +6,7 @@
 #include "builtin.h"
 
 static const char show_branch_usage[] =
-"git-show-branch [--sparse] [--current] [--all] [--heads] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [--topics] [<refs>...]";
+"git-show-branch [--sparse] [--current] [--all] [--heads] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [--topics] [<refs>...] | --reflog[=n] <branch>";
 
 static int default_num;
 static int default_alloc;
@@ -17,6 +17,8 @@ static const char **default_arg;
 #define REV_SHIFT	 2
 #define MAX_REVS	(FLAG_BITS - REV_SHIFT) /* should not exceed bits_per_int - REV_SHIFT */
 
+#define DEFAULT_REFLOG	4
+
 static struct commit *interesting(struct commit_list *list)
 {
 	while (list) {
@@ -570,6 +572,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
 	int head_at = -1;
 	int topics = 0;
 	int dense = 1;
+	int reflog = 0;
 
 	git_config(git_show_branch_config);
 
@@ -615,6 +618,15 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
 			dense = 0;
 		else if (!strcmp(arg, "--date-order"))
 			lifo = 0;
+		else if (!strcmp(arg, "--reflog")) {
+			reflog = DEFAULT_REFLOG;
+		}
+		else if (!strncmp(arg, "--reflog=", 9)) {
+			char *end;
+			reflog = strtoul(arg + 9, &end, 10);
+			if (*end != '\0')
+				die("unrecognized reflog count '%s'", arg + 9);
+		}
 		else
 			usage(show_branch_usage);
 		ac--; av++;
@@ -622,7 +634,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
 	ac--; av++;
 
 	/* Only one of these is allowed */
-	if (1 < independent + merge_base + (extra != 0))
+	if (1 < independent + merge_base + (extra != 0) + (!!reflog))
 		usage(show_branch_usage);
 
 	/* If nothing is specified, show all branches by default */
@@ -631,9 +643,22 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
 
 	if (all_heads + all_tags)
 		snarf_refs(all_heads, all_tags);
-	while (0 < ac) {
-		append_one_rev(*av);
-		ac--; av++;
+	if (reflog) {
+		int reflen;
+		if (!ac)
+			die("--reflog option needs one branch name");
+		reflen = strlen(*av);
+		for (i = 0; i < reflog; i++) {
+			char *name = xmalloc(reflen + 20);
+			sprintf(name, "%s@{%d}", *av, i);
+			append_one_rev(name);
+		}
+	}
+	else {
+		while (0 < ac) {
+			append_one_rev(*av);
+			ac--; av++;
+		}
 	}
 
 	head_p = resolve_ref("HEAD", head_sha1, 1, NULL);





^ permalink raw reply related	[flat|nested] 601+ messages in thread

* [PATCH] Enable reflogs by default in any repository with a working directory.
  2006-12-14 20:35                       ` Junio C Hamano
@ 2006-12-14 22:41                         ` Shawn O. Pearce
  2006-12-14 23:10                           ` J. Bruce Fields
  2006-12-15  0:13                           ` Johannes Schindelin
  2006-12-14 22:44                         ` What's in git.git (stable) Shawn Pearce
  1 sibling, 2 replies; 601+ messages in thread
From: Shawn O. Pearce @ 2006-12-14 22:41 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

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.

We only enable reflogs in repositories that have a working directory
associated with them, as shared/bare repositories do not have
an easy means to prune away old log entries, or may fail logging
entirely if the user's gecos information is not valid during a push.
This heuristic was suggested on the mailing list by Junio.

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 |    7 +++++--
 builtin-init-db.c        |    4 ++++
 cache.h                  |    1 +
 environment.c            |    9 +++++++++
 4 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index a3587f8..8abb082 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -79,8 +79,11 @@ core.logAllRefUpdates::
 	file is automatically created for branch heads.
 
 	This information can be used to determine what commit
-	was the tip of a branch "2 days ago".  This value is
-	false by default (no automated creation of log files).
+	was the tip of a branch "2 days ago".
+
+	This value is true by default in a repository that has
+	a working directory associated with it, and false by
+	default in a bare repository.
 
 core.repositoryFormatVersion::
 	Internal variable identifying the repository format and layout
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 235a0ee..214fc8e 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -239,6 +239,10 @@ static void create_default_files(const char *git_dir, const char *template_path)
 		git_config_set("core.filemode",
 			       filemode ? "true" : "false");
 	}
+
+	/* Enable logAllRefUpdates if a working tree is attached */
+	git_config_set("core.logallrefupdates",
+		!is_bare_git_dir(git_dir) ? "true" : "false");
 }
 
 static const char init_db_usage[] =
diff --git a/cache.h b/cache.h
index f2ec5c8..2d3df98 100644
--- a/cache.h
+++ b/cache.h
@@ -123,6 +123,7 @@ extern int cache_errno;
 #define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
 #define GRAFT_ENVIRONMENT "GIT_GRAFT_FILE"
 
+extern int is_bare_git_dir(const char *dir);
 extern const char *get_git_dir(void);
 extern char *get_object_directory(void);
 extern char *get_refs_directory(void);
diff --git a/environment.c b/environment.c
index 84d870c..b7256eb 100644
--- a/environment.c
+++ b/environment.c
@@ -48,6 +48,15 @@ static void setup_git_env(void)
 	git_graft_file = getenv(GRAFT_ENVIRONMENT);
 	if (!git_graft_file)
 		git_graft_file = xstrdup(git_path("info/grafts"));
+	log_all_ref_updates = !is_bare_git_dir(git_dir);
+}
+
+int is_bare_git_dir (const char *dir)
+{
+	if (!strcmp(dir, DEFAULT_GIT_DIR_ENVIRONMENT))
+		return 0;
+	const char *s = strrchr(dir, '/');
+	return !s || strcmp(s + 1, DEFAULT_GIT_DIR_ENVIRONMENT);
 }
 
 const char *get_git_dir(void)
-- 

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 20:35                       ` Junio C Hamano
  2006-12-14 22:41                         ` [PATCH] Enable reflogs by default in any repository with a working directory Shawn O. Pearce
@ 2006-12-14 22:44                         ` Shawn Pearce
  1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 22:44 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <junkio@cox.net> wrote:
> Maybe a check to say if $GIT_DIR is ".git" or ends with "/.git"
> then enable it and otherwise honor the configuration variable,
> without changing the default in the code (with your patch) nor
> in the default configuration ("enable for new repositories" as I
> suggested) might be a workable compromise.

See my latest patch.  Though that patch also sets the value in the
config file, much as core.filemode is also set in the config file,
based on the guess determined by init-db at the time it was executed.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 21:58             ` Junio C Hamano
@ 2006-12-14 22:50               ` Andy Parkins
  2006-12-15 15:38                 ` Jakub Narebski
  0 siblings, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 22:50 UTC (permalink / raw)
  To: git

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

> 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

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

-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 21:22       ` What's in git.git (stable) Junio C Hamano
@ 2006-12-14 22:55         ` Andy Parkins
  2006-12-14 23:46           ` Junio C Hamano
  2006-12-14 23:53           ` Johannes Schindelin
  0 siblings, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 22:55 UTC (permalink / raw)
  To: git

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

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

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

-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-13 22:37 ` Andy Parkins
                     ` (2 preceding siblings ...)
  2006-12-14  0:22   ` Johannes Schindelin
@ 2006-12-14 23:03   ` Shawn Pearce
  2006-12-15 16:16     ` Jakub Narebski
  3 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 23:03 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git, Junio C Hamano

Andy Parkins <andyparkins@gmail.com> wrote:
>  * git-show-branch output is cryptic.

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

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
  2006-12-14 22:41                         ` [PATCH] Enable reflogs by default in any repository with a working directory Shawn O. Pearce
@ 2006-12-14 23:10                           ` J. Bruce Fields
  2006-12-14 23:18                             ` Shawn Pearce
  2006-12-15  0:13                           ` Johannes Schindelin
  1 sibling, 1 reply; 601+ messages in thread
From: J. Bruce Fields @ 2006-12-14 23:10 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: Junio C Hamano, git

On Thu, Dec 14, 2006 at 05:41:17PM -0500, Shawn O. Pearce wrote:
> 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).

Stupid question--I assume a mention in the reflog doesn't count as a
real reference to an object, so they won't save you in the case when you
pruned recently?


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
  2006-12-14 23:10                           ` J. Bruce Fields
@ 2006-12-14 23:18                             ` Shawn Pearce
  2006-12-14 23:42                               ` J. Bruce Fields
  0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 23:18 UTC (permalink / raw)
  To: J. Bruce Fields; +Cc: Junio C Hamano, git

"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Thu, Dec 14, 2006 at 05:41:17PM -0500, Shawn O. Pearce wrote:
> > 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).
> 
> Stupid question--I assume a mention in the reflog doesn't count as a
> real reference to an object, so they won't save you in the case when you
> pruned recently?

Not a stupid question.  Your assumption is correct, its not a real
reference, so prune will remove things that the log mentions but
that refs don't currently mention.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
  2006-12-14 23:18                             ` Shawn Pearce
@ 2006-12-14 23:42                               ` J. Bruce Fields
  0 siblings, 0 replies; 601+ messages in thread
From: J. Bruce Fields @ 2006-12-14 23:42 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Junio C Hamano, git

On Thu, Dec 14, 2006 at 06:18:32PM -0500, Shawn Pearce wrote:
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > Stupid question--I assume a mention in the reflog doesn't count as a
> > real reference to an object, so they won't save you in the case when you
> > pruned recently?
> 
> Not a stupid question.  Your assumption is correct, its not a real
> reference, so prune will remove things that the log mentions but
> that refs don't currently mention.

OK, thanks.  So we just need to make sure that's documented someplace.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 22:55         ` Andy Parkins
@ 2006-12-14 23:46           ` Junio C Hamano
  2006-12-15  8:58             ` Andy Parkins
  2006-12-14 23:53           ` Johannes Schindelin
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 23:46 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Andy Parkins <andyparkins@gmail.com> writes:

> On Thursday 2006, December 14 21:22, Junio C Hamano wrote:
>
>> 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".
>
> There truly is something wrong with me.

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'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 :-)

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.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-13 23:31   ` Junio C Hamano
                       ` (3 preceding siblings ...)
  2006-12-14  9:59     ` Andy Parkins
@ 2006-12-14 23:52     ` Horst H. von Brand
  2006-12-15 10:53       ` Jakub Narebski
  4 siblings, 1 reply; 601+ messages in thread
From: Horst H. von Brand @ 2006-12-14 23:52 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Andy Parkins, git

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

[...]

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

Nodz. Just hoary Unix tradition.

> Perhaps under "[user] expert" control.

Nope. You'd be surprised what kind of people consider themselves
"experts"... I'd prefer adding -v/--verbose flags to all commands (if
nothing else, for symmetry's sake), have a '[default] --verbose' controlling
this across the board (perhaps also '[default "command"] --verbose'), with
'[default]' setting default switches.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 22:55         ` Andy Parkins
  2006-12-14 23:46           ` Junio C Hamano
@ 2006-12-14 23:53           ` Johannes Schindelin
  1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14 23:53 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Hi,

On Thu, 14 Dec 2006, Andy Parkins wrote:

> On Thursday 2006, December 14 21:22, Junio C Hamano wrote:
> 
> > 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".
> 
> 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?

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

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

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

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
  2006-12-14 22:41                         ` [PATCH] Enable reflogs by default in any repository with a working directory Shawn O. Pearce
  2006-12-14 23:10                           ` J. Bruce Fields
@ 2006-12-15  0:13                           ` Johannes Schindelin
  2006-12-15  0:20                             ` Shawn Pearce
  1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-15  0:13 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: Junio C Hamano, git

Hi,

On Thu, 14 Dec 2006, Shawn O. Pearce wrote:

> +int is_bare_git_dir (const char *dir)
> +{
> +	if (!strcmp(dir, DEFAULT_GIT_DIR_ENVIRONMENT))
> +		return 0;
> +	const char *s = strrchr(dir, '/');
> +	return !s || strcmp(s + 1, DEFAULT_GIT_DIR_ENVIRONMENT);
>  }

This function does not really determine if the repo is bare. I have no 
better name for it, though.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 10:51       ` Johannes Schindelin
  2006-12-14 11:23         ` Andy Parkins
@ 2006-12-15  0:15         ` Horst H. von Brand
  2006-12-15  0:23           ` Johannes Schindelin
  1 sibling, 1 reply; 601+ messages in thread
From: Horst H. von Brand @ 2006-12-15  0:15 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Andy Parkins, git

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 14 Dec 2006, Andy Parkins wrote:

[...]

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

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

So? This is meant to be a /tool/. Not wanting to know how it works doesn't
make one an idiot, it is just economy.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
  2006-12-15  0:13                           ` Johannes Schindelin
@ 2006-12-15  0:20                             ` Shawn Pearce
  2006-12-15 21:55                               ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-15  0:20 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
> 
> On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
> 
> > +int is_bare_git_dir (const char *dir)
> > +{
> > +	if (!strcmp(dir, DEFAULT_GIT_DIR_ENVIRONMENT))
> > +		return 0;
> > +	const char *s = strrchr(dir, '/');
> > +	return !s || strcmp(s + 1, DEFAULT_GIT_DIR_ENVIRONMENT);
> >  }
> 
> This function does not really determine if the repo is bare. I have no 
> better name for it, though.

guess_if_bare_git_dir ?

I struggled to name that thing because it can't really tell, its just
guessing... but it is going to be right most of the time.  Of course
I'm sure there's some Git user somewhere who will confuse it.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15  0:15         ` Horst H. von Brand
@ 2006-12-15  0:23           ` Johannes Schindelin
  0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-15  0:23 UTC (permalink / raw)
  To: Horst H. von Brand; +Cc: Andy Parkins, git

Hi,

On Thu, 14 Dec 2006, Horst H. von Brand wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 14 Dec 2006, Andy Parkins wrote:
> 
> [...]
> 
> > > "newbie" doesn't mean "idiot".  Everybody wants to understand what is 
> > > going on.
> 
> > I heartly disagree. I saw so many faces _begging_ me to just say _what_ to 
> > do, not _why_, and quickly, please.
> 
> So? This is meant to be a /tool/. Not wanting to know how it works doesn't
> make one an idiot, it is just economy.

My thoughts exactly.

And I did not want to force understanding onto the users. Heck, I even 
know people who use git and do not know about the index! They don't need 
to, either.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 10:21       ` Junio C Hamano
  2006-12-14 11:36         ` Andy Parkins
@ 2006-12-15  4:07         ` Nicolas Pitre
  2006-12-15  4:15           ` [PATCH] make commit message a little more consistent and conforting Nicolas Pitre
  1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15  4:07 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Andy Parkins, git

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

> Andy Parkins <andyparkins@gmail.com> writes:
> 
> > $ 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.
> 
> 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.

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.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* [PATCH] make commit message a little more consistent and conforting
  2006-12-15  4:07         ` Nicolas Pitre
@ 2006-12-15  4:15           ` Nicolas Pitre
  2006-12-15  4:24             ` Shawn Pearce
  0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15  4:15 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Andy Parkins, git

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>

---

diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 47505aa..1c31159 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -336,17 +336,9 @@ $ commit=$(echo 'Initial commit' | git-commit-tree $tree)
 $ git-update-ref HEAD $commit
 ------------------------------------------------
 
-which will say:
-
-----------------
-Committing initial tree 8988da15d077d4829fc51d8544c097def6644dbb
-----------------
-
-just to warn you about the fact that it created a totally new commit
-that is not related to anything else. Normally you do this only *once*
-for a project ever, and all later commits will be parented on top of an
-earlier commit, and you'll never see this "Committing initial tree"
-message ever again.
+In this case this creates a totally new commit that is not related to
+anything else. Normally you do this only *once* for a project ever, and
+all later commits will be parented on top of an earlier commit.
 
 Again, normally you'd never actually do this by hand. There is a
 helpful script called `git commit` that will do all of this for you. So
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 97d66ef..0b74cd7 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -113,6 +113,9 @@ but can be used to amend a merge commit.
 	as well.  This is usually not what you want unless you
 	are concluding a conflicted merge.
 
+-q|--quiet::
+	Supress commit summary message.
+
 \--::
 	Do not interpret any more arguments as options.
 
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
index 6389de5..8606381 100644
--- a/Documentation/tutorial-2.txt
+++ b/Documentation/tutorial-2.txt
@@ -22,14 +22,14 @@ defaulting to local storage area
 $ echo 'hello world' > file.txt
 $ git add .
 $ git commit -a -m "initial commit"
-Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe
+Created initial commit 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
  create mode 100644 file.txt
 $ echo 'hello world!' >file.txt
 $ git commit -a -m "add emphasis"
+Created commit c4d59f390b9cfd4318117afde11d601c1085f241
 ------------------------------------------------
 
-What are the 40 digits of hex that git responded to the first commit
-with?
+What are the 40 digits of hex that git responded to the commit with?
 
 We saw in part one of the tutorial that commits have names like this.
 It turns out that every object in the git history is stored under
@@ -39,13 +39,25 @@ the same data twice (since identical data is given an identical SHA1
 name), and that the contents of a git object will never change (since
 that would change the object's name as well).
 
+It is expected that the content of the commit object you created while
+following the example above generates a different SHA1 hash than
+the one shown above because the commit object records the time when
+it was created and the name of the person performing the commit.
+
 We can ask git about this particular object with the cat-file
-command--just cut-and-paste from the reply to the initial commit, to
-save yourself typing all 40 hex digits:
+command. Don't copy the 40 hex digits from this example but use those
+from your own version. Note that you can shorten it to only a few
+characters to save yourself typing all 40 hex digits:
 
 ------------------------------------------------
-$ git cat-file -t 92b8b694ffb1675e5975148e1121810081dbdffe
-tree
+$ git-cat-file -t 54196cc2
+commit
+$ git-cat-file commit 54196cc2
+tree 92b8b694ffb1675e5975148e1121810081dbdffe
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+
+initial commit
 ------------------------------------------------
 
 A tree can refer to one or more "blob" objects, each corresponding to
@@ -102,8 +114,7 @@ $ find .git/objects/
 
 and the contents of these files is just the compressed data plus a
 header identifying their length and their type.  The type is either a
-blob, a tree, a commit, or a tag.  We've seen a blob and a tree now,
-so next we should look at a commit.
+blob, a tree, a commit, or a tag.
 
 The simplest commit to find is the HEAD commit, which we can find
 from .git/HEAD:
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index e2e690a..856f3cd 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -107,8 +107,6 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
 		if (new_parent(parents))
 			parents++;
 	}
-	if (!parents)
-		fprintf(stderr, "Committing initial tree %s\n", argv[1]);
 
 	init_buffer(&buffer, &size);
 	add_buffer(&buffer, &size, "tree %s\n", sha1_to_hex(tree_sha1));
diff --git a/git-commit.sh b/git-commit.sh
index 05828bb..395bcd2 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -80,6 +80,7 @@ no_edit=
 log_given=
 log_message=
 verify=t
+quiet=
 verbose=
 signoff=
 force_author=
@@ -241,6 +242,10 @@ $1"
 		signoff=t
 		shift
 		;;
+	-q|--q|--qu|--qui|--quie|--quiet)
+		quiet=t
+		shift
+		;;
 	-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
 		verbose=t
 		shift
@@ -615,11 +620,17 @@ then
 	git-rerere
 fi
 
-if test -x "$GIT_DIR"/hooks/post-commit && test "$ret" = 0
+if test "$ret" = 0
 then
-	"$GIT_DIR"/hooks/post-commit
+	if test -x "$GIT_DIR"/hooks/post-commit 
+	then
+		"$GIT_DIR"/hooks/post-commit
+	fi
+	if test -z "$quiet"
+	then
+		echo "Created${initial_commit:+ initial} commit $commit"
+		git-diff-tree --summary --root --no-commit-id HEAD
+	fi
 fi
 
-test "$ret" = 0 && git-diff-tree --summary --root --no-commit-id HEAD
-

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: [PATCH] make commit message a little more consistent and conforting
  2006-12-15  4:15           ` [PATCH] make commit message a little more consistent and conforting Nicolas Pitre
@ 2006-12-15  4:24             ` Shawn Pearce
  2006-12-15  8:34               ` Andreas Ericsson
  0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-15  4:24 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Junio C Hamano, Andy Parkins, git

Nicolas Pitre <nico@cam.org> wrote:
> 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.

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.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] make commit message a little more consistent and conforting
  2006-12-15  4:24             ` Shawn Pearce
@ 2006-12-15  8:34               ` Andreas Ericsson
  2006-12-15 15:09                 ` Shawn Pearce
  0 siblings, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-15  8:34 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git

Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
>> 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.
> 
> 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.
> 

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

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 23:46           ` Junio C Hamano
@ 2006-12-15  8:58             ` Andy Parkins
  2006-12-15  9:55               ` Raimund Bauer
  2006-12-15 21:55               ` Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-15  8:58 UTC (permalink / raw)
  To: git

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

> > There truly is something wrong with me.
>
> I did not mean it that way.  I only took it as a sign that maybe

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

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

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

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

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.

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

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

-- 
Dr Andy Parkins, M Eng (hons), MIEE

^ permalink raw reply	[flat|nested] 601+ messages in thread

* RE: What's in git.git (stable)
  2006-12-15  8:58             ` Andy Parkins
@ 2006-12-15  9:55               ` Raimund Bauer
  2006-12-15 21:55               ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Raimund Bauer @ 2006-12-15  9:55 UTC (permalink / raw)
  To: 'Andy Parkins', git

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

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

-- 
best regards

  Ray

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 23:52     ` Horst H. von Brand
@ 2006-12-15 10:53       ` Jakub Narebski
  0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 10:53 UTC (permalink / raw)
  To: git

Horst H. von Brand wrote:

>> Perhaps under "[user] expert" control.
> 
> Nope. You'd be surprised what kind of people consider themselves
> "experts"... I'd prefer adding -v/--verbose flags to all commands (if
> nothing else, for symmetry's sake), have a '[default] --verbose' controlling
> this across the board (perhaps also '[default "command"] --verbose'), with
> '[default]' setting default switches.

Nice idea... but configuration variables have to have name.
So it would be 

  $ git repo-config defaults.command --verbose

resulting in

  [defaults]
        command = --verbose
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 17:06         ` Nicolas Pitre
@ 2006-12-15 14:28           ` Jakub Narebski
  0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 14:28 UTC (permalink / raw)
  To: git

Nicolas Pitre wrote:

> On Thu, 14 Dec 2006, Shawn Pearce wrote:
> 
>> 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.
> 
> git-add -v does output added files already.

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

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14  8:28     ` Andreas Ericsson
@ 2006-12-15 14:39       ` Jakub Narebski
  0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 14:39 UTC (permalink / raw)
  To: git

Andreas Ericsson wrote:
> Junio C Hamano wrote:
>> Andy Parkins <andyparkins@gmail.com> writes:
>> 
>>>  * git-add has no output, whether it works or not
>> 
>> "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.
>> 
> 
> 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.

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


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] make commit message a little more consistent and conforting
  2006-12-15  8:34               ` Andreas Ericsson
@ 2006-12-15 15:09                 ` Shawn Pearce
  2006-12-15 15:32                   ` Andreas Ericsson
  2006-12-15 16:01                   ` Nicolas Pitre
  0 siblings, 2 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-15 15:09 UTC (permalink / raw)
  To: Andreas Ericsson; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git

Andreas Ericsson <ae@op5.se> wrote:
> Shawn Pearce wrote:
> >Nicolas Pitre <nico@cam.org> wrote:
> >>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.
> >
> >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.
> >
> 
> diffstats can be huge though. I'd rather have those only with -v option.

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.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 11:36         ` Andy Parkins
  2006-12-14 11:45           ` Shawn Pearce
@ 2006-12-15 15:26           ` Jakub Narebski
  2006-12-15 15:30             ` Nicolas Pitre
  1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 15:26 UTC (permalink / raw)
  To: git

Andy Parkins wrote:

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

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

>> But you never communicate with your own git repository using the
>> SHA-1 object names when talking about commits you made recently
> 
> 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

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.

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

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

>>> I've always thought that programs that needed an expert/beginner split
>>> were badly designed.
>>
>> There probably is a truth in that.  Let's not add verbosity
>> unnecessarily.
> 
> 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. :-)

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?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 15:26           ` Jakub Narebski
@ 2006-12-15 15:30             ` Nicolas Pitre
  2006-12-15 15:48               ` Andreas Ericsson
  2006-12-15 23:22               ` Johannes Schindelin
  0 siblings, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15 15:30 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

On Fri, 15 Dec 2006, Jakub Narebski wrote:

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

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

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



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] make commit message a little more consistent and conforting
  2006-12-15 15:09                 ` Shawn Pearce
@ 2006-12-15 15:32                   ` Andreas Ericsson
  2006-12-15 15:40                     ` Shawn Pearce
  2006-12-15 16:01                   ` Nicolas Pitre
  1 sibling, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-15 15:32 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git

Shawn Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Shawn Pearce wrote:
>>> Nicolas Pitre <nico@cam.org> wrote:
>>>> 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.
>>> 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.
>>>
>> diffstats can be huge though. I'd rather have those only with -v option.
> 
> But they are on by default for pull/merge, and disabled by -n.
> 

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                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 22:50               ` Andy Parkins
@ 2006-12-15 15:38                 ` Jakub Narebski
  0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 15:38 UTC (permalink / raw)
  To: git

Andy Parkins wrote:

> On Thursday 2006, December 14 21:58, Junio C Hamano wrote:
> 
>> 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
> 
> 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".

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

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] make commit message a little more consistent and conforting
  2006-12-15 15:32                   ` Andreas Ericsson
@ 2006-12-15 15:40                     ` Shawn Pearce
  2006-12-15 15:50                       ` Andreas Ericsson
                                         ` (2 more replies)
  0 siblings, 3 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-15 15:40 UTC (permalink / raw)
  To: Andreas Ericsson; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git

Andreas Ericsson <ae@op5.se> 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.

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.

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 15:30             ` Nicolas Pitre
@ 2006-12-15 15:48               ` Andreas Ericsson
  2006-12-15 16:08                 ` Nicolas Pitre
  2006-12-15 23:22               ` Johannes Schindelin
  1 sibling, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-15 15:48 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Jakub Narebski, git

Nicolas Pitre wrote:
> On Fri, 15 Dec 2006, Jakub Narebski wrote:
> 
>> 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?
> 
> I would say the alias facility has to be fixed then.
> 
> In bash you can alias "ls" to "ls -l" and it just works.
> 

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] make commit message a little more consistent and conforting
  2006-12-15 15:40                     ` Shawn Pearce
@ 2006-12-15 15:50                       ` Andreas Ericsson
  2006-12-15 16:06                       ` Nicolas Pitre
  2006-12-15 18:21                       ` Junio C Hamano
  2 siblings, 0 replies; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-15 15:50 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git

Shawn Pearce wrote:
> Andreas Ericsson <ae@op5.se> 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.
> 
> 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
> 

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] make commit message a little more consistent and conforting
  2006-12-15 15:09                 ` Shawn Pearce
  2006-12-15 15:32                   ` Andreas Ericsson
@ 2006-12-15 16:01                   ` Nicolas Pitre
  2006-12-15 16:08                     ` Shawn Pearce
  2006-12-15 18:14                     ` Junio C Hamano
  1 sibling, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15 16:01 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Andreas Ericsson, Junio C Hamano, Andy Parkins, git

On Thu, 14 Dec 2006, Shawn Pearce wrote:

> Nicolas Pitre <nico@cam.org> wrote:
> > 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.
> 
> 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.

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.

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

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:

> Andreas Ericsson <ae@op5.se> wrote:
> > diffstats can be huge though. I'd rather have those only with -v option.
> 
> 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.

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.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] make commit message a little more consistent and conforting
  2006-12-15 15:40                     ` Shawn Pearce
  2006-12-15 15:50                       ` Andreas Ericsson
@ 2006-12-15 16:06                       ` Nicolas Pitre
  2006-12-15 18:21                       ` Junio C Hamano
  2 siblings, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15 16:06 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: Andreas Ericsson, Junio C Hamano, Andy Parkins, git

On Fri, 15 Dec 2006, Shawn Pearce 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.

Make it with -v.

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



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 15:48               ` Andreas Ericsson
@ 2006-12-15 16:08                 ` Nicolas Pitre
  2006-12-15 16:12                   ` Shawn Pearce
  2006-12-15 16:13                   ` Andreas Ericsson
  0 siblings, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15 16:08 UTC (permalink / raw)
  To: Andreas Ericsson; +Cc: Jakub Narebski, git

On Fri, 15 Dec 2006, Andreas Ericsson wrote:

> Nicolas Pitre wrote:
> > On Fri, 15 Dec 2006, Jakub Narebski wrote:
> > 
> > > 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?
> > 
> > I would say the alias facility has to be fixed then.
> > 
> > In bash you can alias "ls" to "ls -l" and it just works.
> > 
> 
> 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.

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.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] make commit message a little more consistent and conforting
  2006-12-15 16:01                   ` Nicolas Pitre
@ 2006-12-15 16:08                     ` Shawn Pearce
  2006-12-15 18:14                     ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-15 16:08 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Andreas Ericsson, Junio C Hamano, Andy Parkins, git

Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 15 Dec 2006, Shawn Pearce wrote:
> > Andreas Ericsson <ae@op5.se> wrote:
> > > diffstats can be huge though. I'd rather have those only with -v option.
> > 
> > But they are on by default for pull/merge, and disabled by -n.
> 
> 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.

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

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 16:08                 ` Nicolas Pitre
@ 2006-12-15 16:12                   ` Shawn Pearce
  2006-12-15 16:13                   ` Andreas Ericsson
  1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-15 16:12 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Andreas Ericsson, Jakub Narebski, git

Nicolas Pitre <nico@cam.org> 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.

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

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 16:08                 ` Nicolas Pitre
  2006-12-15 16:12                   ` Shawn Pearce
@ 2006-12-15 16:13                   ` Andreas Ericsson
  1 sibling, 0 replies; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-15 16:13 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Jakub Narebski, git

Nicolas Pitre wrote:
> On Fri, 15 Dec 2006, Andreas Ericsson wrote:
> 
>> Nicolas Pitre wrote:
>>> On Fri, 15 Dec 2006, Jakub Narebski wrote:
>>>
>>>> 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?
>>> I would say the alias facility has to be fixed then.
>>>
>>> In bash you can alias "ls" to "ls -l" and it just works.
>>>
>> 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.
> 
> 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.
> 

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?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 23:03   ` Shawn Pearce
@ 2006-12-15 16:16     ` Jakub Narebski
  2006-12-15 21:55       ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 16:16 UTC (permalink / raw)
  To: git

Shawn Pearce wrote:

> Andy Parkins <andyparkins@gmail.com> wrote:
>>  * git-show-branch output is cryptic.
> 
> Agreed.  I still don't know how to read its output.  So I just
> don't use it.  Ever.  :-)

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


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] make commit message a little more consistent and conforting
  2006-12-15 16:01                   ` Nicolas Pitre
  2006-12-15 16:08                     ` Shawn Pearce
@ 2006-12-15 18:14                     ` Junio C Hamano
  2006-12-15 20:13                       ` Nicolas Pitre
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 18:14 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Shawn Pearce, Andreas Ericsson, Andy Parkins, git

Nicolas Pitre <nico@cam.org> writes:

> So in short I do think there should be something shown after a 
> successful commit, and including the commit sha1 doesn't hurt.
> ...
> 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.

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


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] make commit message a little more consistent and conforting
  2006-12-15 15:40                     ` Shawn Pearce
  2006-12-15 15:50                       ` Andreas Ericsson
  2006-12-15 16:06                       ` Nicolas Pitre
@ 2006-12-15 18:21                       ` Junio C Hamano
  2 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 18:21 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: git

Shawn Pearce <spearce@spearce.org> writes:

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

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.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] make commit message a little more consistent and conforting
  2006-12-15 18:14                     ` Junio C Hamano
@ 2006-12-15 20:13                       ` Nicolas Pitre
  2006-12-16  6:18                         ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15 20:13 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Shawn Pearce, Andreas Ericsson, Andy Parkins, git

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

> Nicolas Pitre <nico@cam.org> writes:
> 
> > So in short I do think there should be something shown after a 
> > successful commit, and including the commit sha1 doesn't hurt.
> > ...
> > 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.
> 
> 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

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>

---

diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 9cdd171..f12082e 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -21,6 +21,11 @@
 	deleted lines in decimal notation and pathname without
 	abbreviation, to make it more machine friendly.
 
+--shortstat::
+	Output only the last line of the --stat format containing total
+	number of modified files, as well as number of added and deleted
+	lines.
+
 --summary::
 	Output a condensed summary of extended header information
 	such as creations, renames and mode changes.
diff --git a/diff.c b/diff.c
index 0b284b3..d754280 100644
--- a/diff.c
+++ b/diff.c
@@ -809,6 +809,35 @@ static void show_stats(struct diffstat_t* data, struct diff_options *options)
 	       set, total_files, adds, dels, reset);
 }
 
+static void show_shortstats(struct diffstat_t* data)
+{
+	int i, adds = 0, dels = 0, total_files = data->nr;
+
+	if (data->nr == 0)
+		return;
+
+	for (i = 0; i < data->nr; i++) {
+		if (!data->files[i]->is_binary &&
+		    !data->files[i]->is_unmerged) {
+			int added = data->files[i]->added;
+			int deleted= data->files[i]->deleted;
+			if (!data->files[i]->is_renamed &&
+			    (added + deleted == 0)) {
+				total_files--;
+			} else {
+				adds += added;
+				dels += deleted;
+			}
+		}
+		free(data->files[i]->name);
+		free(data->files[i]);
+	}
+	free(data->files);
+
+	printf(" %d files changed, %d insertions(+), %d deletions(-)\n",
+	       total_files, adds, dels);
+}
+
 static void show_numstat(struct diffstat_t* data, struct diff_options *options)
 {
 	int i;
@@ -1767,6 +1796,7 @@ int diff_setup_done(struct diff_options *options)
 		options->output_format &= ~(DIFF_FORMAT_RAW |
 					    DIFF_FORMAT_NUMSTAT |
 					    DIFF_FORMAT_DIFFSTAT |
+					    DIFF_FORMAT_SHORTSTAT |
 					    DIFF_FORMAT_SUMMARY |
 					    DIFF_FORMAT_PATCH);
 
@@ -1777,6 +1807,7 @@ int diff_setup_done(struct diff_options *options)
 	if (options->output_format & (DIFF_FORMAT_PATCH |
 				      DIFF_FORMAT_NUMSTAT |
 				      DIFF_FORMAT_DIFFSTAT |
+				      DIFF_FORMAT_SHORTSTAT |
 				      DIFF_FORMAT_SUMMARY |
 				      DIFF_FORMAT_CHECKDIFF))
 		options->recursive = 1;
@@ -1868,6 +1899,9 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
 	else if (!strcmp(arg, "--numstat")) {
 		options->output_format |= DIFF_FORMAT_NUMSTAT;
 	}
+	else if (!strcmp(arg, "--shortstat")) {
+		options->output_format |= DIFF_FORMAT_SHORTSTAT;
+	}
 	else if (!strncmp(arg, "--stat", 6)) {
 		char *end;
 		int width = options->stat_width;
@@ -2642,7 +2676,7 @@ void diff_flush(struct diff_options *options)
 		separator++;
 	}
 
-	if (output_format & (DIFF_FORMAT_DIFFSTAT|DIFF_FORMAT_NUMSTAT)) {
+	if (output_format & (DIFF_FORMAT_DIFFSTAT|DIFF_FORMAT_SHORTSTAT|DIFF_FORMAT_NUMSTAT)) {
 		struct diffstat_t diffstat;
 
 		memset(&diffstat, 0, sizeof(struct diffstat_t));
@@ -2656,6 +2690,8 @@ void diff_flush(struct diff_options *options)
 			show_numstat(&diffstat, options);
 		if (output_format & DIFF_FORMAT_DIFFSTAT)
 			show_stats(&diffstat, options);
+		else if (output_format & DIFF_FORMAT_SHORTSTAT)
+			show_shortstats(&diffstat);
 		separator++;
 	}
 
diff --git a/diff.h b/diff.h
index 101b2b5..eff4455 100644
--- a/diff.h
+++ b/diff.h
@@ -29,6 +29,7 @@ typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
 #define DIFF_FORMAT_NUMSTAT	0x0004
 #define DIFF_FORMAT_SUMMARY	0x0008
 #define DIFF_FORMAT_PATCH	0x0010
+#define DIFF_FORMAT_SHORTSTAT	0x0020
 
 /* These override all above */
 #define DIFF_FORMAT_NAME	0x0100
diff --git a/git-commit.sh b/git-commit.sh
index 395bcd2..b9e49ea 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -629,7 +629,7 @@ then
 	if test -z "$quiet"
 	then
 		echo "Created${initial_commit:+ initial} commit $commit"
-		git-diff-tree --summary --root --no-commit-id HEAD
+		git-diff-tree --shortstat --summary --root --no-commit-id HEAD
 	fi
 fi

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-14 21:55                       ` Andreas Ericsson
@ 2006-12-15 21:55                         ` Junio C Hamano
  2006-12-16  2:54                           ` Shawn Pearce
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
  To: Andreas Ericsson; +Cc: git

Andreas Ericsson <ae@op5.se> writes:

> Shawn Pearce wrote:
>>
>> 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.
>
> 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.

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

Volunteers?

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15  8:58             ` Andy Parkins
  2006-12-15  9:55               ` Raimund Bauer
@ 2006-12-15 21:55               ` Junio C Hamano
  2006-12-15 22:54                 ` Carl Worth
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git

Andy Parkins <andyparkins@gmail.com> writes:

> On Thursday 2006 December 14 23:46, Junio C Hamano wrote:
> ...
>> 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.
>
> Absolutely.  I'd agree that only <newbranch> is worth even considering.

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.



^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 16:16     ` Jakub Narebski
@ 2006-12-15 21:55       ` Junio C Hamano
  2006-12-15 22:48         ` Jakub Narebski
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: jnareb, Andy Parkins, git

Jakub Narebski <jnareb@gmail.com> writes:

> Shawn Pearce wrote:
>
>> Andy Parkins <andyparkins@gmail.com> wrote:
>>>  * git-show-branch output is cryptic.
>> 
>> Agreed.  I still don't know how to read its output.  So I just
>> don't use it.  Ever.  :-)
>
> And the way it uses it's options is even more cryptic, and differs from
> other similar commands.

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
  2006-12-15  0:20                             ` Shawn Pearce
@ 2006-12-15 21:55                               ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: git, Johannes Schindelin

Shawn Pearce <spearce@spearce.org> writes:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>> 
>> On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
>> 
>> > +int is_bare_git_dir (const char *dir)
>> > +{
>> > +	if (!strcmp(dir, DEFAULT_GIT_DIR_ENVIRONMENT))
>> > +		return 0;
>> > +	const char *s = strrchr(dir, '/');
>> > +	return !s || strcmp(s + 1, DEFAULT_GIT_DIR_ENVIRONMENT);
>> >  }
>> 
>> This function does not really determine if the repo is bare. I have no 
>> better name for it, though.
>
> guess_if_bare_git_dir ?
>
> I struggled to name that thing because it can't really tell, its just
> guessing... but it is going to be right most of the time.  Of course
> I'm sure there's some Git user somewhere who will confuse it.

I think the name is fine, but probably a comment in front would
help unconfuse people.

	/* Does it look like a repository without a working tree? */

Unfortunately there currently are public bare repositories that
have index under them because they were primed by rsync from
developers' working repositories.  I do not think it is
unreasonable to persuade owners of them to drop index -- then we
could use absence of $GIT_DIR/index as a strong clue that the
repository is bare.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 21:55       ` Junio C Hamano
@ 2006-12-15 22:48         ` Jakub Narebski
  2006-12-15 23:25           ` Johannes Schindelin
  2006-12-15 23:42           ` Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 22:48 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Shawn Pearce, Andy Parkins, git

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> Shawn Pearce wrote:
>>
>>> Andy Parkins <andyparkins@gmail.com> wrote:
>>>>  * git-show-branch output is cryptic.
>>> 
>>> Agreed.  I still don't know how to read its output.  So I just
>>> don't use it.  Ever.  :-)
>>
>> And the way it uses it's options is even more cryptic, and differs from
>> other similar commands.
> 
> (Jakub, please do not drop people from cc: list; you were asked
> more than once).

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.

> Ok, so what's the action you guys are proposing?
> 
>  (1) show-branch input is cryptic and it does not do anything
>      useful.  Drop it.
> 
>  (2) show-branch input is cryptic and I do not understand what
>      it is trying to do.  Document it better.
[...]

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)   
 
> 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.
 
It is odd (git branch not having --list with globbing) also because
'git tag' has globbing support.

-- 
Jakub Narebski

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 21:55               ` Junio C Hamano
@ 2006-12-15 22:54                 ` Carl Worth
  0 siblings, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-12-15 22:54 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Andy Parkins, git

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

> The 'can of worms' is that switching to an existing branch could
> fail with conflicts.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 15:30             ` Nicolas Pitre
  2006-12-15 15:48               ` Andreas Ericsson
@ 2006-12-15 23:22               ` Johannes Schindelin
  1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-15 23:22 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Jakub Narebski, git

Hi,

On Fri, 15 Dec 2006, Nicolas Pitre wrote:

> On Fri, 15 Dec 2006, Jakub Narebski wrote:
> 
> > 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?
> 
> I would say the alias facility has to be fixed then.
> 
> In bash you can alias "ls" to "ls -l" and it just works.

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 22:48         ` Jakub Narebski
@ 2006-12-15 23:25           ` Johannes Schindelin
  2006-12-15 23:45             ` Junio C Hamano
  2006-12-15 23:42           ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-15 23:25 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: Junio C Hamano, git

Hi,

On Fri, 15 Dec 2006, Jakub Narebski wrote:

> Junio C Hamano wrote:
>
> > (Jakub, please do not drop people from cc: list; you were asked
> > more than once).
> 
> The problem is that I'm not subscribed to git mailing list;

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 22:48         ` Jakub Narebski
  2006-12-15 23:25           ` Johannes Schindelin
@ 2006-12-15 23:42           ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 23:42 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: Shawn Pearce, Andy Parkins, git

Jakub Narebski <jnareb@gmail.com> writes:

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

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.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 23:25           ` Johannes Schindelin
@ 2006-12-15 23:45             ` Junio C Hamano
  2006-12-16  0:14               ` Johannes Schindelin
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 23:45 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, Jakub Narebski

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

> On Fri, 15 Dec 2006, Jakub Narebski wrote:
>
>> Junio C Hamano wrote:
>>
>> > (Jakub, please do not drop people from cc: list; you were asked
>> > more than once).
>> 
>> The problem is that I'm not subscribed to git mailing list;
>
> 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.

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.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 23:45             ` Junio C Hamano
@ 2006-12-16  0:14               ` Johannes Schindelin
  2006-12-16  0:30                 ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-16  0:14 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Jakub Narebski

Hi,

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

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Fri, 15 Dec 2006, Jakub Narebski wrote:
> >
> >> Junio C Hamano wrote:
> >>
> >> > (Jakub, please do not drop people from cc: list; you were asked
> >> > more than once).
> >> 
> >> The problem is that I'm not subscribed to git mailing list;
> >
> > 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.
> 
> FWIW, I also read the list traffic through gmane news gateway.

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

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-16  0:14               ` Johannes Schindelin
@ 2006-12-16  0:30                 ` Junio C Hamano
  2006-12-16 17:12                   ` Steven Grimm
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16  0:30 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, Jakub Narebski

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

>> FWIW, I also read the list traffic through gmane news gateway.
>
> So, how do you tackle the problem Jakub evidently has, namely to reply to 
> all the people who your reply refers to?

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.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-15 21:55                         ` Junio C Hamano
@ 2006-12-16  2:54                           ` Shawn Pearce
  0 siblings, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-16  2:54 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Andreas Ericsson, git

Junio C Hamano <junkio@cox.net> wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> > Shawn Pearce wrote:
> >>
> >> 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.
> >
> > 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.
> 
> This sounds sensible, regardless of the current discussion on
> the default 'logallrefupdates' setting.
> 
> Volunteers?

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

-- 

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] make commit message a little more consistent and conforting
  2006-12-15 20:13                       ` Nicolas Pitre
@ 2006-12-16  6:18                         ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16  6:18 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Shawn Pearce, Andreas Ericsson, Andy Parkins, git

Nicolas Pitre <nico@cam.org> writes:

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

Looks good.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* [PATCH] git-clone: use wildcard specification for tracking branches
  2006-12-13 21:35 What's in git.git (stable) Junio C Hamano
  2006-12-13 22:37 ` Andy Parkins
@ 2006-12-16  9:14 ` Junio C Hamano
  2006-12-16  9:36   ` [PATCH] git-pull: refuse default merge without branch.*.merge Junio C Hamano
  2006-12-16  9:39   ` [PATCH] git-clone: use wildcard specification for tracking branches Jakub Narebski
  2006-12-16  9:58 ` What's in git.git (stable) Junio C Hamano
  2006-12-16 13:59 ` What's in git.git (stable) Jakub Narebski
  3 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16  9:14 UTC (permalink / raw)
  To: git

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:

> Things that need to be done to complete what have been merged to
> 'master' are:
> ...
>  - '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.

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

diff --git a/git-clone.sh b/git-clone.sh
index 1f5d07a..422499a 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -366,41 +366,54 @@ then
 		)
 	)
 
-	# Write out remotes/$origin file, and update our "$head_points_at".
+	# Write out remote.$origin config, and update our "$head_points_at".
 	case "$head_points_at" in
 	?*)
-		mkdir -p "$GIT_DIR/remotes" &&
+		# Local default branch
 		git-symbolic-ref HEAD "refs/heads/$head_points_at" &&
+
+		# Tracking branch for the primary branch at the remote.
 		case "$use_separate_remote" in
 		t)	origin_track="$remote_top/$head_points_at"
 			git-update-ref HEAD "$head_sha1" ;;
 		*)	origin_track="$remote_top/$origin"
 			git-update-ref "refs/heads/$origin" "$head_sha1" ;;
 		esac &&
+
+		# Upstream URL and the primary branch tracking
 		git-repo-config remote."$origin".url "$repo" &&
 		git-repo-config remote."$origin".fetch \
 			"refs/heads/$head_points_at:$origin_track" &&
-		(cd "$GIT_DIR/$remote_top" && find . -type f -print) |
-		while read dotslref
-		do
-			name=`expr "$dotslref" : './\(.*\)'`
-			if test "z$head_points_at" = "z$name"
-			then
-				continue
-			fi
-			if test "$use_separate_remote" = '' &&
-			   test "z$origin" = "z$name"
-			then
-				continue
-			fi
-			git-repo-config remote."$origin".fetch "refs/heads/${name}:$remote_top/${name}" '^$'
-		done &&
+
+		# Set up the mappings to track the remaining branches.
+		case "$use_separate_remote" in
+		t)
+			git-repo-config remote."$origin".fetch \
+				"refs/heads/*:$remote_top/*" '^$'
+			;;
+		*)
+			(cd "$GIT_DIR/$remote_top" && find . -type f -print) |
+			while read dotslref
+			do
+				name=`expr "$dotslref" : './\(.*\)'`
+				if test "z$head_points_at" = "z$name" ||
+					test "z$origin" = "z$name"
+				then
+					continue
+				fi
+				git-repo-config remote."$origin".fetch \
+				"refs/heads/${name}:$remote_top/${name}" '^$'
+			done
+			;;
+		esac &&
+
 		case "$use_separate_remote" in
 		t)
 			rm -f "refs/remotes/$origin/HEAD"
 			git-symbolic-ref "refs/remotes/$origin/HEAD" \
 				"refs/remotes/$origin/$head_points_at"
 		esac &&
+
 		git-repo-config branch."$head_points_at".remote "$origin" &&
 		git-repo-config branch."$head_points_at".merge "refs/heads/$head_points_at"
 	esac

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* [PATCH] git-pull: refuse default merge without branch.*.merge
  2006-12-16  9:14 ` [PATCH] git-clone: use wildcard specification for tracking branches Junio C Hamano
@ 2006-12-16  9:36   ` Junio C Hamano
  2006-12-16  9:41     ` [PATCH] git-clone: lose the artificial "first" fetch refspec Junio C Hamano
  2006-12-16 16:44     ` [PATCH] git-pull: refuse default merge without branch.*.merge Linus Torvalds
  2006-12-16  9:39   ` [PATCH] git-clone: use wildcard specification for tracking branches Jakub Narebski
  1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16  9:36 UTC (permalink / raw)
  To: git

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:

> 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

  And this does exactly that.

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

diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 6ae534b..7cd79c2 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -144,7 +144,8 @@ canon_refs_list_for_fetch () {
 			curr_branch=$(git-symbolic-ref HEAD | \
 			    sed -e 's|^refs/heads/||')
 			merge_branches=$(git-repo-config \
-			    --get-all "branch.${curr_branch}.merge")
+			    --get-all "branch.${curr_branch}.merge") ||
+			merge_branches=.this.would.never.match.any.ref.
 		fi
 		set x $(expand_refs_wildcard "$@")
 		shift

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: [PATCH] git-clone: use wildcard specification for tracking branches
  2006-12-16  9:14 ` [PATCH] git-clone: use wildcard specification for tracking branches Junio C Hamano
  2006-12-16  9:36   ` [PATCH] git-pull: refuse default merge without branch.*.merge Junio C Hamano
@ 2006-12-16  9:39   ` Jakub Narebski
  1 sibling, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-16  9:39 UTC (permalink / raw)
  To: git

Junio C Hamano wrote:

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

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


^ permalink raw reply	[flat|nested] 601+ messages in thread

* [PATCH] git-clone: lose the artificial "first" fetch refspec
  2006-12-16  9:36   ` [PATCH] git-pull: refuse default merge without branch.*.merge Junio C Hamano
@ 2006-12-16  9:41     ` Junio C Hamano
  2006-12-16  9:53       ` [PATCH] git-clone: lose the traditional 'no-separate-remote' layout Junio C Hamano
  2006-12-16 11:51       ` [PATCH] git-clone: lose the artificial "first" fetch refspec Johannes Schindelin
  2006-12-16 16:44     ` [PATCH] git-pull: refuse default merge without branch.*.merge Linus Torvalds
  1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16  9:41 UTC (permalink / raw)
  To: git

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>

---
> Junio C Hamano <junkio@cox.net> writes:
>
>> 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
>
>   And this does exactly that.

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

diff --git a/git-clone.sh b/git-clone.sh
index 422499a..68dc4f2 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -380,18 +380,18 @@ then
 			git-update-ref "refs/heads/$origin" "$head_sha1" ;;
 		esac &&
 
-		# Upstream URL and the primary branch tracking
+		# Upstream URL
 		git-repo-config remote."$origin".url "$repo" &&
-		git-repo-config remote."$origin".fetch \
-			"refs/heads/$head_points_at:$origin_track" &&
 
-		# Set up the mappings to track the remaining branches.
+		# Set up the mappings to track the remote branches.
 		case "$use_separate_remote" in
 		t)
 			git-repo-config remote."$origin".fetch \
 				"refs/heads/*:$remote_top/*" '^$'
 			;;
 		*)
+			git-repo-config remote."$origin".fetch \
+				"refs/heads/$head_points_at:$origin_track" &&
 			(cd "$GIT_DIR/$remote_top" && find . -type f -print) |
 			while read dotslref
 			do

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* [PATCH] git-clone: lose the traditional 'no-separate-remote' layout
  2006-12-16  9:41     ` [PATCH] git-clone: lose the artificial "first" fetch refspec Junio C Hamano
@ 2006-12-16  9:53       ` Junio C Hamano
  2006-12-16 16:53         ` Linus Torvalds
  2006-12-16 11:51       ` [PATCH] git-clone: lose the artificial "first" fetch refspec Johannes Schindelin
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16  9:53 UTC (permalink / raw)
  To: git

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:

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

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

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index bfddb21..874934a 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -11,8 +11,7 @@ SYNOPSIS
 [verse]
 'git-clone' [--template=<template_directory>] [-l [-s]] [-q] [-n] [--bare]
 	  [-o <name>] [-u <upload-pack>] [--reference <repository>]
-	  [--use-separate-remote | --no-separate-remote] <repository>
-	  [<directory>]
+	  <repository> [<directory>]
 
 DESCRIPTION
 -----------
@@ -99,18 +98,6 @@ OPTIONS
 	if unset the templates are taken from the installation
 	defined default, typically `/usr/share/git-core/templates`.
 
---use-separate-remote::
-	Save remotes heads under `$GIT_DIR/refs/remotes/origin/` instead
-	of `$GIT_DIR/refs/heads/`.  Only the local master branch is
-	saved in the latter. This is the default.
-
---no-separate-remote::
-	Save remotes heads in the same namespace as the local
-	heads, `$GIT_DIR/refs/heads/'.  In regular repositories,
-	this is a legacy setup git-clone created by default in
-	older Git versions, and will be removed before the next
-	major release.
-
 <repository>::
 	The (possibly remote) repository to clone from.  It can
 	be any URL git-fetch supports.
diff --git a/git-clone.sh b/git-clone.sh
index 68dc4f2..490f3e4 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -14,7 +14,7 @@ die() {
 }
 
 usage() {
-	die "Usage: $0 [--template=<template_directory>] [--no-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
+	die "Usage: $0 [--template=<template_directory>] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
 }
 
 get_repo_base() {
@@ -137,11 +137,9 @@ while
 	*,--template=*)
 	  template="$1" ;;
 	*,-q|*,--quiet) quiet=-q ;;
-	*,--use-separate-remote)
-		# default
-		use_separate_remote=t ;;
+	*,--use-separate-remote) ;;
 	*,--no-separate-remote)
-		use_separate_remote= ;;
+		die "clones are always made with separate-remote layout" ;;
 	1,--reference) usage ;;
 	*,--reference)
 		shift; reference="$1" ;;
@@ -327,12 +325,8 @@ cd "$D" || exit
 
 if test -z "$bare" && test -f "$GIT_DIR/REMOTE_HEAD"
 then
-	# Figure out which remote branch HEAD points at.
-	case "$use_separate_remote" in
-	'')	remote_top=refs/heads ;;
-	*)	remote_top="refs/remotes/$origin" ;;
-	esac
-
+	# a non-bare repository is always in separate-remote layout
+	remote_top="refs/remotes/$origin"
 	head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"`
 	case "$head_sha1" in
 	'ref: refs/'*)
@@ -373,46 +367,18 @@ then
 		git-symbolic-ref HEAD "refs/heads/$head_points_at" &&
 
 		# Tracking branch for the primary branch at the remote.
-		case "$use_separate_remote" in
-		t)	origin_track="$remote_top/$head_points_at"
-			git-update-ref HEAD "$head_sha1" ;;
-		*)	origin_track="$remote_top/$origin"
-			git-update-ref "refs/heads/$origin" "$head_sha1" ;;
-		esac &&
+		origin_track="$remote_top/$head_points_at" &&
+		git-update-ref HEAD "$head_sha1" &&
 
 		# Upstream URL
 		git-repo-config remote."$origin".url "$repo" &&
 
 		# Set up the mappings to track the remote branches.
-		case "$use_separate_remote" in
-		t)
-			git-repo-config remote."$origin".fetch \
-				"refs/heads/*:$remote_top/*" '^$'
-			;;
-		*)
-			git-repo-config remote."$origin".fetch \
-				"refs/heads/$head_points_at:$origin_track" &&
-			(cd "$GIT_DIR/$remote_top" && find . -type f -print) |
-			while read dotslref
-			do
-				name=`expr "$dotslref" : './\(.*\)'`
-				if test "z$head_points_at" = "z$name" ||
-					test "z$origin" = "z$name"
-				then
-					continue
-				fi
-				git-repo-config remote."$origin".fetch \
-				"refs/heads/${name}:$remote_top/${name}" '^$'
-			done
-			;;
-		esac &&
-
-		case "$use_separate_remote" in
-		t)
-			rm -f "refs/remotes/$origin/HEAD"
-			git-symbolic-ref "refs/remotes/$origin/HEAD" \
-				"refs/remotes/$origin/$head_points_at"
-		esac &&
+		git-repo-config remote."$origin".fetch \
+			"refs/heads/*:$remote_top/*" '^$' &&
+		rm -f "refs/remotes/$origin/HEAD"
+		git-symbolic-ref "refs/remotes/$origin/HEAD" \
+			"refs/remotes/$origin/$head_points_at" &&
 
 		git-repo-config branch."$head_points_at".remote "$origin" &&
 		git-repo-config branch."$head_points_at".merge "refs/heads/$head_points_at"

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-13 21:35 What's in git.git (stable) Junio C Hamano
  2006-12-13 22:37 ` Andy Parkins
  2006-12-16  9:14 ` [PATCH] git-clone: use wildcard specification for tracking branches Junio C Hamano
@ 2006-12-16  9:58 ` Junio C Hamano
  2006-12-16 11:22   ` [PATCH] Document git-merge-file Johannes Schindelin
  2006-12-16 13:59 ` What's in git.git (stable) Jakub Narebski
  3 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16  9:58 UTC (permalink / raw)
  To: git

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

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 ;-)?





^ permalink raw reply	[flat|nested] 601+ messages in thread

* [PATCH] Document git-merge-file
  2006-12-16  9:58 ` What's in git.git (stable) Junio C Hamano
@ 2006-12-16 11:22   ` Johannes Schindelin
  0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-16 11:22 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git


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

diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt
new file mode 100644
index 0000000..0b41d66
--- /dev/null
+++ b/Documentation/git-merge-file.txt
@@ -0,0 +1,92 @@
+git-merge-file(1)
+============
+
+NAME
+----
+git-merge-file - threeway file merge
+
+
+SYNOPSIS
+--------
+[verse]
+'git-merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
+	[-p|--stdout] [-q|--quiet] <current-file> <base-file> <other-file>
+
+
+DESCRIPTION
+-----------
+git-file-merge incorporates all changes that lead from the `<base-file>`
+to `<other-file>` into `<current-file>`. The result ordinarily goes into
+`<current-file>`. git-merge-file is useful for combining separate changes
+to an original. Suppose `<base-file>` is the original, and both
+`<current-file>` and `<other-file>` are modifications of `<base-file>`.
+Then git-merge-file combines both changes.
+
+A conflict occurs if both `<current-file>` and `<other-file>` have changes
+in a common segment of lines. If a conflict is found, git-merge-file
+normally outputs a warning and brackets the conflict with <<<<<<< and
+>>>>>>> lines. A typical conflict will look like this:
+
+	<<<<<<< A
+	lines in file A
+	=======
+	lines in file B
+	>>>>>>> B
+
+If there are conflicts, the user should edit the result and delete one of
+the alternatives.
+
+The exit value of this program is negative on error, and the number of
+conflicts otherwise. If the merge was clean, the exit value is 0.
+
+git-merge-file is designed to be a minimal clone of RCS merge, that is, it
+implements all of RCS merge's functionality which is needed by
+gitlink:git[1].
+
+
+OPTIONS
+-------
+
+-L <label>::
+	This option may be given up to three times, and
+	specifies labels to be used in place of the
+	corresponding file names in conflict reports. That is,
+	`git-merge-file -L x -L y -L z a b c` generates output that
+	looks like it came from files x, y and z instead of
+	from files a, b and c.
+
+-p::
+	Send results to standard output instead of overwriting
+	`<current-file>`.
+
+-q::
+	Quiet;  do  not  warn about conflicts.
+
+
+EXAMPLES
+--------
+
+git merge-file README.my README README.upstream::
+
+	combines the changes of README.my and README.upstream since README,
+	tries to merge them and writes the result into README.my.
+
+git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345::
+
+	merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels
+	`a` and `c` instead of `tmp/a123` and `tmp/c345`.
+
+
+Author
+------
+Written by Johannes Schindelin <johannes.schindelin@gmx.de>
+
+
+Documentation
+--------------
+Documentation by Johannes Schindelin and the git-list <git@vger.kernel.org>,
+with parts copied from the original documentation of RCS merge.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git.txt b/Documentation/git.txt
index b9b1e63..b9fc9ae 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -359,6 +359,9 @@ gitlink:git-init-db[1]::
 	Creates an empty git object database, or reinitialize an
 	existing one.
 
+gitlink:git-merge-file[1]::
+	Runs a threeway merge.
+
 gitlink:git-merge-index[1]::
 	Runs a merge for files needing merging.
 
-- 
1.4.4.2.g5dc03

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: [PATCH] git-clone: lose the artificial "first" fetch refspec
  2006-12-16  9:41     ` [PATCH] git-clone: lose the artificial "first" fetch refspec Junio C Hamano
  2006-12-16  9:53       ` [PATCH] git-clone: lose the traditional 'no-separate-remote' layout Junio C Hamano
@ 2006-12-16 11:51       ` Johannes Schindelin
  1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-16 11:51 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

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

>  With the recent flurry of UI updates, I think it is sane to do
>  that before v1.5.0; opinions?

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-13 21:35 What's in git.git (stable) Junio C Hamano
                   ` (2 preceding siblings ...)
  2006-12-16  9:58 ` What's in git.git (stable) Junio C Hamano
@ 2006-12-16 13:59 ` Jakub Narebski
  2006-12-16 22:04   ` Junio C Hamano
  3 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-12-16 13:59 UTC (permalink / raw)
  To: git; +Cc: linux-kernel

Junio C Hamano wrote:

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

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


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] git-pull: refuse default merge without branch.*.merge
  2006-12-16  9:36   ` [PATCH] git-pull: refuse default merge without branch.*.merge Junio C Hamano
  2006-12-16  9:41     ` [PATCH] git-clone: lose the artificial "first" fetch refspec Junio C Hamano
@ 2006-12-16 16:44     ` Linus Torvalds
  1 sibling, 0 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-12-16 16:44 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git



On Sat, 16 Dec 2006, Junio C Hamano wrote:
>
> 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.

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.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH] git-clone: lose the traditional 'no-separate-remote' layout
  2006-12-16  9:53       ` [PATCH] git-clone: lose the traditional 'no-separate-remote' layout Junio C Hamano
@ 2006-12-16 16:53         ` Linus Torvalds
  0 siblings, 0 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-12-16 16:53 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git



On Sat, 16 Dec 2006, Junio C Hamano wrote:
> 
>  And this drops it; modulo bugs, I think this is about it for
>  v1.5.0 around this area.

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


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-16  0:30                 ` Junio C Hamano
@ 2006-12-16 17:12                   ` Steven Grimm
  2006-12-16 19:57                     ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Steven Grimm @ 2006-12-16 17:12 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Schindelin, git, Jakub Narebski

Junio C Hamano wrote:
> It's just a common courtesy, not "tackling".
>   

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?


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-16 17:12                   ` Steven Grimm
@ 2006-12-16 19:57                     ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16 19:57 UTC (permalink / raw)
  To: Steven Grimm; +Cc: Johannes Schindelin, git, Jakub Narebski

Steven Grimm <koreth@midwinter.com> writes:

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

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.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-16 13:59 ` What's in git.git (stable) Jakub Narebski
@ 2006-12-16 22:04   ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16 22:04 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
>
>> Things that need to be done to complete what have been merged to
>> 'master' are:
>
> 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)?

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



^ permalink raw reply	[flat|nested] 601+ messages in thread

* [RFH] An early draft of v1.5.0 release notes
@ 2006-12-27  7:39 Junio C Hamano
  2006-12-27  8:18 ` Shawn Pearce
                   ` (4 more replies)
  0 siblings, 5 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-27  7:39 UTC (permalink / raw)
  To: git

This is still rough, but I think we have a pretty good idea what
will and what won't be in v1.5.0 by now, and end-of-year is a
good slow time to summarize what we have done.

One thing I am wondering is if delta from v1.4.4.3 is good
enough for the intended audience of this release notes.  I am
reasonably sure that the name v1.5.0 will attract more people
than usual and there will be many people upgrading directly from
ancient versions such as v1.1.6 or v1.2.0, and there are a
handful "one-way-street upgrades" and quite a few user visible
changes that already have happened before v1.4.4.  Namely:

 - Pack-compatible loose object headers, introduced between
   v1.4.1 and v1.4.2; repository cannot be read with ancient
   version of git anymore -- this is a one-way street but
   core.legacyheaders is still not enabled by default);

 - delta-base-offset pack encoding, introduced between v1.4.2
   and v1.4.3; this is also a one-way street.

 - 'git -p' to paginate anything -- many commands do pagination
   by default on a tty.  Introduced between v1.4.1 and v1.4.2;
   this may surprise old timer users.

 - 'git archive' superseded 'git tar' in v1.4.3;

 - 'git pack-refs' appeared in v1.4.4;

 - 'git cvsserver' was new invention in v1.3.0;

 - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
   seriously enhanced during v1.4.0 timeperiod.

 - 'gitweb' became part of git.git during v1.4.0 timeperiod and
   seriously modified since then.

 - reflog is v1.4.0 invention.

In the following, I am assuming that jc/utf8 and jc/fsck-reflog
topics currently in 'next' will be part of v1.5.0.


-- >8 --

Updates in v1.5.0 since v1.4.4 series
-------------------------------------

* Index manipulation

 - git-add is to add contents to the index (aka "staging area"
   for the next commit), whether the file the contents happen to
   be is an existing one or a newly created one.

 - git-add without any argument does not add everything
   anymore.  Say "git add ." if you want to.

 - git-add tries to be more friendly to users by offering an
   interactive mode.

 - git-commit <path> used to refuse to commit if <path> was
   different between HEAD and the index (i.e. update-index was
   used on it earlier).  This check was removed.

 - git-rm is much saner and safer.  It is used to remove paths
   from both the index file and the working tree, and makes sure
   you are not losing any local modification before doing so.

 - git-reset <tree> <paths>... can be used to revert index
   entries for selected paths.

 - git-update-index is much less visible.


* Repository layout

 - The data for origin repository is stored in the configuration
   file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
   created clones (the latter is still supported).

 - git-clone always uses what is known as "separate remote"
   layout for a newly created repository with a working tree;
   i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are
   used to track branches from the origin.  New branches that
   appear on the origin side after a clone is made are also
   tracked automatically.

 - git-clone used to be buggy and copied refs outside refs/heads
   and refs/tags; it doesn't anymore.

 - git-branch and git-show-branch know remote tracking branches.

 - git-push can now be used to delete a remote branch or a tag.


* Reflog

 - Reflog records the history of where the tip of each branch
   was at each moment.  This facility is enabled by default for
   repositories with working trees, and can be accessed with the
   "branch@{time}" and "branch@{Nth}" notation.

 - "git show-branch" learned showing the reflog data with the
   new --reflog option.

 - The commits referred to by reflog entries are now protected
   against pruning.  The new command "git reflog expire" can be
   used to truncate older reflog entries and entries that refer
   to commits that have been pruned away previously.

   Existing repositories that have been using reflog may get
   complaints from fsck-objects; please run "git reflog expire
   --all" first to remove reflog entries that refer to commits
   that are no longer in the repository before attempting to
   repack it.

 - git-branch knows how to rename branches and moves existing
   reflog data from the old branch to the new one.


* Packed refs

 - Repositories with hundreds of tags have been paying large
   overhead, both in storage and in runtime.  A new command,
   git-pack-refs, can be used to "pack" them in more efficient
   representation.

 - Clones and fetches over dumb transports are now aware of
   packed refs and can download from repositories that use
   them.


* Configuration

 - configuration related to colorize setting are consolidated
   under color.* namespace (older diff.color.*, status.color.*
   are still supported).


* Less external dependency

 - We have been depended on "merge" program from RCS suite for
   the file-level 3-way merge, but now we lost this dependency.

 - The original implementation of git-merge-recursive which was
   in Python has been removed; we have C implementation of it
   now.

 - git-shortlog is not in Perl anymore, and more importantly it
   does not have to be piped output from git-log.  It can
   traverse the commit ancestry itself.


* I18n

 - We have always encouraged the commit message to be encoded in
   UTF-8, but the users are allowed to use legacy encoding as
   appropriate for their projects (which will never change).
   A non UTF-8 commit encoding however _must_ be explicitly set
   with i18n.commitencoding in the repository configuration;
   otherwise git-commit-tree will complain if the log message does
   not look like a valid UTF-8 string.

 - A commit object recorded in non UTF-8 encoding records the
   encoding i18n.commitencoding specified in the originating
   repository in a new "encoding" header.  This information is
   used by git-log and friends to reencode the message to UTF-8
   when displaying.


* User support

 - Quite a lot of documentation updates.

 - Bash completion scripts have been updated heavily.

 - Better error messages for often used Porcelainish commands.


----------------------------------------------------------------
(shortlog since v1.4.4.3 here)

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27  7:39 [RFH] An early draft of v1.5.0 release notes Junio C Hamano
@ 2006-12-27  8:18 ` Shawn Pearce
  2006-12-27 10:12 ` Jakub Narebski
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-27  8:18 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <junkio@cox.net> wrote:
> This is still rough, but I think we have a pretty good idea what
> will and what won't be in v1.5.0 by now, and end-of-year is a
> good slow time to summarize what we have done.

This is certainly a good idea.  And your summary was pretty good
too, I enjoyed the read.  This group has certainly accomplished
quite a bit lately!

Just a few comments:
 
>  - Pack-compatible loose object headers, introduced between
>    v1.4.1 and v1.4.2; repository cannot be read with ancient
>    version of git anymore -- this is a one-way street but
>    core.legacyheaders is still not enabled by default);
> 
>  - delta-base-offset pack encoding, introduced between v1.4.2
>    and v1.4.3; this is also a one-way street.

Perhaps you can clarify that using these means the repository
cannot be used with an earlier version of Git?  You may also want
to highlight why these features are good, answering the question
"Why should I enable them if it breaks backwards compatibility?".

Isn't the new packed-refs format also a one-way street?  If you
use them for tags on a web server and the client is using a very
old http commit walker, what happens?
 
>  - git-clone used to be buggy and copied refs outside refs/heads
>    and refs/tags; it doesn't anymore.

I mentioned to you on #git this morning that I don't think this
is noteworthy for this release.

You missed talking about the mess of pack files created by git-push
now, especially with pushes over 100 objects.  ;-)
 
>  - git-push can now be used to delete a remote branch or a tag.

You should mention this requires server side support too.  I read
that and assumed I could just upgrade my client and push to delete
- which isn't the case, and I know its not...  but I still read it
that way.
 
>  - "git show-branch" learned showing the reflog data with the
>    new --reflog option.

I had hoped we could get 'git reflog show' into 1.5.0 but the
current discussion with Johannes seems like that's unlikely.
 
>  - We have been depended on "merge" program from RCS suite for
>    the file-level 3-way merge, but now we lost this dependency.

Perhaps just reword as:

	We no longer require the "merge" program from the RCS suite.
	All 3-way file-level merges are now done internally.
 
>  - git-shortlog is not in Perl anymore, and more importantly it
>    does not have to be piped output from git-log.  It can
>    traverse the commit ancestry itself.

The "traverse the commit ancestry itself" part is not very
readable for the average user.  How about instead:

	git-shortlog is no longer a Perl script.  git-shortlog also
	no longer requires output piped from git-log; it can accept
	revision parameters directly on the command line.

-- 
Shawn.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27  7:39 [RFH] An early draft of v1.5.0 release notes Junio C Hamano
  2006-12-27  8:18 ` Shawn Pearce
@ 2006-12-27 10:12 ` Jakub Narebski
  2006-12-27 10:24   ` Junio C Hamano
  2006-12-27 10:50   ` Junio C Hamano
  2006-12-27 12:06 ` Horst H. von Brand
                   ` (2 subsequent siblings)
  4 siblings, 2 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-27 10:12 UTC (permalink / raw)
  To: git

Junio C Hamano wrote:

> This is still rough, but I think we have a pretty good idea what
> will and what won't be in v1.5.0 by now, and end-of-year is a
> good slow time to summarize what we have done.

Very nice idea! Perhaps those release notes can find it's way into
either v1.5.0 commit, or v1.5.0 tag comment?

Just a few comments:

>  - git-add without any argument does not add everything
>    anymore.  Say "git add ." if you want to.
> 
>  - git-add tries to be more friendly to users by offering an
>    interactive mode.

Perhaps information that git-add can be used to add ignored files
with -f option should be added? Or is it not important enough?
 
>  - The commits referred to by reflog entries are now protected
>    against pruning.  The new command "git reflog expire" can be
>    used to truncate older reflog entries and entries that refer
>    to commits that have been pruned away previously.
> 
>    Existing repositories that have been using reflog may get
>    complaints from fsck-objects; please run "git reflog expire
>    --all" first to remove reflog entries that refer to commits
>    that are no longer in the repository before attempting to
>    repack it.

That's a bit bad, as it forces to lose some info... but that
info was not that useful anyway.
 
>  - A commit object recorded in non UTF-8 encoding records the
>    encoding i18n.commitencoding specified in the originating
>    repository in a new "encoding" header.  This information is
>    used by git-log and friends to reencode the message to UTF-8
>    when displaying.

I don't quite like it. Why if someone uses different encoding
that utf-8 because his terminal is not set to utf-8? Having suddenly
what looks like garbage on output, while input was in local encoding
(and specified in i18n.commitencoding) is a bit suprising...
 
> ----------------------------------------------------------------
> (shortlog since v1.4.4.3 here)

I'd rather have description a la "what's cooking" here... 

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27 10:12 ` Jakub Narebski
@ 2006-12-27 10:24   ` Junio C Hamano
  2006-12-27 11:54     ` Johannes Schindelin
  2006-12-27 12:12     ` Jakub Narebski
  2006-12-27 10:50   ` Junio C Hamano
  1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-27 10:24 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

Jakub Narebski <jnareb@gmail.com> writes:

> That's a bit bad, as it forces to lose some info... but that
> info was not that useful anyway.

I am tired of listening to this useless FUD of yours.  You lost
the information when you pruned away the underlying objects; you
are not losing information when you expire the reflog entries
that became useless long time ago.

> I don't quite like it. Why if someone uses different encoding
> that utf-8 because his terminal is not set to utf-8? Having suddenly
> what looks like garbage on output, while input was in local encoding
> (and specified in i18n.commitencoding) is a bit suprising...

If Luben wants UTF-8 in his project, but somebody he pulled from
was mistakenly used latin-1, then the commit pulled record
latin-1 while Luben has i18n.commitencoding in his repository
set to UTF-8.  Output will be done in UTF-8 for Luben.  For the
originator of that latin-1 commit, i18n.commitencoding says
latin-1 (and that was the only reason he managed to create such
a commit) and git show of that commit would not involve
recoding.

At least that is the idea.  Have you spotted a bug, perhaps?

>> (shortlog since v1.4.4.3 here)
>
> I'd rather have description a la "what's cooking" here... 

Send the summary to the list and I'll append it to the release
notes.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27 10:12 ` Jakub Narebski
  2006-12-27 10:24   ` Junio C Hamano
@ 2006-12-27 10:50   ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-27 10:50 UTC (permalink / raw)
  To: git; +Cc: jnareb

Jakub Narebski <jnareb@gmail.com> writes:

> Just a few comments:
>
>>  - git-add without any argument does not add everything
>>    anymore.  Say "git add ." if you want to.
>
> Perhaps information that git-add can be used to add ignored files
> with -f option should be added? Or is it not important enough?

Thanks.  Will change the above bullet to this:

 - git-add without any argument does not add everything
   anymore.  Use 'git-add .' instead.  Also you can add
   otherwise ignored files with an -f option.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27 10:24   ` Junio C Hamano
@ 2006-12-27 11:54     ` Johannes Schindelin
  2006-12-27 12:15       ` Jakub Narebski
  2006-12-27 12:12     ` Jakub Narebski
  1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-27 11:54 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jakub Narebski, git

Hi,

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

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > I don't quite like it. Why if someone uses different encoding
> > that utf-8 because his terminal is not set to utf-8? Having suddenly
> > what looks like garbage on output, while input was in local encoding
> > (and specified in i18n.commitencoding) is a bit suprising...
> 
> If Luben wants UTF-8 in his project, but somebody he pulled from was 
> mistakenly used latin-1, then the commit pulled record latin-1 while 
> Luben has i18n.commitencoding in his repository set to UTF-8.  Output 
> will be done in UTF-8 for Luben.  For the originator of that latin-1 
> commit, i18n.commitencoding says latin-1 (and that was the only reason 
> he managed to create such a commit) and git show of that commit would 
> not involve recoding.

I think that this is a misunderstanding. Maybe the config variable is 
misnamed. As is clearly visible from the commit messages, this whole stuff 
is meant to reencode to whatever encoding the caller of git-log likes, not 
just UTF-8. And it defaults to UTF-8, overridable by i18n.commitEncoding.

BTW I think that latin-1 is not a valid encoding name (at least in my 
setup it isn't), so we should rather talk about iso-8859-1.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27  7:39 [RFH] An early draft of v1.5.0 release notes Junio C Hamano
  2006-12-27  8:18 ` Shawn Pearce
  2006-12-27 10:12 ` Jakub Narebski
@ 2006-12-27 12:06 ` Horst H. von Brand
  2006-12-28  2:58   ` Junio C Hamano
  2006-12-28  1:45 ` An early draft of v1.5.0 release notes (2nd ed) Junio C Hamano
  2006-12-28  3:03 ` [RFH] An early draft of v1.5.0 release notes Eric Wong
  4 siblings, 1 reply; 601+ messages in thread
From: Horst H. von Brand @ 2006-12-27 12:06 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <junkio@cox.net> wrote:
> This is still rough, but I think we have a pretty good idea what
> will and what won't be in v1.5.0 by now, and end-of-year is a
> good slow time to summarize what we have done.

Could somebody please summarize how to "upgrade" a repository to the new
layout?  This has got my head spinning... and I'm /not/ cloning the
various repos I've got here just to take advantage of the changes.

Thanks!
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27 10:24   ` Junio C Hamano
  2006-12-27 11:54     ` Johannes Schindelin
@ 2006-12-27 12:12     ` Jakub Narebski
  2006-12-27 13:00       ` Horst H. von Brand
                         ` (2 more replies)
  1 sibling, 3 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-27 12:12 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Junio C Hamano wrote:
>>>
>>>  - The commits referred to by reflog entries are now protected
>>>    against pruning.  The new command "git reflog expire" can be
>>>    used to truncate older reflog entries and entries that refer
>>>    to commits that have been pruned away previously.
>>>
>>>    Existing repositories that have been using reflog may get
>>>    complaints from fsck-objects; please run "git reflog expire
>>>    --all" first to remove reflog entries that refer to commits
>>>    that are no longer in the repository before attempting to
>>>    repack it.
>>
>> That's a bit bad, as it forces to lose some info... but that
>> info was not that useful anyway.
> 
> I am tired of listening to this useless FUD of yours.  You lost
> the information when you pruned away the underlying objects; you
> are not losing information when you expire the reflog entries
> that became useless long time ago.

Sorry, this is a bit of my inner packrat ;-) showing thru.

I'd rather use "git reflog expire --pruned" to remove reflog entries
which refer to commits which are no longer in the repository; I don't
know, perhaps "git reflog expire --all" does that: but there is no
Documentation/git-reflog.txt (and I'm not running 'next' nor 'master'
but 1.4.4.3). So most probably it is just the case of adding an alias
to reflog expire option.

>>>  - A commit object recorded in non UTF-8 encoding records the
>>>    encoding i18n.commitencoding specified in the originating
>>>    repository in a new "encoding" header.  This information is
>>>    used by git-log and friends to reencode the message to UTF-8
>>>    when displaying.
>>
>> I don't quite like it. Why if someone uses different encoding
>> that utf-8 because his terminal is not set to utf-8? Having suddenly
>> what looks like garbage on output, while input was in local encoding
>> (and specified in i18n.commitencoding) is a bit suprising...
> 
> If Luben wants UTF-8 in his project, but somebody he pulled from
> was mistakenly used latin-1, then the commit pulled record
> latin-1 while Luben has i18n.commitencoding in his repository
> set to UTF-8.  Output will be done in UTF-8 for Luben.  For the
> originator of that latin-1 commit, i18n.commitencoding says
> latin-1 (and that was the only reason he managed to create such
> a commit) and git show of that commit would not involve
> recoding.
> 
> At least that is the idea.  Have you spotted a bug, perhaps?

Perhaps that is the idea, but that idea is not described in above
new feature announcement. "... to reencode the message to UTF-8 
when displaying, if needed." would cover it, but perhaps better
would be to cover this in more detail: "reencode message to UTF-8
if i18n.commitencoding is not set to something other than UTF-8",
or "reencode ... to i18n.commitencoding ... if needed".

BTW. what happens for NO_ICONV? Just curious...

-- 
Jakub Narebski
Poland

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27 11:54     ` Johannes Schindelin
@ 2006-12-27 12:15       ` Jakub Narebski
  0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-27 12:15 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git

Johannes Schindelin wrote:

> BTW I think that latin-1 is not a valid encoding name (at least in my 
> setup it isn't), so we should rather talk about iso-8859-1.

"iconv --list" include l1 and latin1 as aliases to the proper name
of encoding, i.e. iso-8859-1; but not latin-2.
-- 
Jakub Narebski
Poland

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27 12:12     ` Jakub Narebski
@ 2006-12-27 13:00       ` Horst H. von Brand
  2006-12-27 19:42         ` Junio C Hamano
  2006-12-27 19:45       ` Junio C Hamano
  2006-12-28  0:32       ` Jakub Narebski
  2 siblings, 1 reply; 601+ messages in thread
From: Horst H. von Brand @ 2006-12-27 13:00 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: Junio C Hamano, git

Jakub Narebski <jnareb@gmail.com> wrote:

[...]

> Perhaps that is the idea, but that idea is not described in above
> new feature announcement. "... to reencode the message to UTF-8 
> when displaying, if needed." would cover it, but perhaps better
> would be to cover this in more detail: "reencode message to UTF-8
> if i18n.commitencoding is not set to something other than UTF-8",
> or "reencode ... to i18n.commitencoding ... if needed".

And what happens to the people who can't/won't display UTF-8? This is a
both a project wide configuration (how does stuff get saved) + a user/local
configuration (how to display stuff).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27 13:00       ` Horst H. von Brand
@ 2006-12-27 19:42         ` Junio C Hamano
  2006-12-28  0:49           ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-27 19:42 UTC (permalink / raw)
  To: Horst H. von Brand; +Cc: Jakub Narebski, git

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

> Jakub Narebski <jnareb@gmail.com> wrote:
>
> [...]
>
>> Perhaps that is the idea, but that idea is not described in above
>> new feature announcement. "... to reencode the message to UTF-8 
>> when displaying, if needed." would cover it, but perhaps better
>> would be to cover this in more detail: "reencode message to UTF-8
>> if i18n.commitencoding is not set to something other than UTF-8",
>> or "reencode ... to i18n.commitencoding ... if needed".
>
> And what happens to the people who can't/won't display UTF-8? This is a
> both a project wide configuration (how does stuff get saved) + a user/local
> configuration (how to display stuff).

Presumably you would do something like:

	git log | tcs -f utf -t latin1 | less

The point being that the input to tcs will be uniformly UTF-8
even the committers used Latin-1 and UTF-8, either carelessly or
deliberately [*1*].

Maybe i18n.displayencoding set to latin1 is what you are after?
I think it might make sense...

In any case, as Jakub and others pointed out, the description
was not nice nor clear.  How about this as an update?

* I18n

 - We have always encouraged the commit message to be encoded in
   UTF-8, but the users are allowed to use legacy encoding as
   appropriate for their projects.  This will continue to be the
   case.  However, a non UTF-8 commit encoding _must_ be
   explicitly set with i18n.commitencoding in the repository
   where a commit is made; otherwise git-commit-tree will
   complain if the log message does not look like a valid UTF-8
   string.

[Side note: in v1.5.0 preview, it only warns about this
 situation; I have a feeling that it might be better to promote
 this to an error and refuse to commit until the user sets
 i18n.commitencoding to the name of the legacy encoding used for
 the project -- this will be a one-time inconvenience but will
 be much better in the long run.]

 - The value of i18n.commitencoding in the originating
   repository is recorded in the commit object on the "encoding"
   header, if it is not UTF-8.  git-log and friends notice this,
   and reencodes the message to the encoding specified with
   i18n.commitencoding when displaying, if they are different.


[Footnote]

*1* For encoding as simple as Latin I do not think it is an
issue, but we do not want to encode everything to UTF-8 at
commit time, because non-reversible conversion can lose
information.  I do not want to rule out a situation where a
particular commit log entry needs to be in an encoding different
from the project norm, which hopefully is UTF-8, because it
needs to describe something in a character that cannot be
reversibly converted to UTF-8 (maybe the project is about iconv
enhancement, the commit fixes something related to irreversible
conversion and the log message wants to give an example).

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27 12:12     ` Jakub Narebski
  2006-12-27 13:00       ` Horst H. von Brand
@ 2006-12-27 19:45       ` Junio C Hamano
  2006-12-28  0:32       ` Jakub Narebski
  2 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-27 19:45 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

Jakub Narebski <jnareb@gmail.com> writes:

> ... I don't
> know, perhaps "git reflog expire --all" does that: but there is no
> Documentation/git-reflog.txt (and I'm not running 'next' nor 'master'
> but 1.4.4.3)...

If that is the case, may I ask you to at least please make it a
habit to read what are relevant to the topic under discussion
before jumping in?  The list traffic is already high enough that
I am spending a lot of time just to skim all the messages posted
here -- I think that time is better spent on development and
improvements.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27 12:12     ` Jakub Narebski
  2006-12-27 13:00       ` Horst H. von Brand
  2006-12-27 19:45       ` Junio C Hamano
@ 2006-12-28  0:32       ` Jakub Narebski
  2 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-28  0:32 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]

Jakub Narebski wrote:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>> Junio C Hamano wrote:
>>>>
>>>>  - The commits referred to by reflog entries are now protected
>>>>    against pruning.  The new command "git reflog expire" can be
>>>>    used to truncate older reflog entries and entries that refer
>>>>    to commits that have been pruned away previously.
>>>>
>>>>    Existing repositories that have been using reflog may get
>>>>    complaints from fsck-objects; please run "git reflog expire
>>>>    --all" first to remove reflog entries that refer to commits
>>>>    that are no longer in the repository before attempting to
>>>>    repack it.
[...]

> I'd rather use "git reflog expire --pruned" to remove reflog entries
> which refer to commits which are no longer in the repository; I don't
> know, perhaps "git reflog expire --all" does that: but there is no
> Documentation/git-reflog.txt (and I'm not running 'next' nor 'master'
> but 1.4.4.3). So most probably it is just the case of adding an alias
> to reflog expire option.

Thanks for adding Documentation/git-reflog.txt. Nevertheless it didn't
add the information that "git reflog expire" removes reflog entries that
refer to commits that are no longer in the repository (see attached patch).

I'm not sure if such technical information should be in git-reflog(1),
but does only second, current sha1 in reflog line matters for prune?
And does expiring rewrite reflog (previous sha1, making always previous
sha1 (first sha1 in reflog line) always to refer some commit in earlier
reflog line, or before first reflog line), or only delete lines?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

[-- Attachment #2: [PATCH] Add information in git-reflog(1) that "expire" removes pruned entries --]
[-- Type: text/plain, Size: 1327 bytes --]

>From c39e864dec5fc5542e9dd14235a48fa2bb77ed6a Mon Sep 17 00:00:00 2001
From: Jakub Narebski <jnareb@gmail.com>
Date: Thu, 28 Dec 2006 01:30:05 +0100
Subject: [PATCH] Add information in git-reflog(1) that "expire" removes pruned entries

Add information to Documentation/git-reflog.txt that "expire" subcommand
also removes entries which refer to commits that are no longer in
repository.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
 Documentation/git-reflog.txt |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 55a24d3..04ea51a 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -22,11 +22,12 @@ updated.  This command is to manage the information recorded in it.
 The subcommand "expire" is used to prune older reflog entries.
 Entries older than `expire` time, or entries older than
 `expire-unreachable` time and are not reachable from the current
-tip, are removed from the reflog.  This is typically not used
+tip, are removed from the reflog.  Entries which refer to
+commits that are no longer in the repository are pruned
+regardless of their age.  This command is typically not used
 directly by the end users -- instead, see gitlink:git-gc[1].
 
 
-
 OPTIONS
 -------
 
-- 
1.4.4.3


^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27 19:42         ` Junio C Hamano
@ 2006-12-28  0:49           ` Junio C Hamano
  2006-12-28  1:44             ` Nicolas Pitre
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-28  0:49 UTC (permalink / raw)
  To: Horst H. von Brand; +Cc: git

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

> "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> ...
>> And what happens to the people who can't/won't display UTF-8? This is a
>> both a project wide configuration (how does stuff get saved) + a user/local
>> configuration (how to display stuff).
> ...
> Maybe i18n.displayencoding set to latin1 is what you are after?
> I think it might make sense...

I've done this and will be pushing the result out in 'next'
shortly, with a new test.  I find the result mostly sensible.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-28  0:49           ` Junio C Hamano
@ 2006-12-28  1:44             ` Nicolas Pitre
  2006-12-29 11:56               ` David Kågedal
  0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-28  1:44 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Horst H. von Brand, git

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

> Junio C Hamano <junkio@cox.net> writes:
> 
> > "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> > ...
> >> And what happens to the people who can't/won't display UTF-8? This is a
> >> both a project wide configuration (how does stuff get saved) + a user/local
> >> configuration (how to display stuff).
> > ...
> > Maybe i18n.displayencoding set to latin1 is what you are after?
> > I think it might make sense...
> 
> I've done this and will be pushing the result out in 'next'
> shortly, with a new test.  I find the result mostly sensible.

Shouldn't the LANG environment variable be used for this purpose 
instead?


Nicolas

^ permalink raw reply	[flat|nested] 601+ messages in thread

* An early draft of v1.5.0 release notes (2nd ed)
  2006-12-27  7:39 [RFH] An early draft of v1.5.0 release notes Junio C Hamano
                   ` (2 preceding siblings ...)
  2006-12-27 12:06 ` Horst H. von Brand
@ 2006-12-28  1:45 ` Junio C Hamano
  2006-12-28  2:03   ` Shawn Pearce
  2007-01-10  7:58   ` An early draft of v1.5.0 release notes (3rd ed) Junio C Hamano
  2006-12-28  3:03 ` [RFH] An early draft of v1.5.0 release notes Eric Wong
  4 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-28  1:45 UTC (permalink / raw)
  To: git

This incorporates comments from the list (thanks).  Maybe I
should park this in 'todo' branch so that people can review the
updates more easily.

-- >8 --

Major changes that are not news
-------------------------------

There were a handful big changes that happened before this major
release.

This section is for people who are upgrading from ancient
versions.  Some of them are one-way street upgrades -- once you
use the feature your repository cannot be used with ancient git.

 - There is a new configuration variable core.legacyheaders that
   changes the format of loose objects to more efficient to pack
   and send out of the repository over git native protocol.
   However, this format cannot be read by git older than v1.4.2;
   people fetching from your repository using older clients over
   dumb transports (e.g. http) will also be affected.  This is
   not enabled by default.

 - Another configuration repack.usedeltabaseoffset further
   allows packfile to be created in more space efficient format,
   which cannot be read  by git older than v1.4.3.  This is not
   enabled by default.

 - 'git pack-refs' appeared in v1.4.4; this command allows tags
   to be accessed much more efficiently than the traditional
   'one-file-per-tag' format.  Older git-native client can fetch
   from a repository that packed its tags, but older dumb
   transports cannot.  This is done by an explicit user action,
   either by use of "git pack-refs --prune" command or by use of
   "git gc" command.

 - 'git -p' to paginate anything -- many commands do pagination
   by default on a tty.  Introduced between v1.4.1 and v1.4.2;
   this may surprise old timer users.

 - 'git archive' superseded 'git tar' in v1.4.3;

 - 'git cvsserver' was new invention in v1.3.0;

 - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
   seriously enhanced during v1.4.0 timeperiod.

 - 'gitweb' became part of git.git during v1.4.0 timeperiod and
   seriously modified since then.

 - reflog is an v1.4.0 invention.


Updates in v1.5.0 since v1.4.4 series
-------------------------------------

* Index manipulation

 - git-add is to add contents to the index (aka "staging area"
   for the next commit), whether the file the contents happen to
   be is an existing one or a newly created one.

 - git-add without any argument does not add everything
   anymore.  Use 'git-add .' instead.  Also you can add
   otherwise ignored files with an -f option.

 - git-add tries to be more friendly to users by offering an
   interactive mode.

 - git-commit <path> used to refuse to commit if <path> was
   different between HEAD and the index (i.e. update-index was
   used on it earlier).  This check was removed.

 - git-rm is much saner and safer.  It is used to remove paths
   from both the index file and the working tree, and makes sure
   you are not losing any local modification before doing so.

 - git-reset <tree> <paths>... can be used to revert index
   entries for selected paths.

 - git-update-index is much less visible.


* Repository layout and objects transfer

 - The data for origin repository is stored in the configuration
   file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
   created clones (the latter is still supported).

 - git-clone always uses what is known as "separate remote"
   layout for a newly created repository with a working tree;
   i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are
   used to track branches from the origin.  New branches that
   appear on the origin side after a clone is made are also
   tracked automatically.

 - git-branch and git-show-branch know remote tracking branches.

 - git-push can now be used to delete a remote branch or a tag.
   This requires the updated git on the remote side.

 - git-push more agressively keeps the transferred objects
   packed.  Earlier we recommended to monitor amount of loose
   objects and repack regularly, but you should repack when you
   accumulated too many small packs this way as well.  Updated
   git-count-objects helps you with this.


* Reflog

 - Reflog records the history of where the tip of each branch
   was at each moment.  This facility is enabled by default for
   repositories with working trees, and can be accessed with the
   "branch@{time}" and "branch@{Nth}" notation.

 - "git show-branch" learned showing the reflog data with the
   new --reflog option.

 - The commits referred to by reflog entries are now protected
   against pruning.  The new command "git reflog expire" can be
   used to truncate older reflog entries and entries that refer
   to commits that have been pruned away previously with older
   versions of git.

   Existing repositories that have been using reflog may get
   complaints from fsck-objects; please run "git reflog expire
   --all" first to remove reflog entries that refer to commits
   that are no longer in the repository before attempting to
   repack it.

 - git-branch knows how to rename branches and moves existing
   reflog data from the old branch to the new one.


* Packed refs

 - Repositories with hundreds of tags have been paying large
   overhead, both in storage and in runtime.  A new command,
   git-pack-refs, can be used to "pack" them in more efficient
   representation.

 - Clones and fetches over dumb transports are now aware of
   packed refs and can download from repositories that use
   them.


* Configuration

 - configuration related to colorize setting are consolidated
   under color.* namespace (older diff.color.*, status.color.*
   are still supported).


* Less external dependency

 - We no longer require the "merge" program from the RCS suite.
   All 3-way file-level merges are now done internally.

 - The original implementation of git-merge-recursive which was
   in Python has been removed; we have C implementation of it
   now.

 - git-shortlog is no longer a Perl script.  It no longer
   requires output piped from git-log; it can accept revision
   parameters directly on the command line.


* I18n

 - We have always encouraged the commit message to be encoded in
   UTF-8, but the users are allowed to use legacy encoding as
   appropriate for their projects.  This will continue to be the
   case.  However, a non UTF-8 commit encoding _must_ be
   explicitly set with i18n.commitencoding in the repository
   where a commit is made; otherwise git-commit-tree will
   complain if the log message does not look like a valid UTF-8
   string.

 - The value of i18n.commitencoding in the originating
   repository is recorded in the commit object on the "encoding"
   header, if it is not UTF-8.  git-log and friends notice this,
   and reencodes the message to the log output encoding when
   displaying, if they are different.  The log output encoding
   is determined by "git log --encoding=<encoding>",
   i18n.logoutputencoding configuration, or i18n.commitencoding
   configuration, in the decreasing order of preference, and
   defaults to UTF-8. 


* User support

 - Quite a lot of documentation updates.

 - Bash completion scripts have been updated heavily.

 - Better error messages for often used Porcelainish commands.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: An early draft of v1.5.0 release notes (2nd ed)
  2006-12-28  1:45 ` An early draft of v1.5.0 release notes (2nd ed) Junio C Hamano
@ 2006-12-28  2:03   ` Shawn Pearce
  2006-12-28  2:20     ` Junio C Hamano
  2007-01-10  7:58   ` An early draft of v1.5.0 release notes (3rd ed) Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-28  2:03 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <junkio@cox.net> wrote:
> 
> -- >8 --
> 
> Major changes that are not news
> -------------------------------

If these major changes aren't news, what are they?  Chopped liver?
I'm highly confused by the section header.

-- 
Shawn.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: An early draft of v1.5.0 release notes (2nd ed)
  2006-12-28  2:03   ` Shawn Pearce
@ 2006-12-28  2:20     ` Junio C Hamano
  2006-12-28  2:28       ` Shawn Pearce
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-28  2:20 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: git

Shawn Pearce <spearce@spearce.org> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> 
>> -- >8 --
>> 
>> Major changes that are not news
>> -------------------------------
>
> If these major changes aren't news, what are they?

Exactly as described in the part you did not quote:

        There were a handful big changes that happened before this major
        release.

        This section is for people who are upgrading from ancient
        versions.

In other words, they are only to help people who were not paying
enough attention to earlier releases.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: An early draft of v1.5.0 release notes (2nd ed)
  2006-12-28  2:20     ` Junio C Hamano
@ 2006-12-28  2:28       ` Shawn Pearce
  2006-12-28  2:41         ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-28  2:28 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> 
> > Junio C Hamano <junkio@cox.net> wrote:
> >> 
> >> -- >8 --
> >> 
> >> Major changes that are not news
> >> -------------------------------
> >
> > If these major changes aren't news, what are they?
> 
> Exactly as described in the part you did not quote:
> 
>         There were a handful big changes that happened before this major
>         release.
> 
>         This section is for people who are upgrading from ancient
>         versions.
> 
> In other words, they are only to help people who were not paying
> enough attention to earlier releases.

OK, yet again I don't quite quote enough.  Or read enough.  ;-)
 
But maybe you can title the section

	Major changes since 1.2.x

?  Or whatever version preceeded when we started to add that stuff?

The section is really for those who are upgrading from ancient
versions, but the title of the section implies (at least to me)
that these changes aren't something important.

Just my (nearly worthless against the Euro) two US pennies...

-- 
Shawn.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: An early draft of v1.5.0 release notes (2nd ed)
  2006-12-28  2:28       ` Shawn Pearce
@ 2006-12-28  2:41         ` Junio C Hamano
  2006-12-28  2:47           ` Shawn Pearce
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-28  2:41 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: git

Shawn Pearce <spearce@spearce.org> writes:

> The section is really for those who are upgrading from ancient
> versions, but the title of the section implies (at least to me)
> that these changes aren't something important.

True.  How about "Something important you should already know
but just in case" ;-)?

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: An early draft of v1.5.0 release notes (2nd ed)
  2006-12-28  2:41         ` Junio C Hamano
@ 2006-12-28  2:47           ` Shawn Pearce
  2006-12-28  5:54             ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-28  2:47 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> 
> > The section is really for those who are upgrading from ancient
> > versions, but the title of the section implies (at least to me)
> > that these changes aren't something important.
> 
> True.  How about "Something important you should already know
> but just in case" ;-)?

Sure, that's more fun then my proposed text and does summarize the
section better.  Plus it reminds Git users that maybe they should
track our releases a little bit more often than only on "major"
version number increments.  :-)

-- 
Shawn.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27 12:06 ` Horst H. von Brand
@ 2006-12-28  2:58   ` Junio C Hamano
  2006-12-28 11:50     ` Jakub Narebski
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-28  2:58 UTC (permalink / raw)
  To: Horst H. von Brand; +Cc: git

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> This is still rough, but I think we have a pretty good idea what
>> will and what won't be in v1.5.0 by now, and end-of-year is a
>> good slow time to summarize what we have done.
>
> Could somebody please summarize how to "upgrade" a repository to the new
> layout?  This has got my head spinning... and I'm /not/ cloning the
> various repos I've got here just to take advantage of the changes.

The old layout was to map remote branch $B to local tracking
branch .git/refs/heads/$B, unless $B == 'master' in which case
it was mapped to .git/refs/heads/origin (and I think we
discarded 'origin' at remote).

Each remote branch $B is tracked with .git/refs/remote/origin/$B
in the new layout.

And you will get something like this in your .git/config:

    [remote "origin"]
            url = git://git.kernel.org/pub/scm/.../torvalds/linux-2.6.git/
            fetch = refs/heads/*:refs/remotes/origin/*
    [branch "master"]
            remote = origin
            merge = refs/heads/master

The first section defines what the token 'origin' means when you
say "git pull origin" or "git fetch origin".  remote.origin.url
defines the URL to fetch/pull from, and remote.origin.fetch
supplies the refspecs you omitted from the command line (fetch
everything from refs/heads/ hierarchy of remote and store them
in my refs/remotes/origin/ hierarchy).

The second section defines what happens when you say "git pull"
or "git fetch" while on your "master" branch.  It tells that you
meant to say "git pull origin" or "git fetch origin" when you
omitted the URL argument from the command line.  And because you
are also omitting the refspecs, remote.origin.fetch kicks in and
slurps all the branches from the remote side and stores them in
your refs/remotes/origin/ hierarchy.  When the command was "git
pull", it also says the merge that follows the fetch is to merge
the 'master' branch at the remote side (which happens to be
copied to your remotes/origin/master only because you have
remote.origin.fetch) into your current branch (which is
"master", because this section is about what happens while you
are on your "master" branch).

So for an existing repository that does not use the separate
remotes layout, you can easily convert that by hand if you
wanted to by:

 - Move tracking branches from refs/heads/* to
   refs/remotes/origin/*,

 - create the config section like the above in .git/config, and

 - remove .git/remotes/origin when you are done.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-27  7:39 [RFH] An early draft of v1.5.0 release notes Junio C Hamano
                   ` (3 preceding siblings ...)
  2006-12-28  1:45 ` An early draft of v1.5.0 release notes (2nd ed) Junio C Hamano
@ 2006-12-28  3:03 ` Eric Wong
  2006-12-28  5:34   ` Junio C Hamano
  4 siblings, 1 reply; 601+ messages in thread
From: Eric Wong @ 2006-12-28  3:03 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <junkio@cox.net> wrote:
> ancient versions such as v1.1.6 or v1.2.0, and there are a
> handful "one-way-street upgrades" and quite a few user visible
> changes that already have happened before v1.4.4.  Namely:

Addendum:

git-svn related changes:

  - git-svn now requires the Perl SVN:: libraries, the
    command-line backend was too slow and limited.

  - the 'commit' command has been renamed to 'set-tree', and
    'dcommit' is the recommended replacement for day-to-day
    work.

-- 
Eric Wong

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-28  3:03 ` [RFH] An early draft of v1.5.0 release notes Eric Wong
@ 2006-12-28  5:34   ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-28  5:34 UTC (permalink / raw)
  To: Eric Wong; +Cc: git

Eric Wong <normalperson@yhbt.net> writes:

> Addendum:
>
> git-svn related changes:

Thanks.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: An early draft of v1.5.0 release notes (2nd ed)
  2006-12-28  2:47           ` Shawn Pearce
@ 2006-12-28  5:54             ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-28  5:54 UTC (permalink / raw)
  To: Shawn Pearce; +Cc: git

Shawn Pearce <spearce@spearce.org> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> Shawn Pearce <spearce@spearce.org> writes:
>> 
>> > The section is really for those who are upgrading from ancient
>> > versions, but the title of the section implies (at least to me)
>> > that these changes aren't something important.
>> 
>> True.  How about "Something important you should already know
>> but just in case" ;-)?
>
> Sure, that's more fun then my proposed text and does summarize the
> section better.  Plus it reminds Git users that maybe they should
> track our releases a little bit more often than only on "major"
> version number increments.  :-)

That was a tongue-in-cheek comment.

I consider git is still young and I have the right to gripe at
the list if something that has been cooking in 'next' without
anybody complaining causes a real breakage immediately after it
gets pushed out to 'master'.  But for the rest of the world, git
has already matured enough that there is much less need to be on
the bleeding edge for the lack of something crucial in the last
released version.

And let's face it.  Nobody has enough time to keep track of the
changes to all tools he uses, it is not unusual to skip a
handful of minor versions, and it is a norm to get surprised
after an upgrade of any tool because there was a major change in
a couple of releases back that he skipped.  I do not have the
right to complain if the end users do not follow every minor
release or every issue of "What's in git.git" messages.  Not
anymore.

So I'd like the introductory section to have more positive
spin.  I tried rewording it and pushed it out to 'todo' branch.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-28  2:58   ` Junio C Hamano
@ 2006-12-28 11:50     ` Jakub Narebski
  0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-28 11:50 UTC (permalink / raw)
  To: git

[Cc: git@vger.kernel.org, Junio C Hamano <junkio@cox.net>,
 "Horst H. von Brand" <vonbrand@inf.utfsm.cl>]

Junio C Hamano wrote:

> "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> 
>> Junio C Hamano <junkio@cox.net> wrote:
>>> This is still rough, but I think we have a pretty good idea what
>>> will and what won't be in v1.5.0 by now, and end-of-year is a
>>> good slow time to summarize what we have done.
>>
>> Could somebody please summarize how to "upgrade" a repository to the new
>> layout?  This has got my head spinning... and I'm /not/ cloning the
>> various repos I've got here just to take advantage of the changes.
> 
> The old layout was to map remote branch $B to local tracking
> branch .git/refs/heads/$B, unless $B == 'master' in which case
> it was mapped to .git/refs/heads/origin (and I think we
> discarded 'origin' at remote).

How to discard 'origin' in the new wildcard / globbing remote config?
IIRC there was proposal to use '-' or '!' to exclude branch from
fetching, but no code...

[...]
>  - create the config section like the above in .git/config, and

You can use contrib/remotes2config.sh script...

>  - remove .git/remotes/origin when you are done.
 
...which saves remotes/ under remotes.old/
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [RFH] An early draft of v1.5.0 release notes
  2006-12-28  1:44             ` Nicolas Pitre
@ 2006-12-29 11:56               ` David Kågedal
  0 siblings, 0 replies; 601+ messages in thread
From: David Kågedal @ 2006-12-29 11:56 UTC (permalink / raw)
  To: git

Nicolas Pitre <nico@cam.org> writes:

> On Wed, 27 Dec 2006, Junio C Hamano wrote:
>
>> Junio C Hamano <junkio@cox.net> writes:
>> 
>> > "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
>> > ...
>> >> And what happens to the people who can't/won't display UTF-8? This is a
>> >> both a project wide configuration (how does stuff get saved) + a user/local
>> >> configuration (how to display stuff).
>> > ...
>> > Maybe i18n.displayencoding set to latin1 is what you are after?
>> > I think it might make sense...
>> 
>> I've done this and will be pushing the result out in 'next'
>> shortly, with a new test.  I find the result mostly sensible.
>
> Shouldn't the LANG environment variable be used for this purpose 
> instead?

You mean LC_CTYPE, no?

-- 
David Kågedal

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: An early draft of v1.5.0 release notes (3rd ed)
  2006-12-28  1:45 ` An early draft of v1.5.0 release notes (2nd ed) Junio C Hamano
  2006-12-28  2:03   ` Shawn Pearce
@ 2007-01-10  7:58   ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-01-10  7:58 UTC (permalink / raw)
  To: git

Instead of sending the full text, I'll send out the diff against
the one I sent out on the 27th last month.

 Highlights:

 * Introductory notes have been reworded heavily;

 * I intend to merge bare repository support and detached HEAD
   before v1.5.0, so a section each for them has been added;

 * Sliding mmap and shallow clone are also mentioned.

The full text is available as v1.5.0.txt in 'todo' branch.

--
 v1.5.0.txt |  180 +++++++++++++++++++++++++++++++++++++++++++++++++----------
 1 files changed, 149 insertions(+), 31 deletions(-)

diff --git a/v1.5.0.txt b/v1.5.0.txt
index 671c14b..9bbe825 100644
--- a/v1.5.0.txt
+++ b/v1.5.0.txt
@@ -1,37 +1,54 @@
-Major changes that are not news
--------------------------------
+GIT v1.5.0 Release Notes
+========================
 
-There were a handful big changes that happened before this major
-release.
+Old news
+--------
 
 This section is for people who are upgrading from ancient
-versions.  Some of them are one-way street upgrades -- once you
-use the feature your repository cannot be used with ancient git.
-
- - There is a new configuration variable core.legacyheaders that
-   changes the format of loose objects to more efficient to pack
-   and send out of the repository over git native protocol.
-   However, this format cannot be read by git older than v1.4.2;
-   people fetching from your repository using older clients over
-   dumb transports (e.g. http) will also be affected.  This is
-   not enabled by default.
-
- - Another configuration repack.usedeltabaseoffset further
-   allows packfile to be created in more space efficient format,
-   which cannot be read  by git older than v1.4.3.  This is not
-   enabled by default.
+versions of git.  Although all of the changes in this section
+happened before the current v1.4.4 release, they are summarized
+here in the v1.5.0 release notes for people who skipped earlier
+versions.
+
+In general, you should not have to worry about incompatibility,
+and there is no need to perform "repository conversion" if you
+are updating to v1.5.0.  However, some of the changes are
+one-way street upgrades; once you use them your repository
+can no longer be used with ancient git.
+
+ - There is a configuration variable core.legacyheaders that
+   changes the format of loose objects so that they are more
+   efficient to pack and to send out of the repository over git
+   native protocol, since v1.4.2.  However, loose objects
+   written in the new format cannot be read by git older than
+   that version; people fetching from your repository using
+   older clients over dumb transports (e.g. http) using older
+   versions of git will also be affected.
+
+ - Since v1.4.3, configuration repack.usedeltabaseoffset allows
+   packfile to be created in more space efficient format, which
+   cannot be read by git older than that version.
+
+The above two are not enabled by default and you explicitly have
+to ask for them, because these two features make repositories
+unreadable by older versions of git, and in v1.5.0 we still do
+not enable them by default for the same reason.  We will change
+this default probably 1 year after 1.4.2's release, when it is
+reasonable to expect everybody to have new enough version of
+git.
 
  - 'git pack-refs' appeared in v1.4.4; this command allows tags
    to be accessed much more efficiently than the traditional
-   'one-file-per-tag' format.  Older git-native client can fetch
-   from a repository that packed its tags, but older dumb
-   transports cannot.  This is done by an explicit user action,
-   either by use of "git pack-refs --prune" command or by use of
-   "git gc" command.
+   'one-file-per-tag' format.  Older git-native clients can
+   still fetch from a repository that packed and pruned refs
+   (the server side needs to run the up-to-date version of git),
+   but older dumb transports cannot.  Packing of refs is done by
+   an explicit user action, either by use of "git pack-refs
+   --prune" command or by use of "git gc" command.
 
  - 'git -p' to paginate anything -- many commands do pagination
    by default on a tty.  Introduced between v1.4.1 and v1.4.2;
-   this may surprise old timer users.
+   this may surprise old timers.
 
  - 'git archive' superseded 'git tar' in v1.4.3;
 
@@ -43,7 +60,10 @@ use the feature your repository cannot be used with ancient git.
  - 'gitweb' became part of git.git during v1.4.0 timeperiod and
    seriously modified since then.
 
- - reflog is an v1.4.0 invention.
+ - reflog is an v1.4.0 invention.  This allows you to name a
+   revision that a branch used to be at (e.g. "git diff
+   master@{yesterday} master" allows you to see changes since
+   yesterday's tip of the branch).
 
 
 Updates in v1.5.0 since v1.4.4 series
@@ -80,7 +100,9 @@ Updates in v1.5.0 since v1.4.4 series
 
  - The data for origin repository is stored in the configuration
    file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
-   created clones (the latter is still supported).
+   created clones.  The latter is still supported and there is
+   no need to convert your existing repository if you are
+   already comfortable with your workflow with the layout.
 
  - git-clone always uses what is known as "separate remote"
    layout for a newly created repository with a working tree;
@@ -100,6 +122,26 @@ Updates in v1.5.0 since v1.4.4 series
    accumulated too many small packs this way as well.  Updated
    git-count-objects helps you with this.
 
+ - A new command, git-remote, can help you manage your remote
+   tracking branch definitions.
+
+
+* Bare repositories
+
+ - Certain commands change their behaviour in a bare repository
+   (i.e. a repository without associated working tree).  We use
+   a fairly conservative heuristic (if $GIT_DIR is ".git", or
+   ends with "/.git", the repository is not bare) to decide if a
+   repository is bare, but "core.bare" configuration variable
+   can be used to override the heuristic when it misidentifies
+   your repository.
+
+ - git-fetch used to complain updating the current branch but
+   this is now allowed for a bare repository.
+
+ - NEEDSWORK: We should disable Porcelain-ish commands that
+   require a working tree in a bare repository.
+
 
 * Reflog
 
@@ -118,15 +160,42 @@ Updates in v1.5.0 since v1.4.4 series
    versions of git.
 
    Existing repositories that have been using reflog may get
-   complaints from fsck-objects; please run "git reflog expire
-   --all" first to remove reflog entries that refer to commits
-   that are no longer in the repository before attempting to
-   repack it.
+   complaints from fsck-objects and may not be able to run
+   git-repack; please run "git reflog expire --all" first to
+   remove reflog entries that refer to commits that are no
+   longer in the repository when that happens.
 
  - git-branch knows how to rename branches and moves existing
    reflog data from the old branch to the new one.
 
 
+* Detached HEAD
+
+ - You can give non-branch to "git checkout" now.  This will
+   dissociate your HEAD from any of your branches.  A typical
+   use of this feature is to "look around".  E.g.
+
+	$ git checkout v2.6.16
+	... compile, test, etc.
+	$ git checkout v2.6.17
+	... compile, test, etc.
+
+ - After detaching your HEAD, you can go back to an existing
+   branch with usual "git checkout $branch".  Also you can
+   start a new branch using "git checkout -b $newbranch".
+
+ - You can even pull from other repositories, make merges and
+   commits while your HEAD is detached.  Also you can use "git
+   reset" to jump to arbitrary commit.
+
+   Going back to undetached state by "git checkout $branch" can
+   lose the current stat you arrived in these ways, and "git
+   checkout" refuses when the detached HEAD is not pointed by
+   any existing ref (an existing branch, a remote tracking
+   branch or a tag).  This safety can be overriden with "git
+   checout -f".
+
+
 * Packed refs
 
  - Repositories with hundreds of tags have been paying large
@@ -181,6 +250,24 @@ Updates in v1.5.0 since v1.4.4 series
    configuration, in the decreasing order of preference, and
    defaults to UTF-8. 
 
+ - Tools for e-mailed patch application now default to -u
+   behaviour; i.e. it always re-codes from the e-mailed encoding
+   to the encoding specified with i18n.commitencoding.  This
+   unfortunately forces projects that have happily using a
+   legacy encoding without setting i18n.commitencoding, but
+   taken with other improvement, please excuse us for this very
+   minor one-time inconvenience.
+
+
+* Foreign SCM interfaces
+
+  - git-svn now requires the Perl SVN:: libraries, the
+    command-line backend was too slow and limited.
+
+  - the 'commit' subcommand of git-svn has been renamed to
+    'set-tree', and 'dcommit' is the recommended replacement for
+    day-to-day work.
+
 
 * User support
 
@@ -191,4 +278,35 @@ Updates in v1.5.0 since v1.4.4 series
  - Better error messages for often used Porcelainish commands.
 
 
+* Sliding mmap
+
+ - We used to assume that we can mmap the whole packfile while
+   in use, but with a large project this consumes huge virtual
+   memory space and truly huge ones would not fit in the
+   userland address space on 32-bit platforms.  We now mmap huge
+   packfile in pieces to avoid this problem.
+
+
+* Shallow clones
+
+ - There is a partial support for 'shallow' repositories that
+   keeps only recent history now.  A 'shallow clone' is created
+   by specifying how deep that truncated history should be.
+
+   Currently a shallow repository has number of limitations:
+
+   - Cloning and fetching _from_ a shallow clone are not
+     supported (nor tested -- so they might work by accident but
+     they are not expected to).
+
+   - Pushing from nor into a shallow clone are not expected to
+     work.
+
+   - Merging inside a shallow repository would work as long as a
+     merge base is found in the recent history, but otherwise it
+     will be like merging unrelated histories and may result in
+     huge conflicts.
 
+   but this would be more than adequate for people who want to
+   look at near the tip of a big project with a deep history and
+   send patches in e-mail format.

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* [PATCH for "next"] pretty-formats: add 'format:<string>'
  2006-11-24 12:26                                   ` Han-Wen Nienhuys
  2006-11-24 12:41                                     ` Jakub Narebski
  2006-12-05 22:42                                     ` Johannes Schindelin
@ 2007-02-23  0:35                                     ` Johannes Schindelin
  2007-02-23  1:03                                       ` Han-Wen Nienhuys
  2007-02-23  6:21                                       ` Junio C Hamano
  2 siblings, 2 replies; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-23  0:35 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: git, junkio


With this patch,

$ git show -s \
	--pretty=format:'  Ze komit %h woss%n  dunn buy ze great %an'

shows something like

  Ze komit 04c5c88 woss
  dunn buy ze great Junio C Hamano

The supported placeholders are:

	'%H': commit hash
	'%h': abbreviated commit hash
	'%T': tree hash
	'%t': abbreviated tree hash
	'%P': parent hashes
	'%p': abbreviated parent hashes
	'%an': author name
	'%ae': author email
	'%ad': author date
	'%aD': author date, RFC2822 style
	'%ar': author date, relative
	'%at': author date, UNIX timestamp
	'%cn': committer name
	'%ce': committer email
	'%cd': committer date
	'%cD': committer date, RFC2822 style
	'%cr': committer date, relative
	'%ct': committer date, UNIX timestamp
	'%e': encoding
	'%s': subject
	'%b': body
	'%Cred': switch color to red
	'%Cgreen': switch color to green
	'%Cblue': switch color to blue
	'%Creset': reset color
	'%n': newline

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

	On Fri, 24 Nov 2006, Han-Wen Nienhuys wrote:

	> The recently posted patch documenting is an improvement, but why 
	> not add an option so you can do
	> 
	>   --format 'committer %c\nauthor %a\n'
	>   
	> this catches all combinations, and is easier for scripting.

	So, I overcame my laziness after 91 days...

	Of course, this is not as efficient as it could be: it _will_ get 
	_all_ variables from the commit, even if not needed. However, I 
	don't think that it matters in reality.

	BTW I have not found any implementation of xstrndup(), so I let it 
	be static.

 Documentation/pretty-formats.txt |   44 +++++++++
 commit.c                         |  195 ++++++++++++++++++++++++++++++++++++++
 commit.h                         |    1 +
 log-tree.c                       |    2 +-
 4 files changed, 241 insertions(+), 1 deletions(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index fb0b0b9..2fe6c31 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -77,9 +77,53 @@ displayed in full, regardless of whether --abbrev or
 true parent commits, without taking grafts nor history
 simplification into account.
 
+	* 'format:'
++
+The 'format:' format allows you to specify which information
+you want to show. It works a little bit like printf format,
+with the notable exception that you get a newline with '%n'
+instead of '\n'.
+
+E.g, 'format:"The author of %h was %an, %ar%nThe title was >>%s<<"'
+would show something like this:
+
+The author of fe6e0ee was Junio C Hamano, 23 hours ago
+The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
+
+The placeholders are:
+
+- '%H': commit hash
+- '%h': abbreviated commit hash
+- '%T': tree hash
+- '%t': abbreviated tree hash
+- '%P': parent hashes
+- '%p': abbreviated parent hashes
+- '%an': author name
+- '%ae': author email
+- '%ad': author date
+- '%aD': author date, RFC2822 style
+- '%ar': author date, relative
+- '%at': author date, UNIX timestamp
+- '%cn': committer name
+- '%ce': committer email
+- '%cd': committer date
+- '%cD': committer date, RFC2822 style
+- '%cr': committer date, relative
+- '%ct': committer date, UNIX timestamp
+- '%e': encoding
+- '%s': subject
+- '%b': body
+- '%Cred': switch color to red
+- '%Cgreen': switch color to green
+- '%Cblue': switch color to blue
+- '%Creset': reset color
+- '%n': newline
+
+
 --encoding[=<encoding>]::
 	The commit objects record the encoding used for the log message
 	in their encoding header; this option can be used to tell the
 	command to re-code the commit log message in the encoding
 	preferred by the user.  For non plumbing commands this
 	defaults to UTF-8.
+
diff --git a/commit.c b/commit.c
index 8d279b0..a97aef3 100644
--- a/commit.c
+++ b/commit.c
@@ -3,6 +3,7 @@
 #include "commit.h"
 #include "pkt-line.h"
 #include "utf8.h"
+#include "interpolate.h"
 
 int save_commit_buffer = 1;
 
@@ -36,8 +37,11 @@ struct cmt_fmt_map {
 	{ "full",	5,	CMIT_FMT_FULL },
 	{ "fuller",	5,	CMIT_FMT_FULLER },
 	{ "oneline",	1,	CMIT_FMT_ONELINE },
+	{ "format:",	7,	CMIT_FMT_USERFORMAT},
 };
 
+static char *user_format;
+
 enum cmit_fmt get_commit_format(const char *arg)
 {
 	int i;
@@ -46,6 +50,12 @@ enum cmit_fmt get_commit_format(const char *arg)
 		return CMIT_FMT_DEFAULT;
 	if (*arg == '=')
 		arg++;
+	if (!prefixcmp(arg, "format:")) {
+		if (user_format)
+			free(user_format);
+		user_format = xstrdup(arg + 7);
+		return CMIT_FMT_USERFORMAT;
+	}
 	for (i = 0; i < ARRAY_SIZE(cmt_fmts); i++) {
 		if (!strncmp(arg, cmt_fmts[i].n, cmt_fmts[i].cmp_len) &&
 		    !strncmp(arg, cmt_fmts[i].n, strlen(arg)))
@@ -710,6 +720,188 @@ static char *logmsg_reencode(const struct commit *commit,
 	return out;
 }
 
+static char *xstrndup(const char *text, int len)
+{
+	char *result = xmalloc(len + 1);
+	memcpy(result, text, len);
+	result[len] = '\0';
+	return result;
+}
+
+static void fill_person(struct interp *table, const char *msg, int len)
+{
+	int start, end, tz = 0;
+	unsigned long date;
+	char *ep;
+
+	/* parse name */
+	for (end = 0; end < len && msg[end] != '<'; end++)
+		; /* do nothing */
+	start = end + 1;
+	while (end > 0 && isspace(msg[end - 1]))
+		end--;
+	table[0].value = xstrndup(msg, end);
+
+	if (start >= len)
+		return;
+
+	/* parse email */
+	for (end = start + 1; end < len && msg[end] != '>'; end++)
+		; /* do nothing */
+
+	if (end >= len)
+		return;
+
+	table[1].value = xstrndup(msg + start, end - start);
+
+	/* parse date */
+	for (start = end + 1; start < len && isspace(msg[start]); start++)
+		; /* do nothing */
+	if (start >= len)
+		return;
+	date = strtoul(msg + start, &ep, 10);
+	if (msg + start == ep)
+		return;
+
+	table[5].value = xstrndup(msg + start, ep - msg + start);
+
+	/* parse tz */
+	for (start = ep - msg + 1; start < len && isspace(msg[start]); start++)
+		; /* do nothing */
+	if (start + 1 < len) {
+		tz = strtoul(msg + start + 1, NULL, 10);
+		if (msg[start] == '-')
+			tz = -tz;
+	}
+
+	interp_set_entry(table, 2, show_date(date, tz, 0));
+	interp_set_entry(table, 3, show_rfc2822_date(date, tz));
+	interp_set_entry(table, 4, show_date(date, tz, 1));
+}
+
+static long format_commit_message(const struct commit *commit,
+		const char *msg, char *buf, unsigned long space)
+{
+	struct interp table[] = {
+		{ "%H" },	/* commit hash */
+		{ "%h" },	/* abbreviated commit hash */
+		{ "%T" },	/* tree hash */
+		{ "%t" },	/* abbreviated tree hash */
+		{ "%P" },	/* parent hashes */
+		{ "%p" },	/* abbreviated parent hashes */
+		{ "%an" },	/* author name */
+		{ "%ae" },	/* author email */
+		{ "%ad" },	/* author date */
+		{ "%aD" },	/* author date, RFC2822 style */
+		{ "%ar" },	/* author date, relative */
+		{ "%at" },	/* author date, UNIX timestamp */
+		{ "%cn" },	/* committer name */
+		{ "%ce" },	/* committer email */
+		{ "%cd" },	/* committer date */
+		{ "%cD" },	/* committer date, RFC2822 style */
+		{ "%cr" },	/* committer date, relative */
+		{ "%ct" },	/* committer date, UNIX timestamp */
+		{ "%e" },	/* encoding */
+		{ "%s" },	/* subject */
+		{ "%b" },	/* body */
+		{ "%Cred" },	/* red */
+		{ "%Cgreen" },	/* green */
+		{ "%Cblue" },	/* blue */
+		{ "%Creset" },	/* reset color */
+		{ "%n" }	/* newline */
+	};
+	enum interp_index {
+		IHASH = 0, IHASH_ABBREV,
+		ITREE, ITREE_ABBREV,
+		IPARENTS, IPARENTS_ABBREV,
+		IAUTHOR_NAME, IAUTHOR_EMAIL,
+		IAUTHOR_DATE, IAUTHOR_DATE_RFC2822, IAUTHOR_DATE_RELATIVE,
+		IAUTHOR_TIMESTAMP,
+		ICOMMITTER_NAME, ICOMMITTER_EMAIL,
+		ICOMMITTER_DATE, ICOMMITTER_DATE_RFC2822,
+		ICOMMITTER_DATE_RELATIVE, ICOMMITTER_TIMESTAMP,
+		IENCODING,
+		ISUBJECT,
+		IBODY,
+		IRED, IGREEN, IBLUE, IRESET_COLOR,
+		INEWLINE
+	};
+	struct commit_list *p;
+	char parents[1024];
+	int i;
+	enum { HEADER, SUBJECT, BODY } state;
+
+	if (INEWLINE + 1 != ARRAY_SIZE(table))
+		die("invalid interp table!");
+
+	/* these are independent of the commit */
+	interp_set_entry(table, IRED, "\033[31m");
+	interp_set_entry(table, IGREEN, "\033[32m");
+	interp_set_entry(table, IBLUE, "\033[34m");
+	interp_set_entry(table, IRESET_COLOR, "\033[m");
+	interp_set_entry(table, INEWLINE, "\n");
+
+	/* these depend on the commit */
+	if (!commit->object.parsed)
+		parse_object(commit->object.sha1);
+	interp_set_entry(table, IHASH, sha1_to_hex(commit->object.sha1));
+	interp_set_entry(table, IHASH_ABBREV,
+			find_unique_abbrev(commit->object.sha1,
+				DEFAULT_ABBREV));
+	interp_set_entry(table, ITREE, sha1_to_hex(commit->tree->object.sha1));
+	interp_set_entry(table, ITREE_ABBREV,
+			find_unique_abbrev(commit->tree->object.sha1,
+				DEFAULT_ABBREV));
+	for (i = 0, p = commit->parents;
+			p && i < sizeof(parents) - 1;
+			p = p->next)
+		i += snprintf(parents + i, sizeof(parents) - i - 1, "%s ",
+			sha1_to_hex(p->item->object.sha1));
+	interp_set_entry(table, IPARENTS, parents);
+	for (i = 0, p = commit->parents;
+			p && i < sizeof(parents) - 1;
+			p = p->next)
+		i += snprintf(parents + i, sizeof(parents) - i - 1, "%s ",
+			find_unique_abbrev(p->item->object.sha1,
+				DEFAULT_ABBREV));
+	interp_set_entry(table, IPARENTS_ABBREV, parents);
+
+	for (i = 0, state = HEADER; msg[i] && state < BODY; i++) {
+		int eol;
+		for (eol = i; msg[eol] && msg[eol] != '\n'; eol++)
+			; /* do nothing */
+
+		if (state == SUBJECT) {
+			table[ISUBJECT].value = xstrndup(msg + i, eol - i);
+			i = eol;
+		}
+		if (i == eol) {
+			state++;
+			/* strip empty lines */
+			while (msg[eol + 1] == '\n')
+				eol++;
+		} else if (!prefixcmp(msg + i, "author "))
+			fill_person(table + IAUTHOR_NAME,
+					msg + i + 7, eol - i - 7);
+		else if (!prefixcmp(msg + i, "committer "))
+			fill_person(table + ICOMMITTER_NAME,
+					msg + i + 10, eol - i - 10);
+		else if (!prefixcmp(msg + i, "encoding "))
+			table[IENCODING].value = xstrndup(msg + i, eol - i);
+		i = eol;
+	}
+	if (msg[i])
+		table[IBODY].value = xstrdup(msg + i);
+	for (i = 0; i < ARRAY_SIZE(table); i++)
+		if (!table[i].value)
+			interp_set_entry(table, i, "<unknown>");
+
+	interpolate(buf, space, user_format, table, ARRAY_SIZE(table));
+	interp_clear_table(table, ARRAY_SIZE(table));
+
+	return strlen(buf);
+}
+
 unsigned long pretty_print_commit(enum cmit_fmt fmt,
 				  const struct commit *commit,
 				  unsigned long len,
@@ -727,6 +919,9 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,
 	char *reencoded;
 	char *encoding;
 
+	if (fmt == CMIT_FMT_USERFORMAT)
+		return format_commit_message(commit, msg, buf, space);
+
 	encoding = (git_log_output_encoding
 		    ? git_log_output_encoding
 		    : git_commit_encoding);
diff --git a/commit.h b/commit.h
index c737444..83507a0 100644
--- a/commit.h
+++ b/commit.h
@@ -47,6 +47,7 @@ enum cmit_fmt {
 	CMIT_FMT_FULLER,
 	CMIT_FMT_ONELINE,
 	CMIT_FMT_EMAIL,
+	CMIT_FMT_USERFORMAT,
 
 	CMIT_FMT_UNSPECIFIED,
 };
diff --git a/log-tree.c b/log-tree.c
index ac86194..6ce239d 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -211,7 +211,7 @@ void show_log(struct rev_info *opt, const char *sep)
 				 sha1, sha1);
 			opt->diffopt.stat_sep = buffer;
 		}
-	} else {
+	} else if (opt->commit_format != CMIT_FMT_USERFORMAT) {
 		fputs(diff_get_color(opt->diffopt.color_diff, DIFF_COMMIT),
 		      stdout);
 		if (opt->commit_format != CMIT_FMT_ONELINE)
-- 
1.5.0.1.620.gac8f

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
  2007-02-23  0:35                                     ` [PATCH for "next"] pretty-formats: add 'format:<string>' Johannes Schindelin
@ 2007-02-23  1:03                                       ` Han-Wen Nienhuys
  2007-02-23  1:07                                         ` Johannes Schindelin
  2007-02-23  6:21                                       ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Han-Wen Nienhuys @ 2007-02-23  1:03 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, junkio

Johannes Schindelin escreveu:
> With this patch,
> 
> $ git show -s \
> 	--pretty=format:'  Ze komit %h woss%n  dunn buy ze great %an'
> 
> shows something like
> 
>   Ze komit 04c5c88 woss
>   dunn buy ze great Junio C Hamano
> 
> The supported placeholders are:

nitpick:

  \n

for newline would be nice. Similar for backslash, formfeed, alarm, etc.

 

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
  2007-02-23  1:03                                       ` Han-Wen Nienhuys
@ 2007-02-23  1:07                                         ` Johannes Schindelin
  2007-02-23 19:53                                           ` Robin Rosenberg
  0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-23  1:07 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: git, junkio

Hi,

On Fri, 23 Feb 2007, Han-Wen Nienhuys wrote:

> nitpick:
> 
>   \n
> 
> for newline would be nice. Similar for backslash, formfeed, alarm, etc.

Yes, I thought about that. But it would change behaviour (even if I don't 
think it would do serious damage; the only user of interpolate.[ch] I saw 
is git-daemon, and that does not need \n, I guess).

Besides, "%n" is

- more consistent,
- date(1) does it the same way, and
- you can put BS, FF, AL, etc. into the format string before passing 
  it as an option to git; git does not have to help you there.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
  2007-02-23  0:35                                     ` [PATCH for "next"] pretty-formats: add 'format:<string>' Johannes Schindelin
  2007-02-23  1:03                                       ` Han-Wen Nienhuys
@ 2007-02-23  6:21                                       ` Junio C Hamano
  2007-02-23 11:48                                         ` Johannes Schindelin
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-23  6:21 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, git, junkio

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

> With this patch,
>
> $ git show -s \
> 	--pretty=format:'  Ze komit %h woss%n  dunn buy ze great %an'
>
> shows something like
>
>   Ze komit 04c5c88 woss
>   dunn buy ze great Junio C Hamano

Does it say "This commit is by a fool whose name is blah"?

> The supported placeholders are:
>
> 	'%H': commit hash
>...
> 	'%b': body

Hmmm.  Would we want to make them somehow interoperable with
git-for-each-ref format atoms?

Also, it _might_ be worthwhile to do something like "%+4b"
which means "indent each line of this field with 4 spaces", for
a multi-line field like "%b".

> 	'%Cred': switch color to red
> 	'%Cgreen': switch color to green
> 	'%Cblue': switch color to blue
> 	'%Creset': reset color

Hmmm.  I strongly suspect that we would want to reuse code to
grok colors and attributes in color.c.

> 	>   --format 'committer %c\nauthor %a\n'
> 	>   
> 	> this catches all combinations, and is easier for scripting.

I do not have strong preference between "\n" and "%n".

> 	So, I overcame my laziness after 91 days...

Thanks.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
  2007-02-23  6:21                                       ` Junio C Hamano
@ 2007-02-23 11:48                                         ` Johannes Schindelin
  2007-02-23 18:30                                           ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-23 11:48 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Han-Wen Nienhuys, git

Hi,

On Thu, 22 Feb 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > With this patch,
> >
> > $ git show -s \
> > 	--pretty=format:'  Ze komit %h woss%n  dunn buy ze great %an'
> >
> > shows something like
> >
> >   Ze komit 04c5c88 woss
> >   dunn buy ze great Junio C Hamano
> 
> Does it say "This commit is by a fool whose name is blah"?

Vy, it iss korrekt Churmen Inklish [Translation: Why, it is correct 
German "English"]... ;-)

> > The supported placeholders are:
> >
> > 	'%H': commit hash
> >...
> > 	'%b': body
> 
> Hmmm.  Would we want to make them somehow interoperable with
> git-for-each-ref format atoms?

But those placeholders are so long! Not even GNU date supports such long 
placeholders... And I could not reuse interpolate.[ch] as is for that.

> Also, it _might_ be worthwhile to do something like "%+4b" which means 
> "indent each line of this field with 4 spaces", for a multi-line field 
> like "%b".

Same goes here: interpolate.[ch] does not (yet) allow for that.

> > 	'%Cred': switch color to red
> > 	'%Cgreen': switch color to green
> > 	'%Cblue': switch color to blue
> > 	'%Creset': reset color
> 
> Hmmm.  I strongly suspect that we would want to reuse code to grok 
> colors and attributes in color.c.

And again...

> > 	>   --format 'committer %c\nauthor %a\n'
> > 	>   
> > 	> this catches all combinations, and is easier for scripting.
> 
> I do not have strong preference between "\n" and "%n".

This would be easy, methink, to teach to interpolate().

Maybe I can overcome my laziness, and extend interpolate() so that it can 
actually call callbacks with callback data...

Alternatively, I could imitate for-each-ref, and roll my own 
interpolate()? :-)

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
  2007-02-23 11:48                                         ` Johannes Schindelin
@ 2007-02-23 18:30                                           ` Junio C Hamano
  2007-02-23 18:38                                             ` Johannes Schindelin
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-23 18:30 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, git

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

>> > The supported placeholders are:
>> >
>> > 	'%H': commit hash
>> >...
>> > 	'%b': body
>> 
>> Hmmm.  Would we want to make them somehow interoperable with
>> git-for-each-ref format atoms?
>
> But those placeholders are so long! Not even GNU date supports such long 
> placeholders... And I could not reuse interpolate.[ch] as is for that.

What I was hinting at was to fix (or extend) for-each-ref to
accept these short-and-sweet placeholders.

>> Also, it _might_ be worthwhile to do something like "%+4b" which means 
>> "indent each line of this field with 4 spaces", for a multi-line field 
>> like "%b".
>
> Same goes here: interpolate.[ch] does not (yet) allow for that.

Nah, if you feel it is too much work, I trust your judgement (I
do not recall details of how interpolate.c does its thing).  I
do not think it's worth it.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
  2007-02-23 18:30                                           ` Junio C Hamano
@ 2007-02-23 18:38                                             ` Johannes Schindelin
  0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-23 18:38 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Han-Wen Nienhuys, git

Hi,

On Fri, 23 Feb 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> > The supported placeholders are:
> >> >
> >> > 	'%H': commit hash
> >> >...
> >> > 	'%b': body
> >> 
> >> Hmmm.  Would we want to make them somehow interoperable with 
> >> git-for-each-ref format atoms?
> >
> > But those placeholders are so long! Not even GNU date supports such 
> > long placeholders... And I could not reuse interpolate.[ch] as is for 
> > that.
> 
> What I was hinting at was to fix (or extend) for-each-ref to accept 
> these short-and-sweet placeholders.

Ah, the other way round...

> >> Also, it _might_ be worthwhile to do something like "%+4b" which 
> >> means "indent each line of this field with 4 spaces", for a 
> >> multi-line field like "%b".
> >
> > Same goes here: interpolate.[ch] does not (yet) allow for that.
> 
> Nah, if you feel it is too much work, I trust your judgement (I
> do not recall details of how interpolate.c does its thing).  I
> do not think it's worth it.

Sure, it _would_ be nice to let interpolate call back, instead of having 
to fill a table with static strings (xstrdup()ing them, no less).

However, I want to go play Snooker tonight, so this is up-for-grabs.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
  2007-02-23  1:07                                         ` Johannes Schindelin
@ 2007-02-23 19:53                                           ` Robin Rosenberg
  2007-02-24  1:25                                             ` Johannes Schindelin
  0 siblings, 1 reply; 601+ messages in thread
From: Robin Rosenberg @ 2007-02-23 19:53 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, git, junkio

fredag 23 februari 2007 02:07 skrev Johannes Schindelin:
> Hi,
> 
> On Fri, 23 Feb 2007, Han-Wen Nienhuys wrote:
> 
> > nitpick:
> > 
> >   \n
> > 
> > for newline would be nice. Similar for backslash, formfeed, alarm, etc.
> 
> Yes, I thought about that. But it would change behaviour (even if I don't 
> think it would do serious damage; the only user of interpolate.[ch] I saw 
> is git-daemon, and that does not need \n, I guess).
Other tools that come to mind, rpm and clearcase use \n vfor newline in the
format argument, which is good because I can guess that even without looking 
at the documentation. %n I'd guess would be for a number of some kind, e..g.
the ordinal number of the commit listed (in subset and order of the listed commits)

> Besides, "%n" is
> 
> - more consistent,
with...?
> - date(1) does it the same way, and
Ok, I learnt something. Never fi
> - you can put BS, FF, AL, etc. into the format string before passing 
>   it as an option to git; git does not have to help you there.
They are hard to type in shells and even harder in gui's.

-- robin

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
  2007-02-23 19:53                                           ` Robin Rosenberg
@ 2007-02-24  1:25                                             ` Johannes Schindelin
  0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-24  1:25 UTC (permalink / raw)
  To: Robin Rosenberg; +Cc: Han-Wen Nienhuys, git, junkio

Hi,

On Fri, 23 Feb 2007, Robin Rosenberg wrote:

> fredag 23 februari 2007 02:07 skrev Johannes Schindelin:
> > 
> > On Fri, 23 Feb 2007, Han-Wen Nienhuys wrote:
> > 
> > > nitpick:
> > > 
> > >   \n
> > > 
> > > for newline would be nice. Similar for backslash, formfeed, alarm, 
> > > etc.
> > 
> > Yes, I thought about that. But it would change behaviour (even if I 
> > don't think it would do serious damage; the only user of 
> > interpolate.[ch] I saw is git-daemon, and that does not need \n, I 
> > guess).
>
> Other tools that come to mind, rpm and clearcase use \n vfor newline in 
> the format argument, which is good because I can guess that even without 
> looking at the documentation. %n I'd guess would be for a number of some 
> kind, e..g. the ordinal number of the commit listed (in subset and order 
> of the listed commits)

Okay. Patch?

> > Besides, "%n" is
> > 
> > - more consistent,
>
> with...?

... itself? Why should not _one_ escape character be enough?

> > - you can put BS, FF, AL, etc. into the format string before passing
> >   it as an option to git; git does not have to help you there.
>
> They are hard to type in shells and even harder in gui's.

You would not do that all that often, but rather write a script. Even the 
config format allows for inclusion of special characters, so aliases 
should be fine.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2008-07-21  7:09 Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2008-07-21  7:09 UTC (permalink / raw)
  To: git

As announced in a separate message, the tip of master was tagged as
1.6.0-rc0; for people who neglected futureproofing themselves so far, it
would really be a good time to seriously consider doing so.

* The 'maint' branch has these fixes since the last announcement.

Jonathan Nieder (1):
  fix usage string for git grep

Junio C Hamano (1):
  refresh-index: fix bitmask assignment


* The 'master' branch has these since the last announcement
  in addition to the above.

Avery Pennarun (1):
  Reword "your branch has diverged..." lines to reduce line length

Dmitry Potapov (1):
  git-svn: fix git svn info to work without arguments

Junio C Hamano (8):
  rerere.autoupdate: change the message when autoupdate is in effect
  builtin-add.c: restructure the code for maintainability
  git-add --all: add all files
  git-add --all: tests
  git-add --all: documentation
  Link shell with compat layer functions
  Move read_in_full() and write_in_full() to wrapper.c
  "needs update" considered harmful

Lars Noschinski (1):
  cvsserver: Add testsuite for packed refs

Michele Ballabio (2):
  builtin-merge.c: Fix option parsing
  builtin-push.c: Cleanup - use OPT_BIT() and remove some variables

Miklos Vajna (1):
  Teach 'git merge' that some merge strategies no longer exist

Nanako Shiraishi (1):
  git am --abort

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2008-07-20 11:20                                         ` Lars Noschinski
@ 2008-07-20 18:27                                           ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2008-07-20 18:27 UTC (permalink / raw)
  To: Lars Noschinski; +Cc: git

Lars Noschinski <lars-2008-1@usenet.noschinski.de> writes:

> * Junio C Hamano <gitster@pobox.com> [08-07-20 03:59]:
>>Lars Noschinski (2):
>>  cvsserver: Add support for packed refs
>>  cvsserver: Add cvs co -c support
>
> Any specific reason why you did not merge the test for packed refs
> support? Was it considered superfluous?

No, it was not even considered.  This phenomenon is called "lost in the
noise" ;-)

Thanks for reminding.  Applied.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2008-07-20  1:59                                       ` Junio C Hamano
@ 2008-07-20 11:20                                         ` Lars Noschinski
  2008-07-20 18:27                                           ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Lars Noschinski @ 2008-07-20 11:20 UTC (permalink / raw)
  To: git

* Junio C Hamano <gitster@pobox.com> [08-07-20 03:59]:
>Lars Noschinski (2):
>  cvsserver: Add support for packed refs
>  cvsserver: Add cvs co -c support

Any specific reason why you did not merge the test for packed refs
support? Was it considered superfluous?

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-07-16  3:33                                     ` Junio C Hamano
@ 2008-07-20  1:59                                       ` Junio C Hamano
  2008-07-20 11:20                                         ` Lars Noschinski
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-07-20  1:59 UTC (permalink / raw)
  To: git

* The 'maint' branch is at 1.5.6.4.

* The 'master' branch has these since the last announcement
  in addition to what is already in 1.5.6.4.

Alexander Gavrilov (3):
  Avoid rescanning unchanged entries in search for copies.
  Do not try to detect move/copy for entries below threshold.
  Support gitlinks in fast-import.

Eric Raible (1):
  Teach lookup_prog not to select directories

Eric Wong (1):
  t/lib-git-svn: fix SVN_HTTPD tests to work with "trash directory"

Fabian Emmes (2):
  Testsuite: Unset CVS_SERVER
  testsuite for cvs co -c

Johannes Sixt (1):
  builtin-clone: rewrite guess_dir_name()

Junio C Hamano (9):
  git-rebase: report checkout failure
  t/aggregate-results: whitespace fix
  Update draft release notes for 1.6.0
  read-cache.c: typofix
  mailinfo: off-by-one fix for [PATCH (foobar)] removal from Subject: line
  builtin-remote.c: fix earlier "skip_prefix()" conversion
  t9001 (send-email): Do not use hardcoded /bin/sh in test
  .mailmap update
  Getting closer to 1.6.0-rc0

Lars Noschinski (2):
  cvsserver: Add support for packed refs
  cvsserver: Add cvs co -c support

Lukas Sandström (3):
  Make some strbuf_*() struct strbuf arguments const.
  Add some useful functions for strbuf manipulation.
  git-mailinfo: use strbuf's instead of fixed buffers

Miklos Vajna (4):
  t0001-init.sh: change confusing directory name
  t1007-hash-object.sh: use quotes for the test description
  git-bisect: use dash-less form on git bisect log
  make remove-dashes: apply to scripts and programs as well, not just to
    builtins

Nanako Shiraishi (3):
  cache-tree.c: make cache_tree_find() static
  builtin-describe.c: make a global variable "pattern" static
  parse-options.c: make check_typos() static

Peter Harris (1):
  Add ANSI control code emulation for the Windows console

Petr Baudis (5):
  Documentation/git-submodule.txt: Add Description section
  Documentation/RelNotes-1.6.0.txt: Expand on the incompatible packfiles
  Documentation/git-submodule.txt: Further clarify the description
  Documentation: How to ignore local changes in tracked files
  Documentation/git-merge.txt: Partial rewrite of How Merge Works

René Scharfe (8):
  archive: remove args member from struct archiver
  add context pointer to read_tree_recursive()
  archive: add baselen member to struct archiver_args
  archive: centralize archive entry writing
  archive: unify file attribute handling
  archive: remove extra arguments parsing code
  archive: make zip compression level independent from core git
  archive: remove unused headers

Stephan Beyer (4):
  t/test-lib.sh: exit with small negagive int is ok with test_must_fail
  t/: Use "test_must_fail git" instead of "! git"
  Make usage strings dash-less
  Link git-shell only to a subset of libgit.a

SungHyun Nam (1):
  t/Makefile: use specified shell when running aggregation script

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-07-14  5:33                                   ` Junio C Hamano
@ 2008-07-16  3:33                                     ` Junio C Hamano
  2008-07-20  1:59                                       ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-07-16  3:33 UTC (permalink / raw)
  To: git

"Merge-in-C" is in, so is "rename .dotest", and remaining Windows bits.
Now it is almost there for 1.6.0-rc0.

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

Alexander N. Gavrilov (1):
  Fix quadratic performance in rewrite_one.

Brian Gernhardt (1):
  Documentation: mention ORIG_HEAD in am, merge, and rebase

Ciaran McCreesh (1):
  Make git-add -i accept ranges like 7-

Dmitry Kakurin (1):
  Fixed text file auto-detection: treat EOF character 032 at the end of
    file as printable

Frederik Schwarzer (1):
  git-svn: typofix

Ian Katz (1):
  tutorial: use prompt with user names in example, to clarify who is doing
    what

Johannes Schindelin (6):
  Convert CR/LF to LF in tag signatures
  Add pretty format %aN which gives the author name, respecting .mailmap
  Move MERGE_RR from .git/rr-cache/ into .git/
  git-gui: MERGE_RR lives in .git/ directly with newer Git versions
  shortlog: support --pretty=format: option
  Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"

João Abecasis (1):
  git-svn: find-rev and rebase for SVN::Mirror repositories

Junio C Hamano (10):
  Introduce get_merge_bases_many()
  Introduce reduce_heads()
  Teach "am" and "rebase" to mark the original position with ORIG_HEAD
  branch --contains: default to HEAD
  branch --merged/--no-merged: allow specifying arbitrary commit
  Teach merge.log to "git-merge" again
  Update draft release notes for 1.6.0
  reduce_heads(): protect from duplicate input
  tutorial: clarify "pull" is "fetch + merge"
  Update draft release notes to 1.6.0

Lukas Sandström (1):
  git-mailinfo: Fix getting the subject from the in-body [PATCH] line

Mark Levedahl (2):
  git-submodule - make "submodule add" more strict, and document it
  git-submodule - register submodule URL if adding in place

Mike Pape (1):
  We need to check for msys as well as Windows in add--interactive.

Miklos Vajna (15):
  Move split_cmdline() to alias.c
  Move commit_list_count() to commit.c
  Move parse-options's skip_prefix() to git-compat-util.h
  Add new test to ensure git-merge handles pull.twohead and pull.octopus
  Move read_cache_unmerged() to read-cache.c
  git-fmt-merge-msg: make it usable from other builtins
  Introduce get_octopus_merge_bases() in commit.c
  Add new test to ensure git-merge handles more than 25 refs.
  Add new test case to ensure git-merge reduces octopus parents when
    possible
  Add new test case to ensure git-merge prepends the custom merge message
  git-commit-tree: make it usable from other builtins
  Fix t7601-merge-pull-config.sh on AIX
  Build in merge
  t6021: add a new test for git-merge-resolve
  Add a new test for git-merge-resolve

Nicolas Pitre (1):
  restore legacy behavior for read_sha1_file()

Olivier Marin (1):
  builtin-rerere: more carefully find conflict markers

Pavel Roskin (1):
  t9600: allow testing with cvsps 2.2, including beta versions

Pierre Habouzit (1):
  parse-options: add PARSE_OPT_LASTARG_DEFAULT flag

Shawn O. Pearce (3):
  bash completion: Append space after file names have been completed
  bash completion: Resolve git show ref:path<tab> losing ref: portion
  bash completion: Remove dashed command completion support

Soeren Finster (1):
  git-gui: Exit shortcut in MacOSX repaired

Steffen Prohaska (3):
  Move code interpreting path relative to exec-dir to new function
    system_path()
  help.c: Add support for htmldir relative to git_exec_path()
  help (Windows): Display HTML in default browser using Windows' shell API

Stephan Beyer (1):
  rerere: Separate libgit and builtin functions

Sverre Hvammen Johansen (1):
  reduce_heads(): thinkofix

Teemu Likonen (1):
  bash: Add long option completion for 'git send-email'

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-07-08  2:46                                 ` Junio C Hamano
@ 2008-07-14  5:33                                   ` Junio C Hamano
  2008-07-16  3:33                                     ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-07-14  5:33 UTC (permalink / raw)
  To: git

* The 'maint' branch is at 1.5.6.3

* The 'master' branch has these since the last announcement
  in addition to what's in 1.5.6.3

Abhijit Menon-Sen (2):
  Implement "git stash branch <newbranch> <stash>"
  Add a test for "git stash branch"

Adam Brewster (1):
  Teach git-bundle to read revision arguments from stdin like git-rev-list.

Brandon Casey (1):
  t7701-repack-unpack-unreachable.sh: check timestamp of unpacked objects

Eric Hanchrow (2):
  user-manual: typo and grammar fixes
  Documentation: fix broken "linkgit" links

Eric Raible (2):
  Documentation: tweak use case in "git stash save --keep-index"
  completion: add branch options --contains --merged --no-merged

Jeff King (2):
  Allow per-command pager config
  avoid null SHA1 in oldest reflog

Johannes Schindelin (2):
  Teach "git apply" to prepend a prefix with "--root=<root>"
  Allow cherry-picking root commits

Johannes Sixt (1):
  Provide fallback definitions of PRIu32 and PRIx32

Junio C Hamano (17):
  revision traversal: --children option
  rev-list --children
  builtin-blame.c: move prepare_final() into a separate function.
  builtin-blame.c: allow more than 16 parents
  git-blame --reverse
  Per-ref reflog expiry configuration
  Make default expiration period of reflog used for stash infinite
  apply --root: thinkofix.
  Refactor "tracking statistics" code used by "git checkout"
  git-status: show the remote tracking statistics
  git-branch -v: show the remote tracking statistics
  stat_tracking_info(): clear object flags used during counting
  branch -r -v: do not spit out garbage
  git-apply --directory: make --root more similar to GNU diff
  Tone down warning about GNU Interactive Tools
  Documentation: update sections on naming revisions and revision ranges
  apply: fix copy/rename breakage

Mark Levedahl (1):
  install-doc-quick - use git --exec-path to find git-sh-setup

Mike Hommey (4):
  Catch failures from t5540-http-push
  Fix http-push test
  Skip t5540-http-push test when USE_CURL_MULTI is undefined
  Avoid apache complaining about lack of server's FQDN

Petr Baudis (1):
  Git.pm: Add remote_refs() git-ls-remote frontend

Pierre Habouzit (12):
  parse-opt: have parse_options_{start,end}.
  parse-opt: Export a non NORETURN usage dumper.
  parse-opt: create parse_options_step.
  parse-opt: do not print errors on unknown options, return -2 intead.
  parse-opt: fake short strings for callers to believe in.
  parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
  revisions: split handle_revision_opt() from setup_revisions()
  git-blame: migrate to incremental parse-option [1/2]
  git-blame: migrate to incremental parse-option [2/2]
  git-blame: fix lapsus
  git-shortlog: migrate to parse-options partially.
  revisions: refactor handle_revision_opt into parse_revision_opt.

Ramsay Allan Jones (3):
  t9113-*.sh: provide user feedback when test skipped
  t9100-git-svn-basic.sh: Fix determination of utf-8 locale
  git-request-pull: replace call to deprecated peek-remote

Robert Shearman (1):
  git-send-email: Fix authenticating on some servers when using TLS.

SZEDER Gábor (1):
  stash: introduce 'stash save --keep-index' option

Shawn O. Pearce (3):
  Correct pack memory leak causing git gc to try to exceed ulimit
  bash completion: Improve responsiveness of git-log completion
  bash completion: Don't offer "a.." as a completion for "a."

Stephan Beyer (3):
  git-am/git-mailsplit: correct synopsis for reading from stdin
  t3404: test two "preserve merges with -p" cases
  Make rebase--interactive use OPTIONS_SPEC

Thomas Rast (3):
  git-add--interactive: replace hunk recounting with apply --recount
  git-add--interactive: remove hunk coalescing
  git-add--interactive: manual hunk editing mode

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-07-06 10:04                               ` Junio C Hamano
@ 2008-07-08  2:46                                 ` Junio C Hamano
  2008-07-14  5:33                                   ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-07-08  2:46 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since 1.5.6.2.

Alex Riesen (1):
  git-clone: remove leftover debugging fprintf().

Brian Hetro (5):
  builtin-log.c: Use 'git_config_string' to get 'format.subjectprefix' and
    'format.suffix'
  convert.c: Use 'git_config_string' to get 'smudge' and 'clean'
  diff.c: Use 'git_config_string' to get 'diff.external'
  http.c: Use 'git_config_string' to clean up SSL config.
  builtin-commit.c: Use 'git_config_string' to get 'commit.template'

Christian Couder (1):
  Fix "config_error_nonbool" used with value instead of key

Gerrit Pape (1):
  git-svn.perl: workaround assertions in svn library 1.5.0

Junio C Hamano (3):
  attribute documentation: keep EXAMPLE at end
  clone -q: honor "quiet" option over native transports.
  mailinfo: feed the correct line length to decode_transfer_encoding()

Matthew Ogilvie (1):
  Documentation cvs: Clarify when a bare repository is needed

Mikael Magnusson (1):
  Fix grammar in git-rev-parse(1).

Nikolaus Schulz (1):
  Documentation: be precise about which date --pretty uses


* The 'master' branch has these since the last announcement
  in addition to the above.

Abhijit Menon-Sen (2):
  git-gui: Move on to the next filename after staging/unstaging a change
  git-gui: Don't select the wrong file if the last listed file is staged.

Daniel Barkalow (1):
  Only use GIT_CONFIG in "git config", not other programs

David Reiss (4):
  Implement normalize_absolute_path
  Fold test-absolute-path into test-path-utils
  Add support for GIT_CEILING_DIRECTORIES
  Eliminate an unnecessary chdir("..")

Dmitry Potapov (1):
  completion.bash: add 'skip' and 'run' to git-bisect

Jakub Narebski (1):
  gitweb: Describe projects_index format in more detail

Johannes Schindelin (3):
  Add another fast-import example, this time for .zip files
  git daemon: avoid calling syslog() from a signal handler
  run_command(): respect GIT_TRACE

Johannes Sixt (1):
  git-gui: Implement "Stage/Unstage Line"

Junio C Hamano (6):
  rerere: rerere_created_at() and has_resolution() abstraction
  git-rerere: detect unparsable conflicts
  rerere: remove dubious "tail_optimization"
  t4200: fix rerere test
  rerere.autoupdate
  Update draft release notes for 1.6.0

Richard Quirk (1):
  git-gui: Fix accidental staged state toggle when clicking top pixel row

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-07-02  6:28                             ` Junio C Hamano
@ 2008-07-06 10:04                               ` Junio C Hamano
  2008-07-08  2:46                                 ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-07-06 10:04 UTC (permalink / raw)
  To: git

With accumulated fixes, the latest maintenance release 1.5.6.2 is out.

On the 'master' front, port to MinGW has now been merged, and the next
major release 1.6.0 is already taking shape.

----------------------------------------------------------------
* The 'master' branch has these since the last announcement
  in addition to what is in maint.

Adam Brewster (1):
  Move read_revisions_from_stdin from builtin-rev-list.c to revision.c

Brian Gernhardt (1):
  Documentation: Point to gitcli(7) from git(1)

Brian Hetro (5):
  builtin-log.c: Use 'git_config_string' to get 'format.subjectprefix' and
    'format.suffix'
  convert.c: Use 'git_config_string' to get 'smudge' and 'clean'
  diff.c: Use 'git_config_string' to get 'diff.external'
  http.c: Use 'git_config_string' to clean up SSL config.
  builtin-commit.c: Use 'git_config_string' to get 'commit.template'

Christian Couder (2):
  Fix "config_error_nonbool" used with value instead of key
  Fix "config_error_nonbool" used with value instead of key

Johannes Schindelin (2):
  Windows: always chmod(, 0666) before unlink().
  git fetch-pack: do not complain about "no common commits" in an empty
    repo

Johannes Sixt (35):
  Add compat/regex.[ch] and compat/fnmatch.[ch].
  Compile some programs only conditionally.
  Add target architecture MinGW.
  Windows: Use the Windows style PATH separator ';'.
  setup.c: Prepare for Windows directory separators.
  Windows: Treat Windows style path names.
  Windows: Handle absolute paths in safe_create_leading_directories().
  Windows: Strip ".exe" from the program name.
  Windows: Implement a wrapper of the open() function.
  Windows: A minimal implemention of getpwuid().
  Windows: Work around misbehaved rename().
  Make my_mktime() public and rename it to tm_to_time_t()
  Windows: Implement gettimeofday().
  Windows: Fix PRIuMAX definition.
  Windows: Implement setitimer() and sigaction().
  Windows: Wrap execve so that shell scripts can be invoked.
  Windows: A pipe() replacement whose ends are not inherited to children.
  Windows: Implement start_command().
  Windows: A rudimentary poll() emulation.
  Windows: Disambiguate DOS style paths from SSH URLs.
  Windows: Implement asynchronous functions as threads.
  Windows: Work around incompatible sort and find.
  Windows: Implement wrappers for gethostbyname(), socket(), and connect().
  Windows: Implement a custom spawnve().
  Windows: Add a custom implementation for utime().
  Windows: Use a customized struct stat that also has the st_blocks member.
  Turn builtin_exec_path into a function.
  Windows: Compute the fallback for exec_path from the program invocation.
  Windows: Use a relative default template_dir and ETC_GITCONFIG
  When installing, be prepared that template_dir may be relative.
  Windows: Make the pager work.
  Windows: Work around an oddity when a pipe with no reader is written to.
  Windows: Make 'git help -a' work.
  Windows: TMP and TEMP environment variables specify a temporary
    directory.
  t4127-apply-same-fn: Avoid sed -i

Jonathan Nieder (15):
  git-format-patch(1): fix stray \ in output
  Documentation: fix gitlinks
  manpages: fix bogus whitespace
  git(1): add comma
  git-commit(1): depersonalize description
  Documentation: rewrap to prepare for "git-" vs "git " change
  Documentation: more "git-" versus "git " changes
  gitdiffcore(7): fix awkward wording
  manpages: italicize command names in synopses
  manpages: italicize command names
  manpages: italicize git command names (which were in teletype font)
  manpages: italicize gitk's name (where it was in teletype font)
  manpages: italicize nongit command names (if they are in teletype font)
  manpages: italicize git subcommand names (which were in teletype font)
  manpages: use teletype font for sample command lines

Junio C Hamano (3):
  fast-export --export-marks: fix off by one error
  attribute documentation: keep EXAMPLE at end
  clone -q: honor "quiet" option over native transports.

Marius Storm-Olsen (1):
  Windows: Add a new lstat and fstat implementation based on Win32 API.

Matthew Ogilvie (1):
  Documentation cvs: Clarify when a bare repository is needed

Miklos Vajna (6):
  Retire 'stupid' merge strategy
  INSTALL: Update section about git-frotz form.
  hg-to-git: avoid raising a string exception
  hg-to-git: abort if the project directory is not a hg repo
  hg-to-git: rewrite "git-frotz" to "git frotz"
  hg-to-git: use git init instead of git init-db

Nikolaus Schulz (1):
  Documentation: be precise about which date --pretty uses

Ramsay Allan Jones (1):
  Fix some warnings (on cygwin) to allow -Werror

Steffen Prohaska (2):
  Windows: Fix ntohl() related warnings about printf formatting
  compat/pread.c: Add a forward declaration to fix a warning

Thomas Rast (2):
  git-send-email: Do not attempt to STARTTLS more than once
  Fix apply --recount handling of no-EOL line

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-06-25  9:34                           ` Junio C Hamano
@ 2008-07-02  6:28                             ` Junio C Hamano
  2008-07-06 10:04                               ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-07-02  6:28 UTC (permalink / raw)
  To: git

There are a few fixes on 'maint', in addition to futureproofing of "git
shell" so that eventually we can update the ssh clients to ask for server
side programs using "git upload-pack" syntax without a dash between "git"
and the subcommand name.

Many of the medimu size items for 1.6.0 have been merged to 'master'.  The
port to MinGW series will also be merged shortly.

----------------------------------------------------------------

GIT v1.6.0 Release Notes (draft)
================================

User visible changes
--------------------

With the default Makefile settings, most of the programs are now
installed outside your $PATH, except for "git", "gitk", "git-gui" and
some server side programs that need to be accessible for technical
reasons.  Invoking a git subcommand as "git-xyzzy" from the command
line has been deprecated since early 2006 (and officially announced in
1.5.4 release notes); use of them from your scripts after adding
output from "git --exec-path" to the $PATH is still supported in this
release, but users are again strongly encouraged to adjust their
scripts to use "git xyzzy" form, as we will stop installing
"git-xyzzy" hardlinks for built-in commands in later releases.

Source changes needed for porting to MinGW environment are now all in the
main git.git codebase.

By default, packfiles created with this version uses delta-base-offset
encoding introduced in v1.4.4.  Pack idx files are using version 2 that
allows larger packs and added robustness thanks to its CRC checking,
introduced in v1.5.2.


Updates since v1.5.6
--------------------

(subsystems)

* git-p4 in contrib learned "allowSubmit" configuration to control on
  which branch to allow "submit" subcommand.

(portability)

* Sample hook scripts shipped in templates/ are now suffixed with
  *.sample.  We used to prevent them from triggering by default by
  relying on the fact that we install them as unexecutable, but on
  some filesystems this approach does not work.  Instead of running
  "chmod +x" on them, the users who want to activate these samples
  as-is can now rename them dropping *.sample suffix.

* perl's in-place edit (-i) does not work well without backup files on Windows;
  some tests are rewritten to cope with this.

(documentation)

* Updated howto/update-hook-example

* Got rid of usage of "git-foo" from the tutorial.

* Disambiguating "--" between revs and paths is finally documented.

(performance, robustness, sanity etc.)

* even more documentation pages are now accessible via "man" and "git help".

* reduced excessive inlining to shrink size of the "git" binary.

* verify-pack checks the object CRC when using version 2 idx files.

* When an object is corrupt in a pack, the object became unusable even
  when the same object is available in a loose form,  We now try harder to
  fall back to these redundant objects when able.  In particular, "git
  repack -a -f" can be used to fix such a corruption as long as necessary
  objects are available.

* git-clone does not create refs in loose form anymore (it behaves as
  if you immediately ran git-pack-refs after cloning).  This will help
  repositories with insanely large number of refs.

* core.fsyncobjectfiles configuration can be used to ensure that the loose
  objects created will be fsync'ed (this is only useful on filesystems
  that does not order data writes properly).

* "git commit-tree" plumbing can make Octopus with more than 16 parents.
  "git commit" has been capable of this for quite some time.

(usability, bells and whistles)

* git-apply can handle a patch that touches the same path more than once
  much better than before.

* git-apply can be told not to trust the line counts recorded in the input
  patch but recount, with the new --recount option.

* git-archive can be told to omit certain paths from its output using
  export-ignore attributes.

* git-clone can clone from a remote whose URL would be rewritten by
  configuration stored in $HOME/.gitconfig now.

* git-diff --check now checks leftover merge conflict markers.

* When remote side used to have branch 'foo' and git-fetch finds that now
  it has branch 'foo/bar', it refuses to lose the existing remote tracking
  branch and its reflog.  The error message has been improved to suggest
  pruning the remote if the user wants to proceed and get the latest set
  of branches from the remote, including such 'foo/bar'.

* fast-export learned to export and import marks file; this can be used to
  interface with fast-import incrementally.

* Original SHA-1 value for "update-ref -d" is optional now.

* git-send-mail can talk not just over SSL but over TLS now.

* You can tell "git status -u" to even more aggressively omit checking
  untracked files with --untracked-files=no.

* Error codes from gitweb are made more descriptive where possible, rather
  than "403 forbidden" as we used to issue everywhere.

(internal)


Fixes since v1.5.6
------------------

All of the fixes in v1.5.6 maintenance series are included in
this release, unless otherwise noted.

 * diff -c/--cc showed unnecessary "deletion" lines at the context
   boundary (needs backmerge to maint).

 * "git-clone <src> <dst>" did not create leading directories for <dst>
   like the scripted version used to do (needs backport to maint).


----------------------------------------------------------------

* The 'maint' branch has these fixes since v1.5.6.1.

Avery Pennarun (1):
  git-svn: avoid filling up the disk with temp files.

Björn Steinbrink (1):
  git cat-file: Fix memory leak in batch mode

Eric Wong (1):
  git-svn: don't sanitize remote names in config

Jeff King (1):
  doc/rev-parse: clarify reflog vs --until for specifying revisions

Jochen Voss (1):
  avoid off-by-one error in run_upload_archive

Joey Hess (1):
  fix git config example syntax

Junio C Hamano (5):
  diff --check: do not discard error status upon seeing a good line
  git-shell: accept "git foo" form
  GIT 1.5.4.6
  GIT 1.5.5.5
  Start draft release notes for 1.5.6.2

Thomas Rast (1):
  Fix 'git show' on signed tag of signed tag of commit


* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (1):
  Fix use of "perl -i" on Windows

Brian Gernhardt (2):
  Fix t4017-diff-retval for white-space from wc
  Add test results directory to t/.gitignore

Christian Couder (1):
  help: check early if we have a command, if not try a documentation topic

Dmitry Potapov (2):
  update-hook-example: optionally allow non-fast-forward
  shrink git-shell by avoiding redundant dependencies

Don Zickus (1):
  git-apply: handle a patch that touches the same path more than once
    better

Jeff King (3):
  improve for-each-ref test script
  fetch: report local storage errors in status table
  fetch: give a hint to the user when local refs fail to update

Jing Xue (1):
  Add 'git-p4.allowSubmit' to git-p4

Johan Herland (4):
  Incorporate fetched packs in future object traversal
  Move pack_refs() and friends into libgit
  Prepare testsuite for a "git clone" that packs refs
  Teach "git clone" to pack refs

Johannes Schindelin (4):
  clone: respect url.insteadOf setting in global configs
  commit-tree: lift completely arbitrary limit of 16 parents
  Allow git-apply to recount the lines in a hunk (AKA recountdiff)
  clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig

Jonathan Nieder (7):
  Documentation: fix links to tutorials and other new manual pages
  whitespace fix in Documentation/git-repack.txt
  Documentation: complicate example of "man git-command"
  git-daemon(1): don't assume git-daemon is in /usr/bin
  Documentation: prepare to be consistent about "git-" versus "git "
  Documentation: be consistent about "git-" versus "git "
  Documentation formatting and cleanup

Junio C Hamano (15):
  git-shell: accept "git foo" form
  Prepare execv_git_cmd() for removal of builtins from the filesystem
  Keep some git-* programs in $(bindir)
  Allow "git-reset path" when unambiguous
  Start draft release notes for 1.6.0
  diff --check: explain why we do not care whether old side is binary
  check_and_emit_line(): rename and refactor
  checkdiff: pass diff_options to the callback
  Teach "diff --check" about new blank lines at end
  diff --check: detect leftover conflict markers
  Update sample pre-commit hook to use "diff --check"
  Document the double-dash "rev -- path" disambiguator
  t9700: skip when Test::More is not available
  Update draft release notes for 1.6.0
  Update draft release notes for 1.6.0

Kevin Ballard (1):
  git-send-email: Accept fifos as well as files

Lea Wiemann (5):
  t/test-lib.sh: add test_external and test_external_without_stderr
  Git.pm: add test suite
  gitweb: standarize HTTP status codes
  test-lib.sh: show git init output when in verbose mode
  GIT-VERSION-GEN: do not fail if a 'HEAD' file exists in the working copy

Linus Torvalds (4):
  Split up default "core" config parsing into helper routine
  Split up default "user" config parsing into helper routine
  Split up default "i18n" and "branch" config parsing into helper routines
  Add config option to enable 'fsync()' of object files

Miklos Vajna (1):
  A simple script to parse the results from the testcases

Nanako Shiraishi (1):
  gitcli: Document meaning of --cached and --index

Nguyễn Thái Ngọc Duy (1):
  Move all dashed-form commands to libexecdir

Nicolas Pitre (2):
  repack.usedeltabaseoffset config option now defaults to "true"
  pack.indexversion config option now defaults to 2

Olivier Marin (2):
  Documentation: remove {show,whatchanged}.difftree config options
  show_stats(): fix stats width calculation

Patrick Higgins (1):
  Remove the use of '--' in merge program invocation

Stephan Beyer (2):
  api-builtin.txt: update and fix typo
  t3404: stricter tests for git-rebase--interactive

Sverre Rabbelier (2):
  Modify test-lib.sh to output stats to t/test-results/*
  Hook up the result aggregation in the test makefile.

Ted Percival (1):
  Don't use dash commands (git-foo) in tutorial-2

Thomas Rast (2):
  git-send-email: add support for TLS via Net::SMTP::SSL
  git-send-email: prevent undefined variable warnings if no encryption is
    set

jrnieder@uchicago.edu (1):
  Documentation: don't assume git-sh-setup and git-parse-remote are in PATH

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-06-23  7:25                         ` Junio C Hamano
@ 2008-06-25  9:34                           ` Junio C Hamano
  2008-07-02  6:28                             ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-06-25  9:34 UTC (permalink / raw)
  To: git

We'd need a maint release soon to push out the mkstemp() breakage but not
tonight.  There are a handful changes that are in 'master' and 'next' that
need backport/backmerge before 1.5.6.1 happens.

* The 'maint' branch has these fixes since the last announcement.

Jan Krüger (1):
  git-svn: make rebuild respect rewriteRoot option

Patrick Higgins (1):
  Workaround for AIX mkstemp()


* The 'master' branch has these since the last announcement
  in addition to the above.

Jeff King (1):
  clone: create intermediate directories of destination repo

Junio C Hamano (2):
  pre-rebase hook update
  Ship sample hooks with .sample suffix

Michele Ballabio (1):
  t9301-fast-export.sh: Remove debug line

Nicolas Pitre (8):
  call init_pack_revindex() lazily
  implement some resilience against pack corruptions
  test case for pack resilience against corruptions
  refactor pack structure allocation
  optimize verify-pack a bit
  move show_pack_info() where it belongs
  verify-pack: check packed object CRC when using index version 2
  verify-pack: test for detection of index v2 object CRC mismatch

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-06-21 10:06                       ` Junio C Hamano
@ 2008-06-23  7:25                         ` Junio C Hamano
  2008-06-25  9:34                           ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-06-23  7:25 UTC (permalink / raw)
  To: git

There are a few more fixes destined for maint, being tested in next first.

* The 'maint' branch has these fixes since the last announcement.

Michele Ballabio (1):
  parse-options.c: fix documentation syntax of optional arguments

Stephan Beyer (3):
  api-builtin.txt: update and fix typo
  api-parse-options.txt: Introduce documentation for parse options API
  Extend parse-options test suite


* The 'master' branch has these since the last announcement
  in addition to the above.

Jakub Narebski (2):
  gitweb: Separate filling list of projects info
  gitweb: Separate generating 'sort by' table header

Jeff King (5):
  fix whitespace violations in test scripts
  mask necessary whitespace policy violations in test scripts
  avoid whitespace on empty line in automatic usage message
  avoid trailing whitespace in zero-change diffstat lines
  enable whitespace checking of test scripts

Junio C Hamano (1):
  diff -c/--cc: do not include uninteresting deletion before leading
    context

Karl Hasselström (2):
  Clean up builtin-update-ref's option parsing
  Make old sha1 optional with git update-ref -d

Linus Torvalds (3):
  racy-git: an empty blob has a fixed object name
  Make git_dir a path relative to work_tree in setup_work_tree()
  Shrink the git binary a bit by avoiding unnecessary inline functions

Marius Storm-Olsen (3):
  Add an optional <mode> argument to commit/status -u|--untracked-files
    option
  Add argument 'no' commit/status option -u|--untracked-files
  Add configuration option for default untracked files mode

Nanako Shiraishi (2):
  environment.c: remove unused function
  config.c: make git_env_bool() static

Pieter de Bie (1):
  builtin-fast-export: Add importing and exporting of revision marks

Rafael Garcia-Suarez (1):
  gitweb: remove git_blame and rename git_blame2 to git_blame

René Scharfe (1):
  Teach new attribute 'export-ignore' to git-archive

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-06-18  7:32                     ` Junio C Hamano
  2008-06-18 10:59                       ` Jeff King
@ 2008-06-21 10:06                       ` Junio C Hamano
  2008-06-23  7:25                         ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-06-21 10:06 UTC (permalink / raw)
  To: git

* The 'maint' branch has now preparing for 1.5.6.1, with these noncritical
  fixes.

Brandon Casey (2):
  git-merge.sh: fix typo in usage message: sucesses --> succeeds
  t7502-commit.sh: test_must_fail doesn't work with inline environment
    variables

Dan McGee (1):
  completion: add --graph to log command completion

Jan Krüger (1):
  Documentation: fix formatting in git-svn


* The 'master' branch has these since the last announcement
  in addition to the above.  Not much to see here (yet).

Cristian Peraferrer (1):
  Print errno upon failure to open the COMMIT_EDITMSG file

Jakub Narebski (1):
  t/README: Add 'Skipping Tests' section below 'Running Tests'

Lea Wiemann (1):
  test-lib.sh: add --long-tests option

Lukas Sandström (1):
  Add a helper script to send patches with Mozilla Thunderbird

Shawn O. Pearce (1):
  Correct documentation for git-push --mirror

Teemu Likonen (2):
  bash: Add more option completions for 'git log'
  Add target "install-html" the the top level Makefile

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2008-06-18  7:32                     ` Junio C Hamano
@ 2008-06-18 10:59                       ` Jeff King
  2008-06-21 10:06                       ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Jeff King @ 2008-06-18 10:59 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wed, Jun 18, 2008 at 12:32:05AM -0700, Junio C Hamano wrote:

> I am sending this out just as the final minute preview before 1.5.6 final,
> hopefully tomorrow night.

I sent out a code cleanup for remote.c yesterday that fixes a segfault:

  http://mid.gmane.org/20080616161502.GA7219@sigill.intra.peff.net

I am OK if it doesn't make it in to 1.5.6, but if not, then we should at
least apply the very safe one-liner that prevents the segfault. That
patch is below.

-- >8 --
fix segfault with "git push bogus:bogus"

We try to guess the type of the dst half of the refspec
based on the src half. If the src half is bogus, we ended up
dereferencing NULL.
---
 remote.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/remote.c b/remote.c
index 91e3b11..fd8c71a 100644
--- a/remote.c
+++ b/remote.c
@@ -920,7 +920,8 @@ static int match_explicit(struct ref *src, struct ref *dst,
 	case 0:
 		if (!memcmp(dst_value, "refs/", 5))
 			matched_dst = make_linked_ref(dst_value, dst_tail);
-		else if((dst_guess = guess_ref(dst_value, matched_src)))
+		else if(matched_src &&
+			(dst_guess = guess_ref(dst_value, matched_src)))
 			matched_dst = make_linked_ref(dst_guess, dst_tail);
 		else
 			error("unable to push to unqualified destination: %s\n"
-- 
1.5.6.rc3.160.g2a3c9

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-06-13 10:10                   ` Junio C Hamano
@ 2008-06-18  7:32                     ` Junio C Hamano
  2008-06-18 10:59                       ` Jeff King
  2008-06-21 10:06                       ` Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2008-06-18  7:32 UTC (permalink / raw)
  To: git

I am sending this out just as the final minute preview before 1.5.6 final,
hopefully tomorrow night.

* The 'maint' branch has these fixes since the last announcement.

Junio C Hamano (1):
  diff.c: fix emit_line() again not to add extra line

SZEDER Gábor (1):
  diff: reset color before printing newline


* The 'master' branch has these since the last announcement
  in addition to the above.

Alejandro Mery (1):
  git-am: head -1 is obsolete and doesn't work on some new systems

Avery Pennarun (2):
  git-svn: don't append extra newlines at the end of commit messages.
  git-svn: test that extra blank lines aren't inserted in commit messages.

Christian Couder (2):
  documentation: bisect: remove bits talking about a bisection branch
  Documentation: RelNotes-1.5.6: talk about renamed HTML files

Flavio Poletti (1):
  git-instaweb: improve auto-discovery of httpd and call conventions.

Jakub Narebski (2):
  gitweb: Make it work with $GIT containing spaces
  Use 'trash directory' thoroughly in t/test-lib.sh

Johan Herland (3):
  cpio is no longer used by git-clone
  Consistency: Use "libcurl" instead of "cURL library" and "curl"
  The "curl" executable is no longer required

Junio C Hamano (8):
  t4126: fix test that happened to work due to timing
  sha1_file.c: dead code removal
  GIT 1.5.6-rc3
  Makefile: update check-docs target
  Update RPM spec to drop curl executable requirement
  create_tempfile: make sure that leading directories can be accessible by
    peers
  sha1_file.c: simplify parse_pack_index()
  builtin-rerere: fix a small leak

Lea Wiemann (2):
  gitweb: quote commands properly when calling the shell
  gitweb: remove unused parse_ref method

Linus Torvalds (4):
  Avoid cross-directory renames and linking on object creation
  Make loose object file reading more careful
  Simplify and rename find_sha1_file()
  write_loose_object: don't bother trying to read an old object

Mark Levedahl (1):
  git-submodule - Fix errors regarding resolve_relative_url

Mike Hommey (1):
  Don't allocate too much memory in quote_ref_url

Miklos Vajna (2):
  run-command documentation: fix "memset()" parameter
  path-list documentation: document all functions and data structures

Olivier Marin (1):
  Fix approxidate("never") to always return 0

Pierre Habouzit (1):
  Make git reflog expire honour core.sharedRepository.

René Scharfe (1):
  Ignore .gitattributes in bare repositories

SZEDER Gábor (2):
  git add: add long equivalents of '-u' and '-f' options
  completion: add more 'git add' options

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-06-02  8:01                 ` Junio C Hamano
@ 2008-06-13 10:10                   ` Junio C Hamano
  2008-06-18  7:32                     ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-06-13 10:10 UTC (permalink / raw)
  To: git

Since v1.5.6-rc2 there are handful more fixes.  More important ones among
them are:

 - "git-remote prune -n" fix (Olivier Marin)

 - "git-log --graph --first-parent" fix (Adam Simpkins)

 - "git-fast-export" fix for multi-root repository (Shawn)

 - "gitk" works better with detached HEAD (Paul Mackerras)

Time for -rc3 this weekend and hopefully the final sometime next week.

---
* The 'maint' branch has these fixes since the last announcement.

Björn Steinbrink (1):
  name-rev: Fix segmentation fault when using --all

Fred Maranhão (1):
  fix typo in tutorial

Johannes Sixt (1):
  Remove exec bit from builtin-fast-export.c

Junio C Hamano (1):
  GIT 1.5.5.4

Lea Wiemann (1):
  git-for-each-ref.txt: minor improvements

Michael Dressel (1):
  describe: match pattern for lightweight tags too

Miklos Vajna (1):
  git-read-tree: document -v option.


* The 'master' branch has these since the last announcement
  in addition to the above.

Adam Simpkins (2):
  graph API: fix "git log --graph --first-parent"
  git log --graph: print '*' for all commits, including merges

Alex Riesen (1):
  Fix t5516 on cygwin: it does not like double slashes at the beginning of
    a path

Ask Bjørn Hansen (2):
  gitweb setup instruction: rewrite HEAD and root as well
  send-email: Allow the envelope sender to be set via configuration

Boyd Lynn Gerber (2):
  progress.c: avoid use of dynamic-sized array
  Port to 12 other Platforms.

Chris Ridd (1):
  Improve sed portability

Christian Couder (2):
  documentation: convert "diffcore" and "repository-layout" to man pages
  documentation: move git(7) to git(1)

Daniel Barkalow (1):
  Use nonrelative paths instead of absolute paths for cloned repositories

Dirk Suesserott (1):
  Documentation/git-mailsplit: Enhanced description of -o option

Geoffrey Irving (1):
  doc: adding gitman.info and *.texi to .gitignore

Jakub Narebski (2):
  gitweb: Fix "next" link on bottom of page
  gitweb: Add charset info to "raw" output of 'text/plain' blobs

Jeff King (2):
  Fix "git clone http://$URL" to check out the worktree when asked
  document --pretty=tformat: option

Johannes Schindelin (1):
  merge-recursive: respect core.autocrlf when writing out the result

Johannes Sixt (2):
  rebase --interactive: Compute upstream SHA1 before switching branches
  make_nonrelative_path: Use is_absolute_path()

Junio C Hamano (12):
  commit: drop duplicated parents
  GIT v1.5.6-rc1
  t7502: do not globally unset GIT_COMMITTER_* environment variables
  t7502: tighten loosely written test sequence
  Documentation: git-log cannot use rev-list specific options
  t7502: honor SHELL_PATH
  GIT 1.5.6-rc2
  http-push.c: remove duplicated code
  "remote prune": be quiet when there is nothing to prune
  Documentation/git-pull.txt: Use more standard [NOTE] markup
  Documentation: exclude @pxref{[REMOTES]} from texinfo intermediate output
  user-manual: describe how higher stages are set during a merge

Karl Hasselström (1):
  Revert "git.el: Set process-environment instead of invoking env"

Kevin Ballard (1):
  Documentation/git-filter-branch.txt: Fix description of --commit-filter

Lea Wiemann (5):
  cat-file --batch: flush stdout also when objects are missing
  t1006-cat-file.sh: typo
  cat-file --batch / --batch-check: do not exit if hashes are missing
  Documentation/git-cat-file.txt: add missing line break
  t/.gitattributes: only ignore whitespace errors in test files

Linus Torvalds (1):
  Consolidate SHA1 object file close

Marius Storm-Olsen (1):
  Add testcase for merging in a CRLF repo

Mikael Magnusson (1):
  Typo in RelNotes.

Miklos Vajna (3):
  Strbuf documentation: document most functions
  Remove unused code in parse_commit_buffer()
  git-rebase -i: mention the short command aliases in the todo list

Olivier Marin (4):
  remote show: fix the -n option
  builtin-remote: split show_or_prune() in two separate functions
  remote prune: print the list of pruned branches
  remote show: list tracked remote branches with -n

Paul Mackerras (1):
  gitk: Handle detached heads better

Philippe Bruhat (BooK) (1):
  git-cvsimport: do not fail when CVSROOT is /

Pieter de Bie (1):
  git-send-email: allow whitespace in addressee list

Shawn O. Pearce (1):
  fast-export: Correctly generate initial commits with no parents

Stephan Beyer (6):
  git-commit.txt: Correct option alternatives
  git-commit.txt: Add missing long/short options
  Docs: Use "-l::\n--long\n" format in OPTIONS sections
  Docs: add some long/short options
  git-describe.txt: document --always
  git-name-rev.txt: document --no-undefined and --always

Teemu Likonen (1):
  Print info about "git help COMMAND" on git's main usage pages

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-05-30 20:43               ` Junio C Hamano
@ 2008-06-02  8:01                 ` Junio C Hamano
  2008-06-13 10:10                   ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-06-02  8:01 UTC (permalink / raw)
  To: git

* The 'master' branch has these since the last announcement.  I'll tag
  -rc1 in a few days.  Hopefully we can make this cycle much shorter than
  the painfully long one we had for 1.5.5.

Adam Simpkins (2):
  graph API: improve display of merge commits
  graph API: avoid printing unnecessary padding before some octopus merges

Christian Couder (1):
  Documentation: convert "glossary" and "core-tutorial" to man pages

Christian Engwer (1):
  git-svn fails in prop_walk if $self->{path} is not empty

Jakub Narebski (1):
  gitweb: Remove gitweb/test/ directory

Jamis Buck (1):
  git-reset: honor -q and do not show progress message

John J. Franey (1):
  Clarify description of <repository> argument to pull/fetch for naming
    remotes.

Junio C Hamano (4):
  checkout: make reset_clean_to_new() not die by itself
  checkout: consolidate reset_{to_new,clean_to_new}()
  unpack_trees(): allow callers to differentiate worktree errors from merge
    errors
  checkout: "best effort" checkout

Karl Hasselström (1):
  Fix path duplication in git svn commit-diff

Lea Wiemann (4):
  t/test-lib.sh: resolve symlinks in working directory, for pathname
    comparisons
  Git.pm: fix documentation of hash_object
  glossary: improve a few links
  Git.pm: fix return value of config method

Linus Torvalds (2):
  Make pack creation always fsync() the result
  Remove now unnecessary 'sync()' calls

Luciano Rocha (1):
  git-init: accept --bare option

Marius Storm-Olsen (2):
  Clearify the documentation for core.ignoreStat
  Add shortcut in refresh_cache_ent() for marked entries.

Miklos Vajna (1):
  Revision walking documentation: document most important functions

Nicolas Pitre (1):
  make verify-pack a bit more useful with bad packs

Paolo Bonzini (1):
  rollback lock files on more signals than just SIGINT

Seth Falcon (1):
  Add a --dry-run option to git-svn rebase

Shawn O. Pearce (3):
  Remove unused remote_prefix member in builtin-remote
  Make "git-remote prune" delete refs according to fetch specs
  Make "git-remote rm" delete refs acccording to fetch specs

Stephan Beyer (2):
  Add test cases for git-am
  Merge t4150-am-subdir.sh and t4151-am.sh into t4150-am.sh

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-05-24  1:32             ` Junio C Hamano
@ 2008-05-30 20:43               ` Junio C Hamano
  2008-06-02  8:01                 ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-05-30 20:43 UTC (permalink / raw)
  To: git

[jc: I wrote this a few days ago but did not send it out]

* The 'master' branch has these since 1.5.6-rc0.

Christian Couder (1):
  bisect: use "$GIT_DIR/BISECT_START" to check if we are bisecting

Dmitry V. Levin (1):
  builtin-fetch.c (store_updated_refs): Honor update_local_ref() return
    value

Gerrit Pape (2):
  Documentation/git-bundle.txt: fix synopsis
  commit --interactive: properly update the index before commiting

Jeff King (1):
  clone: make sure we support the transport type

Johannes Schindelin (1):
  hg-to-git: add --verbose option

Johannes Sixt (2):
  t5700-clone-reference: Quote $U
  Revert "filter-branch: subdirectory filter needs --full-history"

Junio C Hamano (19):
  tests: do not use implicit "git diff --no-index"
  diff-files: do not play --no-index games
  "git diff": do not ignore index without --no-index
  Update draft release notes for 1.5.6
  log --graph: do not accept log --graphbogus
  log --pretty: do not accept bogus "--prettyshort"
  Release Notes for 1.5.5.2
  Documentation/git.txt: link to 1.5.5.2 documentation.
  Makefile: fix dependency on wt-status.h
  show-branch --current: do not barf on detached HEAD
  git-diff: allow  --no-index semantics a bit more
  git diff --no-index: default to page like other diff frontends
  GIT 1.5.5.3
  t5100: Avoid filename "nul"
  Git::cat_blob: allow using an empty blob to fix git-svn breakage
  fix sha1_pack_index_name()
  Manual subsection to refer to other pages is SEE ALSO
  Documentation: git-cherry uses git-patch-id
  "git checkout -- paths..." should error out when paths cannot be written

Karl Hasselström (1):
  Add some tests for git update-ref -d

Lea Wiemann (1):
  gitweb: only display "next" links in logs if there is a next page

Michele Ballabio (1):
  Documentation: fix graph in git-rev-parse.txt

Pieter de Bie (1):
  builtin-fast-export: Only output a single parent per line

Shawn O. Pearce (5):
  git-gui: Add a --trace command line option
  git-gui: Handle workdir detection when CYGWIN=nowinsymlinks
  Don't diff empty tree on branch creation in paranoid update hook
  Don't load missing ACL files in paranoid update hook
  Ignore no-op changes in paranoid update hook

Twiinz (1):
  git-gui: Vertically align textboxes with labels

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-05-14 22:35           ` Junio C Hamano
@ 2008-05-24  1:32             ` Junio C Hamano
  2008-05-30 20:43               ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-05-24  1:32 UTC (permalink / raw)
  To: git

Quite a many topics have graduated to 'master' and hopefully we can tag
1.5.6-rc0 this weekend.  At about the same time I'll do 1.5.5.2 out of
'maint' branch, as it has accumulated quite a few fixes as well.

* The 'maint' branch has these fixes since the last announcement.

Heikki Orsila (1):
  Add missing "short" alternative to --date in rev-list-options.txt

Jeff King (2):
  doc/git-daemon: s/uploadarchive/uploadarch/
  git-am: fix typo in usage message

Johannes Sixt (1):
  rev-parse --symbolic-full-name: don't print '^' if SHA1 is not a ref

Jon Loeliger (2):
  git-filter-branch: Clarify file removal example.
  git-show.txt: Not very stubby these days.

Shawn O. Pearce (1):
  Clarify repack -n documentation


* The 'master' branch has these since the last announcement
  in addition to the above.

Adam Simpkins (4):
  revision API: split parent rewriting and parent printing options
  Add history graph API
  log and rev-list: add --graph option
  graph API: eliminate unnecessary indentation

Alex Riesen (7):
  Make the exit code of add_file_to_index actually useful
  Extend interface of add_files_to_cache to allow ignore indexing errors
  Add --ignore-errors to git-add to allow it to skip files with read errors
  Add a test for git-add --ignore-errors
  Add a config option to ignore errors for git-add
  Ensure that a test is run in the trash directory
  Fix t3701 if core.filemode disabled

Anders Waldenborg (1):
  gitweb: Convert string to internal form before chopping in chop_str

Brandon Casey (4):
  repack: modify behavior of -A option to leave unreferenced objects
    unpacked
  git-gc: always use -A when manually repacking
  builtin-gc.c: deprecate --prune, it now really has no effect
  t/Makefile: "trash" directory was renamed recently

Chris Frey (2):
  Documentation/git-prune.txt: document unpacked logic
  Documentation/git-repack.txt: document new -A behaviour

Chris Parsons (1):
  Updated status to show 'Not currently on any branch' in red

Christian Couder (1):
  Documentation: rev-parse: add a few "--verify" and "--default" examples

Christian Stimming (3):
  git-gui: Update German translation
  gitk: Update German translation
  gitk: German translation again updated

Dmitry Potapov (1):
  git-init: autodetect core.ignorecase

Dustin Sallings (1):
  Allow tracking branches to set up rebase by default.

Gerrit Pape (1):
  gitk: Makefile/install: force permissions when installing files and dirs

Gustaf Hendeby (1):
  Documentation: Add missing git svn commands

Heikki Orsila (1):
  Add log.date config variable

Horst H. von Brand (1):
  Fix recipient santitization

Imran M Yousuf (1):
  Use '-f' option to point to the .gitmodules file

Jeff King (2):
  send-email: specify content-type of --compose body
  send-email: rfc2047-quote subject lines with non-ascii characters

Johannes Schindelin (2):
  submodule update: add convenience option --init
  pull --rebase: exit early when the working directory is dirty

Johannes Sixt (1):
  git-gui: Report less precise object estimates for database compression

Lars Hjemli (1):
  revision.c: really honor --first-parent

Marcel Koeppen (2):
  Replace in-place sed in t7502-commit
  Fix prepare-commit-msg hook and replace in-place sed

Michele Ballabio (1):
  gitk: Disable "Reset %s branch to here" when on a detached head

Mike Ralphson (1):
  Makefile: update the default build options for AIX

Miklos Vajna (2):
  git-fast-import: rename cmd_*() functions to parse_*()
  git-merge: exclude unnecessary options from OPTIONS_SPEC

Nicolas Pitre (9):
  pack-objects: small cleanup
  pack-objects: remove some double negative logic
  pack-objects: simplify the condition associated with --all-progress
  pack-objects: clean up write_object() a bit
  pack-objects: move compression code in a separate function
  pack-objects: allow for early delta deflating
  pack-objects: fix early eviction for max depth delta objects
  add a force_object_loose() function
  let pack-objects do the writing of unreachable objects as loose objects

Paolo Bonzini (1):
  add special "matching refs" refspec

Paul Mackerras (37):
  gitk: Use git log without --topo-order and reorganize the commits
    ourselves
  gitk: Fix bug in assigning row numbers to arcs
  gitk: Fix bug in parsing multiple revision arguments
  gitk: Compute row numbers and order tokens lazily
  gitk: Fix a couple of bugs
  gitk: Fix more bugs resulting in Tcl "no such element in array" errors
  gitk: More bug fixes and cleanups
  gitk: Implement date mode in the new framework
  gitk: Fix another collection of bugs
  gitk: Don't try to show local changes from a head that isn't shown
  gitk: Keep the same commits visible as other commits come in
  gitk: Fix some corner cases in the targetid/targetrow stuff
  gitk: Fix a couple of bugs in the find function
  gitk: Fix potential bug with fake commit IDs in renumbervarc
  gitk: Index [fnvr]highlights by id rather than row
  gitk: Fix handling of flag arguments
  gitk: Fix a bug in make_disporder
  gitk: Select head of current branch by default
  gitk: Select something appropriate on cherry-pick, branch reset and
    checkout
  gitk: Fix bug where editing an existing view would cause an infinite loop
  gitk: Fix bug causing Tcl error when no commits are selected
  gitk: Fix cherry-picking to insert a real row not a fake row
  gitk: Cope better with getting commits that we have already seen
  gitk: Fix bug where arcs could get lost
  gitk: Handle updating with path limiting better
  gitk: Fix problems with target row stuff
  gitk: Don't filter view arguments through git rev-parse
  gitk: Correct a few strings and comments to say "git log"
  gitk: Fix some corner cases in computing vrowmod and displayorder
  gitk: Avoid a crash in selectline if commitinfo($id) isn't set
  gitk: Fix problem with target row not being in scroll region
  gitk: Reorganize processing of arguments for git log
  gitk: Fix handling of tree file list with special chars in names
  gitk: Make updates go faster
  gitk: Synchronize highlighting in file view for 'f' and 'b' commands
  gitk: Show current row number and total number of rows
  gitk: Add a progress bar for checking out a head

Peter Karlsson (1):
  gitk: Initial Swedish translation.

Santiago Gala (1):
  gitk: Spanish translation of gitk

Shawn O. Pearce (3):
  git-gui: Don't use '$$cr master' with aspell earlier than 0.60
  git-gui: Setup branch.remote,merge for shorthand git-pull
  git-gui: Delete branches with 'git branch -D' to clear config

Steffen Prohaska (4):
  t0050: Test autodetect core.ignorecase
  t0050: Set core.ignorecase case to activate case insensitivity
  t0050: Add test for case insensitive add
  t0050: Fix merge test on case sensitive file systems

Stephen R. van den Berg (1):
  Simplify and fix --first-parent implementation

Teemu Likonen (1):
  Documentation/git-web--browse.txt: fix small typo

Thomas Arcila (1):
  gitk: Allow users to view diffs in external diff viewer

Trent Piepho (1):
  cvsexportcommit: Create config option for CVS dir

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-05-06  6:38         ` Junio C Hamano
@ 2008-05-14 22:35           ` Junio C Hamano
  2008-05-24  1:32             ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-05-14 22:35 UTC (permalink / raw)
  To: git

The largest change to 'master' in this round is Linus's case insensitivity
changes.  I wanted to get feedback and fixes (if needed) from case
insensitive folks while the topic was still in 'next', but it did not
happen, but this should at least not harm sane filesystems, so let's see
how it goes.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

A Large Angry SCM (1):
  git-repack: re-enable parsing of -n command line option

Dustin Sallings (1):
  Documentation/config.txt: Mention branch.<name>.rebase applies to "git
    pull"

Ian Hilt (1):
  Documentation/git-describe.txt: make description more readable

Jeff King (1):
  doc: clarify definition of "update" for git-add -u

Johannes Sixt (1):
  wt-status.h: declare global variables as extern

Sitaram Chamarty (1):
  builtin-commit.c: add -u as short name for --untracked-files


* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (1):
  Improve reporting of errors in config file routines

Brandon Casey (1):
  compat/fopen.c: avoid clobbering the system defined fopen macro

Bryan Donlan (10):
  git-rebase.sh: Fix --merge --abort failures when path contains whitespace
  config.c: Escape backslashes in section names properly
  git-send-email.perl: Handle shell metacharacters in $EDITOR properly
  test-lib.sh: Add a test_set_editor function to safely set $VISUAL
  Use test_set_editor in t9001-send-email.sh
  test-lib.sh: Fix some missing path quoting
  lib-git-svn.sh: Fix quoting issues with paths containing shell
    metacharacters
  Don't use the 'export NAME=value' in the test scripts.
  Fix tests breaking when checkout path contains shell metacharacters
  Rename the test trash directory to contain spaces.

Caio Marcelo de Oliveira Filho (1):
  git-format-patch: add --no-binary to omit binary changes in the patch.

Christian Couder (12):
  help: use man viewer path from "man.<tool>.path" config var
  documentation: help: add "man.<tool>.path" config variable
  help: use "man.<tool>.cmd" as custom man viewer command
  documentation: help: add info about "man.<tool>.cmd" config var
  documentation: web--browse: add a note about konqueror
  Documentation: rename "hooks.txt" to "githooks.txt" and make it a man
    page
  Documentation: improve "add", "pull" and "format-patch" examples
  Documentation: bisect: add a few "git bisect run" examples
  bisect: print an error message when "git rev-list --bisect-vars" fails
  rev-parse: add test script for "--verify"
  rev-parse: fix using "--default" with "--verify"
  rev-parse --verify: do not output anything on error

Dan McGee (1):
  Allow cherry-pick (and revert) to add signoff line

Daniel Barkalow (2):
  Make walker.fetch_ref() take a struct ref.
  Make ls-remote http://... list HEAD, like for git://...

Dustin Sallings (1):
  Allow tracking branches to set up rebase by default.

Eric Wong (1):
  git-svn: fix cloning of HTTP URLs with '+' in their path

Gerrit Pape (1):
  git-bisect.sh: don't accidentally override existing branch "bisect"

Gustaf Hendeby (1):
  Documentation/config.txt: Add git-gui options

Jakub Narebski (1):
  gitweb: Use feed link according to current view

Jeff King (7):
  add merge.renamelimit config option
  bump rename limit defaults
  diff: make "too many files" rename warning optional
  fix bsd shell negation
  t5000: tar portability fix
  clone: bsd shell portability fix
  filter-branch: fix variable export logic

Johannes Sixt (1):
  compat-util: avoid macro redefinition warning

Junio C Hamano (3):
  diff: a submodule not checked out is not modified
  diff-lib.c: rename check_work_tree_entity()
  is_racy_timestamp(): do not check timestamp for gitlinks

Krzysztof Kowalczyk (1):
  alloc_ref_from_str(): factor out a common pattern of alloc_ref from
    string

Linus Torvalds (12):
  Make unpack_trees_options bit flags actual bitfields
  Move name hashing functions into a file of its own
  Make "index_name_exists()" return the cache_entry it found
  Make hash_name_lookup able to do case-independent lookups
  Add 'core.ignorecase' option
  Make branch merging aware of underlying case-insensitive filsystems
  Make unpack-tree update removed files before any updated files
  When adding files to the index, add support for case-independent matches
  Make git-add behave more sensibly in a case-insensitive environment
  Optimize match_pathspec() to avoid fnmatch()
  Avoid some unnecessary lstat() calls
  Optimize symlink/directory detection

Mark Hills (1):
  Be more careful with objects directory permissions on clone

Miklos Vajna (3):
  git-format-patch: add a new format.cc configuration variable
  git-send-email: add a new sendemail.cc configuration variable
  Add tests for sendemail.cc configuration variable

Ping Yin (2):
  t4027: test diff for submodule with empty directory
  Add t7506 to test submodule related functions for git-status

SZEDER Gábor (5):
  doc: moved merge.* config variables into separate merge-config.txt
  merge, pull: introduce '--(no-)stat' option
  add 'merge.stat' config variable
  fmt-merge-msg: add '--(no-)log' options and 'merge.log' config variable
  merge, pull: add '--(no-)log' command line option

Santi Béjar (3):
  Preparation to call determine_author_info from prepare_to_commit
  commit: Show author if different from committer
  commit: Show committer if automatic

Sebastian Schuberth (1):
  mergetool: Make ECMerge use the settings as specified by the user in the
    GUI

Steven Grimm (1):
  Add svn-compatible "blame" output format to git-svn

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-04-27  6:04       ` Junio C Hamano
@ 2008-05-06  6:38         ` Junio C Hamano
  2008-05-14 22:35           ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-05-06  6:38 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since the last announcement.

Alex Riesen (2):
  Use "=" instead of "==" in condition as it is more portable
  Fix use after free() in builtin-fetch

Dan McGee (1):
  Remove 'header' from --signoff option description

Florian Ragwitz (1):
  filter-branch: Documentation fix.

Jeff King (3):
  fix reflog approxidate parsing bug
  cvsimport: always pass user data to "system" as a list
  checkout: don't rfc2047-encode oneline on detached HEAD

Junio C Hamano (2):
  clone: detect and fail on excess parameters
  fetch-pack: brown paper bag fix

Linus Torvalds (1):
  fetch-pack: do not stop traversing an already parsed commit


* The 'master' branch has these since the last announcement
  in addition to the above.

Adam Simpkins (2):
  Remove dead code: show_log() sep argument and diff_options.msg_sep
  log: print log entry terminator even if the message is empty

Alex Riesen (1):
  Use the modern syntax of git-diff-files in t2002-checkout-cache-u.sh

Bart Trojanowski (1):
  make git-status use a pager

Brandon Casey (1):
  filter-branch.sh: support nearly proper tag name filtering

Christian Couder (3):
  rev-parse: teach "--verify" to be quiet when using "-q" or "--quiet"
  rev-parse: fix --verify to error out when passed junk after a good rev
  Documentation: hooks: fix missing verb in pre-applypatch description

Gustaf Hendeby (2):
  git-svn: Make create-ignore use git add -f
  Documentation: Add create-ignore to git svn manual

Heikki Orsila (4):
  Document functions xmemdupz(), xread() and xwrite()
  Die for an early EOF in a file reading loop
  Make read_in_full() and write_in_full() consistent with xread() and
    xwrite()
  Cleanup xread() loops to use read_in_full()

Jeff King (2):
  git-fetch: always show status of non-tracking-ref fetches
  Documentation: point git-prune users to git-gc

Jon Loeliger (1):
  Add otherwise missing --strict option to unpack-objects summary.

Junio C Hamano (2):
  write_index(): optimize ce_smudge_racily_clean_entry() calls with
    CE_UPTODATE
  diff-files: mark an index entry we know is up-to-date as such

Jörg Sommer (1):
  post-merge: Add it's not executed if merge failed.

Lars Hjemli (7):
  Add platform-independent .git "symlink"
  Teach resolve_gitlink_ref() about the .git file
  Teach git-submodule.sh about the .git file
  Teach GIT-VERSION-GEN about the .git file
  git-branch: add support for --merged and --no-merged
  git-branch.txt: compare --contains, --merged and --no-merged
  Add tests for `branch --[no-]merged`

Liu Yubao (1):
  Documentation on --git-dir and --work-tree

Matthieu Moy (1):
  git-svn: detect and fail gracefully when dcommitting to a void

Miklos Vajna (2):
  git checkout: add -t alias for --track
  INSTALL: add a note about GNU interactive tools has been renamed

Paolo Bonzini (1):
  Add a remote.*.mirror configuration option

Richard Quirk (2):
  bash: Add completion for gitk --merge
  Documentation gitk: Describe what --merge does

Stephen R. van den Berg (1):
  git-svn: Same default as cvsimport when using --use-log-author

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-04-19  8:18     ` Junio C Hamano
@ 2008-04-27  6:04       ` Junio C Hamano
  2008-05-06  6:38         ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-04-27  6:04 UTC (permalink / raw)
  To: git

Post 1.5.5 maintenance track is getting stable and more boring ;-).

* The 'maint' branch has these fixes since v1.5.5.1

Andy Parkins (1):
  post-receive-email: fix accidental removal of a trailing space in
    signature line

Ariel Badichi (2):
  copy.c: copy_fd - correctly report write errors
  archive.c: format_subst - fixed bogus argument to memchr

Brandon Casey (1):
  git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc

Dmitry Potapov (1):
  git-gc --prune is deprecated

Gerrit Pape (1):
  diff-options.txt: document the new "--dirstat" option

Jeff King (5):
  Don't force imap.host to be set when imap.tunnel is set
  t5516: remove ambiguity test (1)
  doc/git-gc: add a note about what is collected
  push: allow unqualified dest refspecs to DWIM
  remote: create fetch config lines with '+'

Junio C Hamano (1):
  write-tree: properly detect failure to write tree objects

Matt Graham (1):
  Linked glossary from cvs-migration page

Matthew Ogilvie (1):
  gitattributes: Fix subdirectory attributes specified from root directory

Michael Weber (1):
  svn-git: Use binmode for reading/writing binary rev maps

Miklos Vajna (1):
  diff options documentation: refer to --diff-filter in --name-status

Sam Vilain (1):
  Amend git-push refspec documentation

Teemu Likonen (1):
  bash: Add completion for git diff --base --ours --theirs

Thomas Guyot-Sionnest (1):
  git-svn bug with blank commits and author file

martin f. krafft (2):
  Escape project name in regexp
  Escape project names before creating pathinfo URLs


* The 'master' branch has these since the last announcement
  in addition to the above.

Clifford Caoile (1):
  git.el: Set process-environment instead of invoking env

Dan McGee (2):
  completion: allow 'git remote' subcommand completion
  completion: remove use of dashed git commands

Heikki Orsila (1):
  Make core.sharedRepository more generic

Jeff King (1):
  git-remote: show all remotes with "git remote show"

Junio C Hamano (5):
  sha1-lookup: more memory efficient search in sorted list of SHA-1
  diff: make --dirstat binary-file safe
  sha1-lookup: make selection of 'middle' less aggressive
  log: teach "terminator" vs "separator" mode to "--pretty=format"
  First batch of post 1.5.5 updates

Matthias Kestenholz (1):
  Use color.ui variable in scripts too

Miklos Vajna (3):
  git-gc --auto: add pre-auto-gc hook
  Documentation/hooks: add pre-auto-gc hook
  contrib/hooks: add an example pre-auto-gc hook

Ping Yin (3):
  git-submodule summary: --for-status option
  builtin-status: submodule summary support
  builtin-status: Add tests for submodule summary

Rafael Garcia-Suarez (1):
  Spelling fixes in the gitweb documentation

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-04-14  7:00   ` Junio C Hamano
@ 2008-04-19  8:18     ` Junio C Hamano
  2008-04-27  6:04       ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-04-19  8:18 UTC (permalink / raw)
  To: git

As quite some fixes have accumulated on 'maint', I am planning to do
1.5.5.1 this Sunday with what is in 'maint', perhaps with the 'rebase: do
not munge commit log message' fix that is in 'master' tonight.

* The 'maint' branch has these fixes since the last announcement.

Alberto Bertogli (1):
  builtin-apply: Show a more descriptive error on failure when opening a
    patch

Christian Couder (2):
  bisect: squelch "fatal: ref HEAD not a symref" misleading message
  git-bisect: make "start", "good" and "skip" succeed or fail atomically

Jakub Narebski (1):
  gitweb: Fix 'history' view for deleted files with history

Jon Loeliger (1):
  Clarify and fix English in "git-rm" documentation

Jonas Fonseca (1):
  git-remote: reject adding remotes with invalid names

Junio C Hamano (2):
  git-am: minor cleanup
  am: POSIX portability fix

Linus Torvalds (2):
  Ignore leading empty lines while summarizing merges
  git-am: cope better with an empty Subject: line

Mark Levedahl (1):
  git-submodule - possibly use branch name to describe a module

Matthieu Moy (1):
  Document that WebDAV doesn't need git on the server, and works over SSL

Scott Collins (1):
  Clarify documentation of git-cvsserver, particularly in relation to
    git-shell

Shawn Bohrer (2):
  git clean: Don't automatically remove directories when run within
    subdirectory
  git clean: Add test to verify directories aren't removed with a prefix


* The 'master' branch has these since the last announcement
  in addition to the above.

Christian Couder (1):
  bisect: add "git bisect help" subcommand to get a long usage string

Johannes Sixt (1):
  builtin-commit.c: Remove a redundant assignment.

Junio C Hamano (3):
  git_config_bool_or_int()
  Fix git_config_bool_or_int
  rebase: do not munge commit log message

Stephan Beyer (1):
  builtin-apply.c: use git_config_string() to get apply_default_whitespace

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-04-09  9:44 ` What's in git.git (stable) Junio C Hamano
@ 2008-04-14  7:00   ` Junio C Hamano
  2008-04-19  8:18     ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-04-14  7:00 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since v1.5.5; perhaps v1.5.5.1 mid
  next week.

Björn Steinbrink (1):
  Fix section about backdating tags in the git-tag docs

Carlos Rica (2):
  Fix documentation syntax of optional arguments in short options.
  core-tutorial.txt: Fix showing the current behaviour.

Christian Couder (2):
  bisect: fix bad rev checking in "git bisect good"
  bisect: report bad rev better

Clifford Caoile (1):
  Docs gitk: Explicitly mention the files that gitk uses (~/.gitk)

Daniel Barkalow (1):
  Fix config key miscount in url.*.insteadOf

Dirk Suesserott (1):
  Documentation/git-request-pull: Fixed a typo ("send" -> "end")

Jeff King (1):
  git-fetch: fix status output when not storing tracking ref

Johannes Sixt (1):
  Document option --only of git commit

Junio C Hamano (3):
  Document -w option to shortlog
  Documentation/git-submodule: typofix
  t7401: squelch garbage output

Michele Ballabio (1):
  revision.c: make --date-order overriddable

Pedro Melo (1):
  Force the medium pretty format on calls to git log

Ping Yin (1):
  git-submodule: Avoid 'fatal: cannot describe' message

René Scharfe (1):
  git-archive: ignore prefix when checking file attribute


* The 'master' branch has these since the last announcement
  in addition to the above.

Christian Couder (1):
  bisect: add "git bisect help" subcommand to get a long usage string

Johannes Sixt (1):
  builtin-commit.c: Remove a redundant assignment.

Junio C Hamano (1):
  git_config_bool_or_int()

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-04-09  6:51 [ANNOUNCE] GIT 1.5.5 Junio C Hamano
@ 2008-04-09  9:44 ` Junio C Hamano
  2008-04-14  7:00   ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-04-09  9:44 UTC (permalink / raw)
  To: git

* The 'master' branch has these since v1.5.5.

Frank Lichtenheld (4):
  var: Don't require to be in a git repository.
  Git.pm: Don't require a repository instance for config
  Git.pm: Don't require repository instance for ident
  send-email: Don't require to be called in a repository

Gerrit Pape (2):
  gitweb: fallback to system-wide config file if default config does not
    exist
  gitweb: fallback to system-wide config file (fixup)

Govind Salinas (1):
  pretty.c: add %x00 format specifier.

Jeff King (2):
  add--interactive: ignore mode change in 'p'atch command
  add--interactive: allow user to choose mode update

Junio C Hamano (4):
  Optimize rename detection for a huge diff
  t5300: add test for "unpack-objects --strict"
  unpack-objects: fix --strict handling
  rebase [--onto O] A B: omit needless checkout

Martin Koegler (3):
  unpack-objects: prevent writing of inconsistent objects
  receive-pack: allow using --strict mode for unpacking objects
  t5300: add test for "index-pack --strict"

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2008-04-04 18:24                           ` Junio C Hamano
@ 2008-04-05  3:13                             ` Shawn O. Pearce
  0 siblings, 0 replies; 601+ messages in thread
From: Shawn O. Pearce @ 2008-04-05  3:13 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <gitster@pobox.com> wrote:
> * The 'master' branch has these since the last announcement and we are now
>   at 1.5.5-rc3.  The real 1.5.5 hopefully this weekend.
...
> Shawn O. Pearce (1):
>   git-gui 0.10

0.10 is a dud on Linux.  My master branch has a bug fix, but I'm
considering bringing in Michele's patch before tagging 0.10.1.

So 0.10.1, most likely tagged in a few hours, should be in 1.5.5.
Otherwise Linux users of git-gui will be sort of pissed.

Damn.

-- 
Shawn.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-03-31  8:39                         ` Junio C Hamano
@ 2008-04-04 18:24                           ` Junio C Hamano
  2008-04-05  3:13                             ` Shawn O. Pearce
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-04-04 18:24 UTC (permalink / raw)
  To: git

* The 'master' branch has these since the last announcement and we are now
  at 1.5.5-rc3.  The real 1.5.5 hopefully this weekend.

Brandon Casey (2):
  mktag.c: improve verification of tagger field and tests
  mktag.c: tweak validation of tagger field and adjust test script

Christian Couder (1):
  help: Add a missing OPT_END().

Damien Diederen (7):
  cvsserver: Respond to the 'editors' and 'watchers' commands
  cvsserver: Only print the file part of the filename in status header
  cvsserver: Do not include status output for subdirectories if -l is
    passed
  cvsserver: Add a few tests for 'status' command
  cvsserver: Implement update -p (print to stdout)
  cvsserver: Add test for update -p
  cvsserver: Use the user part of the email in log and annotate results

Johannes Sixt (3):
  filter-branch: Test renaming directories in a tree-filter
  verify-tag: Clean up the temporary file if gpg cannot be started.
  t7004-tag: Skip more tests if gpg is not available.

Jonathan del Strother (1):
  git-gui: Add shortcut keys for Show More/Less Context

Josh Elsasser (1):
  Allow git-cvsserver database table name prefix to be specified.

Junio C Hamano (2):
  Accept git aliases outside a git repository
  GIT 1.5.5-rc3

Paolo Bonzini (1):
  git-cvsserver: handle change type T

Shawn O. Pearce (1):
  git-gui 0.10

Teemu Likonen (1):
  Describe the bug in handling filenames with funny characters in 'git add
    -i'

veillette@yahoo.ca (1):
  filter-branch: Fix renaming a directory in the tree-filter

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-03-28  1:45                       ` Junio C Hamano
@ 2008-03-31  8:39                         ` Junio C Hamano
  2008-04-04 18:24                           ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-31  8:39 UTC (permalink / raw)
  To: git

A handful fixes are in 'master', and a few topics are still in 'next' as I
ran out of time this weekend.

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

Bryan Donlan (1):
  Silence cpio's "N blocks" output when cloning locally

Eric Wong (1):
  git-svn: remove redundant slashes from show-ignore

Junio C Hamano (4):
  builtin-prune: protect objects listed on the command line
  Add corner case tests for diff-index and diff-files
  diff-index: careful when inspecting work tree items
  diff-files: careful when inspecting work tree items

Marius Storm-Olsen (1):
  git-p4: Handle Windows EOLs properly after removal of p4 submit template
    handling.

Michele Ballabio (3):
  parse-options.c: introduce OPT_DATE
  Add tests for git-prune
  builtin-prune.c: use parse_options()

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-03-23 10:08                     ` Junio C Hamano
@ 2008-03-28  1:45                       ` Junio C Hamano
  2008-03-31  8:39                         ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-28  1:45 UTC (permalink / raw)
  To: git

Again with a handful fixes, the most important of which is for regression
introduced in 1.5.4 to "git fetch" (if you are using .git/branches/it to
name your remote repositories, "git fetch it" should update your local
"it" branch but it doesn't since the breakage), maybe we would need
another maintenance branch soon from 'maint'.

With fixes to a handful regressions in the changes that happened during
the 1.5.5 cycle, 'master' is nearling -rc2, which hopefully will happen
soon.  There still are one or two topics we may want to merge from 'next',
but at this point both testers and developers are encouraged to switch to
'master' if you have been using 'next' for your real work to catch the
last minute glitches.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Brandon Casey (1):
  t/t3800-mktag.sh: use test_must_fail rather than '!'

Daniel Barkalow (2):
  Tighten refspec processing
  Fix branches file configuration

Guanqun Lu (1):
  Fix the wrong output of `git-show v1.3.0~155^2~4` in documentation.

Jeff King (1):
  Documentation: clarify use of .git{ignore,attributes} versus .git/info/*

Junio C Hamano (2):
  git-fetch test: test tracking fetch results, not just FETCH_HEAD
  Update draft release notes for 1.5.4.5


* The 'master' branch has these since the last announcement
  in addition to the above.

Dirk Süsserott (1):
  Documentation: git-tag '-m'/'-F' implies '-a'

Frank Lichtenheld (1):
  t9600-cvsimport.sh: set HOME before checking for cvsps availability

Gerrit Pape (1):
  imap-send: properly error out if imap.host is not set in config

Guanqun Lu (1):
  Fix the wrong output of `git-show v1.3.0~155^2~4` in documentation.

Johannes Schindelin (2):
  RelNotes: mention checkout/branch's --track option, too
  init: show "Reinit" message even in an (existing) empty repository

Johannes Sixt (1):
  builtin-remote: Fix missing newline at end of listing of pushed branches

Julian Phillips (1):
  Documentation/git-checkout: Update summary to reflect current abilities

Junio C Hamano (3):
  refspec: allow colon-less wildcard "refs/category/*"
  test_must_fail: 129 is a valid error code from usage()
  Update draft release notes for 1.5.5

SZEDER Gábor (1):
  Always set *nongit_ok in setup_git_directory_gently()

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-03-14  9:11                   ` Junio C Hamano
@ 2008-03-23 10:08                     ` Junio C Hamano
  2008-03-28  1:45                       ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-23 10:08 UTC (permalink / raw)
  To: git

With a few late topics came quite a few regression fixes to make us ready
for -rc1.

 * gitk, git-gui and git-p4 have been updated.

 * "git gc --auto" annoyance is hopefully reduced away.

 * Breakage in automated tag following by git-fetch rewritten in C has
   hopefully been fixed.

 * Quite a few portability improvements from Solaris porting efforts.

 * "git remote show" does not talk about symrefs anymore.

 * "git help" updates to plug in more backends.

 * "git submodule summary" to show symmetric differences between commits
   in submodules.

---

* The 'maint' branch has these fixes since the last announcement.

Bernt Hansen (1):
  git-new-workdir: Share SVN meta data between work dirs and the repository

Eric Wong (1):
  git-svn: don't blindly append '*' to branch/tags config

Jonas Fonseca (1):
  Make man page building quiet when DOCBOOK_XSL_172 is defined

Junio C Hamano (3):
  format-patch: generate MIME header as needed even when there is
    format.header
  rebase -m: do not trigger pre-commit verification
  Start draft ReleaseNotes for 1.5.4.5

Linus Torvalds (1):
  rev-parse: fix meaning of rev~ vs rev~0.


* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (1):
  git-gui: update russian translation

Brandon Casey (2):
  builtin-gc.c: allow disabling all auto-gc'ing by assigning 0 to gc.auto
  t/t7003-filter-branch.sh: use test_must_fail rather than '!'

Christian Couder (5):
  help: add "man.viewer" config var to use "woman" or "konqueror"
  Documentation: help: describe 'man.viewer' config variable
  help: implement multi-valued "man.viewer" config option
  Documentation: help: explain 'man.viewer' multiple values
  help: warn if specified 'man.viewer' is unsupported, instead of erroring
    out

Daniel Barkalow (4):
  Write diff output to a file in struct diff_options
  Tighten refspec processing
  Fix t3200 config
  Fix tag following

David Aguilar (1):
  gitk: Don't show local changes when we there is no work tree

Eyvind Bernhardsen (2):
  fast-import: Allow "reset" to delete a new branch without error
  fast-import: Document the effect of "merge" with no "from" in a commit

Jeff King (15):
  gitk: make autoselect optional
  tr portability fixes
  t0050: perl portability fix
  more tr portability test script fixes
  grep portability fix: don't use "-e" or "-q"
  remove use of "tail -n 1" and "tail -1"
  add test_cmp function for test scripts
  t4020: don't use grep -a
  t6000lib: tr portability fix
  add NO_EXTERNAL_GREP build option
  filter-branch: don't use xargs -0
  filter-branch: use $SHELL_PATH instead of 'sh'
  t9112: add missing #!/bin/sh header
  t7505: use SHELL_PATH in hook
  t6000lib: re-fix tr portability

Johannes Schindelin (1):
  remote show: do not show symbolic refs

Johannes Sixt (1):
  git-submodule summary: fix that some "wc" flavors produce leading spaces

Jonas Fonseca (1):
  shortlog: do not require to run from inside a git repository

Junio C Hamano (15):
  Makefile: DIFF_OBJS is not special at all these days
  Makefile: flatten enumeration of headers, objects and programs
  Documentation/git-help: typofix
  Redo "add test_cmp function for test scripts"
  git-gui: Improve directions regarding POT update in po/README
  Resurrect git-rerere to contrib/examples
  Update draft release notes for 1.5.5
  t1000: use "test_must_fail git frotz", not "! git frotz"
  git-merge-one-file: fix longstanding stupid thinko
  Test: catch if trash cannot be removed
  Add tests to catch problems with un-unlinkable symlinks
  Fix read-tree not to discard errors
  remote.c: Fix overtight refspec validation
  gc --auto: raise default auto pack limit from 20 to 50
  GIT 1.5.5-rc1

Kevin Ballard (4):
  Add --reverse to the git-rev-list usage string
  Document the sendemail.smtpserverport config variable
  Don't try and percent-escape existing percent escapes in git-svn URIs
  Make git-svn tests behave better on OS X

Kristian Høgsberg (1):
  wt-status.c: no need for dup() dance anymore

Linus Torvalds (4):
  Fix recent 'unpack_trees()'-related changes breaking 'git stash'
  Don't update unchanged merge entries
  Fix possible Solaris problem in 'checkout_entry()'
  Make revision limiting more robust against occasional bad commit dates

Marius Storm-Olsen (1):
  git-p4: Optimize the fetching of data from perforce.

Michele Ballabio (4):
  gitk: Mark another string for translation
  git-gui: update Italian translation
  gitk: initial Italian translation
  git-gui: remove spurious "fuzzy" attributes in po/it.po

Miklos Vajna (3):
  Update Hungarian translation. 100% completed.
  git-gui: Updated Hungarian translation (e5fba18)
  Documentation/git-merge: document subtree strategy.

Nanako Shiraishi (2):
  git-gui: Update Japanese translation
  git-gui: Update Japanese translation

Nicolas Pitre (1):
  make it easier for people who just want to get rid of 'git gc --auto'

Paul Mackerras (3):
  gitk: Only restore window size from ~/.gitk, not position
  gitk: Avoid Tcl error when switching views
  gitk: Default to using po2msg.sh if msgfmt doesn't grok --tcl, -l and -d

Pekka Kaitaniemi (1):
  gitk: Add horizontal scrollbar to the diff view

Peter Karlsson (2):
  git-gui: Regenerated po template and merged translations with it
  git-gui: updated Swedish translation

Ping Yin (5):
  git-submodule summary: code framework
  git-submodule summary: show commit summary
  git-submodule summary: limit summary size
  git-submodule summary: documentation
  git-submodule summary: test

Ralf Wildenhues (1):
  Improve description of git filter-branch.

Shawn Bohrer (2):
  git-p4: Unset P4DIFF environment variable when using 'p4 -du diff'
  git-p4: Use P4EDITOR environment variable when set

Shawn O. Pearce (2):
  git-gui: Don't translate the special Apple menu
  git-gui: Adjusted Japanese translation to updated POT

Yann Dirson (1):
  Add an --argscmd flag to get the list of refs to show

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-03-09 10:46                 ` Junio C Hamano
@ 2008-03-14  9:11                   ` Junio C Hamano
  2008-03-23 10:08                     ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-14  9:11 UTC (permalink / raw)
  To: git

We still have remaining fixes and a handful backports (cherry-picks) from
'master' to 'maint', and we would probably need v1.5.4.5 shortly.

On the 'master' front, we have git-gui updates, more bash completion, and
a few recent graduates (rewrite of unpack_trees(), reimplementation of
git-remote).

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Andy Whitcroft (1):
  shortlog: take the first populated line of the description

Clemens Buchacher (1):
  merge-recursive: handle file mode changes

Jakub Narebski (1):
  gitweb: Fix bug in href(..., -replay=>1) when using 'pathinfo' form

Jeff King (1):
  t0021: tr portability fix for Solaris

Johannes Schindelin (3):
  launch_editor(): allow spaces in the filename
  git fetch: Take '-n' to mean '--no-tags'
  merge-file: handle empty files gracefully

Junio C Hamano (3):
  filter-branch: handle "disappearing tree" case correctly in subdir filter
  git-pull documentation: warn about the option order
  quiltimport: fix misquoting of parsed -p<num> parameter

Marc-Andre Lureau (2):
  git-svn: fix find-rev error message when missing arg
  git-cvsimport: fix merging with remote parent branch

Mike Hommey (1):
  git rebase --abort: always restore the right commit

Pierre Habouzit (1):
  git-quiltimport: better parser to grok "enhanced" series files.

Vineet Kumar (1):
  Minor wording changes in the keyboard descriptions in git-add
    --interactive.

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

Adam Piątyszek (1):
  git-gui: Add option for changing the width of the commit message text box

Christian Couder (2):
  web--browse: use custom commands defined at config time
  Documention: web--browse: add info about "browser.<tool>.cmd" config var

Johannes Schindelin (9):
  path-list: add functions to work with unsorted lists
  parseopt: add flag to stop on first non option
  Test "git remote show" and "git remote prune"
  Make git-remote a builtin
  builtin-remote: prune remotes correctly that were added with --mirror
  remote show: Clean up connection correctly if object fetch wasn't done
  remote: fix "update [group...]"
  builtin remote rm: remove symbolic refs, too
  gc: call "prune --expire 2.weeks.ago" by default

Junio C Hamano (6):
  merge-recursive: split low-level merge functions out.
  expose a helper function peel_to_type().
  traverse_trees_recursive(): propagate merge errors up
  git-gui: Simplify MSGFMT setting in Makefile
  Documentation/config: typofix
  read-tree() and unpack_trees(): use consistent limit

Kevin Ballard (1):
  bash: Properly quote the GIT_DIR at all times to fix subdirectory paths
    with spaces

Linus Torvalds (11):
  Add 'df_name_compare()' helper function
  Make 'traverse_tree()' use linked structure rather than 'const char
    *base'
  Add return value to 'traverse_tree()' callback
  Make 'traverse_trees()' traverse conflicting DF entries in parallel
  Move 'unpack_trees()' over to 'traverse_trees()' interface
  Fix tree-walking compare_entry() in the presense of --prefix
  Add 'const' where appropriate to index handling functions
  Make 'unpack_trees()' take the index to work on as an argument
  Make 'unpack_trees()' have a separate source and destination index
  unpack_trees(): minor memory leak fix in unused destination index
  unpack_trees(): fix diff-index regression.

Michal Rokos (1):
  autoconf: Test FREAD_READS_DIRECTORIES

Nicolas Pitre (1):
  pack-objects: proper pack time stamping with --max-pack-size

Philipp A. Hartmann (1):
  git-gui: if a background colour is set, set foreground colour as well

SZEDER Gábor (7):
  bash: remove unnecessary conditions when checking for subcommands
  bash: refactor searching for subcommands on the command line
  bash: add new 'git stash' subcommands
  bash: add 'git svn' subcommands and options
  bash: use __gitdir when completing 'git rebase' options
  bash: fix long option with argument double completion
  update 'git rebase' documentation

Samuel Tardieu (1):
  "remote update": print remote name being fetched from

Shawn O. Pearce (1):
  bash: Remove completion of core.legacyheaders option

Teemu Likonen (1):
  bash: Add more long options to be completed with "git --<TAB>"

eric miao (1):
  git-gui: translate the remaining messages in zh_cn.po to chinese

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-03-08 10:08               ` Junio C Hamano
@ 2008-03-09 10:46                 ` Junio C Hamano
  2008-03-14  9:11                   ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-09 10:46 UTC (permalink / raw)
  To: git

Maintenance release 1.5.4.4 is out with accumulated fixes.

Except for a few remaining topics ("remote rewritten in C", and "saner
unpack_trees"), 'master' is almost feature complete for 1.5.5 and we will
hopefully soon enter -rc freeze.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Adeodato Simó (1):
  Really make the LF after reset in fast-import optional

Johannes Schindelin (1):
  cvsexportcommit: be graceful when "cvs status" reorders the arguments

Johannes Sixt (2):
  daemon: send more error messages to the syslog
  daemon: ensure that base-path is an existing directory

John Goerzen (1):
  Fix dcommit, rebase when rewriteRoot is in use

Junio C Hamano (2):
  Fix "git log --merge --left-right"
  GIT 1.5.4.4

Mike Hommey (1):
  Set proxy override with http_init()

Santi Béjar (1):
  ident.c: reword error message when the user name cannot be determined

Sebastian Noack (1):
  git-svn: Don't prompt for client cert password everytime.

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

Andy Whitcroft (1):
  shortlog: take the first populated line of the description

Carlos Rica (1):
  Make builtin-reset.c use parse_options.

Charles Bailey (2):
  git-mergetool documentaiton: show toolnames in typewriter font
  merge-tool documentation: describe custom command usage

Dmitry Potapov (2):
  Make private quote_path() in wt-status.c available as
    quote_path_relative()
  git-clean: correct printing relative path

Jakub Narebski (1):
  gitweb: Fix and simplify pickaxe search

Jeff King (1):
  Add a test for read-tree -u --reset with a D/F conflict

Junio C Hamano (10):
  describe --always: fall back to showing an abbreviated object name
  am: read from the right mailbox when started from a subdirectory
  am: remove support for -d .dotest
  am: --rebasing
  get_pathspec(): die when an out-of-tree path is given
  Revert part of 744dacd (builtin-mv: minimum fix to avoid losing files)
  Revert part of 1abf095 (git-add: adjust to the get_pathspec() changes)
  Revert part of d089eba (setup: sanitize absolute and funny paths in
    get_pathspec())
  git-clean: add tests for relative path
  filter-branch: handle "disappearing tree" case correctly in subdir filter

Mark Levedahl (1):
  git-submodule - Allow adding a submodule in-place

Michal Rokos (1):
  Add compat/snprintf.c for systems that return bogus

Pierre Habouzit (2):
  parse-opt: bring PARSE_OPT_HIDDEN and NONEG to git-rev-parse --parseopt
  parse-options: new option type to treat an option-like parameter as an
    argument.

Shawn O. Pearce (11):
  Remove unused variable in builtin-fetch find_non_local_tags
  Remove unnecessary delaying of free_refs(ref_map) in builtin-fetch
  Ensure tail pointer gets setup correctly when we fetch HEAD only
  Allow builtin-fetch's find_non_local_tags to append onto a list
  Free the path_lists used to find non-local tags in git-fetch
  Teach upload-pack to log the received need lines to an fd
  Make git-fetch follow tags we already have objects for sooner
  Teach git-fetch to grab a tag at the same time as a commit
  git-pack-objects: Automatically pack annotated tags if object was packed
  Teach fetch-pack/upload-pack about --include-tag
  Teach git-fetch to exploit server side automatic tag following


^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-03-06  6:02             ` Junio C Hamano
@ 2008-03-08 10:08               ` Junio C Hamano
  2008-03-09 10:46                 ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-08 10:08 UTC (permalink / raw)
  To: git

There are about half a dozen topics that need to be merged to 'maint'
before 1.5.4.4 can happen, which hopefully will be mid next week.  They
are already in 'master' and we haven't heard about breakages with them.

It would be really nice to also have msgfmt issue on OSX resolved (e.g.
http://article.gmane.org/gmane.comp.version-control.git/76355) before
that.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Junio C Hamano (1):
  test-lib: fix TERM to dumb for test repeatability

Pierre Habouzit (1):
  unquote_c_style: fix off-by-one.

Shawn O. Pearce (1):
  git-gui: Gracefully fall back to po2msg.sh if msgfmt --tcl fails

Uwe Kleine-König (1):
  config.txt: refer to --upload-pack and --receive-pack instead of --exec


* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (1):
  Do not use GUID on dir in git init --shared=all on FreeBSD

Brandon Casey (10):
  builtin-reflog.c: fix typo that accesses an unset variable
  reflog-delete: parse standard reflog options
  git-reflog: add option --rewrite to update reflog entries while expiring
  refs.c: make close_ref() and commit_ref() non-static
  git-reflog: add option --updateref to write the last reflog sha1 into the
    ref
  git-stash: add new 'drop' subcommand
  git-stash: add new 'pop' subcommand
  t3903-stash.sh: Add missing '&&' to body of testcase
  git-reflog.txt: Document new commands --updateref and --rewrite
  t3903-stash.sh: Add tests for new stash commands drop and pop

Charles Bailey (4):
  Tidy up git mergetool's backup file behaviour
  Changed an internal variable of mergetool to support custom commands
  Teach git mergetool to use custom commands defined at config time
  Add a very basic test script for git mergetool

Christian Couder (1):
  run-command: Redirect stderr to a pipe before redirecting stdout to
    stderr

Denis Cheng (3):
  whatchanged documentation: share description of --pretty with others
  specify explicit "--pretty=medium" with `git log/show/whatchanged`
  log/show/whatchanged: introduce format.pretty configuration

Johannes Schindelin (1):
  Teach "git reflog" a subcommand to delete single entries

Junio C Hamano (1):
  send-email: --no-signed-off-cc should suppress 'sob' cc


^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-03-03  2:06           ` Junio C Hamano
@ 2008-03-06  6:02             ` Junio C Hamano
  2008-03-08 10:08               ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-06  6:02 UTC (permalink / raw)
  To: git

I should probably do a 1.5.4.4 shortly from 'maint' to flush accumulated
fixes.  There is nothing major, but send-email regression fix deserves to
be delibered sooner to the end users.

On the 'master', we briefly had a faulty receive-pack to cause a small
pushes to fail, but that glitch has been reverted.  Also fixed was a
git-describe not quite working when your tags are packed (e.g. after
git-gc).

----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.

Björn Steinbrink (1):
  receive-pack: Initialize PATH to include exec-dir.

Gerrit Pape (1):
  git-merge.sh: better handling of combined --squash,--no-ff,--no-commit
    options

Jeff King (1):
  revert: actually check for a dirty index

Junio C Hamano (2):
  tests: introduce test_must_fail
  Update draft release notes for 1.5.4.4

Matthieu Moy (1):
  Fix incorrect wording in git-merge.txt.

Mike Hommey (1):
  Fix random crashes in http_cleanup()

Ping Yin (1):
  git-submodule: Fix typo 'url' which should be '$url'

Shawn O. Pearce (1):
  Fix 'git remote show' regression on empty repository in 1.5.4

----------------------------------------------------------------
* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (1):
  Fix test for cleanup failure in t7300 on Windows

Junio C Hamano (8):
  Update draft release notes for 1.5.5
  git-describe: use tags found in packed-refs correctly
  describe: fix --long output
  describe: re-fix display_name()
  t6120 (describe): check --long properly
  Revert "receive-pack: use strict mode for unpacking objects"
  Revert "unpack-objects: prevent writing of inconsistent objects"
  fsck.c: fix bogus "empty tree" check

Martin Koegler (1):
  fetch-pack: check parse_commit/object results

Mike Hommey (1):
  t3407-rebase-abort.sh: Enhance existing tests, and add test for rebase
    --merge

SZEDER Gábor (2):
  bash: add git-branch options
  bash: git-branch -d and -m lists only local branches

Shawn O. Pearce (3):
  Don't allow git-describe failures to go unnoticed in t6120
  Test for packed tags in git-describe output
  Add git-describe test for "verify annotated tag names on output"

Simon Hausmann (1):
  git-p4: Fix import of changesets with file deletions


^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-02-28  0:43         ` Junio C Hamano
@ 2008-03-03  2:06           ` Junio C Hamano
  2008-03-06  6:02             ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-03  2:06 UTC (permalink / raw)
  To: git

The 'master' has, aside from trivial fixes and enhancements, the following
topics that have been cooking:

 * "verify-pack" improvements;

 * "describe" that warns about a tag whose name and path contradict;

 * "describe --long" to show an tagged commit as $tag-0-$sha1;

 * "cvsimport -M" can be given more than once;

 * "gitweb" grep-search improvements;

A handful of the topics are meant also for 'maint'; after seeing no
complaints for a while they will be merged to 'maint' as part of the next
maintenance release v1.5.4.4.

----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.

Daniel Barkalow (1):
  Correct name of diff_flush() in API documentation

Gerrit Pape (1):
  templates/Makefile: don't depend on local umask setting

Junio C Hamano (1):
  Start preparing for 1.5.4.4

Mike Ralphson (1):
  Documentation cherry-pick: Fix cut-and-paste error

Rémi Vanicat (1):
  git.el: find the git-status buffer whatever its name is

Shawn O. Pearce (1):
  git-gui: Paper bag fix info dialog when no files are staged at commit

----------------------------------------------------------------
* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (1):
  Fix builtin checkout crashing when given an invalid path

Christian Stimming (2):
  git-gui: (i18n) Add newly added translation strings to template.
  git-gui: Update German translation.

Clemens Buchacher (2):
  http-push: push <remote> :<branch> deletes remote branch
  http-push: add regression tests

Daniel Barkalow (3):
  Always use the current connection's remote ref list in git protocol
  Use diff_tree() directly in making cover letter
  Write index file on any checkout of files

Denis Cheng (1):
  cleanup: remove unused git_checkout_config

Frank Lichtenheld (1):
  gc: Add --quiet option

Jakub Narebski (4):
  gitweb: Change parse_commits signature to allow for multiple options
  gitweb: Simplify fixed string search
  Documentation: Remove --{min,max}-age option from git-log(1)
  gitweb: Mark first match when searching commit messages

Jean-Luc Herren (1):
  fast-import: exit with proper message if not a git dir

Jeff King (3):
  use build-time SHELL_PATH in test scripts
  rename: warn user when we have turned off rename detection
  allow git-am to run in a subdirectory

Johannes Schindelin (4):
  completion: support format-patch's --cover-letter option
  Fix make_absolute_path() for parameters without a slash
  format-patch: use the diff options for the cover letter, too
  format-patch: wrap cover-letter's shortlog sensibly

Johannes Sixt (2):
  daemon: send more error messages to the syslog
  daemon: ensure that base-path is an existing directory

Junio C Hamano (11):
  git-remote: do not complain on multiple URLs for a remote
  Fix "git log --merge --left-right"
  format-patch: remove a leftover debugging message
  tests: introduce test_must_fail
  Update draft release notes for 1.5.5
  t6024: move "git reset" to prepare for a test inside the test itself
  CodingGuidelines: spell out how we use grep in our scripts
  find_unique_abbrev(): redefine semantics
  Clean up find_unique_abbrev() callers
  diff-lib.c: constness strengthening
  diff: make sure work tree side is shown as 0{40} when different

Martin Koegler (10):
  add generic, type aware object chain walker
  builtin-fsck: move away from object-refs to fsck_walk
  Remove unused object-ref code
  builtin-fsck: reports missing parent commits
  builtin-fsck: move common object checking code to fsck.c
  add common fsck error printing function
  unpack-object: cache for non written objects
  unpack-objects: prevent writing of inconsistent objects
  index-pack: introduce checking mode
  receive-pack: use strict mode for unpacking objects

Michele Ballabio (1):
  git-gui: fix typo in lib/spellcheck.tcl

Mike Hommey (4):
  Set proxy override with http_init()
  Add test for git rebase --abort
  Documentation/git-rebase.txt: Add --strategy to synopsys
  git rebase --abort: always restore the right commit

Miklos Vajna (1):
  Improve t6029 to check the real "subtree" case

Nicolas Pitre (4):
  factorize revindex code out of builtin-pack-objects.c
  make verify_one_pack() a bit less wrong wrt packed_git structure
  fix unimplemented packed_object_info_detail() features
  add storage size output to 'git verify-pack -v'

Petr Baudis (1):
  gitweb: Clearly distinguish regexp / exact match searches

Philippe Bruhat (BooK (3):
  cvsimport: have default merge regex allow for dashes in the branch name
  cvsimport: allow for multiple -M options
  cvsimport: document that -M can be used multiple times

Ralf Wildenhues (1):
  Fix doc typos.

Santi Béjar (2):
  git-describe: --long shows the object name even for a tagged commit
  clone: support cloning full bundles

Sebastian Noack (1):
  git-svn: Don't prompt for client cert password everytime.

Shawn O. Pearce (7):
  git-gui: Ensure all spellchecker 'class' variables are initialized
  git-gui: Remove explicit references to 'aspell' in message strings
  git-gui: Only bind the spellcheck popup suggestion hook once
  git-gui: Catch and display aspell startup failures to the user
  git-gui: Gracefully display non-aspell version errors to users
  git-gui: Shorten Aspell version strings to just Aspell version number
  Teach git-describe to verify annotated tag names before output

Uwe Kleine-König (1):
  rev-list: add --branches, --tags and --remotes


^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-02-25  8:42       ` Junio C Hamano
@ 2008-02-28  0:43         ` Junio C Hamano
  2008-03-03  2:06           ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-02-28  0:43 UTC (permalink / raw)
  To: git

For the next maintenance release v1.5.4.4, I made a few
cherry-picks from 'master' and also a merge down of a topic
branch that has been cooking there, to 'maint'.

On the 'master' front, many topics have been merged.  With a few
more topics that are still in 'next', we are pretty much done
feature-wise for the next feature release v1.5.5.

----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.

Brandon Casey (1):
  builtin-reflog.c: don't install new reflog on write failure

Bryan Donlan (1):
  Documentation/git-am.txt: Pass -r in the example invocation of rm -f
    .dotest

Caio Marcelo de Oliveira Filho (1):
  filter-branch documentation: non-zero exit status in command abort the
    filter

Carl Worth (1):
  Eliminate confusing "won't bisect on seeked tree" failure

Daniel Barkalow (2):
  Use a single implementation and API for copy_file()
  Don't use GIT_CONFIG in t5505-remote

Jay Soffian (2):
  rev-parse: fix potential bus error with --parseopt option spec handling
  send-email: fix In-Reply-To regression

Johan Herland (2):
  Add testcase for 'git cvsexportcommit -w $cvsdir ...' with relative
    $GIT_DIR
  Fix 'git cvsexportcommit -w $cvsdir ...' when used with relative $GIT_DIR

Johannes Schindelin (3):
  http-push: avoid invalid memory accesses
  http-push: do not get confused by submodules
  http-push: avoid a needless goto

Jonathan del Strother (1):
  Prompt to continue when editing during rebase --interactive

Miklos Vajna (2):
  Documentation/git-filter-branch: add a new msg-filter example
  Documentation/git svn log: add a note about timezones.

Steven Drake (1):
  timezone_names[]: fixed the tz offset for New Zealand.


----------------------------------------------------------------
* The 'master' branch has these since the last announcement
  in addition to the above.

Alexandre Julliard (1):
  git.el: Do not display empty directories.

Andreas Ericsson (1):
  pack-objects: Add runtime detection of online CPU's

Brandon Casey (2):
  builtin-reflog.c: don't install new reflog on write failure
  pack-objects: Print a message describing the number of threads for packing

Carl Worth (1):
  Eliminate confusing "won't bisect on seeked tree" failure

Daniel Barkalow (26):
  Allow callers of unpack_trees() to handle failure
  Add flag to make unpack_trees() not print errors.
  Send unpack-trees debugging output to stderr
  Discard "deleted" cache entries after using them to update the working tree
  Add "skip_unmerged" option to unpack_trees.
  Build-in merge-recursive
  Move create_branch into a library file
  Use diff -u instead of diff in t7201
  Library function to check for unmerged index entries
  Move code to clean up after a branch change to branch.c
  Build in checkout
  Clean up reporting differences on branch switch
  Add more tests for format-patch
  Improve message-id generation flow control for format-patch
  Export some email and pretty-printing functions
  Use ALLOC_GROW in remote.{c,h}
  Add a --cover-letter option to format-patch
  Add tests for extra headers in format-patch
  Fix format.headers not ending with a newline
  Combine To: and Cc: headers
  Support a --cc=<email> option in format-patch
  Resolve value supplied for no-colon push refspecs
  builtin-checkout.c: Remove unused prefix arguments in switch_branches path
  Add support for url aliases in config files
  Add API access to shortlog
  Improve collection of information for format-patch --cover-letter

Gerrit Pape (1):
  hash-object: cleanup handling of command line options

Jakub Narebski (2):
  gitweb: Better cutting matched string and its context
  Add '--fixed-strings' option to "git log --grep" and friends

Jay Soffian (3):
  builtin-checkout.c: fix possible usage segfault
  branch: optionally setup branch.*.merge from upstream local branches
  doc: documentation update for the branch track changes

Jeff King (3):
  help: use parseopt
  make alias lookup a public, procedural function
  help: respect aliases

Jim Meyering (1):
  Avoid unnecessary "if-before-free" tests.

Johannes Schindelin (2):
  xdl_merge(): make XDL_MERGE_ZEALOUS output simpler
  xdl_merge(): introduce XDL_MERGE_ZEALOUS_ALNUM

Johannes Sixt (2):
  start_command(), .in/.out/.err = -1: Callers must close the file descriptor
  start_command(), if .in/.out > 0, closes file descriptors, not the callers

Junio C Hamano (12):
  diff --relative: output paths as relative to the current subdirectory
  diff --relative: help working in a bare repository
  checkout: notice when the switched branch is behind or forked
  checkout: tone down the "forked status" diagnostic messages
  checkout: work from a subdirectory
  checkout: updates to tracking report
  Add merge-subtree back
  checkout: show progress when checkout takes long time while switching
    branches
  checkout: error out when index is unmerged even with -m
  url rewriting: take longest and first match
  git-apply --whitespace=fix: fix off by one thinko
  Revert "pack-objects: Print a message describing the number of threads
    for packing"

Sebastian Noack (1):
  git-svn: Don't prompt for client cert password everytime.

Shawn O. Pearce (5):
  Optimize peel_ref for the current ref of a for_each_ref callback
  Teach git-describe to use peeled ref information when scanning tags
  Avoid accessing non-tag refs in git-describe unless --all is requested
  Teach git-describe --exact-match to avoid expensive tag searches
  Use git-describe --exact-match in bash prompt on detached HEAD

Simon Hausmann (4):
  git-p4: Remove --log-substitutions feature.
  git-p4: Clean up git-p4 submit's log message handling.
  git-p4: Removed git-p4 submit --direct.
  git-p4: git-p4 submit cleanups.

Steffen Prohaska (2):
  t4014: Replace sed's non-standard 'Q' by standard 'q'
  Add tests for filesystem challenges (case and unicode normalization)

Tommy Thorn (1):
  git-p4: support exclude paths

Tor Arvid Lund (1):
  git-p4: Support usage of perforce client spec

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-02-21  4:16     ` Junio C Hamano
@ 2008-02-25  8:42       ` Junio C Hamano
  2008-02-28  0:43         ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-02-25  8:42 UTC (permalink / raw)
  To: git

By the end of this week, we will hopefully pretty much know what
will be (and what won't be) in 1.5.5.  Tonight's 'master'
contains Linus's "diff --dirstat" and my "apply ---whitespace"
enhancements, among other things.  The next 'master' update is
expected to be fairly big (see "What's cooking").

----------------------------------------------------------------

* The 'maint' branch has these fixes since v1.5.4.3

Shawn O. Pearce (3):
  Ensure 'make dist' compiles git-archive.exe on Cygwin
  Protect peel_ref fallback case from NULL parse_object result
  Correct fast-export file mode strings to match fast-import standard

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

Gerrit Pape (2):
  git-merge-index documentation: clarify synopsis
  builtin-tag.c: remove cruft

Jakub Narebski (1):
  gitweb: Fix bugs in git_search_grep_body: it's length(), not len()

Jay Soffian (2):
  send-email: fix In-Reply-To regression
  pull: pass --strategy along to to rebase

Jeff King (5):
  git_config_*: don't assume we are parsing a config file
  t3404: use configured shell instead of /bin/sh
  diff: fix java funcname pattern for solaris
  t9001: enhance fake sendmail test harness
  send-email: test compose functionality

Johannes Sixt (1):
  prefix_path: use is_absolute_path() instead of *orig == '/'

Junio C Hamano (18):
  builtin-apply.c: refactor small part that matches context
  builtin-apply.c: restructure "offset" matching
  builtin-apply.c: push match-beginning/end logic down
  builtin-apply.c: make it more line oriented
  builtin-apply.c: optimize match_beginning/end processing a bit.
  builtin-apply.c: mark common context lines in lineinfo structure.
  builtin-apply.c: clean-up apply_one_fragment()
  builtin-apply.c: simplify calling site to apply_line()
  builtin-apply.c: do not feed copy_wsfix() leading '+'
  builtin-apply.c: move copy_wsfix() function a bit higher.
  builtin-apply.c: pass ws_rule down to match_fragment()
  git-apply --whitespace=fix: fix whitespace fuzz introduced by previous
    run
  core.whitespace: cr-at-eol
  apply: do not barf on patch with too large an offset
  git-reset --hard and git-read-tree --reset: fix read_cache_unmerged()
  gitweb: Better chopping in commit search results
  ws_fix_copy(): move the whitespace fixing function to ws.c
  diff --dirstat: saner handling of binary and unmerged files

Linus Torvalds (5):
  Add "--dirstat" for some directory statistics
  Fix name re-hashing semantics
  Name hash fixups: export (and rename) remove_hash_entry
  Use helper function for copying index entry information
  Be more verbose when checkout takes a long time

Michele Ballabio (1):
  builtin-for-each-ref.c: fix typo in error message

Miklos Vajna (1):
  git-clean: handle errors if removing files fails

Santi Béjar (1):
  git-bundle.txt: Add different strategies to create the bundle

Shawn O. Pearce (1):
  Teach git-grep --name-only as synonym for -l

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-02-17  3:56   ` What's in git.git (stable) Junio C Hamano
  2008-02-17 13:39     ` Jakub Narebski
@ 2008-02-21  4:16     ` Junio C Hamano
  2008-02-25  8:42       ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-02-21  4:16 UTC (permalink / raw)
  To: git

With a handful of fixes and RPM specfile updates, we would
probably want to do 1.5.4.3 in a week or so from 'maint'.

A handful of new topics are now on 'master', and the ones still
on 'next' are maturing with necessary fixes.  I think we have
enough material for 1.5.5 when they graduate, and I am hoping to
do an rc1 sometime early to mid next month.  We'll see.

* The 'maint' branch has these fixes since the last announcement.

Gerrit Pape (1):
  git-clone.sh: properly configure remote even if remote's head is dangling

Jay Soffian (1):
  send-email: squelch warning due to comparing undefined $_ to ""

Jeff King (3):
  push: indicate partialness of error message
  Documentation/push: clarify matching refspec behavior
  push: document the status output

Junio C Hamano (1):
  GIT 1.5.4.2

Kristian Høgsberg (1):
  Rename git-core rpm to just git and rename the meta-pacakge to git-all.

Miklos Vajna (1):
  Documentation/git-stash: document options for git stash list

Pekka Kaitaniemi (1):
  Clarified the meaning of git-add -u in the documentation


* The 'master' branch has these since the last announcement
  in addition to the above.

Brandon Casey (1):
  Add compat/fopen.c which returns NULL on attempt to open directory

Bruno Ribas (1):
  gitweb: Use the config file to set repository owner's name.

Christian Couder (1):
  help.c: use 'git_config_string' to get 'help_default_format'.

Daniel Barkalow (1):
  API documentation for remote.h

David Kågedal (1):
  git.el: Set process-environment instead of invoking env

Jakub Narebski (3):
  gitweb: Fix displaying unchopped argument in chop_and_escape_str
  gitweb: Add new option -nohtml to quot_xxx subroutines
  gitweb: Fix bug in href(..., -replay=>1) when using 'pathinfo' form

Jay Soffian (1):
  Correct git-pull documentation

Jeff King (2):
  hard-code the empty tree object
  add--interactive: handle initial commit better

Johannes Schindelin (5):
  http-push: avoid invalid memory accesses
  http-push: do not get confused by submodules
  http-push: avoid a needless goto
  bisect view: check for MinGW32 and MacOSX in addition to X11
  cvsexportcommit: be graceful when "cvs status" reorders the arguments

Johannes Sixt (1):
  Technical documentation of the run-command API.

Junio C Hamano (5):
  setup: sanitize absolute and funny paths in get_pathspec()
  git-add: adjust to the get_pathspec() changes.
  builtin-mv: minimum fix to avoid losing files
  Sync with 1.5.4.2 and start 1.5.5 Release Notes
  sending errors to stdout under $PAGER

Lars Hjemli (1):
  Simplify setup of $GIT_DIR in git-sh-setup.sh

Linus Torvalds (1):
  Add "--show-all" revision walker flag for debugging

Marco Costalba (1):
  Avoid a useless prefix lookup in strbuf_expand()

Martin Koegler (15):
  deref_tag: handle return value NULL
  deref_tag: handle tag->tagged = NULL
  check return code of prepare_revision_walk
  read_object_with_reference: don't read beyond the buffer
  get_sha1_oneline: check return value of parse_object
  mark_blob/tree_uninteresting: check for NULL
  reachable.c::add_one_tree: handle NULL from lookup_tree
  list-objects.c::process_tree/blob: check for NULL
  check results of parse_commit in merge_bases
  process_tag: handle tag->tagged == NULL
  reachable.c::process_tree/blob: check for NULL
  revision.c: handle tag->tagged == NULL
  parse_commit: don't fail, if object is NULL
  check return value from parse_commit() in various functions
  peel_onion: handle NULL

Matthias Kestenholz (1):
  Add color.ui variable which globally enables colorization if set

Robin Rosenberg (1):
  Make blame accept absolute paths

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2008-02-18  3:12                 ` Junio C Hamano
@ 2008-02-18 11:15                   ` Jeff King
  0 siblings, 0 replies; 601+ messages in thread
From: Jeff King @ 2008-02-18 11:15 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Schindelin, Jakub Narebski, git

On Sun, Feb 17, 2008 at 07:12:53PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > .... This is in contrast to the
> > current 'master' and v1.5.4, which discard the cache _three_ times
> > during the status process.
> 
> The current 'master' meaning before 959ba67 (commit: discard
> index after setting up partial commit), right?

Heh. Yes. The current 'master' meaning 'the current master when I wrote
that patch.' :)

-Peff

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2008-02-18  1:43               ` Jeff King
  2008-02-18  2:05                 ` Johannes Schindelin
@ 2008-02-18  3:12                 ` Junio C Hamano
  2008-02-18 11:15                   ` Jeff King
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-02-18  3:12 UTC (permalink / raw)
  To: Jeff King; +Cc: Johannes Schindelin, Jakub Narebski, git

Jeff King <peff@peff.net> writes:

> .... This is in contrast to the
> current 'master' and v1.5.4, which discard the cache _three_ times
> during the status process.

The current 'master' meaning before 959ba67 (commit: discard
index after setting up partial commit), right?

I've been hoping that when this turns out to be Ok it would be
worth cherry-picking to 'maint' before 1.5.4.3.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2008-02-18  1:43               ` Jeff King
@ 2008-02-18  2:05                 ` Johannes Schindelin
  2008-02-18  3:12                 ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2008-02-18  2:05 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, Jakub Narebski, git

Hi,

On Sun, 17 Feb 2008, Jeff King wrote:

> On Mon, Feb 18, 2008 at 01:34:50AM +0000, Johannes Schindelin wrote:
> 
> > Well, my workflow has lots of these moments.  I do not even feel "oops" 
> > about it.  More like "by the way, this needs committing _now_".
> > 
> > So I guess I'll be the guinea pig for this patch, and if it is too 
> > painful, I'll just go and fix it.
> 
> Just to be clear, this patch discards the cache after preparing the
> partial index but before doing the status. This is in contrast to the
> current 'master' and v1.5.4, which discard the cache _three_ times
> during the status process.

... but then goes through big pains to reconstruct an index that needs as 
little updating as possible.

> So no, the performance will probably not be a big deal. It is better 
> than it has been in any released version of git.

I'll see, and report back.

IOW I think that your patch is necessary.  There might be some followup 
work to do for me, but at the moment, your patch fixes an existing bug.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2008-02-18  1:34             ` Johannes Schindelin
@ 2008-02-18  1:43               ` Jeff King
  2008-02-18  2:05                 ` Johannes Schindelin
  2008-02-18  3:12                 ` Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Jeff King @ 2008-02-18  1:43 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, Jakub Narebski, git

On Mon, Feb 18, 2008 at 01:34:50AM +0000, Johannes Schindelin wrote:

> Well, my workflow has lots of these moments.  I do not even feel "oops" 
> about it.  More like "by the way, this needs committing _now_".
> 
> So I guess I'll be the guinea pig for this patch, and if it is too 
> painful, I'll just go and fix it.

Just to be clear, this patch discards the cache after preparing the
partial index but before doing the status. This is in contrast to the
current 'master' and v1.5.4, which discard the cache _three_ times
during the status process.

So no, the performance will probably not be a big deal. It is better
than it has been in any released version of git.

-Peff

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2008-02-18  1:31           ` Junio C Hamano
@ 2008-02-18  1:34             ` Johannes Schindelin
  2008-02-18  1:43               ` Jeff King
  0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2008-02-18  1:34 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jakub Narebski, git

Hi,

On Sun, 17 Feb 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Sun, 17 Feb 2008, Junio C Hamano wrote:
> >
> >> The more fundamental improvement was along the lines of what I suggested 
> >> soon after Kristian's initial round was posted, but what the current 
> >> code does is not wrong nor hack.  It is about a partial commit after all 
> >> and is not performance critical either.
> >
> > You mean: at this point, it is not necessary to be careful about the 
> > index, as the index that will be reloaded will already have the most 
> > recent timestamps, right?
> 
> I do not understand the question, but if you are referring to my "not 
> performance critical", I meant: "A partial commit is never performance 
> critical".
> 
> A partial commit is by its nature "oops, I earlier told you to git add 
> this and git add that but I did not mean that, eh, I do mean it but not 
> for this commit yet, sorry, I want to commit changes to these paths 
> first please and then I'll deal with the earlier added paths in later 
> commit perhaps.", i.e. very interactive.  Its performance requirement is 
> unlike an automated script slurping hundreds of changes per minute 
> applying exactly the change it wants in each commit to the index and 
> making commits in rapid succession.

Well, my workflow has lots of these moments.  I do not even feel "oops" 
about it.  More like "by the way, this needs committing _now_".

So I guess I'll be the guinea pig for this patch, and if it is too 
painful, I'll just go and fix it.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2008-02-17 20:51         ` Johannes Schindelin
@ 2008-02-18  1:31           ` Junio C Hamano
  2008-02-18  1:34             ` Johannes Schindelin
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-02-18  1:31 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Jakub Narebski, git

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

> On Sun, 17 Feb 2008, Junio C Hamano wrote:
>
>> The more fundamental improvement was along the lines of what I suggested 
>> soon after Kristian's initial round was posted, but what the current 
>> code does is not wrong nor hack.  It is about a partial commit after all 
>> and is not performance critical either.
>
> You mean: at this point, it is not necessary to be careful about the 
> index, as the index that will be reloaded will already have the most 
> recent timestamps, right?

I do not understand the question, but if you are referring to my
"not performance critical", I meant: "A partial commit is
never performance critical".

A partial commit is by its nature "oops, I earlier told you to
git add this and git add that but I did not mean that, eh, I do
mean it but not for this commit yet, sorry, I want to commit
changes to these paths first please and then I'll deal with the
earlier added paths in later commit perhaps.", i.e. very
interactive.  Its performance requirement is unlike an automated
script slurping hundreds of changes per minute applying exactly
the change it wants in each commit to the index and making
commits in rapid succession.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2008-02-17 20:45       ` Junio C Hamano
@ 2008-02-17 20:51         ` Johannes Schindelin
  2008-02-18  1:31           ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2008-02-17 20:51 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jakub Narebski, git

Hi,

On Sun, 17 Feb 2008, Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> >>   commit: discard index after setting up partial commit
> >
> > IIRC there was also request for proper solution; this was more a hack.
> 
> It is not a hack at all.
> 
> The more fundamental improvement was along the lines of what I suggested 
> soon after Kristian's initial round was posted, but what the current 
> code does is not wrong nor hack.  It is about a partial commit after all 
> and is not performance critical either.

You mean: at this point, it is not necessary to be careful about the 
index, as the index that will be reloaded will already have the most 
recent timestamps, right?

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2008-02-17 13:39     ` Jakub Narebski
@ 2008-02-17 20:45       ` Junio C Hamano
  2008-02-17 20:51         ` Johannes Schindelin
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-02-17 20:45 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

Jakub Narebski <jnareb@gmail.com> writes:

>>   commit: discard index after setting up partial commit
>
> IIRC there was also request for proper solution; this was more a hack.

It is not a hack at all.

The more fundamental improvement was along the lines of what I
suggested soon after Kristian's initial round was posted, but
what the current code does is not wrong nor hack.  It is about a
partial commit after all and is not performance critical either.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2008-02-17  3:56   ` What's in git.git (stable) Junio C Hamano
@ 2008-02-17 13:39     ` Jakub Narebski
  2008-02-17 20:45       ` Junio C Hamano
  2008-02-21  4:16     ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2008-02-17 13:39 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <gitster@pobox.com> writes:

> On the 'master' front, a handful topics have graduated:
> 
>  - Brian Downing's compat/qsort;
>  - Crhstian Couder's browser wrapper;
>  - Paolo Bonzini's prepare-commit-msg hook;
>  - Steffen Prohaska's safe-crlf;
>  - "foo/" in .gitignore matches directory "foo".

Nice.

> Daniel Barkalow (1):
>   Validate nicknames of remote branches to prohibit confusing ones

Good one.

> Jeff King (2):
>   status: suggest "git rm --cached" to unstage for initial commit

Corner case, but good one.

>   commit: discard index after setting up partial commit

IIRC there was also request for proper solution; this was more a hack.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2008-02-12  7:25 ` What's in git.git Junio C Hamano
@ 2008-02-17  3:56   ` Junio C Hamano
  2008-02-17 13:39     ` Jakub Narebski
  2008-02-21  4:16     ` Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2008-02-17  3:56 UTC (permalink / raw)
  To: git

I'll hopefully soon apply the RPM spec patch from Kristian
Høgsberg to 'maint' and cut 1.5.4.2.  It will have bunch of
config parser related fixes among others.

On the 'master' front, a handful topics have graduated:

 - Brian Downing's compat/qsort;
 - Crhstian Couder's browser wrapper;
 - Paolo Bonzini's prepare-commit-msg hook;
 - Steffen Prohaska's safe-crlf;
 - "foo/" in .gitignore matches directory "foo".

Also, updated versions of gitk and git-gui are included.

Have fun.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Christian Couder (8):
  config: add test cases for empty value and no value config variables.
  diff.c: replace a 'strdup' with 'xstrdup'.
  diff.c: remove useless check for value != NULL
  config: add 'git_config_string' to refactor string config variables.
  Add "const" qualifier to "char *pager_program".
  Add "const" qualifier to "char *editor_program".
  Add "const" qualifier to "char *excludes_file".
  diff.c: add "const" qualifier to "char *cmd" member of "struct
    ll_diff_driver"

Daniel Barkalow (1):
  Validate nicknames of remote branches to prohibit confusing ones

Gerrit Pape (1):
  cvsimport: have default merge regex also match beginning of commit
    message

Jay Soffian (1):
  mailinfo: feed only one line to handle_filter() for QP input

Jeff King (2):
  status: suggest "git rm --cached" to unstage for initial commit
  commit: discard index after setting up partial commit

Johannes Schindelin (1):
  bisect: use verbatim commit subject in the bisect log

Johannes Sixt (1):
  upload-pack: Initialize the exec-path.

Junio C Hamano (6):
  Revert "pack-objects: only throw away data during memory pressure"
  Protect get_author_ident_from_commit() from filenames in work tree
  diff.c: fixup garding of config parser from value=NULL
  diff: Fix miscounting of --check output
  filter-branch: handle filenames that need quoting
  Documentation/git-reset:

Miklos Vajna (1):
  git clone -s documentation: force a new paragraph for the NOTE

Pieter de Bie (2):
  Documentation/git-reset: don't mention --mixed for selected-paths reset
  Documentation/git-reset: Add an example of resetting selected paths

Sergei Organov (1):
  git-cvsimport.txt: fix '-M' description.

Shawn O. Pearce (1):
  fast-import: check return value from unpack_entry()

Stelian Pop (1):
  hg-to-git: fix parent analysis

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

Brian Downing (1):
  compat: Add simplified merge sort implementation from glibc

Christian Couder (7):
  help: make 'git-help--browse' usable outside 'git-help'.
  help--browse: add '--config' option to check a config option for a
    browser.
  Rename 'git-help--browse.sh' to 'git-web--browse.sh'.
  instaweb: use 'git-web--browse' to launch browser.
  Documentation: instaweb: add 'git-web--browse' information.
  web--browse: Add a few quotes in 'init_browser_path'.
  Documentation: add 'git-web--browse.txt' and simplify other docs.

Christian Stimming (2):
  git-gui: (i18n) Fix a bunch of still untranslated strings.
  git-gui: Update German translation.

Dmitry Potapov (1):
  git-web--browse: do not start the browser with nohup

Gerrit Pape (1):
  gitk: properly deal with tag names containing / (slash)

Jay Soffian (3):
  git-gui: support Git Gui.app under OS X 10.5
  git-help--browse: improve browser support under OS X
  git-web--browse: fix misplaced quote in init_browser_path()

Jeff King (2):
  allow suppressing of global and system config
  fix config reading in tests

Johan Herland (2):
  Add testcase for 'git cvsexportcommit -w $cvsdir ...' with relative
    $GIT_DIR
  Fix 'git cvsexportcommit -w $cvsdir ...' when used with relative $GIT_DIR

Johannes Schindelin (1):
  Adjust .gitignore for 5884f1(Rename 'git-help--browse.sh'...)

Johannes Sixt (1):
  gitk: Heed the lines of context in merge commits

Junio C Hamano (7):
  Documentation/SubmittingPatches: Instruct how to use [PATCH] Subject
    header
  Documentation/SubmittingPatches: discuss first then submit
  Documentation/SubmittingPatches: What's Acked-by and Tested-by?
  gitignore(5): Allow "foo/" in ignore list to match directory "foo"
  gitignore: lazily find dtype
  .mailmap: adjust to a recent patch application glitch.
  Documentation/SubmittingPatches - a suggested patch flow

Linus Torvalds (1):
  gitk: learn --show-all output

Michele Ballabio (1):
  gitk: Fix "Key bindings" message

Paolo Bonzini (4):
  git-commit: support variable number of hook arguments
  git-commit: set GIT_EDITOR=: if editor will not be launched
  git-commit: Refactor creation of log message.
  git-commit: add a prepare-commit-msg hook

Shawn O. Pearce (7):
  git-gui: Automatically spell check commit messages as the user types
  git-gui: Paper bag fix bad string length call in spellchecker
  git-gui: Correct size of dictionary name widget in options dialog
  Include annotated tags in fast-import crash reports
  Include the fast-import marks table in crash reports
  Finish current packfile during fast-import crash handler
  Update fast-import documentation to discuss crash reports

Steffen Prohaska (2):
  safecrlf: Add mechanism to warn about irreversible crlf conversions
  gitk: Add checkbutton to ignore space changes

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2008-01-14  1:53 Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2008-01-14  1:53 UTC (permalink / raw)
  To: git

* The 'master' branch has these since v1.5.4-rc3

Eric Wong (1):
  git-svn: handle leading/trailing whitespace from svnsync revprops

Jeff King (1):
  git-clean: fix off-by-one memory access when given no arguments

Junio C Hamano (1):
  builtin-commit.c: remove useless check added by faulty cut and paste

Linus Torvalds (1):
  Fix performance regression for partial commits

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-12-07  9:50                     ` Junio C Hamano
@ 2007-12-09 10:32                       ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-12-09 10:32 UTC (permalink / raw)
  To: git

One more topic remains in 'next' before 1.5.4-rc0 where "bugfix only"
freeze period begins.  We have a handful regression fixes on 'master'
from the fallout from massive C-rewrite during this cycle.

People still following 'next' are requested to switch to 'master', and
spare a bit more time on finding and fixing regressions there instead of
coming up with new topics from now on.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Jim Meyering (1):
  config.c:store_write_pair(): don't read the byte before a malloc'd
    buffer.

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

Jeff King (3):
  wt-status.c:quote_path(): convert empty path to "./"
  add status.relativePaths config variable
  git-status: documentation improvements

Junio C Hamano (13):
  War on whitespace: first, a bit of retreat.
  git-diff: complain about >=8 consecutive spaces in initial indent
  core.whitespace: add test for diff whitespace error highlighting
  builtin-apply: rename "whitespace" variables and fix styles
  builtin-apply: teach whitespace_rules
  core.whitespace: documentation updates.
  Use gitattributes to define per-path whitespace rule
  git-bisect visualize: work in non-windowed environments better
  mailmap: fix bogus for() loop that happened to be safe by accident
  shortlog: code restructuring and clean-up
  ls-remote: resurrect pattern limit support
  Fix commit-msg hook to allow editing
  Re-fix "builtin-commit: fix --signoff"

Nicolas Pitre (3):
  pack-objects: fix delta cache size accounting
  pack-objects: reverse the delta search sort list
  pack-objects: fix threaded load balancing

Pini Reznik (1):
  Open external merge tool with original file extensions for all three
    files

Sergei Organov (1):
  Let git-help prefer man-pages installed with this version of git

Wincent Colaiuta (4):
  Teach "git add -i" to colorize whitespace errors
  Allow --no-verify to bypass commit-msg hook
  Documentation: fix --no-verify documentation for "git commit"
  Add tests for pre-commit and commit-msg hooks

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-12-05 10:57                   ` Junio C Hamano
@ 2007-12-07  9:50                     ` Junio C Hamano
  2007-12-09 10:32                       ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-12-07  9:50 UTC (permalink / raw)
  To: git

Heavy merges to 'master' continues.  We are almost there for -rc0.
Merged to 'master' are:

 * Colorized "add -i" (Dan Zwell)
 * Talk more about diff options in "git log" documentation (Miklos)
 * git-gui 0.9.1 preview
 * Make cvsserver act more like receive-pack (Michael Witten)
 * "git-clean <paths>" limits the damage to named paths
 * Use right Perl in Documentation/Makefile

Also people's favorite topic "squelching compilation warnings for iconv"
is included.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

David Symonds (1):
  Change from using email.com to example.com as example domain, as per RFC
    2606.

Junio C Hamano (2):
  git grep shows the same hit repeatedly for unmerged paths
  git-am -i: report rewritten title

Nguyễn Thái Ngọc Duy (3):
  Add missing inside_work_tree setting in setup_git_directory_gently
  Do check_repository_format() early
  Do check_repository_format() early (re-fix)

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

Björn Steinbrink (1):
  git config: Don't rely on regexec() returning 1 on non-match

Brian M. Carlson (1):
  git-gui: Reorder msgfmt command-line arguments

Christian Stimming (2):
  Update git-gui.pot with latest (few) string additions and changes.
  Update German translation. 100% completed.

Jakub Narebski (1):
  autoconf: Add test for OLD_ICONV (squelching compiler warning)

Jeff King (1):
  t7300: add test for clean with wildcard pathspec

Johannes Sixt (2):
  git-gui: Improve the application icon on Windows.
  for-each-ref: Fix quoting style constants.

Junio C Hamano (12):
  Run the specified perl in Documentation/
  git-cvsserver runs hooks/post-update
  Revert "git-am: catch missing author date early."
  Documentation: color.* = true means "auto"
  git config --get-colorbool
  Color support for "git-add -i"
  git-clean: Honor pathspec.
  config --get-colorbool: diff.color is a deprecated synonym to color.diff
  hg-to-git: handle an empty dir in hg.
  do not discard status in fetch_refs_via_pack()
  git-status documentation: mention subdirectory behaviour
  Update draft release notes to 1.5.4

Kristian Høgsberg (1):
  Rewrite builtin-fetch option parsing to use parse_options().

Matthias Kestenholz (1):
  Documentation: add --patch option to synopsis of git-add

Michael Witten (1):
  git-cvsserver runs hooks/post-receive

Michele Ballabio (2):
  git-gui: fix a typo in lib/commit.tcl
  git-gui: update it.po and glossary/it.po

Miklos Vajna (2):
  Include diff options in the git-log manpage
  Update Hungarian translation. 100% completed.

Nanako Shiraishi (1):
  Update ja.po for git-gui

Robert Schiele (1):
  git-gui: install-sh from automake does not like -m755

Wincent Colaiuta (1):
  Silence iconv warnings on Leopard

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-12-04  8:43                 ` Junio C Hamano
@ 2007-12-05 10:57                   ` Junio C Hamano
  2007-12-07  9:50                     ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-12-05 10:57 UTC (permalink / raw)
  To: git

I haven't tagged the tip of 'master' as -rc0 yet, this has more than 80%
of it.  Graduated to 'master' tonight are:

 * Wincent's "git add -p"
 * "git commit in C" by Kristian and others
 * Steffen Prohaska's clean-up of push/fetch refspec handling.

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (2):
  Do not generate full commit log message if it is not going to be used
  Simplify crud() in ident.c

H.Merijn Brand (1):
  Do not rely on the exit status of "unset" for unset variables

Jakub Narebski (1):
  contrib: Make remotes2config.sh script more robust

Jeff King (3):
  git-commit: clean up die messages
  quote_path: fix collapsing of relative paths
  t9600: require cvsps 2.1 to perform tests

Johannes Schindelin (8):
  launch_editor(): read the file, even when EDITOR=:
  builtin-commit: fix reflog message generation
  git status: show relative paths when run in a subdirectory
  builtin-commit: fix --signoff
  builtin-commit --s: add a newline if the last line was not a S-o-b
  builtin-commit: resurrect behavior for multiple -m options
  builtin-commit: Add newline when showing which commit was created
  Replace "runstatus" with "status" in the tests

Junio C Hamano (15):
  file_exists(): dangling symlinks do exist
  builtin-commit: do not color status output shown in the message template
  builtin-commit: run commit-msg hook with correct message file
  Export three helper functions from ls-files
  Fix add_files_to_cache() to take pathspec, not user specified list of
    files
  builtin-commit: fix partial-commit support
  git-add -i: allow multiple selection in patch subcommand
  Add a few more tests for git-commit
  builtin-add: fix command line building to call interactive
  add -i: Fix running from a subdirectory
  Fix --signoff in builtin-commit differently.
  git-commit: Allow to amend a merge commit that does not change the tree
  git-commit --allow-empty
  Documentation/git.txt: typofix
  t5510: add a bit more tests for fetch

Kristian Høgsberg (10):
  Add testcase for amending and fixing author in git commit.
  Export launch_editor() and make it accept ':' as a no-op editor.
  Port git commit to C.
  builtin-commit: Refresh cache after adding files.
  Call refresh_cache() when updating the user index for --only commits.
  builtin-commit: Clean up an unused variable and a debug fprintf().
  t7501-commit: Add test for git commit <file> with dirty index.
  builtin-commit: Include the diff in the commit message when verbose.
  Fix off-by-one error when truncating the diff out of the commit message.
  Use a strbuf for copying the command line for the reflog.

Pascal Obry (1):
  Set OLD_ICONV on Cygwin.

Pierre Habouzit (1):
  builtin-commit.c: export GIT_INDEX_FILE for launch_editor as well.

Ralf Wildenhues (1):
  Document all help keys in "git add -i" patch mode.

Shawn Bohrer (1):
  Make git status usage say git status instead of git commit

Shawn O. Pearce (1):
  Remove git-status from list of scripts as it is builtin

Steffen Prohaska (4):
  push: support pushing HEAD to real branch name
  add refname_match()
  push: use same rules as git-rev-parse to resolve refspecs
  refactor fetch's ref matching to use refname_match()

Wincent Colaiuta (6):
  Teach builtin-add to pass multiple paths to git-add--interactive
  Add path-limiting to git-add--interactive
  Add "--patch" option to git-add--interactive
  Highlight keyboard shortcuts in git-add--interactive
  add -i: allow prefix highlighting for "Add untracked" as well.
  git-add -i: add help text for list-and-choose UI

İsmail Dönmez (1):
  gitweb: use Perl built-in utf8 function for UTF-8 decoding.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-12-01  2:05               ` Junio C Hamano
@ 2007-12-04  8:43                 ` Junio C Hamano
  2007-12-05 10:57                   ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-12-04  8:43 UTC (permalink / raw)
  To: git

Nothing exciting on 'maint' since 1.5.3.7.

On the 'master' front, we will soon be in feature freeze for 1.5.4.
Many topics that have been cooking in 'next' has been pushed out.  This
round it is a rather large batch but hopefully it will not destabilize
it too much.  Knock wood.

 * "git pull --rebase" is a different way to integrate what you fetched
   into your current branch.

 * "git fast-export" produces datastream that can be fed to fast-import
   to reproduce the history recorded in a git repository.

 * gitk is now merged as a subdirectory of git.git project, in
   preparation for its i18n.

 * Value "true" for color.diff and color.status configuration used to
   mean "always" (even when the output is not going to a terminal).
   This has been corrected to mean the same thing as "auto".

 * "git commit --allow-empty" allows you to create a single-parent
   commit that records the same tree as its parent, overriding the usual
   safety valve.

 * "git stash random-text" does not create a new stash anymore.  It was
   a UI mistake.  Use "git stash save random-text", or "git stash"
   (without extra args) for that.

 * HTTP proxy can be specified per remote repository using
   remote.*.proxy configuration, or global http.proxy configuration
   variable.

 * "git rebase -i" also triggers rerere to help you repeated merges.

 * "git prune --expire <time>" can exempt young loose objects from
   getting pruned.

 * "git branch --contains <commit>" can list branches that are
   descendants of a given commit.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Jeff King (1):
  t9600: test cvsimport from CVS working tree

Junio C Hamano (2):
  Fix typo in t4008 test title
  GIT 1.5.3.7


* The 'master' branch has these since the last announcement
  in addition to the above.

Andy Whitcroft (1):
  git-svn: add support for pulling author from From: and Signed-off-by:

Carlos Rica (1):
  Make builtin-tag.c use parse_options.

Christian Couder (2):
  Documentation: add a new man page for "git-help"
  Trace and quote with argv: get rid of unneeded count argument.

David D. Kilzer (1):
  git-svn: Remove unnecessary Git::SVN::Util package

David Symonds (1):
  Mention that git-rm can be an appropriate resolution as well as git-add.

Denis Cheng (1):
  gitweb: the commitdiff is very commonly used, it's needed on search page,
    too

Gustaf Hendeby (1):
  git-svn now reads settings even if called in subdirectory

Jakub Narebski (1):
  gitweb: Update and improve gitweb/README file

Jeff King (2):
  git-tag: test that -s implies an annotated tag
  Enable rewrite as well as rename detection in git-status

Johannes Schindelin (7):
  Replace instances of export VAR=VAL with VAR=VAL; export VAR
  Teach 'git pull' about --rebase
  rebase -i: give rerere a chance
  Add "--expire <time>" option to 'git prune'
  Add 'git fast-export', the sister of 'git fast-import'
  fast-export: rename the signed tag mode 'ignore' to 'verbatim'
  Allow ':/<oneline-prefix>' syntax to work with save_commit_buffer == 0

Johannes Sixt (1):
  git-commit: Allow to amend a merge commit that does not change the tree

Junio C Hamano (17):
  Move gitk to its own subdirectory
  git-branch --contains=commit
  git-branch --contains: doc and test
  builtin-tag: accept and process multiple -m just like git-commit
  "git-tag -s" should create a signed annotated tag
  "color.diff = true" is not "always" anymore.
  git-config --get-color: get configured color
  Update draft release notes for 1.5.4
  Resurrect peek-remote
  Consolidate command list to one.
  Update draft release notes for 1.5.4
  rename: Break filepairs with different types.
  git-am: catch missing author date early.
  git-commit --allow-empty
  git-commit documentation: fix unfinished sentence.
  Add git-fast-export to list of commands.
  Update draft release notes for 1.5.4

Kevin Leung (1):
  git-stash: Display help message if git-stash is run with wrong
    sub-commands

Pierre Habouzit (1):
  parse-options: Allow to hide options from the default usage.

Robert Schiele (1):
  install-sh from automake does not like -m without delimiting space

Sam Vilain (2):
  Allow HTTP proxy to be overridden in config
  Add remote.<name>.proxy

Steven Grimm (1):
  git-svn: Don't create a "master" branch every time rebase is run

Theodore Ts'o (2):
  Make the list of common commands more exclusive
  Remove hint to use "git help -a"

Vineet Kumar (1):
  git-svn: add a show-externals command.

Wincent Colaiuta (1):
  revert/cherry-pick: Allow overriding the help text by the calling
    Porcelain

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-11-25 20:45             ` Junio C Hamano
@ 2007-12-01  2:05               ` Junio C Hamano
  2007-12-04  8:43                 ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-12-01  2:05 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since the last announcement.

J. Bruce Fields (4):
  user-manual: define "branch" and "working tree" at start
  user-manual: failed push to public repository
  user-manual: clarify language about "modifying" old commits
  user-manual: recovering from corruption

Jan Hudec (1):
  Improve description of git-branch -d and -D in man page.

Jeff King (4):
  Add basic cvsimport tests
  cvsimport: use rev-parse to support packed refs
  cvsimport: miscellaneous packed-ref fixes
  cvsimport: fix usage of cvsimport.module

Johannes Schindelin (1):
  Replace the word 'update-cache' by 'update-index' everywhere

Johannes Sixt (1):
  t7003-filter-branch: Fix test of a failing --msg-filter.

Junio C Hamano (1):
  scripts: do not get confused with HEAD in work tree


* The 'master' branch has these since the last announcement
  in addition to the above.

André Goddard Rosa (2):
  Print the real filename that we failed to open.
  Error out when user doesn't have access permission to the repository

Jakub Narebski (1):
  Add config_int() method to the Git perl module

Jeff King (1):
  Revert "t5516: test update of local refs on push"

Johannes Schindelin (4):
  filter-branch: fix dirty way to provide the helpers to commit filters
  git checkout's reflog: even when detaching the HEAD, say from where
  bash completion: add diff options
  receive-pack: allow deletion of corrupt refs

Junio C Hamano (3):
  revert/cherry-pick: do not mention the original ref
  dir.c: minor clean-up
  per-directory-exclude: lazily read .gitignore files

Linus Torvalds (2):
  Fix a pathological case in git detecting proper renames
  Fix a pathological case in git detecting proper renames

Pascal Obry (1):
  git-stash: do not get fooled with "color.diff = true"

Steffen Prohaska (2):
  Use is_absolute_path() in diff-lib.c, lockfile.c, setup.c, trace.c
  sha1_file.c: Fix size_t related printf format warnings

Wincent Colaiuta (1):
  Fix typo in draft 1.5.4 release notes

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-11-17 21:00           ` Junio C Hamano
@ 2007-11-25 20:45             ` Junio C Hamano
  2007-12-01  2:05               ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-11-25 20:45 UTC (permalink / raw)
  To: git

There are quite a few backported fixes on 'maint' and it might make
sense to cut 1.5.3.7 soon.

On 'master' front, many topics that have been cooking in 'next' have
graduated.  Notably:

 - git-bisect learns "skip";

 - git-rebase --skip does not need "reset --hard" beforehand;

 - git-clean is now in C;

 - git-push is much more careful reporting errors and updateing tracking
   refs.

 - git-push learns --mirror option.

Also contains the 0.9.0 series of git-gui with i18n.

----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.

Björn Steinbrink (3):
  git-commit.sh: Fix usage checks regarding paths given when they do
      not make sense
  t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
  git-commit: Add tests for invalid usage of -a/--interactive with paths

Brian Downing (2):
  config: correct core.loosecompression documentation
  config: clarify compression defaults

J. Bruce Fields (3):
  git-remote.txt: fix example url
  user-manual: mention "..." in "Generating diffs", etc.
  Documentation: Fix references to deprecated commands

Jeff King (1):
  send-email: add transfer encoding header with content-type

Johannes Schindelin (1):
  bundle create: keep symbolic refs' names instead of resolving them

Junio C Hamano (10):
  format-patch -s: add MIME encoding header if signer's name requires so
  test format-patch -s: make sure MIME content type is shown as needed
  ce_match_stat, run_diff_files: use symbolic constants for readability
  git-add: make the entry stat-clean after re-adding the same contents
  t2200: test more cases of "add -u"
  grep -An -Bm: fix invocation of external grep command
  GIT 1.5.3.6
  Make test scripts executable.
  Fix sample pre-commit hook
  git-checkout: describe detached head correctly

Linus Torvalds (1):
  Fix rev-list when showing objects involving submodules

Matthieu Moy (1):
  Doc fix for git-reflog: mention @{...} syntax, and <ref> in synopsys.

Rémi Vanicat (1):
  Make GIT_INDEX_FILE apply to git-commit

Steffen Prohaska (1):
  user-manual: Add section "Why bisecting merge commits can be harder ..."


----------------------------------------------------------------
* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (4):
  More updates and corrections to the russian translation of git-gui
  Updated russian translation of git-gui
  Add a test checking if send-pack updated local tracking branches
      correctly
  Update the tracking references only if they were succesfully
      updated on remote

Andy Whitcroft (5):
  Teach send-pack a mirror mode
  git-push: plumb in --mirror mode
  Add tests for git push'es mirror mode
  git-push: add documentation for the newly added --mirror mode
  git-quiltimport.sh fix --patches handling

Anton Gyllenberg (1):
  gitview: import only one of gtksourceview and gtksourceview2

Ask Bjørn Hansen (1):
  send-email: Don't add To: recipients to the Cc: header

Christian Couder (4):
  Bisect reset: remove bisect refs that may have been packed.
  Bisect visualize: use "for-each-ref" to list all good refs.
  Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.
  Bisect reset: do nothing when not bisecting.

Christian Stimming (12):
  Mark strings for translation.
  Makefile rules for translation catalog generation and installation.
  Add glossary that can be converted into a po file for each
      language.
  Add glossary translation template into git.
  German translation for git-gui
  German glossary for translation
  git-gui: Add more words to translation glossary
  git-gui: Update German glossary according to mailing list
      discussion
  git-gui: Incorporate glossary changes into existing German
      translation
  git-gui: Update German translation, including latest glossary
      changes
  git-gui: Add more terms to glossary.
  git-gui: Update German translation

Daniel Barkalow (5):
  Miscellaneous const changes and utilities
  Build-in peek-remote, using transport infrastructure.
  Use built-in send-pack.
  Build-in send-pack, with an API for other programs to call.
  Build in ls-remote

David D Kilzer (3):
  git-svn log: fix ascending revision ranges
  git-svn log: include commit log for the smallest revision in a
      range
  git-svn log: handle unreachable revisions like "svn log"

David D. Kilzer (4):
  git-send-email: show all headers when sending mail
  git-svn: extract reusable code into utility functions
  git-svn info: implement info command
  git-svn: info --url [path]

David Reiss (1):
  git-svn: Fix a typo and add a comma in an error message in git-svn

David Symonds (2):
  git-checkout: Support relative paths containing "..".
  git-checkout: Test for relative path use.

Eric Wong (3):
  git-svn: add tests for command-line usage of init and clone
      commands
  t9106: fix a race condition that caused svn to miss modifications
  git-svn: allow `info' command to work offline

Guido Ostkamp (1):
  Use compat mkdtemp() on Solaris boxes

Harri Ilari Tapio Liusvaara (1):
  git-gui: Disambiguate "commit"

Irina Riesen (1):
  git-gui: initial version of russian translation

Jakub Narebski (3):
  gitweb: Style all tables using CSS
  gitweb: Put project README in div.readme, fix its padding
  autoconf: Add tests for memmem, strtoumax and mkdtemp functions

Jeff King (11):
  more terse push output
  receive-pack: don't mention successful updates
  send-pack: require --verbose to show update of tracking refs
  send-pack: track errors for each ref
  send-pack: check ref->status before updating tracking refs
  send-pack: assign remote errors to each ref
  make "find_ref_by_name" a public function
  send-pack: tighten remote error reporting
  send-pack: fix "everything up-to-date" message
  avoid "defined but not used" warning for fetch_objs_via_walker
  send-pack: cluster ref status reporting

Johannes Schindelin (9):
  Add po/git-gui.pot
  Ignore po/*.msg
  git-gui: Deiconify startup wizard so it raises to the top
  git-gui: add a simple msgfmt replacement
  po2msg: ignore entries marked with "fuzzy"
  po2msg: ignore untranslated messages
  po2msg: actually output statistics
  Close files opened by lock_file() before unlinking.
  rebase -i: move help to end of todo file

Johannes Sixt (14):
  git-gui: Change main window layout to support wider screens
  Give git-am back the ability to add Signed-off-by lines.
  t5300-pack-object.sh: Split the big verify-pack test into smaller
      parts.
  t7501-commit.sh: Not all seds understand option -i
  t5302-pack-index: Skip tests of 64-bit offsets if necessary.
  Skip t3902-quoted.sh if the file system does not support funny
      names.
  Use is_absolute_path() in sha1_file.c.
  Move #include <sys/select.h> and <sys/ioctl.h> to
      git-compat-util.h.
  builtin run_command: do not exit with -1.
  Allow a relative builtin template directory.
  Introduce git_etc_gitconfig() that encapsulates access of
      ETC_GITCONFIG.
  Allow ETC_GITCONFIG to be a relative path.
  fetch-pack: Prepare for a side-band demultiplexer in a thread.
  Flush progress message buffer in display().

Junio C Hamano (20):
  git-gui po/README: Guide to translators
  git-gui: Update Japanese strings (part 2)
  scripts: Add placeholders for OPTIONS_SPEC
  git-rev-parse --parseopt
  git-sh-setup: fix parseopt `eval` string underquoting
  send-pack: segfault fix on forced push
  git-am: -i does not take a string parameter.
  git-bisect: war on "sed"
  git-bisect: use update-ref to mark good/bad commits
  git-bisect: modernize branch shuffling hack
  Draft release notes: fix clean.requireForce description
  Update draft release notes for 1.5.4
  git-clean: Fix error message if clean.requireForce is not set.
  git-compat-util.h: auto-adjust to compiler support of FLEX_ARRAY a
      bit better
  Fix "quote" misconversion for rewrite diff output.
  Make test scripts executable.
  Addendum to "MaintNotes"
  t4119: correct overeager war-on-whitespace
  Deprecate peek-remote
  Update draft release notes for 1.5.4

Kirill (1):
  Updated Russian translation.

Konstantin V. Arkhipov (1):
  git-svn's dcommit must use subversion's config

Linus Torvalds (6):
  Simplify topo-sort logic
  Add "--early-output" log flag for interactive GUI use
  Enhance --early-output format
  revision walker: mini clean-up
  Fix rev-list when showing objects involving submodules
  Fix parent rewriting in --early-output

Michele Ballabio (4):
  git-gui: remove dots in some UI strings
  git-gui: add some strings to translation
  git-gui: fix typo in lib/blame.tcl
  git-gui: update Italian translation

Mike Hommey (1):
  Do git reset --hard HEAD when using git rebase --skip

Miklos Vajna (1):
  Hungarian translation of git-gui

Nanako Shiraishi (2):
  Japanese translation of git-gui
  git-gui: Update Japanese strings

Nicolas Pitre (1):
  rehabilitate some t5302 tests on 32-bit off_t machines

Paolo Ciarrocchi (1):
  Italian translation of git-gui

Pierre Habouzit (17):
  Add a parseopt mode to git-rev-parse to bring parse-options to
      shell scripts.
  Update git-sh-setup(1) to allow transparent use of git-rev-parse
      --parseopt
  Migrate git-clean.sh to use git-rev-parse --parseopt.
  Migrate git-clone to use git-rev-parse --parseopt
  Migrate git-am.sh to use git-rev-parse --parseopt
  Migrate git-merge.sh to use git-rev-parse --parseopt
  Migrate git-instaweb.sh to use git-rev-parse --parseopt
  Migrate git-checkout.sh to use git-rev-parse --parseopt
      --keep-dashdash
  Migrate git-quiltimport.sh to use git-rev-parse --parseopt
  Migrate git-repack.sh to use git-rev-parse --parseopt
  sh-setup: don't let eval output to be shell-expanded.
  parse-options new features.
  Use OPT_SET_INT and OPT_BIT in builtin-branch
  Use OPT_BIT in builtin-for-each-ref
  Use OPT_BIT in builtin-pack-refs
  Make the diff_options bitfields be an unsigned with explicit masks.
  Reorder diff_opt_parse options more logically per topics.

Shawn Bohrer (2):
  Make git-clean a builtin
  Teach git clean to use setup_standard_excludes()

Shawn O. Pearce (57):
  git-gui: Locate the library directory early during startup
  git-gui: Initialize Tcl's msgcat library for internationalization
  git-gui: Update po/README as symlink process is not necessary
  git-gui: Correct stock message for 'Invalid font specified in %s'
  git-gui: Quiet the msgfmt part of the make process
  git-gui: Ensure msgfmt failure stops GNU make
  git-gui: Mark revision chooser tooltip for translation
  git-gui: Localize commit/author dates when displaying them
  git-gui: Support context-sensitive i18n
  git-gui: Document the new i18n context support
  git-gui: Make the tree browser also use lightgray selection
  git-gui: Paper bag fix missing translated strings
  git-gui: Fix missing i18n markup in push/fetch windows
  git-gui: Support native Win32 Tcl/Tk under Cygwin
  git-gui: Refactor some UI init to occur earlier
  git-gui: Allow users to choose/create/clone a repository
  git-gui: Avoid console scrollbars unless they are necessary
  git-gui: Don't bother showing OS error message about hardlinks
  git-gui: Keep the UI responsive while counting objects in clone
  git-gui: Copy objects/info/alternates during standard clone
  git-gui: Don't delete console window namespaces too early
  git-gui: Don't delete scrollbars in console windows
  git-gui: Switch the git-gui logo to Henrik Nyh's logo
  git-gui: Make the status bar easier to read in the setup wizard
  git-gui: Use Henrik Nyh's git logo icon on Windows systems
  git-gui: Support a native Mac OS X application bundle
  git-gui: Refer to ourselves as "Git Gui" and not "git-gui"
  git-gui: Allow forced push into remote repository
  git-gui: Refactor Henrik Nyh's logo into its own procedure
  git-gui: Refactor about dialog code into its own module
  git-gui: Include our Git logo in the about dialog
  git-gui: Use progress meter in the status bar during index updates
  git-gui: Consolidate the Fetch and Push menus into a Remote menu
  git-gui: Bind Cmd-, to Preferences on Mac OS X
  git-gui: Shorten the staged/unstaged changes title bar text
  git-gui: Updated po strings based on current sources
  git-gui: Move load_config procedure below git-version selection
  git-gui: Refactor git-config --list parsing
  git-gui: Support LFs embedded in config file values
  git-gui: Change repository browser radio buttons to hyperlinks
  git-gui: Offer repository management features in menu bar
  git-gui: Fix bind errors when switching repository chooser panels
  git-gui: Disable the text widget in the repository chooser
  git-gui: Bind n/c/o accelerators in repository chooser
  git-gui: Ensure copyright message is correctly read as UTF-8
  git-gui: Use proper Windows shortcuts instead of bat files
  git-gui: Support cloning Cygwin based work-dirs
  git-gui: Collapse $env(HOME) to ~/ in recent repositories on
      Windows
  git-gui: Honor a config.mak in git-gui's top level
  git-gui: Paper bag fix the global config parsing
  git-gui: Make sure we get errors from git-update-index
  git-gui: Protect against bad translation strings
  git-gui: Allow users to set font weights to bold
  Reteach builtin-ls-remote to understand remotes
  git-gui: Bind Meta-T for "Stage To Commit" menu action
  Fix warning about bitfield in struct ref
  git-gui 0.9.0

Shun Kei Leung (1):
  git-p4: Fix typo in --detect-labels

Simon Hausmann (1):
  git-p4: Fix direct import from perforce after fetching changes
      through git from origin

Steffen Prohaska (4):
  git-gui: add directory git-gui is located in to PATH (on Windows)
  git-gui: set NO_MSGFMT to force using pure tcl replacement in
      msysgit
  git-gui: add mingw specific startup wrapper
  git-gui: offer a list of recent repositories on startup

Thomas Harning (1):
  git-merge-ours: make it a builtin.

Wincent Colaiuta (3):
  Further clarify clean.requireForce changes
  Authenticate only once in git-send-email
  Refactor patch_update_cmd

Xudong Guan (2):
  Initial Chinese translation for git-gui
  git-gui: Added initial version of po/glossary/zh_cn.po

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-11-15  0:20         ` Junio C Hamano
@ 2007-11-17 21:00           ` Junio C Hamano
  2007-11-25 20:45             ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-11-17 21:00 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since the last announcement.

There are a few candidate fixes for back-porting from the
development series (see "What's cooking" message).  I will
include them in 1.5.3.6, probably on or around 20th of this
month.

David Symonds (1):
  Improve accuracy of check for presence of deflateBound.

Jeff King (1):
  git-send-email: add charset header if we add encoded 'From'

Junio C Hamano (3):
  core.excludesfile clean-up
  Fix per-directory exclude handing for "git add"
  Update draft release notes for 1.5.3.6

Wincent Colaiuta (1):
  Fix t9101 test failure caused by Subversion "auto-props"


* The 'master' branch has these since the last announcement
  in addition to the above.

Guido Ostkamp (1):
  Remove unreachable statements

Jeff King (1):
  git-ls-files: add --exclude-standard

Johannes Sixt (1):
  refs.c: Remove unused get_ref_sha1()

Junio C Hamano (2):
  Fix per-directory exclude handing for "git add"
  Update draft release notes for 1.5.4

Mike Hommey (1):
  Fix and improve t7004 (git-tag tests)

Sergei Organov (3):
  Documentation: customize diff-options depending on particular
      command
  user-manual.txt: minor clarification.
  Documentation: fix git-clone manpage not to refer to itself

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-11-12  7:06       ` Junio C Hamano
@ 2007-11-15  0:20         ` Junio C Hamano
  2007-11-17 21:00           ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-11-15  0:20 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since the last announcement.

Benoit Sigoure (1):
  git-svn: prevent dcommitting if the index is dirty.

Christian Couder (1):
  for-each-ref: fix off by one read.

Jeff King (1):
  git-branch: remove mention of non-existent '-b' option

Jing Xue (1):
  replace reference to git-rm with git-reset in git-commit doc

Jonas Fonseca (1):
  Documentation: Fix man page breakage with DocBook XSL v1.72

Junio C Hamano (3):
  t/t3404: fix test for a bogus todo file.
  revert/cherry-pick: allow starting from dirty work tree.
  git-clean: honor core.excludesfile

Sergei Organov (2):
  core-tutorial.txt: Fix argument mistake in an example.
  git-remote.txt: fix typo

Shawn O. Pearce (2):
  Fix memory leak in traverse_commit_list
  Don't allow fast-import tree delta chains to exceed maximum depth

Wincent Colaiuta (1):
  Grammar fixes for gitattributes documentation


* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (1):
  Fix dependencies of parse-options test program

Andreas Ericsson (1):
  Simplify strchrnul() compat code

Björn Steinbrink (3):
  git-commit.sh: Fix usage checks regarding paths given when they do
      not make sense
  t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
  git-commit: Add tests for invalid usage of -a/--interactive with
      paths

Brian Gernhardt (2):
  format-patch: Add configuration and off switch for --numbered
  format-patch: Test --[no-]numbered and format.numbered

David Symonds (1):
  Rearrange git-format-patch synopsis to improve clarity.

Emil Medve (1):
  git-stash: Fix listing stashes

Eric Wong (1):
  git-svn: support for funky branch and project names over HTTP(S)

Gordon Hopper (1):
  git-cvsimport: fix handling of user name when it is not set in
      CVSROOT

Johannes Schindelin (2):
  rebase: operate on a detached HEAD
  rebase: fix "rebase --continue" breakage

Johannes Sixt (2):
  git-clean: Fix error message if clean.requireForce is not set.
  Fix preprocessor logic that determines the availablity of
      strchrnul().

Jonas Fonseca (1):
  Documentation: Fix references to deprecated commands

Junio C Hamano (9):
  stash: implement "stash create"
  rebase: allow starting from a dirty tree.
  Revert "rebase: allow starting from a dirty tree."
  git-merge: no reason to use cpio anymore
  ce_match_stat, run_diff_files: use symbolic constants for
      readability
  git-add: make the entry stat-clean after re-adding the same
      contents
  t2200: test more cases of "add -u"
  Resurrect git-revert.sh example and add comment to builtin-revert.c
  core.excludesfile clean-up

Mike Hommey (2):
  Reuse previous annotation when overwriting a tag
  Add tests for git tag

Nicolas Pitre (6):
  fix display overlap between remote and local progress
  sideband.c: ESC is spelled '\033' not '\e' for portability.
  make display of total transferred more accurate
  remove dead code from the csum-file interface
  make display of total transferred fully accurate
  nicer display of thin pack completion

Pierre Habouzit (1):
  git-fetch: be even quieter.

René Scharfe (5):
  Add strchrnul()
  --pretty=format: on-demand format expansion
  --pretty=format: parse commit message only once
  add strbuf_adddup()
  --format=pretty: avoid calculating expensive expansions twice

Robin Rosenberg (1):
  cvsexportcommit: Add switch to specify CVS workdir

Rémi Vanicat (1):
  Make GIT_INDEX_FILE apply to git-commit

Sergei Organov (2):
  user-manual.txt: fix a few mistakes
  user-manual: minor rewording for clarity.

Shawn O. Pearce (5):
  git-fetch: Always fetch tags if the object they reference exists
  run-command: Support sending stderr to /dev/null
  rev-list: Introduce --quiet to avoid /dev/null redirects
  git-fetch: avoid local fetching from alternate (again)
  Handle broken vsnprintf implementations in strbuf

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-11-08  8:06     ` Junio C Hamano
  2007-11-08 11:38       ` Pierre Habouzit
@ 2007-11-12  7:06       ` Junio C Hamano
  2007-11-15  0:20         ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-11-12  7:06 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since the last announcement.

Alex Riesen (1):
  stop t1400 hiding errors in tests

Benoit Sigoure (1):
  git-send-email: Change the prompt for the subject of the initial
      message.

Gerrit Pape (1):
  git-mailsplit: with maildirs not only process cur/, but also new/

Jonas Fonseca (1):
  instaweb: Minor cleanups and fixes for potential problems

Junio C Hamano (3):
  refresh_index_quietly(): express "optional" nature of index writing
      better
  Makefile: add missing dependency on wt-status.h
  Start preparing for 1.5.3.6

Nicolas Pitre (3):
  print warning/error/fatal messages in one shot
  git-hash-object should honor config variables
  fix index-pack with packs >4GB containing deltas on 32-bit machines

Ralf Wildenhues (2):
  Avoid a few unportable, needlessly nested "...`...".
  Fix sed string regex escaping in module_name.

Sergei Organov (1):
  SubmittingPatches: improve the 'Patch:' section of the checklist

Vincent Zanotti (1):
  gitweb: correct month in date display for atom feeds


* The 'master' branch has these since the last announcement
  in addition to the above.

Gerrit Pape (3):
  hooks--update: fix test for properly set up project description
      file
  hooks--update: decline deleting tags or branches by default, add
      config options
  contrib/hooks/post-receive-email: remove cruft, $committer is not
      used

Johannes Schindelin (4):
  parse-options: abbreviation engine fix.
  builtin-reset: do not call "ls-files --unmerged"
  builtin-reset: avoid forking "update-index --refresh"
  builtin-blame: set up the work_tree before the first file access

Johannes Sixt (1):
  upload-pack: Use finish_{command,async}() instead of waitpid().

Junio C Hamano (6):
  Style: place opening brace of a function definition at column 1
  Update draft release notes for 1.5.4
  Documentation: lost-found is now deprecated.
  Make check-docs target detect removed commands
  Documentation: remove documentation for removed tools.
  git-commit: a bit more tests

Lars Hjemli (1):
  for-each-ref: fix setup of option-parsing for --sort

Michele Ballabio (1):
  test-lib.sh: move error line after error() declaration

Nicolas Pitre (1):
  add a howto document about corrupted blob recovery

Ralf Wildenhues (1):
  git-bisect.sh: Fix sed script to work with AIX and BSD sed.

Sergei Organov (1):
  core-tutorial.txt: Fix git-show-branch example and its description

Steffen Prohaska (2):
  push: mention --verbose option in documentation
  push: teach push to pass --verbose option to transport layer

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-11-08  8:06     ` Junio C Hamano
@ 2007-11-08 11:38       ` Pierre Habouzit
  2007-11-12  7:06       ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Pierre Habouzit @ 2007-11-08 11:38 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

On Thu, Nov 08, 2007 at 08:06:14AM +0000, Junio C Hamano wrote:
> On 'master' front:
> 
>  - git-p4 in contrib/ has updates.  As I cannot test it myself
>    and did not hear any success/failure stories from the list,
>    the only way to make sure is to push it out and see if
>    anybody screams.
> 
>  - "git lost-found" is going to be deprecated (not removed) in
>    the next feature release.
> 
>  - Unspecified clean.requireForce defaults to true; this would
>    make "git clean" require "-f" by default.
> 
>  - "git send-email --suppress-from" does not CC yourself even
>    when your name is on S-o-b: or Cc: lines in the body of the
>    message.
> 
> ----------------------------------------------------------------
> 
> * The 'maint' branch has these fixes since the last announcement.
[...]
> Pierre Habouzit (1):
>   Some better parse-options documentation.

  Eeeer isn't there some kind of problem ? This is not in maint, I
believe you swapped 'master' and 'maint' :)

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-11-04  3:52   ` Junio C Hamano
@ 2007-11-08  8:06     ` Junio C Hamano
  2007-11-08 11:38       ` Pierre Habouzit
  2007-11-12  7:06       ` Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-11-08  8:06 UTC (permalink / raw)
  To: git

On 'master' front:

 - git-p4 in contrib/ has updates.  As I cannot test it myself
   and did not hear any success/failure stories from the list,
   the only way to make sure is to push it out and see if
   anybody screams.

 - "git lost-found" is going to be deprecated (not removed) in
   the next feature release.

 - Unspecified clean.requireForce defaults to true; this would
   make "git clean" require "-f" by default.

 - "git send-email --suppress-from" does not CC yourself even
   when your name is on S-o-b: or Cc: lines in the body of the
   message.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Ask Bjørn Hansen (1):
  When exec() fails include the failing command in the error message

David D Kilzer (2):
  RelNotes-1.5.3.5: fix typo
  RelNotes-1.5.3.5: fix another typo

Eric Wong (2):
  git-svn: fix dcommit clobbering when committing a series of diffs
  git-svn: t9114: verify merge commit message in test

Gerrit Pape (3):
  git-diff.txt: add section "output format" describing the diff
      formats
  git-cvsimport: really convert underscores in branch names to dots
      with -u
  git-daemon: fix remote port number in log entry

Johannes Schindelin (1):
  Add Documentation/CodingGuidelines

Junio C Hamano (1):
  grep with unmerged index

Marco Costalba (1):
  Remove a couple of duplicated include

Mike Hommey (1):
  Delay pager setup in git blame


* The 'master' branch has these since the last announcement
  in addition to the above.

Benoit Sigoure (1):
  git-svn: sort the options in the --help message.

Brian Gernhardt (1):
  t3502: Disambiguate between file and rev by adding --

Chris Pettitt (2):
  git-p4: Add a helper function to parse the full git diff-tree
      output.
  git-p4: Detect changes to executable bit and include them in p4
      submit.

Daniel Barkalow (1):
  Use parseopts in builtin-push

David Symonds (1):
  Improve accuracy of check for presence of deflateBound.

Gerrit Pape (4):
  git-reset: add -q option to operate quietly
  contrib/hooks/post-receive-email: fix typo
  contrib/hooks/post-receive-email: reformat to wrap comments at 76
      chars
  contrib/hooks/post-receive-email: make subject prefix configurable

Heikki Orsila (1):
  git-clone: honor "--" to end argument parsing

J. Bruce Fields (1):
  errors: "strict subset" -> "ancestor"

Jakub Narebski (9):
  gitweb: Always set 'from_file' and 'to_file' in
      parse_difftree_raw_line
  gitweb: Add 'status_str' to parse_difftree_raw_line output
  gitweb: Remove CGI::Carp::set_programname() call from t9500 gitweb
      test
  gitweb: Easier adding/changing parameters to current URL
  gitweb: Use href(-replay=>1, page=>...) to generate pagination
      links
  gitweb: Use href(-replay=>1, action=>...) to generate alternate
      views
  gitweb: Add tests for overriding gitweb config with repo config
  gitweb: Read repo config using 'git config -z -l'
  gitweb: Use config file for repository description and URLs

Johannes Schindelin (3):
  git-reset: do not be confused if there is nothing to reset
  Split off the pretty print stuff into its own file
  Deprecate git-lost-found

Johannes Sixt (1):
  Fix an infinite loop in sq_quote_buf().

Junio C Hamano (6):
  revert/cherry-pick: work on merge commits as well
  format-patch -s: add MIME encoding header if signer's name requires
      so
  cherry-pick/revert -m: add tests
  test format-patch -s: make sure MIME content type is shown as
      needed
  clean: require -f to do damage by default
  gc: --prune prunes unreferenced objects.

Mike Hommey (5):
  Refactor working tree setup
  Use setup_work_tree() in builtin-ls-files.c
  Don't always require working tree for git-rm
  Make git-blame fail when working tree is needed and we're not in
      one
  Small code readability improvement in show_reference() in
      builtin-tag.c

Nicolas Pitre (4):
  make the pack index version configurable
  pack-objects: get rid of an ugly cast
  git-fetch: more terse fetch output
  restore fetching with thin-pack capability

Pierre Habouzit (1):
  Some better parse-options documentation.

Ralf Wildenhues (1):
  Fix minor nits in configure.ac

Shawn Bohrer (1):
  Add more tests for git-clean

Simon Sasburg (1):
  Make mailsplit and mailinfo strip whitespace from the start of the
      input

Steffen Prohaska (1):
  Fix comment in strbuf.h to use correct name strbuf_avail()

Steven Grimm (1):
  builtin-fetch: Add "-q" as a synonym for "--quiet"

Uwe Kleine-König (1):
  send-email: apply --suppress-from to S-o-b and cc-cmd

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-11-01  5:39 ` What's in git.git (stable) Junio C Hamano
@ 2007-11-04  3:52   ` Junio C Hamano
  2007-11-08  8:06     ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-11-04  3:52 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since the last announcement.

Brad King (1):
  cvsexportcommit: fix for commits that do not have parents

Jakub Narebski (1):
  gitweb: Update config file example for snapshot feature in
      gitweb/INSTALL

Jonas Fonseca (1):
  Remove escaping of '|' in manpage option sections

Jonathan del Strother (1):
  Fixing path quoting in git-rebase

Kristian Høgsberg (1):
  Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test
      suites.

Ralf Wildenhues (1):
  git-clone.txt: Improve --depth description.

Sergei Organov (3):
  git-filter-branch.txt: fix a typo.
  git-format-patch.txt: fix explanation of an example.
  Documentation: quote commit messages consistently.

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.  Notable topics are:

  - fork-exec removal from MinGW work.
  - the first batch of parse-options.
  - terse progress display.

Short log follows.

Alex Riesen (2):
  Rework make_usage to print the usage message immediately
  Do no colorify test output if stdout is not a terminal

Blake Ramsdell (1):
  transport.c: squelch a gcc 4.0.1 complaint about an uninitialized
      variable

Emil Medve (1):
  Fixed a command line option type for builtin-fsck.c

Gerrit Pape (1):
  git-diff.txt: add section "output format" describing the diff
      formats

James Bowes (1):
  gc: use parse_options

Johannes Schindelin (2):
  Add tests for parse-options.c
  parse-options: Allow abbreviated options when unambiguous

Johannes Sixt (14):
  Change git_connect() to return a struct child_process instead of a
      pid_t.
  Use start_command() in git_connect() instead of explicit fork/exec.
  Use start_command() to run content filters instead of explicit
      fork/exec.
  Use run_command() to spawn external diff programs instead of
      fork/exec.
  Use start_comand() in builtin-fetch-pack.c instead of explicit
      fork/exec.
  Have start_command() create a pipe to read the stderr of the child.
  upload-pack: Use start_command() to run pack-objects in
      create_pack_file().
  Add infrastructure to run a function asynchronously.
  Use the asyncronous function infrastructure in
      builtin-fetch-pack.c.
  upload-pack: Move the revision walker into a separate function.
  upload-pack: Run rev-list in an asynchronous function.
  t0021-conversion.sh: Test that the clean filter really cleans
      content.
  Avoid a dup2(2) in apply_filter() - start_command() can do it for
      us.
  Use the asyncronous function infrastructure to run the content
      filter.

Jonas Fonseca (1):
  Update manpages to reflect new short and long option aliases

Kristian Høgsberg (5):
  Enable wt-status output to a given FILE pointer.
  Enable wt-status to run against non-standard index file.
  Introduce entry point add_interactive and add_files_to_cache
  Export rerere() and launch_editor().
  Port builtin-add.c to use the new option parser.

Nicolas Pitre (16):
  more compact progress display
  cope with multiple line breaks within sideband progress messages
  pack-objects: no delta possible with only one object in the list
  pack-objects.c: fix some global variable abuse and memory leaks
  fix const issues with some functions
  fix for more minor memory leaks
  prune-packed: don't call display_progress() for every file
  make struct progress an opaque type
  relax usage of the progress API
  add throughput to progress display
  add throughput display to index-pack
  add some copyright notice to the progress display code
  add throughput display to git-push
  return the prune-packed progress display to the inner loop
  make sure throughput display gets updated even if progress doesn't
      move
  Show total transferred as part of throughput progress

Pierre Habouzit (17):
  Add a simple option parser.
  parse-options: be able to generate usages automatically
  parse-options: make some arguments optional, add callbacks.
  Add shortcuts for very often used options.
  parse-options: allow callbacks to take no arguments at all.
  Make builtin-rm.c use parse_options.
  Make builtin-mv.c use parse-options
  Make builtin-branch.c use parse_options.
  Make builtin-describe.c use parse_options
  Make builtin-revert.c use parse_options.
  Make builtin-update-ref.c use parse_options
  Make builtin-symbolic-ref.c use parse_options.
  Make builtin-for-each-ref.c use parse-opts.
  Make builtin-fsck.c use parse_options.
  Make builtin-count-objects.c use parse_options.
  Make builtin-name-rev.c use parse_options.
  Make builtin-pack-refs.c use parse_options.

Scott R Parish (7):
  "git" returns 1; "git help" and "git help -a" return 0
  remove unused/unneeded "pattern" argument of list_commands
  "current_exec_path" is a misleading name, use "argv_exec_path"
  list_commands(): simplify code by using chdir()
  use only the $PATH for exec'ing git commands
  include $PATH in generating list of commands for "help -a"
  shell should call the new setup_path() to setup $PATH

Shawn O. Pearce (3):
  Change 'Deltifying objects' to 'Compressing objects'
  Teach prune-packed to use the standard progress meter
  Stop displaying "Pack pack-$ID created." during git-gc

Steffen Prohaska (3):
  mergetool: use path to mergetool in config var
      mergetool.<tool>.path
  mergetool: add support for ECMerge
  mergetool: avoid misleading message "Resetting to default..."

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-10-22  6:11 What's in git/spearce.git (stable) Shawn O. Pearce
@ 2007-11-01  5:39 ` Junio C Hamano
  2007-11-04  3:52   ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-11-01  5:39 UTC (permalink / raw)
  To: git

* The 'maint' branch has just produced the 1.5.3.5 release.

* The 'master' branch has these since the last announcement
  in addition to what's in 1.5.3.5.

  - git-bisect enhancements to support "git bisect skip".
  - git-fetch rewritten in C for performance and portability.
  - git-svnimport is no more --- use git-svn.
  - git-send-pack does not update the tracking ref on the local
    side for failed push (needs cherry-picking to 'maint').
  - git-rebase does not choke when $GIT_DIR has whitespace in it
    (needs cherry-picking to 'maint').
  - optimize rename detection.
  - comes with updated gitk.

  The above list makes me realize that it probably is a good
  time to start freezing things for 1.5.4.  Tonight's "What's
  cooking" will talk about what other topics should graduate to
  'master' before that happens.

Alex Riesen (1):
  Fix a crash in ls-remote when refspec expands into nothing

Alexandre Julliard (4):
  git.el: Fix typo in "Reverted file" message.
  git.el: Fix typo in git-update-saved-file error handling.
  git.el: Refresh only the changed file marks when marking/unmarking
      all.
  git.el: Run git-gc --auto after commits.

Benoit Sigoure (1):
  core-tutorial: Catch up with current Git

Christian Couder (12):
  Test suite: reset TERM to its previous value after testing.
  rev-list: implement --bisect-all
  rev-list documentation: add "--bisect-all".
  Bisect: fix some white spaces and empty lines breakages.
  Bisect: implement "bisect skip" to mark untestable revisions.
  Bisect: refactor "bisect_write_*" functions.
  Bisect: refactor some logging into "bisect_write".
  Bisect: refactor "bisect_{bad,good,skip}" into "bisect_state".
  Bisect: add "bisect skip" to the documentation.
  Bisect: add a "bisect replay" test case.
  Bisect run: "skip" current commit if script exit code is 125.
  Bisect: add "skip" to the short usage string.

Dan McGee (1):
  Remove outdated references to cogito in documentation

Daniel Barkalow (15):
  Refactor http.h USE_CURL_MULTI fill_active_slots().
  Make function to refill http queue a callback
  Remove obsolete commit-walkers
  Modularize commit-walker
  Add uploadpack configuration info to remote.
  Report information on branches from remote.h
  Make fetch-pack a builtin with an internal API
  Push code for transport library
  Add matching and parsing for fetch-side refspec rules
  Add fetch methods to transport library.
  Make fetch a builtin
  Allow abbreviations in the first refspec to be merged
  Restore default verbosity for http fetches.
  Remove duplicate ref matches in fetch
  Correct handling of upload-pack in builtin-fetch-pack

David Symonds (3):
  gitweb: Provide title attributes for abbreviated author names.
  gitweb: Refactor abbreviation-with-title-attribute code.
  gitweb: Use chop_and_escape_str in more places.

Gerrit Pape (1):
  No longer install git-svnimport, move to contrib/examples

Jakub Narebski (1):
  gitweb: Fix and simplify "split patch" detection

Jari Aalto (1):
  On error, do not list all commands, but point to --help option

Jeff King (2):
  send-pack: don't update tracking refs on error
  t5516: test update of local refs on push

Jim Meyering (1):
  hooks-pre-commit: use \t, rather than a literal TAB in regexp

Johannes Schindelin (6):
  Move bundle specific stuff into bundle.[ch]
  Add bundle transport
  Introduce remove_dir_recursively()
  fetch/push: readd rsync support
  Fix compilation when NO_CURL is defined
  fetch: if not fetching from default remote, ignore default merge

Jonathan del Strother (1):
  Fixing path quoting in git-rebase

Junio C Hamano (5):
  bundle transport: fix an alloc_ref() call
  k.org git toppage: Add link to 1.5.3 release notes.
  help: remove extra blank line after "See 'git --help'" message
  git-fetch: do not fail when remote branch disappears
  RelNotes-1.5.4: describe recent updates

Lars Hjemli (1):
  Teach git-pull about --[no-]ff, --no-squash and --commit

Lars Knoll (1):
  Speedup scanning for excluded files.

Linus Torvalds (8):
  Add 'diffcore.h' to LIB_H
  Split out "exact content match" phase of rename detection
  Ref-count the filespecs used by diffcore
  copy vs rename detection: avoid unnecessary O(n*m) loops
  Do linear-time/space rename logic for exact renames
  Do exact rename detection regardless of rename limits
  Fix ugly magic special case in exact rename detection
  Do the fuzzy rename detection limits with the exact renames removed

Miklos Vajna (1):
  git-send-email: add a new sendemail.to configuration variable

Nguyễn Thái Ngọc Duy (1):
  git-sh-setup.sh: use "git rev-parse --show-cdup" to check for
      SUBDIRECTORY_OK

Paul Mackerras (34):
  gitk: Establish and use global left-to-right ordering for commits
  gitk: Improve the drawing of links to parent lines
  gitk: Eliminate diagonal arrows
  gitk: Get rid of idrowranges and rowrangelist
  gitk: Get rid of idinlist array
  gitk: Fix some problems with the display of ids as links
  gitk: Get rid of the rowchk array
  gitk: Do only the parts of the layout that are needed
  gitk: Fix bug causing incorrect ref list contents when switching
      view
  gitk: Fix bug causing undefined variable error when cherry-picking
  gitk: Add a cache for the topology info
  gitk: Make it possible to lay out all the rows we have received so
      far
  gitk: Fix bugs in setting rowfinal
  gitk: Get rid of lookingforhead, use commitinterest instead
  gitk: Fix bug in generating patches
  gitk: Simplify highlighting interface and combine with Find
      function
  gitk: Fix a couple of bugs
  gitk: Add progress bars for reading in stuff and for finding
  gitk: Fix the tab setting in the diff display window
  gitk: Fix bug causing Tcl error when changing find match type
  gitk: Use named fonts instead of the font specification
  gitk: Keep track of font attributes ourselves instead of using font
      actual
  gitk: Add a font chooser
  gitk: Fix bug where the last few commits would sometimes not be
      visible
  gitk: Get rid of the diffopts variable
  gitk: Fix Tcl error: can't unset findcurline
  gitk: Limit diff display to listed paths by default
  gitk: Ensure tabstop setting gets restored by Cancel button
  gitk: Integrate the reset progress bar in the main frame
  gitk: Use the status window for other functions
  gitk: Fix some bugs with path limiting in the diff display
  gitk: Fix a couple more bugs in the path limiting
  gitk: Simplify the code for finding commits
  gitk: Use the UI font for the diff/old version/new version radio
      buttons

Pierre Habouzit (3):
  Add some fancy colors in the test library when terminal supports
      it.
  Support a --quiet option in the test-suite.
  fast-import.c: fix regression due to strbuf conversion

Shawn O. Pearce (37):
  Correct builtin-fetch to handle + in refspecs
  Fix off by one bug in reflog messages written by builtin-fetch
  Remove unnecessary debugging from builtin-fetch
  Remove unused unpacklimit variable from builtin-fetch
  Replace custom memory growth allocator with ALLOC_GROW
  Simplify fetch transport API to just one function
  Refactor index-pack "keep $sha1" handling for reuse
  Remove pack.keep after ref updates in git-fetch
  Always ensure the pack.keep file is removed by git-fetch
  Fix builtin-fetch memory corruption by not overstepping array
  Backup the array passed to fetch_pack so we can free items
  Properly cleanup in http_cleanup so builtin-fetch does not segfault
  Don't bother passing ref log details to walker in builtin-fetch
  Cleanup duplicate initialization code in transport_get
  Add transport.h to LIB_H as transport.o is in LIB_OBJS
  Remove unnecessary 'fetch' argument from transport_get API
  Allow builtin-fetch to work on a detached HEAD
  Don't configure remote "." to fetch everything to itself
  Remove more debugging from builtin-fetch
  builtin-fetch: Don't segfault on "fetch +foo"
  Don't attempt to merge non-existant remotes in t5515
  Correct handling of branch.$name.merge in builtin-fetch
  Avoid printing unnecessary warnings during fetch and push
  Use 'unsigned:1' when we mean boolean options
  Rename remote.uri to remote.url within remote handling internals
  Refactor struct transport_ops inlined into struct transport
  Always obtain fetch-pack arguments from struct fetch_pack_args
  Ensure builtin-fetch honors {fetch,transfer}.unpackLimit
  Fix memory leaks when disconnecting transport instances
  Cleanup style nit of 'x == NULL' in remote.c
  Cleanup unnecessary break in remote.c
  Prevent send-pack from segfaulting when a branch doesn't match
  Fix 'push --all branch...' error handling
  Support 'push --dry-run' for rsync transport
  Support 'push --dry-run' for http transport
  Avoid scary errors about tagged trees/blobs during git-fetch
  Define compat version of mkdtemp for systems lacking it

Väinö Järvelä (1):
  Added a test for fetching remote tags when there is not tags.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-09-26 20:05   ` Junio C Hamano
@ 2007-10-02  5:52     ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-10-02  5:52 UTC (permalink / raw)
  To: git

There are a few usability fixes to 'maint' after 1.5.3.3 but
nothing worth doing 1.5.3.4 for yet.

On the 'master' front, handful topics that have been cooking in
'next' have been merged, to be part of 1.5.4.  Notable are:

 * "git-remote rm"
 * "git-send-email --smtp-server-port"
 * "git-svn" futureproofing.

There are many changes cooking in 'next' that will graduate to
'master' real soon now.  It would probably be a good idea to
slow down and cut 1.5.4 early without aiming to have anything
with huge user visible changes once that happens, because there
are two rather big topics mostly about the implementation and
not about user experience (other than performance gain of fetch
in a repository with insane number of refs).

----------------------------------------------------------------

* The 'maint' branch has these fixes since v1.5.3.3

Andy Parkins (1):
  post-receive-hook: Remove the From field from the generated email
      header so that the pusher's name is used

Jari Aalto (1):
  git-remote: exit with non-zero status after detecting errors.

Jean-Luc Herren (2):
  git-add--interactive: Allow Ctrl-D to exit
  git-add--interactive: Improve behavior on bogus input

Johannes Schindelin (1):
  rebase -i: squash should retain the authorship of the _first_
      commit

Junio C Hamano (1):
  Whip post 1.5.3.3 maintenance series into shape.

Miklos Vajna (1):
  git stash: document apply's --index switch


* The 'master' branch has these since the last announcement
  in addition to the above.

Alexandre Julliard (4):
  git.el: Preserve file marks when doing a full refresh.
  git.el: Do not print a status message on every git command.
  git.el: Update a file status in the git buffer upon save.
  git.el: Reset the permission flags when changing a file state.

Daniel Barkalow (1):
  Fix adding a submodule with a remote url

James Bowes (2):
  remote: add 'rm' subcommand
  remote: document the 'rm' subcommand

Jari Aalto (1):
  git-remote: exit with non-zero status after detecting error in
      "rm".

Jeff King (1):
  diffcore-rename: cache file deltas

Johannes Schindelin (1):
  rebase -i: support single-letter abbreviations for the actions

Junio C Hamano (3):
  git-remote rm: add tests and minor fix-ups
  send-email --smtp-server-port: allow overriding the default port
  Update stale documentation link in the k.org site

Mark Levedahl (1):
  git-submodule - allow a relative path as the subproject url

Sam Vilain (3):
  git-svn: fix test for trunk svn (commit message not needed)
  git-svn: fix test for trunk svn (transaction out of date)
  git-svn: handle changed svn command-line syntax

Stefan Sperling (1):
  Fix pool handling in git-svnimport to avoid memory leaks.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
       [not found] ` <7v3axhd0lr.fsf@gitster.siamese.dyndns.org>
@ 2007-09-26 20:05   ` Junio C Hamano
  2007-10-02  5:52     ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-09-26 20:05 UTC (permalink / raw)
  To: git

Nothing earth-shattering in 'maint', except:

 - if you are on FreeBSD and use its default shell, git scripts
   might work better for you;

 - comes with updated user-manual;

 - send-email would not incorrectly issue duplicated message IDs
   even if you fire many messages within one second;

 - "git rm this-file && git commit this-file" should work
   better;

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Benoit Sigoure (1):
  Add test to check recent fix to "git add -u"

David Brown (1):
  Detect exec bit in more cases.

David Kastrup (1):
  Supplant the "while case ... break ;; esac" idiom

Eric Wong (2):
  Documentation/git-svn: updated design philosophy notes
  git-svn: don't attempt to spawn pager if we don't want one

Gerrit Pape (1):
  git-gui: lib/index.tcl: handle files with % in the filename
      properly

Glenn Rempe (1):
  Fixed minor typo in t/t9001-send-email.sh test command line.

J. Bruce Fields (14):
  user-manual: adjust section levels in "git internals"
  user-manual: move object format details to hacking-git chapter
  user-manual: rename "git internals" to "git concepts"
  user-manual: create new "low-level git operations" chapter
  user-manual: rewrite index discussion
  user-manual: reorder commit, blob, tree discussion
  user-manual: rewrite object database discussion
  user-manual: move packfile and dangling object discussion
  user-manual: fix introduction to packfiles
  user-manual: todo updates and cleanup
  documentation: replace Discussion section by link to user-manual
      chapter
  core-tutorial: minor cleanup
  git-apply: fix whitespace stripping
  user-manual: don't assume refs are stored under .git/refs

Jakub Narebski (2):
  gitweb: Remove parse_from_to_diffinfo code from git_patchset_body
  gitweb: No difftree output for trivial merge

Jari Aalto (1):
  Documentation/git-archive.txt: a couple of clarifications.

Jeff King (1):
  git-push: documentation and tests for pushing only branches

Jim Meyering (2):
  unexpected Make output (e.g. from --debug) causes build failure
  Do not over-quote the -f envelopesender value.

Johannes Schindelin (2):
  revision walker: --cherry-pick is a limited operation
  apply --index-info: fall back to current index for mode changes

Johannes Sixt (2):
  gitattributes.txt: Remove a duplicated paragraph about 'ident' and
      'crlf' interaction.
  gitattributes.txt: Be more to the point in the filter driver
      description.

Junio C Hamano (11):
  diff --no-index: do not forget to run diff_setup_done()
  Documentation/git-config.txt: AsciiDoc tweak to avoid leading dot
  Split grep arguments in a way that does not requires to add
      /dev/null.
  git-sh-setup: typofix in comments
  send-email: make message-id generation a bit more robust
  git-commit: Allow partial commit of file removal.
  git-commit: partial commit of paths only removed from the index
  Document ls-files --with-tree=<tree-ish>
  t/t4014: test "am -3" with mode-only change.
  GIT 1.5.3.2
  Documentation/git-lost-found.txt: drop unnecessarily duplicated
      name.

Linus Torvalds (1):
  Fix the rename detection limit checking

Matt Kraai (2):
  Move the paragraph specifying where the .idx and .pack files should
      be
  Conjugate "search" correctly in the git-prune-packed man page.

Matthias Urlichs (1):
  git-svnimport: Use separate arguments in the pipe for git-rev-parse

Michael Smith (1):
  user-manual: Explain what submodules are good for.

Michele Ballabio (2):
  git-gui: show unstaged symlinks in diff viewer
  git-gui: handle "deleted symlink" diff marker

Miklos Vajna (1):
  User Manual: add a chapter for submodules

Pierre Habouzit (1):
  Fix lapsus in builtin-apply.c

Randy Dunlap (1):
  core-tutorial: correct URL

Shawn Bohrer (1):
  Fix spelling of overridden in documentation

Shawn O. Pearce (13):
  git-gui: Correct starting of git-remote to handle -w option
  git-gui: Fix detaching current branch during checkout
  git-gui: Properly set the state of "Stage/Unstage Hunk" action
  git-gui: Disable Tk send in all git-gui sessions
  git-gui: Avoid use of libdir in Makefile
  git-gui: Assume untracked directories are Git submodules
  git-gui: Trim trailing slashes from untracked submodule names
  git-gui: Don't delete send on Windows as it doesn't exist
  git-gui: Make backporting changes from i18n version easier
  git-gui: Font chooser to handle a large number of font families
  git-gui: Provide 'uninstall' Makefile target to undo an
      installation
  git-gui: Paper bag fix "Commit->Revert" format arguments
  git-gui: Disable native platform text selection in "lists"

Väinö Järvelä (1):
  Fixed update-hook example allow-users format.


* The 'master' branch has these since the last announcement
  in addition to the above.

Carlos Rica (3):
  Add tests for documented features of "git reset".
  Move make_cache_entry() from merge-recursive.c into read-cache.c
  Make "git reset" a builtin.

Christian Couder (4):
  rev-list --bisect: Move finding bisection into do_find_bisection.
  rev-list --bisect: Move some bisection code into best_bisection.
  rev-list --bisect: Bisection "distance" clean up.
  rev-list --bisect: Fix best == NULL case.

David Kastrup (3):
  diff-delta.c: pack the index structure
  diff-delta.c: Rationalize culling of hash buckets
  git-commit.sh: Shell script cleanup

Dmitry Potapov (1):
  preserve executable bits in zip archives

Jeff King (1):
  contrib/fast-import: add perl version of simple example

Johannes Schindelin (7):
  Teach "git remote" a mirror mode
  verify-tag: also grok CR/LFs in the tag signature
  apply: get rid of --index-info in favor of --build-fake-ancestor
  rebase -i: commit when continuing after "edit"
  rebase -i: style fixes and minor cleanups
  rebase -i: Fix numbers in progress report
  rebase -i: avoid exporting GIT_AUTHOR_* variables

Josh England (2):
  Add post-merge hook, related documentation, and tests.
  Added example hook script to save/restore permissions/ownership.

Junio C Hamano (8):
  Keep last used delta base in the delta window
  git-commit: Allow partial commit of file removal.
  An additional test for "git-reset -- path"
  Simplify cache API
  git-commit: partial commit of paths only removed from the index
  Document ls-files --with-tree=<tree-ish>
  builtin-pack-objects.c: avoid bogus gcc warnings
  Start RelNotes for 1.5.4

Lars Hjemli (3):
  git-svn: add support for --first-parent
  git-svn: always use --first-parent
  Make merge-recursive honor diff.renamelimit

Matt Kraai (2):
  Move convert-objects to contrib.
  rebase -i: create .dotest-merge after validating options.

Nguyễn Thái Ngọc Duy (1):
  contrib/fast-import: add simple shell example

Nicolas Pitre (10):
  straighten the list of objects to deltify
  localize window memory usage accounting
  rearrange delta search progress reporting
  basic threaded delta search
  threaded delta search: refine work allocation
  threaded delta search: better chunck split point
  threaded delta search: specify number of threads at run time
  fix threaded delta search locking
  threaded delta search: add pack.threads config variable
  threaded delta search: proper locking for cache accounting

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-09-06  8:52 Junio C Hamano
       [not found] ` <7v3axhd0lr.fsf@gitster.siamese.dyndns.org>
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-09-06  8:52 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since v1.5.3.1

Dmitry V. Levin (1):
  Makefile: Add cache-tree.h to the headers list

Junio C Hamano (1):
  git-apply: do not read past the end of buffer

Shawn O. Pearce (3):
  Don't allow contrib/workdir/git-new-workdir to trash existing dirs
  Cleanup unnecessary file modifications in t1400-update-ref
  Include a git-push example for creating a remote branch


* The 'master' branch has these since v1.5.3 in addition to the
  above.

Carlos Rica (1):
  Function for updating refs.

Douglas Stockwell (1):
  send-email: Add support for SSL and SMTP-AUTH

Junio C Hamano (1):
  Start 1.5.4 cycle

Simon Hausmann (8):
  git-p4: Always call 'p4 sync ...' before submitting to Perforce.
  git-p4: After submission to p4 always synchronize from p4 again
      (into refs/remotes). Whether to rebase HEAD or not is still
      left as question to the end-user.
  git-p4: Cleanup; moved the code for getting a sorted list of p4
      changes for a list of given depot paths into a standalone
      method.
  git-p4: Cleanup; moved the code to import a list of p4 changes
      using fast-import into a separate member function of P4Sync.
  git-p4: Cleanup; Turn self.revision into a function local variable
      (it's not used anywhere outside the function).
  git-p4: Cleanup; moved the code for the initial #head or revision
      import into a separate function, out of P4Sync.run.
  git-p4: Cleanup; moved the (duplicated) code for turning a branch
      into a git ref (for example foo ->
      refs/remotes/p4/<project>/foo) into a separate method.
  git-p4: Added support for automatically importing newly appearing
      perforce branches.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-08-23  0:37 Junio C Hamano
@ 2007-08-24  0:28 ` Jakub Narebski
  0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2007-08-24  0:28 UTC (permalink / raw)
  To: git

Junio C Hamano wrote:

> Hopefully we can do the final without another -rc sometime early
> next week.

By the way, there is no info in RelNotes about performance fix of the O(n^2)
wrt number of files behavior.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-08-23  0:37 Junio C Hamano
  2007-08-24  0:28 ` Jakub Narebski
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-08-23  0:37 UTC (permalink / raw)
  To: git

Many documentation updates, fast-import fixes and enhancements,
updated gitk.

Hopefully we can do the final without another -rc sometime early
next week.

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (3):
  Fix whitespace in "Format of STDIN stream" of fast-import
  Avoid using va_copy in fast-import: it seems to be unportable.
  Fix git-remote for ActiveState Perl

Alexandre Julliard (1):
  git.el: Avoid a lisp error when there's no current branch (detached
      HEAD).

Arjen Laarhoven (2):
  gitk: Make the date/time display configurable
  t1301-shared-repo.sh: fix 'stat' portability issue

Brian Downing (1):
  Clarify actual behavior of 'git add' and ignored files

Brian Gernhardt (1):
  Minor clarifications to git-filter-branch usage and doc

Dave Watson (1):
  Fix misspelling of 'suppress' in docs

Eric Wong (1):
  git-svn: update documentation with CAVEATS section

Johannes Sixt (1):
  gitk: Handle 'copy from' and 'copy to' in diff headers.

Junio C Hamano (5):
  Documentation/git-rebase: fix an example
  Clean-up read-tree error condition.
  fast-import pull request
  git clone: do not issue warning while cloning locally across
      filesystems
  GIT 1.5.3-rc6

Lars Hjemli (1):
  git-submodule: re-enable 'status' as the default subcommand

Linus Torvalds (2):
  Make thin-pack generation subproject aware.
  Take binary diffs into account for "git rebase"

Lukas Sandström (1):
  Add the word reflog to
      Documentation/config.txt:core.logAllRefUpdates

Mark Levedahl (1):
  git-completion.bash - add support for git-bundle

Matthieu Moy (1):
  Add and document a global --no-pager option for git.

Mike Hommey (1):
  Clarify commit-tree documentation

Paul Mackerras (3):
  gitk: Fix warning when removing a branch
  gitk: Fix bug in fix for warning when removing a branch
  gitk: Add a window to list branches, tags and other references

Quy Tonthat (1):
  Fix breakage in git-rev-list.txt

René Scharfe (1):
  Documentation: update tar.umask default

Sean Estabrooks (2):
  Fix small typo in git send-email man page.
  Reset terminal attributes when terminating git send-email

Shawn O. Pearce (13):
  git-gui: Avoid Tcl error in popup menu on diff viewer
  Actually allow TAG_FIXUP branches in fast-import
  Use handy ALLOC_GROW macro in fast-import when possible
  Teach fast-import to ignore lines starting with '#'
  Make trailing LF following fast-import `data` commands optional
  Make trailing LF optional for all fast-import commands
  Allow frontends to bidirectionally communicate with fast-import
  Generate crash reports on die in fast-import
  Include recent command history in fast-import crash reports
  Correct documentation of 'reflog show' to explain it shows HEAD
  Don't allow combination of -g and --reverse as it doesn't work
  Fix new-workdir (again) to work on bare repositories
  Suggest unsetting core.bare when using new-workdir on a bare
      repository

Stefan Sperling (1):
  Document -u option in git-svnimport man page

Steffen Prohaska (1):
  gitk: Let user easily specify lines of context in diff view

Steven Grimm (1):
  Document what the stage numbers in the :$n:path syntax mean.

Väinö Järvelä (1):
  git-gui: Added support for OS X right click

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-08-11  8:41 Junio C Hamano
  2007-08-11  9:32 ` David Kastrup
@ 2007-08-16  5:02 ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-08-16  5:02 UTC (permalink / raw)
  To: git

Maintenance release 1.5.2.5 is out, so that a fix for "add -u"
breakage can be propagated out to a released version without
waiting for the 1.5.3 final.

The 'master' branch has a few more fixes since -rc5.  Notable
are:

 - fix "add -u" (in 'maint');
 - fix "read-tree -m base1 base2 ours theirs";
 - fix "clone --bare";
 - teach "git apply" to handle submodule patches;

I would like to ask subsystem people to give a pull request
destined for the 1.5.3 final by the end of the week, so that we
can do -rc6 and make it the last rc in this cycle.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Junio C Hamano (2):
  Fix "git add -u" data corruption.
  GIT 1.5.2.5

Salikh Zakirov (1):
  git-add -u paths... now works from subdirectory


* The 'master' branch has these since the last announcement
  in addition to the above.

Alberto Bertogli (1):
  Allow git-svnimport to take "" as the trunk directory.

Alex Riesen (2):
  gitk: Continue and show error message in new repos
  gitk: Show an error and exit if no .git could be found

Alexandre Julliard (3):
  git.el: Add support for interactive diffs.
  git.el: Always set the current directory in the git-diff buffer.
  git-add: Add support for --refresh option.

Brian Downing (1):
  Add read_cache to builtin-check-attr

Brian Gernhardt (1):
  Fix t5701-clone-local for white space from wc

David Kastrup (2):
  git-sh-setup.sh: make GIT_DIR absolute
  Add a test for git-commit being confused by relative GIT_DIR

Eric Wong (1):
  git-svn: fix log with single revision against a non-HEAD branch

Junio C Hamano (10):
  t3404: fix "fake-editor"
  builtin-bundle create - use lock_file
  git-diff: squelch "empty" diffs
  merge-recursive: do not rudely die on binary merge
  attr.c: refactoring
  attr.c: read .gitattributes from index as well.
  GIT 1.5.3-rc5
  Fix read-tree merging more than 3 trees using 3-way merge
  Update documentation links for older releases.
  git-clone: allow --bare clone

Luiz Fernando N. Capitulino (3):
  Avoid ambiguous error message if pack.idx header is wrong
  Introduces xmkstemp()
  Use xmkstemp() instead of mkstemp()

Marco Costalba (1):
  Add --log-size to git log to print message size

Mark Levedahl (3):
  gitk: Enable selected patch text on Windows
  gitk: Handle MouseWheel events on Windows
  t3902 - skip test if file system doesn't support HT in names

Nicolas Pitre (1):
  pack-objects: remove bogus arguments to delta_cacheable()

Paul Mackerras (4):
  gitk: Add a context menu for file list entries
  gitk: Fix bug causing the "can't unset idinlist(...)" error
  gitk: Fix bug introduced in commit 67a4f1a7
  gitk: Fix bug causing Tcl error when updating graph

Reece H. Dunn (1):
  git-p4: Fix the sorting of changelists when cloning a Perforce
      repository.

René Scharfe (3):
  diff: don't run pager if user asked for a diff style exit code
  diff: squelch empty diffs even more
  path-list.c: always free strdup'ed paths

Steffen Prohaska (1):
  Improved hint on how to set identity

Sven Verdoolaege (1):
  git-apply: apply submodule changes

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-08-11  8:41 Junio C Hamano
@ 2007-08-11  9:32 ` David Kastrup
  2007-08-16  5:02 ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: David Kastrup @ 2007-08-11  9:32 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <gitster@pobox.com> writes:

> I thought we were pretty in good shape and in a nice and quiet
> freeze period.
>
> Until a few days ago.
>
> Then suddenly, flurry of activity happened.  A few performance
> issues were raised and fixed:

The fix to git-filter-branch I posted is tested and obviously
necessary (without it, git-filter-branch will only work if GIT_DIR is
set previously to calling it).

Also documentation and usage of git-filter-branch are out of kilter,
the given examples for wiping a file from history don't work,
specifing the refs to work on reacts impredictably (it is not clear
what gets accepted and what not, and one seemingly has to always
specify "HEAD" which is basically ignored).

Could you ask Dscho to consider adding cases based on the
documentation to the test suite?  That should help weed out the worst
discrepances.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-08-11  8:41 Junio C Hamano
  2007-08-11  9:32 ` David Kastrup
  2007-08-16  5:02 ` Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-08-11  8:41 UTC (permalink / raw)
  To: git

I thought we were pretty in good shape and in a nice and quiet
freeze period.

Until a few days ago.

Then suddenly, flurry of activity happened.  A few performance
issues were raised and fixed:

 * "git-status" on a huge tree was way suboptimal and found to
   have unnecessary O(n^2) codepath.  Fixing this also sped up
   "git-diff --cached";
 * "git-commit paths..." had a few other bottlenecks.  "git-add
   --stdin" was one of them;
 * In addition, Linus optimized all three cases of "git
   read-tree" that had the same inefficiency;
 * "git-bundle create" had a stupid "one-byte-at-a-time" loop
   that was unnecessary.

Also one of the new features in 1.5.3, GIT_WORK_TREE, was found
to be not-quite-ready.  I think the few commits during the last
couple of days should finally make it ready.

I have resisted merging any new features that were not present
in 1.5.3-rc1, but it appears that we would need to have a few
more -rc rounds before the final _anyway_, so I went into a
merge-binge. A couple of well done topics from the next branch
are now in master:

    * Carlos's "builtin tag" series;
    * David's "format documentation in info format as well" series;

Expect the tip of 'master' to be tagged v1.5.3-rc5 and let's
hope it to be the last -rc before 1.5.3 final.

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (1):
  Fix filehandle leak in "git branch -D"

Brian Downing (1):
  cvsserver: Fix for work trees

Carlos Rica (3):
  Make git tag a builtin.
  builtin-tag.c: Fix two memory leaks and minor notation changes.
  Make verify-tag a builtin.

David Kastrup (4):
  Documentation/git-commit.txt: correct bad list formatting.
  Add support for an info version of the user manual
  INSTALL: explain info installation and dependencies.
  Documentation/Makefile: remove cmd-list.made before redirecting to
      it.

Johannes Schindelin (3):
  launch_editor(): Heed GIT_EDITOR and core.editor settings
  Teach "git stripspace" the --strip-comments option
  Reinstate the old behaviour when GIT_DIR is set and GIT_WORK_TREE
      is unset

Junio C Hamano (9):
  git-clone: aggressively optimize local clone behaviour.
  Reorder the list of commands in the manual.
  Fix formatting of git-blame documentation.
  Fix an illustration in git-rev-parse.txt
  tweak manpage formatting
  Revert "tweak manpage formatting"
  Optimize "diff --cached" performance.
  allow git-bundle to create bottomless bundle
  allow git-bundle to create bottomless bundle

Linus Torvalds (7):
  connect: accept file:// URL scheme
  Start moving unpack-trees to "struct tree_desc"
  Fix "git commit directory/" performance anomaly
  Move old index entry removal from "unpack_trees()" into the
      individual functions
  Optimize the common cases of git-read-tree
  Optimize the two-way merge of git-read-tree too
  Optimize the three-way merge of git-read-tree

Mark Levedahl (2):
  builtin-bundle.c - use stream buffered input for rev-list
  builtin-bundle - use buffered reads for bundle header

Shawn O. Pearce (3):
  Teach update-paranoid how to store ACLs organized by groups
  Teach the update-paranoid to look at file differences
  Use the empty tree for base diff in paranoid-update on new branches

Simon Hausmann (2):
  git-p4: Fix support for symlinks.
  git-p4: Fix git-p4 submit to include only changed files in the
      perforce submit template.

Steve Hoelzer (2):
  git-stash documentation: stash numbering starts at zero, not one
  git-stash documentation: add missing backtick

Steven Grimm (1):
  Add a note about the index being updated by git-status in some
      cases

Uwe Kleine-König (2):
  send-email: rfc822 forbids using <address@domain> without a
      non-empty "phrase"
  send-email: get all the quoting of realnames right

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-07-28  8:47                       ` What's in git.git (stable) Junio C Hamano
  2007-07-28  8:56                         ` David Kastrup
  2007-07-28 12:28                         ` Thomas Glanzmann
@ 2007-08-07  6:22                         ` Junio C Hamano
  2 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-08-07  6:22 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since the last
  announcement, which are all included in 'master' as well.
  Because 1.5.3 is just around the corner, I think it is
  pointless to do 1.5.2.5 from here, though.

Christian Couder (1):
  rev-list --bisect: fix allocation of "int*" instead of "int".

Junio C Hamano (1):
  setup.c:verify_non_filename(): don't die unnecessarily while
      disambiguating

Linus Torvalds (1):
  apply: remove directory that becomes empty by renaming the last
      file away

* The 'master' branch has these since 1.5.3-rc4.

Adam Roben (1):
  Documentation/git-svn: how to clone a git-svn-created repository

Gerrit Pape (1):
  git-am: initialize variable $resume on startup

J. Bruce Fields (4):
  user-manual: update for new default --track behavior
  user-manual: mention git-gui
  documentation: use the word "index" in the git-add manual page
  documentation: use the word "index" in the git-commit man page

Jakub Narebski (1):
  gitweb: Fix handling of $file_name in feed generation

Johannes Schindelin (1):
  checkout-index needs a working tree

Junio C Hamano (8):
  git-completion: add "git stash"
  INSTALL: add warning on docbook-xsl 1.72 and 1.73
  unpack-trees.c: assume submodules are clean during check-out
  Fix install-doc-quick target
  user-manual: mention git stash
  setup.c:verify_non_filename(): don't die unnecessarily while
      disambiguating
  pager: find out pager setting from configuration
  Fix "make GZ=1 quick-install-doc"

Jyotirmoy Bhattacharya (1):
  Fixed git-push manpage

Linus Torvalds (1):
  apply: remove directory that becomes empty by renaming the last
      file away

Randal L. Schwartz (1):
  add "test-absolute-path" to .gitignore

Shawn O. Pearce (1):
  Document GIT_SSH environment variable alongside other variables

Uwe Kleine-König (1):
  send-email: teach sanitize_address to do rfc2047 quoting

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-07-29  9:05                               ` David Kastrup
@ 2007-07-29 16:40                                 ` Theodore Tso
  0 siblings, 0 replies; 601+ messages in thread
From: Theodore Tso @ 2007-07-29 16:40 UTC (permalink / raw)
  To: David Kastrup; +Cc: git

On Sun, Jul 29, 2007 at 11:05:42AM +0200, David Kastrup wrote:
> Theodore Tso <tytso@mit.edu> writes:
> 
> > So I really am beginning to think the right answer is to give up on
> > using git-mergetool to support anything other than basic emacs users
> > (who just use emacs as an editor, what a concept),
> 
> In contrast, you are trying to support only people by using Emacs
> _not_ as an editor, but as a mergetool under the control of git.
> That's a mistake.

The whole *point* of git-mergetool is to automatically call merge
tools so you can do three-way merges under the control of git.  

If you just want an *editor* then you can just edit the files that are
listed as being in conflict after a failed merge or after running "git
status".  You can do that today without using git-mergetool at all!

> Sorry, but you are way off here.  The normal, standard use of Emacs is
> to start it once and do everything in it.  Its startup time is such
> that other uses are not feasible.

Huh?  The startup time of running emacs for me is well under a second
(and I have a 20k ~/.emacs.el file that loads a number of other
files).  I'm sure if you put enough *crap* into your .emacs.el file,
you can make it take a huge amount of time, but I suspect your idea of
what is "normal" for emacs is more than a little skewed.

> So git's mergetool philosophy is currently _straight_ set against the
> way Emacs is designed to work.

So don't use git-mergetool.  Like I said, I suspect the right answer
is contrib/git-mergetool.el, and do everything inside emacs.  If you
are as extreme as someone who pulls in gazillions of emacs packages,
and you are using emacs as a desktop, a shell, and a window manager,
then you can probably do much better using a pure emacs lisp merge
system.

Git mergetool is fundamentally designed to work with tools like meld,
kdiff3, xxdiff, tkdiff, etc.  These are all merge tools, and they work
a certain way.  They expect, and need, to be driven a certain way.  If
you insist on following a fundamentally different paradigm, then past
a certain point git-mergetool is not going to make you happy no matter
what I can do.  The point is, git-mergetool does *need* to do know
when you are done doing a merge, and it needs to know if you've
decided to abandon a merge.  Right now ediff doesn't fit well into
that paradigm.  And that's fundamentally ediff's fault; we can do some
kludgery on the git-mergetool side, but the end result will always be
unsatisfactory, and will require that the person using it to *know*
that it is done.

I, personally, don't feel like trying to twist git-mergetool into
doing the right thing depending on whether you have emacs21, emacs22,
emacs23-snapshot, whether or not the desktop package is in use,
whether or not the user is using emacsclient or not, yadda, yadda,
yaddda.  If you want to take a crack at doing *all* of that mess, and
provide a complete solution, send me patches and I'll look at them.

I think it will add a huge amount of *crap* into git-mergetool in
order to support all possible use cases (I'm not interesting in
putting in hackery just for your favorite use case, if it causes other
users to scratch their heads in befuddlement and confusion), but feel
free to prove me wrong.  

As someone who has used emacs for over two decades, and have written
very sophisticated emacs lisp code during nearly all of those 21 years
(1986--2007; my first use of emacs was on a Vax 750 running BSD 4.3
--- if you want to talk about emacs taking a long time to start up, I
remember what it was like 20 years ago), I'm pretty well aware of what
you can and can not do in emacs, and I think I can say with fairly
good authority that for the amount of effort it would take to try to
get git-mergetool to hack around all of these different cases, writing
git-mergetool.el will probably be easier, and result in a cleaner,
better integration with people who like to live their entire lives in
a single emacs session.

					- Ted

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-07-29  3:16                             ` Theodore Tso
  2007-07-29  9:05                               ` David Kastrup
@ 2007-07-29 11:27                               ` Johannes Schindelin
  1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2007-07-29 11:27 UTC (permalink / raw)
  To: Theodore Tso; +Cc: git

Hi,

On Sat, 28 Jul 2007, Theodore Tso wrote:

> So I really am beginning to think the right answer is to give up on 
> using git-mergetool to support anything other than basic emacs users 
> (who just use emacs as an editor, what a concept), and for the H4rd C0re 
> emacs l33t, they can use a contrib/git-mergetool.el that does everything 
> inside emacs.  Since these are the people who want emacs to be their 
> desktop, their shell, *and* their window manager, they will probably be 
> happier that way....

Well, maybe not happier.  But at least they will be forced to write a 
patch (if they really want to use git _their_ way, and they'll have to 
defend their patch if they break all other people's work flow), instead of 
writing a lot of long and useless emails.

IOW I do not think "we" have to do something about it.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-07-29  3:16                             ` Theodore Tso
@ 2007-07-29  9:05                               ` David Kastrup
  2007-07-29 16:40                                 ` Theodore Tso
  2007-07-29 11:27                               ` Johannes Schindelin
  1 sibling, 1 reply; 601+ messages in thread
From: David Kastrup @ 2007-07-29  9:05 UTC (permalink / raw)
  To: Theodore Tso; +Cc: git

Theodore Tso <tytso@mit.edu> writes:

> So I really am beginning to think the right answer is to give up on
> using git-mergetool to support anything other than basic emacs users
> (who just use emacs as an editor, what a concept),

In contrast, you are trying to support only people by using Emacs
_not_ as an editor, but as a mergetool under the control of git.
That's a mistake.

> and for the H4rd C0re emacs l33t, they can use a
> contrib/git-mergetool.el that does everything inside emacs.  Since
> these are the people who want emacs to be their desktop, their
> shell, *and* their window manager, they will probably be happier
> that way....

Sorry, but you are way off here.  The normal, standard use of Emacs is
to start it once and do everything in it.  Its startup time is such
that other uses are not feasible.

(info "(emacs) Entering Emacs")

       Many editors are designed to edit one file.  When done with
    that file, you exit the editor.  The next time you want to edit a
    file, you must start the editor again.  Working this way, it is
    convenient to use a command-line argument to say which file to
    edit.

       However, killing Emacs after editing one each and starting it
    afresh for the next file is both unnecessary and harmful, since it
    denies you the full power of Emacs.  Emacs can visit more than one
    file in a single editing session, and that is the right way to use
    it.  Exiting the Emacs session loses valuable accumulated context,
    such as the kill ring, registers, undo history, and mark ring.
    These features are useful for operating on multiple files, or even
    continuing to edit one file.  If you kill Emacs after each file,
    you don't take advantage of them.

       The recommended way to use GNU Emacs is to start it only once,
    just after you log in, and do all your editing in the same Emacs
    session.  Each time you edit a file, you visit it with the
    existing Emacs, which eventually has many files in it ready for
    editing.  Usually you do not kill Emacs until you are about to log
    out.  *Note Files::, for more information on visiting more than
    one file.

       To edit a file from another program while Emacs is running, you
    can use the `emacsclient' helper program to open a file in the
    already running Emacs.  *Note Emacs Server::.


So git's mergetool philosophy is currently _straight_ set against the
way Emacs is designed to work.

One solution would be to call emacs -q in order to weed out users with
the impunity of customizing Emacs to suit their needs rather than
those of git.

But the sanest is really to call Emacs just the way the user
configured $EDITOR to call it and pass it an initial merge command.
And then decide from the results on the disk what to further do.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-07-28  9:35                           ` David Kastrup
@ 2007-07-29  3:16                             ` Theodore Tso
  2007-07-29  9:05                               ` David Kastrup
  2007-07-29 11:27                               ` Johannes Schindelin
  0 siblings, 2 replies; 601+ messages in thread
From: Theodore Tso @ 2007-07-29  3:16 UTC (permalink / raw)
  To: David Kastrup; +Cc: git

On Sat, Jul 28, 2007 at 11:35:40AM +0200, David Kastrup wrote:
> David Kastrup <dak@gnu.org> writes:
> 
> > If you use the desktop package, this means that you get a bear of a
> > startup time while a _new_ instance of Emacs gets loaded against the
> > wishes of the setup, and the command line parameters will be
> > interpreted relatively to the last file restored into the desktop
> > rather than the current directory (arguably a bug in the desktop
> > package which I plan to fix eventually, but in the meantime the
> > current package is farspread).
> 
> I can't reproduce anything similar outside of mergetool, so it appears
> more likely that mergetool is passing wrong relative file names.

See my recent posting on this issue.  The problem is that the desktop
package fundamentally changes how emacs behaves when it starts up.
And in order to fix it we will need to change git-mergetool to do an
"emacs --version", parse the version number, and then start changing
how it calls emacs (and if you *really* want to use emacsclient,
whether it can use emacsclient) based on the version of emacs which is
installed as the default for the user.  It's going to be really messy,
and fundamentally, emacs as used by people who are using the desktop
package really wants to be the center of the universe, instead of
something which gets called to run a "merge application".  Testing to
make sure this works on every single emacs version/variant, and every
single user's weird-sh*t startup scripts isn't something I'm looking
forward to.

So I really am beginning to think the right answer is to give up on
using git-mergetool to support anything other than basic emacs users
(who just use emacs as an editor, what a concept), and for the H4rd
C0re emacs l33t, they can use a contrib/git-mergetool.el that does
everything inside emacs.  Since these are the people who want emacs to
be their desktop, their shell, *and* their window manager, they will
probably be happier that way....

						- Ted

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-07-28  8:47                       ` What's in git.git (stable) Junio C Hamano
  2007-07-28  8:56                         ` David Kastrup
@ 2007-07-28 12:28                         ` Thomas Glanzmann
  2007-08-07  6:22                         ` Junio C Hamano
  2 siblings, 0 replies; 601+ messages in thread
From: Thomas Glanzmann @ 2007-07-28 12:28 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: GIT

Hello Junio,
git HEAD compiles under 'Solaris 8/Forte 11' and 'Solaris 10/Forte 12'
for me.

	Thomas

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-07-28  8:56                         ` David Kastrup
  2007-07-28  9:02                           ` Junio C Hamano
@ 2007-07-28  9:35                           ` David Kastrup
  2007-07-29  3:16                             ` Theodore Tso
  1 sibling, 1 reply; 601+ messages in thread
From: David Kastrup @ 2007-07-28  9:35 UTC (permalink / raw)
  To: git

David Kastrup <dak@gnu.org> writes:

[...]

> If you use the desktop package, this means that you get a bear of a
> startup time while a _new_ instance of Emacs gets loaded against the
> wishes of the setup, and the command line parameters will be
> interpreted relatively to the last file restored into the desktop
> rather than the current directory (arguably a bug in the desktop
> package which I plan to fix eventually, but in the meantime the
> current package is farspread).

I can't reproduce anything similar outside of mergetool, so it appears
more likely that mergetool is passing wrong relative file names.

Have to leave now for the day.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-07-28  8:56                         ` David Kastrup
@ 2007-07-28  9:02                           ` Junio C Hamano
  2007-07-28  9:35                           ` David Kastrup
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-07-28  9:02 UTC (permalink / raw)
  To: David Kastrup; +Cc: git, Theodore Ts'o

David Kastrup <dak@gnu.org> writes:

> I'd like to see some changes for mergetool's Emacs support: in
> moderately current versions of Emacs and XEmacs, ediff is a much
> preferable tool to emerge.

Between ediff and emerge, I think Ted gave a well thought out
analysis on the list earlier, so you might want to consider the
issues he raised if/when you tackle this.

This is late in the game, however, so your change probably won't
be merged before I can tag 1.5.3 final, but I'd expect that a
better Emacs support will be widely welcomed.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-07-28  8:47                       ` What's in git.git (stable) Junio C Hamano
@ 2007-07-28  8:56                         ` David Kastrup
  2007-07-28  9:02                           ` Junio C Hamano
  2007-07-28  9:35                           ` David Kastrup
  2007-07-28 12:28                         ` Thomas Glanzmann
  2007-08-07  6:22                         ` Junio C Hamano
  2 siblings, 2 replies; 601+ messages in thread
From: David Kastrup @ 2007-07-28  8:56 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <gitster@pobox.com> writes:

> It's been a while since I sent this the last time.
>
> We are nearing 1.5.3 final; I pulled gitk updates tonight, and
> expect git-gui updates to 0.8.0 over the weekend.  There are a
> handful trivial fixes since 1.5.3-rc3.

I'd like to see some changes for mergetool's Emacs support: in
moderately current versions of Emacs and XEmacs, ediff is a much
preferable tool to emerge.

Also, the mergetool determines when to use emerge for merging by
looking at the EDITOR/VISUAL variables.  While it recognizes the
presence of "emacsclient" and "gnuclient" there for offering the
emerge tool, it does not actually use those settings for calling
Emacs/XEmacs.  If you use the desktop package, this means that you get
a bear of a startup time while a _new_ instance of Emacs gets loaded
against the wishes of the setup, and the command line parameters will
be interpreted relatively to the last file restored into the desktop
rather than the current directory (arguably a bug in the desktop
package which I plan to fix eventually, but in the meantime the
current package is farspread).

I'll try to come up with a fix this weekend if nobody beats me to it.
As it stands, the mergetool is somewhere between subpar and unusable
by default for a considerable number of Emacs users.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-07-13  6:06                     ` What's in git.git Junio C Hamano
@ 2007-07-28  8:47                       ` Junio C Hamano
  2007-07-28  8:56                         ` David Kastrup
                                           ` (2 more replies)
  0 siblings, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-07-28  8:47 UTC (permalink / raw)
  To: git

It's been a while since I sent this the last time.

We are nearing 1.5.3 final; I pulled gitk updates tonight, and
expect git-gui updates to 0.8.0 over the weekend.  There are a
handful trivial fixes since 1.5.3-rc3.

I am hoping one topic (bs/lock) to graduate from 'next' and
another from nowhere (js/worktree) before 1.5.3-rc4, probably by
mid next-week.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Julian Phillips (1):
  Force listingblocks to be monospaced in manpages

Junio C Hamano (1):
  Do not expect unlink(2) to fail on a directory.


* The 'master' branch has these since the last announcement
  in addition to the above.

Adam Roben (1):
  Add GIT_EDITOR environment and core.editor configuration variables

Alex Riesen (1):
  Fix git-rebase -i to allow squashing of fast-forwardable commits

Alexandre Julliard (2):
  git.el: Support for incremental status updates.
  git.el: Pass an explicit argument to enable smerge-mode.

Brian Gernhardt (1):
  Document commit.template configuration variable.

Carlos Rica (1):
  Rename read_pipe() with read_fd() and make its buffer
      nul-terminated.

David Kastrup (2):
  contrib/emacs/Makefile: Also install .el files.
  Documentation/gitignore.txt: Fix the seriously misleading priority
      explanation

Emil Medve (1):
  Use $(RM) in Makefiles instead of 'rm -f'

Eric Wong (2):
  git-svn: remove leading slashes from fetch lines in the generate
      config
  git-svn: fix commiting renames over DAV with funky file names

Francis Moreau (1):
  Fix git-branch documentation when using remote refs

Greg KH (1):
  make git-send-email.perl handle email addresses with no names when
      Email::Valid is present

Jakub Narebski (3):
  gitweb cleanup: Move @diff_opts declaration earlier
  gitweb: Fix support for legacy gitweb config for snapshots
  gitweb: More detailed error messages for snapshot format

Jim Meyering (2):
  git-cvsserver: detect/diagnose write failure, etc.
  pretty-options.txt: tiny doc fix

Johannes Schindelin (13):
  filter-branch: get rid of "set -e"
  rebase -i: call editor just once for a multi-squash
  fsck --lost-found: write blob's contents, not their SHA-1
  mailinfo: fix 'fatal: cannot convert from utf-8 to utf-8'
  Shut "git rebase -i" up when no --verbose was given
  rebase -i: exchange all "if [ .. ]" by "if test .."
  filter-branch: Big syntax change; support rewriting multiple refs
  Teach revision machinery about --no-walk
  git log -g: Complain, but do not fail, when no reflogs are there
  Teach approxidate() to understand "never"
  git am: skip pine's internal folder data
  rebase -i: fix overzealous output redirection
  rebase -i: fix interrupted squashing

Josh Triplett (1):
  Remove useless uses of cat, and replace with filename arguments

Junio C Hamano (24):
  Make show_rfc2822_date() just another date output format.
  Wire new date formats to --date=<format> parser.
  Document new --date=<format>
  Add contrib/stats/mailmap.pl script
  Update .mailmap
  Documentation/git-commit-tree: remove description of a nonexistent
      limitation
  GIT v1.5.3-rc2
  Update INSTALL
  Fix VISUAL/EDITOR preference order in Documentation/config.txt.
  Synonyms: -i == --regexp-ignore-case, -E == --extended-regexp
  Mark user-manual as UTF-8
  user-manual: fix typolets.
  t9200: Be careful when checking CVS/Entries
  GIT 1.5.3-rc3
  Make sure git-stash works from subdirectory.
  gitweb: fix broken snapshot
  git-submodule module_name: avoid using unwieldy "value_regexp"
      feature.
  git-submodule: remove redundant call to git-describe
  When locking in a symlinked repository, try to lock the original.
  git_mkstemp(): be careful not to overflow the path buffer.
  Update description of -z option.
  git-stash: do not remove a ref by hand.
  Fix git-stash apply --index
  git-stash apply --index: optimize postprocessing

Kumar Gala (1):
  send-email: Update regex parsing for pine aliases

Linus Torvalds (2):
  Do a better job at guessing unknown character sets
  Fix up duplicate parents removal

Marco Costalba (1):
  Avoid to duplicate commit message when is not encoded

Marius Storm-Olsen (1):
  Fix git-p4 on Windows to not use the Posix sysconf function.

Mark Levedahl (1):
  gitk: Ignore ctrl-z as EOF on windows

Matt McCutchen (1):
  gitweb: snapshot cleanups & support for offering multiple formats

Matthieu Moy (1):
  More permissive "git-rm --cached" behavior without -f.

Nanako Shiraishi (2):
  Document "git stash message..."
  git-stash: Make sure reflog is created for refs/stash

Nguyễn Thái Ngọc Duy (1):
  git-write-tree should not crash if prefix does not exist

Paul Mackerras (5):
  gitk: Fix bug introduced by previous commit
  gitk: Show changes in index and changes in working directory
      separately
  gitk: Make the fake commit for the index changes green rather than
      magenta
  gitk: Wait for the window to become visible after creating it
  gitk: Fix bugs in the Find function

Peter Hagervall (1):
  Make every builtin-*.c file #include "builtin.h"

René Scharfe (2):
  filter-branch: fix dash complaining about "Missing '))'"
  cleanup unpack-trees.c: shrink struct tree_entry_list

Richard MUSIL (1):
  git-svn: Minimalistic patch which allows svn usernames with
      space(s).

Robin Rosenberg (3):
  Support output ISO 8601 format dates
  cvsexportcommit: avoid racy CVS problem.
  Document --unified/-U option

Scott Lamb (2):
  git-p4: use subprocess in p4CmdList
  git-p4: input to "p4 files" by stdin instead of arguments

Sean Estabrooks (3):
  Remove "WITH_P4IMPORT" knob from the Makefile
  Remove p4 rpm from git.spec.in.
  Demote git-p4import to contrib status.

Shawn O. Pearce (3):
  Correct trivial typo in fast-import documentation
  Teach fast-import to recursively copy files/directories
  gitk: Bind keyboard actions to the command key on Mac OS

Simon Hausmann (4):
  git-p4: Cleanup, make listExistingP4Branches a global function for
      later use.
  git-p4: Fix upstream branch detection for submit/rebase with
      multiple branches.
  git-p4: Cleanup, used common function for listing imported p4
      branches
  git-p4: Fix p4 user cache population on Windows.

Stephen Rothwell (1):
  send-email: discard blank around address in extract_valid_address
      as well.

Steven Grimm (2):
  Document how to tell git to not launch a pager
  Teach git-commit about commit message templates.

Sven Verdoolaege (2):
  lockfile.c: schedule remove_lock_file only once.
  unpack-trees.c: assume submodules are clean during check-out

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-06-25  9:43                 ` Junio C Hamano
@ 2007-07-02  0:16                   ` Junio C Hamano
  2007-07-13  6:06                     ` What's in git.git Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-07-02  0:16 UTC (permalink / raw)
  To: git

Will do a 1.5.2.3 with the tip of 'maint' probably mid-week and
a 1.5.3-rc1 at about the same time from 'master', hopefully with
a few topics that have been in 'next', and also some "discussed
but forgotten" fixes on the list if somebody kindly can remind
me ;-).

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Frank Lichtenheld (2):
  config: Complete documentation of --get-regexp
  config: Change output of --get-regexp for valueless keys

Linus Torvalds (1):
  Fix zero-object version-2 packs

Matt Kraai (1):
  Correct the name of NO_R_TO_GCC_LINKER in the comment describing
      it.

Sam Vilain (3):
  cleanup merge-base test script
  repack: improve documentation on -a option
  git-remote: document -n

Shawn O. Pearce (5):
  git-gui: Correctly install to /usr/bin on Cygwin
  git-gui: Bind Tab/Shift-Tab to cycle between panes in blame
  git-gui: Don't require $DISPLAY just to get --version
  git-gui: Don't nice git blame on MSYS as nice is not supported
  git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack

Sven Verdoolaege (1):
  Ignore submodule commits when fetching over dumb protocols


* The 'master' branch has these since the last announcement
  in addition to the above.

Adam Roben (2):
  git-send-email: Add --threaded option
  git-send-email: make options easier to configure.

Alex Riesen (1):
  Avoid perl in t1300-repo-config

Alexandre Vassalotti (1):
  git-tag: Fix "can't shift that many".

Brian Gernhardt (1):
  Fix t5516-fetch for systems where `wc -l` outputs whitespace.

Carlos Rica (3):
  Fix git-stripspace to process correctly long lines and spaces.
  Add test script for git-stripspace.
  Add test-script for git-tag

Frank Lichtenheld (2):
  config: Add --null/-z option for null-delimted output
  config: add support for --bool and --int while setting values

Gerrit Pape (1):
  git-cvsimport: force checkout of working tree after initial import

Jim Meyering (3):
  detect close failure on just-written file handles
  Don't ignore a pack-refs write failure
  git-log: detect dup and fdopen failure

Johannes Schindelin (2):
  t7004: ship trustdb to avoid gpg warnings
  git add: respect core.filemode with unmerged entries

Junio C Hamano (2):
  Add core.quotepath configuration variable.
  Update draft Release Notes for 1.5.3

Linus Torvalds (3):
  Clean up internal command handling
  Check for IO errors after running a command
  git: Try a bit harder not to lose errno in stdio

Mark Levedahl (5):
  gitk: Make selection highlight color configurable
  gitk: Update fontsize in patch / tree list
  gitk: Allow specifying tabstop as other than default 8 characters.
  gitk: Use a spinbox for setting tabstop settings
  gitk: Update selection background colorbar in prefs dialog

Matthias Lederhofer (10):
  rev-parse: document --is-inside-git-dir
  rev-parse: introduce --is-bare-repository
  test git rev-parse
  introduce GIT_WORK_TREE to specify the work tree
  Use new semantics of is_bare/inside_git_dir/inside_work_tree
  extend rev-parse test for --is-inside-work-tree
  test GIT_WORK_TREE
  setup_git_directory: fix segfault if repository is found in cwd
  filter-branch: always export GIT_DIR if it is set
  make git barf when an alias changes environment variables

Michael Krelin (1):
  git-svn: honor ~/.subversion/ client cert file settings.

Paul Mackerras (18):
  gitk: Use the -q flag to git checkout
  gitk: New infrastructure for working out branches & previous/next
      tags
  gitk: Don't try to list large numbers of tags or heads in the
      details pane
  gitk: Add some more comments to the optimize_rows procedure
  gitk: Improve the behaviour of the initial selection
  gitk: Implement a simple scheduler for the compute-intensive stuff
  gitk: Cope with commit messages with carriage-returns and initial
      blank lines
  gitk: Disable the head context menu entries for the checked-out
      branch
  gitk: Store ids in rowrangelist and idrowranges rather than row
      numbers
  gitk: New algorithm for drawing the graph lines
  gitk: Show local uncommitted changes as a fake commit
  gitk: Speed up the reading of references
  gitk: Get rid of the childlist variable
  gitk: Add a "reset branch to here" row context-menu operation
  gitk: Limit how often we change the canvas scrolling region
  gitk: Fix bug causing nearby tags/heads to sometimes not be
      displayed
  gitk: Improve handling of whitespace and special chars in filenames
  gitk: Add a progress bar to show progress while resetting

Quy Tonthat (1):
  git.spec: RPM failed, looking for wrong files.

René Scharfe (2):
  diffcore-rename: don't change similarity index based on basename
      equality
  diff: round down similarity index

Sam Vilain (2):
  git-svn: use git-log rather than rev-list | xargs cat-file
  git-svn: cache max revision in rev_db databases

Shawn O. Pearce (3):
  git-gui: Quiet our installation process
  Teach bash how to complete +refspec on git-push
  Correct usages of sed in git-tag for Mac OS X

Simon Hausmann (1):
  git-new-workdir: Fix shell warning about operator == used with
      test.

Theodore Ts'o (1):
  Don't fflush(stdout) when it's not helpful

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-06-21  7:21               ` Junio C Hamano
@ 2007-06-25  9:43                 ` Junio C Hamano
  2007-07-02  0:16                   ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-06-25  9:43 UTC (permalink / raw)
  To: git

Among many small fixes and some code churns, there are a few
notable topics from 'next'.

 - git-filter-branch to rewrite history;

 - git-add "Huh?" factor fix when attempting to add an empty directory;

 - git-log and friends do not have the 16kB size limit for
   commit log messages anymore;

 - git-log and friends' --pretty=oneline treats the first
   paragraph of a commit log message as the title line;

 - "git-log --follow -- single-file";

Simon Hausmann and Shawn Pearce have shepherded a fast-import
based Perforce importer into contrib/fast-import area.

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

Dave O'Neill (1):
  Generate tags with correct timestamp (git-svnimport)

Gerrit Pape (1):
  git-svn: trailing slash in prefix is mandatory with --branches/-b

Jeff King (4):
  dir_struct: add collect_ignored option
  builtin-add: simplify (and increase accuracy of) exclude handling
  Fix ALLOC_GROW off-by-one
  Fix ALLOC_GROW calls with obsolete semantics

Johannes Schindelin (7):
  Add git-filter-branch
  filter-branch: use $(($i+1)) instead of $((i+1))
  filter-branch: fix behaviour of '-k'
  Teach filter-branch about subdirectory filtering
  pp_header(): work around possible memory corruption
  diffcore-rename: favour identical basenames
  filter-branch: add example to move everything into a subdirectory

Johannes Sixt (4):
  filter-branch: Use rev-list arguments to specify revision ranges.
  filter-branch: also don't fail in map() if a commit cannot be
      mapped
  filter-branch: Simplify parent computation.
  filter-branch: subdirectory filter needs --full-history

Julian Phillips (1):
  new-workdir: handle rev-parse --git-dir not always giving full path

Junio C Hamano (5):
  t7003: make test repeatable
  Lift 16kB limit of log message output
  Extend --pretty=oneline to cover the first paragraph,
  Two trivial -Wcast-qual fixes
  git-send-email: Do not make @-less message ID

Linus Torvalds (2):
  Finally implement "git log --follow"
  Fix up "git log --follow" a bit..

Matthias Lederhofer (3):
  filter-branch: prevent filters from reading from stdin
  chmod +x git-filter-branch.sh
  make dist: include configure script in tarball

Nanako Shiraishi (1):
  Cloning from a repo without "current branch"

Shawn O. Pearce (2):
  Avoid src:dst syntax as default bash completion for git push
  Document git-gui, git-citool as mainporcelain manual pages

Sven Verdoolaege (1):
  t9500: skip gitweb tests if perl version is too old

-- p4 --

Benjamin Sergeant (1):
  git-p4 fails when cloning a p4 depo.

Han-Wen Nienhuys (28):
  Cleanups
  reformatting: break long lines.
  rename apply() to applyCommit(); apply is a python builtin
  add .dotest to .gitignore
  Robustness fixes for pipes
  cleanup
  minor cleanups
  clone and sync --keep-path to keep perforce path to module.
  use string.strip() iso. slicing.
  use strip() iso. slicing for removing \n
  add --verbose to all commands.
  Extract multiple paths concurrently.
  Diverse cleanups
  remove global .gitdir
  Read p4 files in one batch.
  Thinko, fix buglet.
  store p4 user cache in home directory.
  thinko.
  read files before creating the commit.
  don't p4 print deleted files.
  only run p4 print if necessary
  use p4CmdList() to get file contents in Python dicts. This is more
      robust.
  Cleanups & import into p4/master for local import
  remove debug print
  thinko: really ignore deleted files.
  look for 'text' and 'binary' files.
  print error message when p4 print fails (eg. due to permission
      problems)
  also strip p4/ from local imports.

Kevin Green (1):
  git-p4: check for existence of repo dir before trying to create

Marius Storm-Olsen (7):
  Make the command call silent
  Replace \r\n with \n when importing from p4 on Windows
  Ensure that the commit message is Windows formated (CRLF) before
      invoking the editor.
  Fix git-p4 clone (defaultDestination)
  Fix single branch import into remotes
  Exclude the HEAD symbolic ref from the list of known branches
  Only use double quotes on Windows

Simon Hausmann (222):
  Initial import of a python script to import changesets from
      Perforce into git.
  Added basic support for specifying the depot path to import from as
      well as the range of perforce changes.
  Slightly improved help usage output and made specifying the
      trailing slash for the depot path optional.
  Implemented basic support for converting the date of the perforce
      change to the git format. The timezone isn't correctly set up
      yet though.
  Some fixes to the timezone conversion between the date of a
      perforce change and the git commit.
  Speed up the import of individual files from Perforce into git by
      passing the output of "p4 print" directly to git fast-import.
      Also try to set the mode of the file in git correctly based on
      file type heuristics.
  Removed unused p4cat function and added helper function for the
      perforce python interface (p4Cmd).
  Changed the import mechanism to write to git fast-import through a
      pipe instead of having p4-fast-export write to stdout and let
      the caller connect it to git fast-import.
  Minor code cleanups and ported some p4 interfacing code over to the
      p4 python mode.
  Instead of parsing the output of "p4 users" use the python objects
      of "p4 -G users".
  Ported the remaining functions that parsed p4 shell output over to
      the p4 python interface.
  Avoid calling fstat for every imported file (slow!) and instead
      read the file data first into the python process and use the
      length of the bytes read for the size field of git fast-import.
  Permit calling p4-fast-export with a depot path that has the
      typical ... wildcard at the end.
  Fixed displaying import progress by calling flush on stdout.
  Create a git tag for every changeset imported from perforce.
  Fix file permissions of p4-fast-export.py to be executable.
  Started working on incremental imports from Perforce.
  Simplify the incremental import by elimination the need for a
      temporary import branch.
  Code cleanups, move the code to create a commit with fast-import
      into a separate function out of the main loop.
  Initial support for importing a directory from Perforce at a
      specified revision.
  Minor cleanups and print an error message of git fast-import if it
      fails.
  Fixed incremental imports by using the correct "from" command
      instead of "merge" with git fast-import.
  Make incremental imports easier to use by storing the p4 depot path
      after an import in .git/config and re-using it when we're
      invoked again later.
  Make specifying the revision ranges more convenient.
  Fix calculation of the newest imported revision for #head imports.
  Catch io exceptions from git fast-import again and print the error
      message.
  Made the name of the git branch used for the perforce import
      configurable through a new --branch=<name> commandline option.
  Added a little helper script to debug the output of the p4 python
      interface.
  Minor code cleanups.
  Avoid the excessive use of git tags for every perforce change and
      instead just create one git tag for the last imported change.
  Changed the default git import branch from "p4" to "master".
  Added a little helper script to remove unused tags from the
      perforce import.
  Create lightweight git tags (using the "reset" trick) for the
      incremental import instead of full-blown ones. Also fix parsing
      the output of git name-rev for figuring out the last imported
      p4 change number.
  Cleanups, remove unused variable.
  Code cleanups.
  Started work on p4 branch detection (experimental!).
  More fixes in heuristic p4 branch detection based on common path
      components.
  After marking a p4 branch as merged don't ever merge it in git
      again.
  Set git fast-import marks for every imported change for future use.
  When trying to map p4 integrations to git merges just record it as
      a single merge with the newest p4 change as secondary parent.
  Make it possible to specify the p4 changes to import through a text
      file (for debugging) and made various improvements to the
      branch/merge heuristic detection.
  Use sets.Set() instead of set() to run also with older versions of
      Python.
  Fix single-branch imports by skipping the branch/merge detection
      correctly.
  Added p4 delete behavioural emulation as todo item.
  Added support for --silent so that p4-fast-export can be called
      from cronjobs.
  More work in --silent support.
  Don't print a plain newline at the end of the execution (avoids
      bogus cron error mails).
  Adjust the output parsing of git name-rev to handle the output of
      the latest git version.
  Work in progress on detecting branches.
  Changed --known-branches to take a file as argument instead of a
      comma separated list.
  Fixed p4-debug file extension.
  Make the p4 data/command cache configurable through the
      --cache-debug commandline option.
  Minor code cleanups.
  More code cleanups and preparations for more branch detection
      heuristics.
  More work on branch detection by implementing
      changeIsBranchMerge().
  Reduce the number of false "merges" by skipping "branch from"
      entries in the integrated output as well as by ignoring
      integrations of future (newer) changes.
  Split up the cache commandline options into (command) cache and
      data cache.
  First version of a new script to submit changes back to perforce
      from git repositories.
  Fix git-dir option and allow reading log substitutions from a file
  Lots of bugfixes to p4-git-sync.
  Automatically operate on a temporary branch, needed for cherry-pick
      to work when applying changes to
  Be nice and use /usr/bin/env python for the git-p4 scripts
  Ignore Apple resource files when importing from perforce to git.
  Auto-detect the current git branch before submitting back to
      perforce.
  Use p4 revert ... instead of revert -a ... after submitting, to
      make sure the p4 checkout is clean.
  Default to interactive syncing
  Improved the git dir detection.
  Pass the right number of arguments to commit, fixes single-branch
      imports.
  Start moving the git-p4 tools into one single script.
  Provide a little bit of help description for the git-p4 "tools".
  First (untested) attempt at migrating p4-git-sync into the final
      git-p4 script
  Part of the code is copyright by Trolltech ASA.
  sync-to-perforce is now called submit and fixed the gitdir check a
      little bit
  Completely untested "merge" of p4-fast-export.py into git-p4.py
  Added missing "self"s to make the script evaluate correctly.
  Fixed the initial version import by getting the file index correct
      by correctly skipping deleted files.
  Removed p4-fast-export and p4-git-sync as they've been integrated
      into git-p4 now.
  Start of the git-p4 documentation.
  Documentation enhancements.
  Added experimental but super-fast --apply-as-patch option to git-p4
      submit
  Fix support for deletions in git-p4 submit when using
      --apply-as-patch by filtering out deletions in the diff-tree
      output.
  Made --apply-as-patch the default for git-p4 submit as it's
      significantly faster.
  Make it possible to invoke git-p4 from within subdirectories of a
      git working tree.
  Don't show the submit template and the diff first in less but show
      it in $editor right away
  Removed the .py extension from git-p4 as it's annoying to type
      every time.
  Changed the format of the imported log message slightly, so that
      it's easier to parse again.
  Changed the default branch for imports from "master" to "p4"
  Added some helper function(s) to parse the depot path and change
      number from the log message
  Helper function to check the existance of a revision
  Set the default branch in run, not in the constructor
  Brand new smart incremental import that doesn't need tags or git
      repo-config :)
  Make it possible to run git-p4 submit from within the git
      repository
  Use the new incremental import style by default
  Different versions of p4 have different output for the where
      command ;(
  Minor cosmetic fixlet for the git-p4 submit sync question.
  Prefer git command over git-command.
  Don't try to parse any options with git-p4 debug but pass it
      straight on to p4
  git-p4 debug doesn't need a git repository
  Added support for mapping p4 labels to git tags
  Fix variable usage in tag import
  Fix the docs for git-p4 submit and turn git-p4 submit --master=foo
      into
  Fix "compilation" :)
  Clean up python class names.
  Added git-p4 rebase convenience
  Provide a tree summary after git-p4 rebase
  Turn off potentially slow label detection by default
  Honor --silent for labels
  Added git-p4 clone convenience command
  Fix file determination for #head imports
  fix variable usage (oops)
  Added a simple example of usage to the "documentation" :)
  Allow for convenient rebasing after git-p4 submit
  Print an error message of some sort if git fast-import fails.
  Fix the timezone formatting. Now qgit also displays (parses) it
      correctly.
  Removed the old patch apply code from git-p4 submit.
  Slightly improved formatting of the raw_input questions.
  A new attempt at fixing the child-fast-import-process-not-finished
      race condition
  Handle patch errors in git-p4 submit better.
  Doc cleanups.
  Micro cleanup
  cleanup, renamed self.globalPrefix to self.depotPath
  Cleanup, removed the old tagging code
  Document some implementation details, for the curious... :)
  Use the subprocess module instead of popen2 to make it work on
      Windows.
  Added a little .bat wrapper from Marius
  Make sure all popen calls use binary mode (for Windows) and
  Make submitting work on Windows.
  Converted to unix newlines
  Fix git-p4 clone //depot/project (head import)
  Make git-p4 work with bare repositories.
  Added the possibility of skipping patches during git-p4 submit
  Give a better hint if git-p4 submit fails
  Fix calling git-p4 rebase from within a subdirectory (git rebase
      wants to be in toplevel)
  A little todo note before I forget it :), based on a suggestion
      from Lars.
  Fixing syncing (gitdir discovery / cd) for bare repositories
  Always pass a sha1 for the initial parent so that git-fast-import
      doesn't think
  Clean up code duplication for revision parsing and fix previous
      commit to not
  Removed cleantags command. It doesn't have any meaning anymore.
  Removed ancient and unused code to find the last imported revision
      from previous imports
  Create the origin based import branch using git update-ref instead
      of git branch
  Changed the default p4 import branch to be
      refs/remotes/p4/{HEAD,master}
  Bite the bullet and automatically convert old style refs/heads/p4
      repositories
  Added support for git-p4 sync/rebase --with-origin. See git-p4.txt
      for details :)
  Removed todo item that is implemented :)
  Fix branch setup after initial clone.
  Removed unused cache variables.
  Started rewriting the branch detection, based on "p4 branches" and
      "p4 branch -o foo".
  Give branches a nice project prefix and don't bail out on clone if
      we failed
  More work on the incremental importing of multiple branches.
  Cleanup/speed up the branch<> file split and removed change range
      limitation that I added
  More cleanups and speedups for labels and branches
  Removed unused variable, more cleanups
  Cache the output of "p4 users" for faster syncs on high latency
      links.
  Fix gitdir not being set when cloning. Needed for writing the p4
      users cache.
  Oops, not only /set/ gitdir on clone, also set it /correctly/ :)
  Use git format-patch and git apply --apply when extracting patches
      from git and
  Added support for git-p4 submit --direct (experimental)
  Specifying --detect-branches is now only needed for the initial
      clone/sync.
  Had an idea for debugging, record it :)
  Another (potentially life-saving) idea for submit --direct
  Improved output for multi branch imports and noted another little
      todo item
  Fix conversion from old style heads/p4 to remotes/p4/master
  Fix error detection with git-p4 submit when the requested depot
      path is not in the client view.
  Fix git symbolic-ref warning on initial clone
  Detect with git-p4 submit --direct when there are no changes in the
      working directory
  Make git-p4 submit --direct safer by also creating a git commit
  Added a rollback command for debugging. It sets back the heads of
      the p4 branches to the specified p4 change number or earlier.
  Fix branch detection in multi-branch imports
  Fixes for rollback, delete branches that did not exist at the
      specified p4 change
  Added support for importing multiple branches into refs/heads
      instead of just refs/remotes
  Added support for --max-changes=<count> to ease import debugging
  Use refs/heads/* instead of refs/heads/p4/* for local imports
  Doc updates
  Avoid calling git symbolic-ref refs/heads/p4//HEAD (double slash)
  Make rollback work with locally imported branches
  Don't make len(p4Cmd("p4 changes -m 1 //foo/...")) == 0 succeed
      when the p4 command itself failed.
  Oops, fill the /list/ correct with the p4 exit code.
  Catch p4 errors in rollback early enough (before deleting refs!)
  Fix p4 execution in git-p4 rollback.
  Fix multi-branch import with --silent.
  Load the user map from p4 only once at run-time.
  Fix creating the remotes/p4 branches based on origin/* for the
      multi-branch import
  Forgot to remove this return statement from debugging
  Added support for --with-origin with multi-branch imports
  Oops, fix --with-origin to /really/ also call git fetch :)
  Avoid creating non-p4 branches in remotes/p4 off of remotes/origin
  Make git-p4 work with packed refs (don't use os.path.exists to
      check for the
  Make --with-origin also work without origin :)
  Make --with-origin the default for syncing.
  Shortcut the case where we have no origin branch
  Forgot to remove this TODO item when I made --with-origin the
      default :)
  Added git-p4 submit --trust-me-like-a-fool for the adventurous
      users :)
  Fix creation of refs/remotes/p4/HEAD symbolic ref
  Fix my email address, this isn't really KDE related :)
  In *_pipe print the command that failed if it fails.
  Fix typo in listExistingP4Branches that broke sync.
  Fix support for "depot-path" in older git-p4 imports
  Fix common path "calculation" from logs of multiple branches.
  Don't attempt to set the initialParent on multi-branch imports
      (useless).
  Hack to make the multi-branch import work again with
      self.depotPaths now that
  Fix git-p4 rebase
  Fix git-p4 submit
  Fix depot-path determination for git-p4 submit
  Make clone behave like git clone by default again.
  Make git-p4 submit detect the correct reference (origin) branch
      when
  Only get the expensive branch mapping from the p4 server when not
  Fixed the check to make sure to exclude the HEAD symbolic refs when
      updating
  Fix updating/creating remotes/p4/* heads from origin/p4/*
  Fix project name guessing
  Fix depot-paths encoding for multi-path imports (don't split up
      //depot/path/foo)
  Fix support for explicit disabling of syncing with the origin
  Write out the options tag in the log message of imports only if we
      actually have
  Provide some information for single branch imports where the
      commits go
  Mention remotes/p4/master also in the documentation.
  git-p4 submit: Fix missing quotes around p4 commands to make them
      work with spaces in filenames
  Moved the code from git-p4 submit to figure out the upstream branch
      point
  Fix git-p4 rebase to detect the correct upstream branch instead of
      unconditionally
  Fix initial multi-branch import.
  Fix the branch mapping detection to be independent from the order
      of the "p4 branches" output.
  Warn about conflicting p4 branch mappings and use the first one
      found.
  Added git-p4 branches command that shows the mapping of perforce
      depot paths to imported git branches.
  Make it possible to specify the HEAD for the internal
      findUpstreamBranchPoint function.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-06-13 20:11             ` Junio C Hamano
  2007-06-13 22:31               ` Johannes Schindelin
@ 2007-06-21  7:21               ` Junio C Hamano
  2007-06-25  9:43                 ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-06-21  7:21 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since the last announcement.

 Alex Riesen (1):
  Add a local implementation of hstrerror for the system which do not have it

 Jakub Narebski (1):
  Generated spec file to be ignored is named git.spec and not git-core.spec

 Johannes Schindelin (2):
  Move buffer_is_binary() to xdiff-interface.h
  merge-recursive: refuse to merge binary files

 Junio C Hamano (5):
  $EMAIL is a last resort fallback, as it's system-wide.
  git-branch --track: fix tracking branch computation.
  Avoid diff cost on "git log -z"
  Documentation: adjust to AsciiDoc 8
  GIT 1.5.2.2


* The 'master' branch has these since the last announcement
  in addition to the above.

 Alex Riesen (2):
  Do not use h_errno after connect(2): the function does not set it
  cvsserver: Actually implement --export-all

 Daniel Barkalow (1):
  Fix pushing to a pattern with no dst

 Frank Lichtenheld (3):
  cvsserver: Add some useful commandline options
  cvsserver: Let --base-path and pserver get along just fine
  cvsserver: Actually implement --export-all

 Gerrit Pape (1):
  git-branch: cleanup config file when deleting branches

 Ismail Dönmez (1):
  Change default man page path to /usr/share/man

 Jakub Narebski (8):
  Document git rev-list --full-history
  Document git read-tree --trivial
  Document git rev-parse --is-inside-git-dir
  Document git reflog --stale-fix
  Document git rev-list --timestamp
  Use tabs for indenting definition list for options in git-log.txt
  Document git log --abbrev-commit, as a kind of pretty option
  Document git log --full-diff

 Junio C Hamano (8):
  remote.c: refactor match_explicit_refs()
  remote.c: refactor creation of new dst ref
  remote.c: minor clean-up of match_explicit()
  remote.c: fix "git push" weak match disambiguation
  remote.c: "git-push frotz" should update what matches at the source.
  git-push: Update description of refspecs and add examples
  Documentation: update "stale" links for 1.5.2.2
  INSTALL: explain how to build documentation

 Lars Hjemli (6):
  t7400: barf if git-submodule removes or replaces a file
  git-submodule: remember to checkout after clone
  Rename sections from "module" to "submodule" in .gitmodules
  git-submodule: give submodules proper names
  Add gitmodules(5)
  gitmodules(5): remove leading period from synopsis

 Sam Vilain (1):
  git-svn: avoid string eval for defining functions

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-06-13 22:31               ` Johannes Schindelin
@ 2007-06-14  7:12                 ` Johannes Sixt
  0 siblings, 0 replies; 601+ messages in thread
From: Johannes Sixt @ 2007-06-14  7:12 UTC (permalink / raw)
  To: git

Johannes Schindelin wrote:
> Next plans are: make filter-branch a misnomer: actually be able to rewrite
> more than one branch in one go, writing the outcome to the refs/rewritten/
> namespace. IIRC that was Hannes' project, but I'll gladly step in there if
> need be.

Be my guest. Even though I said "my plan" in that post
http://article.gmane.org/gmane.comp.version-control.git/49292
this was meant as a proposal. I'm not working on the topic at the
moment.

-- Hannes

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-06-13 20:11             ` Junio C Hamano
@ 2007-06-13 22:31               ` Johannes Schindelin
  2007-06-14  7:12                 ` Johannes Sixt
  2007-06-21  7:21               ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2007-06-13 22:31 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Wed, 13 Jun 2007, Junio C Hamano wrote:

> I would want to start the 1.5.3-rc cycle, after merging
> at least the submodule Porcelain (Lars) and filter-tree
> (Johannes and Pasky).

Isn't that Johannesses (and filter-branch)? :-)

FWIW I think that there lies a long road in front of us with 
filter-branch, after submodule is merged in. I have no preference on what 
should go in first, but filter-branch If My Plan Succeeds (TM) will help 
transition from huge imports to subprojects.

So, even if I am not _that_ interested in subprojects myself, I _do_ want 
to enhance filter-branch. IMHO filter-branch is yet another proof that 
cogito -- even if it is now set to die -- was well worth it. Thanks Pasky.

Next plans are: make filter-branch a misnomer: actually be able to rewrite 
more than one branch in one go, writing the outcome to the refs/rewritten/ 
namespace. IIRC that was Hannes' project, but I'll gladly step in there if 
need be.

After that, I imagine automatic subprojects disentangling (maybe somewhat 
related to Alex' suggestion), so you can say "this big project is actually 
a subproject: directories a/, b/ and c/ are self-contained subprojects).

Of course, the nearest future from my POV is to actually implement the 
missing tests :-)

Ciao,
Dscho

P.S.: Junio, wherever you are right now, have a nice time. Hopefully not 
too stressful.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-06-07  2:08           ` Junio C Hamano
@ 2007-06-13 20:11             ` Junio C Hamano
  2007-06-13 22:31               ` Johannes Schindelin
  2007-06-21  7:21               ` Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-06-13 20:11 UTC (permalink / raw)
  To: git

I'll be dormant for the next 72 hours or so, so please do not
get alarmed if no patches sent to the list is applied to my
tree.  Please remind me about them after they are commented on,
revised and improved, and final revision got agreed to be good
on the list.

WIth a big usability change to git-gui blame viewer on 'maint',
I think it is time to do 1.5.2.2 this weekend (if I have the
energy, that is).

The 'master' side has quite a lot of clean-ups and improvements
in the fringes, but nothing big has come out of 'next' since
1.5.2.  I would want to start the 1.5.3-rc cycle, after merging
at least the submodule Porcelain (Lars) and filter-tree
(Johannes and Pasky).  There are other topics already on 'next'
that are probably 1.5.3 material as well.

* The 'maint' branch has these fixes since the last announcement.

 Alex Riesen (2):
  Make the installation target of git-gui a little less chatty
  Fix clone to setup the origin if its name ends with .git

 Gerrit Pape (1):
  Fix typo in remote branch example in git user manual

 J. Bruce Fields (4):
  user-manual: quick-start updates
  user-manual: add a missing section ID
  Documentation: user-manual todo
  tutorial: use "project history" instead of "changelog" in header

 Junio C Hamano (1):
  checkout: do not get confused with ambiguous tag/branch names

 Kristian Høgsberg (1):
  Unquote From line from patch before comparing with given from address.

 Luiz Fernando N. Capitulino (1):
  git-cherry: Document 'limit' command-line option

 Matthijs Melchior (1):
  New selection indication and softer colors

 Sam Vilain (1):
  Don't assume tree entries that are not dirs are blobs

 Shawn O. Pearce (47):
  git-gui: Allow creating a branch when none exists
  git-gui: Allow as few as 0 lines of diff context
  git-gui: Don't quit when we destroy a child widget
  git-gui: Attach font_ui to all spinbox widgets
  git-gui: Verify Tcl/Tk is new enough for our needs
  Revert "Make the installation target of git-gui a little less chatty"
  git-gui: Add a 4 digit commit abbreviation to the blame viewer
  git-gui: Cleanup blame::new widget initialization
  git-gui: Remove empty blank line at end of blame
  git-gui: Improve the coloring in blame viewer
  git-gui: Simplify consecutive lines that come from the same commit
  git-gui: Use arror cursor in blame viewer file data
  git-gui: Display tooltips in blame viewer
  git-gui: Highlight the blame commit header from everything else
  git-gui: Remove unnecessary reshow of blamed commit
  git-gui: Cleanup minor style nit
  git-gui: Space the commit group continuation out in blame view
  git-gui: Show author initials in blame groups
  git-gui: Allow the user to control the blame/commit split point
  git-gui: Display a progress bar during blame annotation gathering
  git-gui: Allow digging through history in blame viewer
  git-gui: Combine blame groups only if commit and filename match
  git-gui: Show original filename in blame tooltip
  git-gui: Use a label instead of a button for the back button
  git-gui: Clip the commit summaries in the blame history menu
  git-gui: Remove the loaded column from the blame viewer
  git-gui: Remove unnecessary space between columns in blame viewer
  git-gui: Use lighter colors in blame view
  git-gui: Make the line number column slightly wider in blame
  git-gui: Automatically expand the line number column as needed
  git-gui: Remove unused commit_list from blame viewer
  git-gui: Better document our blame variables
  git-gui: Cleanup redundant column management in blame viewer
  git-gui: Switch internal blame structure to Tcl lists
  git-gui: Label the uncommitted blame history entry
  git-gui: Rename fields in blame viewer to better descriptions
  git-gui: Display the "Loading annotation..." message in italic
  git-gui: Run blame twice on the same file and display both outputs
  git-gui: Display both commits in our tooltips
  git-gui: Jump to original line in blame viewer
  git-gui: Use three colors for the blame viewer background
  git-gui: Improve our labeling of blame annotation types
  git-gui: Favor the original annotations over the recent ones
  git-gui: Changed blame header bar background to match main window
  git-gui: Include 'war on whitespace' fixes from git.git
  git-gui: Give amend precedence to HEAD over MERGE_MSG
  git-gui: Save geometry before the window layout is damaged

 william pursell (1):
  Make command description imperative statement, not third-person present.


* The 'master' branch has these since the last announcement
  in addition to the above.

 Alex Riesen (1):
  Fix push with refspecs containing wildcards

 Alexandre Julliard (1):
  pack-check: Sort entries by pack offset before unpacking them.

 Andy Whitcroft (3):
  cvsimport: add support for new style remote layout
  cvsimport: update documentation to include separate remotes option
  cvsimport: add <remote>/HEAD reference in separate remotes more

 Aneesh Kumar K.V (2):
  gitview: Fix the blame interface.
  gitview: run blame with -C -C

 Dan McGee (1):
  git-mergetool: Allow gvimdiff to be used as a mergetool

 Elvis Pranskevichus (1):
  Use git-tag in git-cvsimport

 Eric Wong (3):
  git-svn: cleanup: factor out longest_common_path() function
  git-svn: test for creating new directories over svn://
  git-svn: reduce stat() calls for a backwards compatibility check

 Frank Lichtenheld (1):
  cvsserver: Make req_Root more critical of its input data

 Jakub Narebski (6):
  gitweb: Provide links to commitdiff to each parent in 'commitdiff' view
  gitweb: Improve "next" link in commitdiff view
  gitweb: Split git_patchset_body into separate subroutines
  gitweb: Create special from-file/to-file header for combined diff
  gitweb: Add links to blobdiffs in from-file/to-file header for merges
  gitweb: '--cc' for merges in 'commitdiff' view

 Jeff King (2):
  cmd_log_init: remove parsing of --encoding command line parameter
  refactor dir_add_name

 Jim Meyering (1):
  Don't dereference a strdup-returned NULL

 Johan Herland (1):
  Remove unnecessary code and comments on non-existing 8kB tag object restriction

 Johannes Schindelin (2):
  git-merge-file: refuse to merge binary files
  Teach diff to imply --find-copies-harder upon -C -C

 Johannes Sixt (3):
  Avoid double-slash in path names that depend on $(sharedir).
  Remove trailing slash from $(template_dir).
  git-remote show: Also shorten non-fast-forward refs in the 'push' listing

 Junio C Hamano (12):
  War on whitespace
  Test wildcard push/fetch
  More missing static
  More missing static
  Even more missing static
  git-blame: do not indent with spaces.
  git-blame -w: ignore whitespace
  mktag: minimally update the description.
  Makefile: common-cmds.h depends on generate-cmdlist.sh script
  Makefile: allow generating git.o for debugging purposes
  -Wold-style-definition fix
  More static

 Lars Hjemli (2):
  git-submodule: move cloning into a separate function
  git-submodule: clone during update, not during init

 Linus Torvalds (1):
  Makefile: add an explicit rule for building assembly output

 Matthias Lederhofer (1):
  gitweb: change filename/directory name of snapshots

 Michael Ellerman (2):
  gitview: Use new-style classes
  gitview: Define __slots__ for Commit

 Pierre Habouzit (2):
  Active_nr is unsigned, hence can't be < 0
  Missing statics.

 René Scharfe (1):
  t5000: silence unzip availability check

 Shawn O. Pearce (10):
  git gui 0.8.0
  git-gui: GUI support for running 'git remote prune <name>'
  git-gui: Show the git-gui library path in 'About git-gui'
  git-gui: Enable verbose Tcl loading earlier
  git-gui: Provide fatal error if library is unavailable
  git-gui: Disable tearoff menus on Windows, Mac OS X
  git-gui: Allow users to rename branches through 'branch -m'
  git-gui: Allow users to delete remote branches
  git-gui: Expose the merge.diffstat configuration option
  git-gui: Internalize symbolic-ref HEAD reading logic

 Theodore Ts'o (1):
  git-mergetool: Make default selection of merge-tool more intelligent

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-06-02 21:09         ` Junio C Hamano
@ 2007-06-07  2:08           ` Junio C Hamano
  2007-06-13 20:11             ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-06-07  2:08 UTC (permalink / raw)
  To: git

It has been slow on the stable front.

* The 'maint' branch has these fixes since the last announcement.

 Johannes Sixt (1):
  Accept dates before 2000/01/01 when specified as seconds since the epoch

 Michael Milligan (1):
  git-cvsimport: Make sure to use $git_dir always instead of .git sometimes

 Sam Vilain (1):
  fix documentation of unpack-objects -n


* The 'master' branch has these since the last announcement
  in addition to the above.

 Geert Bosch (1):
  Unify write_index_file functions

 Johannes Schindelin (5):
  Update to SubmittingPatches
  git-fsck: learn about --verbose
  Move buffer_is_binary() to xdiff-interface.h
  merge-recursive: refuse to merge binary files
  t5000: skip ZIP tests if unzip was not found

 Johannes Sixt (1):
  Makefile: Remove git-merge-base from PROGRAMS.

 Jon Loeliger (1):
  Add the --numbered-files option to git-format-patch.

 Josh Triplett (1):
  Fix typo in git-mergetool

 Junio C Hamano (4):
  Remove git-applypatch
  Release Notes: start preparing for 1.5.3
  git-apply: what is detected and fixed is not just trailing spaces.
  git-branch --track: fix tracking branch computation.

 Lars Hjemli (2):
  Add git-submodule command
  Add basic test-script for git-submodule

 Martin Koegler (1):
  gitweb: Handle non UTF-8 text better

 Matthias Lederhofer (2):
  add git-filter-branch to .gitignore
  make clean should remove all the test programs too

 Matthijs Melchior (1):
  Teach git-tag about showing tag annotations.

 Petr Baudis (1):
  git-applymbox: Remove command

 Pierre Habouzit (1):
  $EMAIL is a last resort fallback, as it's system-wide.

 Randal L. Schwartz (1):
  Add test-sha1 to .gitignore.

 Sam Vilain (1):
  Don't assume tree entries that are not dirs are blobs

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-05-29 10:12       ` Junio C Hamano
@ 2007-06-02 21:09         ` Junio C Hamano
  2007-06-07  2:08           ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-06-02 21:09 UTC (permalink / raw)
  To: git

I will do a v1.5.2.1 with 'maint' and push it out this weekend.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

 Frank Lichtenheld (2):
  git-config: Various small fixes to asciidoc documentation
  git-config: Improve documentation of git-config file handling

 Jeff King (1):
  Documentation: robustify asciidoc GIT_VERSION replacement

 Jerald Fitzjerald (1):
  decode_85(): fix missing return.

 Josh Triplett (1):
  Create a new manpage for the gitignore format, and reference it elsewhere

 Kristian Høgsberg (1):
  Use =20 when rfc2047 encoding spaces.

 Linus Torvalds (1):
  fix signed range problems with hex conversions


* The 'master' branch has these since the last announcement
  in addition to the above.

 James Bowes (1):
  rev-parse: Identify short sha1 sums correctly.

 Jonas Fonseca (2):
  Fix git-am(1) synopsis formatting
  git-rebase: suggest to use git-add instead of git-update-index

 Julian Phillips (1):
  Makefile: Use generic rule to build test programs

 Junio C Hamano (1):
  Add DLH to .mailmap

 Martin Koegler (4):
  builtin-pack-objects: don't fail, if delta is not possible
  git-pack-objects: cache small deltas between big objects
  builtin-pack-object: cache small deltas
  diff-delta: use realloc instead of xrealloc

 Nicolas Pitre (2):
  fix repack with --max-pack-size
  always start looking up objects in the last used pack first

 Shawn O. Pearce (7):
  Lazily open pack index files on demand
  Micro-optimize prepare_alt_odb
  Attempt to delay prepare_alt_odb during get_sha1
  Test for recent rev-parse $abbrev_sha1 regression
  Simplify index access condition in count-objects, pack-redundant
  Ensure the pack index is opened before access
  Style nit - don't put space after function names

 Theodore Ts'o (1):
  Fix minor grammatical typos in the git-gc man page

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-05-23 21:46     ` Junio C Hamano
@ 2007-05-29 10:12       ` Junio C Hamano
  2007-06-02 21:09         ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-05-29 10:12 UTC (permalink / raw)
  To: git

Time for 1.5.2.1 perhaps.

The second batch of random changes are in 'master' now.  This is
a rather large-ish looking one.  Handle it with care.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

 Andy Parkins (2):
  Fix mishandling of $Id$ expanded in the repository copy in convert.c
  Add test case for $Id$ expanded in the repository

 Carlos Rica (1):
  fix memory leak in parse_object when check_sha1_signature fails

 Eric Wong (1):
  git-svn: avoid md5 calculation entirely if SVN doesn't provide one

 Frank Lichtenheld (3):
  cvsserver: Correct inetd.conf example in asciidoc documentation
  cvsserver: Note that CVS_SERVER can also be specified as method variable
  cvsserver: Fix some typos in asciidoc documentation

 Jakub Narebski (3):
  Documentation: Clean up links in GIT Glossary
  Replace the last 'dircache's by 'index'
  Documentation: Add definition of "evil merge" to GIT Glossary

 James Bowes (1):
  Documentation: fix git-config.xml generation

 James Y Knight (1):
  Fix git-svn to handle svn not reporting the md5sum of a file, and test.

 Jeff King (2):
  git-am: use printf instead of echo on user-supplied strings
  More echo "$user_message" fixes.

 Johan Herland (1):
  Fix stupid typo in lookup_tag()

 Jonas Fonseca (1):
  Update bash completion to ignore some more plumbing commands

 Junio C Hamano (3):
  name-rev: tolerate clock skew in committer dates
  git-commit: use printf '%s\n' instead of echo on user-supplied strings
  Add tests for the last two fixes.

 Nguyễn Thái Ngọc Duy (1):
  Makefile: Remove git-fsck and git-verify-pack from PROGRAMS

 Shawn O. Pearce (12):
  git-gui: Tighten internal pattern match for lib/ directory
  Refactor fast-import branch creation from existing commit
  Fix possible coredump with fast-import --import-marks
  Hide the plumbing diff-{files,index,tree} from bash completion
  Teach bash completion about git-shortlog
  Remove a duplicate --not option in bash completion
  Update bash completion header documentation
  Teach bash completion about 'git remote update'
  Teach bash completion about recent log long options
  Update bash completion for git-config options
  Correct key bindings to Control-<foo>
  git-gui: Guess our share/git-gui/lib path at runtime if possible

 Simon Hausmann (2):
  fast-import: Fix uninitialized variable
  fast-import: Fix crash when referencing already existing objects

 Steffen Prohaska (1):
  user-manual: fixed typo in example


* The 'master' branch has these since the last announcement
  in addition to the above.

 Alex Riesen (6):
  Add run_command_v_opt_cd: chdir into a directory before exec
  Add ability to specify environment extension to run_command
  Allow environment variables to be unset in the processes started by run_command
  Verbose connect messages to show the IP addresses used
  Add another verbosity level to git-fetch
  Add a configuration option to control diffstat after merge

 Dana L. How (7):
  Alter sha1close() 3rd argument to request flush only
  git-repack --max-pack-size: new file statics and code restructuring
  git-repack --max-pack-size: write_{object,one}() respect pack limit
  git-repack --max-pack-size: split packs as asked by write_{object,one}()
  git-repack --max-pack-size: add option parsing to enable feature
  pack-objects: clarification & option checks for --max-pack-size
  Ensure git-repack -a -d --max-pack-size=N deletes correct packs

 Daniel Barkalow (5):
  Move remote parsing into a library file out of builtin-push.
  Move refspec parser from connect.c and cache.h to remote.{c,h}
  Add handlers for fetch-side configuration of remotes.
  Update local tracking refs when pushing
  Move refspec pattern matching to match_refs().

 Fernando J. Pereda (1):
  Teach mailsplit about Maildir's

 Frank Lichtenheld (5):
  t9400: Add test cases for config file handling
  t9400: Add some more cvs update tests
  t9400: Add some basic pserver tests
  t9400: Work around CVS' deficiencies
  cvsserver: Handle 'cvs login'

 Junio C Hamano (4):
  pack-objects: pass fullname down to add_object_entry()
  Teach "delta" attribute to pack-objects.
  builtin-pack-objects: remove unnecessary code for no-delta
  mailsplit: fix for more than one input files

 Linus Torvalds (2):
  Make "git gc" pack all refs by default
  Make the pack-refs interfaces usable from outside

 Mark Levedahl (1):
  gitweb.perl - Optionally send archives as .zip files

 Nicolas Pitre (3):
  fixes to output of git-verify-pack -v
  improve delta long block matching with big files
  update diff-delta.c copyright

 Robin Rosenberg (1):
  Add option to cvs update before export

 Shawn O. Pearce (1):
  Allow contrib new-workdir to link into bare repositories

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-05-19  5:24   ` Junio C Hamano
@ 2007-05-23 21:46     ` Junio C Hamano
  2007-05-29 10:12       ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-05-23 21:46 UTC (permalink / raw)
  To: git

Although there are a few post release fixups queued for v1.5.2.1
on 'maint' already, all things considered I must say v1.5.2 was
a quite good release.  There isn't a huge "oops, hand me a brown
paper bag please" fix yet.  Knock, knock...

On the 'master' front, as promised, the first batch that were on
hold since v1.5.2-rc1 is in.  Nothing earth-shattering, really.

----------------------------------------------------------------

* The 'maint' branch has these fixes since v1.5.2.

 Fernando J. Pereda (1):
  Use PATH_MAX instead of TEMPFILE_PATH_LEN

 Frank Lichtenheld (2):
  t1300: Add tests for git-config --bool --get
  git-config: Correct asciidoc documentation for --int/--bool

 Jim Meyering (1):
  git-daemon: don't ignore pid-file write failure

 Johannes Schindelin (2):
  SubmittingPatches: mention older C compiler compatibility
  git-status: respect core.excludesFile

 Jonas Fonseca (1):
  branch: fix segfault when resolving an invalid HEAD

 Junio C Hamano (2):
  annotate: make it work from subdirectories.
  git-cvsserver: fix disabling service via per-method config

 Paolo Bonzini (1):
  Document branch.autosetupmerge.

 Stephan Springl (1):
  Use git-for-each-ref to check whether the origin branch exists.

 Sven Verdoolaege (1):
  unpack-trees.c: verify_uptodate: remove dead code


* The 'master' branch has these since v1.5.2, in addition to the above.

 Alex Riesen (1):
  Fix the progress code to output LF only when it is really needed

 Dana How (1):
  Custom compression levels for objects and packs

 Jakub Narebski (2):
  gitweb: Add test t9500 for gitweb (as standalone script)
  Add an option to git-ls-tree to display also the size of blob

 James Bowes (1):
  Add colour support in rebase and merge tree diff stats output.

 Junio C Hamano (2):
  git-apply: Fix removal of new trailing blank lines.
  Fix command line parameter parser of revert/cherry-pick

 Marco Costalba (1):
  Teach 'git-apply --whitespace=strip' to remove empty lines at the end of file

 Martin Waitz (1):
  rename dirlink to gitlink.

 Michael S. Tsirkin (1):
  connect: display connection progress

 Nicolas Pitre (3):
  allow for undeltified objects not to be reused
  make "repack -f" imply "pack-objects --no-reuse-object"
  deprecate the new loose object header format

 Petr Baudis (1):
  git-rev-list: Add regexp tuning options

 Shawn O. Pearce (1):
  Teach git-describe how to run name-rev

 Sven Verdoolaege (1):
  git-update-ref: add --no-deref option for overwriting/detaching ref

 Theodore Ts'o (1):
  Add --aggressive option to 'git gc'

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-05-17  0:21 ` Junio C Hamano
@ 2007-05-19  5:24   ` Junio C Hamano
  2007-05-23 21:46     ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-05-19  5:24 UTC (permalink / raw)
  To: git

I've done release 1.5.1.5, which hopefully would be the second
from the last release in 1.5.1 maintenance series (I somehow
ended up missing documentation formatting updates from Matthias
Kestenholz, which fix longstanding ugly formatting mistakes in
some manual pages).

The tip of 'master' will be tagged v1.5.2 hopefully in 24 hours.
Nothing earth shattering since the last message of this series.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

 J. Bruce Fields (10):
  user-manual: revise birdseye-view chapter
  glossary: expand and clarify some definitions, prune cross-references
  user-manual: move quick-start to an appendix
  Documentation: remove howto's now incorporated into manual
  user-manual: move howto/make-dist.txt into user manual
  user-manual: move howto/using-topic-branches into manual
  user-manual: add a "counting commits" example
  user-manual: introduce git
  user-manual: listing commits reachable from some refs not others
  user-manual: reorganize public git repo discussion

 Johannes Schindelin (1):
  Add a birdview-on-the-source-code section to the user manual

 Junio C Hamano (1):
  GIT v1.5.1.5

 Matthias Kestenholz (2):
  Documentation: Added [verse] to SYNOPSIS where necessary
  Documentation: Reformatted SYNOPSIS for several commands

 Michael Hendricks (2):
  git-send-email: allow leading white space on mutt aliases
  Document core.excludesfile for git-add

 Petr Baudis (1):
  Documentation: git-rev-list's "patterns"


* The 'master' branch has these since the last announcement
  in addition to the above.

 Andy Parkins (1):
  Fix crlf attribute handling to match documentation

 Jakub Narebski (2):
  gitweb: Fix error in git_patchset_body for deletion in merge commit
  gitweb: Fix "Use of uninitialized value" warning in git_feed

 Junio C Hamano (3):
  gitweb: fix another use of undefined value
  Add link to 1.5.1.5 release notes.
  Documentation/git.txt: Update links to older documentation pages.

 Petr Baudis (4):
  gitweb: Normalize searchbar font size
  gitweb: Add support for grep searches
  gitweb: Allow arbitrary strings to be dug with pickaxe
  gitweb: Remove redundant $searchtype setup

 René Scharfe (1):
  git-archive: convert archive entries like checkouts do

 Shawn O. Pearce (1):
  git-gui: Gracefully handle bad TCL_PATH at compile time

 Steffen Prohaska (1):
  Optimized cvsexportcommit: calling 'cvs status' once instead of once per touched file.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-05-13 22:30 Junio C Hamano
@ 2007-05-17  0:21 ` Junio C Hamano
  2007-05-19  5:24   ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-05-17  0:21 UTC (permalink / raw)
  To: git

It probably would be more interesting to look at the earlier
"What's not in 1.5.2" messages, but here is the current status
of my tree on the 'stable' front.

I'd expect to have 1.5.1.5 from 'maint' perhaps on Saturday, and
1.5.2 from 'master' hopefully on Sunday if everything goes well.

----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.

 Andy Whitcroft (1):
  git name-rev writes beyond the end of malloc() with large generations

 Frank Lichtenheld (3):
  builtin-log.c: Fix typo in comment
  Documentation: format-patch has no --mbox option
  git-am: Clean up the asciidoc documentation

 Jakub Narebski (1):
  gitweb: Add a few comments about %feature hash

 Jeff King (1):
  format-patch: add MIME-Version header when we add content-type.

 Johannes Schindelin (1):
  import-tars: Use the "Link indicator" to identify directories

 Junio C Hamano (2):
  Fix git-clone buglet for remote case.
  Prepare for 1.5.1.5 Release Notes

 Quy Tonthat (1):
  Documentation/branch: fix small typo in -D example

 Steffen Prohaska (1):
  Fixed link in user-manual


* The 'master' branch has these since the last announcement
  in addition to the above.

 Andy Parkins (1):
  Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs

 Frank Lichtenheld (1):
  cvsserver: Don't send mixed messages to clients

 Jakub Narebski (5):
  gitweb: Fix "Use of unitialized value" warnings in empty repository
  Documentation: Split description of pretty formats of commit log
  gitweb: Do not use absolute font sizes
  gitweb: Separate search regexp from search text
  gitweb: Empty patch for merge means trivial merge, not no differences

 Jeff King (1):
  Documentation/git-add: clarify -u with path limiting

 Johan Herland (2):
  Fix signedness on return value from xread()
  Ensure return value from xread() is always stored into an ssize_t

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-05-13 22:30 Junio C Hamano
  2007-05-17  0:21 ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-05-13 22:30 UTC (permalink / raw)
  To: git

We accumulated quite a few fixes on 'maint' since v1.5.1.4, and
they apply to 'master' as well.

Things that are not in 'master' yet but are scheduled for v1.5.2
final are a performance bug fix for cvsexportcommit (in 'pu')
and user manual updates to add a bit of source code tour, which
hopefully would happen by the middle of the week, and then we
will have the final v1.5.2 next weekend.

----------------------------------------------------------------

* The 'maint' branch has these fixes since v1.5.1.4

 Alex Riesen (1):
  Allow fetching references from any namespace

 Eric Wong (4):
  git-svn: don't drop the username from URLs when dcommit is run
  git-svn: clean up caching of SVN::Ra functions
  git-svn: fix segfaults due to initial SVN pool being cleared
  git-svn: don't attempt to minimize URLs by default

 Jan Hudec (1):
  Updated documentation of hooks in git-receive-pack.

 Jari Aalto (1):
  SPECIFYING RANGES typo fix: it it => it is

 Junio C Hamano (4):
  git-clone: don't get fooled by $PWD
  .mailmap: add some aliases
  checkout: allow detaching to HEAD even when switching to the tip of a branch
  git-config: do not forget seeing "a.b.var" means we are out of "a.var" section.

 Marco Costalba (1):
  Fix an unmatched comment end in arm/sha1_arm.S

 Matthieu Castet (1):
  Remove stale non-static-inline prototype for tree_entry_extract()

 Quy Tonthat (1):
  RPM spec: include files in technical/ to package.

 Richard P. Curnow (2):
  Fix documentation of tag in git-fast-import.txt
  Fix documentation of tag in git-fast-import.txt

 Shawn O. Pearce (1):
  Properly handle '0' filenames in import-tars

 Steffen Prohaska (2):
  tiny fix in documentation of git-clone
  git-config: test for 'do not forget "a.b.var" ends "a.var" section'.


* The 'master' branch has these since v1.5.2-rc3, in addition to the above.

 Frank Lichtenheld (1):
  cvsserver: Limit config parser to needed options

 Jakub Narebski (2):
  gitweb: Test if $from_id and $to_id are defined before comparison
  gitweb: Check if requested object exists

 Jan Hudec (1):
  Minor fixup to documentation of hooks in git-receive-pack.

 Jeff King (1):
  git-add: allow path limiting with -u

 Junio C Hamano (5):
  Minor copyediting on Release Notes for 1.5.2
  Add has_symlink_leading_path() function.
  apply: do not get confused by symlinks in the middle
  read-tree -m -u: avoid getting confused by intermediate symlinks.
  Link to HTML version of external doc if available

 Junio Hamano (1):
  t9400: Use the repository config and nothing else.

 Lars Hjemli (1):
  git-archive: don't die when repository uses subprojects

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-05-09  8:46 Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-05-09  8:46 UTC (permalink / raw)
  To: git

v1.5.1.4 is out.

Thanks to HPA who installed libdbi-dbd interface to sqlite on
kernel.org machines, Frank's cvsserver tests are now in
'master', along with updates to gitweb and git-gui.  I've thrown
in the diff-tree memory optimization we discussed in the OOo
thread as well.

I haven't tagged the tip of the 'master', but this is pretty
much 1.5.2-rc3 -- I may tag it tomorrow with a few more fixes I
noticed are needed while I was reviewing the list traffic (I
updated todo:TODO with them).

v1.5.2 final is scheduled for sometime late next week, hopefully
with git-gui v0.7.0 final.

----------------------------------------------------------------

* The 'maint' branch is now at 1.5.1.4, with these fixes since
  the last announcement.

 Amos Waterland (1):
  wcwidth redeclaration

 J. Bruce Fields (7):
  user-manual: more discussion of detached heads, fix typos
  user-manual: add section ID's
  user-manual: clean up fast-forward and dangling-objects sections
  user-manual: fix .gitconfig editing examples
  user-manual: miscellaneous editing
  user-manual: stop deprecating the manual
  user-manual: fix clone and fetch typos

 Jeff King (1):
  Documentation: don't reference non-existent 'git-cvsapplycommit'

 Junio C Hamano (1):
  GIT v1.5.1.4

 Paul Mackerras (1):
  gitk: Allow user to choose whether to see the diff, old file, or new file

 Quy Tonthat (1):
  Add howto files to rpm packages.

 Shawn O. Pearce (1):
  git-gui: Allow spaces in path to 'wish'


* The 'master' branch has these since the last announcement
  in addition to the above.

 Alex Riesen (1):
  Use GIT_OBJECT_DIR for temporary files of pack-objects

 Frank Lichtenheld (1):
  cvsserver: Add test cases for git-cvsserver

 Jakub Narebski (6):
  gitweb: Add parsing of raw combined diff format to parse_difftree_raw_line
  gitweb: Add combined diff support to git_difftree_body
  gitweb: Add combined diff support to git_patchset_body
  gitweb: Make it possible to use pre-parsed info in git_difftree_body
  gitweb: Show combined diff for merge commits in 'commitdiff' view
  gitweb: Show combined diff for merge commits in 'commit' view

 Junio C Hamano (5):
  diff: release blobs after generating textual diff.
  diff.c: do not use a separate "size cache".
  diff -M: release the preimage candidate blobs after rename detection.
  diff -S: release the image after looking for needle in it
  Update documentation links to point at 1.5.1.4

 Matthieu Moy (2):
  Document git add -u introduced earlier.
  Added a reference to git-add in the documentation for git-update-index

 Michael Spang (3):
  dir.c: Omit non-excluded directories with dir->show_ignored
  t7300: Basic tests for git-clean
  Fix minor documentation errors

 Shawn O. Pearce (17):
  git-gui: Correctly handle UTF-8 encoded commit messages
  git-gui: Include the subject in the status bar after commit
  git-gui: Warn users before making an octopus merge
  git-gui: Correct line wrapping for too many branch message
  git-gui: Cleanup common font handling for font_ui
  git-gui: Use option database defaults to set the font
  git-gui: Refactor to use our git proc more often
  git-gui: Track our own embedded values and rebuild when they change
  git-gui: Refactor into multiple files to save my sanity
  git-gui: Move console procs into their own namespace
  git-gui: Allow vi keys to scroll the diff/blame regions
  git-gui: Move merge support into a namespace
  git-gui: Show all possible branches for merge
  git-gui: Include commit id/subject in merge choices
  git-gui: Use vi-like keys in merge dialog
  Remove duplicate exports from Makefile
  Use .git/MERGE_MSG in cherry-pick/revert

 Theodore Ts'o (2):
  Add pack.depth option to git-pack-objects.
  Increase pack.depth default to 50

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-05-06  8:53           ` Junio C Hamano
  2007-05-07  0:59             ` Jakub Narebski
@ 2007-05-07 13:33             ` Frank Lichtenheld
  1 sibling, 0 replies; 601+ messages in thread
From: Frank Lichtenheld @ 2007-05-07 13:33 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sun, May 06, 2007 at 01:53:19AM -0700, Junio C Hamano wrote:
> GIT v1.5.2 Release Notes (draft)
> ========================
[...]
>   to be handled with caution (do not use it unless you
>   understand the earlier mailing list discussion on keyward
>   expansion).

I guess that should be "keyword"

Gruesse,
-- 
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-05-06  8:53           ` Junio C Hamano
@ 2007-05-07  0:59             ` Jakub Narebski
  2007-05-07 13:33             ` Frank Lichtenheld
  1 sibling, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2007-05-07  0:59 UTC (permalink / raw)
  To: git

Junio C Hamano wrote:

>   - "git diff $commit1:$path2 $commit2:$path2" can now report
>     mode changes between the two blobs.

I think that actually it is enough to have $tree1:$path1 $tree2:$path2
(and it should be $commit1:$path1 not $path2 nevertheless).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-04-29 18:33         ` Junio C Hamano
  2007-04-30  4:15           ` J. Bruce Fields
@ 2007-05-06  8:53           ` Junio C Hamano
  2007-05-07  0:59             ` Jakub Narebski
  2007-05-07 13:33             ` Frank Lichtenheld
  1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-05-06  8:53 UTC (permalink / raw)
  To: git

Master is at v1.5.2-rc2; maint is probably ready to produce
v1.5.1.4, but not tonight.

Here are two draft release notes, followed by the usual "What's in"
summaries.

----------------------------------------------------------------

GIT v1.5.1.4 Release Notes (draft)
==========================

Fixes since v1.5.1.3
--------------------

* Bugfixes

  - "git-http-fetch" did not work around a bug in libcurl
    earlier than 7.16 (curl_multi_remove_handle() was broken).

  - "git cvsserver" handles a file that was once removed and
    then added again correctly.

  - import-tars script (in contrib/) handles GNU tar archives
    that contain pathnames longer than 100 bytes (long-link
    extension) correctly.

  - xdelta test program did not build correctly.

  - gitweb sometimes tried incorrectly to apply function to
    decode utf8 twice, resulting in corrupt output.

  - "git blame -C" mishandled text at the end of a group of
    lines.

  - "git log/rev-list --boundary" did not produce output
    correctly without --left-right option.

----------------------------------------------------------------

GIT v1.5.2 Release Notes (draft)
========================

Updates since v1.5.1
--------------------

* Plumbing level subproject support.

  You can include a subdirectory that has an independent git
  repository in your index and tree objects as a
  "subproject".  This plumbing (i.e. "core") level subproject
  support explicitly excludes recursive behaviour.

  The "subproject" entries in the index and trees are
  incompatible with older versions of git.  Experimenting with
  the plumbing level support is encouraged, but be warned that
  unless everybody in your project updates to this release or
  later, using this feature would make your project
  inaccessible by people with older versions of git.

* Plumbing level gitattributes support.

  The gitattributes mechanism allows you to add 'attributes' to
  paths in your project, and affect the way certain git
  operations work.  Currently you can influence if a path is
  considered a binary or text (the former would be treated by
  'git diff' not to produce textual output; the latter can go
  through the line endings conversion process in repositories
  with core.autocrlf set), expand and unexpand '$ident$' keyword
  with blob object name, specify a custom 3-way merge driver,
  and specify a custom diff driver.  You can also apply
  arbitrary filter to contents on check-in/check-out codepath
  but this feature is an extremely sharp-edged razor and needs
  to be handled with caution (do not use it unless you
  understand the earlier mailing list discussion on keyward
  expansion).

* The packfile format now optionally suports 64-bit index.

  This release supports the "version 2" format of the .idx
  file.  This is automatically enabled when a huge packfile
  needs more than 32-bit to express offsets of objects in the
  pack

* New commands and options.

  - "git bisect start" can optionally take a single bad commit and
    zero or more good commits on the command line.

  - "git shortlog" can optionally be told to wrap its output.

  - "subtree" merge strategy allows another project to be merged in as
    your subdirectory.

  - "git format-patch" learned a new --subject-prefix=<string>
    option, to override the built-in "[PATCH]".

  - "git add -u" is a quick way to do the first stage of "git
    commit -a" (i.e. update the index to match the working
    tree); it obviously does not make a commit.

  - "git clean" honors a new configuration, "clean.requireforce".  When
    set to true, this makes "git clean" a no-op, preventing you
    from losing files by typing "git clean" when you meant to
    say "make clean".  You can still say "git clean -f" to
    override this.

  - "git log" family of commands learned --date={local,relative,default}
    option.  --date=relative is synonym to the --relative-date.
    --date=local gives the timestamp in local timezone.

* Updated behavior of existing commands.

  - When $GIT_COMMITTER_EMAIL or $GIT_AUTHOR_EMAIL is not set
    but $EMAIL is set, the latter is used as a substitute.

  - "git diff --stat" shows size of preimage and postimage blobs
    for binary contents.  Earlier it only said "Bin".

  - "git lost-found" shows stuff that are unreachable except
    from reflogs.

  - "git checkout branch^0" now detaches HEAD at the tip commit
    on the named branch, instead of just switching to the
    branch (use "git checkout branch" to switch to the branch,
    as before).

  - "git bisect next" can be used after giving only a bad commit
    without giving a good one (this starts bisection half-way to
    the root commit).  We used to refuse to operate without a
    good and a bad commit.

  - "git push", when pushing into more than one repository, does
    not stop at the first error.

  - "git archive" does not insist you to give --format parameter
    anymore; it defaults to "tar".

  - "git cvsserver" can use backends other than sqlite.

  - "gitview" (in contrib/ section) learned to better support
    "git-annotate".

  - "git diff $commit1:$path2 $commit2:$path2" can now report
    mode changes between the two blobs.

  - Local "git fetch" from a repository whose object store is
    one of the alternates (e.g. fetching from the origin in a
    repository created with "git clone -l -s") avoids
    downloading objects unnecessary.

  - "git blame" uses .mailmap to canonicalize the author name
    just like "git shortlog" does.

* Builds

  - git-p4import has never been installed; now there is an
    installation option to do so.

  - gitk and git-gui can be configured out.

  - Generated documentation pages automatically get version
    information from GIT_VERSION

  - Parallel build with "make -j" descending into subdirectory
    was fixed.

* Performance Tweaks

  - Optimized "git-rev-list --bisect" (hence "git-bisect").

  - Optimized "git-add $path" in a large directory, most of
    whose contents are ignored.

  - The recursive merge strategy updated a worktree file that
    was changed identically in two branches, when one of them
    renamed it.  We do not do that when there is no rename, so
    match that behaviour.

Fixes since v1.5.1
------------------

All of the fixes in v1.5.1 maintenance series are included in
this release, unless otherwise noted.

* Bugfixes

  - Switching branches with "git checkout" refused to work when
    a path changes from a file to a directory between the
    current branch and the new branch, in order not to lose
    possible local changes in the directory that is being turned
    into a file with the switch.  We now allow such a branch
    switch after making sure that there is no locally modified
    file nor un-ignored file in the directory.  This has not
    been backported to 1.5.1.x series, as it is rather an
    intrusive change.

  - Merging branches that have a file in one and a directory in
    another at the same path used to get quite confused.  We
    handle such a case a bit more carefully, even though that is
    still left as a conflict for the user to sort out.  This
    will not be backported to 1.5.1.x series, as it is rather an
    intrusive change.

  - git-fetch had trouble with a remote with insanely large number
    of refs.

  [[[jc: I'll probably copy&paste v1.5.1.X release notes here, or
  refer readers to those separate documents.  I haven't decided
  which way I would go, but I am inclined to do the latter.]]]

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

 Alex Riesen (1):
  Small correction in reading of commit headers

 Alexandre Julliard (1):
  http-fetch: Disable use of curl multi support for libcurl < 7.16.

 Arjen Laarhoven (1):
  Document 'opendiff' value in config.txt and git-mergetool.txt

 Bryan Larsen (2):
  Allow PERL_PATH="/usr/bin/env perl"
  posix compatibility for t4200

 Carl Worth (1):
  Mention version 1.5.1 in tutorial and user-manual

 Daniel Barkalow (1):
  Make xstrndup common

 Frank Lichtenheld (1):
  cvsserver: Handle re-added files correctly

 Ismail Dönmez (1):
  gitweb: use decode_utf8 directly

 Jakub Narebski (1):
  diff format documentation: describe raw combined diff format

 James Bowes (1):
  Documentation: fix typo in git-remote.txt

 Johannes Schindelin (1):
  Teach import-tars about GNU tar's @LongLink extension.

 Junio C Hamano (4):
  diff.c: fix "size cache" handling.
  blame: Notice a wholesale incorporation of an existing file.
  blame: -C -C -C
  Add test for blame corner cases.

 Karl Hasselström (2):
  Fix markup in git-svn man page
  Add --no-rebase option to git-svn dcommit

 Linus Torvalds (1):
  Fix --boundary output

 Martin Koegler (1):
  Fix compilation of test-delta


* The 'master' branch has these since the last announcement
  in addition to the above.

 Alex Riesen (1):
  Handle return code of parse_commit in revision machinery

 Dana L. How (1):
  Create pack-write.c for common pack writing code

 Jonas Fonseca (1):
  git-tag(1): -v option is a subcommand; fix code block

 Junio C Hamano (2):
  blame: use .mailmap unconditionally
  GIT v1.5.2-rc2

 Shawn O. Pearce (3):
  Reuse fixup_pack_header_footer in index-pack
  Don't use seq in tests, not everyone has it
  Improve request-pull to handle non-rebased branches

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-04-30  5:12             ` Junio C Hamano
@ 2007-05-01  3:36               ` J. Bruce Fields
  0 siblings, 0 replies; 601+ messages in thread
From: J. Bruce Fields @ 2007-05-01  3:36 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sun, Apr 29, 2007 at 10:12:42PM -0700, Junio C Hamano wrote:
> Thanks, and absolutely no reason to say sorry.  This is a
> collective volunteer effort and I believe your effort on the
> user's manual so far has already made git much more approachable
> to new people.  It's greatly appreciated.
> 
> Besides, I made it sound as if -rc1 will be blocked, *waiting*
> for these two updates, but it was a mistake; it doesn't have to
> wait and documentation updates and polishes can happen anytime
> before the final.

OK!  I will get back to it soon....

> And contribution from others on the list, especially from people
> with some git virginity still left, to review the user's manual
> would be valuable.

Yep.--b.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-04-30  4:15           ` J. Bruce Fields
@ 2007-04-30  5:12             ` Junio C Hamano
  2007-05-01  3:36               ` J. Bruce Fields
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-04-30  5:12 UTC (permalink / raw)
  To: J. Bruce Fields; +Cc: git

"J. Bruce Fields" <bfields@fieldses.org> writes:

> On Sun, Apr 29, 2007 at 11:33:07AM -0700, Junio C Hamano wrote:
>> Hopefully we will have a handful user-manual updates from JBF
>> and git-gui 0.6.6 from Shawn and have v1.5.2-rc1 soon.
>
> Sorry for the relative silence; I've had a busy couple of weeks keeping
> me away from git, and a backlog of comments.  I'll try to have a few
> things ready tommorow (Monday) night, but nothing earth-shattering.--b.

Thanks, and absolutely no reason to say sorry.  This is a
collective volunteer effort and I believe your effort on the
user's manual so far has already made git much more approachable
to new people.  It's greatly appreciated.

Besides, I made it sound as if -rc1 will be blocked, *waiting*
for these two updates, but it was a mistake; it doesn't have to
wait and documentation updates and polishes can happen anytime
before the final.

And contribution from others on the list, especially from people
with some git virginity still left, to review the user's manual
would be valuable.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-04-29 18:33         ` Junio C Hamano
@ 2007-04-30  4:15           ` J. Bruce Fields
  2007-04-30  5:12             ` Junio C Hamano
  2007-05-06  8:53           ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: J. Bruce Fields @ 2007-04-30  4:15 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sun, Apr 29, 2007 at 11:33:07AM -0700, Junio C Hamano wrote:
> Hopefully we will have a handful user-manual updates from JBF
> and git-gui 0.6.6 from Shawn and have v1.5.2-rc1 soon.

Sorry for the relative silence; I've had a busy couple of weeks keeping
me away from git, and a backlog of comments.  I'll try to have a few
things ready tommorow (Monday) night, but nothing earth-shattering.--b.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-04-27  8:34       ` Junio C Hamano
  2007-04-27  9:19         ` Andy Parkins
@ 2007-04-29 18:33         ` Junio C Hamano
  2007-04-30  4:15           ` J. Bruce Fields
  2007-05-06  8:53           ` Junio C Hamano
  1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-04-29 18:33 UTC (permalink / raw)
  To: git

We would need PerlIO fix for git-svn to handle symlinks on MacOS
properly on 'maint', which is still a known issue.  With that
I'll do a v1.5.1.3.

In addition to a few more new features recently discussed, and
of course a lot of fixes that came in the last couple of days,
I've merged the "give them rope" conversion series to 'master'.
Hopefully we will have a handful user-manual updates from JBF
and git-gui 0.6.6 from Shawn and have v1.5.2-rc1 soon.

* The 'maint' branch has these fixes since the last announcement.

 Adam Roben (1):
  git-svn: Added 'find-rev' command

 Johannes Schindelin (1):
  import-tars: be nice to wrong directory modes

 Josh Triplett (1):
  Add missing reference to GIT_COMMITTER_DATE in git-commit-tree documentation

 Julian Phillips (1):
  http.c: Fix problem with repeated calls of http_init

 Junio C Hamano (3):
  Do not barf on too long action description
  Update .mailmap with "Michael"
  Fix import-tars fix.

 Michele Ballabio (1):
  git shortlog documentation: add long options and fix a typo

 Shawn O. Pearce (2):
  Don't allow empty pathnames in fast-import
  Catch empty pathnames in trees during fsck


* The 'master' branch has these since the last announcement
  in addition to the above.

 Josh Triplett (1):
  Fall back to $EMAIL for missing GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL

 Junio C Hamano (7):
  Add 'ident' conversion.
  Add 'filter' attribute and external filter driver definition.
  blame -s: suppress author name and time.
  Split out mailmap handling out of shortlog
  Apply mailmap in git-blame output.
  Make macros to prevent double-inclusion in headers consistent.
  Make sure test-genrandom and test-chmtime are builtas part of the main build.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-04-27 18:03             ` Andy Parkins
@ 2007-04-27 18:12               ` Linus Torvalds
  0 siblings, 0 replies; 601+ messages in thread
From: Linus Torvalds @ 2007-04-27 18:12 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git, Junio C Hamano



On Fri, 27 Apr 2007, Andy Parkins wrote:
> 
> I was actually surprised how little I'm finding I need submodule support 
> in the porcelain.  The only slight problem at the moment is with 
> git-checkout; switching from a branch with the supermodule to a branch 
> without it and back needs a bit of hoop jumping, but nothing too 
> painful.  All in all - success all over.

Heh, good to hear, but I suspect your habits may differ from other 
peoples...

I agree that "git checkout" needs to have that .gitmodules thing. It 
should actually be fairly straightforward, although there are subtle 
issues (ie right now we can *atomically* say "cannot check out, it's 
dirty" - what happens when you've already checked out five subprojects, 
and the sixth one is dirty?).

"git diff --subprojects" is likely also something people will want, and 
that should be _reasonably_ straigtforward.

"git merge" is the big one. 

		Linus

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-04-27 17:11           ` Linus Torvalds
@ 2007-04-27 18:03             ` Andy Parkins
  2007-04-27 18:12               ` Linus Torvalds
  0 siblings, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2007-04-27 18:03 UTC (permalink / raw)
  To: git; +Cc: Linus Torvalds, Junio C Hamano

On Friday 2007, April 27, Linus Torvalds wrote:

> I'm personally really really sure. The whole point of subprojects (at

Fair enough.  I just hadn't seen very much talk about this issue and 
wanted to make sure.

> trouble with the new feature: at a minimum, git-fsck would always
> complain about the invalid mode (and things like "git diff" would too
> - I think it used to just die on unknown modes).

That kind of settles it really - if neither implementation would have 
worked with non-submodule git then the decision must come down to which 
is technically better - and I'm persuaded that the extra layer of 
indirection doesn't actually gain anything other than some extra 
objects to track.

>  - with 1.5.2, git will be good enough to _serve_ stuff, even if it
> might not be very usable for the client-side operations. So

>From my point of view, I don't really mind manually fetching the 
submodules.  I very much appreciate that I don't _have_ to have the 
submodules for the superproject to continue to work.

I was actually surprised how little I'm finding I need submodule support 
in the porcelain.  The only slight problem at the moment is with 
git-checkout; switching from a branch with the supermodule to a branch 
without it and back needs a bit of hoop jumping, but nothing too 
painful.  All in all - success all over.


Andy

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-04-27  9:19         ` Andy Parkins
  2007-04-27 14:01           ` Nicolas Pitre
@ 2007-04-27 17:11           ` Linus Torvalds
  2007-04-27 18:03             ` Andy Parkins
  1 sibling, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2007-04-27 17:11 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git, Junio C Hamano



On Fri, 27 Apr 2007, Andy Parkins wrote:
> 
> Let's be really, really sure.  I'm not sure a big enough fuss has been made of 
> the fact that this is a change of repository format.  Before this you could 
> pretty much access any repository with any version.

I'm personally really really sure. The whole point of subprojects (at 
least the way _I_ envisioned them) was to have them point to objects 
outside the same repository, so it's more than just an implementation 
detail, it's very much design.

And yes, of course we could have made it point to a blob inside the 
superproject, and have that blob then contain a SHA1 that old versions of 
git wouldn't have known to follow. But that would have been pretty hacky, 
and old versions of git would _still_ have had trouble with the new 
feature: at a minimum, git-fsck would always complain about the invalid 
mode (and things like "git diff" would too - I think it used to just die 
on unknown modes).

The "git-fsck/diff not working" thing might be seen as something that 
isn't important on the server side, but I think it ends up being critial, 
both for gitweb, and simply because I'd expect server side to want to 
verify the projects they export too. So I do think you'd want to have a 
recent git to support recent featurs.

So I think it boils down to: 
 - old git versions will obviously happily continue to  export all normal 
   repositories (including the submodules themselves).
 - but the actual supermodule support for embedding those submodules 
   really is a fundamentally new linkage, and if you want to use 
   supermodules, you have to have a recent enough git. Even if it's just 
   exporting them.
 - with 1.5.2, git will be good enough to _serve_ stuff, even if it might 
   not be very usable for the client-side operations. So especially since 
   there won't be a whole lot of users (due to the client limitations), I 
   think it's fine to expect a "sufficiently capable" git version if you 
   start serving subproject content.

But, yeah, this is just my personal view of sub/superproject support, and 
I've never actually _used_ it myself apart from my small test-repo thing.

		Linus

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-04-27 14:01           ` Nicolas Pitre
@ 2007-04-27 15:21             ` Andy Parkins
  0 siblings, 0 replies; 601+ messages in thread
From: Andy Parkins @ 2007-04-27 15:21 UTC (permalink / raw)
  To: git; +Cc: Nicolas Pitre, Junio C Hamano

On Friday 2007 April 27, Nicolas Pitre wrote:

> I think it is reasonable to say that if you intend to work with a repo
> that contains references to submodules, then you need to upgrade your
> Git version.  It is not like if the Git licensing fees are really
> prohibitive.

:-)  Absolutely.

The case I was thinking about was when the server hosting your project doesn't 
have submodule support and isn't under your direct control.  For example: 
kernel.org and repo.or.cz.  The same is true for those people for whom the IT 
department manage their central server, and aren't very helpful.

In those cases, that repository is being used as storage, it's bare, doesn't 
have an index and doesn't ever checkout the files.  If submodule support were 
capable of being stored (not checked out) by an older git, then people can 
use submodules merely if they have support on the client side.

There's also the distributions to think about - taking Debian as an example - 
a lot of people stick with stable only (especially for servers) - and stable 
is stuck with 1.4.4.4.  It's going to be a long time before a 
submodule-capable git hits Debian stable.



Andy

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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-04-27  9:19         ` Andy Parkins
@ 2007-04-27 14:01           ` Nicolas Pitre
  2007-04-27 15:21             ` Andy Parkins
  2007-04-27 17:11           ` Linus Torvalds
  1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2007-04-27 14:01 UTC (permalink / raw)
  To: Andy Parkins; +Cc: git, Junio C Hamano

On Fri, 27 Apr 2007, Andy Parkins wrote:

> I am still concerned about the submodule thing - once we push a mainline 
> version out with the format decided, that will be that and we'll be stuck 
> with it.  Are we _really_ sure that it's right to have a non-object hash in 
> the tree objects?
> 
> It's a fundamental change in the form of the tree: at the moment every hash in 
> the tree object represents another object in the same repository; with 
> gitlink as it is, that convention is broken.
> 
> Let's be really, really sure.  I'm not sure a big enough fuss has been made of 
> the fact that this is a change of repository format.  Before this you could 
> pretty much access any repository with any version.

I think it is reasonable to say that if you intend to work with a repo 
that contains references to submodules, then you need to upgrade your 
Git version.  It is not like if the Git licensing fees are really 
prohibitive.


Nicolas

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-04-27  8:34       ` Junio C Hamano
@ 2007-04-27  9:19         ` Andy Parkins
  2007-04-27 14:01           ` Nicolas Pitre
  2007-04-27 17:11           ` Linus Torvalds
  2007-04-29 18:33         ` Junio C Hamano
  1 sibling, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2007-04-27  9:19 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

On Friday 2007 April 27, Junio C Hamano wrote:
> We've accumulated quite a bit of fixes on 'maint', so I need to
> do a 1.5.1.3 release soonish, as we will go into feature freeze
> on 'master' shortly in preparation for 1.5.2.

I am still concerned about the submodule thing - once we push a mainline 
version out with the format decided, that will be that and we'll be stuck 
with it.  Are we _really_ sure that it's right to have a non-object hash in 
the tree objects?

It's a fundamental change in the form of the tree: at the moment every hash in 
the tree object represents another object in the same repository; with 
gitlink as it is, that convention is broken.

Let's be really, really sure.  I'm not sure a big enough fuss has been made of 
the fact that this is a change of repository format.  Before this you could 
pretty much access any repository with any version.


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

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-04-23  7:04     ` Junio C Hamano
@ 2007-04-27  8:34       ` Junio C Hamano
  2007-04-27  9:19         ` Andy Parkins
  2007-04-29 18:33         ` Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-04-27  8:34 UTC (permalink / raw)
  To: git

We've accumulated quite a bit of fixes on 'maint', so I need to
do a 1.5.1.3 release soonish, as we will go into feature freeze
on 'master' shortly in preparation for 1.5.2.

On the 'master' front, things have been stabilizing.  Modulo
documentation updates and bugfixes, I expect what we have here
tonight will be pretty much what the final 1.5.2 would look
like.  I already know Shawn has plans to feed git-gui 0.6.6
updates, which should also be included in the final one.

But I might have missed or dismissed patches we have seen and
reviewed on the list recently that deserve to be in 1.5.2, so
please raise hand if you see something missing.  After that,
I'll tag v1.5.2-rc1 and from there we will do the usual "no new
features, options, commands -- only fixes", which hopefully will
happen on Monday.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

 Adam Roben (3):
  Remove usernames from all commit messages, not just when using svmprops
  git-svn: Don't rely on $_ after making a function call
  git-svn: Ignore usernames in URLs in find_by_url

 Alex Riesen (1):
  Fix handle leak in write_tree

 Andrew Ruder (8):
  Removing -n option from git-diff-files documentation
  Document additional options for git-fetch
  Update git-fmt-merge documentation
  Update git-grep documentation
  Update -L documentation for git-blame/git-annotate
  Update git-http-push documentation
  Update git-local-fetch documentation
  Update git-http-fetch documentation

 Brian Gernhardt (2):
  Reverse the order of -b and --track in the man page.
  Ignore all man sections as they are generated files.

 Gerrit Pape (1):
  Documentation/git-reset.txt: suggest git commit --amend in example.

 Johannes Schindelin (1):
  dir.c(common_prefix): Fix two bugs

 Josh Triplett (2):
  Fix typo in git-am: s/Was is/Was it/
  Create a sysconfdir variable, and use it for ETC_GITCONFIG

 Junio C Hamano (3):
  Build RPM with ETC_GITCONFIG=/etc/gitconfig
  applymbox & quiltimport: typofix.
  Start preparing for 1.5.1.3

 Robin H. Johnson (10):
  Document --dry-run parameter to send-email.
  Prefix Dry- to the message status to denote dry-runs.
  Debugging cleanup improvements
  Change the scope of the $cc variable as it is not needed outside of send_message.
  Perform correct quoting of recipient names.
  Validate @recipients before using it for sendmail and Net::SMTP.
  Ensure clean addresses are always used with Net::SMTP
  Allow users to optionally specify their envelope sender.
  Document --dry-run and envelope-sender for git-send-email.
  Sanitize @to recipients.

 Shawn O. Pearce (1):
  Actually handle some-low memory conditions


* The 'master' branch has these since the last announcement
  in addition to the above.

 Alex Riesen (3):
  Avoid excessive rewrites in merge-recursive
  Add a test for merging changed and rename-changed branches
  Ignore merged status of the file-level merge

 Andy Parkins (3):
  post-receive-email example hook: fastforward should have been fast_forward
  post-receive-email example hook: detect rewind-only updates and output sensible message
  post-receive-email example hook: sed command for getting description was wrong

 Johannes Schindelin (1):
  t4201: Do not display weird characters on the terminal

 Josh Triplett (1):
  Add clean.requireForce option, and add -f option to git-clean to override it

 Junio C Hamano (9):
  Move index-related variables into a structure.
  Make read-cache.c "the_index" free.
  Document "diff=driver" attribute
  t5302: avoid using tail -c
  t6030: grab commit object name as we go
  Diff between two blobs should take mode changes into account now.
  t/test-lib.sh: Protect ourselves from common misconfiguration
  gitattributes documentation: clarify overriding
  Add --date={local,relative,default}

 Luiz Fernando N. Capitulino (5):
  remove_subtree(): Use strerror() when possible
  entry.c: Use const qualifier for 'struct checkout' parameters
  read_cache_from(): small simplification
  core-tutorial: minor fixes
  init_buffer(): Kill buf pointer

 Martin Koegler (5):
  Add S_IFINVALID mode
  add get_sha1_with_mode
  add add_object_array_with_mode
  store mode in rev_list, if <tree>:<filename> syntax is used
  use mode of the tree in git-diff, if <tree>:<file> syntax is used

 Nicolas Pitre (1):
  add file checkout progress

 OGAWA Hirofumi (1):
  git-fetch: Fix "argument list too long"

 Sami Farin (1):
  fast-import: size_t vs ssize_t

 Shawn O. Pearce (1):
  Don't repack existing objects in fast-import

 Uwe Kleine-König (1):
  fix importing of subversion tars

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-04-22  6:22   ` Junio C Hamano
@ 2007-04-23  7:04     ` Junio C Hamano
  2007-04-27  8:34       ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-04-23  7:04 UTC (permalink / raw)
  To: git

Together with fixes to pack-objects mode bits gotcha that caused
quite a traffic on the list this morning, and crlf conversion
bug from Alex, I've fast-tracked a few topics to 'master' tonight:

 - Nico's progress meter clean-up.
 - My custom diff driver in gitattributes series.

By "fast-track", I mean there might still be bugs in the code
but there do not seem to be anything contentious in the design,
and I trust the people who can fix possible breakages are
responsive.  I think "ident" attribute to expand "$ident$" in
blobs is probably less controversial as it is a stateless
transformation, but I left it out for now.

The tip of 'master' tonight is v1.5.2-rc0.  I am reasonably sure
that I have missed a few topics that we saw/reviewed patches for
the past several days.  Please do not get discouraged as I have
not necessarily rejected them; I was just busy whipping v1.5.1.2
and the 'master' branch into shape tonight.  Please discuss the
patches that are missing from tonight's 'master' for possible
inclusion in the coming few days, and then let's declare feature
freeze by the end of the week with v1.5.2-rc1.  After that, the
usual rules for stabilization period applies (no new features,
only fixes including documentation updates).

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

 Alex Riesen (2):
  Fix a typo in crlf conversion code
  Fix crash in t0020 (crlf conversion)

 Junio C Hamano (8):
  Update documentation links to point at v1.5.1.2
  Documentation/Makefile: fix section (5) installation
  Update draft release notes for v1.5.2
  pack-objects: quickfix for permission modes.
  Fix 'quickfix' on pack-objects.
  Update tests not to assume that generated packfiles are writable.
  pack-objects: make generated packfile read-only
  Support 'diff=pgm' attribute

 Martin Koegler (1):
  gitweb: Show "no difference" message for empty diff

 Nicolas Pitre (4):
  common progress display support
  make progress "title" part of the common progress interface
  provide a facility for "delayed" progress reporting
  delay progress display when checking out files

 Shawn O. Pearce (1):
  Cleanup variables in cat-file

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-04-18 23:58 ` Junio C Hamano
@ 2007-04-22  6:22   ` Junio C Hamano
  2007-04-23  7:04     ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-04-22  6:22 UTC (permalink / raw)
  To: git

The latest maintenance release v1.5.1.2 is out.

Tonight's 'master' contains 64-bit index, core subproject
support, and gitattributes (but not the controversial "filter"
part).  As I promised I'd do something about attributes some
time ago (I think it was during v1.5.1 stabilization period), I
am reasonably happy with the state of 'master' right now.  The
other two major topics are also nice, unexpected bonus toward
v1.5.2 from my point of view.

Please expect stabilization cycle for v1.5.2 to start soon.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last
  announcement; these are all contained in v1.5.1.2, the latest
  maintenance release.

 Andrew Ruder (4):
  Update git-archive documentation
  Update git-cherry-pick documentation
  Fix unmatched emphasis tag in git-tutorial
  Update git-config documentation

 Andy Whitcroft (1):
  fix up strtoul_ui error handling

 Eric Wong (1):
  perl: install private Error.pm if the site version is older than our own

 Junio C Hamano (2):
  git-clone: fix dumb protocol transport to clone from pack-pruned ref
  GIT 1.5.1.2

 Sam Vilain (1):
  git-tar-tree: complete deprecation conversion message


* The 'master' branch has these since the last announcement
  in addition to the above.

 Alex Riesen (2):
  Tests for core subproject support
  Simplify calling of CR/LF conversion routines

 Alexandre Julliard (1):
  git.el: Add a commit description to the reflog.

 Aneesh Kumar K.V (1):
  gitview: annotation support

 Brian Gernhardt (1):
  Remove case-sensitive file in t3030-merge-recursive.

 James Bowes (1):
  Document git-check-attr

 Julian Phillips (1):
  refs.c: add a function to sort a ref list, rather then sorting on add

 Junio C Hamano (30):
  git-fetch--tool pick-rref
  git-fetch: use fetch--tool pick-rref to avoid local fetch from alternate
  Add basic infrastructure to assign attributes to paths
  Define 'crlf' attribute.
  Teach 'diff' about 'diff' attribute.
  Fix 'crlf' attribute semantics.
  Fix 'diff' attribute semantics.
  Makefile: add patch-ids.h back in.
  attribute macro support
  Define a built-in attribute macro "binary".
  Change attribute negation marker from '!' to '-'.
  Make sure quickfetch is not fooled with a previous, incomplete fetch.
  Allow more than true/false to attributes.
  merge-recursive: separate out xdl_merge() interface.
  Allow specifying specialized merge-backend per path.
  Add a demonstration/test of customized merge.
  Custom low-level merge driver support.
  Allow the default low-level merge driver to be configured.
  Custom low-level merge driver: change the configuration scheme.
  Allow low-level driver to specify different behaviour during internal merge.
  Fix funny types used in attribute value representation
  Counto-fix in merge-recursive
  Simplify code to find recursive merge driver.
  Documentation: support manual section (5) - file formats.
  Update 'crlf' attribute semantics.
  Document gitattributes(5)
  git-add -u: match the index with working tree.
  Fix bogus linked-list management for user defined merge drivers.
  convert.c: restructure the attribute checking part.
  lockfile: record the primary process.

 Linus Torvalds (21):
  diff-lib: use ce_mode_from_stat() rather than messing with modes manually
  Avoid overflowing name buffer in deep directory structures
  Add 'resolve_gitlink_ref()' helper function
  Add "S_IFDIRLNK" file mode infrastructure for git links
  Teach "fsck" not to follow subproject links
  Teach core object handling functions about gitlinks
  Fix thinko in subproject entry sorting
  Teach directory traversal about subprojects
  Teach git-update-index about gitlinks
  Don't show gitlink directories when we want "other" files
  Teach git list-objects logic not to follow gitlinks
  Teach "git-read-tree -u" to check out submodules as a directory
  Fix gitlink index entry filesystem matching
  Teach git list-objects logic to not follow gitlinks
  Teach "git-read-tree -u" to check out submodules as a directory
  Fix some "git ls-files -o" fallout from gitlinks
  Expose subprojects as special files to "git diff" machinery
  Use proper object allocators for unknown object nodes too
  Clean up object creation to use more common code
  Fix working directory errno handling when unlinking a directory
  Fix a copy-n-paste bug in the object decorator code.

 Nicolas Pitre (27):
  get rid of num_packed_objects()
  make overflow test on delta base offset work regardless of variable size
  add overflow tests on pack offset variables
  compute a CRC32 for each object as stored in a pack
  compute object CRC32 with index-pack
  pack-objects: learn about pack index version 2
  index-pack: learn about pack index version 2
  sha1_file.c: learn about index version 2
  show-index.c: learn about index v2
  pack-redundant.c: learn about index v2
  allow forcing index v2 and 64-bit offset treshold
  validate reused pack data with CRC when possible
  simple random data generator for tests
  use test-genrandom in tests instead of /dev/urandom
  tests for various pack index features
  clean up add_object_entry()
  pack-objects: optimize preferred base handling a bit
  pack-objects: equal objects in size should delta against newer objects
  pack-objects: rework check_delta_limit usage
  pack-objects: clean up list sorting
  pack-objects: get rid of reuse_cached_pack
  pack-objects: get rid of create_final_object_list()
  pack-objects: make in_pack_header_size a variable of its own
  add get_size_from_delta()
  pack-objects: better check_object() performances
  pack-objects: remove obsolete comments
  document --index-version for index-pack and pack-objects

 Shawn O. Pearce (2):
  Contribute a fairly paranoid update hook
  Kill the useless progress meter in merge-recursive

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-04-16  1:27 Junio C Hamano
@ 2007-04-18 23:58 ` Junio C Hamano
  2007-04-22  6:22   ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-04-18 23:58 UTC (permalink / raw)
  To: git

Accumulated fixes on 'maint' are mostly documentation updates.
I will do a 1.5.1.2 probably this weekend, when I find time.

On 'master' are Frank's cvsserver updates to use DBI to allow
backends other than sqlite.  There also is an update to
merge-recursive to make it saner for merges that involves a
directory changing to a file (or vice versa).

I did not hear anything positive nor negative while they were on
'next', so if you have been using cvsserver or merge and this
breaks them for you, you had it coming.  At least you can keep
both pieces ;-).

But more seriously, hopefully no news was a good news.  There
are also other minor new features and enhancements on 'master'.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

 Alex Riesen (1):
  Fix overwriting of files when applying contextually independent diffs

 Andrew Ruder (4):
  Update git-am documentation
  Update git-applymbox documentation
  Update git-apply documentation
  Update git-annotate/git-blame documentation

 Carlos Rica (1):
  Use const qualifier for 'sha1' parameter in delete_ref function

 Eric Wong (3):
  git-svn: respect lower bound of -r/--revision when following parent
  git-svn: quiet some warnings when run only with --version/--help
  git-svn: don't allow globs to match regular files

 Frank Lichtenheld (1):
  git-shortlog: Fix two formatting errors in asciidoc documentation

 Gerrit Pape (2):
  variable $projectdesc needs to be set before checking against unchanged default.
  Have sample update hook not refuse deleting a branch through push.

 J. Bruce Fields (7):
  Documentation: minor edits of git-lost-found manpage
  Documentation: clarify git-checkout -f, minor editing
  Documentation: clarify track/no-track option.
  user-manual: fix discussion of default clone
  user-manual: detached HEAD
  user-manual: start revising "internals" chapter
  user-manual: use detached head when rewriting history

 Junio C Hamano (1):
  Start preparing for 1.5.1.2

 Shawn O. Pearce (1):
  git-gui: Brown paper bag fix division by 0 in blame


* The 'master' branch has these since the last announcement
  in addition to the above.

 Alex Riesen (2):
  Fix t4201: accidental arithmetic expansion
  Fix permissions on test scripts

 Andrew Ruder (1):
  Add policy on user-interface changes

 Christian Couder (2):
  Bisect: simplify "bisect start" logging.
  Bisect: rename "t/t6030-bisect-run.sh" to "t/t6030-bisect-porcelain.sh".

 Eygene Ryabinkin (4):
  Allow wish interpreter to be defined with TCLTK_PATH
  Teach git-gui to use the user-defined UI font everywhere.
  Improve look-and-feel of the git-gui tool.
  Do not break git-gui messages into multiple lines.

 Frank Lichtenheld (12):
  cvsserver: Introduce new state variable 'method'
  cvsserver: Handle three part keys in git config correctly
  cvsserver: Allow to override the configuration per access method
  cvsserver: Make the database backend configurable
  cvsserver: Abort if connect to database fails
  cvsserver: Use DBI->table_info instead of DBI->tables
  cvsserver: Corrections to the database backend configuration
  cvsserver: Add asciidoc documentation for new database backend configuration
  cvsserver: Allow to "add" a removed file
  cvsserver: Reword documentation on necessity of write access
  cvsserver: Document the GIT branches -> CVS modules mapping more prominently
  config.txt: Add gitcvs.db* variables

 Johannes Schindelin (1):
  Use print_wrapped_text() in shortlog

 Junio C Hamano (9):
  shortlog -w: make wrap-line behaviour optional.
  t1000: fix case table.
  Treat D/F conflict entry more carefully in unpack-trees.c::threeway_merge()
  merge-recursive: do not barf on "to be removed" entries.
  merge-recursive: handle D/F conflict case more carefully.
  t3030: merge-recursive backend test.
  send-email: do not leave an empty CC: line if no cc is present.
  git-gui: Honor TCLTK_PATH if supplied
  Update draft release notes for 1.5.2 with accumulated changes.

 Linus Torvalds (2):
  Add a generic "object decorator" interface, and make object refs use it
  Add support for "commit name decorations" to log family of commands

 Michael S. Tsirkin (1):
  Display the subject of the commit just made.

 Shawn O. Pearce (3):
  Always bind the return key to the default button
  git-gui: Display the directory basename in the title
  Revert "Allow wish interpreter to be defined with TCLTK_PATH"

 Steven Grimm (3):
  Add --quiet option to suppress output of "rm" commands for removed files.
  git-rm: Trivial fix for a comment typo.
  Add --ignore-unmatch option to exit with zero status when no files are removed.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-04-16  1:27 Junio C Hamano
  2007-04-18 23:58 ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-04-16  1:27 UTC (permalink / raw)
  To: git

Perhaps we would need 1.5.1.2 to push out a few accumulated
small fixes on 'maint'.

----------------------------------------------------------------

* The 'maint' branch has these fixes since v1.5.1.1.

 Alex Riesen (2):
  Use rev-list --reverse in git-rebase.sh
  Document -g (--walk-reflogs) option of git-log

 Eygene Ryabinkin (2):
  Teach gitk to use the user-defined UI font everywhere.
  Improve look-and-feel of the gitk tool.

 Frank Lichtenheld (4):
  config.txt: Document gitcvs.allbinary
  config.txt: Document core.autocrlf
  config.txt: Change pserver to server in description of gitcvs.*
  config.txt: Fix grammatical error in description of http.noEPSV

 Jim Meyering (1):
  sscanf/strtoul: parse integers robustly

 Junio C Hamano (1):
  Do not default to --no-index when given two directories.

 Linus Torvalds (1):
  git-quiltimport complaining yet still working

 Matthias Lederhofer (1):
  handle_options in git wrapper miscounts the options it handled.

 Michael Spang (1):
  git-blame: Fix overrun in fake_working_tree_commit()


* The 'master' branch has these since the last announcement
  in addition to the above.

 Frank Lichtenheld (2):
  gitweb: Allow forks with project list file
  gitweb: Allow configuring the default projects order and add order 'none'

 Jim Meyering (1):
  sscanf/strtoul: parse integers robustly

 Junio C Hamano (5):
  Add %m to '--pretty=format:'
  Refactor patch-id filtering out of git-cherry and git-format-patch.
  git-log --cherry-pick A...B
  Documentation: --cherry-pick
  Fix git {log,show,...} --pretty=email

 Luiz Fernando N. Capitulino (2):
  ident.c: Use const qualifier for 'struct passwd' parameters
  ident.c: Use size_t (instead of int) to store sizes

 René Scharfe (1):
  git-archive: make tar the default format

 Robin H. Johnson (2):
  Add custom subject prefix support to format-patch (take 3)
  Add testcase for format-patch --subject-prefix (take 3)

 Shawn O. Pearce (1):
  Don't yap about merge-subtree during make

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-04-09  8:17 Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-04-09  8:17 UTC (permalink / raw)
  To: git

Maybe will do 1.5.1.1 on Wednesday with the accumulated fixes on
'maint'.

The 'master' has a few topics merged from 'next':

 - Christian Couder's "git bisect" improvements.
 - Fernando J Perada's parallel make fix.
 - Andy Parkins's "git diff --stat" for binary files.
 - Shawn Pearce's "git lost-found" that ignores reflog.
 - Switching between two branches that have D/F conflicts.
 - "git merge -s subtree".

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

 Arjen Laarhoven (4):
  usermanual.txt: some capitalization nits
  t3200-branch.sh: small language nit
  t5300-pack-object.sh: portability issue using /usr/bin/stat
  Makefile: iconv() on Darwin has the old interface

 Brian Gernhardt (2):
  Document --left-right option to rev-list.
  Distinguish branches by more than case in tests.

 Dana How (1):
  Fix lseek(2) calls with args 2 and 3 swapped

 Eric Wong (3):
  git-svn: bail out on incorrect command-line options
  git-svn: dcommit/rebase confused by patches with git-svn-id: lines
  git-svn: fix log command to avoid infinite loop on long commit messages

 Frank Lichtenheld (6):
  cvsimport: sync usage lines with existing options
  cvsimport: Improve documentation of CVSROOT and CVS module determination
  cvsimport: Improve usage error reporting
  cvsimport: Reorder options in documentation for better understanding
  cvsimport: Improve formating consistency
  cvsserver: small corrections to asciidoc documentation

 Geert Bosch (1):
  Fix renaming branch without config file

 Jakub Narebski (1):
  gitweb: Fix bug in "blobdiff" view for split (e.g. file to symlink) patches

 Junio C Hamano (3):
  Fix dependency of common-cmds.h
  Documentation: tighten dependency for git.{html,txt}
  Add Documentation/cmd-list.made to .gitignore

 Lars Hjemli (2):
  rename_ref(): only print a warning when config-file update fails
  Make builtin-branch.c handle the git config file

 René Scharfe (1):
  Revert "builtin-archive: use RUN_SETUP"

 Shawn O. Pearce (1):
  Honor -p<n> when applying git diffs

 Ville Skyttä (1):
  DESTDIR support for git/contrib/emacs

 YOSHIFUJI Hideaki (1):
  Avoid composing too long "References" header.


* The 'master' branch has these since the last announcement
  in addition to the above.

 Alex Riesen (1):
  Fix passing of TCLTK_PATH to git-gui

 Andy Parkins (1):
  Show binary file size change in diff --stat

 Christian Couder (2):
  Bisect: teach "bisect start" to optionally use one bad and many good revs.
  Documentation: bisect: "start" accepts one bad and many good commits

 Fernando J. Pereda (1):
  Makefile: Add '+' to QUIET_SUBDIR0 to fix parallel make.

 Junio C Hamano (21):
  git-fetch: add --quiet
  checkout: allow detaching to HEAD even when switching to the tip of a branch
  _GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.
  git-read-tree --index-output=<file>
  add_cache_entry(): removal of file foo does not conflict with foo/bar
  unpack_trees.c: pass unpack_trees_options structure to keep_entry() as well.
  unpack-trees: get rid of *indpos parameter.
  Fix read-tree --prefix=dir/.
  Fix twoway_merge that passed d/f conflict marker to merged_entry().
  Fix switching to a branch with D/F when current branch has file D.
  Fix bogus error message from merge-recursive error path
  Propagate cache error internal to refresh_cache() via parameter.
  Rename internal function "add_file_to_cache" in builtin-update-index.c
  Rename static variable write_index to update_index in builtin-apply.c
  Rename add_file_to_index() to add_file_to_cache()
  git-bisect: modernization
  t6030: add a bit more tests to git-bisect
  git-bisect: allow bisecting with only one bad commit.
  git-push reports the URL after failing.
  git-push to multiple locations does not stop at the first failure
  A new merge stragety 'subtree'.

 Nicolas Pitre (1):
  clean up and optimize nth_packed_object_sha1() usage

 Shawn O. Pearce (1):
  Fix lost-found to show commits only referenced by reflogs

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-03-31  9:34 Junio C Hamano
  2007-03-31 11:54 ` Alex Riesen
@ 2007-04-05  6:44 ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-04-05  6:44 UTC (permalink / raw)
  To: git

So here is the status for tonight.

* There is no biggie in 'maint' yet.

* On 'master', as I promised, the following topics are merged:

  - An option to install p4import, and make it part of the RPM
    binary package suite.

  - An option to exclude git-gui and gitk.

  - Build tweak to include GIT_VERSION string in the documentation.

  - Optimize "add single-path" in a huge directory whose
    contents are mostly ignored.

  - Optimize "rev-list --bisect".

  - A handful gitweb, git-svn and git-blame.el cleanups.

  In addition, a few patches are also in:

  - "diff --stat" to show bytesize changes for binary files.

  - "lost-found" to ignore objects only reachable from the reflog.

  - "patch -p<n>" is honored even for "diff --git" patches.

  - A handful internal clean-ups.

----------------------------------------------------------------

* The 'maint' branch has these fixes since v1.5.1

 Brian Gernhardt (1):
  Fix t4200-rerere for white-space from "wc -l"

 Gerrit Pape (1):
  rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email.

 Junio C Hamano (1):
  rerere: make sorting really stable.


* The 'master' branch has these since v1.5.1 in addition to the above.

 Andy Parkins (1):
  Show binary file size change in diff --stat

 Brian Gernhardt (1):
  Remove unused WITH_OWN_SUBPROCESS_PY from RPM spec

 Eric Wong (1):
  git-svn: bail out on incorrect command-line options

 Eygene Ryabinkin (7):
  Add the WITH_P4IMPORT knob to the Makefile.
  Added git-p4 package to the list of git RPMs.
  Added correct Python path to the RPM specfile.
  NO_TCLTK
  Add --with-tcltk and --without-tcltk to configure.
  Rewrite Tcl/Tk interpreter path for the GUI tools.
  Eliminate checks of user-specified Tcl/Tk interpreter.

 Frank Lichtenheld (2):
  Documentation: Replace @@GIT_VERSION@@ in documentation
  Documentation: Add version information to man pages

 Jakub Narebski (2):
  gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (3)
  gitweb: Quote hash keys, and do not use barewords keys

 Junio C Hamano (14):
  t6002: minor spelling fix.
  git-rev-list: add --bisect-vars option.
  git-rev-list --bisect: optimization
  t6004: add a bit more path optimization test.
  rev-list --bisect: Fix "halfway" optimization.
  make the previous optimization work also on path-limited rev-list --bisect
  Documentation: unbreak user-manual.
  Optional Tck/Tk: ignore generated files.
  RPM spec: include git-p4 in the list of all packages.
  Fix bogus error message from merge-recursive error path
  Propagate cache error internal to refresh_cache() via parameter.
  Rename internal function "add_file_to_cache" in builtin-update-index.c
  Rename static variable write_index to update_index in builtin-apply.c
  Rename add_file_to_index() to add_file_to_cache()

 Linus Torvalds (1):
  Optimize directory listing with pathspec limiter.

 Nicolas Pitre (1):
  clean up and optimize nth_packed_object_sha1() usage

 Shawn O. Pearce (2):
  Fix lost-found to show commits only referenced by reflogs
  Honor -p<n> when applying git diffs

 Xavier Maillard (2):
  git-blame.el: separate git-blame-mode to ease maintenance
  git-blame.el: pick a set of random colors for each git-blame turn

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-03-31  9:34 Junio C Hamano
@ 2007-03-31 11:54 ` Alex Riesen
  2007-04-05  6:44 ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Alex Riesen @ 2007-03-31 11:54 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano, Sat, Mar 31, 2007 11:34:14 +0200:
> 
> If you can remind me of patches that are "must have"s for 1.5.1
> that I've missed, that would be very nice.  We've broken "git
> am" and "git rebase" (without --merge) on 'master' branch for
> people who has i18n contents after 1.5.0 but they should be
> fixed now.

We still have absolutely broken merge-recursive WRT rename/rename
conflicts in intermediate trees.

> Please, remember that the key word for this weekend is "make
> 1.5.1 NO WORSE than 1.5.0".  IOW, the focus is on obvious
> regression fixes.

It is "no worse", but doesn't "pretty bad" count?

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-03-31  9:34 Junio C Hamano
  2007-03-31 11:54 ` Alex Riesen
  2007-04-05  6:44 ` Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-03-31  9:34 UTC (permalink / raw)
  To: git

As you can see, there are a few more fixes on the 'maint' branch
since 1.5.0.6; I might do 1.5.0.7 just for the sake of it, but I
am fairly determined to tag 1.5.1 on Apr 4th in a shape that is
"no worse" than 1.5.0, so it might not be strictly necessary.

If you can remind me of patches that are "must have"s for 1.5.1
that I've missed, that would be very nice.  We've broken "git
am" and "git rebase" (without --merge) on 'master' branch for
people who has i18n contents after 1.5.0 but they should be
fixed now.

Please, remember that the key word for this weekend is "make
1.5.1 NO WORSE than 1.5.0".  IOW, the focus is on obvious
regression fixes.

----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.

 Gerrit Pape (2):
  Documentation/git-svnimport.txt: fix typo.
  Documentation/git-rev-parse.txt: fix example in SPECIFYING RANGES.

 H. Peter Anvin (1):
  git-upload-pack: make sure we close unused pipe ends


* The 'master' branch has these since the last announcement
  in addition to the above.

 Andy Parkins (1):
  Reimplement emailing part of hooks--update in contrib/hooks/post-receive-email

 Christian Couder (1):
  Bisect: Improve error message in "bisect_next_check".

 Don Zickus (1):
  git-mailinfo fixes for patch munging

 Eric Wong (1):
  git-svn: avoid respewing similar error messages for missing paths

 Francis Daly (1):
  git-quiltimport /bin/sh-ism fix

 Jakub Narebski (1):
  gitweb: Support comparing blobs (files) with different names

 Julian Phillips (1):
  contrib/workdir: add a simple script to create a working directory

 Junio C Hamano (2):
  Update draft release notes for 1.5.1
  Do not bother documenting fetch--tool

 Theodore Ts'o (12):
  Fix minor formatting issue in man page for git-mergetool
  mergetool: Replace use of "echo -n" with printf(1) to be more portable
  mergetool: Don't error out in the merge case where the local file is deleted
  mergetool: portability fix: don't assume true is in /bin
  mergetool: portability fix: don't use reserved word function
  mergetool: factor out common code
  mergetool: Remove spurious error message if merge.tool config option not set
  mergetool: Fix abort command when resolving symlinks and deleted files
  mergetool: Add support for Apple Mac OS X's opendiff command
  mergetool: Make git-rm quiet when resolving a deleted file conflict
  mergetool: Clean up description of files and prompts for merge resolutions
  Rename warn() to warning() to fix symbol conflicts on BSD and Mac OS

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-03-13  8:49     ` Junio C Hamano
  2007-03-13  9:26       ` Junio C Hamano
  2007-03-22 17:08       ` Steven Grimm
@ 2007-03-25  8:32       ` Junio C Hamano
  2 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-03-25  8:32 UTC (permalink / raw)
  To: git

On the 'maint' front, there are a handful gitweb fixes, but
there is nothing major.  I'll perhaps do a v1.5.0.6 if I have
time when I do the v1.5.1-rc2.

I allowed a handful new features to the 'master' side, contrary
to the promise of -rc1 which is supposed to be 'no new features,
only fixes'.  They should be safe changes, though.

 - 'git-diff --quiet' optimizes tree-level comparison by exiting
   early when it finds one difference.  This speeds up path-limited
   form of git-rev-list and git-log significantly.

 - 'git-bisect run <script>' can be used to automate simple
   bisection. 

Notable fixes since -rc1 includes:

 - 'git-clone -q' supresses the "walk" and "got" noises while
   fetching over http.

 - 'git-revert' does not add duplicated abbreviated commit
   object name on the title line anymore.

 - With core.legacyheaders turned off, zero-length loose object
   was incorrectly judged corrupt.

 - 'git-apply' with core.autocrlf generated bogus results.

 - path-limited 'git-bisect' terminated too early before finding
   the guilty commit.

 - the sample update hook does not generate change notification
   e-mails anymore. 

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

 Jakub Narebski (4):
  gitweb: Fix "next" link in commit view
  gitweb: Don't escape attributes in CGI.pm HTML methods
  gitweb: Fix not marking signoff lines in "log" view
  gitweb: Add some installation notes in gitweb/INSTALL

 Li Yang (1):
  gitweb: Change to use explicitly function call cgi->escapHTML()

 Michael S. Tsirkin (1):
  fix typo in git-am manpage

 Peter Eriksen (1):
  Documentation/pack-format.txt: Clear up description of types.


* The 'master' branch has these since v1.5.1-rc1.

 Alex Riesen (2):
  Document --quiet option to git-diff
  Use diff* with --exit-code in git-am, git-rebase and git-merge-ours

 Andy Parkins (2):
  update-hook: abort early if the project description is unset
  update-hook: remove e-mail sending hook.

 Brandon Casey (1):
  prefer "git COMMAND" over "git-COMMAND" in gitk

 Chris Wright (1):
  make git clone -q suppress the noise with http fetch

 Christian Couder (6):
  Bisect: implement "git bisect run <cmd>..." to automatically bisect.
  Documentation: bisect: reformat some paragraphs.
  Documentation: bisect: reword one paragraph.
  Documentation: bisect: reformat more paragraphs.
  Documentation: bisect: add some titles to some paragraphs.
  Documentation: bisect: make a comment fit better in the man page.

 Eric Wong (1):
  gitk: bind <F5> key to Update (reread commits)

 James Bowes (1):
  Replace remaining instances of strdup with xstrdup.

 Johannes Schindelin (5):
  xdiff/xutils.c(xdl_hash_record): factor out whitespace handling
  Add a HOWTO for setting up a standalone git daemon
  Provide some technical documentation for shallow clones
  t4118: be nice to non-GNU sed
  git-revert: Revert revert message to old behaviour

 Junio C Hamano (12):
  blame: micro-optimize cmp_suspect()
  blame: cmp_suspect is not "cmp" anymore.
  Teach tree_entry_interesting() that the tree entries are sorted.
  tree-diff: avoid strncmp()
  tree_entry_interesting(): allow it to say "everything is interesting"
  git-rebase: make 'rebase HEAD branch' work as expected.
  git-apply: Do not free the wrong buffer when we convert the data for writeout
  checkout: report where the new HEAD is upon detaching HEAD
  git-bisect: typofix
  git-bisect.sh: properly dq $GIT_DIR
  Fix path-limited "rev-list --bisect" termination condition.
  git-am documentation: describe what is taken from where.

 Linus Torvalds (6):
  Fix loose object uncompression check.
  Don't ever return corrupt objects from "parse_object()"
  Be more careful about zlib return values
  Remove "pathlen" from "struct name_entry"
  Initialize tree descriptors with a helper function rather than by hand.
  Switch over tree descriptors to contain a pre-parsed entry

 Michael S. Tsirkin (1):
  git-merge: Put FETCH_HEAD data in merge commit message

 Nicolas Pitre (10):
  clean up the delta base cache size a bit
  use a LRU eviction policy for the delta base cache
  don't ever allow SHA1 collisions to exist by fetching a pack
  index-pack: use hash_sha1_file()
  index-pack: more validation checks and cleanups
  improve checkout message when asking for same branch
  minor git-prune optimization
  update HEAD reflog when branch pointed to by HEAD is directly modified
  make it more obvious that temporary files are temporary files
  write_sha1_from_fd() should make new objects read-only

 Santi Béjar (1):
  git-fetch: Fix single_force in append_fetch_head

 Shawn O. Pearce (1):
  contrib/continuous: a continuous integration build manager

 Uwe Kleine-König (1):
  Bisect: convert revs given to good and bad to commits

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-03-22 17:08       ` Steven Grimm
@ 2007-03-22 21:30         ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-03-22 21:30 UTC (permalink / raw)
  To: Steven Grimm; +Cc: Git Mailing List

Steven Grimm <koreth@midwinter.com> writes:

> Will you be applying your patch for the "checkout fails if something
> is a file in one branch and a directory in another" problem? I realize
> it's not a complete solution, but it's at least a significant
> improvement over the current behavior, and I don't imagine it breaks
> anything else.

If I understand correctly, the patch is already broken.  Rather,
the patch itself may be correct but it exposes more breakages
that currently is hidden only because we do not replace bunch of
files in a subdirectory with a single file in the index thanks
to the "too strict" check that is bothering you.  Lifting that
check with the previous patch would make it either fail to
notice other local changes (which is worse), or mistakenly say
there is a local change when there is none (which is not better
but not worse).  In particular, I think it is highly suspicious
what the current code with the patch does to paths that
immediately follow the directory to be removed, although I
stopped looking into this issue, as we already said this will
not be dealt with in 1.5.1.

In short, I do not think the patch is suitable for production,
as the cure seems worse than the disease.

That does not mean anybody is forbidden to look into a fix in
the meantime.  I am just saying I do not expect it to happen
before 1.5.1.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-03-13  8:49     ` Junio C Hamano
  2007-03-13  9:26       ` Junio C Hamano
@ 2007-03-22 17:08       ` Steven Grimm
  2007-03-22 21:30         ` Junio C Hamano
  2007-03-25  8:32       ` Junio C Hamano
  2 siblings, 1 reply; 601+ messages in thread
From: Steven Grimm @ 2007-03-22 17:08 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git Mailing List

Will you be applying your patch for the "checkout fails if something is 
a file in one branch and a directory in another" problem? I realize it's 
not a complete solution, but it's at least a significant improvement 
over the current behavior, and I don't imagine it breaks anything else.

I can resend my test case if you like.

-Steve


Junio C Hamano wrote:
> Perhaps it is time for 1.5.0.4 this Wednesday (my time) from
> 'maint'.
>
> On the 'master' front, Johannes and Matthias cleaned up the
> git-bundle and made it (hopefully) usable shape.  Also git-diff
> got even nicer when used outside the context of git, again
> thanks to Johannes.  I think we are nearing 1.5.1-rc1, which
> I'll talk about in "What's cooking".
>
> ----------------------------------------------------------------
>
> * The 'maint' branch has these fixes since the last announcement.
>
>  Alexandre Julliard (2):
>   git.el: Avoid appending a signoff line that is already present.
>   git.el: Retrieve commit log information from .dotest directory.
>
>  Avi Kivity (1):
>   git-send-email: Document configuration options
>
>  Brian Gernhardt (1):
>   Fix diff-options references in git-diff and git-format-patch
>
>  J. Bruce Fields (13):
>   Documentation: mention module option to git-cvsimport
>   user-manual: reset to ORIG_HEAD not HEAD to undo merge
>   user-manual: ensure generated manual references stylesheet
>   user-manual: insert earlier of mention content-addressable architecture
>   user-manual: how to replace commits older than most recent
>   user-manual: more detailed merge discussion
>   glossary: fix overoptimistic automatic linking of defined terms
>   user-manual: fix inconsistent example
>   user-manual: fix inconsistent use of pull and merge
>   user-manual: fix missing colon in git-show example
>   user-manual: fix rendering of history diagrams
>   user-manual: install user manual stylesheet with other web documents
>   git-merge: warn when -m provided on a fast forward
>
>  Jeff King (2):
>   Documentation: s/seperator/separator/
>   fast-import: grow tree storage more aggressively
>
>  Johannes Schindelin (2):
>   Begin SubmittingPatches with a check list
>   make t8001 work on Mac OS X again
>
>  Junio C Hamano (2):
>   GIT 1.5.0.3
>   git-commit: cd to top before showing the final stat
>
>  Matthias Kestenholz (1):
>   Adjust reflog filemode in shared repository
>
>  Matthias Lederhofer (1):
>   setup_git_directory_gently: fix off-by-one error
>
>  Shawn O. Pearce (13):
>   git-gui: Relocate the menu/transport menu code.
>   git-gui: Add Reset to the Branch menu.
>   git-gui: Don't create empty (same tree as parent) commits.
>   git-gui: Remove unnecessary /dev/null redirection.
>   fast-import: Avoid infinite loop after reset
>   fast-import: Fail if a non-existant commit is used for merge
>   git-gui: Make 'make' quieter by default
>   Catch write_ref_sha1 failure in receive-pack
>   git-gui: Allow committing empty merges
>   git-gui: Revert "Don't modify CREDITS-FILE if it hasn't changed."
>   git-gui: Revert "git-gui: Display all authors of git-gui."
>   git-gui: Allow 'git gui version' outside of a repository
>   Don't package the git-gui credits file anymore
>
>  Theodore Ts'o (1):
>   Add definition of <commit-ish> to the main git man page.
>
>  Yasushi SHOJI (1):
>   glossary: Add definitions for dangling and unreachable objects
>
>
> * The 'master' branch has these since the last announcement
>   in addition to the above.
>
>  Alex Riesen (4):
>   git-gui: Support of "make -s" in: do not output anything of the build itself
>   More build output cleaning up
>   Support of "make -s": do not output anything of the build itself
>   Allow "make -w" generate its usual output
>
>  Avi Kivity (1):
>   git-send-email: configurable bcc and chain-reply-to
>
>  Frank Lichtenheld (1):
>   cvsserver: Use Merged response instead of Update-existing for merged files
>
>  Jakub Narebski (1):
>   gitweb: Don't escape attributes in CGI.pm HTML methods
>
>  Jeff King (1):
>   New fast-import test case for valid tree sorting
>
>  Jim Meyering (1):
>   I like the idea of the new ':/<oneline prefix>' notation, and gave it
>
>  Johannes Schindelin (15):
>   fetch & clone: do not output progress when not on a tty
>   Fixup no-progress for fetch & clone
>   Make git-revert & git-cherry-pick a builtin
>   diff: support reading a file from stdin via "-"
>   diff --no-index: support /dev/null as filename
>   Get rid of the dependency to GNU diff in the tests
>   cherry-pick: Suggest a better method to retain authorship
>   format-patch: add --inline option and make --attach a true attachment
>   bundle: fix wrong check of read_header()'s return value & add tests
>   git-bundle: avoid packing objects which are in the prerequisites
>   git-bundle: Make thin packs
>   git-bundle: handle thin packs in subcommand "unbundle"
>   git-bundle: die if a given ref is not included in bundle
>   git-bundle: prevent overwriting existing bundles
>   git-bundle: only die if pack would be empty, warn if ref is skipped
>
>  Johannes Sixt (3):
>   Add core.symlinks to mark filesystems that do not support symbolic links.
>   Handle core.symlinks=false case in merge-recursive.
>   Tell multi-parent diff about core.symlinks.
>
>  Junio C Hamano (14):
>   diff-ni: fix the diff with standard input
>   format-patch --attach: not folding some long headers.
>   Post 1.5.0.3 cleanup
>   fsck: fix broken loose object check.
>   unpack_sha1_file(): detect corrupt loose object files.
>   fsck: exit with non-zero status upon errors
>   git-bundle: fix pack generation.
>   revision walker: Fix --boundary when limited
>   revision traversal: retire BOUNDARY_SHOW
>   git-bundle: various fixups
>   revision traversal: SHOWN means shown
>   git-bundle: make verify a bit more chatty.
>   revision --boundary: fix stupid typo
>   revision --boundary: fix uncounted case.
>
>  Li Yang (1):
>   gitweb: Change to use explicitly function call cgi->escapHTML()
>
>  Linus Torvalds (1):
>   Re-fix get_sha1_oneline()
>
>  Paolo Bonzini (3):
>   git-config: document --rename-section, provide --remove-section
>   git-archimport: allow remapping branch names
>   git-commit: add a --interactive option
>
>  Santi Béjar (2):
>   t/t5515-fetch-merge-logic.sh: Added tests for the merge login in git-fetch
>   t/t5515-fetch-merge-logic.sh: Add two more tests
>
>  Shawn O. Pearce (31):
>   cherry-pick: Bug fix 'cherry picked from' message.
>   Make 'make' quieter while building git
>   Make 'make' quiet by default
>   Display the null SHA-1 as the base for an OBJ_OFS_DELTA.
>   Fix mmap leak caused by reading bad indexes.
>   Don't build external_grep if its not used
>   General const correctness fixes
>   Use uint32_t for all packed object counts.
>   Use uint32_t for pack-objects counters.
>   Use off_t when we really mean a file offset.
>   Use off_t in pack-objects/fast-import when we mean an offset
>   Cast 64 bit off_t to 32 bit size_t
>   Preallocate memory earlier in fast-import
>   Move post-update hook to after all other activity
>   Don't run post-update hook unless a ref changed
>   Refactor run_update_hook to be more useful
>   Refactor handling of error_string in receive-pack
>   Teach receive-pack to run pre-receive/post-receive hooks
>   Use atomic updates to the fast-import mark file
>   Allow fast-import frontends to reload the marks table
>   Switch to run_command_v_opt in revert
>   Remove unused run_command variants
>   Start defining a more sophisticated run_command
>   Split run_command into two halves (start/finish)
>   Teach run_command how to setup a stdin pipe
>   Refactor run_command error handling in receive-pack
>   Split back out update_hook handling in receive-pack
>   Change {pre,post}-receive hooks to use stdin
>   Remove unnecessary casts from fast-import
>   Simplify closing two fds at once in run-command.c
>   Fix t5510-fetch's use of sed
>
>  Xavier Maillard (1):
>   contrib/emacs: Use non-interactive function to byte-compile files
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-03-13  8:49     ` Junio C Hamano
@ 2007-03-13  9:26       ` Junio C Hamano
  2007-03-22 17:08       ` Steven Grimm
  2007-03-25  8:32       ` Junio C Hamano
  2 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-03-13  9:26 UTC (permalink / raw)
  To: git

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

> On the 'master' front, Johannes and Matthias cleaned up the
> git-bundle and made it (hopefully) usable shape.

Sorry, but I meant Mark Levedahl here.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-03-04 10:32   ` Junio C Hamano
@ 2007-03-13  8:49     ` Junio C Hamano
  2007-03-13  9:26       ` Junio C Hamano
                         ` (2 more replies)
  0 siblings, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-03-13  8:49 UTC (permalink / raw)
  To: git

Perhaps it is time for 1.5.0.4 this Wednesday (my time) from
'maint'.

On the 'master' front, Johannes and Matthias cleaned up the
git-bundle and made it (hopefully) usable shape.  Also git-diff
got even nicer when used outside the context of git, again
thanks to Johannes.  I think we are nearing 1.5.1-rc1, which
I'll talk about in "What's cooking".

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

 Alexandre Julliard (2):
  git.el: Avoid appending a signoff line that is already present.
  git.el: Retrieve commit log information from .dotest directory.

 Avi Kivity (1):
  git-send-email: Document configuration options

 Brian Gernhardt (1):
  Fix diff-options references in git-diff and git-format-patch

 J. Bruce Fields (13):
  Documentation: mention module option to git-cvsimport
  user-manual: reset to ORIG_HEAD not HEAD to undo merge
  user-manual: ensure generated manual references stylesheet
  user-manual: insert earlier of mention content-addressable architecture
  user-manual: how to replace commits older than most recent
  user-manual: more detailed merge discussion
  glossary: fix overoptimistic automatic linking of defined terms
  user-manual: fix inconsistent example
  user-manual: fix inconsistent use of pull and merge
  user-manual: fix missing colon in git-show example
  user-manual: fix rendering of history diagrams
  user-manual: install user manual stylesheet with other web documents
  git-merge: warn when -m provided on a fast forward

 Jeff King (2):
  Documentation: s/seperator/separator/
  fast-import: grow tree storage more aggressively

 Johannes Schindelin (2):
  Begin SubmittingPatches with a check list
  make t8001 work on Mac OS X again

 Junio C Hamano (2):
  GIT 1.5.0.3
  git-commit: cd to top before showing the final stat

 Matthias Kestenholz (1):
  Adjust reflog filemode in shared repository

 Matthias Lederhofer (1):
  setup_git_directory_gently: fix off-by-one error

 Shawn O. Pearce (13):
  git-gui: Relocate the menu/transport menu code.
  git-gui: Add Reset to the Branch menu.
  git-gui: Don't create empty (same tree as parent) commits.
  git-gui: Remove unnecessary /dev/null redirection.
  fast-import: Avoid infinite loop after reset
  fast-import: Fail if a non-existant commit is used for merge
  git-gui: Make 'make' quieter by default
  Catch write_ref_sha1 failure in receive-pack
  git-gui: Allow committing empty merges
  git-gui: Revert "Don't modify CREDITS-FILE if it hasn't changed."
  git-gui: Revert "git-gui: Display all authors of git-gui."
  git-gui: Allow 'git gui version' outside of a repository
  Don't package the git-gui credits file anymore

 Theodore Ts'o (1):
  Add definition of <commit-ish> to the main git man page.

 Yasushi SHOJI (1):
  glossary: Add definitions for dangling and unreachable objects


* The 'master' branch has these since the last announcement
  in addition to the above.

 Alex Riesen (4):
  git-gui: Support of "make -s" in: do not output anything of the build itself
  More build output cleaning up
  Support of "make -s": do not output anything of the build itself
  Allow "make -w" generate its usual output

 Avi Kivity (1):
  git-send-email: configurable bcc and chain-reply-to

 Frank Lichtenheld (1):
  cvsserver: Use Merged response instead of Update-existing for merged files

 Jakub Narebski (1):
  gitweb: Don't escape attributes in CGI.pm HTML methods

 Jeff King (1):
  New fast-import test case for valid tree sorting

 Jim Meyering (1):
  I like the idea of the new ':/<oneline prefix>' notation, and gave it

 Johannes Schindelin (15):
  fetch & clone: do not output progress when not on a tty
  Fixup no-progress for fetch & clone
  Make git-revert & git-cherry-pick a builtin
  diff: support reading a file from stdin via "-"
  diff --no-index: support /dev/null as filename
  Get rid of the dependency to GNU diff in the tests
  cherry-pick: Suggest a better method to retain authorship
  format-patch: add --inline option and make --attach a true attachment
  bundle: fix wrong check of read_header()'s return value & add tests
  git-bundle: avoid packing objects which are in the prerequisites
  git-bundle: Make thin packs
  git-bundle: handle thin packs in subcommand "unbundle"
  git-bundle: die if a given ref is not included in bundle
  git-bundle: prevent overwriting existing bundles
  git-bundle: only die if pack would be empty, warn if ref is skipped

 Johannes Sixt (3):
  Add core.symlinks to mark filesystems that do not support symbolic links.
  Handle core.symlinks=false case in merge-recursive.
  Tell multi-parent diff about core.symlinks.

 Junio C Hamano (14):
  diff-ni: fix the diff with standard input
  format-patch --attach: not folding some long headers.
  Post 1.5.0.3 cleanup
  fsck: fix broken loose object check.
  unpack_sha1_file(): detect corrupt loose object files.
  fsck: exit with non-zero status upon errors
  git-bundle: fix pack generation.
  revision walker: Fix --boundary when limited
  revision traversal: retire BOUNDARY_SHOW
  git-bundle: various fixups
  revision traversal: SHOWN means shown
  git-bundle: make verify a bit more chatty.
  revision --boundary: fix stupid typo
  revision --boundary: fix uncounted case.

 Li Yang (1):
  gitweb: Change to use explicitly function call cgi->escapHTML()

 Linus Torvalds (1):
  Re-fix get_sha1_oneline()

 Paolo Bonzini (3):
  git-config: document --rename-section, provide --remove-section
  git-archimport: allow remapping branch names
  git-commit: add a --interactive option

 Santi Béjar (2):
  t/t5515-fetch-merge-logic.sh: Added tests for the merge login in git-fetch
  t/t5515-fetch-merge-logic.sh: Add two more tests

 Shawn O. Pearce (31):
  cherry-pick: Bug fix 'cherry picked from' message.
  Make 'make' quieter while building git
  Make 'make' quiet by default
  Display the null SHA-1 as the base for an OBJ_OFS_DELTA.
  Fix mmap leak caused by reading bad indexes.
  Don't build external_grep if its not used
  General const correctness fixes
  Use uint32_t for all packed object counts.
  Use uint32_t for pack-objects counters.
  Use off_t when we really mean a file offset.
  Use off_t in pack-objects/fast-import when we mean an offset
  Cast 64 bit off_t to 32 bit size_t
  Preallocate memory earlier in fast-import
  Move post-update hook to after all other activity
  Don't run post-update hook unless a ref changed
  Refactor run_update_hook to be more useful
  Refactor handling of error_string in receive-pack
  Teach receive-pack to run pre-receive/post-receive hooks
  Use atomic updates to the fast-import mark file
  Allow fast-import frontends to reload the marks table
  Switch to run_command_v_opt in revert
  Remove unused run_command variants
  Start defining a more sophisticated run_command
  Split run_command into two halves (start/finish)
  Teach run_command how to setup a stdin pipe
  Refactor run_command error handling in receive-pack
  Split back out update_hook handling in receive-pack
  Change {pre,post}-receive hooks to use stdin
  Remove unnecessary casts from fast-import
  Simplify closing two fds at once in run-command.c
  Fix t5510-fetch's use of sed

 Xavier Maillard (1):
  contrib/emacs: Use non-interactive function to byte-compile files

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-02-23  8:33 ` Junio C Hamano
@ 2007-03-04 10:32   ` Junio C Hamano
  2007-03-13  8:49     ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-03-04 10:32 UTC (permalink / raw)
  To: git

I'll do another maintenance release 1.5.0.3 soonish to flush
accumulated fixes on 'maint' branch.

On the 'master' front, we have

 * a largish git-svn updates.
 * a handful git diff improvements.
 * a beginning of CRLF mangling.
 * improved behaviour of git-apply run in subdirectories.
 * /etc/gitconfig

Soon we will also have these from 'next'.  I think it will be
time to do v1.5.1 after they are in:

 * "fake symlink" work for MinGW port
 * built-in revert/cherry-pick
 * "git diff" that compares stdin and /dev/null
 * make "git fetch" quieter when noninteractive.

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

 Alexandre Julliard (1):
  git.el: Set the default commit coding system from the repository config.

 Aneesh Kumar K.V (1):
  blameview: Fix the browse behavior in blameview

 Christian Schlotter (1):
  Documentation: Correct minor typo in git-add documentation.

 Eygene Ryabinkin (2):
  http-push.c::lock_remote(): validate all remote refs.
  Another memory overrun in http-push.c

 Gerrit Pape (2):
  git-cvsexportcommit: don't cleanup .msg if not yet committed to cvs.
  Fix quoting in update hook template

 Jim Meyering (1):
  diff --cc: integer overflow given a 2GB-or-larger file

 Johannes Schindelin (3):
  fetch.o depends on the headers, too.
  builtin-archive: use RUN_SETUP
  Document the config variable format.suffix

 Junio C Hamano (4):
  git-apply: do not fix whitespaces on context lines.
  Documentation: git-remote add [-t <branch>] [-m <branch>] [-f] name url
  Start preparing Release Notes for 1.5.0.3
  git-merge: fail correctly when we cannot fast forward.

 Linus Torvalds (2):
  mailinfo: do not get confused with logical lines that are too long.
  git-show: Reject native ref

 Matthias Kestenholz (1):
  Fix git-gc usage note

 Michael Coleman (2):
  Fix minor typos/grammar in user-manual.txt
  builtin-fmt-merge-msg: fix bugs in --file option

 Michael Poole (1):
  Correct ordering in git-cvsimport's option documentation

 Paolo Bonzini (1):
  git-archimport: support empty summaries, put summary on a single line.

 Ramsay Allan Jones (5):
  Fix a "label defined but unreferenced" warning.
  Fix an "implicit function definition" warning.
  Fix some "comparison is always true/false" warnings.
  Fix a "pointer type missmatch" warning.
  Unset NO_C99_FORMAT on Cygwin.

 Sergey Vlasov (3):
  Documentation/build-docdep.perl: Fix dependencies for included asciidoc files
  Documentation/git-quiltimport.txt: Fix labeled list formatting
  Documentation/git-send-email.txt: Fix labeled list formatting

 Shawn O. Pearce (1):
  index-pack: Loop over pread until data loading is complete.

 Theodore Ts'o (1):
  Fix git-show man page formatting in the EXAMPLES section

 Uwe Kleine-König (1):
  Include config.mak in doc/Makefile


* The 'master' branch has these since the last announcement
  in addition to the above.

 Andy Parkins (3):
  cvsserver: Remove trailing "\n" from commithash in checkin function
  cvsserver: Make always-binary mode a config file option
  Sample update hook: typofix and modernization to use "git log"

 Aneesh Kumar K.V (1):
  Documentation: document remote.<name>.tagopt

 Eric Wong (118):
  git-svn: move authentication prompts into their own namespace
  git-svn: cleanup: move process_rm around
  git-svn: cleanup: put SVN workarounds into their own namespace
  git-svn: cleanup: avoid re-use()ing Git.pm in sub-packages
  git-svn: add Git::SVN module (to avoid global variables)
  git-svn: convert 'init' to use Git::SVN
  git-svn: convert multi-init over to using Git::SVN
  git-svn: make multi-init capable of reusing the Ra connection
  git-svn: add a test for show-ignore
  git-svn: convert show-ignore over to Git::SVN
  git-svn: moved the 'log' command into its own namespace
  git-svn: port the 'rebuild' command to use Git::SVN objects
  git-svn: do not let Git.pm warn if we prematurely close pipes
  git-svn: convert the 'commit-diff' command to Git::SVN
  git-svn: get rid of Memoize for now...
  git-svn: fetch/multi-fetch converted over to Git::SVN module
  git-svn: switch dcommit to using Git::SVN code
  git-svn: convert 'set-tree' command to use Git::SVN
  git-svn: remove graft-branches command
  git-svn: add support for metadata in .git/config
  git-svn: fix a regression in dcommit that caused empty log messages
  git-svn: reuse open SVN::Ra connections by URL
  git-svn: enable --minimize to simplify the config and connections
  git-svn: fix --follow-parent to work with Git::SVN
  git-svn: --follow-parent works with svn-remotes multiple branches
  git-svn: disallow ambigious local refspecs
  git-svn: allow --follow-parent on deleted directories
  git-svn: get rid of additional fetch-arguments
  git-svn: allow 'init' to work outside of tests
  git-svn: better error reporting if --follow-parent fails
  git-svn: 'init' attempts to connect to the repository root if possible
  git-svn: --follow-parent now works on sub-directories of larger branches
  git-svn: track writes writes to the index in fetch
  git-svn: add an odd test case that seems to cause segfaults over HTTP
  git-svn: avoid tracking change-less revisions
  git-svn: correctly track revisions made to deleted branches
  git-svn: fix segfaults from accessing svn_log_changed_path_t
  git-svn: fix committing to subdirectories, add tests
  git-svn: avoid an extra svn_ra connection during commits
  git-svn: simplify usage of the SVN::Git::Editor interface
  git-svn: cleanup remove unused function
  git-svn: allow multi-fetch to fetch things chronologically
  git-svn: correctly track diff-less copies with do_switch
  git-svn: correctly handle do_{switch,update} in deep directories
  git-svn: stop using path names as refnames with --follow-parent
  git-svn: cleanup: move editor-specific variables into the editor namespace
  git-svn: just use Digest::MD5 instead of requiring it
  git-svn: reinstate the default SVN error handler after using get_log
  git-svn: don't rely on do_switch + reparenting with svn(+ssh)://
  git-svn: fetch tracks initial change with --follow-parent
  git-svn: remove the 'rebuild' command and make the functionality automatic
  git-svn: fix several fetch bugs related to repeated invocations
  git-svn: reinstate --no-metadata, add --svn-remote=, variable cleanups
  git-svn: gracefully handle --follow-parent failures
  git-svn: make (multi-)fetch safer but slower
  git-svn: avoid a huge memory spike with high-numbered revisions
  git-svn: re-enable repacking flags
  git-svn: do our best to ensure that our ref and rev_db are consistent
  git-svn: avoid redundant get_log calls between invocations
  git-svn: use sys* IO functions for reading rev_db
  git-svn: don't write to the config file from --follow-parent
  git-svn: save paths to tags/branches with for future reuse
  git-svn: migrations default to [svn-remote "git-svn"]
  git-svn: get rid of revisions_eq check for --follow-parent
  git-svn: avoid extra get_log calls when refspecs are added for fetching
  git-svn: just name the default svn-remote "svn" instead of "git-svn"
  git-svn: prepare multi-init for wildcard support
  git-svn: reintroduce using a single get_log() to fetch
  git-svn: run get_log() on a sub-directory if possible
  git-svn: implement auto-discovery of branches/tags
  git-svn: --follow-parent tracks multi-parent paths
  git-svn: remove check_path calls before calling do_update
  git-svn: remove some noisy debugging messages
  git-svn: enable follow-parent functionality by default
  git-svn: fix buggy regular expression usage in several places
  git-svn: correctly handle the -q flag in SVN::Git::Fetcher
  git-svn: correctly handle globs with a right-hand-side path component
  git-svn: remove optimized commit stuff for set-tree
  git-svn: add support for SVN::Mirror/svk using revprops for metadata
  git-svn: add support for per-[svn-remote "..."] options
  git-svn: use private $GIT_DIR/svn/config file more
  git-svn: extra safety for noMetadata and useSvmProps users
  git-svn: use separate, per-repository .rev_db files
  git-svn: write the highest maxRex out for branches and tags
  git-svn: handle multi-init without --trunk, UseSvmProps fixes
  git-svn: make dcommit usable for glob users
  git-svn: include merges when calling rev-list for decommit
  git-svn: usability fixes for the 'git svn log' command
  t910*: s/repo-config/config/g; poke around possible race conditions
  git-svn: hopefully make 'fetch' more user-friendly
  git-svn: allow 'init' to act as multi-init
  git-svn: brown paper bag fixes
  git-svn: simplify the (multi-)init methods of fetching
  git-svn: allow --log-window-size to be specified, default to 100
  git-svn: remember to check for clean indices on globbed refs, too
  git-svn: error checking for invalid [svn-remote "..."] sections
  git-svn: allow dcommit for those who only fetch from SVM with useSvmProps
  git-svn: documentation updates for new functionality
  git-svn: add support for --stat in the log command
  git-svn: checkout files on new fetches
  git-svn: add a 'rebase' command
  git-svn: fix some issues for people migrating from older versions
  git-svn: hide the private git-svn 'config' file as '.metadata'
  git-svn: add 'clone' command, an alias for init + fetch
  git-svn: allow overriding of the SVN repo root in metadata
  git-svn: add support for using svnsync properties
  git-svn: fix useSvmProps, hopefully for the last time
  git-svn: add test for useSvnsyncProps
  git-svn: documentation updates
  git-svn: allow metadata options to be specified with 'init' and 'clone'
  git-svn: give show-ignore HEAD smarts, like dcommit and log
  git-svn: ensure we're at the top-level and can access $GIT_DIR
  git-svn: fix clone when a target directory has been specified
  git-svn: fix reconnections to different paths of svn:// repositories
  git-svn: fix some potential bugs with --follow-parent
  Add test-chmtime: a utility to change mtime on files
  Update tests to use test-chmtime
  git-svn: fix show-ignore when not connected to the repository root

 Johannes Schindelin (18):
  rev-list --max-age, --max-count: support --boundary
  config: read system-wide defaults from /etc/gitconfig
  apply: make --verbose a little more useful
  Teach git-diff-files the new option `--no-index`
  pretty-formats: add 'format:<string>'
  Make tests independent of global config files
  Add git-bundle: move objects and references by archive
  git-bundle: assorted fixes
  git-bundle: avoid fork() in verify_bundle()
  git-bundle: fix 'create --all'
  git-bundle: record commit summary in the prerequisite data
  object name: introduce ':/<oneline prefix>' notation
  Fix typo: do not show name1 when name2 fails
  diff --no-index: also imitate the exit status of diff(1)
  Actually make print_wrapped_text() useful
  show_date(): rename the "relative" parameter to "mode"
  diff: make more cases implicit --no-index
  print_wrapped_text: fix output for negative indent

 Julian Phillips (2):
  git-branch: improve abbreviation of sha1s in verbose mode
  git-branch: document new --no-abbrev option

 Junio C Hamano (13):
  git-status: do not be totally useless in a read-only repository.
  update-index: do not die too early in a read-only repository.
  run_diff_{files,index}(): update calling convention.
  .mailmap maintenance after pulling from git-svn
  bundle: reword missing prerequisite error message
  diff --cached: give more sensible error message when HEAD is yet to be created.
  Documentation: link in 1.5.0.2 material to the top documentation page.
  Make 'cvs ci' lockless in git-cvsserver by using git-update-ref
  index_fd(): use enum object_type instead of type name string.
  index_fd(): pass optional path parameter as hint for blob conversion
  index_fd(): convert blob only if it is a regular file.
  Add recent changes to draft 1.5.1 release notes.
  diff-ni: allow running from a subdirectory.

 Michael Coleman (2):
  git-send-email: abort/usage on bad option
  fix various doc typos

 Nicolas Pitre (7):
  sha1_file.c: cleanup hdr usage
  sha1_file.c: cleanup "offset" usage
  sha1_file.c: don't ignore an error condition in sha1_loose_object_info()
  formalize typename(), and add its reverse type_from_string()
  convert object type handling from a string to a number
  get rid of lookup_object_type()
  make sure enum object_type is signed

 Sam Vilain (3):
  git-svn: make test for SVK mirror path import
  git-svn: don't consider SVN URL usernames significant when comparing
  git-svn: document --username

 Sergey Vlasov (1):
  Documentation/git-svn.txt: Fix formatting errors

 Shawn O. Pearce (1):
  Cleanup check_valid in commit-tree.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-02-20  7:32 Junio C Hamano
@ 2007-02-23  8:33 ` Junio C Hamano
  2007-03-04 10:32   ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-23  8:33 UTC (permalink / raw)
  To: git

On the 'maint' front, there aren't that many 'grave fixes'
anymore, which is somewhat (happily) surprising after a big
release like 1.5.0.  Shawn has updated git-gui to 0.6.1.
I'll perhaps do 1.5.0.2 next week.

In 'master', I pushed out autoCRLF and git-apply fixes.  These
are changes people can easily notice breakage and would benefit
from wider exposure.  Hopefully we can have simple path based
text/binary attribute on top of them -- I am hoping it to come
from people who actually benefit from autoCRLF ;-).

* The 'maint' branch has these fixes since the last announcement.

 Fredrik Kuivinen (1):
  Fix 'git commit -a' in a newly initialized repository

 Jason Riedy (1):
  Check for PRIuMAX rather than NO_C99_FORMAT in fast-import.c.

 Johannes Schindelin (1):
  git-diff: fix combined diff

 Martin Koegler (1):
  git-gui: Create new branches from a tag.

 Michael Loeffler (1):
  Use gunzip -c over gzcat in import-tars example.

 Shawn O. Pearce (16):
  git-gui: Refactor 'exec git subcmd' idiom.
  git-gui: Basic version check to ensure git 1.5.0 or later is used.
  git-gui: Permit merging tags into the current branch.
  git-gui: More consistently display the application name.
  git-gui: Print version on the console.
  git-gui: Prefer version file over git-describe.
  git-gui: Expose the browser as a subcommand.
  git-gui: Correct crash when saving options in blame mode.
  git-gui: Use mixed path for docs on Cygwin.
  git-gui: Display all authors of git-gui.
  git-gui: Change summary of git-gui.
  git-gui: Include browser in our usage message.
  git-gui: Remove TODO list.
  git-gui: Don't crash in citool mode on initial commit.
  Document the new core.bare configuration option.
  Include git-gui credits file in dist.


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

 Alex Riesen (1):
  disable t4016-diff-quote.sh on some filesystems

 Fredrik Kuivinen (2):
  New autoconf test for iconv
  Fix 'git commit -a' in a newly initialized repository

 Jason Riedy (1):
  Check for PRIuMAX rather than NO_C99_FORMAT in fast-import.c.

 Johannes Schindelin (5):
  apply: fix memory leak in prefix_one()
  name-rev: avoid "^0" when unneeded
  git grep: use pager
  Teach diff -B about colours
  git-diff: fix combined diff

 Junio C Hamano (16):
  t0020: add test for auto-crlf
  Teach 'git apply' to look at $GIT_DIR/config
  Teach core.autocrlf to 'git apply'
  Teach 'git apply' to look at $HOME/.gitconfig even outside of a repository
  git-apply: do not lose cwd when run from a subdirectory.
  git-apply: require -p<n> when working in a subdirectory.
  Link 1.5.0.1 documentation from the main page.
  Add prefixcmp()
  Mechanical conversion to use prefixcmp()
  prefixcmp(): fix-up mechanical conversion.
  prefixcmp(): fix-up leftover strncmp().
  t4119: add test for traditional patch and different p_value
  Fix botched "leak fix"
  git-apply: notice "diff --git" patch again
  git-apply: guess correct -p<n> value for non-git patches.
  t4119: test autocomputing -p<n> for traditional diff input.

 Linus Torvalds (2):
  Lazy man's auto-CRLF
  Make AutoCRLF ternary variable.

 Martin Koegler (1):
  git-gui: Create new branches from a tag.

 Martin Waitz (1):
  Support for large files on 32bit systems.

 Michael Loeffler (1):
  Use gunzip -c over gzcat in import-tars example.

 Pavel Roskin (1):
  git-remote: support remotes with a dot in the name

 Shawn O. Pearce (16):
  git-gui: Refactor 'exec git subcmd' idiom.
  git-gui: Basic version check to ensure git 1.5.0 or later is used.
  git-gui: Permit merging tags into the current branch.
  git-gui: More consistently display the application name.
  git-gui: Print version on the console.
  git-gui: Prefer version file over git-describe.
  git-gui: Expose the browser as a subcommand.
  git-gui: Correct crash when saving options in blame mode.
  git-gui: Use mixed path for docs on Cygwin.
  git-gui: Display all authors of git-gui.
  git-gui: Change summary of git-gui.
  git-gui: Include browser in our usage message.
  git-gui: Remove TODO list.
  git-gui: Don't crash in citool mode on initial commit.
  Document the new core.bare configuration option.
  Include git-gui credits file in dist.

 Simon 'corecode' Schubert (1):
  Allow passing of an alternative CVSROOT via -d.

 Theodore Ts'o (2):
  Add config_boolean() method to the Git perl module
  Allow git-remote to update named groups of remotes

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-02-20  7:32 Junio C Hamano
  2007-02-23  8:33 ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-20  7:32 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since v1.5.0.1

 Christian Schlotter (1):
  git-clone: Sync documentation to usage note.

 Jason Riedy (2):
  Add a compat/strtoumax.c for Solaris 8.
  Obey NO_C99_FORMAT in fast-import.c.


* The 'master' branch has these since the last announcement, in
  addition to the above.

 Andy Parkins (1):
  Have git-cvsserver call hooks/update before really altering the ref

 Fredrik Kuivinen (2):
  Read the config in rev-list
  Documentation/i18n.txt: it is i18n.commitencoding not core.commitencoding

 Johannes Schindelin (2):
  name-rev: introduce the --refs=<pattern> option
  diff --check: use colour

 Junio C Hamano (9):
  Make gitk work reasonably well on Cygwin.
  gitk: Use show-ref instead of ls-remote
  remotes.not-origin.tagopt
  pretend-sha1: grave bugfix.
  git-merge: minor fix for no_trivial_merge_strategies.
  Do not take mode bits from index after type change.
  Update draft release notes for 1.5.0.1
  Update draft release notes for 1.5.1
  GIT 1.5.0.1

 Mark Levedahl (3):
  gitk - remove trailing whitespace from a few lines.
  Make gitk save and restore the user set window position.
  Make gitk save and restore window pane position on Linux and Cygwin.

 Paul Mackerras (1):
  Change git repo-config to git config

 Shawn O. Pearce (2):
  Attempt to improve git-rebase lead-in description.
  Convert update-index references in docs to add.

 Theodore Ts'o (1):
  Teach git-remote to update existing remotes by fetching from them

 Tommi Kyntola (1):
  git-blame: prevent argument parsing segfault

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-02-14 23:54 Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-02-14 23:54 UTC (permalink / raw)
  To: git

The next maintenance release from 'maint' branch will be 1.5.0.1
when we accumulate enough fixes worth to cut one.

The next feature release from 'master' will be 1.5.1.  I'd like
to have 6 to 8 weeks between releases, so that will be around
end of March or mid-April.  Maybe we can talk about what the
theme for that release should be in a separate thread.

Now the big release is over, I should be able to slow a little
bit down for a few days.


* The 'maint' branch has these fixes since v1.5.0

 Alexandre Julliard (2):
  git-daemon: Avoid leaking the listening sockets into child processes.
  sha1_file.c: Round the mmap offset to half the window size.

 Junio C Hamano (8):
  Documentation: Drop full-stop from git-fast-import title.
  cmd-list: add git-remote
  Makefile: update check-docs target
  Clarify two backward incompatible repository options.
  Still updating 1.5.0 release notes.
  Add RelNotes 1.5.0.1
  Make sure packedgitwindowsize is multiple of (pagesize * 2)
  GIT-VERSION-FILE: check ./version first.

 Nicolas Pitre (1):
  Minor corrections to release notes


* The 'master' branch has these since v1.5.0; this includes all
  of the above.

 Alexandre Julliard (2):
  git-daemon: Avoid leaking the listening sockets into child processes.
  sha1_file.c: Round the mmap offset to half the window size.

 Andy Parkins (2):
  Only show log entries for new revisions in hooks--update
  The "table-of-contents" in the update hook script should match the body

 Johannes Schindelin (2):
  Teach revision machinery about --reverse
  teach diff machinery about --ignore-space-at-eol

 Junio C Hamano (18):
  git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
  Make merge-base a built-in.
  Allow in_merge_bases() to take more than one reference commits.
  Remove git-resolve.
  Remove git-diff-stages.
  Add link to v1.5.0 documentation.
  blame: --show-stats for easier optimization work.
  Documentation: Drop full-stop from git-fast-import title.
  cmd-list: add git-remote
  Makefile: update check-docs target
  Document --ignore-space-at-eol option.
  Add RelNotes 1.5.1
  Point top-level RelNotes link at 1.5.1 release notes being prepared.
  Clarify two backward incompatible repository options.
  Still updating 1.5.0 release notes.
  Add RelNotes 1.5.0.1
  Make sure packedgitwindowsize is multiple of (pagesize * 2)
  GIT-VERSION-FILE: check ./version first.

 Nicolas Pitre (1):
  Minor corrections to release notes

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-13 22:02           ` Jimmy Tang
@ 2007-02-13 23:31             ` Linus Torvalds
  0 siblings, 0 replies; 601+ messages in thread
From: Linus Torvalds @ 2007-02-13 23:31 UTC (permalink / raw)
  To: Jimmy Tang; +Cc: Johannes Schindelin, Randal L. Schwartz, Junio C Hamano, git



On Tue, 13 Feb 2007, Jimmy Tang wrote:
> 
> how about code naming the release(s) with british slang words? since
> ``git'' is a fairly common british slang word (also used quite abit in
> ireland too) to describe an unlikeable person. and since the release is
> going to be cut on the 14th, how about calling it the "snog" release :)

I think that's a great naming convention for releases!

		Linus

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-13 18:37         ` Johannes Schindelin
@ 2007-02-13 22:02           ` Jimmy Tang
  2007-02-13 23:31             ` Linus Torvalds
  0 siblings, 1 reply; 601+ messages in thread
From: Jimmy Tang @ 2007-02-13 22:02 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Randal L. Schwartz, Junio C Hamano, git

Hi All,

On Tue, Feb 13, 2007 at 07:37:03PM +0100, Johannes Schindelin wrote:
> 
> <silly>
> Let's call it "American PI minus one" release. Since Americans love to 
> fsck up the dates, they would write the month first, then the day, 
> which ends up being 2.14, which is exactly PI - 1 rounded to three digits! 
> 
> Alternatively, since they really write 2/14, we could call it the "one 
> seventh" release...
> </silly>
> 

in a totally different direction...

how about code naming the release(s) with british slang words? since
``git'' is a fairly common british slang word (also used quite abit in
ireland too) to describe an unlikeable person. and since the release is
going to be cut on the 14th, how about calling it the "snog" release :)

not too sure how appropriate it would be to name releases after british
slang words as they usually have inappropriate meanings.

Jimmy

-- 
Jimmy Tang
Trinity Centre for High Performance Computing,
Lloyd Building, Trinity College Dublin, Dublin 2, Ireland.
http://www.tchpc.tcd.ie/ | http://www.tchpc.tcd.ie/~jtang

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-13 18:21       ` Randal L. Schwartz
@ 2007-02-13 18:37         ` Johannes Schindelin
  2007-02-13 22:02           ` Jimmy Tang
  0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-13 18:37 UTC (permalink / raw)
  To: Randal L. Schwartz; +Cc: Junio C Hamano, git

Hi,

On Tue, 13 Feb 2007, Randal L. Schwartz wrote:

> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> 
> Junio> I am starting to regret asking that question.  I initially had
> Junio> something related to Feb 14th in mind when I sent the message,
> Junio> but realized it is not as universal as I thought after reading
> Junio> an Wikipedia article.
> 
> The "would have been Randal's Parents' 46th wedding anniversary had
> they not divorced 28 years ago" release? :)
> 
> And I was born exactly nine months later.  Amazing.  Not only that, my brother
> was born the same day a year later.  Can anyone say "wedding night and first
> anniversary"? :)

Okay, okay, I already had one shot, but here's another:

<silly>
Let's call it "American PI minus one" release. Since Americans love to 
fsck up the dates, they would write the month first, then the day, 
which ends up being 2.14, which is exactly PI - 1 rounded to three digits! 

Alternatively, since they really write 2/14, we could call it the "one 
seventh" release...
</silly>

Enough already,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-13 17:33     ` Junio C Hamano
@ 2007-02-13 18:21       ` Randal L. Schwartz
  2007-02-13 18:37         ` Johannes Schindelin
  0 siblings, 1 reply; 601+ messages in thread
From: Randal L. Schwartz @ 2007-02-13 18:21 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Schindelin, git

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

Junio> I am starting to regret asking that question.  I initially had
Junio> something related to Feb 14th in mind when I sent the message,
Junio> but realized it is not as universal as I thought after reading
Junio> an Wikipedia article.

The "would have been Randal's Parents' 46th wedding anniversary had
they not divorced 28 years ago" release? :)

And I was born exactly nine months later.  Amazing.  Not only that, my brother
was born the same day a year later.  Can anyone say "wedding night and first
anniversary"? :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-13 10:15   ` Johannes Schindelin
@ 2007-02-13 17:33     ` Junio C Hamano
  2007-02-13 18:21       ` Randal L. Schwartz
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-13 17:33 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

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

>> Unless there is some last minute showstopper, the final will be
>> cut on Wednesday.  Should I give it a catchy codename?  ;-)
>
> Oh yes, yes, yes! (To both.)
>
> Ciao,
> Dscho
>
> P.S.: How about "The frotzy Nitfol"?

I am starting to regret asking that question.  I initially had
something related to Feb 14th in mind when I sent the message,
but realized it is not as universal as I thought after reading
an Wikipedia article.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-13 14:37     ` Bill Lear
@ 2007-02-13 17:18       ` Randal L. Schwartz
  0 siblings, 0 replies; 601+ messages in thread
From: Randal L. Schwartz @ 2007-02-13 17:18 UTC (permalink / raw)
  To: Bill Lear; +Cc: Junio C Hamano, git

>>>>> "Bill" == Bill Lear <rael@zopyra.com> writes:

Bill> Actually, I think "Wotan" is it...

Wotan Clang?

(Sideways reference to Wu-Tang Clan "music" group.)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-13 13:56   ` Matthias Lederhofer
@ 2007-02-13 16:58     ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-02-13 16:58 UTC (permalink / raw)
  To: Matthias Lederhofer; +Cc: git

Matthias Lederhofer <matled@gmx.net> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> Unless there is some last minute showstopper, the final will be
>> cut on Wednesday.  Should I give it a catchy codename?  ;-)
> Documentation/git-checkout.txt still needs an update about reflogs
> with detached HEAD (the paragraph starting with "The command would
> refuse [..]").

Thanks.  I'd do the following.

---

diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 55c9289..e4ffde4 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -103,22 +103,12 @@ by any branch (which is natural --- you are not on any branch).
 What this means is that you can discard your temporary commits
 and merges by switching back to an existing branch (e.g. `git
 checkout master`), and a later `git prune` or `git gc` would
-garbage-collect them.
-
-The command would refuse to switch back to make sure that you do
-not discard your temporary state by mistake when your detached
-HEAD is not pointed at by any existing ref.  If you did want to
-save your state (e.g. "I was interested in the fifth commit from
-the top of 'master' branch", or "I made two commits to fix minor
-bugs while on a detached HEAD" -- and if you do not want to lose
-these facts), you can create a new branch and switch to it with
-`git checkout -b newbranch` so that you can keep building on
-that state, or tag it first so that you can come back to it
-later and switch to the branch you wanted to switch to with `git
-tag that_state; git checkout master`.  On the other hand, if you
-did want to discard the temporary state, you can give `-f`
-option (e.g. `git checkout -f master`) to override this
-behaviour.
+garbage-collect them.  If you did this by mistake, you can ask
+the reflog for HEAD where you were, e.g.
+
+------------
+$ git log -g -2 HEAD
+------------
 
 
 EXAMPLES

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-13 14:33   ` Bill Lear
@ 2007-02-13 14:37     ` Bill Lear
  2007-02-13 17:18       ` Randal L. Schwartz
  0 siblings, 1 reply; 601+ messages in thread
From: Bill Lear @ 2007-02-13 14:37 UTC (permalink / raw)
  To: Junio C Hamano, git

On Tuesday, February 13, 2007 at 08:33:22 (-0600) Bill Lear writes:
>On Monday, February 12, 2007 at 21:15:41 (-0800) Junio C Hamano writes:
>>It feels like it took me forever to get here, but this is almost
>>it.  The short-log looks huge but only because Shawn's git-gui
>>is now included.
>>
>>Unless there is some last minute showstopper, the final will be
>>cut on Wednesday.  Should I give it a catchy codename?  ;-)
>
>How about "Wodin"?

Actually, I think "Wotan" is it...


Bill

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-13  5:15 ` What's in git.git (stable) Junio C Hamano
  2007-02-13 10:15   ` Johannes Schindelin
  2007-02-13 13:56   ` Matthias Lederhofer
@ 2007-02-13 14:33   ` Bill Lear
  2007-02-13 14:37     ` Bill Lear
  2 siblings, 1 reply; 601+ messages in thread
From: Bill Lear @ 2007-02-13 14:33 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Monday, February 12, 2007 at 21:15:41 (-0800) Junio C Hamano writes:
>It feels like it took me forever to get here, but this is almost
>it.  The short-log looks huge but only because Shawn's git-gui
>is now included.
>
>Unless there is some last minute showstopper, the final will be
>cut on Wednesday.  Should I give it a catchy codename?  ;-)

How about "Wodin"?


Bill

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-13  5:15 ` What's in git.git (stable) Junio C Hamano
  2007-02-13 10:15   ` Johannes Schindelin
@ 2007-02-13 13:56   ` Matthias Lederhofer
  2007-02-13 16:58     ` Junio C Hamano
  2007-02-13 14:33   ` Bill Lear
  2 siblings, 1 reply; 601+ messages in thread
From: Matthias Lederhofer @ 2007-02-13 13:56 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <junkio@cox.net> wrote:
> Unless there is some last minute showstopper, the final will be
> cut on Wednesday.  Should I give it a catchy codename?  ;-)
Documentation/git-checkout.txt still needs an update about reflogs
with detached HEAD (the paragraph starting with "The command would
refuse [..]").

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-13  5:15 ` What's in git.git (stable) Junio C Hamano
@ 2007-02-13 10:15   ` Johannes Schindelin
  2007-02-13 17:33     ` Junio C Hamano
  2007-02-13 13:56   ` Matthias Lederhofer
  2007-02-13 14:33   ` Bill Lear
  2 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-13 10:15 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Mon, 12 Feb 2007, Junio C Hamano wrote:

> It feels like it took me forever to get here, but this is almost
> it.

Congratulations!

> The short-log looks huge but only because Shawn's git-gui is now 
> included.

So, it's a huge-log?

> Unless there is some last minute showstopper, the final will be
> cut on Wednesday.  Should I give it a catchy codename?  ;-)

Oh yes, yes, yes! (To both.)

Ciao,
Dscho

P.S.: How about "The frotzy Nitfol"?

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-02-07 23:21 [ANNOUNCE] GIT 1.5.0-rc4 Junio C Hamano
@ 2007-02-13  5:15 ` Junio C Hamano
  2007-02-13 10:15   ` Johannes Schindelin
                     ` (2 more replies)
  0 siblings, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-02-13  5:15 UTC (permalink / raw)
  To: git

It feels like it took me forever to get here, but this is almost
it.  The short-log looks huge but only because Shawn's git-gui
is now included.

Unless there is some last minute showstopper, the final will be
cut on Wednesday.  Should I give it a catchy codename?  ;-)

* The 'master' branch has these since v1.5.0-rc4

 Alexandre Julliard (3):
  diff.c: Reuse the pprint_rename function for diff --summary output.
  diff.c: Properly quote file names in diff --summary output.
  diff.c: More logical file name quoting for renames in diffstat.

 Aneesh Kumar K.V (1):
  blameview: Move the commit info to a pane below the blame window.

 David Kågedal (5):
  Handle uncommitted changes and cache descriptions
  git-blame.el: improve color handling
  git-blame.el: blame unsaved changes
  git-blame.el: Doc fixes and cleanup
  git-blame.el: Autoupdate while editing

 Dotan Barak (1):
  Make it easier to override path to asciidoc command

 Eric Wong (1):
  git-svn: correctly handle boolean options via git-config

 Jakub Narebski (2):
  git-blame: Add Emacs Lisp file headers and GNU GPL boilerplate
  git-blame: Change installation instructions

 James Bowes (1):
  Read cvsimport options from repo-config

 Johannes Schindelin (4):
  for_each_reflog_ent: be forgiving about missing message
  log --reflog: honour --relative-date
  format-patch -n: make sorting easier by padding number
  log --reflog: use dwim_log

 Junio C Hamano (11):
  create_symref(): create leading directories as needed.
  reflog: handle $name => remotes/%s/HEAD mapping consistently for logs
  Documentation/git-pull: describe default behaviour and config interactions
  git-fetch: document automatic tag following.
  wt_status_prepare(): clean up structure initialization.
  diff_flush_name(): take struct diff_options parameter.
  t4016: test quoting funny pathnames in diff output
  Documentation: git-rebase -C<n>
  Teach git-am to pass -p option down to git-apply
  Add discussion section to git-tag documentation.
  Add RPM target for git-gui

 Linus Torvalds (1):
  git reflog show

 Mark Levedahl (2):
  Make gitk save and restore the user set window position.
  Make gitk save and restore window pane position on Linux and Cygwin.

 Matthias Lederhofer (1):
  git merge documentation: -m is optional

 Michael Loeffler (1):
  import-tars: brown paper bag fix for file mode.

 Michael S. Tsirkin (3):
  Update git-log and git-show documentation
  add -C[NUM] to git-am
  Document that git-am can read standard input.

 Mukund (1):
  Fixed some typos in git-repack docs

 Nicolas Pitre (1):
  remove mailmap.linux

 René Scharfe (1):
  Avoid ugly linewrap in git help

 Shawn O. Pearce (313):
  git-gui: Initial revision.
  git-gui: Additional early feature development.
  git-gui: Fixed UI layout problems on Windows.
  git-gui: Corrected keyboard bindings on Windows, improved state management.
  git-gui: Verify we should actually perform a commit when asked to do so.
  git-gui: Finished commit implementation.
  git-gui: Implemented amended commits.
  git-gui: Misc. nit type of bug fixes.
  git-gui: Started construction of fetch and push operations.
  git-gui: Worked around environment variable problems on Windows.
  git-gui: Reorganized startup procedure to ensure gitdir is right.
  git-gui: Fix menu item accelerator display on Mac OS X.
  git-gui: Correctly handle CR vs. LF within the console of fetch.
  git-gui: Check for fetch or push command failure and denote it.
  git-gui: Don't complain if no .git/remotes exist.
  git-gui: Added current TODO list.
  git-gui: Last minute idea about fetch shortcuts.
  git-gui: Automatically reopen any console closed by the user.
  git-gui: Cache all repo-config data in an array.
  git-gui: Added support for pulling from default branch of a remote.
  git-gui: Updated TODO list now that pull is starting to work.
  git-gui: Corrected diff-index/diff-files protocol parsing errors.
  git-gui: Performance improvements for large file sets.
  git-gui: More performance improvements to rescan logic.
  git-gui: Flip commit message buffer and diff area.
  git-gui: Added repack database menu option, to invoke git repack.
  git-gui: Allow the user to disable update-index --refresh during rescan.
  git-gui: Grab the index lock while running pull.
  git-gui: Pluralize timestamps within the options menu.
  git-gui: Disable pull menu items when the index is locked.
  git-gui: Don't let the user pull into an uncommitted working directory.
  git-gui: Update TODO list.
  git-gui: Bug fix for bad variable reference in display_file.
  git-gui: Changed term 'check-in' to 'include'.
  git-gui: Show only the abbreviated SHA1 after committing.
  git-gui: Cache the GIT_COMMITTER_IDENT value on first sign-off.
  git-gui: Save window geometry to .git/config during exit.
  git-gui: Change accelerator for "Include All" to M1-I.
  git-gui: Created edit menu and basic editing bindings.
  git-gui: Clear undo/redo stack when loading a message file from disk.
  git-gui: Updated TODO list now that geometry is stored.
  git-gui: Always indicate the file in the diff viewer.
  git-gui: Correctly handle files containing LF in their name.
  git-gui: Efficiently update the UI after committing.
  git-gui: Use catch rather than array names to check file.
  git-gui: Rename difffont/mainfont variables.
  git-gui: Use native tk_messageBox for errors.
  git-gui: Cleaned up error message formatting.
  git-gui: Simplified format of geometry configuration.
  git-gui: Misc. formatting cleanups.
  git-gui: Misc. bug fixes for mouse click crashes.
  git-gui: Added context menus for consoles and commit message buffer.
  git-gui: Fix mouse cursor behavior when in widgets.
  git-gui: Teach sign off to be more intelligent.
  git-gui: Corrected font used for options menu items.
  git-gui: Honor system font and let user configure fonts.
  git-gui: Allow the user to change the diff viewer font size.
  git-gui: Refresh a file if it has an empty diff.
  git-gui: Make use of the Tk font system rather than faking it.
  git-gui: Improve right click context menu binding on all platforms.
  git-gui: Rename quitting global to is_quitting.
  git-gui: Use arrow cursor rather than left_ptr.
  git-gui: Refactor options menu into an options dialog.
  git-gui: Allow the user to manipulate the fonts from the options panel.
  git-gui: Supply progress feedback when running update-index.
  git-gui: Minor options dialog UI cleanups.
  git-gui: Added Options... menu item to end of diff context menu.
  git-gui: Use 'after 1' to post UI rather than tkwait.
  git-gui: Correct bugs in font config handling.
  git-gui: Hide non-commit related commands when invoked as git-citool.
  git-gui: Don't load the global options unless necessary.
  git-gui: Allow the user to disable diff stat summary during pull.
  git-gui: Run the pre-commit hook in the background.
  git-gui: Remove the commit_active global variable.
  git-gui: Added post-commit invocation after the commit is done.
  git-gui: Always use eq/ne for string comparsions.
  git-gui: Reshow diff if we sent the file to update-index.
  git-gui: Cleanup diff construction code to prepare for more options.
  git-gui: Allow the user to control the number of context lines in a diff.
  git-gui: Sort the list of paths being updated in the index.
  git-gui: Use a smaller pipe buffer for update-index.
  git-gui: Allow the user to copy name of the file in the diff viewer.
  git-gui: Correct language for M_/A_ status codes.
  git-gui: Display status on left in diff header.
  git-gui: Minor UI layout improvements for console windows.
  git-gui: Reverted file name text field to a label.
  git-gui: By default don't allow partially included files.
  git-gui: Refactor mouse clicking on file names/icons.
  git-gui: Narrow the no differences information message.
  git-gui: Implemented multiple selection in file lists.
  git-gui: Refactor update_status -> rescan.
  git-gui: Provide an after-rescan script to rescan.
  git-gui: Allow update_index to also run a script when it completes.
  git-gui: Automatically update-index all included files before commit.
  git-gui: Disable diff actions when no diff is active.
  git-gui: Created makefile to install the program.
  git-gui: Correctly handle GIT_DIR environment variable.
  git-gui: Create Windows shortcut icons for git-gui.
  git-gui: Protect ourselves from funny GIT_DIR/working directory setups.
  git-gui: Handle ' within paths when creating Windows shortcuts.
  git-gui: Only populate a fetch or push if we have an action.
  git-gui: Create a .app file on MacOS X if requested.
  git-gui: Display error dialog on Mac OS X when no .git found.
  git-gui: Make initial commits work properly.
  git-gui: Only reshow diff when really necessary.
  git-gui: Refactor file state representations.
  git-gui: Add menu option to include only selected files.
  git-gui: Misc. comment formatting cleanups.
  git-gui: Start UI with the index locked.
  git-gui: Remove completed items from TODO list.
  git-gui: Toggle between new commit and amend commit modes.
  git-gui: Verify the user has GIT_COMMITTER_IDENT before comitting.
  git-gui: Rephrase rescan before commit informational message.
  git-gui: Allow adding untracked files in selection.
  git-gui: Don't create PkgInfo on Mac OS X "desktop icons".
  git-gui: Teach the gui how to uninclude a file.
  git-gui: Make consecutive icon clicks toggle included status of a file.
  git-gui: Correct toggling of deleted file status.
  git-gui: Fix list loading corruption introduced by 1461c5f3.
  git-gui: Describe deleted symlinks in a more friendly way.
  git-gui: Correct toggling of added/untracked status for new files.
  git-gui: Updated TODO list now that a task is complete.
  git-gui: Refactored diff line display formatting logic.
  git-gui: Restore the all important shebang line.
  git-gui: Update in memory states after commit.
  git-gui: Correct some state matchings for include/remove.
  git-gui: Improve handling of merge commits.
  git-gui: Allow users to run fsck-objects from the gui.
  git-gui: Don't save amended commit message buffer.
  git-gui: Reworded verify console title.
  git-gui: Seperate out the database operations in project menu.
  git-gui: Rename Project menu to Repository.
  git-gui: Added about dialog box.
  git-gui: Be more Macintosh like.
  git-gui: Make the copyright notice serve double duty.
  git-gui: Include the Tcl/Tk version in the about dialog.
  git-gui: Abstract out windows platform test to is_Windows proc.
  git-gui: Correct is_MacOSX platform test.
  git-gui: Warn Cygwin users about possible environment issues.
  git-gui: Added configuration editor TODO list.
  git-gui: Refactor M1 binding selection.
  git-gui: Added menu command to visualize all branches.
  git-gui: Don't start 'gitk --all' on Mac OS X.
  git-gui: Improve pull error dialogs.
  git-gui: Added revert changes command.
  git-gui: Display the current branch.
  git-gui: Support file state MD (modified/deleted).
  git-gui: Created Branch menu.
  git-gui: Parse off refs/remotes when showing current branch.
  git-gui: Abort on not implemented branch switching.
  git-gui: Automatically skip tracking branches in branch menu.
  git-gui: Rename all_branches -> all_heads.
  git-gui: Misc. comment and formatting cleanups.
  git-gui: Started implementation of switch_branch.
  git-gui: Set a proper title on our revert confirm dialog box.
  git-gui: Updated todo list.
  git-gui: Enable resolution of merge conflicts.
  git-gui: Auto-update any A? or M? files during rescan.
  git-gui: Reworded 'Include' to 'Add' to match core Git.
  git-gui: Created very crude Tools menu, to support miga.
  git-gui: Show all fetched branches for remote pulls.
  git-gui: Run git-gc rather than git-repack.
  git-gui: Corrected behavior of deleted (but existing in HEAD) files.
  git-gui: Correct wording of the revert confirmation dialog.
  git-gui: Work around odd cygpath bug on Windows.
  git-gui: Change more 'include' language to 'add'.
  git-gui: Hide the ugly bash command line from the windows desktop icon.
  git-gui: Modified makefile to embed version into git-gui script.
  git-gui: Display the git-gui version in the Help->About dialog.
  git-gui: Display the full GPL copyright notice in about dialog.
  git-gui: Ensure version number is always current.
  git-gui: Allow the user to copy the version data to the clipboard.
  git-gui: Don't offer my miga hack if its configuration file isn't present.
  git-gui: Suggest when running 'git gc' may be worthwhile.
  git-gui: Refactor reponame computation.
  git-gui: Cleanup usage of gitdir global variable.
  git-gui: Allow [gitdir ...] to act as [file join [gitdir] ...].
  git-gui: Make the gitk starting message match our usual format.
  git-gui: Display the directory we are entering during startup.
  git-gui: Start file status display refactoring.
  git-gui: Convert UI to use 'staged for commit' interface.
  git-gui: Correct DD file state to be only D_.
  git-gui: Remove invalid DM state.
  git-gui: Cleanup state descriptions.
  git-gui: Refactor add/remove proc names to align with reality.
  git-gui: Add or unstage based on the specific icon used.
  git-gui: Refactor the revert (aka checkout-index) implementation.
  git-gui: Refactor the add to commit state filters.
  git-gui: Simplify printing of index info to update-index.
  git-gui: Only permit selection in one list at a time.
  git-gui: Pad the cancel/save buttons in the options window.
  git-gui: Implemented create branch GUI.
  git-gui: Bind M1-N to create branch.
  git-gui: Implemented local branch deletion.
  git-gui: Allow users to delete branches merged upstream.
  git-gui: Allow creating branches from tracking heads.
  git-gui: Use borders on text fields in branch dialog.
  git-gui: Remove 'Allow Partially Added Files' option.
  git-gui: Move commit_prehook into commit_tree.
  git-gui: Improve the branch delete confirmation dialogs.
  git-gui: Don't delete the test target branch.
  git-gui: Attempt to checkout the new branch after creation.
  git-gui: Refactor current_diff -> current_diff_path.
  git-gui: Remove combined diff showing behavior.
  git-gui: Improve the display of merge conflicts.
  git-gui: Improve diff --cc viewing for unmerged files.
  git-gui: Fix bug in unmerged file display.
  git-gui: Clear diff from viewer if the side changed.
  git-gui: Correct disappearing unstaged files.
  git-gui: Add Refresh to diff viewer context menu.
  git-gui: Correct unmerged file detection at commit time.
  git-gui: Pad new branch name input box.
  git-gui: Use a grid layout for branch dialog.
  git-gui: Improve the merge check interface for branch deletion.
  git-gui: Change rude error popup to info popup.
  git-gui: Correctly ignore '* Unmerged path' during diff.
  git-gui: Make diff viewer colors match gitk's defaults.
  git-gui: Never line wrap in file lists.
  git-gui: Don't offer tracking branches if none exist.
  git-gui: Give a better error message on an empty branch name.
  git-gui: Allow user to specify a branch name pattern.
  git-gui: Improve keyboard traversal in dialogs.
  git-gui: Fully select a field when entering into it.
  git-gui: Automatically toggle the relevant radio buttons.
  git-gui: Correctly categorize tracking branches and heads.
  git-gui: Update todo list with finished and new items.
  git-gui: Slightly tweak new window geometry.
  git-gui: Create missing branch head on initial commit.
  git-gui: Don't format the mode line of a diff.
  git-gui: Force an update-index --refresh on unchanged files.
  git-gui: Don't attempt to tag new file/deleted file headers in diffs.
  git-gui: Fix 'Select All' action on Windows.
  git-gui: Ignore 'No newline at end of file' marker line.
  git-gui: Always start a rescan on an empty diff.
  git-gui: Don't show content of untracked binary files.
  git-gui: Limit display of large untracked files.
  git-gui: When possible show the type of an untracked file.
  git-gui: Don't try to tag the 'Binary files * and * differ' line.
  git-gui: Remove spurious newline in untracked file display.
  git-gui: Honor system encoding for filenames.
  git-gui: Handle commit encoding better.
  git-gui: Display database stats (count-objects -v) on demand.
  git-gui: Implement basic branch switching through read-tree.
  git-gui: Use system default labelframe bordering.
  git-gui: Display the size of the pack directory.
  git-gui: Only allow Refresh in diff context menu when we have a diff.
  git-gui: Allow staging/unstaging individual diff hunks.
  git-gui: Elide CRs appearing in diff output from display.
  git-gui: Cleanup end-of-line whitespace in commit messages.
  git-gui: Unset unnecessary UI setup variable.
  git-gui: Force focus to the diff viewer on mouse click.
  git-gui: Support 'Visualize All Branches' on Mac OS X.
  git-gui: Pad the database statistics dialog window.
  git-gui: Prefer Tk's entry widget over a 1 line text field.
  git-gui: Remove Pull menu and cleanup Branch/Fetch/Push menus.
  git-gui: Don't switch branches if changing to the current branch.
  git-gui: Maintain the same file list for diff during refresh.
  git-gui: Always use lsearch -exact, to prevent globbing.
  git-gui: Added arbitrary branch pushing support.
  git-gui: Remove no longer used pull from remote code.
  git-gui: Always use -v option to push.
  git-gui: Refactor console success/failure handling.
  git-gui: Use builtin version of 'git gc'.
  git-gui: Implement local merge operations.
  git-gui: Let users abort with `reset --hard` type logic.
  git-gui: Update status bar during a merge.
  git-gui: Don't allow users to commit a bad octopus merge.
  git-gui: Don't allow merges in the middle of other things.
  git-gui: Always offer scrollbars for branch lists.
  git-gui: Support merge.summary, merge.verbosity.
  git-gui: Reword meaning of merge.summary.
  git-gui: Offer quick access to the HTML formatted documentation.
  git-gui: Test for Cygwin differently than from Windows.
  git-gui: Implemented file browser and incremental blame.
  git-gui: Improve the icons used in the browser display.
  git-gui: Display the current branch name in browsers.
  git-gui: Allow users to edit user.name, user.email from options.
  git-gui: Use -M and -C when running blame.
  git-gui: Correctly handle spaces in filepaths.
  git-gui: Display original filename and line number in blame.
  git-gui: Install column headers in blame viewer.
  git-gui: Use a grid layout for the blame viewer.
  git-gui: Assign background colors to each blame hunk.
  Correct ^0 asciidoc syntax in fast-import docs.
  Correct some language in fast-import documentation.
  Correct spelling of fast-import in docs.
  tar archive frontend for fast-import.
  git-gui: Update known branches during rescan.
  git-gui: Support keyboard traversal in browser.
  git-gui: Replace \ with \\ when showing paths.
  git-gui: Refactor single_commit to a proc.
  git-gui: Separate transport/branch menus from multicommit.
  git-gui: Optionally save commit buffer on exit.
  git-gui: View blame from the command line.
  git-gui: Select subcommands like git does.
  git-gui: Relabel the Add All action.
  git-gui: Use git-config now over git-repo-config.
  git-gui: Redesign the display of annotated files.
  git-gui: Jump to the first annotation block as soon as its available.
  git-gui: Improve annotated file display.
  git-gui: Focus into blame panels on Mac OS.
  git-gui: Stop deleting gitk preferences.
  fast-import: Hide the pack boundary commits by default.
  fast-import: Add tip about importing renames.
  bash: Hide git-fast-import.
  fast-import: Support reusing 'from' and brown paper bag fix reset.
  git-gui: Allow gitexecdir, INSTALL to be set by the caller.
  git-gui: Rename GIT_VERSION to GITGUI_VERSION.
  git-gui: Generate a version file on demand.
  git-gui: Handle gitgui tags in version gen.
  git-gui: Guess our version accurately as a subproject.
  git-gui: Change base version to 0.6.
  Link git-gui into the master Makefile.

 Theodore Ts'o (2):
  Print a sane error message if an alias expands to an invalid git command
  Allow aliases to expand to shell commands

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-04 21:34         ` Jakub Narebski
@ 2007-02-04 22:25           ` David Kågedal
  0 siblings, 0 replies; 601+ messages in thread
From: David Kågedal @ 2007-02-04 22:25 UTC (permalink / raw)
  To: git; +Cc: jnareb

Jakub Narebski <jnareb@gmail.com> writes:

> Theodore Tso wrote:
>> On Sun, Feb 04, 2007 at 11:12:34AM -0800, Linus Torvalds wrote:
>>> On Sun, 4 Feb 2007, Jeff King wrote:
>>>> 
>>>> Just a thought, but it might be useful to blame the contents of an
>>>> arbitrary file (but starting the history at a given pathname). Something
>>>> like "git blame --contents /tmp/foo.c file.c", with contents defaulting
>>>> to "file.c". There's much discussion of editor interfaces, and this
>>>> leaves the possibility of git-blaming the contents of the editor buffer
>>>> (after writing it out to a temp file) without having to save changes to
>>>> the working tree file.
>>> 
>>> I agree, that probably would make most sense. If we do this at all. On the 
>>> other hand, I suspect that most editors would probably want to pipe the 
>>> contents to the program, not write it to a temp-file.
>> 
>> ... and use it with --incremental, as well.  In emacs you can have the
>> annotation take place as it is being written out relatively easily, by
>> arranging to have a callback function get called each time more
>> information is handed back to emacs via a pipe.
>
> So perhaps instead of "git blame --contents /tmp/foo.c file.c" we should
> have "cat /tmp/foo.c | git blame --stdin file.c", hmmm? Editor would then
> pipe current contents of the buffer to "git blame --stdin --incremental
> file.c" (where file.c is the name in tree/in HEAD).

But if we allow the standard convention of using - to mean stdin, the
--contents option would be more flexible, since "--contents -" would
just be a special case.

-- 
David Kågedal

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-04 20:58       ` Theodore Tso
@ 2007-02-04 21:34         ` Jakub Narebski
  2007-02-04 22:25           ` David Kågedal
  0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2007-02-04 21:34 UTC (permalink / raw)
  To: git

Theodore Tso wrote:
> On Sun, Feb 04, 2007 at 11:12:34AM -0800, Linus Torvalds wrote:
>> On Sun, 4 Feb 2007, Jeff King wrote:
>>> 
>>> Just a thought, but it might be useful to blame the contents of an
>>> arbitrary file (but starting the history at a given pathname). Something
>>> like "git blame --contents /tmp/foo.c file.c", with contents defaulting
>>> to "file.c". There's much discussion of editor interfaces, and this
>>> leaves the possibility of git-blaming the contents of the editor buffer
>>> (after writing it out to a temp file) without having to save changes to
>>> the working tree file.
>> 
>> I agree, that probably would make most sense. If we do this at all. On the 
>> other hand, I suspect that most editors would probably want to pipe the 
>> contents to the program, not write it to a temp-file.
> 
> ... and use it with --incremental, as well.  In emacs you can have the
> annotation take place as it is being written out relatively easily, by
> arranging to have a callback function get called each time more
> information is handed back to emacs via a pipe.

So perhaps instead of "git blame --contents /tmp/foo.c file.c" we should
have "cat /tmp/foo.c | git blame --stdin file.c", hmmm? Editor would then
pipe current contents of the buffer to "git blame --stdin --incremental
file.c" (where file.c is the name in tree/in HEAD).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-04 19:12     ` Linus Torvalds
@ 2007-02-04 20:58       ` Theodore Tso
  2007-02-04 21:34         ` Jakub Narebski
  0 siblings, 1 reply; 601+ messages in thread
From: Theodore Tso @ 2007-02-04 20:58 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Jeff King, Junio C Hamano, git

On Sun, Feb 04, 2007 at 11:12:34AM -0800, Linus Torvalds wrote:
> 
> 
> On Sun, 4 Feb 2007, Jeff King wrote:
> > 
> > Just a thought, but it might be useful to blame the contents of an
> > arbitrary file (but starting the history at a given pathname). Something
> > like "git blame --contents /tmp/foo.c file.c", with contents defaulting
> > to "file.c". There's much discussion of editor interfaces, and this
> > leaves the possibility of git-blaming the contents of the editor buffer
> > (after writing it out to a temp file) without having to save changes to
> > the working tree file.
> 
> I agree, that probably would make most sense. If we do this at all. On the 
> other hand, I suspect that most editors would probably want to pipe the 
> contents to the program, not write it to a temp-file.

... and use it with --incremental, as well.  In emacs you can have the
annotation take place as it is being written out relatively easily, by
arranging to have a callback function get called each time more
information is handed back to emacs via a pipe.

						- Ted

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-04 18:51   ` Jeff King
@ 2007-02-04 19:12     ` Linus Torvalds
  2007-02-04 20:58       ` Theodore Tso
  0 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2007-02-04 19:12 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, git



On Sun, 4 Feb 2007, Jeff King wrote:
> 
> Just a thought, but it might be useful to blame the contents of an
> arbitrary file (but starting the history at a given pathname). Something
> like "git blame --contents /tmp/foo.c file.c", with contents defaulting
> to "file.c". There's much discussion of editor interfaces, and this
> leaves the possibility of git-blaming the contents of the editor buffer
> (after writing it out to a temp file) without having to save changes to
> the working tree file.

I agree, that probably would make most sense. If we do this at all. On the 
other hand, I suspect that most editors would probably want to pipe the 
contents to the program, not write it to a temp-file.

(I think it's a worthy feature, but Junio's patch wasn't exactly pretty, 
so the question boils down to whether it's really worth it).

		Linus

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-02-04  9:36 ` What's in git.git (stable) Junio C Hamano
@ 2007-02-04 18:51   ` Jeff King
  2007-02-04 19:12     ` Linus Torvalds
  0 siblings, 1 reply; 601+ messages in thread
From: Jeff King @ 2007-02-04 18:51 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sun, Feb 04, 2007 at 01:36:29AM -0800, Junio C Hamano wrote:

>  - Teaching "git blame" to also use the working tree files
>    and/or index.  I actually think defaulting to working tree
>    when an explicit HEAD is not given (and --cached to use the
>    one in the index) makes a lot of sense, but I haven't got
>    around to code the latter yet.  Not defaulting to HEAD
>    changes semantics, so if we ever are going to do it, I think
>    we should do so before 1.5.0.

Just a thought, but it might be useful to blame the contents of an
arbitrary file (but starting the history at a given pathname). Something
like "git blame --contents /tmp/foo.c file.c", with contents defaulting
to "file.c". There's much discussion of editor interfaces, and this
leaves the possibility of git-blaming the contents of the editor buffer
(after writing it out to a temp file) without having to save changes to
the working tree file.

Admittedly, I think this will be rare, but if you git-blame from an
editor, it seems awkward to either be inaccurate (by blaming the last
saved working tree file, but comparing it to the buffer) or to save the
file as a side effect.

-Peff

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-02-01  0:26 [ANNOUNCE] GIT 1.5.0-rc3 Junio C Hamano
@ 2007-02-04  9:36 ` Junio C Hamano
  2007-02-04 18:51   ` Jeff King
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-04  9:36 UTC (permalink / raw)
  To: git

Thanks everybody for helping to tie the loose ends for the next
release.

Thanks to Nico's handful updates, I think his "reflog on HEAD
itself" series is ready for inclusion, although tonight's update
still has it parked in 'next' (I did try out 'next' with his
latest for a couple of hours today).  I've already updated the
draft release notes for 1.5.0 (v1.5.0.txt in todo branch), with
its inclusion in mind.

I've re-read the three tutorials and tried to fix them up
somewhat to match the recent reality.  I'd appreciate somebody
can look at JBF's user manual.

Several things to note (in the following, substitute $gmane with
http://article.gmane.org/gmane.comp.version-control.git):

 - Working around Tk geometry problem, especially on non Linux+X
   platforms.  I've forwarded Mark Levedahl's patches
   ($gmane/38361) to Paul Mackerras for his blessing; hopefully
   he can Ack and/or suggest improvements.  I'd really like to
   have them in 1.5.0 in some form.

 - Nico's "reflog on HEAD".  I'll merge this tomorrow (I just
   ran out of time today).  I will re-try to break its "git
   reflog expire --stale-fix --all" before actually merging it,
   though.

 - Reverting the patch to allow tracking branch names as the
   value of branch.*.merge ($gmane/38621).  I think it is a good
   idea to revert this before 1.5.0 gets out; just haven't got
   around to do so.

 - Teaching "git blame" to also use the working tree files
   and/or index.  I actually think defaulting to working tree
   when an explicit HEAD is not given (and --cached to use the
   one in the index) makes a lot of sense, but I haven't got
   around to code the latter yet.  Not defaulting to HEAD
   changes semantics, so if we ever are going to do it, I think
   we should do so before 1.5.0.

 - Preventing push from updating the current branch of non-bare
   repository.  I think doing so unconditionally is a bad idea
   (and I have Linus's veto to back it up $gmane/38592), but I
   suspect most people would want the default to be less
   confusing to new people.  If we are ever going to forbid by
   default and allow pusher to force, that would be a behaviour
   change and it would be better to do so before 1.5.0.

 - We might want to allow git-push to use the wildcard refspec,
   like git-fetch does, for symmetry.  It would make the
   mothership-satellite arrangement much more natural
   ($gname/38549).  Unfortunately I haven't had a chance to
   start coding it.  I think however this could be added post
   1.5.0.

 - "git remote add -t -f -m" and rewrite of "git clone" based on
   it ($gmane/38470, $gmane/38545).  While I think this leads us
   in right direction, I do not think 1.5.0 needs to wait for
   it.  Certainly I do not want to reimplement "git clone"
   before 1.5.0, although I think the additions to "git remote add"
   are relatively safe.

 - Catering to filesystems whose readdir() returns pathnames
   that are different from what are used when they were creat()ed
   will not happen ($gmane/38620).


* The 'master' branch has these since v1.5.0-rc3.

 Andy Parkins (1):
  doc: hooks.txt said post-commit default sends an email, it doesn't

 Eric Wong (2):
  git-svn: do not let Git.pm warn if we prematurely close pipes
  Disallow invalid --pretty= abbreviations

 Johannes Schindelin (2):
  Teach the '@{...}' notation to git-log -g
  Update the documentation for the new '@{...}' syntax

 Junio C Hamano (9):
  detached HEAD -- finishing touches
  Use "git checkout -q" in git-bisect
  Tutorial: fix asciidoc formatting of "git add" section.
  Tutorial-2: Adjust git-status output to recent reality.
  core-tutorial: http reference link fix
  fix reflog entries for "git-branch"
  honor GIT_REFLOG_ACTION in git-commit
  Why is it bad to rewind a branch that has already been pushed out?
  combine-diff: special case --unified=0

 Mike Coleman (1):
  Fix some documentation typos and grammar

 Nicolas Pitre (4):
  reword the detached head message a little again
  add a quiet option to git-checkout
  prevent HEAD reflog to be interpreted as current branch reflog
  provide a nice @{...} syntax to always mean the current branch reflog

 Pavel Roskin (2):
  git-config --rename-section could rename wrong section
  Assorted typo fixes

 Shawn O. Pearce (18):
  Pull out remote listing functions in git-remote.
  Teach 'git remote' how to cleanup stale tracking branches.
  Cleanup prepare_packed_git_one to reuse install_packed_git.
  Correct comment in prepare_packed_git_one.
  Refactor open_packed_git to return an error code.
  Don't find objects in packs which aren't available anymore.
  Don't leak file descriptors from unavailable pack files.
  Cleanup subcommand documentation for git-remote.
  Keep untracked files not involved in a merge.
  Default GIT_MERGE_VERBOSITY to 5 during tests.
  bash: Remove short option completions for branch/checkout/diff.
  bash: Classify cat-file and reflog as plumbing.
  bash: Complete long options to git-add.
  bash: Add space after unique command name is completed.
  bash: Classify more commends out of completion.
  bash: Support unique completion on git-config.
  bash: Support unique completion when possible.
  bash: Support internal revlist options better.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-01-28 19:34 ` Bill Lear
@ 2007-01-28 20:06   ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-01-28 20:06 UTC (permalink / raw)
  To: Bill Lear; +Cc: git

Bill Lear <rael@zopyra.com> writes:

> On Saturday, January 27, 2007 at 00:05:56 (-0800) Junio C Hamano writes:
>>I am hoping that we can declare -rc3 and go into a deep freeze
>>after merging Shawn's "describe with accumulated commits since"
>>and Nico's "reflog on HEAD", perhaps by end of the month.
>
> Was there any final decision on allowing pushes through git-daemon?

Not really.  I personally think it is Ok as long as the default
stays disabled as Linus posted.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-01-27  8:05 Junio C Hamano
  2007-01-27  8:59 ` Aneesh Kumar K.V
  2007-01-27 17:56 ` J. Bruce Fields
@ 2007-01-28 19:34 ` Bill Lear
  2007-01-28 20:06   ` Junio C Hamano
  2 siblings, 1 reply; 601+ messages in thread
From: Bill Lear @ 2007-01-28 19:34 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Saturday, January 27, 2007 at 00:05:56 (-0800) Junio C Hamano writes:
>I am hoping that we can declare -rc3 and go into a deep freeze
>after merging Shawn's "describe with accumulated commits since"
>and Nico's "reflog on HEAD", perhaps by end of the month.

Was there any final decision on allowing pushes through git-daemon?


Bill

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-01-27  8:59 ` Aneesh Kumar K.V
  2007-01-27 18:06   ` J. Bruce Fields
@ 2007-01-27 22:00   ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-01-27 22:00 UTC (permalink / raw)
  To: Aneesh Kumar K.V; +Cc: git

"Aneesh Kumar K.V" <aneesh.kumar@gmail.com> writes:

> What about the final version of this doc
> [DRAFT] Branching and merging with git from
> http://www.gelato.unsw.edu.au/archives/git/0611/31902.html

What about it?

The last time I said I was interested in the latest incarnation
of it, the response was "will be reposted soon" and we never
heard about it after that, I think.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-01-27  8:59 ` Aneesh Kumar K.V
@ 2007-01-27 18:06   ` J. Bruce Fields
  2007-01-27 22:00   ` Junio C Hamano
  1 sibling, 0 replies; 601+ messages in thread
From: J. Bruce Fields @ 2007-01-27 18:06 UTC (permalink / raw)
  To: Aneesh Kumar K.V; +Cc: Junio C Hamano, git

On Sat, Jan 27, 2007 at 02:29:15PM +0530, Aneesh Kumar K.V wrote:
> Junio C Hamano wrote:
> 
> >
> >I'd like to take a look at JBF's manual and merge it early -- I
> >fed some small changes to him some time ago but did not have
> >chance to review its recent progress.  It deserves attention
> >from wider audience.
> >
> 
> What about the final version of this doc
> [DRAFT] Branching and merging with git from 
> http://www.gelato.unsw.edu.au/archives/git/0611/31902.html

I haven't seen anything from him in a while.

If anyone wants to point out material from that document that they found
particularly helpful, I'd be happy to help incorporate something
similar.  But I feel a little uneasy taking large chunks of it without
the author's go-ahead.

--b.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-01-27  8:05 Junio C Hamano
  2007-01-27  8:59 ` Aneesh Kumar K.V
@ 2007-01-27 17:56 ` J. Bruce Fields
  2007-01-28 19:34 ` Bill Lear
  2 siblings, 0 replies; 601+ messages in thread
From: J. Bruce Fields @ 2007-01-27 17:56 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sat, Jan 27, 2007 at 12:05:56AM -0800, Junio C Hamano wrote:
> I'd like to take a look at JBF's manual and merge it early -- I
> fed some small changes to him some time ago but did not have
> chance to review its recent progress.  It deserves attention
> from wider audience.

That would be great, thanks.

At this point I'm most interested in higher-level questions: Are things
in a sensible order?  What's the most important material that's not
covered?  Etc.  Not that fixes to the details aren't helpful too, of
course.

It still feels really rough, so I'm expecting it to take some time
before we'd want to point newbies to it as the place to go for an
in-depth git introduction.

--b.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2007-01-27  8:05 Junio C Hamano
@ 2007-01-27  8:59 ` Aneesh Kumar K.V
  2007-01-27 18:06   ` J. Bruce Fields
  2007-01-27 22:00   ` Junio C Hamano
  2007-01-27 17:56 ` J. Bruce Fields
  2007-01-28 19:34 ` Bill Lear
  2 siblings, 2 replies; 601+ messages in thread
From: Aneesh Kumar K.V @ 2007-01-27  8:59 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano wrote:

> 
> I'd like to take a look at JBF's manual and merge it early -- I
> fed some small changes to him some time ago but did not have
> chance to review its recent progress.  It deserves attention
> from wider audience.
> 

What about the final version of this doc
[DRAFT] Branching and merging with git from 
http://www.gelato.unsw.edu.au/archives/git/0611/31902.html

-aneesh

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-01-27  8:05 Junio C Hamano
  2007-01-27  8:59 ` Aneesh Kumar K.V
                   ` (2 more replies)
  0 siblings, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-01-27  8:05 UTC (permalink / raw)
  To: git

I am hoping that we can declare -rc3 and go into a deep freeze
after merging Shawn's "describe with accumulated commits since"
and Nico's "reflog on HEAD", perhaps by end of the month.

I haven't looked at the finishing touches from Shawn I received
tonight yet (it is parked in 'pu').  Nico's "reflog on HEAD"
looked good (also parked in 'pu'), but I think it needs to teach
the repack/prune/fsck/reflog-expire machinery about reflog
entries for HEAD -- otherwise a prune can make reflog useless
while your HEAD is detached (which may not be a big deal and
while I do not deeply care personally, it would be better to
consistently protect them like reflog entries for regular refs).

Although it is tempting to start futzing with prune and ancestry
traversal so that commits hidden by grafts are not lost by it,
which was brought up today, I think it should be better dealt
with after 1.5.0 (it is not a recent regression).

I'd like to take a look at JBF's manual and merge it early -- I
fed some small changes to him some time ago but did not have
chance to review its recent progress.  It deserves attention
from wider audience.

* The 'master' branch has these since v1.5.0-rc2.

  Alex Riesen (4):
    Insert ACTIVESTATE_STRING in Git.pm
    Force Activestate Perl to tie git command pipe handle to a handle class
    Cleanup uninitialized value in chomp
    Allow default core.logallrefupdates to be overridden with template's
       config

  Alexandre Julliard (1):
    vc-git.el: Take into account the destination name in vc-checkout.

  Andy Parkins (2):
    New files in git weren't being downloaded during CVS update
    If abbrev is set to zero in git-describe, don't add the unique suffix

  Eric Wong (1):
    git-svn: remove leading slash when printing removed directories

  Jakub Narebski (3):
    Documentation/config.txt: Document config file syntax better
    t/t1300-repo-config.sh: value continued on next line
    Documentation/config.txt: Correct info about subsection name

  Jason Riedy (1):
    Use inttypes.h rather than stdint.h.

  Jeff King (3):
    format-patch: fix bug with --stdout in a subdirectory
    contrib/vim: update syntax for changed commit template
    diffcore-pickaxe: fix infinite loop on zero-length needle

  Johannes Schindelin (2):
    annotate: use pager
    reflog inspection: introduce shortcut "-g"

  Junio C Hamano (25):
    Documentation/tutorial-2: Fix interesting typo in an example.
    Revert "prune: --grace=time"
    Make sure git_connect() always give two file descriptors.
    is_repository_shallow(): prototype fix.
    shallow repository: disable unsupported operations for now.
    git-gc: do not run git-prune by default.
    cvsimport: activate -a option, really.
    .mailmap: fix screw-ups in Uwe's name
    honor --author even with --amend, -C, and -c.
    reflog gc: a tag that does not point at a commit is not a crime.
    git-checkout -m: fix merge case
    git-daemon documentation on enabling services.
    ls-remote and clone: accept --upload-pack=<path> as well.
    Refactor the pack header reading function out of receive-pack.c
    Allow fetch-pack to decide keeping the fetched pack without exploding
    fetch-pack: remove --keep-auto and make it the default.
    Consolidate {receive,fetch}.unpackLimit
    Allow non-developer to clone, checkout and fetch more easily.
    parse-remote: do not barf on a remote shorthand without any refs to fetch.
    show-branch -g: default to HEAD
    Documentation: pack-refs --all vs default behaviour
    Make sure we do not write bogus reflog entries.
    git-merge: leave sensible reflog message when used as the first level UI.
    create_symref: check error return from open().
    write_in_full: size_t is unsigned.

  Linus Torvalds (3):
    fsck-objects: refactor checking for connectivity
    Fix seriously broken "git pack-refs"
    Add dangling objects tips.

  Nicolas Pitre (1):
    fix suggested branch creation command when detaching head

  Peter Eriksen (2):
    sha1_file.c: Avoid multiple calls to find_pack_entry().
    Documentation: --amend cannot be combined with -c/-C/-F.

  Sam Vilain (1):
    contrib/emacs/vc-git.el: support vc-version-other-window

  Shawn O. Pearce (1):
    Remove unnecessary found variable from describe.

  Uwe Kleine-König (2):
    rename --exec to --upload-pack for fetch-pack and peek-remote
    make --upload-pack option to git-fetch configurable

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-01-10  8:24 Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-01-10  8:24 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since the last announcement.

  Junio C Hamano (2):
     Do not ignore a detected patchfile brokenness.
     Fix "Do not ignore a detected patchfile brokenness."

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

  Two rather big changes are included: sliding mmap; UTF-8 is
  default for e-mail acceptance tools.  I am slightly worried
  about the interaction of the latter with git-rebase, though...


  Alexandre Julliard (3):
     git-apply: Remove directories that have become empty after deleting a file.
     git-clone: Make sure the master branch exists before running cat on it.
     git.el: Define the propertize function if needed, for XEmacs compatibility.

  Andy Whitcroft (5):
     ssh-upload: prevent buffer overrun
     short i/o: clean up the naming for the write_{in,or}_xxx family
     short i/o: fix calls to read to use xread or read_in_full
     short i/o: fix calls to write to use xwrite or write_in_full
     short i/o: fix config updates to use write_in_full

  Brian Gernhardt (2):
     Ignore git-init and git-remote
     Auto-quote config values in config.c:store_write_pair()

  Eric Wong (2):
     git-svn: add --prefix= option to multi-init
     git-svn: pass an unambiguous ref to rev-list when grafting-branches

  J. Bruce Fields (2):
     Documentation: clarify definition of "reachable"
     Documentation: add git-remote man page

  Jakub Narebski (2):
     gitweb: Remove superfluous "|" in "commit" view
     gitweb: Fix git_patchset_body not closing <div class="patch">

  Jeff King (1):
     get_tree_entry: map blank requested entry to tree root

  Junio C Hamano (21):
     pack-objects: fix use of use_pack().
     mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()
     git-remote
     builtin-prune: make file-scope static struct to an argument.
     builtin-prune: separate ref walking from reflog walking.
     Move traversal of reachable objects into a separate library.
     reflog expire --fix-stale
     reflog --fix-stale: do not check the same trees and commits repeatedly.
     diff-index --cached --raw: show tree entry on the LHS for unmerged entries.
     git-reset <tree> -- <path> restores absense of <path> in <tree>
     Spell default packedgitlimit slightly differently
     --utf8 is now default for 'git-am'
     --prune is now default for 'pack-refs'
     rm git-rerere.perl -- it is now a built-in.
     merge-base: do not leak commit list
     Do not ignore a detected patchfile brokenness.
     Fix "Do not ignore a detected patchfile brokenness."
     builtin-archive: do not free a tree held by the object layer.
     git-am: should work when "--no-utf8 --utf8" is given
     -u is now default for 'git-applymbox'
     -u is now default for 'git-mailinfo'.

  Jürgen Rühle (5):
     Clarify syntax and role of git-add in status output
     Improve "nothing to commit" part of status output
     Support --amend on initial commit in status output
     Improve cached content header of status output
     Remove unnecessary git-rm --cached reference from status output

  Martin Langhoff (6):
     cvsimport: skip commits that are too recent
     cvsimport: skip commits that are too recent (option and documentation)
     cvsimport: document -S and -L options
     cvsimport: cleanup temporary cvsps file
     cvsserver: detect early of we are up to date and avoid costly rev-list
     cvsserver: fix revision number during file adds

  Michael Loeffler (1):
     git-commit: do not fail to print the diffstat even if there is a file named HEAD

  Nicolas Pitre (1):
     "init-db" can really be just "init"

  Pavel Roskin (1):
     Fix warnings in sha1_file.c - use C99 printf format if available

  Sasha Khapyorsky (1):
     git-svnimport: fix edge revisions double importing

  Shawn O. Pearce (25):
     Replace unpack_entry_gently with unpack_entry.
     Introduce new config option for mmap limit.
     Refactor packed_git to prepare for sliding mmap windows.
     Use off_t for index and pack file lengths.
     Create read_or_die utility routine.
     Refactor how we open pack files to prepare for multiple windows.
     Replace use_packed_git with window cursors.
     Loop over pack_windows when inflating/accessing data.
     Document why header parsing won't exceed a window.
     Unmap individual windows rather than entire files.
     Fully activate the sliding window pack access.
     Load core configuration in git-verify-pack.
     Ensure core.packedGitWindowSize cannot be less than 2 pages.
     Improve error message when packfile mmap fails.
     Support unmapping windows on 'temporary' packfiles.
     Create pack_report() as a debugging aid.
     Test suite for sliding window mmap implementation.
     Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
     Release pack windows before reporting out of memory.
     Replace mmap with xmmap, better handling MAP_FAILED.
     Cleanup read_cache_from error handling.
     Fix random segfaults in pack-objects.
     Update packedGit config option documentation.
     Increase packedGit{Limit,WindowSize} on 64 bit systems.
     Don't die in git-http-fetch when fetching packs.

  Stefan-W. Hahn (1):
     Replacing the system call pread() with lseek()/xread()/lseek() sequence.

  Steven Grimm (1):
     Update git-svn manpage to remove the implication that SVN::* is optional.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-01-10  8:23 Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-01-10  8:23 UTC (permalink / raw)
  To: git

* The 'maint' branch has these fixes since the last announcement.

  Junio C Hamano (2):
     Do not ignore a detected patchfile brokenness.
     Fix "Do not ignore a detected patchfile brokenness."

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

  Two rather big changes are included: sliding mmap; UTF-8 is
  default for e-mail acceptance tools.  I am slightly worried
  about the interaction of the latter with git-rebase, though...


  Alexandre Julliard (3):
     git-apply: Remove directories that have become empty after deleting a file.
     git-clone: Make sure the master branch exists before running cat on it.
     git.el: Define the propertize function if needed, for XEmacs compatibility.

  Andy Whitcroft (5):
     ssh-upload: prevent buffer overrun
     short i/o: clean up the naming for the write_{in,or}_xxx family
     short i/o: fix calls to read to use xread or read_in_full
     short i/o: fix calls to write to use xwrite or write_in_full
     short i/o: fix config updates to use write_in_full

  Brian Gernhardt (2):
     Ignore git-init and git-remote
     Auto-quote config values in config.c:store_write_pair()

  Eric Wong (2):
     git-svn: add --prefix= option to multi-init
     git-svn: pass an unambiguous ref to rev-list when grafting-branches

  J. Bruce Fields (2):
     Documentation: clarify definition of "reachable"
     Documentation: add git-remote man page

  Jakub Narebski (2):
     gitweb: Remove superfluous "|" in "commit" view
     gitweb: Fix git_patchset_body not closing <div class="patch">

  Jeff King (1):
     get_tree_entry: map blank requested entry to tree root

  Junio C Hamano (21):
     pack-objects: fix use of use_pack().
     mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()
     git-remote
     builtin-prune: make file-scope static struct to an argument.
     builtin-prune: separate ref walking from reflog walking.
     Move traversal of reachable objects into a separate library.
     reflog expire --fix-stale
     reflog --fix-stale: do not check the same trees and commits repeatedly.
     diff-index --cached --raw: show tree entry on the LHS for unmerged entries.
     git-reset <tree> -- <path> restores absense of <path> in <tree>
     Spell default packedgitlimit slightly differently
     --utf8 is now default for 'git-am'
     --prune is now default for 'pack-refs'
     rm git-rerere.perl -- it is now a built-in.
     merge-base: do not leak commit list
     Do not ignore a detected patchfile brokenness.
     Fix "Do not ignore a detected patchfile brokenness."
     builtin-archive: do not free a tree held by the object layer.
     git-am: should work when "--no-utf8 --utf8" is given
     -u is now default for 'git-applymbox'
     -u is now default for 'git-mailinfo'.

  Jürgen Rühle (5):
     Clarify syntax and role of git-add in status output
     Improve "nothing to commit" part of status output
     Support --amend on initial commit in status output
     Improve cached content header of status output
     Remove unnecessary git-rm --cached reference from status output

  Martin Langhoff (6):
     cvsimport: skip commits that are too recent
     cvsimport: skip commits that are too recent (option and documentation)
     cvsimport: document -S and -L options
     cvsimport: cleanup temporary cvsps file
     cvsserver: detect early of we are up to date and avoid costly rev-list
     cvsserver: fix revision number during file adds

  Michael Loeffler (1):
     git-commit: do not fail to print the diffstat even if there is a file named HEAD

  Nicolas Pitre (1):
     "init-db" can really be just "init"

  Pavel Roskin (1):
     Fix warnings in sha1_file.c - use C99 printf format if available

  Sasha Khapyorsky (1):
     git-svnimport: fix edge revisions double importing

  Shawn O. Pearce (25):
     Replace unpack_entry_gently with unpack_entry.
     Introduce new config option for mmap limit.
     Refactor packed_git to prepare for sliding mmap windows.
     Use off_t for index and pack file lengths.
     Create read_or_die utility routine.
     Refactor how we open pack files to prepare for multiple windows.
     Replace use_packed_git with window cursors.
     Loop over pack_windows when inflating/accessing data.
     Document why header parsing won't exceed a window.
     Unmap individual windows rather than entire files.
     Fully activate the sliding window pack access.
     Load core configuration in git-verify-pack.
     Ensure core.packedGitWindowSize cannot be less than 2 pages.
     Improve error message when packfile mmap fails.
     Support unmapping windows on 'temporary' packfiles.
     Create pack_report() as a debugging aid.
     Test suite for sliding window mmap implementation.
     Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
     Release pack windows before reporting out of memory.
     Replace mmap with xmmap, better handling MAP_FAILED.
     Cleanup read_cache_from error handling.
     Fix random segfaults in pack-objects.
     Update packedGit config option documentation.
     Increase packedGit{Limit,WindowSize} on 64 bit systems.
     Don't die in git-http-fetch when fetching packs.

  Stefan-W. Hahn (1):
     Replacing the system call pread() with lseek()/xread()/lseek() sequence.

  Steven Grimm (1):
     Update git-svn manpage to remove the implication that SVN::* is optional.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2007-01-02  0:07 Junio C Hamano
@ 2007-01-07  7:43 ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-01-07  7:43 UTC (permalink / raw)
  To: git

I'll do v1.4.4.4 from 'maint' to have grave bugfixes in an
"officially released version" tomorrow, although we will be in
stabilation period for v1.5.0 shortly.

* The 'maint' branch has these fixes since the last announcement.

   Junio C Hamano (2):
      Fix infinite loop when deleting multiple packed refs.
      pack-check.c::verify_packfile(): don't run SHA-1 update on huge data


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

   Alexandre Julliard (3):
      git-clean: Fix the -q option.
      git.el: Don't use --info-only when resolving a file.
      git.el: Avoid setting font lock keywords before entering log-edit mode.

   Andy Whitcroft (1):
      send pack check for failure to send revisions list

   Brian Gernhardt (1):
      Add documentation for git-branch's color configuration.

   Eric Wong (6):
      instaweb: load Apache mime and dir modules if they are needed
      git-svn: make multi-init less confusing
      git-svn: update documentation for multi-{init|fetch}
      git-svn: make --repack work consistently between fetch and multi-fetch
      Documentation/git-svn: clarify dcommit, rebase vs pull/merge
      git-svn: fix show-ignore

   Fredrik Kuivinen (1):
      instaweb: Nicer error message when the http daemon isn't found

   J. Bruce Fields (1):
      Documentation: tutorial editing

   Jakub Narebski (9):
      gitweb: Fix error in git_project_index subroutine
      gitweb: Fix bug in git_difftree_body (was '!=' instead of 'ne')
      gitweb: There can be empty patches (in git_patchset_body)
      gitweb: Fix "Use of uninitialized value" warning in git_tags_body
      gitweb: Fix error in git_patchest_body for file creation/deletion patch
      gitweb: Fix error in "rename to"/"copy to" git diff header output
      gitweb: Fix errors in git_patchset_body for empty patches
      Revert "gitweb: There can be empty patches (in git_patchset_body)"
      gitweb: Fix split patches output (e.g. file to symlink)

   Junio C Hamano (9):
      Remove unused variable (git-commit.sh)
      fetch-pack: do not use lockfile structure on stack.
      Fix infinite loop when deleting multiple packed refs.
      tutorial: misc updates.
      git-verify-tag: make sure we remove temporary file.
      pack-check.c::verify_packfile(): don't run SHA-1 update on huge data
      rerere: Fix removal of already resolved path.
      builtin-prune: memory diet.
      Fix timestamp for test-tick

   Lars Hjemli (2):
      Skip excessive blank lines before commit body
      Refactor print-functions in builtin-branch

   Luben Tuikov (1):
      Blame "linenr" link jumps to previous state at "orig_lineno"

   René Scharfe (3):
      Make check target depend on common-cmds.h
      Remove shadowing variable from traverse_trees()
      Set default "tar" umask to 002 and owner.group to root.root

   Robert Fitzsimons (1):
      gitweb: Fix shortlog only showing HEAD revision.

   Santi Béjar (2):
      Documentation/tutorial: misc updates
      git-tag: add flag to verify a tag

   Sasha Khapyorsky (2):
      git-svnimport: support for incremental import
      git-svnimport: clean svn path when accessing SVN repo

   Steven Grimm (2):
      Describe git-clone's actual behavior in the summary
      Print a more accurate error message when we fail to create a lock file.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2007-01-02  0:07 Junio C Hamano
  2007-01-07  7:43 ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-01-02  0:07 UTC (permalink / raw)
  To: git

A happy new year.

I think this is more-or-less it to start the -rc1 cycle.  

I'll leave the window open for another week or so before people
come back from the christmas and new year break.  I have not
been working on any of the potential changes other people talked
about recently on the list, but things like detached HEAD and
more generic per-branch customization may magically materialize
from somewhere as a robust and usable set of patches.

I also haven't reviewed the introductory documentation set
recently, which I think is necessary before the release.

I'll be sending out an updated draft for v1.5.0 release notes in a
separate message.

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

   Eric Wong (3):
      git-svn: remove svnadmin dependency from the tests
      git-svn: t/t9100-git-svn-basic: remove old check for NO_SYMLINK
      git-svn: t/t91??-*: optimize the tests a bit

   J. Bruce Fields (6):
      Docs: update cvs-migration.txt to reflect clone's new default behavior
      Documentation: update git-clone.txt for clone's new default behavior
      Documentation: update glossary entry for "origin"
      Documentation: update tutorial's discussion of origin
      Documentation: update git-pull.txt for new clone behavior
      Documentation: remove master:origin example from pull-fetch-param.txt

   Junio C Hamano (12):
      send-pack: fix pipeline.
      Documentation: illustrate send-pack pipeline.
      Update documentation for update hook.
      send-pack.c: use is_null_sha1()
      send-pack: tell pack-objects to use its internal rev-list.
      Do not merge random set of refs out of wildcarded refs
      i18n: do not leak 'encoding' header even when we cheat the conversion.
      Update send-pack pipeline documentation.
      fail pull/merge early in the middle of conflicted merge
      git-fetch: remove .keep file at the end.
      Strongly discourage --update-head-ok in fetch-options documentation.
      Update clone/fetch documentation with --depth (shallow clone) option

   Shawn O. Pearce (4):
      Move better_branch_name above get_ref in merge-recursive.
      Allow merging bare trees in merge-recursive.
      Use merge-recursive in git-am -3.
      Add test case for update hooks in receive-pack.

   Theodore Tso (1):
      Fix formatting for urls section of fetch, pull, and push manpages

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2006-12-31  8:07 Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-31  8:07 UTC (permalink / raw)
  To: git

I am happy that we are making steady progress towards v1.5.0,
especially with tonight's handful fixes from Shawn.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

  Jakub Narebski (1):
   Add info about new test families (8 and 9) to t/README

  Johannes Schindelin (1):
   Fix yet another subtle xdl_merge() bug

  Junio C Hamano (12):
   Work around http-fetch built with cURL 7.16.0
   t5400 send-pack test: try a bit more nontrivial transfer.
   Revert "read_directory: show_both option."
   Fix 'git add' with .gitignore
   commit re-encoding: fix confusion between no and default conversion.
   t3900: test log --encoding=none
   Documentation: i18n commit log message notes.
   Documentation: minor rewording for git-log and git-show pages.
   Move commit reencoding parameter parsing to revision.c
   commit-tree: cope with different ways "utf-8" can be spelled.
   i18n: drop "encoding" header in the output after re-coding.
   Documentation/config.txt (and repo-config manpage): mark-up fix.

  Shawn O. Pearce (8):
   Force core.filemode to false on Cygwin.
   Use PATH_MAX constant for --bare.
   Replace "GIT_DIR" with GIT_DIR_ENVIRONMENT.
   Automatically detect a bare git repository.
   Remove unnecessary argc parameter from run_command_v.
   Redirect update hook stdout to stderr.
   Use /dev/null for update hook stdin.
   Teach Git how to parse standard power of 2 suffixes.

  Theodore Ts'o (1):
   Fix formatting for urls section of fetch, pull, and push manpages

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
  2006-12-26  3:22 What's in git.git (stable) and announcing GIT 1.5.0 preview Junio C Hamano
@ 2006-12-29  5:44 ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-29  5:44 UTC (permalink / raw)
  To: git

I've merged a handful topics since v1.5.0-rc0.

 - reflog is now integral part of the data tracked by git, as
   far as local repository is concerned.  You do not have to end
   your sentence with "... but only if you haven't pruned" when
   you tell your users "don't worry, you can get it back with
   master@{2.hours.ago}" anymore.

 - a single command "git gc" would help your repository
   housekeeping chores.

 - shallow-clone capable upload-pack/fetch-pack pair is in.
   Although I think the way they cauterize the ancestry graph
   during the want-have exchange is basically sound, I haven't
   used it extensively and suspect not many people have.  The
   additional code, however, does not seem to harm the normal,
   non-shallow operation in any way; this is to give them wider
   exposure.

 - recording the commit encoding in the new "encoding" header
   and using it together with i18n.{logoutput,commit}encoding
   upon output is also in.  I think Nico's suggestion to use
   LANG also makes sense (perhaps with LC_CTYPE), but haven't
   done that myself yet.

 - git-svn got a handful improvements.

 - segfaulting bug in xdl_merge was fixed.

I'm waiting for ack's to my workaround for http-fetch breakage
when built with cURL 7.16.0, which I would like to resolve
before v1.5.0-rc1.  Also I have a reproducible problem which I
suspect is with Shawn's sliding mmap(), and am hoping we can
ship the sliding mmap() as part of the v1.5.0 after resolving
it.

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

   Alexandre Julliard (6):
      Shallow clone: do not ignore shallowness when following tags
      fetch-pack: Properly remove the shallow file when it becomes empty.
      upload-pack: Check for NOT_SHALLOW flag before sending a shallow to
        the client.
      git-fetch: Reset shallow_depth before auto-following tags.
      get_shallow_commits: Avoid memory leak if a commit has been reached
	already.
      fetch-pack: Do not fetch tags for shallow clones.

   Andy Parkins (1):
      hooks/commit-msg: add example to add Signed-off-by line to message

   Eric Wong (9):
      git-svn: quiet down tests and fix some unportable shell constructs
      git-svn: dcommit should diff against the current HEAD after committing
      t6024-recursive-merge: quiet down this test
      test-lib: quiet down init-db output for tests
      t9200-git-cvsexportcommit.sh: quiet down commit
      git-svn: remove non-delta fetch code paths
      git-svn: print out the SVN library version in --version, too
      git-svn: verify_ref() should actually --verify
      git-svn: sort multi-init output

   Jakub Narebski (2):
      gitweb: Add mod_perl version string to "generator" meta header
      gitweb: Precompile CGI routines for mod_perl

   Jim Meyering (1):
      update hook: redirect _both_ diagnostic lines to stderr upon tag failure

   Johannes Schindelin (6):
      upload-pack: no longer call rev-list
      support fetching into a shallow repository
      allow cloning a repository "shallowly"
      allow deepening of a shallow repository
      add tests for shallow stuff
      xdl_merge(): fix a segmentation fault when refining conflicts

   Junio C Hamano (32):
      We should make sure that the protocol is still extensible.
      Why does it mean we do not have to register shallow if we have one?
      Why didn't we mark want_obj as ~UNINTERESTING in the old code?
      shallow clone: unparse and reparse an unshallowed commit
      add for_each_reflog_ent() iterator
      Protect commits recorded in reflog from pruning.
      Teach git-repack to preserve objects referred to by reflog entries.
      reflog: fix warning message.
      Move in_merge_bases() to commit.c
      git reflog expire
      reflog expire: prune commits that are not incomplete
      reflog expire: do not punt on tags that point at non commits.
      show-branch --reflog: add documentation.
      Document --numstat in git-apply and git-diff
      Document git-reset <commit> -- <paths>...
      Move encoding conversion routine out of mailinfo to utf8.c
      i18n.logToUTF8: convert commit log message to UTF-8
      Teach log family --encoding
      everyday: update for v1.5.0
      count-objects -v: show number of packs as well.
      rerere gc: honor configuration and document it
      git-reflog: gc.* configuration and documentation.
      everyday: replace a few 'prune' and 'repack' with 'gc'
      Use 'repack -a -d -l' instead of 'repack -a -d' in git-gc
      Set NO_MMAP for Cygwin by default
      UTF-8: introduce i18n.logoutputencoding.
      gcc does not necessarily pass runtime libpath with -R
      Rename t3900 test vector file
      t3900: test conversion to non UTF-8 as well
      GIT_SKIP_TESTS: allow users to omit tests that are known to break
      core.logallrefupdates: log remotes/ tracking branches.
      Allow non-fast-forward of remote tracking branches in default clone

   Nicolas Pitre (3):
      add .mailmap for git-shortlog output with the git repository
      Add git-reflog to .gitignore
      move git-blame to its place in .gitignore

   Quy Tonthat (1):
      git-send-email: default value for "From:" field.

   Robert Fitzsimons (1):
      gitweb: Re-enable rev-list --parents for parse_commit.

   Shawn O. Pearce (8):
      Don't crash during repack of a reflog with pruned commits.
      Create 'git gc' to perform common maintenance operations.
      Use GIT_REFLOG_ACTION environment variable instead.
      Honor GIT_REFLOG_ACTION in git-rebase.
      Use branch names in 'git-rebase -m' conflict hunks.
      Ensure `git-pull` fails if `git-merge` fails.
      Honor pull.{twohead,octopus} in git-merge.
      Allow git-merge to select the default strategy.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-27  1:19                     ` Luben Tuikov
@ 2006-12-27  2:14                       ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-27  2:14 UTC (permalink / raw)
  To: ltuikov; +Cc: git, Randal L. Schwartz, Josef Weidendorfer

Luben Tuikov <ltuikov@yahoo.com> writes:

> --- Junio C Hamano <junkio@cox.net> wrote:
>> Luben Tuikov <ltuikov@yahoo.com> writes:
>> 
>> >> I am not quite sure about that.  An old timer would work in a
>> >> newly cloned repository after all, and what this "newbie
>> >> protection" is breaking is not existing repositories but
>> >> expectation from existing users.
>> >
>> > Hmm, "newbie protection" doesn't sound good.  It sounds like
>> > "screw the old-timers and let's change well-established workflow".
>> 
>> As far as I am concerned, this is a topic already closed four
>> days ago with commit fb8696d9.
>> 
>> Are you way too behind, are you rubbing it in, or am I
>> hallucinating and fb8696d9 did not actually fix it?
>
> I'm behind.  I'll pull and take a look at that commit.

Thanks.

And sorry that I sounded harsher than necessary.  Between the
two paragraphs, I meant to say "... with commit fb8696d9.  It
was a mistake, I broke existing workflows, I apologized, and the
commit should have fixed it".

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-26 23:54                   ` Junio C Hamano
@ 2006-12-27  1:19                     ` Luben Tuikov
  2006-12-27  2:14                       ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Luben Tuikov @ 2006-12-27  1:19 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Randal L. Schwartz, Josef Weidendorfer

--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
> 
> >> I am not quite sure about that.  An old timer would work in a
> >> newly cloned repository after all, and what this "newbie
> >> protection" is breaking is not existing repositories but
> >> expectation from existing users.
> >
> > Hmm, "newbie protection" doesn't sound good.  It sounds like
> > "screw the old-timers and let's change well-established workflow".
> 
> As far as I am concerned, this is a topic already closed four
> days ago with commit fb8696d9.
> 
> Are you way too behind, are you rubbing it in, or am I
> hallucinating and fb8696d9 did not actually fix it?

I'm behind.  I'll pull and take a look at that commit.

    Luben

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-26 20:25                 ` Luben Tuikov
@ 2006-12-26 23:54                   ` Junio C Hamano
  2006-12-27  1:19                     ` Luben Tuikov
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-26 23:54 UTC (permalink / raw)
  To: Luben Tuikov; +Cc: git, Randal L. Schwartz, Josef Weidendorfer

Luben Tuikov <ltuikov@yahoo.com> writes:

>> I am not quite sure about that.  An old timer would work in a
>> newly cloned repository after all, and what this "newbie
>> protection" is breaking is not existing repositories but
>> expectation from existing users.
>
> Hmm, "newbie protection" doesn't sound good.  It sounds like
> "screw the old-timers and let's change well-established workflow".

As far as I am concerned, this is a topic already closed four
days ago with commit fb8696d9.

Are you way too behind, are you rubbing it in, or am I
hallucinating and fb8696d9 did not actually fix it?

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 21:44               ` Junio C Hamano
@ 2006-12-26 20:25                 ` Luben Tuikov
  2006-12-26 23:54                   ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Luben Tuikov @ 2006-12-26 20:25 UTC (permalink / raw)
  To: Junio C Hamano, Johannes Schindelin
  Cc: git, Randal L. Schwartz, Josef Weidendorfer

--- Junio C Hamano <junkio@cox.net> wrote:
> I am not quite sure about that.  An old timer would work in a
> newly cloned repository after all, and what this "newbie
> protection" is breaking is not existing repositories but
> expectation from existing users.

Hmm, "newbie protection" doesn't sound good.  It sounds like
"screw the old-timers and let's change well-established workflow".

The expectation is that one always pulls into origin, merges
into master, and maybe checks out master to see the remote
master.  From then on, they decide what, where and how to
merge (from) master into any local branches, and then
eventually export local branches to the public.

The "^branch.\.*" options seem to be counter-intuitive to
1) git's behavor and 2) see above.

Generally "pulling" a remote master in a local branch, without
the local "origin+master" being fast-forwarded/merged should be
considered non-git-conformant behavior.  Assuming that the local
branch is a branch of master/origin, which is almost ever the case.

> In any case, here is a patch for discussion.
> 
> diff --git a/git-parse-remote.sh b/git-parse-remote.sh
> index f163821..b4d071b 100755
> --- a/git-parse-remote.sh
> +++ b/git-parse-remote.sh
> @@ -145,10 +145,22 @@ canon_refs_list_for_fetch () {
>  			merge_branches=$(git-repo-config \
>  			    --get-all "branch.${curr_branch}.merge")
>  		fi
> -		# If we are fetching only one branch, then first branch
> -		# is the only thing that makes sense to merge anyway,
> -		# so there is no point refusing that traditional rule.
> -		if test $# != 1 && test "z$merge_branches" = z
> +		if test "z$merge_branches" = z &&
> +			# If we are fetching only one branch, then
> +			# first branch is the only thing that makes
> +			# sense to merge anyway, so there is no point
> +			# refusing that traditional rule.
> +			test $# != 1 &&
> +
> +			# Also, old timers have been happily working
> +			# with the first branch rule without having
> +			# any branch.*.merge configuration, so if
> +			# there is none, do not bother with this
> +			# "newbie protection".  A newly cloned
> +			# repository would have branch.master.merge
> +			# set for it.

It should probably have branch.*.remote _and_ branch.*.merge set
for completeness.  Or we should remove the branch.* options
from git-config and leave this up to porcelains.

> +			git repo-config --get-regexp \
> +				'^branch\..*\.merge$' >/dev/null

How does this "set" it?

    Luben


>  		then
>  			merge_branches=..this..would..never..match..
>  		fi

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 20:56           ` Jakub Narebski
@ 2006-12-22 21:49             ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-22 21:49 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
> ...
>>>> Possibilities:
>>>> 
>>>>  (1) Forget about that "protection" business.  If you do not
>>>>      want mistakes, use 'branch.*.merge' but otherwise we will
>>>>      continue to follow the good old "first set of branches"
>>>>      rule.
>>>
>>> What about marking default branch to merge explicitely using
>>> "Merge:" in remotes/<repo>, or remote.<name>.merge?
>> 
>> Sorry, how is that an improvement over the current branch.*.merge?
>> and how would that help not breaking existing setups?
>
> I meant that in addition to forgetting about "protection" business.
> This would be intermediate improvement over old behavior.

I do not think so.  It does not talk about "when on my local
branch X do this", and applies to all pulls from the named
remote.  Then longstanding rule of merging the first set of
branches is just fine and as expressive.  You see them the first
in the list, and you already know they somehow matter more.

On the other hand, I think Santi's branch.*.merge (done in
commit 5372806a) _was_ a real improvement.

> Perhaps make "protection" business optional, default to on for
> new users?

Now the question is how you would tell "new users".

The possibility (2) is not even good enough, because even old
timers work in a newly cloned repositories.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 20:44             ` Johannes Schindelin
@ 2006-12-22 21:44               ` Junio C Hamano
  2006-12-26 20:25                 ` Luben Tuikov
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-22 21:44 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: git, Randal L. Schwartz, Josef Weidendorfer, Luben Tuikov

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

> So, if I understand your option (2) correctly, it complains _only_ if 
> there is at least one branch.*.merge in the config, but not for the 
> current branch?
>
> I think that would safeguard the existing repositories _and_ the new ones, 
> because git-clone sets them up with such an entry to begin with.
>
> If that behaviour was meant by (2), I am all for it.

I am not quite sure about that.  An old timer would work in a
newly cloned repository after all, and what this "newbie
protection" is breaking is not existing repositories but
expectation from existing users.

In any case, here is a patch for discussion.

diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index f163821..b4d071b 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -145,10 +145,22 @@ canon_refs_list_for_fetch () {
 			merge_branches=$(git-repo-config \
 			    --get-all "branch.${curr_branch}.merge")
 		fi
-		# If we are fetching only one branch, then first branch
-		# is the only thing that makes sense to merge anyway,
-		# so there is no point refusing that traditional rule.
-		if test $# != 1 && test "z$merge_branches" = z
+		if test "z$merge_branches" = z &&
+			# If we are fetching only one branch, then
+			# first branch is the only thing that makes
+			# sense to merge anyway, so there is no point
+			# refusing that traditional rule.
+			test $# != 1 &&
+
+			# Also, old timers have been happily working
+			# with the first branch rule without having
+			# any branch.*.merge configuration, so if
+			# there is none, do not bother with this
+			# "newbie protection".  A newly cloned
+			# repository would have branch.master.merge
+			# set for it.
+			git repo-config --get-regexp \
+				'^branch\..*\.merge$' >/dev/null
 		then
 			merge_branches=..this..would..never..match..
 		fi

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 20:16         ` Junio C Hamano
@ 2006-12-22 20:56           ` Jakub Narebski
  2006-12-22 21:49             ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-12-22 20:56 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> <opublikowany i wysłany>
>>
>> Junio C Hamano wrote:
>>
>>> Possibilities:
>>> 
>>>  (1) Forget about that "protection" business.  If you do not
>>>      want mistakes, use 'branch.*.merge' but otherwise we will
>>>      continue to follow the good old "first set of branches"
>>>      rule.
>>
>> What about marking default branch to merge explicitely using
>> "Merge:" in remotes/<repo>, or remote.<name>.merge?
> 
> Sorry, how is that an improvement over the current branch.*.merge?
> and how would that help not breaking existing setups?

I meant that in addition to forgetting about "protection" business.
This would be intermediate improvement over old behavior, marking
clearly which is default branch to merge (with first branch still
being default, and perhaps error out if there is _only_ wildcard
Pull:/fetch line/variable; the branches marked with + are ineligible
as candidate for merge with "first branch being default branch to
merge" default).

Perhaps make "protection" business optional, default to on for
new users?
-- 
Jakub Narebski
Poland

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 20:13           ` Junio C Hamano
@ 2006-12-22 20:44             ` Johannes Schindelin
  2006-12-22 21:44               ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-22 20:44 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Randal L. Schwartz

Hi,

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

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > HOWEVER, it has been in "What's cooking in git (topics)".
> >
> > Having said that, we could (at least for some time) print a big red 
> > warning for the specific case of "git pull" meaning "git pull origin 
> > <whateveristhefirstfetchedhead>" that this will GO AWAY SOON.
> >
> > Of course, you would not see it. Only your script.
> >
> > BTW I would _never_ allow a script to rely on such a DWIM feature.
> 
> That's too strong a statement.  It is not DWIM but has been a
> longstanding rule to use "the first set of branches" for the
> merge.  We've merged the first set of branches since day one,
> and even after branch.*.merge we've done so unless you do not
> have such configuration.

Okay, I have been wrong. My sincere apologies.

So, if I understand your option (2) correctly, it complains _only_ if 
there is at least one branch.*.merge in the config, but not for the 
current branch?

I think that would safeguard the existing repositories _and_ the new ones, 
because git-clone sets them up with such an entry to begin with.

If that behaviour was meant by (2), I am all for it.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22  9:25 Junio C Hamano
  2006-12-22 17:15 ` Randal L. Schwartz
@ 2006-12-22 20:21 ` Quy Tonthat
  1 sibling, 0 replies; 601+ messages in thread
From: Quy Tonthat @ 2006-12-22 20:21 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano wrote:
> * The 'master' branch has these since the last announcement.
[...]
> 
>    Quy Tonthat (2):
>       ...
>       Documentation/git-branch: new -r to delete remote-tracking branches.
> 
This one is not there on the 'master' branch.
Quy

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 20:04       ` Jakub Narebski
@ 2006-12-22 20:16         ` Junio C Hamano
  2006-12-22 20:56           ` Jakub Narebski
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-22 20:16 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

Jakub Narebski <jnareb@gmail.com> writes:

> <opublikowany i wysłany>
>
> Junio C Hamano wrote:
>
>> Possibilities:
>> 
>>  (1) Forget about that "protection" business.  If you do not
>>      want mistakes, use 'branch.*.merge' but otherwise we will
>>      continue to follow the good old "first set of branches"
>>      rule.
>
> What about marking default branch to merge explicitely using
> "Merge:" in remotes/<repo>, or remote.<name>.merge?

Sorry, how is that an improvement over the current branch.*.merge?
and how would that help not breaking existing setups?

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 19:21         ` Johannes Schindelin
@ 2006-12-22 20:13           ` Junio C Hamano
  2006-12-22 20:44             ` Johannes Schindelin
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-22 20:13 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, Randal L. Schwartz

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

> HOWEVER, it has been in "What's cooking in git (topics)".
>
> Having said that, we could (at least for some time) print a big red 
> warning for the specific case of "git pull" meaning "git pull origin 
> <whateveristhefirstfetchedhead>" that this will GO AWAY SOON.
>
> Of course, you would not see it. Only your script.
>
> BTW I would _never_ allow a script to rely on such a DWIM feature.

That's too strong a statement.  It is not DWIM but has been a
longstanding rule to use "the first set of branches" for the
merge.  We've merged the first set of branches since day one,
and even after branch.*.merge we've done so unless you do not
have such configuration.

The complaint (or "newbie protection") was a backward
incompatible change, and it was executed poorly.  So my
apologies go to Merlyn.

While many "new features" can be done in backward compatible
way, any "newbie protection" can break existing practices --
because the whole point of "protection" is to forbid what once
was allowed only because we did not use to check.  And when we
have something that we check now that we did not check before,
that by definition will not be backward compatible.

Some backward incompatibilities are more justfiable than others.
For example, we recently changed "git add" without argument not
to do anything.  It used to have the same effect as "git add .",
but (1) adding all files in a working tree is a rare event, (2)
just a single dot is not hard to type, (3) without argument you
will get a response "not doing anything".  On the other hand,
doing "git add" without argument by mistake and ending up with
the index with many unwanted files is more painful and more
likely to hapen -- it is more valuable to protect users against
it than saving the two keysrokes.  That's why I think that
change is a justified improvement.

I do not think this "merge complaint", at least in the form that
lived on 'master', is justifiable.  The first one that was
merged from the topic made it a requirement to have the
branch.*.merge configuration when you do not give explicit
refspecs on the command line, which was just outright WRONG.
The one currently on the public repository says if the fetch
ended up getting only one branch then not having branch.*.merge
is Ok, which arguably is an improvement, but I do not think is
good enough.  I mentioned other possibilities in my earlier
message.

I also personally think that it is not as clear cut as the "git
add" case that "the first set of branches" rule is wrong, but
the trouble I caused to Merlyn and Luben primarily comes from
the check to trigger "newbie protection", not from what the
protection is trying to do.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 18:58     ` Junio C Hamano
@ 2006-12-22 20:04       ` Jakub Narebski
  2006-12-22 20:16         ` Junio C Hamano
  0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-12-22 20:04 UTC (permalink / raw)
  To: git

<opublikowany i wysłany>

Junio C Hamano wrote:

> Possibilities:
> 
>  (1) Forget about that "protection" business.  If you do not
>      want mistakes, use 'branch.*.merge' but otherwise we will
>      continue to follow the good old "first set of branches"
>      rule.

What about marking default branch to merge explicitely using
"Merge:" in remotes/<repo>, or remote.<name>.merge?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 18:12       ` Randal L. Schwartz
  2006-12-22 18:21         ` Randal L. Schwartz
@ 2006-12-22 19:21         ` Johannes Schindelin
  2006-12-22 20:13           ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-22 19:21 UTC (permalink / raw)
  To: Randal L. Schwartz; +Cc: Junio C Hamano, git

Hi,

On Fri, 22 Dec 2006, Randal L. Schwartz wrote:

> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> 
> >>>>> writes:
> 
> >> Ahh, it's "git-pull . origin".
> 
> Johannes> This is just a merge, not a real pull (it leaves out the fetch 
> Johannes> part).
> 
> OK, so what does what a naked "git-pull" used to do before, which was 
> "fetch origin, then pull it into the current branch"?

$ git repo-config branch.xyz.remote origin
$ git repo-config branch.xyz.merge refs/heads/<whateveryourfirstfetchis>

> Johannes> So, for each branch (e.g. "xyz") for which you have a 
> Johannes> preferred upstream (e.g. remote "linus" with branch
> Johannes> "master"), say
> 
> Johannes> 	$ git repo-config branch.xyz.remote linus
> Johannes> 	$ git repo-config branch.xyz.merge refs/heads/master
> 
> But that's not upward compatible.  The default should be the old 
> behavior, or we need a better way to notify people that this breaks 
> things.

AFAIK it is not in maint. Not even in 1.4.4.3. So, you got it with master.

So, TFA should have been in a message "What's in git (stable)". 
Alas, the commit a71fb0a1: "git-pull: refuse default merge without 
branch.*.merge" was merged _after_ the latest announcement.

HOWEVER, it has been in "What's cooking in git (topics)".

Having said that, we could (at least for some time) print a big red 
warning for the specific case of "git pull" meaning "git pull origin 
<whateveristhefirstfetchedhead>" that this will GO AWAY SOON.

Of course, you would not see it. Only your script.

BTW I would _never_ allow a script to rely on such a DWIM feature.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 17:19   ` Randal L. Schwartz
  2006-12-22 18:09     ` Johannes Schindelin
@ 2006-12-22 18:58     ` Junio C Hamano
  2006-12-22 20:04       ` Jakub Narebski
  1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-22 18:58 UTC (permalink / raw)
  To: Randal L. Schwartz; +Cc: git

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> Junio> git-pull: refuse default merge without branch.*.merge
>
> Randal> Argh.  How do I get back the old behavior?
> Randal> "git-pull origin" doesn't seem to be enough.
>
> Randal> You just broke a bunch of automated scripts for me.
>
> Ahh, it's "git-pull . origin".
>
> Maybe a bit more warning for non-upward-compatible changes though, please.
>
> Or maybe we should presume everything is non-upward compatible?  I didn't
> think a naked "git-pull" was that out of the ordinary.

Things are supposed to be upward compatible, but this round
until v1.5.0 some things may not be when it is justifiably an
improvement.  For example, we've already made 'separate remote'
not only the default but the only layout 'git clone' produces.
I cannot think of others offhand, but I am reasonably certain
there are others.  We need a "incompatible changes" list.

The tradtional "pull always merges the first set of branches"
rule, although I was actually very much in favor of it, was
something that was hated by everybody.

It was said that people had lot of trouble after doing "git pull
origin" without any refspecs ("git pull" without any argument
defaults to 'origin' which is backward compatible, if you do not
have branch.*.remote, so that form has the same issues), when on
a branch other than the 'master' branch.  "merges the same first
set of branches no matter which branch you are on" was the rule,
but people did not want to merge the ones they usually merge to
their 'master' but wanted some other branch merged.
"branch.*.merge" can be used to specify this, but if you do not
have need for this "merge different branches depending on which
branch I am on", you do not have to use it.  Without
"branch.*.merge" for the current branch, we are still backward
compatible and follow the "first set of branches" rule.

The real trouble is that some people further argued that pulling
without 'branch.*.merge' when you might not want to follow the
"first set of branches" rule might be a newbie mistake and
should be warned and forbidden.  The commit that broke you was
an attempt for that behaviour.  I think that newbie protection
intent is good, but the execution was obviously not.

What I have on 'master' has a little fixup to use 'first set of
branches' rule when the fetch gets only one branch without
complaining.  I am still not happy with that either, and at this
point I am not sure if there is a good compromise that does not
break existing setup while offering the newbie protection.

Possibilities:

 (1) Forget about that "protection" business.  If you do not
     want mistakes, use 'branch.*.merge' but otherwise we will
     continue to follow the good old "first set of branches"
     rule.

 (2) A slight variant of the above; do the "protection" only
     when 'branch.*.merge' is defined for _any_ of the branches,
     not just the current branch.

 (3) A further variant; do not do the above "protection" if the
     current branch is 'master' (this further makes 'master'
     special, which some people may hate).

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 18:12       ` Randal L. Schwartz
@ 2006-12-22 18:21         ` Randal L. Schwartz
  2006-12-22 19:21         ` Johannes Schindelin
  1 sibling, 0 replies; 601+ messages in thread
From: Randal L. Schwartz @ 2006-12-22 18:21 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

Randal> But that's not upward compatible.  The default should be the old behavior,
Randal> or we need a better way to notify people that this breaks things.

Not to mention that the manpage still says:

       git pull, git pull origin
           Fetch the default head from the repository you cloned from and
           merge it into your current branch.

So even if I was *looking* for a change in behavior, it wasn't documented.
Nothing changed in that area in recent history.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 18:09     ` Johannes Schindelin
@ 2006-12-22 18:12       ` Randal L. Schwartz
  2006-12-22 18:21         ` Randal L. Schwartz
  2006-12-22 19:21         ` Johannes Schindelin
  0 siblings, 2 replies; 601+ messages in thread
From: Randal L. Schwartz @ 2006-12-22 18:12 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git

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

>> Ahh, it's "git-pull . origin".

Johannes> This is just a merge, not a real pull (it leaves out the fetch part).

OK, so what does what a naked "git-pull" used to do before, which was
"fetch origin, then pull it into the current branch"?

Johannes> So, for each branch (e.g. "xyz") for which you have a preferred upstream 
Johannes> (e.g. remote "linus" with branch "master"), say

Johannes> 	$ git repo-config branch.xyz.remote linus
Johannes> 	$ git repo-config branch.xyz.merge refs/heads/master

But that's not upward compatible.  The default should be the old behavior,
or we need a better way to notify people that this breaks things.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 17:19   ` Randal L. Schwartz
@ 2006-12-22 18:09     ` Johannes Schindelin
  2006-12-22 18:12       ` Randal L. Schwartz
  2006-12-22 18:58     ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-22 18:09 UTC (permalink / raw)
  To: Randal L. Schwartz; +Cc: Junio C Hamano, git

Hi,

On Fri, 22 Dec 2006, Randal L. Schwartz wrote:

> >>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
> 
> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> Junio> git-pull: refuse default merge without branch.*.merge
> 
> Randal> Argh.  How do I get back the old behavior?
> Randal> "git-pull origin" doesn't seem to be enough.

Maybe "git-pull origin master"?

> Randal> You just broke a bunch of automated scripts for me.
> 
> Ahh, it's "git-pull . origin".

This is just a merge, not a real pull (it leaves out the fetch part).

> Maybe a bit more warning for non-upward-compatible changes though, 
> please.

It is unfortunate that this change broke your scripts. But I really think 
that the new behaviour is much saner: If you have different branches, you 
probably do not want to pull the _same_ remote branch into _all_ of them.

So, for each branch (e.g. "xyz") for which you have a preferred upstream 
(e.g. remote "linus" with branch "master"), say

	$ git repo-config branch.xyz.remote linus
	$ git repo-config branch.xyz.merge refs/heads/master

Then,

	$ git pull

pulls your preferred upstream. But when you pull from another remote, or 
into another branch, without specifying which remote branch you want to 
pull, git now refuses to blindly pull branch "master". This should prevent 
quite some pilot errors.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22 17:15 ` Randal L. Schwartz
@ 2006-12-22 17:19   ` Randal L. Schwartz
  2006-12-22 18:09     ` Johannes Schindelin
  2006-12-22 18:58     ` Junio C Hamano
  0 siblings, 2 replies; 601+ messages in thread
From: Randal L. Schwartz @ 2006-12-22 17:19 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> git-pull: refuse default merge without branch.*.merge

Randal> Argh.  How do I get back the old behavior?
Randal> "git-pull origin" doesn't seem to be enough.

Randal> You just broke a bunch of automated scripts for me.

Ahh, it's "git-pull . origin".

Maybe a bit more warning for non-upward-compatible changes though, please.

Or maybe we should presume everything is non-upward compatible?  I didn't
think a naked "git-pull" was that out of the ordinary.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-22  9:25 Junio C Hamano
@ 2006-12-22 17:15 ` Randal L. Schwartz
  2006-12-22 17:19   ` Randal L. Schwartz
  2006-12-22 20:21 ` Quy Tonthat
  1 sibling, 1 reply; 601+ messages in thread
From: Randal L. Schwartz @ 2006-12-22 17:15 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

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

Junio>       git-pull: refuse default merge without branch.*.merge

Argh.  How do I get back the old behavior?
"git-pull origin" doesn't seem to be enough.

You just broke a bunch of automated scripts for me.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2006-12-22  9:25 Junio C Hamano
  2006-12-22 17:15 ` Randal L. Schwartz
  2006-12-22 20:21 ` Quy Tonthat
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-22  9:25 UTC (permalink / raw)
  To: git

I guess I'll need to push another maintenance release out soon,
if only to fix the manual pages.

On the 'master' front there are a handful more topics pushed out
from 'next'.  I still need to apply the __FREEBSD__ fix yet, but
otherwise we should be able to start calming things down.

* The 'maint' branch has these fixes since the last announcement.

   Johannes Schindelin (1):
      diff --check: fix off by one error

   Junio C Hamano (1):
      spurious .sp in manpages

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

   Eric Wong (3):
      git-svn: convert to using Git.pm
      git-svn: remove support for the svn command-line client
      git-svn: rename 'commit' command to 'set-tree'

   Johannes Schindelin (5):
      Introduce GIT_TEMPLATE_DIR
      diff --check: fix off by one error
      Use git-merge-file in git-merge-one-file, too
      git-tag: support -F <file> option
      git-reset --hard: tell the user what the HEAD was reset to

   Josef Weidendorfer (1):
      Move "no merge candidate" warning into git-pull

   Junio C Hamano (22):
      git-clone: use wildcard specification for tracking branches
      git-pull: refuse default merge without branch.*.merge
      git-clone: lose the artificial "first" fetch refspec
      git-clone: lose the traditional 'no-separate-remote' layout
      rev-list --left-right
      Teach all of log family --left-right output.
      Make left-right automatic.
      fix testsuite: make sure they use templates freshly built from the source
      Teach git-branch to delete tracking branches with -r -d
      blame: -b (blame.blankboundary) and --root (blame.showroot)
      Revert "fix testsuite: make sure they use templates freshly
        built from the source"
      Do not create $GIT_DIR/remotes/ directory anymore.
      Use preprocessor constants for environment variable names.
      Revert "Make left-right automatic."
      git-add: error out when given no arguments.
      spurious .sp in manpages
      compat/inet_ntop: do not use u_int
      diff documentation: mostly talk about <commit>
      Revert "git-pull: refuse default merge without branch.*.merge"
      parse-remote: mark all refs not for merge only when fetching more
        than one
      _XOPEN_SOURCE problem also exists on FreeBSD
      commit-tree: do not overflow MAXPARENT

   Quy Tonthat (2):
      git-branch -d: do not stop at the first failure.
      Documentation/git-branch: new -r to delete remote-tracking branches.

   Shawn Pearce (3):
      Suggest 'add' in am/revert/cherry-pick.
      Rename imap-send's internal info/warn functions.
      Introduce a global level warn() function.

   Terje Sten Bjerkseth (1):
      Fix system header problems on Mac OS X

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
       [not found] ` <Pine.LNX.4.64.0612181012280.3479@woody.osdl.org>
@ 2006-12-18 22:04   ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-18 22:04 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: git

Linus Torvalds <torvalds@osdl.org> writes:

> On Sun, 17 Dec 2006, Junio C Hamano wrote:
>> 
>>  - blame A..B's output shows lines attributed to the boundary
>>    commit with commit SHA-1 prefixed with '^';
>
> I wonder if it would make sense to have a flag or mode or something where 
> boundary commit attributions are simply left unattributed (ie just leave 
> that _empty_).

How about this?

-- >8 --
blame: -b (blame.blankboundary) and --root (blame.showroot)

When blame.blankboundary is set (or -b option is given), commit
object names are blanked out in the "human readable" output
format for boundary commits.

When blame.showroot is not set (or --root is not given), the
root commits are treated as boundary commits.  The code still
attributes the lines to them, but with -b their object names are
not shown.

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

---
 builtin-blame.c |   33 +++++++++++++++++++++++++++++++--
 1 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/builtin-blame.c b/builtin-blame.c
index a250724..211bdb3 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -22,7 +22,9 @@
 static char blame_usage[] =
 "git-blame [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>] [-M] [-C] [-C] [commit] [--] file\n"
 "  -c, --compatibility Use the same output mode as git-annotate (Default: off)\n"
+"  -b                  Show blank SHA-1 for boundary commits (Default: off)\n"
 "  -l, --long          Show long commit SHA1 (Default: off)\n"
+"  --root              Do not treat root commits as boundaries (Default: off)\n"
 "  -t, --time          Show raw timestamp (Default: off)\n"
 "  -f, --show-name     Show original filename (Default: auto)\n"
 "  -n, --show-number   Show original linenumber (Default: off)\n"
@@ -36,6 +38,8 @@ static int longest_author;
 static int max_orig_digits;
 static int max_digits;
 static int max_score_digits;
+static int show_root;
+static int blank_boundary;
 
 #ifndef DEBUG
 #define DEBUG 0
@@ -1095,6 +1099,9 @@ static void assign_blame(struct scoreboard *sb, struct rev_info *revs, int opt)
 			if (commit->object.parsed)
 				mark_parents_uninteresting(commit);
 		}
+		/* treat root commit as boundary */
+		if (!commit->parents && !show_root)
+			commit->object.flags |= UNINTERESTING;
 
 		/* Take responsibility for the remaining entries */
 		for (ent = sb->ent; ent; ent = ent->next)
@@ -1318,8 +1325,12 @@ static void emit_other(struct scoreboard *sb, struct blame_entry *ent, int opt)
 		int length = (opt & OUTPUT_LONG_OBJECT_NAME) ? 40 : 8;
 
 		if (suspect->commit->object.flags & UNINTERESTING) {
-			length--;
-			putchar('^');
+			if (!blank_boundary) {
+				length--;
+				putchar('^');
+			}
+			else
+				memset(hex, ' ', length);
 		}
 
 		printf("%.*s", length, hex);
@@ -1639,6 +1650,19 @@ static void prepare_blame_range(struct scoreboard *sb,
 		usage(blame_usage);
 }
 
+static int git_blame_config(const char *var, const char *value)
+{
+	if (!strcmp(var, "blame.showroot")) {
+		show_root = git_config_bool(var, value);
+		return 0;
+	}
+	if (!strcmp(var, "blame.blankboundary")) {
+		blank_boundary = git_config_bool(var, value);
+		return 0;
+	}
+	return git_default_config(var, value);
+}
+
 int cmd_blame(int argc, const char **argv, const char *prefix)
 {
 	struct rev_info revs;
@@ -1654,6 +1678,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
 	char type[10];
 	const char *bottomtop = NULL;
 
+	git_config(git_blame_config);
 	save_commit_buffer = 0;
 
 	opt = 0;
@@ -1662,6 +1687,10 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
 		const char *arg = argv[i];
 		if (*arg != '-')
 			break;
+		else if (!strcmp("-b", arg))
+			blank_boundary = 1;
+		else if (!strcmp("--root", arg))
+			show_root = 1;
 		else if (!strcmp("-c", arg))
 			output_option |= OUTPUT_ANNOTATE_COMPAT;
 		else if (!strcmp("-t", arg))

^ permalink raw reply related	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2006-12-18  7:26 Junio C Hamano
       [not found] ` <Pine.LNX.4.64.0612181012280.3479@woody.osdl.org>
  0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-18  7:26 UTC (permalink / raw)
  To: git

I've updated 'master' with a handful topics along with a few
fixes:

 - Jakub's gitweb updates;

 - blame A..B's output shows lines attributed to the boundary
   commit with commit SHA-1 prefixed with '^';

 - "branch -m $old $new" renames branch.$old.* configuration
   variables to branch.$new.*;

 - "git add A/B C", when A and C/D used to be tracked files, now
   properly works, it used to result in a bogus index you cannot
   write-tree out;

 - "git show-branch --reflog=<n> <branch>" shows latest n entries
   of the reflog of the branch.

 - "git fetch" between repositories with tons of refs had huge
   performance problem; hopefully fixed.

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

   Jakub Narebski (8):
      gitweb: Don't use Content-Encoding: header in git_snapshot
      gitweb: Show target of symbolic link in "tree" view
      gitweb: Add generic git_object subroutine to display object of any type
      gitweb: Hyperlink target of symbolic link in "tree" view (if possible)
      gitweb: SHA-1 in commit log message links to "object" view
      gitweb: Do not show difftree for merges in "commit" view
      gitweb: Add title attribute to ref marker with full ref name
      gitweb: Add "next" link to commit view

   Johannes Schindelin (2):
      add a function to rename sections in the config
      git-branch: rename config vars branch.<branch>.*, too

   Junio C Hamano (11):
      git-blame: show lines attributed to boundary commits differently.
      update-index: make D/F conflict error a bit more verbose.
      git-add: remove conflicting entry when adding.
      Fix check_file_directory_conflict().
      Fix mis-mark-up in git-merge-file.txt documentation
      markup fix in svnimport documentation.
      Teach show-branch how to show ref-log data.
      git-fetch: Avoid reading packed refs over and over again
      avoid accessing _all_ loose refs in git-show-ref --verify
      show-ref: fix --quiet --verify
      show-ref: fix --verify --hash=length

   Quy Tonthat (1):
      Documentation: new option -P for git-svnimport

   Shawn Pearce (1):
      Default GIT_COMMITTER_NAME to login name in recieve-pack.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2006-12-16 23:10 Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16 23:10 UTC (permalink / raw)
  To: git

At the end is a list of stuff merged to 'master' since the last
announcement.

----------------------------------------------------------------

Andy Parkins (1):
      git-status always says what branch it's on

Brian Gernhardt (2):
      Add --add option to git-repo-config
      Make git-diff documentation use [--] when it should.

Johannes Schindelin (3):
      INSTALL: no need to have GNU diff installed
      git-show: grok blobs, trees and tags, too
      Document git-merge-file

Junio C Hamano (7):
      Revert "git-diff: Introduce --index and deprecate --cached."
      git-svn: allow both diff.color and color.diff
      Update git-diff documentation
      git-fetch: make it work from within a subdirectory.
      git-reset: make it work from within a subdirectory.
      git-reset [--mixed] <tree> [--] <paths>...
      merge: give a bit prettier merge message to "merge branch~$n"

Luben Tuikov (1):
      Export PERL_PATH

Nicolas Pitre (2):
      repacked packs should be read-only
      make commit message a little more consistent and conforting

Quy Tonthat (1):
      git-clone documentation

Shawn Pearce (7):
      Bypass expensive content comparsion during rename detection.
      Avoid accessing a slow working copy during diffcore operations.
      Provide more meaningful output from 'git init-db'.
      Enable reflogs by default in any repository with a working directory.
      Teach bash the new features of 'git show'.
      Suggest use of "git add file1 file2" when there is nothing to commit.
      Align section headers of 'git status' to new 'git add'.


^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-09 20:44 ` Tilman Sauerbeck
@ 2006-12-09 21:10   ` Junio C Hamano
  0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-09 21:10 UTC (permalink / raw)
  To: Tilman Sauerbeck; +Cc: git

Tilman Sauerbeck <tilman@code-monkey.de> writes:

> Junio C Hamano [2006-12-06 13:18]:
>> * The 'maint' branch has produced a new release 1.4.4.2
>
> Any reason why this wasn't announced?

Well, vger seems to have ate the message.

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-06 21:18 Junio C Hamano
  2006-12-08 15:36 ` Jakub Narebski
@ 2006-12-09 20:44 ` Tilman Sauerbeck
  2006-12-09 21:10   ` Junio C Hamano
  1 sibling, 1 reply; 601+ messages in thread
From: Tilman Sauerbeck @ 2006-12-09 20:44 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

Junio C Hamano [2006-12-06 13:18]:
> * The 'maint' branch has produced a new release 1.4.4.2

Any reason why this wasn't announced?

Regards,
Tilman

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 601+ messages in thread

* Re: What's in git.git (stable)
  2006-12-06 21:18 Junio C Hamano
@ 2006-12-08 15:36 ` Jakub Narebski
  2006-12-09 20:44 ` Tilman Sauerbeck
  1 sibling, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-08 15:36 UTC (permalink / raw)
  To: git; +Cc: linux-kernel

Junio C Hamano wrote:

> * The 'maint' branch has produced a new release 1.4.4.2

What happened to "[ANNOUNCE] GIT 1.4.4.2" thread?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


^ permalink raw reply	[flat|nested] 601+ messages in thread

* What's in git.git (stable)
@ 2006-12-06 21:18 Junio C Hamano
  2006-12-08 15:36 ` Jakub Narebski
  2006-12-09 20:44 ` Tilman Sauerbeck
  0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-06 21:18 UTC (permalink / raw)
  To: git; +Cc: linux-kernel

* The 'maint' branch has produced a new release 1.4.4.2

* In the 'master' branch:

  - we now officially favor 'remotes' information to be in
    $GIT_DIR/config, and 'git clone' records origin in there,
    not in $GIT_DIR/remotes/origin (thanks to Andy Parkins).

  - "git send-pack $URL :refs/heads/$branch" can be used to
    delete a remote branch (so does "git push $URL :$ref" over
    git native protocols).

  - built-in shortlog lets you directly say "git shortlog
    v2.6.18..master", instead of piping an output from the
    corresponding "git log v2.6.18..master" into it.

  - git-svn updates
  - gitweb updates
  - gitk updates
  - bash completion updates

The shortlog since the last announcement for 'master' is:

Alex Riesen (2):
      git-blame: fix rev parameter handling.
      Make perl/ build procedure ActiveState friendly.

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

Andy Parkins (3):
      Use .git/config for storing "origin" shortcut repository
      Document git-repo-config --bool/--int options.
      De-emphasise the symbolic link documentation.

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

Eric Wong (10):
      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

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

J. Bruce Fields (1):
      cvs-migration: improved section titles, better push/commit explanation

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

Jim Meyering (1):
      Set permissions of each new file before "cvs add"ing it.

Johannes Schindelin (10):
      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()
      git-mv: search more precisely for source directory in index
      diff -b: ignore whitespace at end of line
      cvs-migration document: make the need for "push" more obvious

Junio C Hamano (24):
      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-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
      receive-pack: do not insist on fast-forward outside refs/heads/
      unpack-trees: make sure "df_conflict_entry.name" is NUL terminated.
      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

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

Nicolas Pitre (2):
      builtin git-shortlog is broken
      pack-objects: remove redundent status information

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

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

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

Shawn O. Pearce (15):
      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.


^ permalink raw reply	[flat|nested] 601+ messages in thread

end of thread, other threads:[~2008-07-21  7:10 UTC | newest]

Thread overview: 601+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-12-13 21:35 What's in git.git (stable) Junio C Hamano
2006-12-13 22:37 ` Andy Parkins
2006-12-13 22:48   ` Jakub Narebski
2006-12-14  9:27     ` Andy Parkins
2006-12-14  9:36       ` Shawn Pearce
2006-12-14 10:03         ` Andy Parkins
2006-12-14 17:06         ` Nicolas Pitre
2006-12-15 14:28           ` Jakub Narebski
2006-12-13 23:31   ` Junio C Hamano
2006-12-13 23:52     ` Peter Baumann
2006-12-14  0:16     ` Johannes Schindelin
2006-12-14  3:32       ` Nicolas Pitre
2006-12-14  6:29         ` Junio C Hamano
2006-12-14  7:59           ` git-show, was " Johannes Schindelin
2006-12-14  8:28             ` Junio C Hamano
2006-12-14 10:25               ` Johannes Schindelin
2006-12-14  8:28     ` Andreas Ericsson
2006-12-15 14:39       ` Jakub Narebski
2006-12-14  9:59     ` Andy Parkins
2006-12-14 10:21       ` Junio C Hamano
2006-12-14 11:36         ` Andy Parkins
2006-12-14 11:45           ` Shawn Pearce
2006-12-14 11:58             ` Carl Worth
2006-12-14 12:05               ` Shawn Pearce
2006-12-14 14:03                 ` reflog by default?, was " Johannes Schindelin
2006-12-14 18:06                 ` Nicolas Pitre
2006-12-14 19:52                   ` Junio C Hamano
2006-12-14 20:02                     ` Shawn Pearce
2006-12-14 20:22                       ` Nicolas Pitre
2006-12-14 20:35                       ` Junio C Hamano
2006-12-14 22:41                         ` [PATCH] Enable reflogs by default in any repository with a working directory Shawn O. Pearce
2006-12-14 23:10                           ` J. Bruce Fields
2006-12-14 23:18                             ` Shawn Pearce
2006-12-14 23:42                               ` J. Bruce Fields
2006-12-15  0:13                           ` Johannes Schindelin
2006-12-15  0:20                             ` Shawn Pearce
2006-12-15 21:55                               ` Junio C Hamano
2006-12-14 22:44                         ` What's in git.git (stable) Shawn Pearce
2006-12-14 21:55                       ` Andreas Ericsson
2006-12-15 21:55                         ` Junio C Hamano
2006-12-16  2:54                           ` Shawn Pearce
2006-12-14 20:17                     ` Nicolas Pitre
2006-12-14 20:50                       ` Junio C Hamano
2006-12-14 19:58                   ` [PATCH] Enable reflogs by default in all repositories Shawn O. Pearce
2006-12-14 17:47             ` What's in git.git (stable) Nicolas Pitre
2006-12-14 21:58             ` Junio C Hamano
2006-12-14 22:50               ` Andy Parkins
2006-12-15 15:38                 ` Jakub Narebski
2006-12-15 15:26           ` Jakub Narebski
2006-12-15 15:30             ` Nicolas Pitre
2006-12-15 15:48               ` Andreas Ericsson
2006-12-15 16:08                 ` Nicolas Pitre
2006-12-15 16:12                   ` Shawn Pearce
2006-12-15 16:13                   ` Andreas Ericsson
2006-12-15 23:22               ` Johannes Schindelin
2006-12-15  4:07         ` Nicolas Pitre
2006-12-15  4:15           ` [PATCH] make commit message a little more consistent and conforting Nicolas Pitre
2006-12-15  4:24             ` Shawn Pearce
2006-12-15  8:34               ` Andreas Ericsson
2006-12-15 15:09                 ` Shawn Pearce
2006-12-15 15:32                   ` Andreas Ericsson
2006-12-15 15:40                     ` Shawn Pearce
2006-12-15 15:50                       ` Andreas Ericsson
2006-12-15 16:06                       ` Nicolas Pitre
2006-12-15 18:21                       ` Junio C Hamano
2006-12-15 16:01                   ` Nicolas Pitre
2006-12-15 16:08                     ` Shawn Pearce
2006-12-15 18:14                     ` Junio C Hamano
2006-12-15 20:13                       ` Nicolas Pitre
2006-12-16  6:18                         ` Junio C Hamano
2006-12-14 21:22       ` What's in git.git (stable) Junio C Hamano
2006-12-14 22:55         ` Andy Parkins
2006-12-14 23:46           ` Junio C Hamano
2006-12-15  8:58             ` Andy Parkins
2006-12-15  9:55               ` Raimund Bauer
2006-12-15 21:55               ` Junio C Hamano
2006-12-15 22:54                 ` Carl Worth
2006-12-14 23:53           ` Johannes Schindelin
2006-12-14 23:52     ` Horst H. von Brand
2006-12-15 10:53       ` Jakub Narebski
2006-12-14  0:22   ` Johannes Schindelin
2006-12-14 10:21     ` Andy Parkins
2006-12-14 10:51       ` Johannes Schindelin
2006-12-14 11:23         ` Andy Parkins
2006-12-14 11:27           ` Johannes Schindelin
2006-12-14 12:00             ` Andy Parkins
2006-12-14 12:10               ` Shawn Pearce
2006-12-14 13:20                 ` Andy Parkins
2006-12-15  0:15         ` Horst H. von Brand
2006-12-15  0:23           ` Johannes Schindelin
2006-12-14 17:23       ` Nicolas Pitre
2006-12-14 21:02         ` Andy Parkins
2006-12-14 23:03   ` Shawn Pearce
2006-12-15 16:16     ` Jakub Narebski
2006-12-15 21:55       ` Junio C Hamano
2006-12-15 22:48         ` Jakub Narebski
2006-12-15 23:25           ` Johannes Schindelin
2006-12-15 23:45             ` Junio C Hamano
2006-12-16  0:14               ` Johannes Schindelin
2006-12-16  0:30                 ` Junio C Hamano
2006-12-16 17:12                   ` Steven Grimm
2006-12-16 19:57                     ` Junio C Hamano
2006-12-15 23:42           ` Junio C Hamano
2006-12-16  9:14 ` [PATCH] git-clone: use wildcard specification for tracking branches Junio C Hamano
2006-12-16  9:36   ` [PATCH] git-pull: refuse default merge without branch.*.merge Junio C Hamano
2006-12-16  9:41     ` [PATCH] git-clone: lose the artificial "first" fetch refspec Junio C Hamano
2006-12-16  9:53       ` [PATCH] git-clone: lose the traditional 'no-separate-remote' layout Junio C Hamano
2006-12-16 16:53         ` Linus Torvalds
2006-12-16 11:51       ` [PATCH] git-clone: lose the artificial "first" fetch refspec Johannes Schindelin
2006-12-16 16:44     ` [PATCH] git-pull: refuse default merge without branch.*.merge Linus Torvalds
2006-12-16  9:39   ` [PATCH] git-clone: use wildcard specification for tracking branches Jakub Narebski
2006-12-16  9:58 ` What's in git.git (stable) Junio C Hamano
2006-12-16 11:22   ` [PATCH] Document git-merge-file Johannes Schindelin
2006-12-16 13:59 ` What's in git.git (stable) Jakub Narebski
2006-12-16 22:04   ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2008-07-21  7:09 Junio C Hamano
2008-04-09  6:51 [ANNOUNCE] GIT 1.5.5 Junio C Hamano
2008-04-09  9:44 ` What's in git.git (stable) Junio C Hamano
2008-04-14  7:00   ` Junio C Hamano
2008-04-19  8:18     ` Junio C Hamano
2008-04-27  6:04       ` Junio C Hamano
2008-05-06  6:38         ` Junio C Hamano
2008-05-14 22:35           ` Junio C Hamano
2008-05-24  1:32             ` Junio C Hamano
2008-05-30 20:43               ` Junio C Hamano
2008-06-02  8:01                 ` Junio C Hamano
2008-06-13 10:10                   ` Junio C Hamano
2008-06-18  7:32                     ` Junio C Hamano
2008-06-18 10:59                       ` Jeff King
2008-06-21 10:06                       ` Junio C Hamano
2008-06-23  7:25                         ` Junio C Hamano
2008-06-25  9:34                           ` Junio C Hamano
2008-07-02  6:28                             ` Junio C Hamano
2008-07-06 10:04                               ` Junio C Hamano
2008-07-08  2:46                                 ` Junio C Hamano
2008-07-14  5:33                                   ` Junio C Hamano
2008-07-16  3:33                                     ` Junio C Hamano
2008-07-20  1:59                                       ` Junio C Hamano
2008-07-20 11:20                                         ` Lars Noschinski
2008-07-20 18:27                                           ` Junio C Hamano
2008-01-30  8:32 What's in git.git (stable frozen) Junio C Hamano
2008-02-12  7:25 ` What's in git.git Junio C Hamano
2008-02-17  3:56   ` What's in git.git (stable) Junio C Hamano
2008-02-17 13:39     ` Jakub Narebski
2008-02-17 20:45       ` Junio C Hamano
2008-02-17 20:51         ` Johannes Schindelin
2008-02-18  1:31           ` Junio C Hamano
2008-02-18  1:34             ` Johannes Schindelin
2008-02-18  1:43               ` Jeff King
2008-02-18  2:05                 ` Johannes Schindelin
2008-02-18  3:12                 ` Junio C Hamano
2008-02-18 11:15                   ` Jeff King
2008-02-21  4:16     ` Junio C Hamano
2008-02-25  8:42       ` Junio C Hamano
2008-02-28  0:43         ` Junio C Hamano
2008-03-03  2:06           ` Junio C Hamano
2008-03-06  6:02             ` Junio C Hamano
2008-03-08 10:08               ` Junio C Hamano
2008-03-09 10:46                 ` Junio C Hamano
2008-03-14  9:11                   ` Junio C Hamano
2008-03-23 10:08                     ` Junio C Hamano
2008-03-28  1:45                       ` Junio C Hamano
2008-03-31  8:39                         ` Junio C Hamano
2008-04-04 18:24                           ` Junio C Hamano
2008-04-05  3:13                             ` Shawn O. Pearce
2008-01-14  1:53 Junio C Hamano
2007-10-22  6:11 What's in git/spearce.git (stable) Shawn O. Pearce
2007-11-01  5:39 ` What's in git.git (stable) Junio C Hamano
2007-11-04  3:52   ` Junio C Hamano
2007-11-08  8:06     ` Junio C Hamano
2007-11-08 11:38       ` Pierre Habouzit
2007-11-12  7:06       ` Junio C Hamano
2007-11-15  0:20         ` Junio C Hamano
2007-11-17 21:00           ` Junio C Hamano
2007-11-25 20:45             ` Junio C Hamano
2007-12-01  2:05               ` Junio C Hamano
2007-12-04  8:43                 ` Junio C Hamano
2007-12-05 10:57                   ` Junio C Hamano
2007-12-07  9:50                     ` Junio C Hamano
2007-12-09 10:32                       ` Junio C Hamano
2007-09-06  8:52 Junio C Hamano
     [not found] ` <7v3axhd0lr.fsf@gitster.siamese.dyndns.org>
2007-09-26 20:05   ` Junio C Hamano
2007-10-02  5:52     ` Junio C Hamano
2007-08-23  0:37 Junio C Hamano
2007-08-24  0:28 ` Jakub Narebski
2007-08-11  8:41 Junio C Hamano
2007-08-11  9:32 ` David Kastrup
2007-08-16  5:02 ` Junio C Hamano
2007-05-13 22:30 Junio C Hamano
2007-05-17  0:21 ` Junio C Hamano
2007-05-19  5:24   ` Junio C Hamano
2007-05-23 21:46     ` Junio C Hamano
2007-05-29 10:12       ` Junio C Hamano
2007-06-02 21:09         ` Junio C Hamano
2007-06-07  2:08           ` Junio C Hamano
2007-06-13 20:11             ` Junio C Hamano
2007-06-13 22:31               ` Johannes Schindelin
2007-06-14  7:12                 ` Johannes Sixt
2007-06-21  7:21               ` Junio C Hamano
2007-06-25  9:43                 ` Junio C Hamano
2007-07-02  0:16                   ` Junio C Hamano
2007-07-13  6:06                     ` What's in git.git Junio C Hamano
2007-07-28  8:47                       ` What's in git.git (stable) Junio C Hamano
2007-07-28  8:56                         ` David Kastrup
2007-07-28  9:02                           ` Junio C Hamano
2007-07-28  9:35                           ` David Kastrup
2007-07-29  3:16                             ` Theodore Tso
2007-07-29  9:05                               ` David Kastrup
2007-07-29 16:40                                 ` Theodore Tso
2007-07-29 11:27                               ` Johannes Schindelin
2007-07-28 12:28                         ` Thomas Glanzmann
2007-08-07  6:22                         ` Junio C Hamano
2007-05-09  8:46 Junio C Hamano
2007-04-16  1:27 Junio C Hamano
2007-04-18 23:58 ` Junio C Hamano
2007-04-22  6:22   ` Junio C Hamano
2007-04-23  7:04     ` Junio C Hamano
2007-04-27  8:34       ` Junio C Hamano
2007-04-27  9:19         ` Andy Parkins
2007-04-27 14:01           ` Nicolas Pitre
2007-04-27 15:21             ` Andy Parkins
2007-04-27 17:11           ` Linus Torvalds
2007-04-27 18:03             ` Andy Parkins
2007-04-27 18:12               ` Linus Torvalds
2007-04-29 18:33         ` Junio C Hamano
2007-04-30  4:15           ` J. Bruce Fields
2007-04-30  5:12             ` Junio C Hamano
2007-05-01  3:36               ` J. Bruce Fields
2007-05-06  8:53           ` Junio C Hamano
2007-05-07  0:59             ` Jakub Narebski
2007-05-07 13:33             ` Frank Lichtenheld
2007-04-09  8:17 Junio C Hamano
2007-03-31  9:34 Junio C Hamano
2007-03-31 11:54 ` Alex Riesen
2007-04-05  6:44 ` Junio C Hamano
2007-02-20  7:32 Junio C Hamano
2007-02-23  8:33 ` Junio C Hamano
2007-03-04 10:32   ` Junio C Hamano
2007-03-13  8:49     ` Junio C Hamano
2007-03-13  9:26       ` Junio C Hamano
2007-03-22 17:08       ` Steven Grimm
2007-03-22 21:30         ` Junio C Hamano
2007-03-25  8:32       ` Junio C Hamano
2007-02-14 23:54 Junio C Hamano
2007-02-07 23:21 [ANNOUNCE] GIT 1.5.0-rc4 Junio C Hamano
2007-02-13  5:15 ` What's in git.git (stable) Junio C Hamano
2007-02-13 10:15   ` Johannes Schindelin
2007-02-13 17:33     ` Junio C Hamano
2007-02-13 18:21       ` Randal L. Schwartz
2007-02-13 18:37         ` Johannes Schindelin
2007-02-13 22:02           ` Jimmy Tang
2007-02-13 23:31             ` Linus Torvalds
2007-02-13 13:56   ` Matthias Lederhofer
2007-02-13 16:58     ` Junio C Hamano
2007-02-13 14:33   ` Bill Lear
2007-02-13 14:37     ` Bill Lear
2007-02-13 17:18       ` Randal L. Schwartz
2007-02-01  0:26 [ANNOUNCE] GIT 1.5.0-rc3 Junio C Hamano
2007-02-04  9:36 ` What's in git.git (stable) Junio C Hamano
2007-02-04 18:51   ` Jeff King
2007-02-04 19:12     ` Linus Torvalds
2007-02-04 20:58       ` Theodore Tso
2007-02-04 21:34         ` Jakub Narebski
2007-02-04 22:25           ` David Kågedal
2007-01-27  8:05 Junio C Hamano
2007-01-27  8:59 ` Aneesh Kumar K.V
2007-01-27 18:06   ` J. Bruce Fields
2007-01-27 22:00   ` Junio C Hamano
2007-01-27 17:56 ` J. Bruce Fields
2007-01-28 19:34 ` Bill Lear
2007-01-28 20:06   ` Junio C Hamano
2007-01-10  8:24 Junio C Hamano
2007-01-10  8:23 Junio C Hamano
2007-01-02  0:07 Junio C Hamano
2007-01-07  7:43 ` Junio C Hamano
2006-12-31  8:07 Junio C Hamano
2006-12-27  7:39 [RFH] An early draft of v1.5.0 release notes Junio C Hamano
2006-12-27  8:18 ` Shawn Pearce
2006-12-27 10:12 ` Jakub Narebski
2006-12-27 10:24   ` Junio C Hamano
2006-12-27 11:54     ` Johannes Schindelin
2006-12-27 12:15       ` Jakub Narebski
2006-12-27 12:12     ` Jakub Narebski
2006-12-27 13:00       ` Horst H. von Brand
2006-12-27 19:42         ` Junio C Hamano
2006-12-28  0:49           ` Junio C Hamano
2006-12-28  1:44             ` Nicolas Pitre
2006-12-29 11:56               ` David Kågedal
2006-12-27 19:45       ` Junio C Hamano
2006-12-28  0:32       ` Jakub Narebski
2006-12-27 10:50   ` Junio C Hamano
2006-12-27 12:06 ` Horst H. von Brand
2006-12-28  2:58   ` Junio C Hamano
2006-12-28 11:50     ` Jakub Narebski
2006-12-28  1:45 ` An early draft of v1.5.0 release notes (2nd ed) Junio C Hamano
2006-12-28  2:03   ` Shawn Pearce
2006-12-28  2:20     ` Junio C Hamano
2006-12-28  2:28       ` Shawn Pearce
2006-12-28  2:41         ` Junio C Hamano
2006-12-28  2:47           ` Shawn Pearce
2006-12-28  5:54             ` Junio C Hamano
2007-01-10  7:58   ` An early draft of v1.5.0 release notes (3rd ed) Junio C Hamano
2006-12-28  3:03 ` [RFH] An early draft of v1.5.0 release notes Eric Wong
2006-12-28  5:34   ` Junio C Hamano
2006-12-26  3:22 What's in git.git (stable) and announcing GIT 1.5.0 preview Junio C Hamano
2006-12-29  5:44 ` What's in git.git (stable) Junio C Hamano
2006-12-22  9:25 Junio C Hamano
2006-12-22 17:15 ` Randal L. Schwartz
2006-12-22 17:19   ` Randal L. Schwartz
2006-12-22 18:09     ` Johannes Schindelin
2006-12-22 18:12       ` Randal L. Schwartz
2006-12-22 18:21         ` Randal L. Schwartz
2006-12-22 19:21         ` Johannes Schindelin
2006-12-22 20:13           ` Junio C Hamano
2006-12-22 20:44             ` Johannes Schindelin
2006-12-22 21:44               ` Junio C Hamano
2006-12-26 20:25                 ` Luben Tuikov
2006-12-26 23:54                   ` Junio C Hamano
2006-12-27  1:19                     ` Luben Tuikov
2006-12-27  2:14                       ` Junio C Hamano
2006-12-22 18:58     ` Junio C Hamano
2006-12-22 20:04       ` Jakub Narebski
2006-12-22 20:16         ` Junio C Hamano
2006-12-22 20:56           ` Jakub Narebski
2006-12-22 21:49             ` Junio C Hamano
2006-12-22 20:21 ` Quy Tonthat
2006-12-18  7:26 Junio C Hamano
     [not found] ` <Pine.LNX.4.64.0612181012280.3479@woody.osdl.org>
2006-12-18 22:04   ` Junio C Hamano
2006-12-16 23:10 Junio C Hamano
2006-12-06 21:18 Junio C Hamano
2006-12-08 15:36 ` Jakub Narebski
2006-12-09 20:44 ` Tilman Sauerbeck
2006-12-09 21:10   ` Junio C Hamano
2006-11-14 16:42 [PATCH] commit: Steer new users toward "git commit -a" rather than update-index Carl Worth
2006-11-14 18:55 ` Andy Whitcroft
2006-11-14 19:22   ` Cleaning up git user-interface warts Carl Worth
2006-11-14 19:29     ` Shawn Pearce
2006-11-14 19:59       ` Carl Worth
2006-11-14 19:47     ` Petr Baudis
2006-11-14 20:56       ` Carl Worth
2006-11-15  0:31         ` Junio C Hamano
2006-11-15  4:08           ` Petr Baudis
2006-11-15  4:33             ` Junio C Hamano
2006-11-15  4:46               ` Nicolas Pitre
2006-11-15 10:09                 ` Jakub Narebski
2006-11-15 10:15                   ` Santi Béjar
2006-11-15 10:28                     ` Jakub Narebski
2006-11-16  2:43                       ` Petr Baudis
2006-11-15 14:56                   ` Nicolas Pitre
2006-11-15 20:39               ` Petr Baudis
2006-11-15 10:05             ` Jakub Narebski
2006-11-15 10:25               ` Karl Hasselström
2006-11-15 20:51           ` Carl Worth
2006-11-15 20:57             ` Jakub Narebski
2006-11-15 22:00               ` Shawn Pearce
2006-11-15 22:17                 ` Carl Worth
2006-11-17 20:30         ` Steven Grimm
2006-11-17 21:35           ` Junio C Hamano
2006-11-17 22:07             ` Petr Baudis
2006-11-14 20:46     ` Karl Hasselström
2006-11-14 20:52     ` Nicolas Pitre
2006-11-14 21:01       ` Jakub Narebski
2006-11-14 21:32         ` Nicolas Pitre
2006-11-14 22:04           ` Jakub Narebski
2006-11-14 22:29             ` Nicolas Pitre
2006-11-14 21:10       ` Carl Worth
2006-11-14 21:30         ` Jakub Narebski
2006-11-14 21:34           ` Nicolas Pitre
2006-11-14 22:56             ` Junio C Hamano
2006-11-15  1:48               ` Nicolas Pitre
2006-11-15  2:10                 ` Junio C Hamano
2006-11-15  2:27                   ` Michael K. Edwards
2006-11-15  4:20                   ` Nicolas Pitre
2006-11-15  4:58                     ` Junio C Hamano
2006-11-15 18:03                     ` Linus Torvalds
2006-11-15 18:28                       ` Jakub Narebski
2006-11-15 20:31                         ` Josef Weidendorfer
2006-11-15 20:35                           ` Petr Baudis
2006-11-15 21:12                             ` Josef Weidendorfer
2006-11-15 21:31                               ` Linus Torvalds
2006-11-15 18:43                       ` Nicolas Pitre
2006-11-15 18:49                         ` Shawn Pearce
2006-11-15 19:05                           ` Marko Macek
2006-11-15 20:41                             ` Junio C Hamano
2006-11-15 22:07                               ` Shawn Pearce
2006-11-16  6:07                               ` Marko Macek
2006-11-16 10:36                                 ` Junio C Hamano
2006-11-17 13:45                                   ` Jakub Narebski
2006-11-15 22:28                             ` Sean
     [not found]                             ` <20061115172834.0a328154.seanlkml@sympatico.ca>
2006-11-16  3:07                               ` Petr Baudis
2006-11-15 18:58                       ` Andy Parkins
2006-11-15 19:18                         ` Linus Torvalds
2006-11-15 19:39                           ` Michael K. Edwards
2006-11-15 20:09                             ` Linus Torvalds
2006-11-15 20:21                               ` Nicolas Pitre
2006-11-15 20:40                                 ` Linus Torvalds
2006-11-15 21:08                                   ` Carl Worth
2006-11-15 21:31                                     ` Junio C Hamano
2006-11-15 21:40                                       ` Nicolas Pitre
2006-11-15 21:52                                         ` Junio C Hamano
2006-11-15 21:59                                           ` Nicolas Pitre
2006-11-17 12:20                                           ` Karl Hasselström
2006-11-15 21:45                                     ` Linus Torvalds
2006-11-15 22:52                                       ` Carl Worth
2006-11-15 23:02                                         ` Shawn Pearce
2006-11-15 23:33                                           ` Linus Torvalds
2006-11-16  0:08                                             ` Nicolas Pitre
2006-11-16  3:07                                               ` Linus Torvalds
2006-11-16  3:43                                                 ` Nicolas Pitre
2006-11-16  3:02                                             ` Michael K. Edwards
2006-11-16 11:35                                               ` Andreas Ericsson
2006-11-16 16:37                                             ` Carl Worth
2006-11-16 17:57                                               ` Michael K. Edwards
2006-11-16 18:23                                                 ` Carl Worth
2006-11-17  8:41                                                   ` Junio C Hamano
2006-11-17  9:18                                                     ` Carl Worth
2006-11-17 10:11                                                       ` Johannes Schindelin
2006-11-17 11:41                                                         ` Junio C Hamano
2006-11-17 16:58                                                         ` Shawn Pearce
2006-11-17 11:29                                                       ` Junio C Hamano
2006-11-15 23:07                                         ` Sean
     [not found]                                         ` <20061115180722.83ff8990.seanlkml@sympatico.ca>
2006-11-15 23:15                                           ` Shawn Pearce
2006-11-16  7:51                                             ` Richard CURNOW
2006-11-16 23:01                                               ` Johannes Schindelin
2006-11-21 13:25                                     ` Jerome Lovy
2006-11-16  4:26                                   ` Theodore Tso
2006-11-16 11:50                                     ` Andreas Ericsson
2006-11-16 16:30                                       ` Linus Torvalds
2006-11-16 17:01                                         ` Carl Worth
2006-11-16 17:30                                           ` Linus Torvalds
2006-11-16 17:44                                             ` Sean
2006-11-16  1:40                           ` Anand Kumria
2006-11-15 19:32                         ` Junio C Hamano
2006-11-16  1:14                       ` Theodore Tso
2006-11-16  4:21                         ` Junio C Hamano
2006-11-16 11:34                           ` Alexandre Julliard
2006-11-16 14:01                             ` Petr Baudis
2006-11-16 15:48                               ` Alexandre Julliard
2006-11-17 13:32                             ` Jakub Narebski
2006-11-17 16:49                               ` Alexandre Julliard
2006-11-17 17:41                                 ` Jakub Narebski
2006-11-16 16:07                           ` Theodore Tso
2006-11-16 16:49                             ` Theodore Tso
2006-11-22 23:21                             ` Sanjoy Mahajan
2006-11-24 11:29                               ` Jakub Narebski
2006-11-16  1:20                       ` Han-Wen Nienhuys
2006-11-16  1:53                         ` Jakub Narebski
2006-11-16  2:03                         ` Junio C Hamano
2006-11-16  2:30                           ` Han-Wen Nienhuys
2006-11-16  3:27                             ` Junio C Hamano
2006-11-16  3:35                               ` Junio C Hamano
2006-11-16  4:07                               ` Junio C Hamano
2006-11-16  3:12                         ` Linus Torvalds
2006-11-16 10:31                           ` Junio C Hamano
2006-11-16 10:45                           ` Han-Wen Nienhuys
2006-11-16 11:11                             ` Junio C Hamano
2006-11-16 11:47                               ` Junio C Hamano
2006-11-20 19:44                                 ` Horst H. von Brand
2006-11-20 19:46                                   ` Shawn Pearce
2006-11-20 20:02                                   ` Jakub Narebski
2006-11-16 13:03                               ` Han-Wen Nienhuys
2006-11-16 13:11                                 ` Han-Wen Nienhuys
2006-11-17 13:25                                 ` Jakub Narebski
2006-11-24 12:26                                   ` Han-Wen Nienhuys
2006-11-24 12:41                                     ` Jakub Narebski
2006-12-05 22:42                                     ` Johannes Schindelin
2006-12-05 22:58                                       ` Junio C Hamano
2007-02-23  0:35                                     ` [PATCH for "next"] pretty-formats: add 'format:<string>' Johannes Schindelin
2007-02-23  1:03                                       ` Han-Wen Nienhuys
2007-02-23  1:07                                         ` Johannes Schindelin
2007-02-23 19:53                                           ` Robin Rosenberg
2007-02-24  1:25                                             ` Johannes Schindelin
2007-02-23  6:21                                       ` Junio C Hamano
2007-02-23 11:48                                         ` Johannes Schindelin
2007-02-23 18:30                                           ` Junio C Hamano
2007-02-23 18:38                                             ` Johannes Schindelin
2006-11-16 16:23                             ` Cleaning up git user-interface warts Linus Torvalds
2006-11-16 16:42                               ` Han-Wen Nienhuys
2006-11-16 17:17                                 ` Linus Torvalds
2006-11-16 17:40                                   ` multi-project repos (was Re: Cleaning up git user-interface warts) Han-Wen Nienhuys
2006-11-16 18:21                                     ` Linus Torvalds
2006-11-16 18:33                                       ` multi-project repos Junio C Hamano
2006-11-16 19:01                                       ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
2006-11-17 16:26                                         ` Shawn Pearce
2006-11-17 16:45                                           ` Linus Torvalds
2006-11-17 16:51                                             ` Carl Worth
2006-11-17 17:08                                             ` Shawn Pearce
2006-11-17 16:46                                           ` Carl Worth
2006-11-17 17:15                                             ` Shawn Pearce
2006-11-17 17:50                                               ` Marko Macek
2006-11-17 20:24                                                 ` multi-project repos Junio C Hamano
2006-11-17 17:39                                           ` Junio C Hamano
2006-11-18  6:02                                             ` Shawn Pearce
2006-11-18  7:31                                               ` Junio C Hamano
2006-11-18  7:45                                                 ` Shawn Pearce
2006-11-16 22:21                                       ` multi-project repos (was Re: Cleaning up git user-interface warts) Johannes Schindelin
2006-11-16 22:44                                         ` multi-project repos Junio C Hamano
2006-11-17  0:29                                           ` Johannes Schindelin
2006-11-16 22:49                                         ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
2006-11-16 23:08                                           ` Linus Torvalds
2006-11-16 23:36                                           ` Johannes Schindelin
2006-11-17  0:49                                             ` Linus Torvalds
2006-11-17  1:08                                               ` Carl Worth
2006-11-17  1:22                                               ` Johannes Schindelin
2006-11-17  1:52                                                 ` Petr Baudis
2006-11-17  2:16                                                   ` Johannes Schindelin
2006-11-16 23:40                                           ` Han-Wen Nienhuys
2006-11-16 23:32                                       ` Han-Wen Nienhuys
2006-11-17 12:53                                         ` Jakub Narebski
2006-11-16 17:57                                   ` Cleaning up git user-interface warts Linus Torvalds
2006-11-16 18:27                                     ` Junio C Hamano
2006-11-16 18:28                                     ` Linus Torvalds
2006-11-16 19:47                                       ` Junio C Hamano
2006-11-16 19:53                                         ` Linus Torvalds
2006-11-16 18:13                                   ` Carl Worth
2006-11-16 23:00                           ` Johannes Schindelin
2006-11-16 23:22                             ` Linus Torvalds
2006-11-17  0:05                               ` Han-Wen Nienhuys
2006-11-17  0:13                                 ` Junio C Hamano
2006-11-17  0:27                                   ` Han-Wen Nienhuys
2006-11-17  0:35                                     ` Petr Baudis
2006-11-17  0:37                                   ` Carl Worth
2006-11-17  1:25                                   ` Carl Worth
2006-11-17  0:39                                 ` Linus Torvalds
2006-11-17  0:52                                   ` Han-Wen Nienhuys
2006-11-17  1:34                                 ` Michael K. Edwards
2006-11-17  6:42                                   ` Michael K. Edwards
2006-11-17  7:32                                     ` Junio C Hamano
2006-11-18  1:24                                       ` Michael K. Edwards
2006-11-17 12:25                                     ` Jakub Narebski
2006-11-23  2:52                                 ` Horst H. von Brand
2006-11-16  4:30                       ` Petr Baudis
2006-11-15 20:12                   ` Petr Baudis
2006-11-15 20:26                     ` Nicolas Pitre
2006-11-15 20:50                       ` Linus Torvalds
2006-11-15 21:18                         ` Nicolas Pitre
2006-11-16  1:51                       ` Anand Kumria
2006-11-14 22:36         ` Junio C Hamano
2006-11-14 22:50           ` Junio C Hamano
2006-11-15  4:32             ` Nicolas Pitre
2006-11-15  5:35               ` Junio C Hamano
2006-11-15  6:18                 ` Shawn Pearce
2006-11-15  6:30                   ` Junio C Hamano
2006-11-15 14:01                 ` Johannes Schindelin
2006-11-15 15:03                   ` Sean
2006-11-15 15:10                   ` Nicolas Pitre
2006-11-15 18:16                     ` Junio C Hamano
2006-11-15 19:02                       ` Andy Parkins
2006-11-15 19:41                         ` Junio C Hamano
2006-11-15 20:15                           ` Nicolas Pitre
2006-11-15 20:19                           ` Carl Worth
2006-11-15 21:13                             ` Junio C Hamano
2006-11-15 22:36                               ` Carl Worth
2006-11-16  3:21                                 ` Petr Baudis
2006-11-16 10:09                                   ` Robin Rosenberg
2006-11-16 13:46                                     ` Petr Baudis
2006-11-16  0:23                       ` Han-Wen Nienhuys
2006-11-15  9:17               ` Andy Parkins
2006-11-15  9:59                 ` Jakub Narebski
2006-11-15 10:33                   ` Andy Parkins
2006-11-15 10:48                     ` Karl Hasselström
2006-11-15 11:28                       ` Andy Parkins
2006-11-15 15:41                 ` Nicolas Pitre
2006-11-15 17:59                   ` Junio C Hamano
2006-11-15 18:11                     ` Nicolas Pitre
2006-11-16 13:21                       ` Karl Hasselström
2006-11-18 11:09                   ` Alan Chandler
2006-11-15 17:55                 ` Junio C Hamano
2006-11-15 19:14                   ` Andy Parkins
2006-11-16  3:53                 ` Petr Baudis
2006-11-15 12:15               ` Andreas Ericsson
2006-11-15 12:31                 ` Jakub Narebski
2006-11-16 13:58               ` Petr Baudis
2006-11-16  5:12           ` Petr Baudis
2006-11-16 10:45             ` Junio C Hamano
2006-11-16 13:43               ` Petr Baudis
2006-11-16 21:49             ` Junio C Hamano
2006-11-16 22:20               ` Petr Baudis
2006-11-17  1:49                 ` Junio C Hamano
2006-11-17  0:11             ` Han-Wen Nienhuys
2006-11-18  7:59           ` Alan Chandler
2006-11-14 23:30   ` [PATCH] commit: Steer new users toward "git commit -a" rather than update-index Junio C Hamano
2005-07-27 10:01 Git 1.0 Synopis (Draft v2) Ryan Anderson
2005-07-27 22:13 ` Junio C Hamano
2005-07-29  8:27   ` Ryan Anderson
2005-07-29  8:29 ` Git 1.0 Synopis (Draft v3 Ryan Anderson
2005-07-29 10:58   ` Johannes Schindelin
2005-07-29 21:26   ` Sam Ravnborg
2005-07-31 22:18     ` Horst von Brand
2005-07-31 22:15   ` Horst von Brand
2005-08-01 13:21     ` Horst von Brand
2005-08-15  4:55     ` Git 1.0 Synopis (Draft v4) Ryan Anderson
2005-08-15  5:09       ` Ryan Anderson
2005-08-15  5:19       ` Junio C Hamano
2005-08-15  6:58         ` Ryan Anderson
2005-08-15  7:17           ` Junio C Hamano
2005-08-15  8:02             ` Ryan Anderson
2005-08-15  8:17               ` Junio C Hamano
2005-08-15 18:59                 ` Daniel Barkalow
2005-08-16  7:28                   ` Junio C Hamano
2005-08-16 10:03                     ` Johannes Schindelin
2005-08-16 10:14                       ` Dongsheng Song
2005-08-16 10:17                       ` about git server & permissions Dongsheng Song
2005-08-16 15:31                     ` Git 1.0 Synopis (Draft v4) Johannes Schindelin
2005-08-16 15:47                       ` Daniel Barkalow
2005-08-16 15:39                     ` Daniel Barkalow
2005-08-16 19:41                     ` Horst von Brand
2005-08-16 20:41                       ` Johannes Schindelin
2005-08-18  9:27                       ` Matthias Urlichs

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