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.