linux-kernel - Re: [Announce] GIT v1.5.0-rc2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.63.0701212234520.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Date:	Sun, 21 Jan 2007 22:55:52 +0100 (CET)
From:	Johannes Schindelin <Johannes.Schindelin@....de>
To:	Junio C Hamano <junkio@....net>
cc:	git@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [Announce] GIT v1.5.0-rc2

Hi,

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

> * 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 
is_repository_shallow()?

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

Ciao,
Dscho

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/