What's cooking in git.git (topics)

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  The topics list the commits in reverse chronological
order.

* jc/apply-config (Tue Feb 20 03:45:49 2007 +0100) 5 commits
 - apply: fix memory leak in prefix_one()
 + git-apply: require -p<n> when working in a subdirectory.
 + git-apply: do not lose cwd when run from a subdirectory.
 + Teach 'git apply' to look at $HOME/.gitconfig even outside of a
   repository
 + Teach 'git apply' to look at $GIT_DIR/config

* lt/crlf (Sat Feb 17 12:37:25 2007 -0800) 4 commits
 + Teach core.autocrlf to 'git apply'
 + t0020: add test for auto-crlf
 + Make AutoCRLF ternary variable.
 + Lazy man's auto-CRLF

The above two series are to help MinGW and people who suffer
from CRLF in general.  I think they are good enough for general
consumption now.  Will perhaps push them out sometime this week.

* js/fetch-progress (Tue Feb 20 03:01:44 2007 +0100) 1 commit
 - fetch & clone: do not output progress when not on a tty
* js/name-rev-fix (Tue Feb 20 01:08:48 2007 +0100) 1 commit
 + name-rev: avoid "^0" when unneeded
* js/grep-pager (Mon Feb 19 15:56:04 2007 +0100) 1 commit
 - git grep: use pager
* js/no-limit-boundary (Mon Feb 19 03:14:59 2007 +0100) 1 commit
 + rev-list --max-age, --max-count: support --boundary
* fk/autoconf (Sun Feb 18 09:44:42 2007 +0100) 1 commit
 + New autoconf test for iconv
* js/etc-config (Wed Feb 14 12:48:14 2007 +0100) 1 commit
 - config: read system-wide defaults from /etc/gitconfig
* mw/64bit (Sat Feb 17 10:13:10 2007 +0100) 1 commit
 - Support for large files on 32bit systems.
* sb/merge (Thu Feb 15 16:39:53 2007 +0100) 1 commit
 - t/t5515-fetch-merge-logic.sh: Added tests for the merge logic in
   git-fetch

These should be Ok.  All should cook in 'next' and graduate to
'master' by end of next week at the latest.

* jc/fetch (Tue Feb 13 01:21:41 2007 +0000) 8 commits
 - Use stdin reflist passing in git-fetch.sh
 - Use stdin reflist passing in parse-remote
 - Allow fetch--tool to read from stdin
 - git-fetch: rewrite expand_ref_wildcard in C
 - git-fetch: rewrite another shell loop in C
 - git-fetch: move more code into C.
 - git-fetch--tool: start rewriting parts of git-fetch in C.
 - git-fetch: split fetch_main into fetch_dumb and fetch_native

Stalled.  If somebody wants to take this over I'll push this out
to 'next'.

* js/diff-2 (Sun Feb 18 12:44:43 2007 +0100) 1 commit
 - Add `git diff2`, a GNU diff workalike

Undecided.  Perhaps will merge to 'next' to see if somebody else
comes up with a better naming idea.

* jc/merge-subtree (Thu Feb 15 16:32:45 2007 -0800) 1 commit
 - A new merge stragety 'subtree'.

Seems to work very well, but I do not see great urgency to merge
this to 'next' yet.

* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
 - test-para: combined diff between HEAD, index and working tree.
 - para-walk: walk n trees, index and working tree in parallel

Stalled.

* js/objhash (Sat Feb 17 18:38:50 2007 +0100) 2 commits
 . Add `struct object_hash` (fixup)
 . Add `struct object_hash`

Stalled.

Re: What's cooking in git.git (topics)

[Eric Wong]

Junio C Hamano <junkio@cox.net> wrote:
> * js/diff-2 (Sun Feb 18 12:44:43 2007 +0100) 1 commit
>  - Add `git diff2`, a GNU diff workalike
> 
> Undecided.  Perhaps will merge to 'next' to see if somebody else
> comes up with a better naming idea.

With this, we can get rid of any test dependency on an external diff
and have a consistent replacement for cmp[1], as well.

`git gdiff`?  `git xdiff`?  `gdiff` would be easier on the fingers
(assuming querty), but `xdiff` is probably a more accurate name.

[1] - <200702172225.12758.johannes.sixt@telecom.at>
-- 
Eric Wong

Re: What's cooking in git.git (topics)

[Junio C Hamano]

Eric Wong <normalperson@yhbt.net> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> * js/diff-2 (Sun Feb 18 12:44:43 2007 +0100) 1 commit
>>  - Add `git diff2`, a GNU diff workalike
>> 
>> Undecided.  Perhaps will merge to 'next' to see if somebody else
>> comes up with a better naming idea.
>
> With this, we can get rid of any test dependency on an external diff
> and have a consistent replacement for cmp[1], as well.
>
> `git gdiff`?  `git xdiff`?  `gdiff` would be easier on the fingers
> (assuming querty), but `xdiff` is probably a more accurate name.

Well, my trouble was that it is anything other than "diff".

An obvious alternative is the same command name (at least
superficially) with an option, such as "diff --fs".  I am not
sure if that is any better than "git {something}diff", though.

Re: What's cooking in git.git (topics)

[Alexander Litvinov]

В сообщении от Tuesday 20 February 2007 13:42 Junio C Hamano написал:
>
> * lt/crlf (Sat Feb 17 12:37:25 2007 -0800) 4 commits
>  + Teach core.autocrlf to 'git apply'
>  + t0020: add test for auto-crlf
>  + Make AutoCRLF ternary variable.
>  + Lazy man's auto-CRLF
>
> The above two series are to help MinGW and people who suffer
> from CRLF in general.  I think they are good enough for general
> consumption now.  Will perhaps push them out sometime this week.

I use the auto crlf convertion as far as Linus made it. Under cygwin it works 
and I have not seen any problems except converting repo from \r\n to \n 
style. Convertion produce a lot of confilcts then merge branches.

All other sides of git I am using works well.

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  The topics list the commits in reverse chronological
order.

* js/bundle (Fri Feb 23 03:17:51 2007 +0100) 5 commits
 + git-bundle: record commit summary in the prerequisite data
 + git-bundle: fix 'create --all'
 + git-bundle: avoid fork() in verify_bundle()
 + git-bundle: assorted fixes
 + Add git-bundle: move objects and references by archive

Johannes muttered something about leak in "create --all" but I
do not think there is any --- they are pointing at memory
location in refs.c:cached_refs.{loose,packed}.  I haven't
checked if the prerequisite logic is done correctly yet -- I
trust that the list can verify it for me before I get around to
it myself.

* js/no-limit-boundary (Mon Feb 19 03:14:59 2007 +0100) 1 commit
 + rev-list --max-age, --max-count: support --boundary

This should graduate to 'master' soon.

* js/etc-config (Thu Feb 15 11:43:56 2007 +0100) 2 commits
 + Make tests independent of global config files
 + config: read system-wide defaults from /etc/gitconfig

I think this is Ok, I do not have a real need for this myself
but it was done in response to a specific user request, so I can
be easily persuaded to make this graduate to 'master' by a
gentle reminder with a success report.

* js/commit-format (Fri Feb 23 01:35:03 2007 +0100) 1 commit
 - pretty-formats: add 'format:<string>'

Cute, but probably can be cleaned up.

* js/diff-ni (Thu Feb 22 21:50:10 2007 +0100) 1 commit
 - Teach git-diff-files the new option `--no-index`

With a minor code restructure I think it got much nicer.

* js/apply (Thu Feb 22 20:11:21 2007 +0100) 1 commit
 + apply: make --verbose a little more useful

Nice touch.  I think this is ready and I'll merge after I have a
chance or two to exercise it myself in real-life.

* jc/status (Thu Feb 22 02:07:56 2007 -0800) 5 commits
 - git-status: use in-core --refresh in a read-only repository.
 - git-runstatus --refresh
 + run_diff_{files,index}(): update calling convention.
 + update-index: do not die too early in a read-only repository.
 + git-status: do not be totally useless in a read-only repository.

The first (meaning bottom in the list) two are true improvement
for obscure corner case, the third is a code cleanup to make
future enhancements (and the later ones in the series) easier.
I have not decided if it is worth to have the remaining two, so
they are left in 'pu'.

* js/fetch-progress (Tue Feb 20 03:01:44 2007 +0100) 1 commit
 + fetch & clone: do not output progress when not on a tty

I'll see it in action from my cron job.

* jc/fetch (Tue Feb 13 01:21:41 2007 +0000) 8 commits
 - Use stdin reflist passing in git-fetch.sh
 - Use stdin reflist passing in parse-remote
 - Allow fetch--tool to read from stdin
 - git-fetch: rewrite expand_ref_wildcard in C
 - git-fetch: rewrite another shell loop in C
 - git-fetch: move more code into C.
 - git-fetch--tool: start rewriting parts of git-fetch in C.
 - git-fetch: split fetch_main into fetch_dumb and fetch_native

Works, does not break anything, very ugly.  Probably needs
reworking if we were to have this in 'next'.

* sb/merge (Thu Feb 15 16:39:53 2007 +0100) 1 commit
 - t/t5515-fetch-merge-logic.sh: Added tests for the merge logic in
   git-fetch

* jc/merge-subtree (Thu Feb 15 16:32:45 2007 -0800) 1 commit
 - A new merge stragety 'subtree'.

I agree with Shawn that its tree-shifting logic should be based
on something similar to tree-diff rename detection before moving
it into 'next'.

* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
 - test-para: combined diff between HEAD, index and working tree.
 - para-walk: walk n trees, index and working tree in parallel

Stalled.

Re: What's cooking in git.git (topics)

[Johannes Schindelin]

Hi,

On Fri, 23 Feb 2007, Junio C Hamano wrote:

> * js/fetch-progress (Tue Feb 20 03:01:44 2007 +0100) 1 commit
>  + fetch & clone: do not output progress when not on a tty
> 
> I'll see it in action from my cron job.

That's how I tried to test it. It does not work. The problem is that the 
remote git-upload-pack is unlikely to understand the option 
"--no-progress".

So maybe we have to make this a new pack protocol option?

Ciao,
Dscho

Re: What's cooking in git.git (topics)

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Fri, 23 Feb 2007, Junio C Hamano wrote:
>
>> * js/fetch-progress (Tue Feb 20 03:01:44 2007 +0100) 1 commit
>>  + fetch & clone: do not output progress when not on a tty
>> 
>> I'll see it in action from my cron job.
>
> That's how I tried to test it. It does not work. The problem is that the 
> remote git-upload-pack is unlikely to understand the option 
> "--no-progress".
>
> So maybe we have to make this a new pack protocol option?

Yes.

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  The topics list the commits in reverse chronological
order.

* js/attach (Sun Mar 4 00:12:06 2007 +0100) 1 commit
 - format-patch: add --inline option and make --attach a true
   attachment

With this, --attach makes a mixed/multipart message with
"content-disposition: attachment"; the previous behaviour to
emit "content-disposition: inline" is available with the new
option --inline.  It is an improvement in the sense that it
makes the option name and behaviour match each other, but it
changes the behaviour, so some people may not like it.  I think
I'll merge to 'next' anyway, if only to see if anybody screams.

* js/symlink (Sat Mar 3 20:38:00 2007 +0100) 3 commits
 + Tell multi-parent diff about core.symlinks.
 + Handle core.symlinks=false case in merge-recursive.
 + Add core.symlinks to mark filesystems that do not support symbolic
   links.

This is to help the MinGW port; I think this topic is ready to
graduate to 'master'.

* js/config-rename (Fri Mar 2 21:53:33 2007 +0100) 1 commit
 + git-config: document --rename-section, provide --remove-section

This would help clean-up after removing branches and remotes.

* js/gnucl (Fri Mar 2 15:29:08 2007 +0100) 2 commits
 - --pretty=gnucl: avoid line wrapping before the comma
 - Add --pretty=gnucl

This is to output logs in the GNU ChangeLog format.

* jc/pathattr (Thu Mar 1 01:20:21 2007 -0800) 5 commits
 - pathattr: allow piping to external program.
 - pathattr: read from git_config().
 - git-show: use pathattr to run "display"
 - pathattr: path based configuration of various attributes.
 + convert: add scaffolding for path based selection of conversion
   routines.

This is a continuation of the CRLF munging topic that is already
in the 'master' branch, but I am expecting to have to redo
almost all of them.  This is left in 'pu' just as a reference.

* js/revert-cherry (Thu Mar 1 05:26:30 2007 +0100) 1 commit
 + Make git-revert & git-cherry-pick a builtin

Will cook for some time.

* jc/fetch (Wed Feb 28 17:02:18 2007 -0800) 14 commits
 + builtin-fetch--tool: fix reflog notes.
 + git-fetch: retire update-local-ref which is not used anymore.
 + builtin-fetch--tool: make sure not to overstep ls-remote-result
   buffer.
 + fetch--tool: fix uninitialized buffer when reading from stdin
 + builtin-fetch--tool: adjust to updated sha1_object_info().
 + git-fetch--tool takes flags before the subcommand.
 + Use stdin reflist passing in git-fetch.sh
 + Use stdin reflist passing in parse-remote
 + Allow fetch--tool to read from stdin
 + git-fetch: rewrite expand_ref_wildcard in C
 + git-fetch: rewrite another shell loop in C
 + git-fetch: move more code into C.
 + git-fetch--tool: start rewriting parts of git-fetch in C.
 + git-fetch: split fetch_main into fetch_dumb and fetch_native

Beginning of built-in git-fetch, primarily to speed up fetching
between repositories with insane number of refs.

* jb/per-user-exclude (Tue Feb 27 22:31:10 2007 -0500) 1 commit
 - add: Support specifying an excludes file with a configuration
   variable

I was hoping that the attribute system would make this
unnecessary (you assign 'ignored' attribute to paths, instead of
spelling them out in the additional .gitignore), but that is a
bit in the future.

* js/diff-ni (Sun Feb 25 23:36:53 2007 +0100) 4 commits
 + Get rid of the dependency to GNU diff in the tests
 + diff --no-index: support /dev/null as filename
 + diff-ni: fix the diff with standard input
 + diff: support reading a file from stdin via "-"

I've fixed up this series since it was posted, and I think it is
in a testable shape now, so it is in 'next'.

* js/fetch-progress (Sun Feb 25 13:13:17 2007 -0800) 3 commits
 . git-fetch: add --quiet
 + Fixup no-progress for fetch & clone
 + fetch & clone: do not output progress when not on a tty

The early parts that have been in 'next' should be ready to go
to 'master' now.  The last one I am not sure.

* jc/status (Thu Feb 22 02:07:56 2007 -0800) 2 commits
 - git-status: use in-core --refresh in a read-only repository.
 - git-runstatus --refresh

These two were done for the specific purpose of helping qgit,
but I haven't heard about them, so they are on hold.  If they
are not needed by qgit nor people who like to run git-status in
a read-only repository, I do not see any reason to keep them.

* jc/merge-subtree (Thu Feb 15 16:32:45 2007 -0800) 1 commit
 - A new merge stragety 'subtree'.

This is still my useful toy at this stage.  I agree with Shawn
that subtree identification needs to be improved.

* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
 - test-para: combined diff between HEAD, index and working tree.
 - para-walk: walk n trees, index and working tree in parallel

This is just a reference, waiting for a day somebody has enough
energy to rewrite diff family with a unified tree walker.

Re: What's cooking in git.git (topics)

[Johannes Schindelin]

Hi,

On Sun, 4 Mar 2007, Junio C Hamano wrote:

> * js/attach (Sun Mar 4 00:12:06 2007 +0100) 1 commit
>
> [...]
>
> * js/symlink (Sat Mar 3 20:38:00 2007 +0100) 3 commits

The prefix system is showing its limitation... :-)

> * js/gnucl (Fri Mar 2 15:29:08 2007 +0100) 2 commits
>  - --pretty=gnucl: avoid line wrapping before the comma
>  - Add --pretty=gnucl
> 
> This is to output logs in the GNU ChangeLog format.

FWIW I am opposed to include that. After letting it sink in, Linus' 
remarks convinced me that this format is not as useful as our other log 
formats, and for those people who really want it, there is git2cl.

> * js/revert-cherry (Thu Mar 1 05:26:30 2007 +0100) 1 commit
>  + Make git-revert & git-cherry-pick a builtin
> 
> Will cook for some time.

Yes. I worked with them a bit, but nowhere enough to say that they are 
not introducing regressions.

> * js/diff-ni (Sun Feb 25 23:36:53 2007 +0100) 4 commits
>  + Get rid of the dependency to GNU diff in the tests
>  + diff --no-index: support /dev/null as filename
>  + diff-ni: fix the diff with standard input
>  + diff: support reading a file from stdin via "-"
> 
> I've fixed up this series since it was posted, and I think it is
> in a testable shape now, so it is in 'next'.

Thank you.

> * js/fetch-progress (Sun Feb 25 13:13:17 2007 -0800) 3 commits
>  . git-fetch: add --quiet
>  + Fixup no-progress for fetch & clone
>  + fetch & clone: do not output progress when not on a tty
> 
> The early parts that have been in 'next' should be ready to go to 
> 'master' now.  The last one I am not sure.

BTW I just added this to my fetches in crontab: ' | sed -e "s/^.*\r//g"' 
This is the workaround Nico proposed, only a little bit more obvious (and 
removable).

Ciao,
Dscho

Re: What's cooking in git.git (topics)

[Linus Torvalds]

On Sun, 4 Mar 2007, Johannes Schindelin wrote:
> > 
> > This is to output logs in the GNU ChangeLog format.
> 
> FWIW I am opposed to include that. After letting it sink in, Linus' 
> remarks convinced me that this format is not as useful as our other log 
> formats, and for those people who really want it, there is git2cl.

Side note: I would hate to be the person who torpedoes anything that some 
people actually find useful (my motto: "actually useful is a lot better 
than clean, but not as useful")

So in that sense, if people actually find GNU changelog format to be 
useful enough that they want a script for it, I don't think we should 
relegate it to second-class citizenship just because _we_ don't think it's 
a wonderful format.

The GNU code formatting guidelines are much much worse than the GNU 
changelogs, yet we certainly allow people to check in their braindamage 
into git if they want to. The GNU changelog format isn't horrid, and the 
function names can be even nice as a way of seeing "what does this touch".

The fact that GNU changelog is then mis-designed to do per-file changelogs 
etc is more an effect of CVS misfeatures than anything else. But compared 
to all the other things CVS gets wrong, that's a very small detail ;)

		Linus

Re: What's cooking in git.git (topics)

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sun, 4 Mar 2007, Johannes Schindelin wrote:
>> > 
>> > This is to output logs in the GNU ChangeLog format.
>> 
>> FWIW I am opposed to include that. After letting it sink in, Linus' 
>> remarks convinced me that this format is not as useful as our other log 
>> formats, and for those people who really want it, there is git2cl.
>
> Side note: I would hate to be the person who torpedoes anything that some 
> people actually find useful (my motto: "actually useful is a lot better 
> than clean, but not as useful")
>
> So in that sense, if people actually find GNU changelog format to be 
> useful enough that they want a script for it, I don't think we should 
> relegate it to second-class citizenship just because _we_ don't think it's 
> a wonderful format.

Oh, I certainly would not disagree.

But I do not think encouraging people to script is necessarily
relegating it to second-class citizenship, as it appears there
are rooms for project and language specific heuristics to come
in for summarizing the real log into a variant of GNU changelog
that is most useful for a particular project, I think it makes
sense to implement it as a postprocessing filter to git-log -p
(even "git-log -p -U999", if somebody want to do a language
specific function labels), just like Simon did with his git2cl
to output a particular variant (i.e. the one that lacks the
function names) of GNU changelog to suit his projects' needs.

Given time, Simon's script may be improved and prove to be
flexible enough to accomodate the needs of all (or almost all)
other projects that want to use GNU changelog format.  At that
point, we might even want to include it in contrib/ of git.git,
if enough people are interested in it and if distributing with
the core helps the script gain wider exposure.

> The fact that GNU changelog is then mis-designed to do per-file changelogs 
> etc is more an effect of CVS misfeatures than anything else. But compared 
> to all the other things CVS gets wrong, that's a very small detail ;)

That part I 100% agree ;-).

Re: What's cooking in git.git (topics)

[Marco Costalba]

On 3/4/07, Junio C Hamano <junkio@cox.net> wrote:
>
> * jc/status (Thu Feb 22 02:07:56 2007 -0800) 2 commits
>  - git-status: use in-core --refresh in a read-only repository.
>  - git-runstatus --refresh
>
> These two were done for the specific purpose of helping qgit,
> but I haven't heard about them, so they are on hold.  If they
> are not needed by qgit nor people who like to run git-status in
> a read-only repository, I do not see any reason to keep them.
>

Currently they are not needed by qgit. Probably neither in the future.
It is better to keep working dir view disabled if in a read-only repo
then wait for a sloooow command to return incorrect data (BTW _all_
repo files are always marked as 'modified' due to an issue with
different implementations of lstat in cygwin and ntfs kernel driver).

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  The topics list the commits in reverse chronological
order.


* sp/run-command (Mon Mar 12 19:00:29 2007 -0400) 9 commits
 + Use run_command within send-pack
 + Use run_command within receive-pack to invoke index-pack
 + Use run_command within merge-index
 + Use run_command for proxy connections
 + Use RUN_GIT_CMD to run push backends
 + Correct new compiler warnings in builtin-revert
 + Replace fork_with_pipe in bundle with run_command
 + Teach run-command to redirect stdout to /dev/null
 + Teach run-command about stdout redirection

This is really internal clean-up without behaviour change (but I
suspect the error messages from failure cases might be
different).  Good to flush these to 'master' before 1.5.1-rc1.

* dz/mailinfo (Mon Mar 12 15:52:07 2007 -0400) 3 commits
 + Add a couple more test cases to the suite.
 + restrict the patch filtering
 + builtin-mailinfo.c infrastrcture changes

The mailinfo implementation in 'master' I punted to do
complicated multi-part and Don Zickus rewrote much of the hacky
parts.  The less hacky code of mine remains in the tree, the
happier I am.  Should be in 'master' before 1.5.1-rc1.

* jc/repack (Fri Mar 9 03:52:12 2007 -0800) 1 commit
 + prepare_packed_git(): sort packs by age and localness.

This is to improve the access pattern when repository has many
small packfiles, as recent push/fetch tend to keep packs
unexploded.  The idea is to check younger packs and local packs
before others when we iterate over .idx files to look for packed
objects from find_pack_entry().  I've repacked linux-2.6 kernel
repository so that it has one pack per one public tag (which is
a bit excessive -- it results in 70 or so small packs), and saw
"git log -r --raw v2.6.20.." got some speed-up in hot cache case
(4.4 seconds vs 5.3 seconds on average).

* jc/fetch (Sun Mar 4 15:36:08 2007 -0800) 15 commits
 + .gitignore: add git-fetch--tool
 + builtin-fetch--tool: fix reflog notes.
 + git-fetch: retire update-local-ref which is not used anymore.
 + builtin-fetch--tool: make sure not to overstep ls-remote-result
   buffer.
 + fetch--tool: fix uninitialized buffer when reading from stdin
 + builtin-fetch--tool: adjust to updated sha1_object_info().
 + git-fetch--tool takes flags before the subcommand.
 + Use stdin reflist passing in git-fetch.sh
 + Use stdin reflist passing in parse-remote
 + Allow fetch--tool to read from stdin
 + git-fetch: rewrite expand_ref_wildcard in C
 + git-fetch: rewrite another shell loop in C
 + git-fetch: move more code into C.
 + git-fetch--tool: start rewriting parts of git-fetch in C.
 + git-fetch: split fetch_main into fetch_dumb and fetch_native

This is a partial C rewrite of heaviest part of git-fetch to
help fetching between repositories with hundreds of refs.  I do
not like the way it is split, but it may be a good idea to throw
it in 'master' as it does not seem to regress anything and see
if there are other interested people who want to finish the
rewriting.

* pb/branch-track (Thu Mar 8 13:59:54 2007 -0800) 2 commits
 + Fix broken create_branch() in builtin-branch.
 + git-branch, git-checkout: autosetup for remote branch tracking

As I personally do not use "git branch --track", all I can say
is that this, with the fix-up patch already in, does not seem to
regress anything.  Positive feedbacks requested before advancing
to 'master'.

* jb/per-user-exclude (Tue Feb 27 22:31:10 2007 -0500) 1 commit
 + add: Support specifying an excludes file with a configuration
   variable

Same as above.

* ml/workdir (Sun Mar 11 22:29:06 2007 +0100) 3 commits
 - use $GIT_DIR/workdir as working directory with $GIT_DIR
 - introduce GIT_WORK_DIR environment variable
 - rev-parse: --is-bare-repository option

Not in 'next' yet, but I think this one is ready to be tested.
We need testsuite for it before that happens, though.

* js/fetch-progress (Sun Feb 25 13:13:17 2007 -0800) 1 commit
 + git-fetch: add --quiet

This does not break anything, but I am not sure how useful it
would be.

* sb/fetch (Mon Mar 12 19:01:11 2007 -0700) 19 commits
 + git-fetch.sh:append_fetch_head() no longer has a remote_nick
   argument
 + git-fetch: Split fetch and merge logic

I have a soft spot to anything that claims to be a clean-up, but
I suspect that the shell loop this series introduces may defeat
the git-fetch--tool optimization.  Also I think having to base
the patch on this made Paolo's "dot is special token to mean
'git pull' merges from a local branch" needlessly complex (but I
haven't tried rewriting it myself without these two).  Although
I merged these to 'next', I am considering to revert them.

* jc/pathattr (Thu Mar 1 01:20:21 2007 -0800) 5 commits
 - pathattr: allow piping to external program.
 - pathattr: read from git_config().
 - git-show: use pathattr to run "display"
 - pathattr: path based configuration of various attributes.
 + convert: add scaffolding for path based selection of conversion
   routines.

Stalled.

* jc/merge-subtree (Thu Feb 15 16:32:45 2007 -0800) 1 commit
 - A new merge stragety 'subtree'.

Stalled.

* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
 - test-para: combined diff between HEAD, index and working tree.
 - para-walk: walk n trees, index and working tree in parallel

Just a reference code.

Re: What's cooking in git.git (topics)

[Matthias Lederhofer]

Junio C Hamano <junkio@cox.net> wrote:
> * ml/workdir (Sun Mar 11 22:29:06 2007 +0100) 3 commits
>  - use $GIT_DIR/workdir as working directory with $GIT_DIR
>  - introduce GIT_WORK_DIR environment variable
>  - rev-parse: --is-bare-repository option
> 
> Not in 'next' yet, but I think this one is ready to be tested.
> We need testsuite for it before that happens, though.

Will you apply the git-init patch too?

I did not write any tests yet, but I can try.

Here is what I thought about:

check that --work-dir overrides $GIT_WORK_DIR and both override
$GIT_DIR/workdir.

use a correct and an invalid path for:
    $GIT_DIR/workdir:
        file containing a relative and an absolute path
        symlink pointing to an invalid path, a directory, a file
        test a symlink to something else (e.g. device, fifo, ..) too?
        directory
    $GIT_WORK_DIR: relative and absolute path
    and test what git does with git-rev-parse
            --is-bare-repository
            --show-prefix
            --show-cdup

test git rev-parse --is-inside-git-dir

A symlink pointing to an invalid path is currently handled as if there
is no $GIT_DIR/workdir at all because stat returns ENOENT.  Is this ok
or should git complain like it does for an invalid path when
$GIT_DIR/workdir is a file?  We could also decide to ignore all
invalid workdir settings and handle this the same as being outside the
workdir.

Re: What's cooking in git.git (topics)

[Junio C Hamano]

Matthias Lederhofer <matled@gmx.net> writes:

> Here is what I thought about:
>
> check that --work-dir overrides $GIT_WORK_DIR and both override
> $GIT_DIR/workdir.
>
> use a correct and an invalid path for:
>     $GIT_DIR/workdir:
>         file containing a relative and an absolute path
>         symlink pointing to an invalid path, a directory, a file
>         test a symlink to something else (e.g. device, fifo, ..) too?
>         directory
>     $GIT_WORK_DIR: relative and absolute path
>     and test what git does with git-rev-parse
>             --is-bare-repository
>             --show-prefix
>             --show-cdup
>
> test git rev-parse --is-inside-git-dir

... and do the rev-parse test with *and* *without* $GIT_WORK_DIR
or $GIT_DIR/workdir to make sure there won't be any regressions.

> A symlink pointing to an invalid path is currently handled as if there
> is no $GIT_DIR/workdir at all because stat returns ENOENT.  Is this ok
> or should git complain like it does for an invalid path when
> $GIT_DIR/workdir is a file?  We could also decide to ignore all
> invalid workdir settings and handle this the same as being outside the
> workdir.

Silently ignoring would leave the user who misconfigured it by
mistake.

By the way, why should it be $GIT_DIR/workdir when it appears
everybody is putting things in $GIT_DIR/config?  Shouldn't it be
something like:

	[core]
        	worktree = "/path/to/the/working/tree"

And more importantly, why nobody mentioned the above so far?
Maybe it is a sign that nobody is interested in this new
feature?

Re: What's cooking in git.git (topics)

[Matthias Lederhofer]

Junio C Hamano <junkio@cox.net> wrote:
> By the way, why should it be $GIT_DIR/workdir when it appears
> everybody is putting things in $GIT_DIR/config?  Shouldn't it be
> something like:
> 
> 	[core]
>         	worktree = "/path/to/the/working/tree"

That's right.  When I wrote the code I first had only support for a
directory in $GIT_DIR/workdir (using a symlink) and added a file after
that.  Using a symlink is still easily possible with core.worktree =
workdir.

Re: What's cooking in git.git (topics)

[Julian Phillips]

On Tue, 13 Mar 2007, Junio C Hamano wrote:

> * jc/fetch (Sun Mar 4 15:36:08 2007 -0800) 15 commits
> + .gitignore: add git-fetch--tool
> + builtin-fetch--tool: fix reflog notes.
> + git-fetch: retire update-local-ref which is not used anymore.
> + builtin-fetch--tool: make sure not to overstep ls-remote-result
>   buffer.
> + fetch--tool: fix uninitialized buffer when reading from stdin
> + builtin-fetch--tool: adjust to updated sha1_object_info().
> + git-fetch--tool takes flags before the subcommand.
> + Use stdin reflist passing in git-fetch.sh
> + Use stdin reflist passing in parse-remote
> + Allow fetch--tool to read from stdin
> + git-fetch: rewrite expand_ref_wildcard in C
> + git-fetch: rewrite another shell loop in C
> + git-fetch: move more code into C.
> + git-fetch--tool: start rewriting parts of git-fetch in C.
> + git-fetch: split fetch_main into fetch_dumb and fetch_native
>
> This is a partial C rewrite of heaviest part of git-fetch to
> help fetching between repositories with hundreds of refs.  I do
> not like the way it is split, but it may be a good idea to throw
> it in 'master' as it does not seem to regress anything and see
> if there are other interested people who want to finish the
> rewriting.

As it happens I was planning to start looking at writing a builtin fetch 
when I got home this evening ... the fetch--tool improvements have whetted 
my appetite for speed ... ;)

> * sb/fetch (Mon Mar 12 19:01:11 2007 -0700) 19 commits
> + git-fetch.sh:append_fetch_head() no longer has a remote_nick
>   argument
> + git-fetch: Split fetch and merge logic
>
> I have a soft spot to anything that claims to be a clean-up, but
> I suspect that the shell loop this series introduces may defeat
> the git-fetch--tool optimization.  Also I think having to base
> the patch on this made Paolo's "dot is special token to mean
> 'git pull' merges from a local branch" needlessly complex (but I
> haven't tried rewriting it myself without these two).  Although
> I merged these to 'next', I am considering to revert them.

I found that this series did introduce a regression, but not a serious 
one.  A null fetch went from ~30s to ~40s IIRC.  I moved 
canon_refs_list_for_fetch from git-parse-remote.sh to git-fetch--tool in 
response, and was pretty much able to get back to where I was before - I 
can send the patch if you want, I didn't think it that important.

-- 
Julian

  ---
The new Congressmen say they're going to turn the government around.  I
hope I don't get run over again.

Re: What's cooking in git.git (topics)

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Here are the topics that have been cooking.

> * sb/fetch (Mon Mar 12 19:01:11 2007 -0700) 19 commits
>  + git-fetch.sh:append_fetch_head() no longer has a remote_nick
>    argument
>  + git-fetch: Split fetch and merge logic
>
> I have a soft spot to anything that claims to be a clean-up, but
> I suspect that the shell loop this series introduces may defeat
> the git-fetch--tool optimization.  Also I think having to base
> the patch on this made Paolo's "dot is special token to mean
> 'git pull' merges from a local branch" needlessly complex (but I
> haven't tried rewriting it myself without these two).  Although
> I merged these to 'next', I am considering to revert them.

I tried the "NULL fetch between 1000-refs repositories" test,
which prompted the git-fetch--tool work that was done on
jc/fetch topic in 'next', with the following versions:

 (1) 1.5.0 (without any git-fetch--tool optimization)
 (2) master (ditto)
 (3) master with jc/fetch (but not sb/fetch topic)
 (4) next ((3) plus sb/fetch and others)

The test scripts are at the end of this message.  Both (1) and
(2) take 3 minutes 7 seconds wallclock time.  (3) improves it
down to 15 seconds.  (4) makes the operation spend 24 seconds
(the times are all on my primary machine x86-64 with 1GB, hot
cache and average of three runs each).

So the "Split fetch and merge" series hurts the performance
quite a bit.  If it had enough "code clean-up" merit to warrant
this, I would say it probably is a cost we should bear, but I
personally do not see it.

Paolo recently worked on top of next to base the fake '.' remote
patch.  This wants to allow:

	[branch "foo"]
        	remote = .
                merge = refs/heads/master

with an implicit (meaning, you do not have to have this in your
configuration):

	[remote "."]
        	url = .
                fetch = refs/*

so that you can say:

	$ git checkout foo
        $ git pull

to merge from the local 'master' branch.

I haven't reimplemented Paolo's patch on top of (3) above for
comparison, but I have a feeling that it would not have been
helped by the alleged clean-up value of "Split fetch and merge"
patch (iow, I do not think it would be the case that the code
got clearer to understand thanks to the clean-up).

What Paolo's patch needs to do is to bypass the actual fetch and
generate the following line in .git/FETCH_HEAD:

	sha1-of-our-master <TAB> <TAB> branch 'master' of .

I even suspect that "Split fetch and merge", by introducing
FETCH_FETCHED and making FETCH_HEAD generated from it, made
Paolo's patch more difficult to do and the end result less
efficient.

So unless there is a convincing counterexample otherwise, I'd
like to revert the "Split fetch and merge" series.


-- >8 -- setting up test repositories -- >8 --
#!/bin/sh

rm -fr origin clone

mkdir origin
cd origin
git init
: >hello
git add hello
git commit -a -m 'initial'
i=0
while test $i -lt 500
do
	git tag t$i
	git branch b$i
	i=$(($i+1))
done

: >bye
git add bye
git commit -a -m 'second'
while test $i -lt 1000
do
	git tag t$i
	git branch b$i
	i=$(($i+1))
done

cd ..
-- >8 -- NULL fetch test -- >8 --
#!/bin/sh

cd clone
echo '* fetching'
time git fetch origin

Re: What's cooking in git.git (topics)

[Santi Béjar]

On 3/13/07, Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Here are the topics that have been cooking.
>
> > * sb/fetch (Mon Mar 12 19:01:11 2007 -0700) 19 commits
> >  + git-fetch.sh:append_fetch_head() no longer has a remote_nick
> >    argument
> >  + git-fetch: Split fetch and merge logic
> >
> > I have a soft spot to anything that claims to be a clean-up, but
> > I suspect that the shell loop this series introduces may defeat
> > the git-fetch--tool optimization.  Also I think having to base
> > the patch on this made Paolo's "dot is special token to mean
> > 'git pull' merges from a local branch" needlessly complex (but I
> > haven't tried rewriting it myself without these two).  Although
> > I merged these to 'next', I am considering to revert them.
>
> I tried the "NULL fetch between 1000-refs repositories" test,
> which prompted the git-fetch--tool work that was done on
> jc/fetch topic in 'next', with the following versions:
>
>  (1) 1.5.0 (without any git-fetch--tool optimization)
>  (2) master (ditto)
>  (3) master with jc/fetch (but not sb/fetch topic)
>  (4) next ((3) plus sb/fetch and others)
>
> The test scripts are at the end of this message.  Both (1) and
> (2) take 3 minutes 7 seconds wallclock time.  (3) improves it
> down to 15 seconds.  (4) makes the operation spend 24 seconds
> (the times are all on my primary machine x86-64 with 1GB, hot
> cache and average of three runs each).

I think it is not fair, I wonder what would be the time with the merge
logic in sb/fetch in C. I'll try to make the git-fetch--tool
optimization.

>
> So the "Split fetch and merge" series hurts the performance
> quite a bit.  If it had enough "code clean-up" merit to warrant
> this, I would say it probably is a cost we should bear, but I
> personally do not see it.
>
> Paolo recently worked on top of next to base the fake '.' remote
> patch.  This wants to allow:
>
>         [branch "foo"]
>                 remote = .
>                 merge = refs/heads/master
>
> with an implicit (meaning, you do not have to have this in your
> configuration):
>
>         [remote "."]
>                 url = .
>                 fetch = refs/*
>
> so that you can say:
>
>         $ git checkout foo
>         $ git pull
>
> to merge from the local 'master' branch.
>
> I haven't reimplemented Paolo's patch on top of (3) above for
> comparison, but I have a feeling that it would not have been
> helped by the alleged clean-up value of "Split fetch and merge"
> patch (iow, I do not think it would be the case that the code
> got clearer to understand thanks to the clean-up).
>
> What Paolo's patch needs to do is to bypass the actual fetch and
> generate the following line in .git/FETCH_HEAD:
>
>         sha1-of-our-master <TAB> <TAB> branch 'master' of .
>
> I even suspect that "Split fetch and merge", by introducing
> FETCH_FETCHED and making FETCH_HEAD generated from it, made
> Paolo's patch more difficult to do and the end result less
> efficient.

I think my patch to support this is independent of the "Split fetch and merge".

>
> So unless there is a convincing counterexample otherwise, I'd
> like to revert the "Split fetch and merge" series.

Santi

Re: What's cooking in git.git (topics)

[Junio C Hamano]

"Santi Béjar" <sbejar@gmail.com> writes:

>> I tried the "NULL fetch between 1000-refs repositories" test,
>> which prompted the git-fetch--tool work that was done on
>> jc/fetch topic in 'next', with the following versions:
>>
>>  (1) 1.5.0 (without any git-fetch--tool optimization)
>>  (2) master (ditto)
>>  (3) master with jc/fetch (but not sb/fetch topic)
>>  (4) next ((3) plus sb/fetch and others)
>>
>> The test scripts are at the end of this message.  Both (1) and
>> (2) take 3 minutes 7 seconds wallclock time.  (3) improves it
>> down to 15 seconds.  (4) makes the operation spend 24 seconds
>> (the times are all on my primary machine x86-64 with 1GB, hot
>> cache and average of three runs each).
>
> I think it is not fair,...

That's a very unexpected response.  I personally do not think
the separation of FETCH_FETCHED made improvements to the code,
but the above numbers do not have anything to do with such
perhaps subjective ascetic judgement.

The comparison showed that the "Split" patch is a step backward
from the existing optimization hack that was specifically made
to solve an issue raised on the list, and you may not like the
numbers, but if you call that is "not fair", I do not know what
could be considered fair.

Yes, life is unfair, but I do not think that word applies to
this particular case.

Re: What's cooking in git.git (topics)

[Santi Béjar]

On 3/14/07, Junio C Hamano <junkio@cox.net> wrote:
> "Santi Béjar" <sbejar@gmail.com> writes:
>
> >> I tried the "NULL fetch between 1000-refs repositories" test,
> >> which prompted the git-fetch--tool work that was done on
> >> jc/fetch topic in 'next', with the following versions:
> >>
> >>  (1) 1.5.0 (without any git-fetch--tool optimization)
> >>  (2) master (ditto)
> >>  (3) master with jc/fetch (but not sb/fetch topic)
> >>  (4) next ((3) plus sb/fetch and others)
> >>
> >> The test scripts are at the end of this message.  Both (1) and
> >> (2) take 3 minutes 7 seconds wallclock time.  (3) improves it
> >> down to 15 seconds.  (4) makes the operation spend 24 seconds
> >> (the times are all on my primary machine x86-64 with 1GB, hot
> >> cache and average of three runs each).
> >
> > I think it is not fair,...

[...]

>, and you may not like the
> numbers, but if you call that is "not fair", I do not know what
> could be considered fair.

I would consider fair the comparison you did not quote, a comparison
with the merge logic written in C. I know that (4) is a step backwards
in performance as it is now, and I understand that with those numbers
the "Split" patch must be reverted.

Santi

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  The topics list the commits in reverse chronological
order.

* jc/bisect (Fri Mar 23 17:54:03 2007 -0700) 6 commits
 + make the previous optimization work also on path-limited rev-list
   --bisect
 + rev-list --bisect: Fix "halfway" optimization.
 + t6004: add a bit more path optimization test.
 + git-rev-list --bisect: optimization
 + git-rev-list: add --bisect-vars option.
 + t6002: minor spelling fix.

This improves "rev-list --bisect" performance, sometimes
significantly, especially in a repository with long lines of
single-parent commits.  This is only about performance, and as
we are already in -rc1, the topic will have to wait 1.5.1.

* fl/cvsserver (Mon Mar 19 16:56:01 2007 +0100) 5 commits
 + cvsserver: Abort if connect to database fails
 + cvsserver: Make the database backend configurable
 + cvsserver: Allow to override the configuration per access method
 + cvsserver: Handle three part keys in git config correctly
 + cvsserver: Introduce new state variable 'method'

This is a beginning of supporting use of different database
backends, other than sqlite, with git-cvsserver.  Will not be in
'master' until 1.5.1 is done.

* js/remote-show-push (Sun Mar 18 21:34:46 2007 +0100) 1 commit
 + Teach git-remote to list pushed branches.

This is a new feature but of very little risk of breaking
anything, so I'll merge it to 'master'.

* ml/workdir (Sat Mar 17 02:58:55 2007 +0100) 6 commits
 . git-init: set core.workdir when GIT_WORK_DIR is specified
 . test GIT_WORK_DIR
 . test git-rev-parse
 . core.workdir config variable
 . introduce GIT_WORK_DIR environment variable
 . rev-parse: --is-bare-repository option

Waiting for a resend without "oops", "ah this is better"
iterations, but in no hurry, as it won't be in 'master' until
1.5.1 is done.

* jc/fpl (Tue Mar 13 01:57:22 2007 -0700) 1 commit
 + git-log --first-parent: show only the first parent log

This makes viewing topic-heavy style of project history
pleasant, at least in my opinion.  With a bit of cheering up,
I'd merge it to 'master', as it has been cooking in 'next'
without causing problems, and is of low-impact kind.  But it can
wait until 1.5.1 is done.

* jc/read-tree-df (Thu Mar 15 23:25:22 2007 -0700) 1 commit
 . Fix switching to a branch with D/F when current branch has file D.

This is unfortunately way premature as it seems to expose other
breakages this too-strict safety measure prevents from
happening.  We need to rethink the whole unpack_trees() business
after 1.5.1.

* jc/pathattr (Thu Mar 1 01:20:21 2007 -0800) 5 commits
 . pathattr: allow piping to external program.
 . pathattr: read from git_config().
 . git-show: use pathattr to run "display"
 . pathattr: path based configuration of various attributes.
 + convert: add scaffolding for path based selection of conversion
   routines.

Stalled.  gitattributes support should be one of the focus in
the 1.5.2 cycle.

* jc/merge-subtree (Thu Feb 15 16:32:45 2007 -0800) 1 commit
 - A new merge stragety 'subtree'.
* js/fetch-progress (Sun Feb 25 13:13:17 2007 -0800) 1 commit
 + git-fetch: add --quiet
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
 . test-para: combined diff between HEAD, index and working tree.
 . para-walk: walk n trees, index and working tree in parallel

The above are stalled.

Re: What's cooking in git.git (topics)

[Johannes Schindelin]

Hi,

On Sun, 25 Mar 2007, Junio C Hamano wrote:

> * jc/fpl (Tue Mar 13 01:57:22 2007 -0700) 1 commit
>  + git-log --first-parent: show only the first parent log
> 
> This makes viewing topic-heavy style of project history pleasant, at 
> least in my opinion.  With a bit of cheering up, I'd merge it to 
> 'master', as it has been cooking in 'next' without causing problems, and 
> is of low-impact kind.  But it can wait until 1.5.1 is done.

*lol* I just tried it on 'next'...

But I agree that it is ready to be merged, and that it is useful.

Ciao,
Dscho

Re: What's cooking in git.git (topics)

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Sun, 25 Mar 2007, Junio C Hamano wrote:
>
>> * jc/fpl (Tue Mar 13 01:57:22 2007 -0700) 1 commit
>>  + git-log --first-parent: show only the first parent log
>> 
>> This makes viewing topic-heavy style of project history pleasant, at 
>> least in my opinion.  With a bit of cheering up, I'd merge it to 
>> 'master', as it has been cooking in 'next' without causing problems, and 
>> is of low-impact kind.  But it can wait until 1.5.1 is done.
>
> *lol* I just tried it on 'next'...
>
> But I agree that it is ready to be merged, and that it is useful.

Hmph.  I am having hard time to decide what to make out of that
"*lol*".  That branch is exactly where this is useful, as it is
a pure integration branch that never gets its own commits (there
is one exception "Revert" that is directly on it, but that is an
exception. And making an exception stand out is also a good
thing). I do not see there is anything to laugh out loudly
about.

On the other hand, running "git log -F master" gives a mixed
picture, as non-merge commits on 'master' are supposed to be
obvious patches that do not need cooking period in 'next', but
without the "pee in the snow merges for fast-forwarding case" we
do not use, commits on a topic that was born and cooked fully
while 'master' was quiescent would also appear on the output,
making it a less useful to tell which ones are "obviously
correct" ones and which ones were cooked in their own topics.

Re: What's cooking in git.git (topics)

[Johannes Schindelin]

Hi,

On Sun, 25 Mar 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Sun, 25 Mar 2007, Junio C Hamano wrote:
> >
> >> * jc/fpl (Tue Mar 13 01:57:22 2007 -0700) 1 commit
> >>  + git-log --first-parent: show only the first parent log
> >> 
> >> This makes viewing topic-heavy style of project history pleasant, at 
> >> least in my opinion.  With a bit of cheering up, I'd merge it to 
> >> 'master', as it has been cooking in 'next' without causing problems, and 
> >> is of low-impact kind.  But it can wait until 1.5.1 is done.
> >
> > *lol* I just tried it on 'next'...
> >
> > But I agree that it is ready to be merged, and that it is useful.
> 
> Hmph.  I am having hard time to decide what to make out of that "*lol*".

I was not sure what to expect, and thus was surprised by _that_ many 
diagonal lines...

But this picture -- unexpected as it was -- makes tons of sense if you are 
interested to see e.g. the history of a topic branch which was merged into 
'next'.

So, I'm all in favour of this feature.

Ciao,
Dscho

Re: What's cooking in git.git (topics)

[Florian Weimer]

* Junio C. Hamano:

> * jc/fpl (Tue Mar 13 01:57:22 2007 -0700) 1 commit
>  + git-log --first-parent: show only the first parent log

I think it's still missing documentation.

Re: What's cooking in git.git (topics)

[Junio C Hamano]

Florian Weimer <fw@deneb.enyo.de> writes:

> * Junio C. Hamano:
>
>> * jc/fpl (Tue Mar 13 01:57:22 2007 -0700) 1 commit
>>  + git-log --first-parent: show only the first parent log
>
> I think it's still missing documentation.

Patches welcome.

[PATCH] Document git-log --first-parent

[Junio C Hamano]

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 Documentation/git-log.txt |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 361eaec..030edaf 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -38,6 +38,11 @@ include::pretty-formats.txt[]
 	and <until>, see "SPECIFYING REVISIONS" section in
 	gitlink:git-rev-parse[1].
 
+--first-parent::
+	Follow only the first parent commit upon seeing a merge
+	commit.  This  option gives a better overview of the
+	evolution of a particular branch.
+
 -p::
 	Show the change the commit introduces in a patch form.
 
-- 
1.5.1.rc2.618.g98453b