What's in git.git

The "deathmatch" between Ryan's annotate and Fredrik's blame is
officially on.  Currently the last test in all three branches
fail.  Please do not get alarmed.

I'd like asciidoc tweaks in "next" by Francis Daly tested by
people who have access to different vintages of docbook-xsl by
trying to build manpages.  Look for displayed examples, such as
the one in git-branch documentation.  I've tried it with v1.68
and getting far better results than before, and Francis says
v1.69 works fine with or without the change. IOW this is a
workaround for a problem in v1.68.

I've been tweaking on-and-off the similarity estimator in the
"next" branch.  It has become independent from the xdelta code
used for pack generation.  It may detect more renames that it
missed before, and it may miss some other renames and copies.
In general, it seems that the algorithm tends to detect slightly
more breaks than before.  I'd appreciate feedback from people
interested in this area.

Another thing I have started in "pu" branch is to stop placing
an object we decided to delta that is already max-depth deep
back in the delta-base window, because such a thing only wastes
the delta base slot.  The changed pack-objects does pick up more
delta, but the resulting pack seems bigger and I am puzzled why.

This may suggest that our criteria to delta should be tightened
a bit (the value of max_size in try_delta should be decreased).
We are better off storing a plain deflated representation instad
of generating a bad, bigger delta.  Insights?

-- -- --

* The 'master' branch has these since the last announcement.

- Documentation fixes (Dmitry V. Levin, Mark Wooding, Martin
  Langhoff, Jeff Muizelaar)

  git/Documentation: fix SYNOPSIS style bugs
  Documentation/Makefile: Some `git-*.txt' files aren't manpages.
  cvsserver: updated documentation
  cosmetics: change from 'See-Also' to 'See Also'
  documentation: add 'see also' sections to git-rm and git-add

- The deathmatch between annotate/blame (Ryan Anderson, Fredrik
  Kuivinen, me cheerleading)

  annotate: Support annotation of files on other revisions.
  git-blame: Make the output human readable
  git-blame: Use the same tests for git-blame as for git-annotate
  blame: avoid -lm by not using log().
  blame and annotate: show localtime with timezone.
  blame: avoid "diff -u0".
  annotate/blame tests updates.
  annotate-blame test: don't "source", but say "."
  annotate-blame test: add evil merge.

- Tweak rev-list (Linus Torvalds)

  get_revision(): do not dig deeper when we know we are at the end.

- Fix git-commit --amend (me)

  git-commit --amend: allow empty commit.

- Misc fixes and cleanups (Mark Wooding and me)

  gitignore: Ignore some more boring things.
  contrib/emacs/Makefile: Provide tool for byte-compiling files.
  Const tightening.

* The 'next' branch, in addition, has these.

- Fix manpage formatting (Francis Daly)

  Tweak asciidoc output to work with broken docbook-xsl

- Tweak break/rename/copy similarity estimator tweaks (me)

  diffcore-rename: similarity estimator fix.
  count-delta: no need for this anymore.
  diffcore-break: similarity estimator fix.
  diffcore-delta: make change counter to byte oriented again.

- Help pack generation tweaks (me)

  verify-pack -v: show delta-chain histogram.

- checkout-index --temp (Shawn Pearce)

  Add --temp and --stage=all options to checkout-index.

* The 'pu' branch, in addition, has these.

- WIP: pack generation tweak (me)

  [WIP] do not waste delta window with objects with already at max-depth.

On 3/6/06, Junio C Hamano [off-list ref] wrote:

- The deathmatch between annotate/blame (Ryan Anderson, Fredrik
  Kuivinen, me cheerleading)

Add fuel to the fire  ;-) Can git-blame take cached git-rev-list
output like annotate does with -S?


m

Hi,

On Sun, 5 Mar 2006, Junio C Hamano wrote:

Another thing I have started in "pu" branch is to stop placing
an object we decided to delta that is already max-depth deep
back in the delta-base window, because such a thing only wastes
the delta base slot.  The changed pack-objects does pick up more
delta, but the resulting pack seems bigger and I am puzzled why.

Not that I know much about the pack format, but is it possible that the 
deltas are deflated? In that case, a possible explanation is that a better 
delta is less compressible (and taken together, this could amount to more 
bytes).

Ciao,
Dscho

Junio C Hamano wrote:
 

I'd like asciidoc tweaks in "next" by Francis Daly tested by
people who have access to different vintages of docbook-xsl by
trying to build manpages.  Look for displayed examples, such as
the one in git-branch documentation.  I've tried it with v1.68
and getting far better results than before, and Francis says
v1.69 works fine with or without the change. IOW this is a
workaround for a problem in v1.68.

I tested it with asciidoc 7.0.1 and the examples in the git-branch 
man page look better with the fix.

/Lukas

Before:
 Examples
       Start development off of a know tag


              $  git  clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 $
              cd my2.6 $ git branch my2.6.14 v2.6.14 $ git checkout my2.6.14

               These two steps are the same as "checkout -b my2.6.14 v2.6.14".

       Delete unneeded branch


              $  git clone git://git.kernel.org/.../git.git my.git $ cd my.git
              $ git branch -D todo

               delete todo branch even if the "master" branch  does  not  have
              all commits from todo branch.

After:
   Examples
       Start development off of a know tag

              $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
              $ cd my2.6
              $ git branch my2.6.14 v2.6.14
              $ git checkout my2.6.14

               These two steps are the same as "checkout -b my2.6.14 v2.6.14".


       Delete unneeded branch

              $ git clone git://git.kernel.org/.../git.git my.git
              $ cd my.git
              $ git branch -D todo

               delete todo branch even if the "master" branch does not have all
              commits from todo branch.

On Mon, Mar 06, 2006 at 10:05:41PM +1300, Martin Langhoff wrote:

On 3/6/06, Junio C Hamano [off-list ref] wrote:

quoted

- The deathmatch between annotate/blame (Ryan Anderson, Fredrik
  Kuivinen, me cheerleading)

Add fuel to the fire  ;-) Can git-blame take cached git-rev-list
output like annotate does with -S?

Currently it cannot do that. How is that option used? If you want to
make annotate/blame faster for certain files you might as well cache
the output of annotate/blame instead of the git-rev-list output, no?

What am I missing?

- Fredrik

Hi,

On Fri, 10 Mar 2006, Fredrik Kuivinen wrote:

On Mon, Mar 06, 2006 at 10:05:41PM +1300, Martin Langhoff wrote:

quoted

On 3/6/06, Junio C Hamano [off-list ref] wrote:

quoted

- The deathmatch between annotate/blame (Ryan Anderson, Fredrik
  Kuivinen, me cheerleading)

Add fuel to the fire  ;-) Can git-blame take cached git-rev-list
output like annotate does with -S?

Currently it cannot do that. How is that option used?

The history is linearized, and the commits are ordered accordingly, then 
to be passed to git-annotate/-blame.

If you want to make annotate/blame faster for certain files you might as 
well cache the output of annotate/blame instead of the git-rev-list 
output, no?

What am I missing?

Two things:

- the history is growing, and
- it would be inefficient/error-prone to save the annotates for files 

Hth,
Dscho
  

On 3/11/06, Johannes Schindelin [off-list ref] wrote:

The history is linearized, and the commits are ordered accordingly, then
to be passed to git-annotate/-blame.

Exactly.

If a process has already done the costly git-rev-list for other
purposes (say, grab logentries of the relevant commits), and wants to
also run annotate/blame, it should be able to reuse it cheaply, by
passing -S filename. Possibly an IDE (or gitk/qgit) would want to do
this.

Now, what I use it for in git-cvsserver is to "flatten" merges. CVS
clients don't really understand that we know about parallel history,
so every time we have a merge the view that the CVS client gets is of
a "merge commit" with a merge summary. And I sweep the merged commits
under the carpet.

(there's some arbitrary nondeterministic magic in how I pick what side
to track and what side to merge. let's not think about that too much.
but I just want git-blame to see a somewhat simplified git-rev-list).

does that help?

cheers,


m