LKML Archive on
help / color / mirror / Atom feed
From: Johannes Schindelin <>
To: Junio C Hamano <>
Subject: Re: [Announce] GIT v1.5.0-rc2
Date: Sun, 21 Jan 2007 22:55:52 +0100 (CET)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


On Sun, 21 Jan 2007, Junio C Hamano wrote:

>  - 'git pack-refs' appeared in v1.4.4;

You should probably mention that it is not necessary to run git-pack-refs 
by hand: git-gc is what you want.

BTW have I praised y'all for inventing git-gc? It is _awesome_. I think I 
will turn into a DWIM geek yet; it is soooo much more convenient to issue 
"git gc" from time to time, than to think exactly about what I want to 
clean up right now.

>  - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
>    seriously enhanced during v1.4.0 timeperiod.

Should we introduce "git config" in time for the "let's please end-users" 
release (1.5.0)?

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

... instead of $GIT_DIR/refs/heads/, making the difference between 
remotely tracked and local branches more obvious.

>  - git-branch and git-show-branch know remote tracking branches.

... (use the command line switch "-r" to list only tracked branches.)

>  - git-push can now be used to delete a remote branch or a tag.
>    This requires the updated git on the remote side.

... (use "git push <remote> :refs/heads/<branch>" to delete "branch".)

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

It might make sense to enable something similar for git-fetch in time for 

> * Reflog
>  - Reflog records the history of where the tip of each branch
>    was at each moment.

It might make sense to reformulate that:

	Reflog records the history from the view point of the local 
	repository. In other words, regardless of the real history,
	the reflog shows the history as seen by one particular repository
	(this enables you to ask "what was the current revision in _this_
	repository, yesterday at 1pm?").

>  - There is a toplevel garbage collector script, 'git-gc', that
>    is an easy way to run 'git-repack -a -d', 'git-reflog gc',
>    and 'git-prune'.

Did I mention that I really _love_ git-gc?

>  - The original implementation of git-merge-recursive which was
>    in Python has been removed; we have C implementation of it
>    now.

I am no native speaker, but should that not be "we have a C 
implementation" instead?

>  - The default suffix for git-format-patch output is now ".patch",
>    not ".txt".  This can be changed with --suffix=.txt option,
>    or "format.suffix = .txt" in the configuration.

I fully expect people to complain that a config like this

	format.suffix = .txt

does not work. better say ...

	or setting the config variable "format.suffix" to ".txt".

>  - Better error messages for often used Porcelainish commands.

Amen. I think this really helped a lot of people already.

>    - Cloning and fetching _from_ a shallow clone are not
>      supported (nor tested -- so they might work by accident but
>      they are not expected to).

Maybe we should go the "restrict first, and loosen later" approach? I.e. 
forbid git-upload-pack to run if is_repository_shallow()?

>    - Pushing from nor into a shallow clone are not expected to
>      work.

Maybe forbid git-push and git-receive-pack to run if 

(I _think_ git-push should be safe, but not git-receive-pack.)


  parent reply	other threads:[~2007-01-21 21:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-21  8:56 Junio C Hamano
2007-01-21 11:20 ` Junio C Hamano
2007-01-21 13:42   ` Bill Lear
2007-01-21 13:52     ` Bill Lear
2007-01-21 21:26       ` Johannes Schindelin
2007-01-21 21:33         ` Jakub Narebski
2007-01-21 22:01           ` Johannes Schindelin
2007-01-21 22:24             ` Jakub Narebski
2007-01-21 13:43   ` Willy Tarreau
2007-01-21 15:06     ` Jakub Narebski
2007-01-21 18:58     ` Junio C Hamano
2007-01-21 19:49       ` H. Peter Anvin
2007-01-22 17:23         ` Nicolas Pitre
2007-01-21 20:01       ` Horst H. von Brand
2007-01-22  1:27         ` Junio C Hamano
2007-01-21 19:46   ` Horst H. von Brand
2007-01-21 21:55   ` Johannes Schindelin [this message]
2007-01-21 22:45     ` Jakub Narebski
2007-01-22 18:08   ` Carl Worth
2007-01-22 19:28     ` Junio C Hamano
2007-01-23  1:01       ` Carl Worth
2007-01-22 18:22   ` Jakub Narebski

Reply instructions:

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

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

  Avoid top-posting and favor interleaved quoting:

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

  git send-email \ \ \ \ \ \
    --subject='Re: [Announce] GIT v1.5.0-rc2' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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