What's new in git.git

What's new in git.git

[Junio C Hamano]

I was planning to do a 1.2.0 this weekend, but things slipped.
But in a good way.  We've had quite a long but good discussion
on how people expect "git commit paths..." to behave, and along
the way the command learned a couple of new tricks.

In 1.2.0, there will be three major changes that might surprise
people who are still using 1.1.0 based releases (e.g. 1.1.6).
People who followed the list traffic and/or the master branch
are familiar with them already:

 * Checkout -m option.  This allows you to switch branches when
   you have local changes to paths that are different in the
   current branch and new branch.

 * Add -c and --cc to diff-tree and diff-files.  They give the
   "combined diff" output that shows merges more human readably.

 * git-commit updates.

   - Allow git-commit from a subdirecotry.

   - Aborted "git-commit -a" leaves the index as it was.

   - "git commit --only paths..." checks in changes to only
     named paths.  We may later make this default for "git
     commit" with explicit paths.

   - Add --author='A U Thor <author@example.com>' command
     line option.

These are still in "pu" but I am expecting all of them would
graduate to "master" before 1.2.0:

 - git-show (Linus)
 - git-daemon updates (Mark Wooding)
 - git-http-fetch various fixes (Mark Wooding)
 - git-commit updates
 - git-read-tree --aggressive to speed up resolve merger
 - git-fmt-merge-msg to optionally put shortlog in merge commit log
 - fix git-rev-list --parents | git-diff-tree --stdin
 - git-rerere

Re: What's new in git.git

[Linus Torvalds]

On Sun, 5 Feb 2006, Junio C Hamano wrote:
> 
>  * Add -c and --cc to diff-tree and diff-files.  They give the
>    "combined diff" output that shows merges more human readably.

Btw, the only concern I have left about "-c" and "--cc" is that I don't 
think the old merge-diff behaviour makes any sense at all, and that we 
should drop it entirely in favour of "-c" and "--cc".

The old merge-diff code was so useless that nobody ever used it. It was 
disabled by default (you had to enable it specially with the "-m" flag), 
and I don't think anybody really ever did. The output was just not usable.

The only reason it existed at all was really because I _didn't_ do it 
right, and I wanted some output.

So I would actually much prefer that "-c" would be the default, and that 
"-p" would imply "--cc". With some other option to have the "long format" 
diff.

Has anybody on the git list ever used "-m" with git-diff-tree? Speak up..

		Linus

Re: What's new in git.git

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Sun, 5 Feb 2006, Junio C Hamano wrote:
>> 
>>  * Add -c and --cc to diff-tree and diff-files.  They give the
>>    "combined diff" output that shows merges more human readably.
>
> Btw, the only concern I have left about "-c" and "--cc" is that I don't 
> think the old merge-diff behaviour makes any sense at all, and that we 
> should drop it entirely in favour of "-c" and "--cc".
> ...
> Has anybody on the git list ever used "-m" with git-diff-tree? Speak up..

One thing that makes me a bit reluctant is that I am not as
confident as you are about -c doing the right thing.  I have not
examined differences between -m -p and -c, especially under
various combinations of other flags like -B, -C and -M. I did
compare output from -c and --cc to check if the logic to drop
"uninteresting" hunks are doing the right thing and I am
reasonably sure that part is good, though.

The code to do -c punts at showing type changes, and there is no
filemode information in the output either.  So far nobody has
complained about it, and a type change would be a rare thing
anyway and might not matter in practice.  We should however not
just silently ignore rare cases that we do not handle.  Instead
we should raise a big red flag; otherwise the rare cases in
which -c cheats can go unnoticed, which feels wrong.

Having said that, the above concern is primarily about debugging
the -c implementation and for that we could always fall back on
running "diff-tree -p H H^2" by hand, so maybe dropping "-m -p"
is an OK thing to do from that point of view.

People who are doing SCM migration part might be using it as a
replacement for "for i; do diff-tree -p H H^$i; done" to extract
diffs from each parent with a single command, though...

Re: What's new in git.git

[Johannes Schindelin]

Hi,

On Mon, 6 Feb 2006, Linus Torvalds wrote:

> Has anybody on the git list ever used "-m" with git-diff-tree? Speak up..

I have. When I tried to pickaxe some ugly bug across several merges. I 
guess "--cc" is more effective anyway, so I wouldn't mind to let "-m" go.

Ciao,
Dscho

Heads up, git.git approaches 1.2.0

[Junio C Hamano]

I've done a bit more work to round the corners diff-tree -c/--cc
had.  Most notably, earlier the algorithm punted if the merge
removed or added files.  These should raise red flag, because
diff-tree -c/--cc deal with case where the result is different
from all parents, so removal of a file means all parents had it
in some shape but the file does not appear in the result, and
addition of a file means no parents had it but merge made it
magically appear.  These cases are now shown as interesting.

BTW, I was pleasantly surprised that "git show 2950411" showed
exactly what the commit log message said.  Now I agree with
Linus that --cc is a wonderful thing ;-).

Tonight I have pushed out all I said I would want to have in the
next feature release 1.2.0 in the master branch, so that people
can beat it more easily and help us shaking out potential bugs.
Most of the things are something I've been using myself on git
itself and also during my day-job, so there hopefully won't be
any major data eating problems.  Admittedly I almost never do
"git commit paths...", but for the last couple of days I tried
to use it whenever possible to make sure it works as intended.
It defaults to --include behaviour which is the traditional one.

"git commit --only paths..." and running "git commit" from a
subdirectory are also implemented and I've tried them with toy
commits.  If you are one of the people who missed them, please
try it out and see if they satisfy your expectations.

I might receive some more HTTP fixes from Mark, documentation
updates from J. Bruce etc. and I'd merge them before 1.2.0. But
otherwise I am pretty happy with what's there in the "master"
branch right now.  The tip of the "master" is this commit:

    commit 5a798fb57f788692467b1a11416dd5ebff0d31ae
    Author: Junio C Hamano <junkio@cox.net>

        git-commit: finishing touches.

Please consider it a 1.2.0-rc1, and treat it the same way you
would treat -rc1 from the kernel project.  If you are going to
test only one -rc version, this is THE one to test, and all the
rest are bugfixes.

What's new in git.git

[Junio C Hamano]

Latest maintenance release for GIT 1.0 (1.0.8) and the new
feature release GIT 1.1.0 have been pushed out.

Waiting in the proposed updates branch are two backward
incompatible changes.

 - Require packfiles to be named pack-[0-9a-f]{40}.pack, and
   issue an warning if [0-9a-f]{40} part does not match the SHA1
   checksum of sorted object names that are contained in the
   pack.  Later I would like to promote the warning to an error,
   and there is a tool to help renaming packs created with older
   git-pack-objects.  When the warning is promoted to an error,
   this will break existing packfiles.

 - Use textual symbolic refs to represent .git/HEAD everywhere,
   not just on filesystems without symbolic link supports.  This
   was proposed by Pavel mid November 2005, but is known to
   break Porcelains that read(2) from .git/HEAD and expect to
   read an object name for the current branch head (use "git
   rev-parse --verify HEAD" instead), and write(2) into
   .git/HEAD and expect to update the current branch head (use
   "git update-ref HEAD $commit [$old]" instead).  Last time I
   checked, gitweb would break with this change.

Also there are patches floating around to update format-patch
and rebase.  I rejected the initial round, but consider what
the latter wants to achieve a worthwhile goal, and expect to
update rebase in some form.

Now the core and the barebone Porcelain are more or less stable
and changes have significantly slowed down, I think it is a good
time to start revisiting the libification effort, started by
Smurf.  I haven't taken a look at his tree for a while.

Another area that needs attention is to see how we can improve
handling of merges between branches that have renamed things
(i.e. HPA's klibc repositories).  I'd also like to teach
renaming merge to resolve strategy somehow.

Other small things I have in mind, in random order, are:

 - Give extra option to "diff-tree -m -p" to show difference
   between natural merge among parents and the actual merge
   result.  I do not think this would make sense for non patch
   format.

 - The recent "git-daemon --base=/pub/git" is a good addition
   (git://host/frotz.git is mapped to /pub/git/frotz.git
   directory), but with the current implementation whitelist
   needs to start with /pub/git/.  I initially thought it was
   not so nice, but maybe it is OK; but this needs to be
   documented.  It also forbids user relative paths, which
   should be made an independent switch.

 - Also in "git-daemon", I outlined --strict-symlink option a
   while ago, which forbids symbolic links to step outside of
   whitelisted areas.  This has not been implemented, and we may
   want to add it.

 - Although Linus has been pretty negative about improving the
   current dumb http transport, many people seem to rely on it.
   It "works" with packfiles in the sense that it does not barf,
   but the server file packing strategy to reduce duplicated
   download needs to be worked out to make it more efficient.

 - If the same cloning requests are made number of times, we
   should be able to cache the packfile we sent out and reuse,
   to reduce the load on the server side.  When used with
   git-daemon, this requires the daemon to be able to write
   somewhere (not necessarily the original repository itself),
   so there is certain security implications.