threads / discuss / 3848

What's in git.git

Subject: What's in git.git

## tl;dr

4 messages between Apr 11, 2006 and Apr 11, 2006.

replies: 3people: 3as markdown or json

Junio C Hamano· Apr 11, 2006, 04:40 UTC · lore
No real 1.3.0 yet...
* The 'master' branch has these since the last announcement.
  All of them are fixes and clean-ups (except --parents stuff
  from Linus which seems safe enough).
Junio C Hamano:
      git-log: match rev-list --abbrev and --abbrev-commit
      diff: fix output of total-rewrite diff.
      diffcore-rename: fix merging back a broken pair.
      Retire diffcore-pathspec.
      Retire git-log.sh
      Retire git-log.sh (take#2)
Linus Torvalds:
      Make "--parents" logs also be incremental
Marco Roeland:
      xdiff/xdiffi.c: fix warnings about possibly uninitialized variables
Petr Baudis:
      Improve the git-diff-tree -c/-cc documentation
* The 'next' branch, in addition, has these.
  - diff-* --patch-with-raw
  - Implement limited context matching in git-apply (Eric W. Biederman)
  - log-tree: separate major part of diff-tree.
  - git log [diff-tree options]...

I should not be moving anything new from "next" to "master" before 1.3.0, but I am inclined to include the --patch-with-raw change, which Cogito wants. Also apply -Cn by Eric seems safe enough; as long as you do not ask for it, it keeps the existing behaviour. The initial part of "git log with diff-tree options" seems safe enough so it is also in 'next'.

I have the rest of "git log with diff-tree options", along with its fallouts, which turned out to be more than what I wanted to see, in "pu".

Linus Torvalds· Apr 11, 2006, 13:50 UTC · re: Junio C Hamano · lore

Re: What's in git.git

On Mon, 10 Apr 2006, Junio C Hamano wrote:
>
>       Retire git-log.sh
>       Retire git-log.sh (take#2)
I think you need a (take#3).

This creates "git-log" as a link to "git", but does so at _build_ time, not install time.

Which means that when it actually gets installed, it gets installed as a copy of that link, and you get two different executables instead of one single executable that is just linked to two names:

  [torvalds@g5 git]$ ls -li /home/torvalds/bin/git ~/bin/git-log
  67272830 -rwxr-xr-x 1 torvalds torvalds 333613 Apr 11 06:45 /home/torvalds/bin/git
  67272781 -rwxr-xr-x 1 torvalds torvalds 333613 Apr 11 06:45 /home/torvalds/bin/git-log

so it _works_, but it wastes 300kB+ for each "builtin". Which was kind of against the whole point.

I think the builtins should be a install-time only issue. 
		Linus
Petr Baudis· Apr 11, 2006, 15:55 UTC · re: Linus Torvalds · lore

Re: What's in git.git

Dear diary, on Tue, Apr 11, 2006 at 03:50:14PM CEST, I got a letter where Linus Torvalds <torvalds@osdl.org> said that...

> I think the builtins should be a install-time only issue. 

I don't care about git-log in particular since I don't use it, but I use development Git versions without actually installing them and if it's not a huge hurdle, it would be nice to keep this possible.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.
Junio C Hamano· Apr 11, 2006, 17:58 UTC · re: Petr Baudis · lore

Re: What's in git.git

Petr Baudis <pasky@suse.cz> writes:
Show 5 quoted lines
>> I think the builtins should be a install-time only issue. 
>
> I don't care about git-log in particular since I don't use it, but I use
> development Git versions without actually installing them and if it's
> not a huge hurdle, it would be nice to keep this possible.

Also not making the link would probably break test suite (I do not know if we have git-log test right now, though).

But installing *copies* is obviously not right as you pointed out.

← back to recent threads