git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* What's cooking in git.git (topics)
@ 2007-09-06  8:52 Junio C Hamano
       [not found] ` <7v1wd1d0le.fsf@gitster.siamese.dyndns.org>
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2007-09-06  8:52 UTC (permalink / raw)
  To: git

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/tag (Mon Sep 3 17:51:43 2007 +0100) 1 commit
 + verify-tag: also grok CR/LFs in the tag signature

Looks correct.  Merge to 'master' this weekend.

* lh/svn-first-parent (Wed Sep 5 11:35:29 2007 +0200) 1 commit
 + git-svn: add support for --first-parent

Queued to 'next' with Eric's blessing.  Perhaps merge to
'master' by the end of next week unless there are issues.

* rs/archive (Mon Sep 3 20:08:01 2007 +0200) 3 commits
 + Remove unused function convert_sha1_file()
 + archive: specfile support (--pretty=format: in archive files)
 + Export format_commit_message()

Waiting for the "$Format: ...$" updates.

* js/remote (Sun Sep 2 21:10:14 2007 +0100) 1 commit
 + Teach "git remote" a mirror mode

Waiting for tests.  We should resurrect earlier "git remote rm"
and add tests for it as well.

* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
 - rebase: allow starting from a dirty tree.
 - stash: implement "stash create"

A quick hack to allow starting "git rebase" in a dirty work tree
by automatically stashing the changes first, and unstashing them
after rebase is done.  Needs tests and documentation.

* np/delta (Thu Sep 6 02:13:11 2007 -0400) 4 commits
 - basic threaded delta search
 - rearrange delta search progress reporting
 - localize window memory usage accounting
 - straighten the list of objects to deltify

I do not know where Nico's "threaded pack generation" would lead
us to yet, so they are parked on 'pu' for now.  The first in the
series should be applicable to 'next', though.

* jc/pack (Sat Sep 1 23:53:47 2007 -0700) 1 commit
 + Keep last used delta base in the delta window

Would need to straighten out the implementation from the one
that is suited for the original FIFO usage to another that is
more appropriate for LRU.

* jc/autogc (Wed Sep 5 14:59:59 2007 -0700) 2 commits
 - Invoke "git gc --auto" from commit, merge, am and rebase.
 - Implement git gc --auto

This has been updated since the ones I sent to the list earlier
in the day.  It detects a situation where the user has too much
cruft in the repository that too many loose objects are left
unpruned, and issues a warning.  Also 'rebase' is covered by
running "git gc --auto" from either merge or am.

* ph/strbuf (Wed Sep 5 21:18:43 2007 +0200) 7 commits
 - Use strbuf in cache-tree.c
 - Use strbuf in buitin-rerere.c
 - Use strbuf in apply, blame, commit-tree and diff
 - mktree: Simplify write_tree() using strbuf's.
 - fast-import: Use strbuf API, and simplify cmd_data()
 - Simplify strbuf uses in archive-tar.c using strbuf API
 - Rework strbuf API and semantics.

The idea is good, and removes more code than it adds, but I find
it not 'next' material yet.  I haven't checked every single line
yet, and this series needs that kind of vetting.

* jc/pathspec (Tue Sep 4 02:47:25 2007 -0700) 1 commit
 - tree-diff.c: split out a function to match a single pattern.

Just started and not even started to cause breakage yet ;-).
I'd want to fix pathspec semantics of "diff-tree", "log" and
"ls-tree" so that they understand globs in addition to leading
directory prefix, just like "ls-files", "diff-files",
"diff-index" and "grep" does.

* 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

Have been on hold for a long time.  This is about traversing the
index, work tree and zero or more trees in parallel, which is
one way to rewrite the merge backend.  I may end up reusing
merge-tree.c implementation which would make this series
unnecessary.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
       [not found] ` <7v1wd1d0le.fsf@gitster.siamese.dyndns.org>
@ 2007-09-14 18:30   ` Shawn O. Pearce
  2007-09-15  7:47     ` db/fetch-pack topic (was: What's cooking in git.git (topics)) Shawn O. Pearce
  2007-09-14 23:47   ` What's cooking in git.git (topics) Johannes Schindelin
  2007-09-26 20:05   ` Junio C Hamano
  2 siblings, 1 reply; 575+ messages in thread
From: Shawn O. Pearce @ 2007-09-14 18:30 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <gitster@pobox.com> wrote:
> * db/fetch-pack (Fri Sep 14 03:31:25 2007 -0400) 22 commits
...
> This is Daniel's fetch-pack in C plus fixups from Shawn.
> Unfortunately the fixups breaks t3200 ("*** glibc detected ***
> fetch: free(): invalid pointer xxx ***"), which I haven't looked
> into yet.

Doesn't crash out on my Mac OS X system but I am getting the
above failure on my amd64 Linux system.  I'm debugging it now.
I'll have to quit in about an hour and pick it up later, so don't
expect a patch immediately.  But I'll certainly send something soon.
Clearly I made a change in my fixups that I shouldn't have.  ;-)

-- 
Shawn.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
       [not found] ` <7v1wd1d0le.fsf@gitster.siamese.dyndns.org>
  2007-09-14 18:30   ` Shawn O. Pearce
@ 2007-09-14 23:47   ` Johannes Schindelin
  2007-09-26 21:07     ` Carlos Rica
  2007-09-26 20:05   ` Junio C Hamano
  2 siblings, 1 reply; 575+ messages in thread
From: Johannes Schindelin @ 2007-09-14 23:47 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Fri, 14 Sep 2007, Junio C Hamano wrote:

> * cr/reset (Fri Sep 14 01:19:30 2007 -0700) 5 commits
>  + Simplify cache API
>  + An additional test for "git-reset -- path"
>  + Make "git reset" a builtin.
>  + Move make_cache_entry() from merge-recursive.c into read-cache.c
>  + Add tests for documented features of "git reset".
> 
> I found "git reset commit paths..." had problem in this series,
> which was why jc/cachetree is merged into this topic to fix it.
> Hopefully we can put this in 'master' soon, after giving it
> another and final round of eyeballing.

I think this is my bug.  The initial reset-with-paths functionality in the 
builtin reset came out of my feather... Sorry!

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: db/fetch-pack topic (was: What's cooking in git.git (topics))
  2007-09-14 18:30   ` Shawn O. Pearce
@ 2007-09-15  7:47     ` Shawn O. Pearce
  2007-09-16  4:03       ` Shawn O. Pearce
  0 siblings, 1 reply; 575+ messages in thread
From: Shawn O. Pearce @ 2007-09-15  7:47 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > * db/fetch-pack (Fri Sep 14 03:31:25 2007 -0400) 22 commits
> ...
> > This is Daniel's fetch-pack in C plus fixups from Shawn.
> > Unfortunately the fixups breaks t3200 ("*** glibc detected ***
> > fetch: free(): invalid pointer xxx ***"), which I haven't looked
> > into yet.
> 
> Doesn't crash out on my Mac OS X system but I am getting the
> above failure on my amd64 Linux system.

OK, so in addition to the above fixups Junio mentions I have
also sent two more series today:

  2 patch "fixup of the fixup" to resolve the t3200 crash
  5 patch "fixup + cleanup" of http support

and now I just discovered that pushing to yourself is probably also
broken by this series:

  $ git push . jc/maint:gfi-maint
  updating 'refs/heads/gfi-maint' using 'refs/remotes/jc/maint'
    from 05cc2ffc572f05e8aeec495a9ab9bc9609863491
    to   8419d2ee9ba8b375186a5c1019df8dfbce610aba
  Also local refs/heads/gfi-maint
  Generating pack...
  Done counting 0 objects.
  Writing 0 objects...
  Unpacking 0 objects...
  error: Ref refs/heads/gfi-maint is at 8419d2ee9ba8b375186a5c1019df8dfbce610aba but expected 05cc2ffc572f05e8aeec495a9ab9bc9609863491
  error: failed to lock refs/heads/gfi-maint
  Total 0 (delta 0), reused 0 (delta 0)
  ng refs/heads/gfi-maint failed to lock
  error: failed to push to '.'

What's really exciting is we actually updated the ref 'gfi-maint',
even though it was "ng" and we failed to push.  Yup.  More work
for me to look at tomorrow.  Right now I think I'm all memory
corruptioned out for *** brain detected *** Shawn(): nextword():
too tired, try sleep ***

;-)

-- 
Shawn.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: db/fetch-pack topic (was: What's cooking in git.git (topics))
  2007-09-15  7:47     ` db/fetch-pack topic (was: What's cooking in git.git (topics)) Shawn O. Pearce
@ 2007-09-16  4:03       ` Shawn O. Pearce
  0 siblings, 0 replies; 575+ messages in thread
From: Shawn O. Pearce @ 2007-09-16  4:03 UTC (permalink / raw)
  To: git

> "Shawn O. Pearce" <spearce@spearce.org> wrote:
> > Junio C Hamano <gitster@pobox.com> wrote:
> > > * db/fetch-pack (Fri Sep 14 03:31:25 2007 -0400) 22 commits
> > ...
> > > This is Daniel's fetch-pack in C plus fixups from Shawn.
> > > Unfortunately the fixups breaks t3200 ("*** glibc detected ***
> > > fetch: free(): invalid pointer xxx ***"), which I haven't looked
> > > into yet.

With all of my fixups applied I took some performance measurements
today from two of my larger day-job repositories:

  A.git (356 branches):
    Current Fetch             New "Builtin" Fetch
    ------------------        --------------------
    real    3m19.921s         real    0m9.969s
    user    1m58.050s         user    0m1.449s
    sys     2m4.747s          sys     0m4.465s

  B.git (24 branches):
    Current Fetch             New "Builtin" Fetch
    ------------------        --------------------
    real    0m21.250s         real    0m4.735s
    user    0m10.981s         user    0m0.510s
    sys     0m12.387s         sys     0m1.481s

All runs were a no-op fetch over SSH on the LAN.  The system running
git-fetch was a Cygwin/Windows 2000 box and the server was Solaris 9.
Just starting an SSH connection (`ssh solsrv echo hi`) takes me on
average 1 second so a 4.7s no-op fetch on the smaller repository
is very respectable.

3m19s vs. 9s?  I'll take 9s, thankyouverymuch.  Even if I have
more testing and debugging to do.  Especially since the two repos
above are only a sampling of the actual set I have to deal with on
a daily basis.

-- 
Shawn.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
       [not found] ` <7v1wd1d0le.fsf@gitster.siamese.dyndns.org>
  2007-09-14 18:30   ` Shawn O. Pearce
  2007-09-14 23:47   ` What's cooking in git.git (topics) Johannes Schindelin
@ 2007-09-26 20:05   ` Junio C Hamano
  2007-09-26 21:44     ` Johannes Schindelin
                       ` (3 more replies)
  2 siblings, 4 replies; 575+ messages in thread
From: Junio C Hamano @ 2007-09-26 20:05 UTC (permalink / raw)
  To: git

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.

* jk/diff-rename (Tue Sep 25 15:29:42 2007 -0400) 1 commit
 + diffcore-rename: cache file deltas

Parked in 'next' for now but is 'master' material.

* mv/unknown (Tue Sep 25 16:38:46 2007 +0200) 1 commit
 + Don't use "<unknown>" for placeholders and suppress printing of
   empty user formats.

Parked in 'next'; I was already burned by it not passing one of
the test cases, and I am not absolutely certain what else this
subtly breaks.  Hopefully minor.

* jb/remote-rm (Sun Sep 23 22:29:12 2007 -0700) 3 commits
 + git-remote rm: add tests and minor fix-ups
 + remote: document the 'rm' subcommand
 + remote: add 'rm' subcommand

Should be Ok to push out to 'master'.

* ml/submodule (Sun Sep 23 22:19:42 2007 -0400) 1 commit
 + git-submodule - allow a relative path as the subproject url

Should be Ok to push out to 'master'.

* lh/merge (Mon Sep 24 00:51:45 2007 +0200) 6 commits
 + git-merge: add --ff and --no-ff options
 + git-merge: add support for --commit and --no-squash
 + git-merge: add support for branch.<name>.mergeoptions
 + git-merge: refactor option parsing
 + git-merge: fix faulty SQUASH_MSG
 + Add test-script for git-merge porcelain

Comments?  I personally never felt need for --no-ff but the
series is reasonably clean so I do not see strong objection
against this series either.

* sv/svn (Fri Sep 21 15:27:01 2007 +1200) 3 commits
 + git-svn: handle changed svn command-line syntax
 + git-svn: fix test for trunk svn (transaction out of date)
 + git-svn: fix test for trunk svn (commit message not needed)

Will merge to 'master' this weekend.

* js/rebase-i (Tue Sep 25 16:43:15 2007 +0100) 1 commit
 + rebase -i: work on a detached HEAD

Waiting for autogc change as this textually interacts with it,
and the additional convenience can wait.

* jc/autogc (Mon Sep 17 00:55:13 2007 -0700) 10 commits
 + git-gc --auto: run "repack -A -d -l" as necessary.
 + git-gc --auto: restructure the way "repack" command line is built.
 + git-gc --auto: protect ourselves from accumulated cruft
 + git-gc --auto: add documentation.
 + git-gc --auto: move threshold check to need_to_gc() function.
 + repack -A -d: use --keep-unreachable when repacking
 + pack-objects --keep-unreachable
 + Export matches_pack_name() and fix its return value
 + Invoke "git gc --auto" from commit, merge, am and rebase.
 + Implement git gc --auto

I think the only remaining thing left with this thing is to
prevent more than one instances of it from running at the same
time.  Any takers?

* ph/strbuf (Tue Sep 25 10:22:44 2007 +0200) 37 commits
 + Small cache_tree_write refactor.
 + Make builtin-rerere use of strbuf nicer and more efficient.
 + Add strbuf_cmp.
 + strbuf_setlen(): do not barf on setting length of an empty buffer
   to 0
 + sq_quote_argv and add_to_string rework with strbuf's.
 + Full rework of quote_c_style and write_name_quoted.
 + ...

I had to make a small fix-up to strbuf_setlen() last night to
this series; this should be ready for 'master'.

And it is better to push this out early, as the series touches
everywhere and conflicts with peoples' patches.

* db/fetch-pack (Tue Sep 25 00:13:25 2007 -0400) 45 commits
 + Prevent send-pack from segfaulting when a branch doesn't match
 + Cleanup unnecessary break in remote.c
 + Cleanup style nit of 'x == NULL' in remote.c
 + Fix memory leaks when disconnecting transport instances
 + Ensure builtin-fetch honors {fetch,transfer}.unpackLimit
 + ...

Two issues known to me are:

 - "rsync" transport is not supported yet;

 - regresses "git pull <name>" using .git/remotes/<name>; does
   not merge the first refspec when branch.<name>.merge is not
   set.

There may be others but some people apparently use this in
production (including me) and I do not expect major breakages in
the really essential part.

* ss/svnimport (Mon Sep 24 12:57:40 2007 +0200) 1 commit
 + Fix pool handling in git-svnimport to avoid memory leaks.

This is meant to eventually go to 'maint' as well but with
diminishing user base of svnimport it is getting harder to get
good "tested successfully, seen improvements" reports.

* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
 + rebase: allow starting from a dirty tree.
 + stash: implement "stash create"

I think "stash create" is going in a good direction, but I do
not think rebase should unstash unconditionally on the resulting
work tree.  A good compromise might be not to unstash if the
user asked to switch branches first and to unstash if he didn't.

* kh/commit (Mon Sep 17 20:06:48 2007 -0400) 7 commits
 - Implement git commit as a builtin command.
 - Export rerere() and launch_editor().
 - Add strbuf_read_file().
 - Clean up stripspace a bit, use strbuf even more.
 - Introduce entry point for launching add--interactive.
 - Enable wt-status to run against non-standard index file.
 - Enable wt-status output to a given FILE pointer.

There were a few updates/replacements to the list I missed;

* gr/smtp (Tue Sep 25 17:27:54 2007 -0700) 2 commits
 - [TO BE SQUASHED] Fix-up after review
 - Add ability to specify SMTP server port when using git-send-email.

Will be in 'next'.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-09-14 23:47   ` What's cooking in git.git (topics) Johannes Schindelin
@ 2007-09-26 21:07     ` Carlos Rica
  0 siblings, 0 replies; 575+ messages in thread
From: Carlos Rica @ 2007-09-26 21:07 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git

2007/9/15, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Fri, 14 Sep 2007, Junio C Hamano wrote:
>
> > * cr/reset (Fri Sep 14 01:19:30 2007 -0700) 5 commits
> >  + Simplify cache API
> >  + An additional test for "git-reset -- path"
> >  + Make "git reset" a builtin.
> >  + Move make_cache_entry() from merge-recursive.c into read-cache.c
> >  + Add tests for documented features of "git reset".
> >
> > I found "git reset commit paths..." had problem in this series,
> > which was why jc/cachetree is merged into this topic to fix it.
> > Hopefully we can put this in 'master' soon, after giving it
> > another and final round of eyeballing.
>
> I think this is my bug.  The initial reset-with-paths functionality in the
> builtin reset came out of my feather... Sorry!

I'm sorry for not being able to review that code, but now it was
a bit too hard for my current knowledge of the git's internals.
These days I'm very busy here and I cannot continue with that work,
but I will be soon in git to learn more. Please, be free to rework the
code of builtin-reset.c without waiting for me if anyone is interested
in get it done ASAP.

--
Carlos

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-09-26 20:05   ` Junio C Hamano
@ 2007-09-26 21:44     ` Johannes Schindelin
  2007-09-26 21:53       ` Tom Clarke
  2007-09-27  2:36     ` Jeff King
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 575+ messages in thread
From: Johannes Schindelin @ 2007-09-26 21:44 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Wed, 26 Sep 2007, Junio C Hamano wrote:

> * mv/unknown (Tue Sep 25 16:38:46 2007 +0200) 1 commit
>  + Don't use "<unknown>" for placeholders and suppress printing of
>    empty user formats.
> 
> Parked in 'next'; I was already burned by it not passing one of the test 
> cases, and I am not absolutely certain what else this subtly breaks.  
> Hopefully minor.

I guess a few scripts could maybe rely on this behaviour.  We should 
advertise it as such.

> * lh/merge (Mon Sep 24 00:51:45 2007 +0200) 6 commits
>  + git-merge: add --ff and --no-ff options
>  + git-merge: add support for --commit and --no-squash
>  + git-merge: add support for branch.<name>.mergeoptions
>  + git-merge: refactor option parsing
>  + git-merge: fix faulty SQUASH_MSG
>  + Add test-script for git-merge porcelain
> 
> Comments?  I personally never felt need for --no-ff but the series is 
> reasonably clean so I do not see strong objection against this series 
> either.

Together with a resubmitted git-merge-rebase.sh (hint, hint), the 
mergeOptions would be quite useful for a workflow where you want to rebase 
on top of an upstream quite often.

> * js/rebase-i (Tue Sep 25 16:43:15 2007 +0100) 1 commit
>  + rebase -i: work on a detached HEAD
> 
> Waiting for autogc change as this textually interacts with it, and the 
> additional convenience can wait.

Sure.  I never used it anyway, but you specifically requested it ;-)  BTW 
thanks for merging the rest; especially the progress meter was a sore 
point for me since long.

> * jc/autogc (Mon Sep 17 00:55:13 2007 -0700) 10 commits
>  + git-gc --auto: run "repack -A -d -l" as necessary.
>  + git-gc --auto: restructure the way "repack" command line is built.
>  + git-gc --auto: protect ourselves from accumulated cruft
>  + git-gc --auto: add documentation.
>  + git-gc --auto: move threshold check to need_to_gc() function.
>  + repack -A -d: use --keep-unreachable when repacking
>  + pack-objects --keep-unreachable
>  + Export matches_pack_name() and fix its return value
>  + Invoke "git gc --auto" from commit, merge, am and rebase.
>  + Implement git gc --auto
> 
> I think the only remaining thing left with this thing is to prevent more 
> than one instances of it from running at the same time.  Any takers?

You mean, just creating a throw-away lock file?

> * ph/strbuf (Tue Sep 25 10:22:44 2007 +0200) 37 commits
>  + Small cache_tree_write refactor.
>  + Make builtin-rerere use of strbuf nicer and more efficient.
>  + Add strbuf_cmp.
>  + strbuf_setlen(): do not barf on setting length of an empty buffer
>    to 0
>  + sq_quote_argv and add_to_string rework with strbuf's.
>  + Full rework of quote_c_style and write_name_quoted.
>  + ...
> 
> I had to make a small fix-up to strbuf_setlen() last night to this 
> series; this should be ready for 'master'.
> 
> And it is better to push this out early, as the series touches 
> everywhere and conflicts with peoples' patches.

Hehe.  Indeed, I had to fix the notes series after rebasing it...

> * db/fetch-pack (Tue Sep 25 00:13:25 2007 -0400) 45 commits
>  + Prevent send-pack from segfaulting when a branch doesn't match
>  + Cleanup unnecessary break in remote.c
>  + Cleanup style nit of 'x == NULL' in remote.c
>  + Fix memory leaks when disconnecting transport instances
>  + Ensure builtin-fetch honors {fetch,transfer}.unpackLimit
>  + ...
> 
> Two issues known to me are:
> 
>  - "rsync" transport is not supported yet;

I promised to do this, and so I will today.

> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
>  + rebase: allow starting from a dirty tree.
>  + stash: implement "stash create"
> 
> I think "stash create" is going in a good direction, but I do not think 
> rebase should unstash unconditionally on the resulting work tree.  A 
> good compromise might be not to unstash if the user asked to switch 
> branches first and to unstash if he didn't.

Sounds like a sensible change to me; maybe a little warning after the 
rebase?

I have no idea if I come around to do the same for rebase--interactive any 
time soon, though.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-09-26 21:44     ` Johannes Schindelin
@ 2007-09-26 21:53       ` Tom Clarke
  0 siblings, 0 replies; 575+ messages in thread
From: Tom Clarke @ 2007-09-26 21:53 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git

On 9/26/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Together with a resubmitted git-merge-rebase.sh (hint, hint), the
> mergeOptions would be quite useful for a workflow where you want to rebase
> on top of an upstream quite often.

I'll resubmit merge rebase tomorrow :-)

-Tom

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-09-26 20:05   ` Junio C Hamano
  2007-09-26 21:44     ` Johannes Schindelin
@ 2007-09-27  2:36     ` Jeff King
  2007-09-27  6:08       ` David Kastrup
  2007-10-02  4:16       ` Jeff King
  2007-09-28  3:24     ` Daniel Barkalow
  2007-10-02  5:53     ` Junio C Hamano
  3 siblings, 2 replies; 575+ messages in thread
From: Jeff King @ 2007-09-27  2:36 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wed, Sep 26, 2007 at 01:05:59PM -0700, Junio C Hamano wrote:

> * jk/diff-rename (Tue Sep 25 15:29:42 2007 -0400) 1 commit
>  + diffcore-rename: cache file deltas
> 
> Parked in 'next' for now but is 'master' material.

My tests after this patch show that spanhash_find is responsible for
a large portion of the processing time in large renames, so I am going
to look into speeding that up.

> * lh/merge (Mon Sep 24 00:51:45 2007 +0200) 6 commits
>  + git-merge: add --ff and --no-ff options
>  + git-merge: add support for --commit and --no-squash
>  + git-merge: add support for branch.<name>.mergeoptions
>  + git-merge: refactor option parsing
>  + git-merge: fix faulty SQUASH_MSG
>  + Add test-script for git-merge porcelain
> 
> Comments?  I personally never felt need for --no-ff but the
> series is reasonably clean so I do not see strong objection
> against this series either.

I like it. I know that --no-ff is frowned upon, but I think previous
discussions have mentioned workflows where it might be used
intelligently. Since the patch is unlikely to break anything for
traditional workflows, I think it is a nice way to let people experiment
with alternative workflows that use --no-ff. Maybe something interesting
will come of it.

-Peff

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-09-27  2:36     ` Jeff King
@ 2007-09-27  6:08       ` David Kastrup
  2007-09-27  6:43         ` David Kastrup
  2007-09-27 13:30         ` Jeff King
  2007-10-02  4:16       ` Jeff King
  1 sibling, 2 replies; 575+ messages in thread
From: David Kastrup @ 2007-09-27  6:08 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, git

Jeff King <peff@peff.net> writes:

> On Wed, Sep 26, 2007 at 01:05:59PM -0700, Junio C Hamano wrote:
>
>> * jk/diff-rename (Tue Sep 25 15:29:42 2007 -0400) 1 commit
>>  + diffcore-rename: cache file deltas
>> 
>> Parked in 'next' for now but is 'master' material.
>
> My tests after this patch show that spanhash_find is responsible for
> a large portion of the processing time in large renames, so I am going
> to look into speeding that up.

In itself, it does not look like there is all too much room for
optimization.  One can remove the temporary pointer "optimization" and
see whether this makes strength reduction possible for the compiler.
Making this an endless loop wrapped around a loop on bucket might also
help the compiler in that effect.

But there is really not all too much leeway, and it might be better
spent in the caller.  For example, the search will take something like
r/(1-r) iterations on average where r is the fill ratio of the hash
array.  So one would not want to, say, let r grow above 0.75 or
something like that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-09-27  6:08       ` David Kastrup
@ 2007-09-27  6:43         ` David Kastrup
  2007-09-27 13:30         ` Jeff King
  1 sibling, 0 replies; 575+ messages in thread
From: David Kastrup @ 2007-09-27  6:43 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, git

David Kastrup <dak@gnu.org> writes:

> Jeff King <peff@peff.net> writes:
>
>> On Wed, Sep 26, 2007 at 01:05:59PM -0700, Junio C Hamano wrote:
>>
>>> * jk/diff-rename (Tue Sep 25 15:29:42 2007 -0400) 1 commit
>>>  + diffcore-rename: cache file deltas
>>> 
>>> Parked in 'next' for now but is 'master' material.
>>
>> My tests after this patch show that spanhash_find is responsible for
>> a large portion of the processing time in large renames, so I am going
>> to look into speeding that up.
>
> In itself, it does not look like there is all too much room for
> optimization.  One can remove the temporary pointer "optimization" and
> see whether this makes strength reduction possible for the compiler.
> Making this an endless loop wrapped around a loop on bucket might also
> help the compiler in that effect.
>
> But there is really not all too much leeway, and it might be better
> spent in the caller.  For example, the search will take something like
> r/(1-r) iterations on average where r is the fill ratio of the hash
> array.  So one would not want to, say, let r grow above 0.75 or
> something like that.

Ok, here is some suggestion:

Here is the inner loop for this stuff:

	for (i = 0; i < ssz; i++) {
		struct spanhash *s = &(src_count->data[i]);
		struct spanhash *d;
		unsigned dst_cnt, src_cnt;
		if (!s->cnt)
			continue;
		src_cnt = s->cnt;
		d = spanhash_find(dst_count, s->hashval);
		dst_cnt = d ? d->cnt : 0;
		if (src_cnt < dst_cnt) {
			la += dst_cnt - src_cnt;
			sc += src_cnt;
		}
		else
			sc += dst_cnt;
	}

Now here is how one could optimize the data structures: The hash
structures are with linear probing, and we try to find any hash
matches from source to destination.  If we sort all hashes indexed to
a given first hash bucket by their full hash value, then one could
basically use passes similar to list merges for figuring the 1:1
relations.  That cuts down the O(l n) cost (where n is the number of
elements and l their average run length) to O(n).

Of course, making l close to 1 by keeping the hash utilization
reasonably low is much simpler.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-09-27  6:08       ` David Kastrup
  2007-09-27  6:43         ` David Kastrup
@ 2007-09-27 13:30         ` Jeff King
  2007-09-27 13:46           ` David Kastrup
  1 sibling, 1 reply; 575+ messages in thread
From: Jeff King @ 2007-09-27 13:30 UTC (permalink / raw)
  To: David Kastrup; +Cc: Junio C Hamano, git

On Thu, Sep 27, 2007 at 08:08:44AM +0200, David Kastrup wrote:

> In itself, it does not look like there is all too much room for
> optimization.  One can remove the temporary pointer "optimization" and
> see whether this makes strength reduction possible for the compiler.
> Making this an endless loop wrapped around a loop on bucket might also
> help the compiler in that effect.

I am considering reworking the data structure to be a hash table whose
buckets never overflow. However, Junio indicated that he tried something
similar at one point and was not successful. So we will see. I haven't
had time to play with it yet, but I will post numbers when I do.

-Peff

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-09-27 13:30         ` Jeff King
@ 2007-09-27 13:46           ` David Kastrup
  0 siblings, 0 replies; 575+ messages in thread
From: David Kastrup @ 2007-09-27 13:46 UTC (permalink / raw)
  To: git

Jeff King <peff@peff.net> writes:

> On Thu, Sep 27, 2007 at 08:08:44AM +0200, David Kastrup wrote:
>
>> In itself, it does not look like there is all too much room for
>> optimization.  One can remove the temporary pointer "optimization" and
>> see whether this makes strength reduction possible for the compiler.
>> Making this an endless loop wrapped around a loop on bucket might also
>> help the compiler in that effect.
>
> I am considering reworking the data structure to be a hash table
> whose buckets never overflow. However, Junio indicated that he tried
> something similar at one point and was not successful. So we will
> see. I haven't had time to play with it yet, but I will post numbers
> when I do.

Linear probing is pretty efficient with regard to keeping memory
access locality.  With a reasonable table filling ratio (not more than
something like 75%, for which it is necessary to know the maximum
number of hashable entries in advance), there is no gain to be
expected in either speed or even memory usage (the waste of 25% is
offset by not needing space for link pointers) with escape lists.
Linear probing hashes are quite hard to resize: if the maximum member
count is _not_ to be guessed in advance, things might look different.

I don't have the time to look at the code right now, so I don't know
whether resizing or unknown maximum size is a relevant factor.

-- 
David Kastrup

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-09-26 20:05   ` Junio C Hamano
  2007-09-26 21:44     ` Johannes Schindelin
  2007-09-27  2:36     ` Jeff King
@ 2007-09-28  3:24     ` Daniel Barkalow
  2007-10-02  5:53     ` Junio C Hamano
  3 siblings, 0 replies; 575+ messages in thread
From: Daniel Barkalow @ 2007-09-28  3:24 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wed, 26 Sep 2007, Junio C Hamano wrote:

> * db/fetch-pack (Tue Sep 25 00:13:25 2007 -0400) 45 commits
>  + Prevent send-pack from segfaulting when a branch doesn't match
>  + Cleanup unnecessary break in remote.c
>  + Cleanup style nit of 'x == NULL' in remote.c
>  + Fix memory leaks when disconnecting transport instances
>  + Ensure builtin-fetch honors {fetch,transfer}.unpackLimit
>  + ...
> 
> Two issues known to me are:
> 
>  - "rsync" transport is not supported yet;
> 
>  - regresses "git pull <name>" using .git/remotes/<name>; does
>    not merge the first refspec when branch.<name>.merge is not
>    set.

Actually, I think it's only that it doesn't merge anything if the first 
refspec doesn't match the first fetched ref from the server. I'm running 
tests on a patch that should fix it, but I'm not sure how to write a test 
for this particular case; I think the fetch tests try to test this, but 
pass by chance.

	-Daniel
*This .sig left intentionally blank*

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-09-27  2:36     ` Jeff King
  2007-09-27  6:08       ` David Kastrup
@ 2007-10-02  4:16       ` Jeff King
  2007-10-02  5:01         ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Jeff King @ 2007-10-02  4:16 UTC (permalink / raw)
  To: git

On Wed, Sep 26, 2007 at 10:36:33PM -0400, Jeff King wrote:

> > * jk/diff-rename (Tue Sep 25 15:29:42 2007 -0400) 1 commit
> >  + diffcore-rename: cache file deltas
> > 
> > Parked in 'next' for now but is 'master' material.
> 
> My tests after this patch show that spanhash_find is responsible for
> a large portion of the processing time in large renames, so I am going
> to look into speeding that up.

Just to update, I tried using a non-colliding hash for this (at the
expense of much memory), and I wasn't able to get things much faster
(and certainly not worth the explosion in memory), short of reducing the
size of the hash (which is going to reduce the quality of the output).
So I am giving up for the time being, but if others are interested in
trying to speed things up, I would be happy to discuss ideas.

-Peff

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  4:16       ` Jeff King
@ 2007-10-02  5:01         ` Junio C Hamano
  2007-10-02  5:08           ` Jeff King
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2007-10-02  5:01 UTC (permalink / raw)
  To: Jeff King; +Cc: git

Jeff King <peff@peff.net> writes:

> Just to update, I tried using a non-colliding hash for this (at the
> expense of much memory), and I wasn't able to get things much faster
> (and certainly not worth the explosion in memory), short of reducing the
> size of the hash (which is going to reduce the quality of the output).
> So I am giving up for the time being, but if others are interested in
> trying to speed things up, I would be happy to discuss ideas.

Bummer.  You are giving up at the same place I gave up the last
time.  I was somehow hoping that other people are more clever
and determined than I was ;-).

Thanks for trying.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  5:01         ` Junio C Hamano
@ 2007-10-02  5:08           ` Jeff King
  2007-10-02  5:13             ` Jeff King
  0 siblings, 1 reply; 575+ messages in thread
From: Jeff King @ 2007-10-02  5:08 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Mon, Oct 01, 2007 at 10:01:16PM -0700, Junio C Hamano wrote:

> > Just to update, I tried using a non-colliding hash for this (at the
> > expense of much memory), and I wasn't able to get things much faster
> > (and certainly not worth the explosion in memory), short of reducing the
> > size of the hash (which is going to reduce the quality of the output).
> > So I am giving up for the time being, but if others are interested in
> > trying to speed things up, I would be happy to discuss ideas.
> 
> Bummer.  You are giving up at the same place I gave up the last
> time.  I was somehow hoping that other people are more clever
> and determined than I was ;-).
> 
> Thanks for trying.

What was so discouraging is that I literally simplified the process to

  for(i = 0; i < HASH_SIZE; i++)
      if(src[i] < dst[i])
        ...

and it spent all of the time on that one conditional.

One approach which I haven't tried but might be promising is to actually
keep each list sorted, and then do a "merge" of the two lists, comparing
as you go. We don't really need to do arbitrary lookups in the hash; we
just need to compare two hash tables at a time. My approach was to be
simple, but have O(HASH_SIZE) comparisons (where HASH_SIZE is on the
order of 2^17), and that's clearly just too big. But with a list merge,
it should be O(n), where n is the actual number of lines in the files
(or binary chunks for the binary case).

-Peff

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  5:08           ` Jeff King
@ 2007-10-02  5:13             ` Jeff King
  2007-10-02  6:10               ` David Kastrup
  0 siblings, 1 reply; 575+ messages in thread
From: Jeff King @ 2007-10-02  5:13 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Tue, Oct 02, 2007 at 01:08:20AM -0400, Jeff King wrote:

> One approach which I haven't tried but might be promising is to actually
> keep each list sorted, and then do a "merge" of the two lists, comparing
> as you go. We don't really need to do arbitrary lookups in the hash; we
> just need to compare two hash tables at a time. My approach was to be
> simple, but have O(HASH_SIZE) comparisons (where HASH_SIZE is on the
> order of 2^17), and that's clearly just too big. But with a list merge,
> it should be O(n), where n is the actual number of lines in the files
> (or binary chunks for the binary case).

BTW, I don't want to steal credit for this idea...it comes from thinking
about what David Kastrup said earlier in the thread, though I think he
was proposing sorting just inside buckets.

-Peff

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2007-09-26 20:05   ` Junio C Hamano
                       ` (2 preceding siblings ...)
  2007-09-28  3:24     ` Daniel Barkalow
@ 2007-10-02  5:53     ` Junio C Hamano
  2007-10-02  6:41       ` Steven Grimm
                         ` (3 more replies)
  3 siblings, 4 replies; 575+ messages in thread
From: Junio C Hamano @ 2007-10-02  5:53 UTC (permalink / raw)
  To: git

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.

----------------------------------------------------------------

* ph/strbuf (Thu Sep 27 13:33:19 2007 +0200) 44 commits
 + Make read_patch_file work on a strbuf.
 + strbuf_read_file enhancement, and use it.
 + strbuf change: be sure ->buf is never ever NULL.
 + double free in builtin-update-index.c
 + Clean up stripspace a bit, use strbuf even more.
 + Add strbuf_read_file().
 ...

Will be in 'master' soon.  We've seen nice linecount reduction
and the end result is rather pleasant to read.

* jc/am-quiet (Mon Oct 1 00:27:51 2007 -0700) 2 commits
 + git-am: fix typo in the previous one.
 + git-am: make the output quieter.

Response against recent "rebase being too chatty" complaints.
This should be a 'master' material.

* ap/dateformat (Fri Sep 28 15:17:45 2007 +0100) 3 commits
 + Make for-each-ref's grab_date() support per-atom formatting
 + Make for-each-ref allow atom names like "<name>:<something>"
 + parse_date_format(): convert a format name to an enum date_mode

With some test suite additions, this could go to 'master' soon.
Yes, that's a HINT, people ;-).

* je/hooks (Wed Sep 26 15:31:01 2007 -0600) 1 commit
 + post-checkout hook, tests, and docs

Will be in 'master' soon.

* db/fetch-pack (Mon Oct 1 00:59:39 2007 +0100) 49 commits
 + fetch/push: readd rsync support
 + Introduce remove_dir_recursively()
 + bundle transport: fix an alloc_ref() call
 + Allow abbreviations in the first refspec to be merged
 + Prevent send-pack from segfaulting when a branch doesn't match
 + Cleanup unnecessary break in remote.c
 ...

Has been cooking for quite long time.

There was a regression that made me quite unhappy about the
rewrite, but Daniel fixed it, so I should be happy.  There is
another usability regression: http transport is now totally
silent.  Even when you fetch daily, if the other end frequently
repacks everything into one big ball of wax like repo.or.cz
does, you will end up transferring quite a large pack every
time, and the total lack of progress report is unacceptably
unnerving.  At least we should reinstate "Fetching blah from URL
using http", and preferrably "walk $object_name" lines.  The
latter could be replaced with just series of CR + "walked N
commits..." if we do not like many output from the current "walk
$object_name" lines scrolling the other information away.

I am not sure the quality of "rsync" transport near the tip,
either, but at least the change should not affect other
transports.  Nobody should using about rsync transport these
days anyway.  Perhaps we should put a deprecation notice in the
release notes to 1.5.4, and remove it three months later.

* jc/autogc (Mon Sep 17 00:55:13 2007 -0700) 10 commits
 + git-gc --auto: run "repack -A -d -l" as necessary.
 + git-gc --auto: restructure the way "repack" command line is built.
 + git-gc --auto: protect ourselves from accumulated cruft
 + git-gc --auto: add documentation.
 + git-gc --auto: move threshold check to need_to_gc() function.
 + repack -A -d: use --keep-unreachable when repacking
 + pack-objects --keep-unreachable
 + Export matches_pack_name() and fix its return value
 + Invoke "git gc --auto" from commit, merge, am and rebase.
 + Implement git gc --auto

I think this one is reasonably sane, but I was the one who wrote
it so people should take that with a grain of salt.  What it is
and isn't:

 - "gc --auto" is a way to prevent you from keeping your
   repository _grossly_ inefficient.  Ideally, if you ever
   rapacked your repository once, and do the regular repository
   maintenance ("'git gc' before you leave for lunch every other
   day"), it should never trigger.

 - "gc --auto" is not something you can background.  We do not
   want to lock the repository and worry about associated stale
   lock, expiry etc.  The complexity is not worth it, compared
   to the stated purpose above (I suspect it might already be
   safe to run multiple instances at the same time, but the
   effort to analyze if it is is not even worth, compared to the
   stated purpose above.  Just let it run synchronously if it
   triggers, but it should not trigger for you).

* js/rebase-i (Tue Sep 25 16:43:15 2007 +0100) 1 commits
 + rebase -i: work on a detached HEAD

Will be in 'master', together with "gc --auto", soon.

* mv/unknown (Tue Sep 25 16:38:46 2007 +0200) 1 commit
 + Don't use "<unknown>" for placeholders and suppress printing of
   empty user formats.

Will be in 'master' soon.

* lh/merge (Mon Sep 24 00:51:45 2007 +0200) 6 commits
 + git-merge: add --ff and --no-ff options
 + git-merge: add support for --commit and --no-squash
 + git-merge: add support for branch.<name>.mergeoptions
 + git-merge: refactor option parsing
 + git-merge: fix faulty SQUASH_MSG
 + Add test-script for git-merge porcelain

Will be in 'master' soon.

* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
 + rebase: allow starting from a dirty tree.
 + stash: implement "stash create"

Instead of refusing to rebase, telling you that your work tree
is dirty, this stashes your local changes, runs rebase and then
unstashes automatically.  That _sounds_ nicer and easier to use,
but I am not sure if it is a wise/sane thing to do.  We may want
to revert the "autostash" from rebase.  Opinions?

* kh/commit (Mon Sep 17 20:06:47 2007 -0400)
 + Export rerere() and launch_editor().
 + Introduce entry point add_interactive and add_files_to_cache
 + Clean up stripspace a bit, use strbuf even more.
 + Add strbuf_read_file().
 + rerere: Fix use of an empty strbuf.buf
 + Small cache_tree_write refactor.
 ...

Stalled.

* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
 - pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
 - ls-tree.c: refactor show_recursive() and rename it.
 - tree-diff.c: split out a function to match a single pattern.

Stalled.  This is about my pet-peeve that log (diff-tree) family
has much limited pathspec semantics.  It should learn to glob
like ls-files and grep do.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  5:13             ` Jeff King
@ 2007-10-02  6:10               ` David Kastrup
  2007-10-02 16:11                 ` Jeff King
  0 siblings, 1 reply; 575+ messages in thread
From: David Kastrup @ 2007-10-02  6:10 UTC (permalink / raw)
  To: git

Jeff King <peff@peff.net> writes:

> On Tue, Oct 02, 2007 at 01:08:20AM -0400, Jeff King wrote:
>
>> One approach which I haven't tried but might be promising is to actually
>> keep each list sorted, and then do a "merge" of the two lists, comparing
>> as you go. We don't really need to do arbitrary lookups in the hash; we
>> just need to compare two hash tables at a time. My approach was to be
>> simple, but have O(HASH_SIZE) comparisons (where HASH_SIZE is on the
>> order of 2^17), and that's clearly just too big. But with a list merge,
>> it should be O(n), where n is the actual number of lines in the files
>> (or binary chunks for the binary case).
>
> BTW, I don't want to steal credit for this idea...it comes from thinking
> about what David Kastrup said earlier in the thread, though I think he
> was proposing sorting just inside buckets.

Yes: my proposal was about a microoptimization: work with the
basically existing data structures and put the already contained
information to best use.

I have not actually looked at the actual task that the structures are
going to be used in, and whether "reusing" the information is likely
to be worth the trouble.

When we are talking about buzzword compliance, "keep sorted" with the
meaning of "maintain sorted across modifications" has an O(n^2) or at
least O(nm) ring to it.  However, if it is possible to sort it just
once, and then then only merge with other lists...

I am actually quite a fan of merge sort and have even posted a small
and quite efficient version to this list once.  However, merge sorts
were really greatest at the time when cache memory was unusual to
have.  Nowadays, quicksort or similar could be faster due to better
locality of memory accesses.  I think the glibc qsort more or less
uses an array-based merge into a separate memory area (unless it runs
out of memory in which case it resorts to regular quicksort).

-- 
David Kastrup

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  5:53     ` Junio C Hamano
@ 2007-10-02  6:41       ` Steven Grimm
  2007-10-02  6:44       ` Steffen Prohaska
                         ` (2 subsequent siblings)
  3 siblings, 0 replies; 575+ messages in thread
From: Steven Grimm @ 2007-10-02  6:41 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano wrote:
> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
>  + rebase: allow starting from a dirty tree.
>  + stash: implement "stash create"
>
> Instead of refusing to rebase, telling you that your work tree
> is dirty, this stashes your local changes, runs rebase and then
> unstashes automatically.  That _sounds_ nicer and easier to use,
> but I am not sure if it is a wise/sane thing to do.  We may want
> to revert the "autostash" from rebase.  Opinions?
>   

I can say that for people coming from svn (who are often using "git svn 
rebase" rather than directly running "git rebase") this is a nice 
workflow improvement. It eliminates one more "Why is this more of a pain 
to do in git than in svn?" complaint.

I don't see any circumstance in my use of git -- either in a git-svn 
context or not -- where this wouldn't be an improvement over the 
existing behavior. However, I don't claim to be using git in any 
particularly interesting way, so I suppose it's possible that this will 
break someone's workflow horribly.

-Steve

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  5:53     ` Junio C Hamano
  2007-10-02  6:41       ` Steven Grimm
@ 2007-10-02  6:44       ` Steffen Prohaska
  2007-10-02  7:03         ` Matthieu Moy
  2007-10-02 12:52       ` What's cooking in git.git (topics) Johannes Schindelin
  2007-10-02 17:00       ` Daniel Barkalow
  3 siblings, 1 reply; 575+ messages in thread
From: Steffen Prohaska @ 2007-10-02  6:44 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git


On Oct 2, 2007, at 7:53 AM, Junio C Hamano wrote:

>
> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
>  + rebase: allow starting from a dirty tree.
>  + stash: implement "stash create"
>
> Instead of refusing to rebase, telling you that your work tree
> is dirty, this stashes your local changes, runs rebase and then
> unstashes automatically.  That _sounds_ nicer and easier to use,
> but I am not sure if it is a wise/sane thing to do.  We may want
> to revert the "autostash" from rebase.  Opinions?

What would happen if 'git stash' fails to work? Could this bring
the repo in a state that is hard to recover from? Especially if
'stash' commands were run automatically for you. Maybe if you had
a choice you would not choose to use stash but would commit your
changes, or would bring your work tree in a clean state by other means.

I'm a bit concerned because 'git stash' still doesn't work for me
when the work tree is dirty because of a changed subproject (in
msysgit with git 1.5.3). After I run 'git stash' the work tree stays
dirty. How would "autostash" behave?

BTW, I run 'git submodule update' to bring the tree into a clean
state and later manually check out the previous head in the submodule.
Quite annoying, but not directly related to the discussion above.

	Steffen

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  6:44       ` Steffen Prohaska
@ 2007-10-02  7:03         ` Matthieu Moy
  2007-10-02  7:21           ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Matthieu Moy @ 2007-10-02  7:03 UTC (permalink / raw)
  To: Steffen Prohaska; +Cc: Junio C Hamano, git

Steffen Prohaska <prohaska@zib.de> writes:

> On Oct 2, 2007, at 7:53 AM, Junio C Hamano wrote:
>
>>
>> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
>>  + rebase: allow starting from a dirty tree.
>>  + stash: implement "stash create"
>>
>> Instead of refusing to rebase, telling you that your work tree
>> is dirty, this stashes your local changes, runs rebase and then
>> unstashes automatically.  That _sounds_ nicer and easier to use,
>> but I am not sure if it is a wise/sane thing to do.  We may want
>> to revert the "autostash" from rebase.  Opinions?
>
> What would happen if 'git stash' fails to work? Could this bring
> the repo in a state that is hard to recover from? Especially if
> 'stash' commands were run automatically for you. Maybe if you had
> a choice you would not choose to use stash but would commit your
> changes, or would bring your work tree in a clean state by other means.

I'm also concerned about the possibility of stash/unstash to fail:
that means the user has to deal with two kinds of conflicts (rebase
can conflict, unstash can also), which can be confusing.

But the current behavior can be greatly improved by just making the
error message better. Currently, I have this:

$ git rebase branch
foo.txt: needs update
$ _

I'd prefer something like

$ git rebase branch
cannot rebase: the working tree is not clean.
foo.txt: Changed but not updated
Commit your changes, or put them appart with "git stash" and retry.
$ _

-- 
Matthieu

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  7:03         ` Matthieu Moy
@ 2007-10-02  7:21           ` Junio C Hamano
  2007-10-02  8:01             ` David Kågedal
  2007-10-02  8:07             ` Matthieu Moy
  0 siblings, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2007-10-02  7:21 UTC (permalink / raw)
  To: git; +Cc: Steffen Prohaska, Matthieu Moy

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> I'm also concerned about the possibility of stash/unstash to fail:
> that means the user has to deal with two kinds of conflicts (rebase
> can conflict, unstash can also), which can be confusing.

Unstash should be invoked automatically _only_ after rebase
completes, so I do not forsee such confusion.

But the trouble I have with the auto unstashing is more at the
conceptual and workflow level.  You start rebasing a branch, and
your work tree is dirty.  What branch should the local
modification belong to?

Logically, it is with the branch you were on when you typed "git
rebase" command.

But when "rebase" successfully concludes (either with or without
manual fix-ups), you can be either on your original branch (if
you said "git rebase base") or something totally unrelated (if
you said "git rebase base other").  Currently we auto-unstash in
both cases.  I _think_ the former case should auto-unstash, but
the latter shouldn't.

However, this auto-stash uses the new "git stash create" command
that does not update the reflog for "refs/stash", specifically
so that the auto-stashing does _not_ interfere with the normal
stash the end user uses.  Which means that it is a bit
cumbersome to give the autostashed state back to the user if we
do _not_ unstash upon completion of rebase.

Perhaps a good compromise would be to

 * not to do the autostash, but fail as we have always done,
   when "git rebase base other" form was used, first instructing
   rebase to switch to another branch;

 * autostash when "git rebase base" form was used, and auto
   unstash upon completion.

> But the current behavior can be greatly improved by just making the
> error message better. Currently, I have this:
>
> $ git rebase branch
> foo.txt: needs update
> $ _
>
> I'd prefer something like
>
> $ git rebase branch
> cannot rebase: the working tree is not clean.
> foo.txt: Changed but not updated
> Commit your changes, or put them appart with "git stash" and retry.
> $ _

You forgot 'needs merge' case, so that would not fly very well,
but something like this might be a good starting point.

---
 git-rebase.sh |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index 058fcac..4f8aeb9 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -252,7 +252,10 @@ else
 fi
 
 # The tree must be really really clean.
-git update-index --refresh || exit
+o=$(git update-index -q --refresh) || {
+	printf "cannot rebase: the work tree is not clean.\n%s\n" "$o"
+	exit 1
+}
 diff=$(git diff-index --cached --name-status -r HEAD)
 case "$diff" in
 ?*)	echo "cannot rebase: your index is not up-to-date"

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  7:21           ` Junio C Hamano
@ 2007-10-02  8:01             ` David Kågedal
  2007-10-02  8:07             ` Matthieu Moy
  1 sibling, 0 replies; 575+ messages in thread
From: David Kågedal @ 2007-10-02  8:01 UTC (permalink / raw)
  To: git

Junio C Hamano <gitster@pobox.com> writes:

>  * not to do the autostash, but fail as we have always done,
>    when "git rebase base other" form was used, first instructing
>    rebase to switch to another branch;

I don't like the idea of automatic stashing on a rebase.  It makes it
harder to understand what is happening, and figuring out were things
went if everything wasn't successful.

-- 
David Kågedal

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  7:21           ` Junio C Hamano
  2007-10-02  8:01             ` David Kågedal
@ 2007-10-02  8:07             ` Matthieu Moy
  2007-10-02 17:44               ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Matthieu Moy @ 2007-10-02  8:07 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Steffen Prohaska

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> I'm also concerned about the possibility of stash/unstash to fail:
>> that means the user has to deal with two kinds of conflicts (rebase
>> can conflict, unstash can also), which can be confusing.
>
> Unstash should be invoked automatically _only_ after rebase
> completes, so I do not forsee such confusion.

Well, if rebase itself conflicts, it will stop and tell you about
conflicts, then you'll have to "rebase --continue". If unstash fails,
you'll have to resolve the conflicts, and probably do "commit", or
continue working afterwards. You don't have to deal with both at the
same time, but both do exist, and they have to be taken care of
differently.

For an advanced user with good understanding of the flow, that's OK,
but I'm still afraid of the confusion for not-so-advanced users.

But that's not a strong argument against auto-stash, just one
downside.

> But the trouble I have with the auto unstashing is more at the
> conceptual and workflow level.  You start rebasing a branch, and
> your work tree is dirty.  What branch should the local
> modification belong to?

You're in a better position than me to juge on that point.

>  # The tree must be really really clean.
> -git update-index --refresh || exit
> +o=$(git update-index -q --refresh) || {
> +	printf "cannot rebase: the work tree is not clean.\n%s\n" "$o"
> +	exit 1
> +}
>  diff=$(git diff-index --cached --name-status -r HEAD)
>  case "$diff" in
>  ?*)	echo "cannot rebase: your index is not up-to-date"

That alone would already be a real improvement.

I'd add this to be consistant with "git status". I find the "needs
update" really short, and especially confusing for centralized systems
users, for whom "needs update" would probably mean "new version
available, please run '$VCS update'".

diff --git a/read-cache.c b/read-cache.c
index 2e40a34..3745a48 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -869,7 +869,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
                        }
                        if (quiet)
                                continue;
-                       printf("%s: needs update\n", ce->name);
+                       printf("%s: Changed but not updated\n", ce->name);
                        has_errors = 1;
                        continue;
                }


-- 
Matthieu

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  5:53     ` Junio C Hamano
  2007-10-02  6:41       ` Steven Grimm
  2007-10-02  6:44       ` Steffen Prohaska
@ 2007-10-02 12:52       ` Johannes Schindelin
  2007-10-02 17:00       ` Daniel Barkalow
  3 siblings, 0 replies; 575+ messages in thread
From: Johannes Schindelin @ 2007-10-02 12:52 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Mon, 1 Oct 2007, Junio C Hamano wrote:

> I am not sure the quality of "rsync" transport near the tip, either, but 
> at least the change should not affect other transports.  Nobody should 
> using about rsync transport these days anyway.  Perhaps we should put a 
> deprecation notice in the release notes to 1.5.4, and remove it three 
> months later.

Why not keep it?  It's not like it hurts somebody, and in some 
circumstances (lacking git on the remote side, where it was served via 
http) I found it really convenient.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  6:10               ` David Kastrup
@ 2007-10-02 16:11                 ` Jeff King
  2007-10-02 16:31                   ` David Kastrup
  0 siblings, 1 reply; 575+ messages in thread
From: Jeff King @ 2007-10-02 16:11 UTC (permalink / raw)
  To: David Kastrup; +Cc: git

On Tue, Oct 02, 2007 at 08:10:28AM +0200, David Kastrup wrote:

> I have not actually looked at the actual task that the structures are
> going to be used in, and whether "reusing" the information is likely
> to be worth the trouble.

The algorithm is something like this:  We have N files, and we want to
find "similar" candidates. So we go through each file and generate a
table of fingperint hashes (diffcore-rename.c:hash_chars), and then
compare each file with every other file, using the hash tables to do the
comparison.

So the comparison step for two files is currently something like:

  for each hash in file1
    hash2 = look up hash in file2
    compare hash and hash2

and if they were sorted, perhaps we could do something merge-like:

  while hashes are left to compare
      compare file1.next, file2.next
      advance file1, file2, or both (depending on comparison)

> When we are talking about buzzword compliance, "keep sorted" with the
> meaning of "maintain sorted across modifications" has an O(n^2) or at
> least O(nm) ring to it.  However, if it is possible to sort it just
> once, and then then only merge with other lists...

It would be sort once. I.e.,:

  for each file
     generate file.hashes
     sort file.hashes
  for each file1
    for each file2
      compare file1.hashes to file2.hashes

where that 'compare' step is taking most of the CPU time (for the
obvious reason that we call it in an O(n^2) loop).

I will try to implement this as time permits, but if you want to tinker
with it in the meantime, feel free.

-Peff

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02 16:11                 ` Jeff King
@ 2007-10-02 16:31                   ` David Kastrup
  2007-10-02 17:39                     ` Jeff King
  2007-10-03  2:28                     ` Linus Torvalds
  0 siblings, 2 replies; 575+ messages in thread
From: David Kastrup @ 2007-10-02 16:31 UTC (permalink / raw)
  To: git

Jeff King <peff@peff.net> writes:

> On Tue, Oct 02, 2007 at 08:10:28AM +0200, David Kastrup wrote:

[...]

> The algorithm is something like this: We have N files, and we want
> to find "similar" candidates. So we go through each file and
> generate a table of fingperint hashes
> (diffcore-rename.c:hash_chars), and then compare each file with
> every other file, using the hash tables to do the comparison.
>
> So the comparison step for two files is currently something like:
>
>   for each hash in file1
>     hash2 = look up hash in file2
>     compare hash and hash2
>
> and if they were sorted, perhaps we could do something merge-like:
>
>   while hashes are left to compare
>       compare file1.next, file2.next
>       advance file1, file2, or both (depending on comparison)
>
>> When we are talking about buzzword compliance, "keep sorted" with
>> the meaning of "maintain sorted across modifications" has an O(n^2)
>> or at least O(nm) ring to it.  However, if it is possible to sort
>> it just once, and then then only merge with other lists...
>
> It would be sort once. I.e.,:
>
>   for each file
>      generate file.hashes
>      sort file.hashes
>   for each file1
>     for each file2
>       compare file1.hashes to file2.hashes
>
> where that 'compare' step is taking most of the CPU time (for the
> obvious reason that we call it in an O(n^2) loop).
>
> I will try to implement this as time permits, but if you want to
> tinker with it in the meantime, feel free.

This does not actually require an actual merge _sort_ AFAICS: do the
"sort file.hashed" step using qsort.  The comparison step does not
actually need to produce merged output, but merely advances through
two hash arrays and generates statistics.

This should already beat the pants off the current implementation,
even when the hash array is sparse, simply because our inner loop then
has perfect hash coherence.

Getting rid of this outer O(n^2) remains an interesting challenge,
though.  One way would be the following: fill a _single_ array with
entries containing _both_ hash and file number.  Sort this, and then
gather the statistics of hash runs by making a single pass through.
That reduces the O(n^2) behavior to only those parts with actual hash
collisions.

-- 
David Kastrup

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  5:53     ` Junio C Hamano
                         ` (2 preceding siblings ...)
  2007-10-02 12:52       ` What's cooking in git.git (topics) Johannes Schindelin
@ 2007-10-02 17:00       ` Daniel Barkalow
  3 siblings, 0 replies; 575+ messages in thread
From: Daniel Barkalow @ 2007-10-02 17:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Mon, 1 Oct 2007, Junio C Hamano wrote:

> * db/fetch-pack (Mon Oct 1 00:59:39 2007 +0100) 49 commits
>  + fetch/push: readd rsync support
>  + Introduce remove_dir_recursively()
>  + bundle transport: fix an alloc_ref() call
>  + Allow abbreviations in the first refspec to be merged
>  + Prevent send-pack from segfaulting when a branch doesn't match
>  + Cleanup unnecessary break in remote.c
>  ...
> 
> Has been cooking for quite long time.
> 
> There was a regression that made me quite unhappy about the
> rewrite, but Daniel fixed it, so I should be happy.  There is
> another usability regression: http transport is now totally
> silent.

I think this is due to passing through equal verbosity levels, when the 
non-verbose case for the native protocols was a lot less silent than the 
non-verbose case for http. "git fetch -v -v" does show everything. I think 
just replacing "transport->verbose" with "1" on line 347 of transport.c 
would give the old default behavior, but fetch probably needs a more quiet 
setting than the default, as well as the current more verbose than 
default. I'll put together a patch for this when I get a chance.

> Even when you fetch daily, if the other end frequently
> repacks everything into one big ball of wax like repo.or.cz
> does, you will end up transferring quite a large pack every
> time, and the total lack of progress report is unacceptably
> unnerving.  At least we should reinstate "Fetching blah from URL
> using http", and preferrably "walk $object_name" lines.  The
> latter could be replaced with just series of CR + "walked N
> commits..." if we do not like many output from the current "walk
> $object_name" lines scrolling the other information away.

The right thing for now is probably to match the old git-fetch's behavior, 
once I can remember what it is. (I've been using my C version for my 
personal use long enough that I can't remember everything the shell 
version did. My new version should be sufficiently flexible to accomodate 
most things without too much trouble, but I've lost my ability to notice 
differences without prompting.)

After the implementation change is in, we can look at improving 
user-visible things. I think a display like the "counting objects" display 
(number that counts up in place), plus progress bars for big downloads, would 
be ideal.

> I am not sure the quality of "rsync" transport near the tip,
> either, but at least the change should not affect other
> transports.  Nobody should using about rsync transport these
> days anyway.  Perhaps we should put a deprecation notice in the
> release notes to 1.5.4, and remove it three months later.

I think that rsync should be kept until we've got sftp in place, which 
should cover the same cases and be better overall. 

	-Daniel
*This .sig left intentionally blank*

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02 16:31                   ` David Kastrup
@ 2007-10-02 17:39                     ` Jeff King
  2007-10-02 18:44                       ` David Kastrup
  2007-10-03  2:28                     ` Linus Torvalds
  1 sibling, 1 reply; 575+ messages in thread
From: Jeff King @ 2007-10-02 17:39 UTC (permalink / raw)
  To: David Kastrup; +Cc: git

On Tue, Oct 02, 2007 at 06:31:18PM +0200, David Kastrup wrote:

> This does not actually require an actual merge _sort_ AFAICS: do the
> "sort file.hashed" step using qsort.  The comparison step does not
> actually need to produce merged output, but merely advances through
> two hash arrays and generates statistics.

Right, that's why I used "merge" in quotes. The sort used in the O(n)
step is irrelevant, but we are doing a merge-sort-like behavior in the
second step (except instead of actually merging into a new list, we are
summarizing the comparisons in a numeric "difference" variable). But I
think we are on the same page.

> This should already beat the pants off the current implementation,
> even when the hash array is sparse, simply because our inner loop then
> has perfect hash coherence.

Yes, I hope so. We'll see. :)

> Getting rid of this outer O(n^2) remains an interesting challenge,
> though.  One way would be the following: fill a _single_ array with
> entries containing _both_ hash and file number.  Sort this, and then
> gather the statistics of hash runs by making a single pass through.
> That reduces the O(n^2) behavior to only those parts with actual hash
> collisions.

Interesting. Care to take a stab at implementing it?

-Peff

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02  8:07             ` Matthieu Moy
@ 2007-10-02 17:44               ` Junio C Hamano
  2007-10-03  5:30                 ` [PATCH] rebase: make the warning more useful when the work tree is unclean Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2007-10-02 17:44 UTC (permalink / raw)
  To: Matthieu Moy; +Cc: git, Steffen Prohaska

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> I'd add this to be consistant with "git status". I find the "needs
> update" really short, and especially confusing for centralized systems
> users, for whom "needs update" would probably mean "new version
> available, please run '$VCS update'".

Yeah, and "needs merge" solicits 'SCM merge'.

> diff --git a/read-cache.c b/read-cache.c
> index 2e40a34..3745a48 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -869,7 +869,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
>                         }
>                         if (quiet)
>                                 continue;
> -                       printf("%s: needs update\n", ce->name);
> +                       printf("%s: Changed but not updated\n", ce->name);
>                         has_errors = 1;
>                         continue;
>                 }

I tried to stay away from touching that part on purpose.  Doing
this unconditionally may break people's existing scripts that
use update-index --refresh plumbing.

We could introduce a new option to "update-index --refresh" that
makes the output more machine readable by either NUL terminating
or c_quoting ce->name to protect the caller from potential
spaces and newlines in the name, and use that from the caller.

But for this particular case, I think a much simpler alternative
would be to do it this way:

>  # The tree must be really really clean.
> -git update-index --refresh || exit
> +git update-index -q --refresh || {
+	git status
> +	printf "cannot rebase: the work tree is not clean.\n"
> +	exit 1
> +}
>  diff=$(git diff-index --cached --name-status -r HEAD)
>  case "$diff" in
>  ?*)	echo "cannot rebase: your index is not up-to-date"

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02 17:39                     ` Jeff King
@ 2007-10-02 18:44                       ` David Kastrup
  0 siblings, 0 replies; 575+ messages in thread
From: David Kastrup @ 2007-10-02 18:44 UTC (permalink / raw)
  To: Jeff King; +Cc: git

Jeff King <peff@peff.net> writes:

> On Tue, Oct 02, 2007 at 06:31:18PM +0200, David Kastrup wrote:
>
>> This does not actually require an actual merge _sort_ AFAICS: do the
>> "sort file.hashed" step using qsort.  The comparison step does not
>> actually need to produce merged output, but merely advances through
>> two hash arrays and generates statistics.
>
> Right, that's why I used "merge" in quotes.
>
>> This should already beat the pants off the current implementation,
>> even when the hash array is sparse, simply because our inner loop
>> then has perfect hash coherence.
>
> Yes, I hope so. We'll see. :)
>
>> Getting rid of this outer O(n^2) remains an interesting challenge,
>> though.  One way would be the following: fill a _single_ array with
>> entries containing _both_ hash and file number.  Sort this, and
>> then gather the statistics of hash runs by making a single pass
>> through.  That reduces the O(n^2) behavior to only those parts with
>> actual hash collisions.
>
> Interesting. Care to take a stab at implementing it?

I actually have worked through the last night on the day job, have
urgent stuff piling up in my freelance work queue, and the next thing
I need to finish for git is some smart stuff for delta packing.

So it's unlikely I'll get to _that_ anytime soon.  However, I had a
hilarious idea on the way home that kept me rather amused (perhaps my
programmer's humour is affected by sleep deprivation).

I was annoyed at needing double the space because of having to keep
score of both hash and file number.  So I came up with a rather cute
manner to avoid this: first do all files in isolation with full
precision, but store the resulting list of hash as difference to the
last value.  When merging the data of 2^k and 2^k (or somewhat less)
files, we multiply the values by two (this will not carry except for
utterly improbable cases or very small data sets which we can do
differently) and add one bit of identification.  When we have just a
single sequence remaining, undeltafying will tell us about collisions
in the high bits, and the affected files in the low bits.

Of course, using a merge-like algorithm means that we temporarily need
double space anyway.  Which takes some of the fun.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-02 16:31                   ` David Kastrup
  2007-10-02 17:39                     ` Jeff King
@ 2007-10-03  2:28                     ` Linus Torvalds
  2007-10-03  6:54                       ` Jeff King
                                         ` (2 more replies)
  1 sibling, 3 replies; 575+ messages in thread
From: Linus Torvalds @ 2007-10-03  2:28 UTC (permalink / raw)
  To: David Kastrup, Jeff King; +Cc: Git Mailing List


[ This is the discussed stupid approach - just sort the dang hash array, 
  so that we can use a linear scan over the src/dst ]

On Tue, 2 Oct 2007, David Kastrup wrote:
> 
> This does not actually require an actual merge _sort_ AFAICS: do the
> "sort file.hashed" step using qsort.  The comparison step does not
> actually need to produce merged output, but merely advances through
> two hash arrays and generates statistics.
> 
> This should already beat the pants off the current implementation,
> even when the hash array is sparse, simply because our inner loop then
> has perfect hash coherence.

Sadly, that's not the case. It *does* seem to beat the current 
implementation, but it's not "beat the pants off". It looks like an 
improvement of about 15%, which is nothing to sneeze at, but it's not an 
order-of-magnitude improvement either.

Here's a test-patch. I don't guarantee anything, except that when I did 
the timings I also did a "wc" on the result, and they matched..

Before:
	[torvalds@woody linux]$ time git diff -l0 --stat -C v2.6.22.. | wc
	   7104   28574  438020

	real    0m10.526s
	user    0m10.401s
	sys     0m0.136s

After:
	[torvalds@woody linux]$ time ~/git/git diff -l0 --stat -C v2.6.22.. | wc
	   7104   28574  438020
	
	real    0m8.876s
	user    0m8.761s
	sys     0m0.128s

but the diff is fairly simple, so if somebody will go over it and say 
whether it's likely to be *correct* too, that 15% may well be worth it.

[ Side note, without rename detection, that diff takes just under three 
  seconds for me, so in that sense the improvement to the rename detection 
  itself is larger than the overall 15% - it brings the cost of just 
  rename detection from 7.5s to 5.9s, which would be on the order of just 
  over a 20% performance improvement. ]

Hmm. The patch depends on half-way subtle issues like the fact that the 
hashtables are guaranteed to not be full => we're guaranteed to have zero 
counts at the end => we don't need to do any steenking iterator count in 
the loop. A few comments might in order.

		Linus

---
 diffcore-delta.c |   54 ++++++++++++++++++++++++++++++------------------------
 1 files changed, 30 insertions(+), 24 deletions(-)

diff --git a/diffcore-delta.c b/diffcore-delta.c
index d9729e5..6d65697 100644
--- a/diffcore-delta.c
+++ b/diffcore-delta.c
@@ -46,22 +46,6 @@ struct spanhash_top {
 	struct spanhash data[FLEX_ARRAY];
 };
 
-static struct spanhash *spanhash_find(struct spanhash_top *top,
-				      unsigned int hashval)
-{
-	int sz = 1 << top->alloc_log2;
-	int bucket = hashval & (sz - 1);
-	while (1) {
-		struct spanhash *h = &(top->data[bucket++]);
-		if (!h->cnt)
-			return NULL;
-		if (h->hashval == hashval)
-			return h;
-		if (sz <= bucket)
-			bucket = 0;
-	}
-}
-
 static struct spanhash_top *spanhash_rehash(struct spanhash_top *orig)
 {
 	struct spanhash_top *new;
@@ -122,6 +106,20 @@ static struct spanhash_top *add_spanhash(struct spanhash_top *top,
 	}
 }
 
+static int spanhash_cmp(const void *_a, const void *_b)
+{
+	const struct spanhash *a = _a;
+	const struct spanhash *b = _b;
+
+	/* A count of zero compares at the end.. */
+	if (!a->cnt)
+		return !b->cnt ? 0 : 1;
+	if (!b->cnt)
+		return -1;
+	return a->hashval < b->hashval ? -1 :
+		a->hashval > b->hashval ? 1 : 0;
+}
+
 static struct spanhash_top *hash_chars(struct diff_filespec *one)
 {
 	int i, n;
@@ -158,6 +156,10 @@ static struct spanhash_top *hash_chars(struct diff_filespec *one)
 		n = 0;
 		accum1 = accum2 = 0;
 	}
+	qsort(hash->data,
+		1ul << hash->alloc_log2,
+		sizeof(hash->data[0]),
+		spanhash_cmp);
 	return hash;
 }
 
@@ -169,7 +171,7 @@ int diffcore_count_changes(struct diff_filespec *src,
 			   unsigned long *src_copied,
 			   unsigned long *literal_added)
 {
-	int i, ssz;
+	struct spanhash *s, *d;
 	struct spanhash_top *src_count, *dst_count;
 	unsigned long sc, la;
 
@@ -190,22 +192,26 @@ int diffcore_count_changes(struct diff_filespec *src,
 	}
 	sc = la = 0;
 
-	ssz = 1 << src_count->alloc_log2;
-	for (i = 0; i < ssz; i++) {
-		struct spanhash *s = &(src_count->data[i]);
-		struct spanhash *d;
+	s = src_count->data;
+	d = dst_count->data;
+	for (;;) {
 		unsigned dst_cnt, src_cnt;
 		if (!s->cnt)
-			continue;
+			break;
+		while (d->cnt) {
+			if (d->hashval >= s->hashval)
+				break;
+			d++;
+		}
 		src_cnt = s->cnt;
-		d = spanhash_find(dst_count, s->hashval);
-		dst_cnt = d ? d->cnt : 0;
+		dst_cnt = d->hashval == s->hashval ? d->cnt : 0;
 		if (src_cnt < dst_cnt) {
 			la += dst_cnt - src_cnt;
 			sc += src_cnt;
 		}
 		else
 			sc += dst_cnt;
+		s++;
 	}
 
 	if (!src_count_p)

^ permalink raw reply	[flat|nested] 575+ messages in thread

* [PATCH] rebase: make the warning more useful when the work tree is unclean.
  2007-10-02 17:44               ` Junio C Hamano
@ 2007-10-03  5:30                 ` Junio C Hamano
  2007-10-03  9:02                   ` Matthieu Moy
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2007-10-03  5:30 UTC (permalink / raw)
  To: Matthieu Moy; +Cc: git, Steffen Prohaska

Instead of letting "update-index --refresh" report paths needing
updates and merges, use git-status to give more useful output.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * I won't be a good judge of the updated behaviour, as I never
   start rebase in an unclear tree.  Running git-status in a
   large tree may be too expensive to be worth changing the
   output.

 git-rebase.sh |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index 1583402..93e3b3c 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -254,7 +254,11 @@ else
 fi
 
 # The tree must be really really clean.
-git update-index --refresh || exit
+git update-index -q --refresh || {
+	git status
+	printf "cannot rebase: the work tree is not clean.\n"
+	exit 1
+}
 diff=$(git diff-index --cached --name-status -r HEAD)
 case "$diff" in
 ?*)	echo "cannot rebase: your index is not up-to-date"
-- 
1.5.3.3.1144.gf10f2

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-03  2:28                     ` Linus Torvalds
@ 2007-10-03  6:54                       ` Jeff King
  2007-10-03 16:13                         ` Linus Torvalds
  2007-10-03  8:20                       ` David Kastrup
  2007-10-04  7:10                       ` Junio C Hamano
  2 siblings, 1 reply; 575+ messages in thread
From: Jeff King @ 2007-10-03  6:54 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: David Kastrup, Git Mailing List

On Tue, Oct 02, 2007 at 07:28:19PM -0700, Linus Torvalds wrote:

> Sadly, that's not the case. It *does* seem to beat the current 
> implementation, but it's not "beat the pants off". It looks like an 
> improvement of about 15%, which is nothing to sneeze at, but it's not an 
> order-of-magnitude improvement either.
> 
> Here's a test-patch. I don't guarantee anything, except that when I did 
> the timings I also did a "wc" on the result, and they matched..

I get slightly better speedups with my pathological case (around 30%):

Before:
  $ /usr/bin/time git-diff --raw -M -l0 06d288^ 06d288 >/dev/null
  105.38user 3.65system 2:14.90elapsed 80%CPU (0avgtext+0avgdata 0maxresident)k
  0inputs+0outputs (15432major+542627minor)pagefaults 0swaps

After:
  $ /usr/bin/time git-diff --raw -M -l0 06d288^ 06d288 >/dev/null
  71.70user 3.47system 1:40.43elapsed 74%CPU (0avgtext+0avgdata 0maxresident)k
  0inputs+0outputs (15065major+551778minor)pagefaults 0swaps

But yes, it's not the order of magnitude we were looking for.

> 	[torvalds@woody linux]$ time git diff -l0 --stat -C v2.6.22.. | wc

I found less noise in the timing by using --raw, since the patch
computation takes an appreciable amount of time.

> but the diff is fairly simple, so if somebody will go over it and say 
> whether it's likely to be *correct* too, that 15% may well be worth it.

Patch looks correct, and it produces correct results on my (admittedly
limited) test data.

I think it's worth applying (though I agree that a comment on the
assumption of a zero "cnt" at the end is worth adding) unless some
drastically different solution comes along (e.g., David's idea to try
avoiding the outer O(n^2) loop). But I don't think there is much more to
be gained from a different approach to comparing the two hash tables.

-Peff

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-03  2:28                     ` Linus Torvalds
  2007-10-03  6:54                       ` Jeff King
@ 2007-10-03  8:20                       ` David Kastrup
  2007-10-03 16:59                         ` Jeff King
  2007-10-04  7:10                       ` Junio C Hamano
  2 siblings, 1 reply; 575+ messages in thread
From: David Kastrup @ 2007-10-03  8:20 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Jeff King, Git Mailing List

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

> [ This is the discussed stupid approach - just sort the dang hash array, 
>   so that we can use a linear scan over the src/dst ]
>
> On Tue, 2 Oct 2007, David Kastrup wrote:
>> 
>> This does not actually require an actual merge _sort_ AFAICS: do the
>> "sort file.hashed" step using qsort.  The comparison step does not
>> actually need to produce merged output, but merely advances through
>> two hash arrays and generates statistics.
>> 
>> This should already beat the pants off the current implementation,
>> even when the hash array is sparse, simply because our inner loop then
>> has perfect hash coherence.
>
> Sadly, that's not the case. It *does* seem to beat the current 
> implementation, but it's not "beat the pants off".

Part of the reason is that it is not actually what I had in mind.  Why
create the hash array as a hash array?  Filling the hash array in
basically random order, then sort+compressing it is what is causing
much of the costs.  My idea was to just fill the "hash array"
linearly.  It is quite pointless (and certainly very inefficient with
regard to cache poisoning) to do it in hash order when we are going to
sort it anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: [PATCH] rebase: make the warning more useful when the work tree is unclean.
  2007-10-03  5:30                 ` [PATCH] rebase: make the warning more useful when the work tree is unclean Junio C Hamano
@ 2007-10-03  9:02                   ` Matthieu Moy
  0 siblings, 0 replies; 575+ messages in thread
From: Matthieu Moy @ 2007-10-03  9:02 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Steffen Prohaska

Junio C Hamano <gitster@pobox.com> writes:

> Instead of letting "update-index --refresh" report paths needing
> updates and merges, use git-status to give more useful output.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
>  * I won't be a good judge of the updated behaviour, as I never
>    start rebase in an unclear tree.  Running git-status in a
>    large tree may be too expensive to be worth changing the
>    output.

I see your patch as an improvement too. status is a bit expansive, but
you hit this portion of code only when trying "rebase" by mistake, so
it's acceptable to let git take a bit of time to explain your mistake.

That said, I think it's still worth making the messages of
"update-index" a little more verbose and consistant with "status" (my
previous patch), since I think there are other occurences of
user-visible output of update-index in porcelain git.

Ideally, update-index would be a C function returning a struct
containing all the information about the status, with a function
is_clean(...) and another print_as_status(...), to allow the same
functionality with better performances, but I won't have time to do
this.

-- 
Matthieu

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-03  6:54                       ` Jeff King
@ 2007-10-03 16:13                         ` Linus Torvalds
  0 siblings, 0 replies; 575+ messages in thread
From: Linus Torvalds @ 2007-10-03 16:13 UTC (permalink / raw)
  To: Jeff King; +Cc: David Kastrup, Git Mailing List



On Wed, 3 Oct 2007, Jeff King wrote:
> 
> I get slightly better speedups with my pathological case (around 30%):

Ok, 30% is definitely "worth doing". Even if your performance still sucks, 
and 71 seconds is just way out of line for anything like this (of course, 
these days you need that "-l0" to ever trigger that case, but it would be 
nice if we could speed things up so much that we no longer care).

		Linus

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-03  8:20                       ` David Kastrup
@ 2007-10-03 16:59                         ` Jeff King
  2007-10-03 17:53                           ` Linus Torvalds
  0 siblings, 1 reply; 575+ messages in thread
From: Jeff King @ 2007-10-03 16:59 UTC (permalink / raw)
  To: David Kastrup; +Cc: Linus Torvalds, Git Mailing List

On Wed, Oct 03, 2007 at 10:20:49AM +0200, David Kastrup wrote:

> Part of the reason is that it is not actually what I had in mind.  Why
> create the hash array as a hash array?  Filling the hash array in
> basically random order, then sort+compressing it is what is causing
> much of the costs.  My idea was to just fill the "hash array"
> linearly.  It is quite pointless (and certainly very inefficient with
> regard to cache poisoning) to do it in hash order when we are going to
> sort it anyway.

Try profiling the code, and you will see that the creation of the hashes
is totally dwarfed by the comparisons. So yes, you might be able to
speed up the creation code, but it's going to have a minimal impact on
the overall run time.

-Peff

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-03 16:59                         ` Jeff King
@ 2007-10-03 17:53                           ` Linus Torvalds
  2007-10-03 18:09                             ` David Kastrup
  0 siblings, 1 reply; 575+ messages in thread
From: Linus Torvalds @ 2007-10-03 17:53 UTC (permalink / raw)
  To: Jeff King; +Cc: David Kastrup, Git Mailing List



On Wed, 3 Oct 2007, Jeff King wrote:
>
> Try profiling the code, and you will see that the creation of the hashes
> is totally dwarfed by the comparisons. So yes, you might be able to
> speed up the creation code, but it's going to have a minimal impact on
> the overall run time.

Yeah. Oprofile is your friend.

The biggest win would be to avoid calling diffcore_count_changes() in the 
first place, and we actually do that in the caller by looking at the size 
of the files. However, while that prunes out the *really* obvious cases, 
it's not nearly enough, since there tends to be very limited filesizes 
anyway.

What we could also do is to pass in the minimum similarity score, and use 
that to at least exit early. We currently pass in "delta_limit" which is 
close, but we never use it, and we really probably would be better off 
passing in the minimum score itself and perhaps be able to exit early from 
diffcore_count_changes.

However, while I did think about doing that, I came to the conclusion that 
we'd still always end up having to look at least at *half* the hash data 
(for the default 50% score), so while it would help, it again wouldn't be 
a matter of orders-of-magnitudes, and it looked like the end result would 
be unnecessarily complex too.

The best option, of course, would be to use a similarity hash to make the 
initial choice. I think we had one at one point, but it wasn't 
fine-grained enough. But it might be interesting to do that as a filter in 
*front* of the more expensive diffcore_count_changes() call.

We had some "similarity fingerprint" code at some point using a Rabin 
polynomial. It wasn't reliable enough to be used as a direct score, but 
maybe it can be used as a first-line "we know this isn't even worth doing 
the expensive stuff on".

			Linus

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-03 17:53                           ` Linus Torvalds
@ 2007-10-03 18:09                             ` David Kastrup
  0 siblings, 0 replies; 575+ messages in thread
From: David Kastrup @ 2007-10-03 18:09 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Jeff King, Git Mailing List

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

> On Wed, 3 Oct 2007, Jeff King wrote:
>>
>> Try profiling the code, and you will see that the creation of the hashes
>> is totally dwarfed by the comparisons. So yes, you might be able to
>> speed up the creation code, but it's going to have a minimal impact on
>> the overall run time.
>
> Yeah. Oprofile is your friend.

Well, and if -Oprofile has no strong opinion, I'd let wc -l pitch in.

When we are not actually going to use the hash tables as hash tables,
why create them as such?  If the first thing that actually looks at
the values of the hashes (except possibly for the optimization of not
storing the same hash twice in succession) is the sort, then there is
no code that can go out of whack when confronted with degenerate data.

Maybe it's not much of an optimization, but it certainly should be a
cleanup.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2007-10-03  2:28                     ` Linus Torvalds
  2007-10-03  6:54                       ` Jeff King
  2007-10-03  8:20                       ` David Kastrup
@ 2007-10-04  7:10                       ` Junio C Hamano
  2 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2007-10-04  7:10 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: David Kastrup, Jeff King, Git Mailing List

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

> Hmm. The patch depends on half-way subtle issues like the fact that the 
> hashtables are guaranteed to not be full => we're guaranteed to have zero 
> counts at the end => we don't need to do any steenking iterator count in 
> the loop. A few comments might in order.

The patch actually is quite readable.  That double-loop finding
the matching hashval in destination hash was simply silly to
begin with, so even if this is not "orders of magnitude"
improvement, I think your patch is worth doing.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2010-12-14  7:23                                                                             ` Johannes Sixt
@ 2010-12-14 14:21                                                                               ` Yaroslav Halchenko
  0 siblings, 0 replies; 575+ messages in thread
From: Yaroslav Halchenko @ 2010-12-14 14:21 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: Junio C Hamano, git


On Tue, 14 Dec 2010, Johannes Sixt wrote:
> > hm -- read-tree sounded like yet another unknown to me feature of GIT I
> > was trying desperately to discover ;)  unfortunately it doesn't produce a merge
> > for me :-/ -- just a simple commit with the state taken from the other tree:
> How about:
>   git merge --no-commit -s ours 0.2
>   git read-tree -m -u 0.2
>   git commit -m "Reset to 0.2"

Thank you Johannes for chewing it up to ease the digestion by my
brainless stomach -- works just fine ;)

I guess this could be the alias for my needs:

    mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u "$1"' -

but since it might be a generic pattern for the use case(s) I have
stated I still see no objective reason why simple '-s theirs' should not
be there.

-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2010-12-13 21:46                                                                           ` Yaroslav Halchenko
  2010-12-13 22:15                                                                             ` Junio C Hamano
@ 2010-12-14  7:23                                                                             ` Johannes Sixt
  2010-12-14 14:21                                                                               ` Yaroslav Halchenko
  1 sibling, 1 reply; 575+ messages in thread
From: Johannes Sixt @ 2010-12-14  7:23 UTC (permalink / raw)
  To: Yaroslav Halchenko; +Cc: Junio C Hamano, git

Am 12/13/2010 22:46, schrieb Yaroslav Halchenko:
> On Mon, 13 Dec 2010, Junio C Hamano wrote:
>> But for such a use case, "git read-tree -m -u 0.2" would work just as
>> well, and discussion ended there ;-)
> 
> hm -- read-tree sounded like yet another unknown to me feature of GIT I
> was trying desperately to discover ;)  unfortunately it doesn't produce a merge
> for me :-/ -- just a simple commit with the state taken from the other tree:

How about:

  git merge --no-commit -s ours 0.2
  git read-tree -m -u 0.2
  git commit -m "Reset to 0.2"

-- Hannes

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2010-12-13 22:15                                                                             ` Junio C Hamano
@ 2010-12-13 22:36                                                                               ` Yaroslav Halchenko
  0 siblings, 0 replies; 575+ messages in thread
From: Yaroslav Halchenko @ 2010-12-13 22:36 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git


On Mon, 13 Dec 2010, Junio C Hamano wrote:
> > hm -- read-tree sounded like yet another unknown to me feature of GIT I
> > was trying desperately to discover ;)  unfortunately it doesn't produce a merge
> > for me

> Didn't I already say it makes sense only with --no-commit?  IOW to shape
> the tree.

rright -- in my case --no-commit so I could remove the content before
committing.

> And in your use case I do not think you would even want to have a merge.
> Even if you run "git rm" to remove non-free stuff from the merge result,
> if you merged the history of 0.2 that contains non-free stuff you are not
> allowed to distribute (forbidden either by upstream or self-imposed dfsg,
> the reason does not matter), people who gets the merge commit can follow
> its second parent to grab the non-free stuff, no?

I see your point better now -- so it is yet another dimension of
"the feature".

as for non-free -- I probably should have been more precise --
non-DFSG (debian free software guidelines)-free ;) i.e.:

*  free compiled,rendered materials, often binary blobs, without
   sources (e.g. .dll's, pdfs etc)

*  material under free but not DFSG-free licenses, etc

* if upstream repository already provides that 'non-free' material it
  would not be much of my misdemeanor to keep them as well buried in the
  repository history.  What I care is to have a cleaned branch from
  which I could git archive, and also which I could inspect in regards to
  changes between releases without visually filtering all changes in
  non-sources (e.g. those binary blobs) or irrelevant content.

  if ever legal situation causes upstream to rewrite history to remove
  them -- I will have to do that as well anyways :-/

Having an actual merge would be useful for making the explicit "bridge"
from upstream branch, thus '--no-commit -s theirs' with consecutive
cleaning before commit looks the way to go IMHO.  But I see now
that I could possibly use read-tree at times if a real necessity comes
to prune non-distributable content, and then obviously I do not want to
drag upstream's illegal stuff along.

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2010-12-13 21:46                                                                           ` Yaroslav Halchenko
@ 2010-12-13 22:15                                                                             ` Junio C Hamano
  2010-12-13 22:36                                                                               ` Yaroslav Halchenko
  2010-12-14  7:23                                                                             ` Johannes Sixt
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2010-12-13 22:15 UTC (permalink / raw)
  To: Yaroslav Halchenko; +Cc: git

Yaroslav Halchenko <debian@onerussian.com> writes:

> On Mon, 13 Dec 2010, Junio C Hamano wrote:
>> would make sense only if used with --no-commit.
>
>> But for such a use case, "git read-tree -m -u 0.2" would work just as
>> well, and discussion ended there ;-)
>
> hm -- read-tree sounded like yet another unknown to me feature of GIT I
> was trying desperately to discover ;)  unfortunately it doesn't produce a merge
> for me

Didn't I already say it makes sense only with --no-commit?  IOW to shape
the tree.

And in your use case I do not think you would even want to have a merge.
Even if you run "git rm" to remove non-free stuff from the merge result,
if you merged the history of 0.2 that contains non-free stuff you are not
allowed to distribute (forbidden either by upstream or self-imposed dfsg,
the reason does not matter), people who gets the merge commit can follow
its second parent to grab the non-free stuff, no?

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2010-12-13 20:46                                                                         ` Junio C Hamano
@ 2010-12-13 21:46                                                                           ` Yaroslav Halchenko
  2010-12-13 22:15                                                                             ` Junio C Hamano
  2010-12-14  7:23                                                                             ` Johannes Sixt
  0 siblings, 2 replies; 575+ messages in thread
From: Yaroslav Halchenko @ 2010-12-13 21:46 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]


On Mon, 13 Dec 2010, Junio C Hamano wrote:
> would make sense only if used with --no-commit.

> But for such a use case, "git read-tree -m -u 0.2" would work just as
> well, and discussion ended there ;-)

hm -- read-tree sounded like yet another unknown to me feature of GIT I
was trying desperately to discover ;)  unfortunately it doesn't produce a merge
for me :-/ -- just a simple commit with the state taken from the other tree:

$> git read-tree -m -u origin/master                 
cached/staged changes: 179 changes  

$> git commit -m 'blunt merge for -s theirs: -m -u origin/master '
[maint/0.5 b246251] blunt merge for -s theirs: -m -u origin/master
 175 files changed, 9589 insertions(+), 4914 deletions(-)
 create mode 100644 doc/pics/ex_curvefitting_bold.svg
 create mode 100644 doc/pics/ex_curvefitting_searchlight.svg
 ...
$> git show HEAD^2                                                
fatal: ambiguous argument 'HEAD^2': unknown revision or path not in the working tree.

I am using git (Debian amd64): 1:1.7.2.3-2.1 (so it is 1.7.2.3)

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2010-12-13 19:09                                                                       ` Yaroslav Halchenko
@ 2010-12-13 20:46                                                                         ` Junio C Hamano
  2010-12-13 21:46                                                                           ` Yaroslav Halchenko
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2010-12-13 20:46 UTC (permalink / raw)
  To: Yaroslav Halchenko; +Cc: git

Yaroslav Halchenko <debian@onerussian.com> writes:

> git checkout dfsg
> git merge --no-commit -s theirs 0.2
> # after all I do not, and must not have my modifications
> git rm -rf non-free-1 ... # probably would be scripted
> git commit

The other day I was talking with Shawn Pearce and said that "-s theirs"
would make sense only if used with --no-commit.

But for such a use case, "git read-tree -m -u 0.2" would work just as
well, and discussion ended there ;-)

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-18  9:58                                                                     ` Junio C Hamano
@ 2010-12-13 19:09                                                                       ` Yaroslav Halchenko
  2010-12-13 20:46                                                                         ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Yaroslav Halchenko @ 2010-12-13 19:09 UTC (permalink / raw)
  To: git

Dear Everyone,

> I tried not to sound too negative when describing -Xours and -Xtheirs
> there, but actually I think "-s theirs" is even worse.  It is how you
> would discard what you did (perhaps because the other side has much better
> solution than your hack)

or perhaps this is very well intended, e.g. if you are tracking other project's
development and just need to carry a limited portion of the source tree.

Sorry for reincarnating this old thread, but  since I have filed Debian
wishlist bug against GIT for '-s theirs':

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581680

and this thread is linked to it as the ultimate source 'why not (yet)', I want
to describe a usecase when/why I wanted to have -s theirs:

For debian packaging, we often need to clean up the upstream source tree so it
does not contain non-free material (binary blobs, components under non-free
licenses, etc).  If I want to setup all packaging within GIT, I would follow
natively following setup:

git checkout -b dfsg 0.1
git rm non-free-1 non-free-2 ...
git commit -m "DFSG-compliant 0.1"
git tag -a -m 0.1.dfsg

and base my packaging off dfsg branch (in a separate branch, e.g. debian).

Upon release 0.2 of upstream work, in the simplest case, I can do now

git checkout dfsg
git merge 0.2

and there things could get hairy -- if files were modified upstream, I get
conflicts, so I would need to git rm files again, and only then commit the
merge:

git rm 

Moreover, 0.2 might not follow 0.1 -- upstream might release off
"release-branches", then I simply *must not* do "git merge" with recursive 
strategy.

Moreover, if some material finally became free, I would need to re-add it
somehow into dfsg branch from 0.2 branch.


*All* those complications could easily be avoided if I only had '-s theirs'.
Then I simply

git checkout dfsg
git merge --no-commit -s theirs 0.2
# after all I do not, and must not have my modifications
git rm -rf non-free-1 ... # probably would be scripted
git commit

With -s theirs now I would be able manage all tricky cases above without hassle
in a unified way.

Would it be possible to have GIT people reconsider addition of '-s theirs'?

Thank you in advance for your time!

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-20 22:58                                                                                       ` Sverre Rabbelier
@ 2008-07-21  8:47                                                                                         ` Jakub Narebski
  0 siblings, 0 replies; 575+ messages in thread
From: Jakub Narebski @ 2008-07-21  8:47 UTC (permalink / raw)
  To: Sverre Rabbelier
  Cc: Miklos Vajna, Junio C Hamano, Johannes Schindelin, Nanako Shiraishi, git

"Sverre Rabbelier" <alturin@gmail.com> writes:

> On Sun, Jul 20, 2008 at 10:33 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
>>> Whatever happened to quotes?
>>>
>>>         $ git merge -s subtree -Xpath="git-gui git-gui/master"
>>
>> Read again what did you wrote. ;-)
>>
>> The current form is
>>
>> git merge -s subtree git-gui/master, so at most it could be
>>
>>        $ git merge -s subtree -Xpath="git-gui" git-gui/master
> 
> Meh, what I of course mean was:
>          $ git merge -s subtree -X"path=git-gui" git-gui/master
> 
> But that looks rather awkward, which is probably why I typed it the
> way I did? Maybe something like....
>          $ git merge -s subtree -X(--path=git-gui --foo=bar) git-gui/master

Or perhaps (following -Wx family of GCC options)

           $ git merge -s subtree -X--path=git-gui,--foo=bar git-gui/master

-- 
Jakub Narebski
Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-20 22:40                                                                 ` Petr Baudis
@ 2008-07-20 23:04                                                                   ` Junio C Hamano
  0 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-07-20 23:04 UTC (permalink / raw)
  To: Petr Baudis; +Cc: git

Petr Baudis <pasky@suse.cz> writes:

> Do you think this would create serious problems?
>
> One thing this patch series depends on now is changing the git mv
> semantics in a rather non-trivial way, which is something we might want
> to do in a major release instead of within the 1.6 series.

The change to git-mv perhaps is necessary to happen between a major
release boundary.  I do not know if the current round of patch to do so
will become ready in time for 1.6.0.  The rename-ce-at patch I looked at
did not look like it was.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-20 20:33                                                                                     ` Miklos Vajna
@ 2008-07-20 22:58                                                                                       ` Sverre Rabbelier
  2008-07-21  8:47                                                                                         ` Jakub Narebski
  0 siblings, 1 reply; 575+ messages in thread
From: Sverre Rabbelier @ 2008-07-20 22:58 UTC (permalink / raw)
  To: Miklos Vajna; +Cc: Junio C Hamano, Johannes Schindelin, Nanako Shiraishi, git

On Sun, Jul 20, 2008 at 10:33 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
>> Whatever happened to quotes?
>>
>>         $ git merge -s subtree -Xpath="git-gui git-gui/master"
>
> Read again what did you wrote. ;-)
>
> The current form is
>
> git merge -s subtree git-gui/master, so at most it could be
>
>        $ git merge -s subtree -Xpath="git-gui" git-gui/master

Meh, what I ofcourse mean was:
         $ git merge -s subtree -X"path=git-gui" git-gui/master

But that looks rather awkward, which is probably why I typed it the
way I did? Maybe something like....
         $ git merge -s subtree -X(--path=git-gui --foo=bar) git-gui/master

-- 
Cheers,

Sverre Rabbelier

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-20  1:58                                                               ` Junio C Hamano
@ 2008-07-20 22:40                                                                 ` Petr Baudis
  2008-07-20 23:04                                                                   ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Petr Baudis @ 2008-07-20 22:40 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sat, Jul 19, 2008 at 06:58:55PM -0700, Junio C Hamano wrote:
> * pb/submodule (Wed Jul 16 21:11:40 2008 +0200) 7 commits
>  . t7403: Submodule git mv, git rm testsuite
>  . git rm: Support for removing submodules
>  . git mv: Support moving submodules
>  . submodule.*: Introduce simple C interface for submodule lookup by
>    path
>  . git submodule add: Fix naming clash handling
>  . t7400: Add short "git submodule add" testsuite
>  . git-mv: Remove dead code branch
> 
> Long overdue usability improvement series for submodule.  Very much
> welcomed.  It would be nice to have some submodule improvements in 1.6.0,
> but it would take us a few more rounds to hit 'next' with this, and it
> will not be in 'master' when 1.6.0 ships.

Do you think this would create serious problems?

One thing this patch series depends on now is changing the git mv
semantics in a rather non-trivial way, which is something we might want
to do in a major release instead of within the 1.6 series.

				Petr "Pasky" Baudis

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-20 19:58                                                                                 ` Junio C Hamano
  2008-07-20 20:03                                                                                   ` Sverre Rabbelier
@ 2008-07-20 22:24                                                                                   ` Johannes Schindelin
  1 sibling, 0 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-07-20 22:24 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Miklos Vajna, Nanako Shiraishi, git

Hi,

On Sun, 20 Jul 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> I personally think -sstrategy=string1,string2,... is simply a bad taste.
> >> 
> >> Why force yourself to parse things by having the users to concatenate
> >> something that the user could give us separated?  If you care about the
> >> order and association between strategy and their options, you can always
> >> do:
> >> 
> >> 	-s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
> >> 	-s strategy2 -X option-1-for-strategy-2 ...
> >
> > You mean something like
> >
> > 	$ git merge -s subtree -X --path -X git-gui/ git-gui/master
> >
> > Wow. :-)
> 
> I would envision it to be more like:
> 
> 	$ git merge -s subtree -Xpath=git-gui git-gui/master
> 
> which git-merge internally would turn into:
> 
> 	$ git-merge-subtree --path=git-gui HEAD -- OURS THEIRS
> 
> That way both the external command line (that the end users do care about)
> and the internal one (that the strategy programmer would care about) look
> a lot more sensible than your command line, don't they?

I still find it a lot easier to explain

	$ git -s subtree=git-gui git-gui/master

to a new user than your command line, especially since

	$ git -X path=git-gui -s subtree git-gui/master

would be a not so obvious mistake, _and_ especially since the 
implementation of your option parsing would be rather ugly.

But the subject has been discussed to death, and you seem to still prefer 
the -X way, so I give up.

You win,
Dscho "who can adapt even to a syntax he does not like"

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-20 20:03                                                                                   ` Sverre Rabbelier
  2008-07-20 20:33                                                                                     ` Miklos Vajna
@ 2008-07-20 20:33                                                                                     ` Junio C Hamano
  1 sibling, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-07-20 20:33 UTC (permalink / raw)
  To: sverre
  Cc: Junio C Hamano, Johannes Schindelin, Miklos Vajna, Nanako Shiraishi, git

"Sverre Rabbelier" <alturin@gmail.com> writes:

> Whatever happened to quotes?
>
>         $ git merge -s subtree -Xpath="git-gui git-gui/master"

Nothing special needs to happen.  That would naturally be passed to the
underlying strategy as the equivalent of:

	$ git merge-subtree --path="git-gui git-gui/master"

but now "git-merge" is in C, it does not have to quote nor unquote
explicitly itself.  Unquoting will be done by the shell when you call
"git-merge", and quoting is unneeded when you give each argument as a
separate string in **argv to call execv().

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-20 20:03                                                                                   ` Sverre Rabbelier
@ 2008-07-20 20:33                                                                                     ` Miklos Vajna
  2008-07-20 22:58                                                                                       ` Sverre Rabbelier
  2008-07-20 20:33                                                                                     ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Miklos Vajna @ 2008-07-20 20:33 UTC (permalink / raw)
  To: sverre; +Cc: Junio C Hamano, Johannes Schindelin, Nanako Shiraishi, git

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
> On Sun, Jul 20, 2008 at 9:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> You mean something like
> >>
> >>       $ git merge -s subtree -X --path -X git-gui/ git-gui/master
> >>
> >> Wow. :-)
> >
> > I would envision it to be more like:
> >
> >        $ git merge -s subtree -Xpath=git-gui git-gui/master
> 
> Whatever happened to quotes?
> 
>         $ git merge -s subtree -Xpath="git-gui git-gui/master"

Read again what did you wrote. ;-)

The current form is

git merge -s subtree git-gui/master, so at most it could be

        $ git merge -s subtree -Xpath="git-gui" git-gui/master

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-20 19:58                                                                                 ` Junio C Hamano
@ 2008-07-20 20:03                                                                                   ` Sverre Rabbelier
  2008-07-20 20:33                                                                                     ` Miklos Vajna
  2008-07-20 20:33                                                                                     ` Junio C Hamano
  2008-07-20 22:24                                                                                   ` Johannes Schindelin
  1 sibling, 2 replies; 575+ messages in thread
From: Sverre Rabbelier @ 2008-07-20 20:03 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Schindelin, Miklos Vajna, Nanako Shiraishi, git

On Sun, Jul 20, 2008 at 9:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> You mean something like
>>
>>       $ git merge -s subtree -X --path -X git-gui/ git-gui/master
>>
>> Wow. :-)
>
> I would envision it to be more like:
>
>        $ git merge -s subtree -Xpath=git-gui git-gui/master

Whatever happened to quotes?

        $ git merge -s subtree -Xpath="git-gui git-gui/master"

-- 
Cheers,

Sverre Rabbelier

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-20 19:07                                                                               ` Johannes Schindelin
@ 2008-07-20 19:58                                                                                 ` Junio C Hamano
  2008-07-20 20:03                                                                                   ` Sverre Rabbelier
  2008-07-20 22:24                                                                                   ` Johannes Schindelin
  0 siblings, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-07-20 19:58 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Miklos Vajna, Nanako Shiraishi, git

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

>> I personally think -sstrategy=string1,string2,... is simply a bad taste.
>> 
>> Why force yourself to parse things by having the users to concatenate
>> something that the user could give us separated?  If you care about the
>> order and association between strategy and their options, you can always
>> do:
>> 
>> 	-s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
>> 	-s strategy2 -X option-1-for-strategy-2 ...
>
> You mean something like
>
> 	$ git merge -s subtree -X --path -X git-gui/ git-gui/master
>
> Wow. :-)

I would envision it to be more like:

	$ git merge -s subtree -Xpath=git-gui git-gui/master

which git-merge internally would turn into:

	$ git-merge-subtree --path=git-gui HEAD -- OURS THEIRS

That way both the external command line (that the end users do care about)
and the internal one (that the strategy programmer would care about) look
a lot more sensible than your command line, don't they?

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-20 18:27                                                                             ` Junio C Hamano
@ 2008-07-20 19:07                                                                               ` Johannes Schindelin
  2008-07-20 19:58                                                                                 ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Johannes Schindelin @ 2008-07-20 19:07 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Miklos Vajna, Nanako Shiraishi, git

Hi,

On Sun, 20 Jul 2008, Junio C Hamano wrote:

> Miklos Vajna <vmiklos@frugalware.org> writes:
> 
> > Third, it would be nice to allow passing extra parameter(s) to the
> > backends, but I do not know what concept is the best here. The
> > strategy1=foo,stategy2=bar limits the input to a single string. Is that
> > enough? Given that recursive=theirs was considered harmful, we don't
> > have too much examples;...
> 
> I personally think -sstrategy=string1,string2,... is simply a bad taste.
> 
> Why force yourself to parse things by having the users to concatenate
> something that the user could give us separated?  If you care about the
> order and association between strategy and their options, you can always
> do:
> 
> 	-s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
> 	-s strategy2 -X option-1-for-strategy-2 ...

You mean something like

	$ git merge -s subtree -X --path -X git-gui/ git-gui/master

Wow. :-)

Speechless,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-20 13:04                                                                           ` Miklos Vajna
  2008-07-20 13:16                                                                             ` Johannes Schindelin
@ 2008-07-20 18:27                                                                             ` Junio C Hamano
  2008-07-20 19:07                                                                               ` Johannes Schindelin
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-07-20 18:27 UTC (permalink / raw)
  To: Miklos Vajna; +Cc: Johannes Schindelin, Nanako Shiraishi, git

Miklos Vajna <vmiklos@frugalware.org> writes:

> Third, it would be nice to allow passing extra parameter(s) to the
> backends, but I do not know what concept is the best here. The
> strategy1=foo,stategy2=bar limits the input to a single string. Is that
> enough? Given that recursive=theirs was considered harmful, we don't
> have too much examples;...

I personally think -sstrategy=string1,string2,... is simply a bad taste.

Why force yourself to parse things by having the users to concatenate
something that the user could give us separated?  If you care about the
order and association between strategy and their options, you can always
do:

	-s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
	-s strategy2 -X option-1-for-strategy-2 ...

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-20 13:04                                                                           ` Miklos Vajna
@ 2008-07-20 13:16                                                                             ` Johannes Schindelin
  2008-07-20 18:27                                                                             ` Junio C Hamano
  1 sibling, 0 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-07-20 13:16 UTC (permalink / raw)
  To: Miklos Vajna; +Cc: Junio C Hamano, Nanako Shiraishi, git

Hi,

On Sun, 20 Jul 2008, Miklos Vajna wrote:

> First, currently you can specify multiple strategies in the config
> (pull.twohead, pull.octopus) using a space separated list.

Oh, I did not mean to change that.  I just misremembered.

> Second, we could allow custom strategies, as we started to discuss here:
> 
> http://thread.gmane.org/gmane.comp.version-control.git/86584/focus=87684

In my opinion, this would make it easier for interested parties to start 
implementing that blame-based merge strategy I mentioned.

> Third, it would be nice to allow passing extra parameter(s) to the
> backends, but I do not know what concept is the best here. The
> strategy1=foo,stategy2=bar limits the input to a single string. Is that
> enough? Given that recursive=theirs was considered harmful, we don't
> have too much examples; for subtree the only parameter I could think of
> is the path, so a string there is enough.
> 
> However, further strategies, like blame, could take more parameters,
> like git blame -C<num> -M<othernum>. Or do I just overcomplicate it? ;-)

The common solution is like with gcc's -Wl option, which translates 
commata into spaces, like so: "-Wl,--machine,i386" is added as "--machine 
i386" to the linker command line.

Our own cvsimport implements the same principle:

	$ git cvsimport -p -b,HEAD

will only update the main branch.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-19 11:19                                                                         ` Johannes Schindelin
  2008-07-19 16:55                                                                           ` Junio C Hamano
@ 2008-07-20 13:04                                                                           ` Miklos Vajna
  2008-07-20 13:16                                                                             ` Johannes Schindelin
  2008-07-20 18:27                                                                             ` Junio C Hamano
  1 sibling, 2 replies; 575+ messages in thread
From: Miklos Vajna @ 2008-07-20 13:04 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, Nanako Shiraishi, git

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

On Sat, Jul 19, 2008 at 01:19:46PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So I still feel that "-s subtree=<blabla>,recursive=theirs" would be a 
> viable way to go.  And more intuitive than "-X".
> 
> I'll just ask Miklos what he thinks of the idea, and to write the patch if 
> he likes it, once he's back from the saddle. :-)

I think there are three steps here.

First, currently you can specify multiple strategies in the config
(pull.twohead, pull.octopus) using a space separated list. If we want to
change it to a coma-separated list, should we care about backwards
compatibility? There are tests for this, but it's undocumented (and my
patch to document it was rejected, saying we should not encourage people
to use it).

Second, we could allow custom strategies, as we started to discuss here:

http://thread.gmane.org/gmane.comp.version-control.git/86584/focus=87684

Third, it would be nice to allow passing extra parameter(s) to the
backends, but I do not know what concept is the best here. The
strategy1=foo,stategy2=bar limits the input to a single string. Is that
enough? Given that recursive=theirs was considered harmful, we don't
have too much examples; for subtree the only parameter I could think of
is the path, so a string there is enough.

However, further strategies, like blame, could take more parameters,
like git blame -C<num> -M<othernum>. Or do I just overcomplicate it? ;-)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-18  8:50                                                               ` Nanako Shiraishi
                                                                                   ` (2 preceding siblings ...)
  2008-07-18 11:56                                                                 ` Johannes Schindelin
@ 2008-07-20 10:20                                                                 ` Nanako Shiraishi
  3 siblings, 0 replies; 575+ messages in thread
From: Nanako Shiraishi @ 2008-07-20 10:20 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git

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

> On Fri, 18 Jul 2008, Nanako Shiraishi wrote:
>
>> Quoting Junio C Hamano <gitster@pobox.com>:
>> > This needs to be merged to master iff/when merge-theirs gets merged, 
>> > but I do not think this series is widely supported, so both are on 
>> > hold.
>> 
>> Why do you say it is not widely supported?  I may be wrong but I think 
>> you developed these patches after somebody from the mailing list asked 
>> for this feature.
>
> Asking for a feature, and then not doing a single thing to defend why it 
> makes sense, of a single person, who does not even speak up now, does not 
> count for "wide support".

For the record, I was not the one who asked for such a feature.

It seems that the conclusion of the discussion is that "theirs" promotes a bad workflow, and I am happy with that.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-07-17  8:08                                                             ` Junio C Hamano
  2008-07-17 13:09                                                               ` Stephan Beyer
  2008-07-18  8:50                                                               ` Nanako Shiraishi
@ 2008-07-20  1:58                                                               ` Junio C Hamano
  2008-07-20 22:40                                                                 ` Petr Baudis
  2 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-07-20  1:58 UTC (permalink / raw)
  To: git

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.  The topics
meant to be merged to the maintenance series have "maint-" in their names.

Due to increased activity level from people including GSoC students, I
expect 'next' to stay somewhat more active than previous rounds during the
1.6.0-rc cycle.  The request for people who usually follow 'next' is the
same as usual, though.  After -rc1 is tagged, please run 'master' for your
daily git use instead, in order to make sure 'master' does what it claims
to do without regression.

Tentative schedule, my wishful thinking:

 - 1.6.0-rc0 (Jul 20)
 - 1.6.0-rc1 (Jul 23)
 - 1.6.0-rc2 (Jul 30)
 - 1.6.0-rc3 (Aug  6)
 - 1.6.0     (Aug 10)

No real activity on 'next', as I was busy tending bugfixes and pushing out
v1.5.6.4 today.

----------------------------------------------------------------
[Will merge to "master" soon]

* ns/am-abort (Wed Jul 16 19:39:10 2008 +0900) 1 commit
 + git am --abort

This one is for Ted; builds on top of the recent "am and rebase leaves
ORIG_HEAD just like reset, merge and pull does" rather nicely.

* jc/rerere-auto-more (Wed Jul 16 20:25:18 2008 -0700) 1 commit
 + rerere.autoupdate: change the message when autoupdate is in effect

This one is for Ingo.

This changes the message rerere issues after reusing previous conflict
resolution from "Resolved" to "Staged" when autoupdate option is in
effect.

It is envisioned that in practice, some auto resolutions are trickier and
iffier than others, and we would want to add a feature to mark individual
resolutions as "this is ok to autoupdate" or "do not autoupdate the result
using this resolution even when rerere.autoupdate is in effect" in the
future.  When that happens, these messages will make the distinction
clearer.

* ap/trackinfo (Wed Jul 16 15:19:27 2008 -0400) 1 commit
 + Reword "your branch has diverged..." lines to reduce line length

----------------------------------------------------------------
[Stalled/Needs more work]

* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
 - Documentation: Improve documentation for git-imap-send(1)
 - imap-send.c: more style fixes
 - imap-send.c: style fixes
 - git-imap-send: Support SSL
 - git-imap-send: Allow the program to be run from subdirectories of
   a git tree

I said: "Some people seem to prefer having this feature available also
with gnutls.  If such a patch materializes soon, that would be good, but
otherwise I'll merge this as-is to 'next'.  Such an enhancement can be
done in-tree on top of this series."  Anybody?

* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
 . cherry: cache patch-ids to avoid repeating work

The discussion suggested that the value of having the cache itself is
iffy, but I should pick up the updated one and look at it.

* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
 . gitweb: use new Git::Repo API, and add optional caching
 . Add new Git::Repo API
 . gitweb: add test suite with Test::WWW::Mechanize::CGI

* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
 . Migrate git-am to use git-sequencer
 . Add git-sequencer test suite (t3350)
 . Add git-sequencer prototype documentation
 . Add git-sequencer shell prototype

I haven't looked at the updated series yet.  I should, but nobody else
seems to be looking at these patches, which is somewhat depressing but
understandable.  Summer is slower ;-)

* pb/submodule (Wed Jul 16 21:11:40 2008 +0200) 7 commits
 . t7403: Submodule git mv, git rm testsuite
 . git rm: Support for removing submodules
 . git mv: Support moving submodules
 . submodule.*: Introduce simple C interface for submodule lookup by
   path
 . git submodule add: Fix naming clash handling
 . t7400: Add short "git submodule add" testsuite
 . git-mv: Remove dead code branch

Long overdue usability improvement series for submodule.  Very much
welcomed.  It would be nice to have some submodule improvements in 1.6.0,
but it would take us a few more rounds to hit 'next' with this, and it
will not be in 'master' when 1.6.0 ships.

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - [BROKEN wrt shallow clones] Ignore graft during object transfer

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output

This is for peeling the line from the blamed version to see what's behind
it, which may or may not help applications like gitweb.

----------------------------------------------------------------
[Will drop]

* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
 + Teach git-merge -X<option> again.
 + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
 + builtin-merge.c: use parse_options_step() "incremental parsing"
   machinery
 + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next

* jc/merge-theirs (Fri Jul 18 02:43:00 2008 -0700) 6 commits
 - Document that merge strategies can now take their own options
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

It appears nobody wants "theirs" nor "ours", so I'll soon apply a
wholesale revert for these series to 'next', and then these will be
dropped when we rewind 'next' after 1.6.0 final.

Please make sure next time somebody asks "ours/theirs" merge on the list
and #git s/he is quickly told that it was unanimously rejected so that
people do not have to waste time rehashing the topic ever again.

----------------------------------------------------------------
[On Hold]

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-19 16:55                                                                           ` Junio C Hamano
@ 2008-07-19 23:16                                                                             ` Johannes Schindelin
  0 siblings, 0 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-07-19 23:16 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nanako Shiraishi, git

Hi,

On Sat, 19 Jul 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Yes, I agree, if all strategies fail, it is dubitable that we find a 
> > metric that will always find the "best" one.  But if one fails and the 
> > next one does not, it is obvious what is correct.
> 
> Not at all.  Imagine the case where one of them is either ours or 
> theirs.

But then it is not the _default_ at all!

It is what the _user_ _asked_ for.

So this is what the user gets.

With Git, the user is not ignored (like GNOME does, to "help" the user).  
With Git, the user _gets_ what she asked for, even if the question does 
not make sense.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-19 11:19                                                                         ` Johannes Schindelin
@ 2008-07-19 16:55                                                                           ` Junio C Hamano
  2008-07-19 23:16                                                                             ` Johannes Schindelin
  2008-07-20 13:04                                                                           ` Miklos Vajna
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-07-19 16:55 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Nanako Shiraishi, git

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

> Yes, I agree, if all strategies fail, it is dubitable that we find a 
> metric that will always find the "best" one.  But if one fails and the 
> next one does not, it is obvious what is correct.

Not at all.  Imagine the case where one of them is either ours or theirs.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-19  5:32                                                                       ` Junio C Hamano
@ 2008-07-19 11:19                                                                         ` Johannes Schindelin
  2008-07-19 16:55                                                                           ` Junio C Hamano
  2008-07-20 13:04                                                                           ` Miklos Vajna
  0 siblings, 2 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-07-19 11:19 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nanako Shiraishi, git

Hi,

On Fri, 18 Jul 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Fri, 18 Jul 2008, Junio C Hamano wrote:
> >
> >> +The 'recursive' strategy can take the following options:
> >> +
> >> +ours;;
> >
> > You still have not addressed the issue that you can specify multiple 
> > strategies,...
> 
> Even though multiple -s parameters are supported, I know you have been 
> here long enough in git scene to remember how it came about.  I've seen 
> some third-party documents that talk about our ability to "try multiple 
> strategies and pick the best one" as one of the unique features, but 
> anybody who was there knows that it was just a failed experiment that we 
> did not bother removing.

I think that we made it hard for that experiment to succeed, by 
disallowing custom merge strategies.

See

http://git.or.cz/gitwiki/SoC2007Ideas#head-cfde15f16950c2579a89cc109762e911546e6fe3

for an idea that would make complete sense as a _fallback_ strategy.  
Fallback, because it is definitely too slow to be the default.

Yes, I agree, if all strategies fail, it is dubitable that we find a 
metric that will always find the "best" one.  But if one fails and the 
next one does not, it is obvious what is correct.

So I still feel that "-s subtree=<blabla>,recursive=theirs" would be a 
viable way to go.  And more intuitive than "-X".

I'll just ask Miklos what he thinks of the idea, and to write the patch if 
he likes it, once he's back from the saddle. :-)

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-18 11:55                                                                     ` Johannes Schindelin
@ 2008-07-19  5:32                                                                       ` Junio C Hamano
  2008-07-19 11:19                                                                         ` Johannes Schindelin
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-07-19  5:32 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Nanako Shiraishi, git

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

> On Fri, 18 Jul 2008, Junio C Hamano wrote:
>
>> +The 'recursive' strategy can take the following options:
>> +
>> +ours;;
>
> You still have not addressed the issue that you can specify multiple 
> strategies,...

Even though multiple -s parameters are supported, I know you have been
here long enough in git scene to remember how it came about.  I've seen
some third-party documents that talk about our ability to "try multiple
strategies and pick the best one" as one of the unique features, but
anybody who was there knows that it was just a failed experiment that we
did not bother removing.

The thing is, trying multiple strategies was a cute idea and it was quite
straightforward to implement.  But picking the best one is the much more
important part, and judging whose result is the best shouldn't be done
with just a naïve "how many conflicting paths remain there?" metric
(c.f. $gmane/87297 which talks about "stupid" but the argument is exactly
the same --- smaller number of conflicts may not necessarily be the
easiest to resolve nor the right resolution).  I would be surprised if
anybody uses multiple -s options in their daily workflow, even though I
would not be surprised if people tried to use it just as an experiment and
for its entertainment value once or maybe twice.  After all, I invented
the multiple strategy support for amusement, not from any practical real
world needs ;-)

So I do not consider that a convincing argument at all.

> ... or even a single _wrong_ one.  So:
>
> 	$ git merge -s stupid -Xours
>
> would not fail at all, but definitely not do the right thing either (it 
> disobeys a direct command of the user).

It does fail gracefully, though.

    $ git merge -s resolve -Xours next
    Trying really trivial in-index merge...
    error: Untracked working tree file '.gitattributes' would be overwritten by merge.
    Nope.
    fatal: Not a valid object name --ours
    Merge with strategy resolve failed.

I consider this falls into "You say it hurts?  Don't do that, then"
category.

The error message will naturally improve, once we teach the merge strategy
backends that they can be given --<option> in front of the usual
<base>... -- <ents>... parameters, and there is no risk of ambiguity
because no object names begin with a dash.

Having said all that, I do not have any reason to push for -Xours/theirs
myself.  I've made myself very clear from the beginning that what these
options do is a bad idea, just as "-s theirs" is a bad idea.  These
encourage a broken workflow and I do not see a clear upside, however
narrow, and you and Pasky seem to agree with me (heh, isn't it a rare
occasion that all three of us agree on something these days? ;-)

I won't shed tears to see them go.

However, I do think it is wrong to deny that it will eventually be
necessary for us to be able to pass strategy specific options via the
git-merge frontend driver to the strategy backend.  The primary reason why
I wrote "subtree" strategy to _guess_ how to shift trees was because there
was no way to pass "how the end user wants to shift them" to the strategy
backend over "pull -- merge -- merge-subtree" callchain.  Coming up with
the algorithm was fun, but that was secondary.

If we allow users to say -Xsubtree=<path>, it would be a true improvement
to a tool that is used in real life.  Unlike "multiple -s strategy"
support that I think nobody ever uses in practice (on which part of your
objection is based), "-s subtree" has been useful in real life, and you
can verify that claim easily by counting how many times I've used that in
git.git history yourself.

Even though I do not care deeply about the syntax (and if you do not like
the "-X" as the external option introducer, you are welcome to pick a
different notation and send in a patch), it would help for example the
vanilla "recursive" strategy to allow the user, when dealing with really
tricky merge, to influence the rename threshold score it uses by passing
it as a strategy-specific option.

As a conclusion of this discussion, I'll discard xx/merge-in-c-into-next
branch from "next", at the beginning of post-1.6.0 cycle.  We might in the
future need to resurrect only the -X<option> part to allow us to pass
strategy specific options (that are not "ours/theirs"), but there is no
immediate need for it, other than -Xsubtree=<path>.  If somebody wants to
step up and give the custom rename threshold to the recursive strategy,
keeping that code to do -X<option> might help that too, though.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-18  9:44                                                                   ` Petr Baudis
  2008-07-18  9:58                                                                     ` Junio C Hamano
@ 2008-07-19  5:13                                                                     ` Nanako Shiraishi
  1 sibling, 0 replies; 575+ messages in thread
From: Nanako Shiraishi @ 2008-07-19  5:13 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Petr Baudis, git

Quoting Junio C Hamano <gitster@pobox.com>:

> I tried not to sound too negative when describing -Xours and -Xtheirs
> there, but actually I think "-s theirs" is even worse.  It is how you
> would discard what you did (perhaps because the other side has much better
> solution than your hack), but that can be much more easily and cleanly
> done with:
>
> 	$ git reset --hard origin
>
> Some poeple might say "But with 'merge -s theirs', I can keep what I did,
> too".  That reset is simply discarding what I did.
>
> That logic also is flawed.  You can instead:
>
> 	$ git branch i-was-stupid
>       $ git reset --hard origin
>
> if you really want to keep record of your failure.
>
> One big problem "-s theirs" has, compared to the above "reset to origin,
> discarding or setting aside the failed history" is that your 'master'
> history that your further development is based on will keep your failed
> crap in it forever if you did "-s theirs".  Hopefully you will become a
> better programmer over time, and you may eventually have something worth
> sharing with the world near the tip of your master branch.  When that
> happens, however, you _cannot_ offer your master branch to be pulled by
> the upstream, as the wider world will not be interested in your earlier
> mistakes at all.

Thanks for sharing your insight.  Perhaps the above can become a separate pargraph to explains why there is no "theirs" merge strategy somewhere in the manual?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-18  8:50                                                               ` Nanako Shiraishi
  2008-07-18  9:08                                                                 ` Junio C Hamano
  2008-07-18  9:20                                                                 ` Nanako Shiraishi
@ 2008-07-18 11:56                                                                 ` Johannes Schindelin
  2008-07-20 10:20                                                                 ` Nanako Shiraishi
  3 siblings, 0 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-07-18 11:56 UTC (permalink / raw)
  To: Nanako Shiraishi; +Cc: Junio C Hamano, git

Hi,

On Fri, 18 Jul 2008, Nanako Shiraishi wrote:

> Quoting Junio C Hamano <gitster@pobox.com>:
> 
> > * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
> >  + Teach git-merge -X<option> again.
> >  + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
> >  + builtin-merge.c: use parse_options_step() "incremental parsing"
> >    machinery
> >  + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
> >
> > This needs to be merged to master iff/when merge-theirs gets merged, 
> > but I do not think this series is widely supported, so both are on 
> > hold.
> 
> Why do you say it is not widely supported?  I may be wrong but I think 
> you developed these patches after somebody from the mailing list asked 
> for this feature.

Asking for a feature, and then not doing a single thing to defend why it 
makes sense, of a single person, who does not even speak up now, does not 
count for "wide support".

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-18  9:43                                                                   ` Junio C Hamano
@ 2008-07-18 11:55                                                                     ` Johannes Schindelin
  2008-07-19  5:32                                                                       ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Johannes Schindelin @ 2008-07-18 11:55 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nanako Shiraishi, git

Hi,

On Fri, 18 Jul 2008, Junio C Hamano wrote:

> +The 'recursive' strategy can take the following options:
> +
> +ours;;

You still have not addressed the issue that you can specify multiple 
strategies, or even a single _wrong_ one.  So:

	$ git merge -s stupid -Xours

would not fail at all, but definitely not do the right thing either (it 
disobeys a direct command of the user).

Apart from having to choose different -X option names for the different 
backends, to avoid them from clashing when you specify multiple 
strategies, you also deprive the user from being able to try the _same_ 
backend with different options.

IOW all my objections to the -X option (even that it does not fit with our 
short option parsing paradigm) still apply.

We already have the "-S" wart, let's not add to that pile.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-18  9:44                                                                   ` Petr Baudis
@ 2008-07-18  9:58                                                                     ` Junio C Hamano
  2010-12-13 19:09                                                                       ` Yaroslav Halchenko
  2008-07-19  5:13                                                                     ` Nanako Shiraishi
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-07-18  9:58 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Nanako Shiraishi, git

Petr Baudis <pasky@suse.cz> writes:

> On Fri, Jul 18, 2008 at 06:20:10PM +0900, Nanako Shiraishi wrote:
>> I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves?
>
> It is dangerous to introduce new options just because we think someone,
> sometimes might find it useful, especially if they potentially encourage
> a bad workflow. Adding options and commands is expensive since it
> complicates the UI further, thus we should add further only when we have
> good reason for it.
>
>> > That also was the reason I did not add any documentation to it.
>
> I was actually looking for something like this based on some question on
> #git (about git pull -s theirs possibility), and did stumble upon these
> patches, but quickly gave up on them since it wasn't immediately clear
> for me from the patch description exactly how the workflow looks like
> (it doesn't really seem to work like the opposite of -s ours nor is it a
> separate strategy... huh) and the options were completely undocumented.

Heh, now you have some readings to do ;-)

I tried not to sound too negative when describing -Xours and -Xtheirs
there, but actually I think "-s theirs" is even worse.  It is how you
would discard what you did (perhaps because the other side has much better
solution than your hack), but that can be much more easily and cleanly
done with:

	$ git reset --hard origin

Some poeple might say "But with 'merge -s theirs', I can keep what I did,
too".  That reset is simply discarding what I did.

That logic also is flawed.  You can instead:

	$ git branch i-was-stupid
        $ git reset --hard origin

if you really want to keep record of your failure.

One big problem "-s theirs" has, compared to the above "reset to origin,
discarding or setting aside the failed history" is that your 'master'
history that your further development is based on will keep your failed
crap in it forever if you did "-s theirs".  Hopefully you will become a
better programmer over time, and you may eventually have something worth
sharing with the world near the tip of your master branch.  When that
happens, however, you _cannot_ offer your master branch to be pulled by
the upstream, as the wider world will not be interested in your earlier
mistakes at all.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-18  9:20                                                                 ` Nanako Shiraishi
  2008-07-18  9:43                                                                   ` Junio C Hamano
@ 2008-07-18  9:44                                                                   ` Petr Baudis
  2008-07-18  9:58                                                                     ` Junio C Hamano
  2008-07-19  5:13                                                                     ` Nanako Shiraishi
  1 sibling, 2 replies; 575+ messages in thread
From: Petr Baudis @ 2008-07-18  9:44 UTC (permalink / raw)
  To: Nanako Shiraishi; +Cc: Junio C Hamano, git

On Fri, Jul 18, 2008 at 06:20:10PM +0900, Nanako Shiraishi wrote:
> I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves?

It is dangerous to introduce new options just because we think someone,
sometimes might find it useful, especially if they potentially encourage
a bad workflow. Adding options and commands is expensive since it
complicates the UI further, thus we should add further only when we have
good reason for it.

> > That also was the reason I did not add any documentation to it.

I was actually looking for something like this based on some question on
#git (about git pull -s theirs possibility), and did stumble upon these
patches, but quickly gave up on them since it wasn't immediately clear
for me from the patch description exactly how the workflow looks like
(it doesn't really seem to work like the opposite of -s ours nor is it a
separate strategy... huh) and the options were completely undocumented.

-- 
				Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-18  9:20                                                                 ` Nanako Shiraishi
@ 2008-07-18  9:43                                                                   ` Junio C Hamano
  2008-07-18 11:55                                                                     ` Johannes Schindelin
  2008-07-18  9:44                                                                   ` Petr Baudis
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-07-18  9:43 UTC (permalink / raw)
  To: Nanako Shiraishi; +Cc: git

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> ... I do not think it is a sensible
>> thing to say "let's take as much automerge results as possible to salvage
>> our changes where they do not overlap with what the upstream did, but I
>> would give up our changes to places that the upstream also touched,
>> because I do not understand what they did well enough to be able to
>> resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly
>> that.
>
> I do not know if "I do not understand what they did well enough" is the
> only reason people would want to use that feature. Isn't it better to
> let people decide that for themselves?

We have been saying that we will give long enough rope to people, but at
the same time I believe there are things that the world is better without,
and a feature that would only encourage a bad workflow is one of them.
The way I try to tell such a (mis)feature from a feature that can be
useful to people other than myself is to ask people why they would want
such a feature and what their response to possible downsides of such a
feature.

Don't get me wrong.  Choice is good, and it is also good that some people
may choose differently from me.  After all, we are different people with
different workflows.

But they should be able to explain the reason why they choose something
clearly, at least well enough to convince themselves to choose it.  If
they can't come up with a rational explanation, it becomes an irrational
"because I want to" (and "because I can, now that you have already coded
it").  That leads to feeping creaturism and a bad feature that the world
is better without.

I haven't heard an explanation other than the one I said above, and I do
not think that explanation is rational.

	Side note. Even though I invented rerere and it turned out to be a
	great ti[mp]esaver, I do want to validate the reused resolution
	makes sense in the new context every time rerere does its job.
	Recently Ingo wanted the auto resolution to be staged
	automatically, and rerere.autoupdate was born.  I was initially
	very much against it, but his description of the workflow where it
	would be useful was convincing enough.  This "convincing" does not
	have to be "Yeah, it's useful to me as well; thanks for explaining
	it to me".  Even though my workflow might never be helped with
	such a feature, I can see that the different workflow he presented
	would be useful to people other than myself, and I could agree
	that the new feature would help such a workflow.  This was a good
	example of "choosing something I initially thought would be
	detrimental with a good reason, and with a good explanation making
	me realize that my initial thought was too narrow".

> I think such a documentation will help people to decide if 'theirs'
> option makes sense for their workflow.

So here it is.

-- >8 --
[PATCH] Document that merge strategies can now take their own options

Also document the recently added -Xtheirs, -Xours and -Xsubtree[=path]
options to the merge-recursive strategy.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/merge-options.txt    |    4 ++++
 Documentation/merge-strategies.txt |   26 ++++++++++++++++++++++++++
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index ffbc6e9..96aec48 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -58,3 +58,7 @@
 	If there is no `-s` option, a built-in list of strategies
 	is used instead (`git-merge-recursive` when merging a single
 	head, `git-merge-octopus` otherwise).
+
+-X<option>::
+	Pass merge strategy specific option through to the merge
+	strategy.
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 1276f85..39ff0a8 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -1,6 +1,11 @@
 MERGE STRATEGIES
 ----------------
 
+The merge mechanism ('git-merge' and 'git-pull' commands) allows the
+backend 'merge strategies' to be chosen with `-s` option.  Some strategies
+can also take their own options, which can be passed by giving `-X<option>`
+arguments to 'git-merge' and/or 'git-pull'.
+
 resolve::
 	This can only resolve two heads (i.e. the current branch
 	and another branch you pulled from) using 3-way merge
@@ -20,6 +25,27 @@ recursive::
 	Additionally this can detect and handle merges involving
 	renames.  This is the default merge strategy when
 	pulling or merging one branch.
++
+The 'recursive' strategy can take the following options:
+
+ours;;
+	This option forces conflicting hunks to be auto-resolved cleanly by
+	favoring 'our' version.  Changes from the other tree that do not
+	conflict with our side are reflected to the merge result.
++
+This should not be confused with the 'ours' merge strategy, which does not
+even look at what the other tree contains at all.  IOW, it discards everything
+the other tree did, declaring 'our' history contains all that happened in it.
+
+theirs;;
+	This is opposite of 'ours'.
+
+subtree[=path];;
+	This option is a more advanced form of 'subtree' strategy, where
+	the strategy makes a guess on how two trees must be shifted to
+	match with each other when merging.  Instead, the specified path
+	is prefixed (or stripped from the beginning) to make the shape of
+	two trees to match.
 
 octopus::
 	This resolves more than two-head case, but refuses to do
-- 
1.5.6.3.573.gd2d2

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-18  8:50                                                               ` Nanako Shiraishi
  2008-07-18  9:08                                                                 ` Junio C Hamano
@ 2008-07-18  9:20                                                                 ` Nanako Shiraishi
  2008-07-18  9:43                                                                   ` Junio C Hamano
  2008-07-18  9:44                                                                   ` Petr Baudis
  2008-07-18 11:56                                                                 ` Johannes Schindelin
  2008-07-20 10:20                                                                 ` Nanako Shiraishi
  3 siblings, 2 replies; 575+ messages in thread
From: Nanako Shiraishi @ 2008-07-18  9:20 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Quoting Junio C Hamano <gitster@pobox.com>:

> Well, for one thing, I do not believe in their cause.  As I wrote in the
> log messages for these commits (actually not these above which is a series
> for merge fixup, but the other topic), I do not think it is a sensible
> thing to say "let's take as much automerge results as possible to salvage
> our changes where they do not overlap with what the upstream did, but I
> would give up our changes to places that the upstream also touched,
> because I do not understand what they did well enough to be able to
> resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly
> that.

I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves?

> That also was the reason I did not add any documentation to it.  But I do
> like the change to the infrastructure to allow passing strategy-specific
> options through git-merge and git-pull.  Perhaps I should write something
> up, if only to salvage that -X<option> part, even though I am very much
> inclined to discard -Xtheirs (and -Xours) part.

I think such a documentation will help people to decide if 'theirs' option makes sense for their workflow.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-18  8:50                                                               ` Nanako Shiraishi
@ 2008-07-18  9:08                                                                 ` Junio C Hamano
  2008-07-18  9:20                                                                 ` Nanako Shiraishi
                                                                                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-07-18  9:08 UTC (permalink / raw)
  To: Nanako Shiraishi; +Cc: git

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
>>  + Teach git-merge -X<option> again.
>>  + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
>>  + builtin-merge.c: use parse_options_step() "incremental parsing"
>>    machinery
>>  + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
>>
>> This needs to be merged to master iff/when merge-theirs gets merged,
>> but I do not think this series is widely supported, so both are on hold.
>
> Why do you say it is not widely supported?  I may be wrong but I think
> you developed these patches after somebody from the mailing list asked
> for this feature.

Well, for one thing, I do not believe in their cause.  As I wrote in the
log messages for these commits (actually not these above which is a series
for merge fixup, but the other topic), I do not think it is a sensible
thing to say "let's take as much automerge results as possible to salvage
our changes where they do not overlap with what the upstream did, but I
would give up our changes to places that the upstream also touched,
because I do not understand what they did well enough to be able to
resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly
that.

That also was the reason I did not add any documentation to it.  But I do
like the change to the infrastructure to allow passing strategy-specific
options through git-merge and git-pull.  Perhaps I should write something
up, if only to salvage that -X<option> part, even though I am very much
inclined to discard -Xtheirs (and -Xours) part.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-17  8:08                                                             ` Junio C Hamano
  2008-07-17 13:09                                                               ` Stephan Beyer
@ 2008-07-18  8:50                                                               ` Nanako Shiraishi
  2008-07-18  9:08                                                                 ` Junio C Hamano
                                                                                   ` (3 more replies)
  2008-07-20  1:58                                                               ` Junio C Hamano
  2 siblings, 4 replies; 575+ messages in thread
From: Nanako Shiraishi @ 2008-07-18  8:50 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Quoting Junio C Hamano <gitster@pobox.com>:

> * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
>  + Teach git-merge -X<option> again.
>  + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
>  + builtin-merge.c: use parse_options_step() "incremental parsing"
>    machinery
>  + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
>
> This needs to be merged to master iff/when merge-theirs gets merged,
> but I do not think this series is widely supported, so both are on hold.

Why do you say it is not widely supported?  I may be wrong but I think you developed these patches after somebody from the mailing list asked for this feature.

You may find out people are enthusiastic about this only after you merge it to your master branch.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-17  8:08                                                             ` Junio C Hamano
@ 2008-07-17 13:09                                                               ` Stephan Beyer
  2008-07-18  8:50                                                               ` Nanako Shiraishi
  2008-07-20  1:58                                                               ` Junio C Hamano
  2 siblings, 0 replies; 575+ messages in thread
From: Stephan Beyer @ 2008-07-17 13:09 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

Junio C Hamano wrote:
> * sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
>  . Migrate git-am to use git-sequencer
>  . Add git-sequencer test suite (t3350)
>  . Add git-sequencer prototype documentation
>  . Add git-sequencer shell prototype
> 
> I haven't looked at the updated series yet.  I should, but nobody else
> seems to be looking at these patches, which is somewhat depressing but
> understandable.  Summer is slower ;-)

imho there is no need to hurry, but if I can help, just tell me how.

Regards.

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-07-16  3:33                                                           ` Junio C Hamano
@ 2008-07-17  8:08                                                             ` Junio C Hamano
  2008-07-17 13:09                                                               ` Stephan Beyer
                                                                                 ` (2 more replies)
  0 siblings, 3 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-07-17  8:08 UTC (permalink / raw)
  To: git

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.  The topics
meant to be merged to the maintenance series have "maint-" in their names.

Right now 'next' is very thin.  After today's new topics, perhaps except
for the submodule stuff by Pasky, are merged to 'master', we will have the
1.6.0-rc0, and from there the usual pre-release freeze begins.

Due to increased activity level from people including GSoC students, I
expect 'next' to stay somewhat more active than previous rounds during the
1.6.0-rc cycle.  The request for people who usually follow 'next' is the
same as usual, though.  After -rc1 is tagged, please run 'master' for your
daily git use instead, in order to make sure 'master' does what it claims
to do without regression.

Tentative schedule, my wishful thinking:

 - 1.6.0-rc0 (Jul 20)
 - 1.6.0-rc1 (Jul 23)
 - 1.6.0-rc2 (Jul 30)
 - 1.6.0-rc3 (Aug  6)
 - 1.6.0     (Aug 10)

----------------------------------------------------------------
[New Topics]

* jc/rerere-auto-more (Wed Jul 16 20:25:18 2008 -0700) 1 commit
 - rerere.autoupdate: change the message when autoupdate is in effect

This one is for Ingo.

This changes the message rerere issues after reusing previous conflict
resolution from "Resolved" to "Staged" when autoupdate option is in
effect.

It is envisioned that in practice, some auto resolutions are trickier and
iffier than others, and we would want to add a feature to mark individual
resolutions as "this is ok to autoupdate" or "do not autoupdate the result
using this resolution even when rerere.autoupdate is in effect" in the
future.  When that happens, these messages will make the distinction
clearer.

* ap/trackinfo (Wed Jul 16 15:19:27 2008 -0400) 1 commit
 - Reword "your branch has diverged..." lines to reduce line length

You saw the exchange on the list.  Queued is my "make it shorter and make
sure variable parts are closer to left edge of the screen" version but
better alternatives are welcome.  I suspect not many people would care too
much about details, as long as the message fits and does not waste screen
real estate.

* ns/am-abort (Wed Jul 16 19:39:10 2008 +0900) 1 commit
 - git am --abort

This one is for Ted; builds on top of the recent "am and rebase leaves
ORIG_HEAD just like reset, merge and pull does" rather nicely.

* pb/submodule (Wed Jul 16 21:11:40 2008 +0200) 7 commits
 - t7403: Submodule git mv, git rm testsuite
 - git rm: Support for removing submodules
 - git mv: Support moving submodules
 - submodule.*: Introduce simple C interface for submodule lookup by
   path
 - git submodule add: Fix naming clash handling
 - t7400: Add short "git submodule add" testsuite
 - git-mv: Remove dead code branch

Long overdue usability improvement series for submodule.  Very much
welcomed.  It would be nice to have some submodule improvements in 1.6.0.
Realistically speaking, however, I predict that it would take us a few
more rounds to hit 'next' with this, and it will not be in 'master' when
1.6.0 ships.

----------------------------------------------------------------
[Graduated to "master"]

* sp/maint-index-pack (Tue Jul 15 04:45:34 2008 +0000) 4 commits
 + index-pack: Honor core.deltaBaseCacheLimit when resolving deltas
 + index-pack: Track the object_entry that creates each base_data
 + index-pack: Chain the struct base_data on the stack for traversal
 + index-pack: Refactor base arguments of resolve_delta into a struct

* rs/rebase-checkout-not-so-quiet (Mon Jul 14 14:05:35 2008 -0700) 1 commit
 + git-rebase: report checkout failure

* ag/blame (Wed Jul 16 02:00:58 2008 +0400) 2 commits
 + Do not try to detect move/copy for entries below threshold.
 + Avoid rescanning unchanged entries in search for copies.

This gives a drastic performance improvement to "git-blame -C -C" with
quite straightforward and obvious code change.

* rs/archive (Mon Jul 14 21:22:05 2008 +0200) 6 commits
 + archive: remove extra arguments parsing code
 + archive: unify file attribute handling
 + archive: centralize archive entry writing
 + archive: add baselen member to struct archiver_args
 + add context pointer to read_tree_recursive()
 + archive: remove args member from struct archiver

* sb/dashless (Sun Jul 13 15:36:15 2008 +0200) 3 commits
 + Make usage strings dash-less
 + t/: Use "test_must_fail git" instead of "! git"
 + t/test-lib.sh: exit with small negagive int is ok with
   test_must_fail

* mv/dashless (Fri Jul 11 02:12:06 2008 +0200) 4 commits
 + make remove-dashes: apply to scripts and programs as well, not
   just to builtins
 + git-bisect: use dash-less form on git bisect log
 + t1007-hash-object.sh: use quotes for the test description
 + t0001-init.sh: change confusing directory name

* ls/mailinfo (Sun Jul 13 20:30:12 2008 +0200) 3 commits
 + git-mailinfo: use strbuf's instead of fixed buffers
 + Add some useful functions for strbuf manipulation.
 + Make some strbuf_*() struct strbuf arguments const.

This actually had a tiny regression I did not discover until I merged it
to 'master', where a fixup has already been applied.

----------------------------------------------------------------
[On Hold]

* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
 - Documentation: Improve documentation for git-imap-send(1)
 - imap-send.c: more style fixes
 - imap-send.c: style fixes
 - git-imap-send: Support SSL
 - git-imap-send: Allow the program to be run from subdirectories of
   a git tree

I said: "Some people seem to prefer having this feature available also
with gnutls.  If such a patch materializes soon, that would be good, but
otherwise I'll merge this as-is to 'next'.  Such an enhancement can be
done in-tree on top of this series."  Anybody?

* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
 + Teach git-merge -X<option> again.
 + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
 + builtin-merge.c: use parse_options_step() "incremental parsing"
   machinery
 + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next

This needs to be merged to master iff/when merge-theirs gets merged,
but I do not think this series is widely supported, so both are on hold.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

----------------------------------------------------------------
[Stalled/Needs more work]

* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
 . cherry: cache patch-ids to avoid repeating work

The discussion suggested that the value of having the cache itself is
iffy, but I should pick up the updated one and look at it.

* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
 . gitweb: use new Git::Repo API, and add optional caching
 . Add new Git::Repo API
 . gitweb: add test suite with Test::WWW::Mechanize::CGI

* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
 . Migrate git-am to use git-sequencer
 . Add git-sequencer test suite (t3350)
 . Add git-sequencer prototype documentation
 . Add git-sequencer shell prototype

I haven't looked at the updated series yet.  I should, but nobody else
seems to be looking at these patches, which is somewhat depressing but
understandable.  Summer is slower ;-)

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - [BROKEN wrt shallow clones] Ignore graft during object transfer

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output

This is for peeling the line from the blamed version to see what's behind
it, which may or may not help applications like gitweb.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-07-14  5:11                                                         ` Junio C Hamano
                                                                             ` (3 preceding siblings ...)
  2008-07-15  3:38                                                           ` Geoffrey Irving
@ 2008-07-16  3:33                                                           ` Junio C Hamano
  2008-07-17  8:08                                                             ` Junio C Hamano
  4 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-07-16  3:33 UTC (permalink / raw)
  To: git

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.  The topics
meant to be merged to the maintenance series have "maint-" in their names.

It so happens that the topics clearly separated between the ones that are
obviously ready for 1.6.0 and the others that aren't yet as of tonight.
It seems that it is a good time to draw that line and tag -rc0 tomorrow,
after merging the remaining topics in 'next'.

----------------------------------------------------------------
[New Topics]

I could apply these directly to master, but I am just playing it safe.

* sp/maint-index-pack (Tue Jul 15 04:45:34 2008 +0000) 4 commits
 + index-pack: Honor core.deltaBaseCacheLimit when resolving deltas
 + index-pack: Track the object_entry that creates each base_data
 + index-pack: Chain the struct base_data on the stack for traversal
 + index-pack: Refactor base arguments of resolve_delta into a struct

* rs/rebase-checkout-not-so-quiet (Mon Jul 14 14:05:35 2008 -0700) 1 commit
 + git-rebase: report checkout failure

* ag/blame (Wed Jul 16 02:00:58 2008 +0400) 2 commits
 + Do not try to detect move/copy for entries below threshold.
 + Avoid rescanning unchanged entries in search for copies.

This gives a drastic performance improvement to "git-blame -C -C" with
quite straightforward and obvious code change.

* rs/archive (Mon Jul 14 21:22:05 2008 +0200) 6 commits
 + archive: remove extra arguments parsing code
 + archive: unify file attribute handling
 + archive: centralize archive entry writing
 + archive: add baselen member to struct archiver_args
 + add context pointer to read_tree_recursive()
 + archive: remove args member from struct archiver

----------------------------------------------------------------
[Will merge to master soon]

* sb/dashless (Sun Jul 13 15:36:15 2008 +0200) 3 commits
 + Make usage strings dash-less
 + t/: Use "test_must_fail git" instead of "! git"
 + t/test-lib.sh: exit with small negagive int is ok with
   test_must_fail

* mv/dashless (Fri Jul 11 02:12:06 2008 +0200) 4 commits
 + make remove-dashes: apply to scripts and programs as well, not
   just to builtins
 + git-bisect: use dash-less form on git bisect log
 + t1007-hash-object.sh: use quotes for the test description
 + t0001-init.sh: change confusing directory name

* ls/mailinfo (Sun Jul 13 20:30:12 2008 +0200) 3 commits
 + git-mailinfo: use strbuf's instead of fixed buffers
 + Add some useful functions for strbuf manipulation.
 + Make some strbuf_*() struct strbuf arguments const.

----------------------------------------------------------------
[Graduated to "master"]

* sp/maint-bash-completion-optim (Mon Jul 14 00:22:03 2008 +0000) 1 commit
 + bash completion: Append space after file names have been completed

Early parts were already merged to 'master' and need to be merged down to
maint as well, as this is about a "performance bug" that has been with us
almost forever.

* ag/rewrite_one (Sat Jul 12 22:00:57 2008 +0400) 1 commit
 + Fix quadratic performance in rewrite_one.

* sp/win (Fri Jul 11 18:52:42 2008 +0200) 3 commits
 + We need to check for msys as well as Windows in add--interactive.
 + Convert CR/LF to LF in tag signatures
 + Fixed text file auto-detection: treat EOF character 032 at the end
   of file as printable

* js/merge-rr (Sat Jul 12 15:56:19 2008 +0100) 2 commits
 + Move MERGE_RR from .git/rr-cache/ into .git/
 + builtin-rerere: more carefully find conflict markers

* sb/rerere-lib (Wed Jul 9 14:58:57 2008 +0200) 2 commits
 + rerere: Separate libgit and builtin functions
 + builtin-rerere: more carefully find conflict markers

* js/maint-pretty-mailmap (Sat Jul 12 00:28:18 2008 +0100) 1 commit
 + Add pretty format %aN which gives the author name, respecting
   .mailmap

* js/more-win (Sun Jul 13 22:31:23 2008 +0200) 3 commits
 + help (Windows): Display HTML in default browser using Windows'
   shell API
 + help.c: Add support for htmldir relative to git_exec_path()
 + Move code interpreting path relative to exec-dir to new function
   system_path()

* jc/rebase-orig-head (Tue Jul 8 00:12:22 2008 -0400) 2 commits
 + Documentation: mention ORIG_HEAD in am, merge, and rebase
 + Teach "am" and "rebase" to mark the original position with
   ORIG_HEAD

* jc/branch-merged (Tue Jul 8 17:55:47 2008 -0700) 3 commits
 + branch --merged/--no-merged: allow specifying arbitrary commit
 + branch --contains: default to HEAD
 + parse-options: add PARSE_OPT_LASTARG_DEFAULT flag

* om/rerere-careful (Mon Jul 7 14:42:48 2008 +0200) 1 commit
 + builtin-rerere: more carefully find conflict markers

* ls/maint-mailinfo-patch-label (Thu Jul 10 23:41:33 2008 +0200) 1 commit
 + git-mailinfo: Fix getting the subject from the in-body [PATCH]
   line

* mv/merge-in-c (Mon Jul 14 00:09:41 2008 -0700) 20 commits
 + reduce_heads(): protect from duplicate input
 + reduce_heads(): thinkofix
 + Add a new test for git-merge-resolve
 + t6021: add a new test for git-merge-resolve
 + Teach merge.log to "git-merge" again
 + Build in merge
 + Fix t7601-merge-pull-config.sh on AIX
 + git-commit-tree: make it usable from other builtins
 + Add new test case to ensure git-merge prepends the custom merge
   message
 + Add new test case to ensure git-merge reduces octopus parents when
   possible
 + Introduce reduce_heads()
 + Introduce get_merge_bases_many()
 + Add new test to ensure git-merge handles more than 25 refs.
 + Introduce get_octopus_merge_bases() in commit.c
 + git-fmt-merge-msg: make it usable from other builtins
 + Move read_cache_unmerged() to read-cache.c
 + Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 + Move parse-options's skip_prefix() to git-compat-util.h
 + Move commit_list_count() to commit.c
 + Move split_cmdline() to alias.c

----------------------------------------------------------------
[On Hold]

* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
 - Documentation: Improve documentation for git-imap-send(1)
 - imap-send.c: more style fixes
 - imap-send.c: style fixes
 - git-imap-send: Support SSL
 - git-imap-send: Allow the program to be run from subdirectories of
   a git tree

Some people seem to prefer having this feature available also with gnutls.
If such a patch materializes soon, that would be good, but otherwise I'll
merge this as-is to 'next'.  Such an enhancement can be done in-tree on
top of this series.

* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
 + Teach git-merge -X<option> again.
 + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
 + builtin-merge.c: use parse_options_step() "incremental parsing"
   machinery
 + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next

This needs to be merged to master iff/when merge-theirs gets merged,
but I do not think this series is widely supported, so both are on hold.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

----------------------------------------------------------------
[Stalled/Needs more work]

* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
 . cherry: cache patch-ids to avoid repeating work

* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
 . gitweb: use new Git::Repo API, and add optional caching
 . Add new Git::Repo API
 . gitweb: add test suite with Test::WWW::Mechanize::CGI

* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
 . Migrate git-am to use git-sequencer
 . Add git-sequencer test suite (t3350)
 . Add git-sequencer prototype documentation
 . Add git-sequencer shell prototype

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - [BROKEN wrt shallow clones] Ignore graft during object transfer

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output

This is for peeling to see what's behind the blamed commit, which may or
may not help applications like gitweb.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-15  9:22                                                             ` Johannes Schindelin
@ 2008-07-15 16:48                                                               ` Geoffrey Irving
  0 siblings, 0 replies; 575+ messages in thread
From: Geoffrey Irving @ 2008-07-15 16:48 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git

On Tue, Jul 15, 2008 at 2:22 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 14 Jul 2008, Geoffrey Irving wrote:
>
>> The problem (beyond the basic problem of me not having tried running the
>> tests) is that the current caching code isn't taking into account the
>> changing values of diff_options.  t6007 computes a patch-id for a commit
>> with one value of options.paths, and then tries to compute a _different_
>> patch-id for the same commit using a different value of options.paths.
>>
>> Here are a few different ways of fixing this:
>>
>> 1. Modify commit_patch_id in patch-ids.c to compute a sha1 of the
>>    diff_options structure and xor it with the commit sha1 to get a truly
>>    unique hash of the input.  This means the optimization can be safely
>>    applied for all patch-id computations regardless of the diff_options.
>>    I can add a diff_options_sha1 function in diff.[ch] to compute the
>>    checksum.
>>
>> 2. Restrict commit_patch_id in patch-ids.c to apply the optimization
>>    only if options.nr_paths is zero, and perhaps a few other conditions.
>>    This is rather fragile, since it would mean that the cache would
>>    break if someone decided to change the default diff options.
>
> Funnily, (2) contradicts (1).  The patch id is _different_ when you have
> nr_paths > 0.  At least in the general case.
>
> So what you propose in (1) will not work, unless you also hash the path
> names (in the correct order, otherwise you'll end up with two hashes).

The sha1 would include paths, of course, since it's part of diff_options.

> OTOH I would be really surprised if you needed --cherry-pick with paths
> and/or diff options more than once for the same commits.  So the caching
> does not make sense to begin with (especially since we do not have a
> proper way of gc'ing it, right?).
>
> So I'd suggest saving diff_opts before the command line parsing, and
> disable the cache when it is different _and/or_ (||) nr_paths.

I'll attach the patch to the other thread.

Geoffrey

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-15  3:38                                                           ` Geoffrey Irving
@ 2008-07-15  9:22                                                             ` Johannes Schindelin
  2008-07-15 16:48                                                               ` Geoffrey Irving
  0 siblings, 1 reply; 575+ messages in thread
From: Johannes Schindelin @ 2008-07-15  9:22 UTC (permalink / raw)
  To: Geoffrey Irving; +Cc: Junio C Hamano, git

Hi,

On Mon, 14 Jul 2008, Geoffrey Irving wrote:

> The problem (beyond the basic problem of me not having tried running the 
> tests) is that the current caching code isn't taking into account the 
> changing values of diff_options.  t6007 computes a patch-id for a commit 
> with one value of options.paths, and then tries to compute a _different_ 
> patch-id for the same commit using a different value of options.paths.
> 
> Here are a few different ways of fixing this:
> 
> 1. Modify commit_patch_id in patch-ids.c to compute a sha1 of the 
>    diff_options structure and xor it with the commit sha1 to get a truly 
>    unique hash of the input.  This means the optimization can be safely 
>    applied for all patch-id computations regardless of the diff_options.  
>    I can add a diff_options_sha1 function in diff.[ch] to compute the 
>    checksum.
> 
> 2. Restrict commit_patch_id in patch-ids.c to apply the optimization 
>    only if options.nr_paths is zero, and perhaps a few other conditions.  
>    This is rather fragile, since it would mean that the cache would 
>    break if someone decided to change the default diff options.

Funnily, (2) contradicts (1).  The patch id is _different_ when you have 
nr_paths > 0.  At least in the general case.

So what you propose in (1) will not work, unless you also hash the path 
names (in the correct order, otherwise you'll end up with two hashes).

OTOH I would be really surprised if you needed --cherry-pick with paths 
and/or diff options more than once for the same commits.  So the caching 
does not make sense to begin with (especially since we do not have a 
proper way of gc'ing it, right?).

So I'd suggest saving diff_opts before the command line parsing, and 
disable the cache when it is different _and/or_ (||) nr_paths.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-14  5:11                                                         ` Junio C Hamano
                                                                             ` (2 preceding siblings ...)
  2008-07-14 23:12                                                           ` Lea Wiemann
@ 2008-07-15  3:38                                                           ` Geoffrey Irving
  2008-07-15  9:22                                                             ` Johannes Schindelin
  2008-07-16  3:33                                                           ` Junio C Hamano
  4 siblings, 1 reply; 575+ messages in thread
From: Geoffrey Irving @ 2008-07-15  3:38 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Schindelin

On Sun, Jul 13, 2008 at 10:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Here are the topics that have been cooking.  Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'.
>
> <snip>
>
> * gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
>  - cherry: cache patch-ids to avoid repeating work
>
> This does not seem to pass tests even on its own.

The problem (beyond the basic problem of me not having tried running
the tests) is that the current caching code isn't taking into account
the changing values of diff_options.  t6007 computes a patch-id for a
commit with one value of options.paths, and then tries to compute a
_different_ patch-id for the same commit using a different value of
options.paths.

Here are a few different ways of fixing this:

1. Modify commit_patch_id in patch-ids.c to compute a sha1 of the
diff_options structure and xor it with the commit sha1 to get a truly
unique hash of the input.  This means the optimization can be safely
applied for all patch-id computations regardless of the diff_options.
I can add a diff_options_sha1 function in diff.[ch] to compute the
checksum.

2. Restrict commit_patch_id in patch-ids.c to apply the optimization
only if options.nr_paths is zero, and perhaps a few other conditions.
This is rather fragile, since it would mean that the cache would break
if someone decided to change the default diff options.

3. Add a flag in struct patch_ids defaulting to false which turns the
caching on or off, and manually set the flag to true in cmd_cherry.

I'd lean towards (1), but wanted to check before writing the code to
make sure that it's reasonable to treat diff_options as stable enough
that computing a sha1 hash of it makes sense.  According to "git help
patch-id", it is only "reasonable stable", which is sufficient as long
as we're confident that whenever the diff format changes, the
diff_options_sha1 function will be updated to reflect that change.

As an aside: is it correct that as long as the change is in pu, I
should be submitting complete (nonincremental) patches whenever I fix
bugs?

Thanks,
Geoffrey

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-14 23:20                                                             ` Lea Wiemann
@ 2008-07-15  0:03                                                               ` Junio C Hamano
  0 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-07-15  0:03 UTC (permalink / raw)
  To: Lea Wiemann; +Cc: git

Lea Wiemann <lewiemann@gmail.com> writes:

> Lea Wiemann wrote:
>> It'll be fixed in the next version I post
>
> By the way Junio, how do you prefer to get reposts of patch sequences?
> Should I repost the whole sequence under a new common parent message, or
> can I simply post v2 of each patch in the sequence as a followup to its
> respective v1?

I do not have major preference either way, but for a long series, I'd
prefer a resend to be independent from the previous series, i.e.

        [PATCH 0/3]
        .[PATCH 1/3]
        ..[PATCH 2/3]
        ...[PATCH 3/3]

        [PATCH 0/4 v2]
        .[PATCH 1/4 v2]
        ..[PATCH 2/4 v2]
        ...[PATCH 3/4 v2]
        ....[PATCH 4/4 v2]
        
I can live with the first one from the new series being a follow-up to the
first one from the old series, i.e.:

        [PATCH 0/3]
        .[PATCH 1/3]
        ..[PATCH 2/3]
        ...[PATCH 3/3]
        .[PATCH 0/4 v2]
        ..[PATCH 1/4 v2]
        ...[PATCH 2/4 v2]
        ....[PATCH 3/4 v2]
        .....[PATCH 4/4 v2]

but _not_ with this, i.e. N/M being followup to old N/M:

        [PATCH 0/3]
        .[PATCH 0/4 v2]
        .[PATCH 1/3]
        ..[PATCH 1/4 v2]
        ..[PATCH 2/3]
        ...[PATCH 2/4 v2]
        ...[PATCH 3/3]
        ....[PATCH 3/4 v2]
        .....[PATCH 4/4 v2]

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-14 23:12                                                           ` Lea Wiemann
@ 2008-07-14 23:20                                                             ` Lea Wiemann
  2008-07-15  0:03                                                               ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Lea Wiemann @ 2008-07-14 23:20 UTC (permalink / raw)
  To: Lea Wiemann; +Cc: Junio C Hamano, git

Lea Wiemann wrote:
> It'll be fixed in the next version I post

By the way Junio, how do you prefer to get reposts of patch sequences?
Should I repost the whole sequence under a new common parent message, or
can I simply post v2 of each patch in the sequence as a followup to its
respective v1?

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-14  5:11                                                         ` Junio C Hamano
  2008-07-14  6:45                                                           ` Junio C Hamano
  2008-07-14 11:53                                                           ` Johannes Schindelin
@ 2008-07-14 23:12                                                           ` Lea Wiemann
  2008-07-14 23:20                                                             ` Lea Wiemann
  2008-07-15  3:38                                                           ` Geoffrey Irving
  2008-07-16  3:33                                                           ` Junio C Hamano
  4 siblings, 1 reply; 575+ messages in thread
From: Lea Wiemann @ 2008-07-14 23:12 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano wrote:
> * lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
>  - Add new Git::Repo API
> 
> This does not pass t9710, at least for me X-<.

Yikes; I thought I had removed all instanced of Carp::Always (which I
had put in for development), but this one apparently slipped through.
It'll be fixed in the next version I post (which will also have the
dependency on the non-core Test::Exception package removed).

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-14  5:11                                                         ` Junio C Hamano
  2008-07-14  6:45                                                           ` Junio C Hamano
@ 2008-07-14 11:53                                                           ` Johannes Schindelin
  2008-07-14 23:12                                                           ` Lea Wiemann
                                                                             ` (2 subsequent siblings)
  4 siblings, 0 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-07-14 11:53 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Sun, 13 Jul 2008, Junio C Hamano wrote:

> * js/more-win (Sun Jul 13 22:31:23 2008 +0200) 6 commits
>  - Allow add_path() to add non-existent directories to the path
>  - Allow the built-in exec path to be relative to the command
>    invocation path
>  - Fix relative built-in paths to be relative to the command
>    invocation
>  + help (Windows): Display HTML in default browser using Windows'
>    shell API
>  + help.c: Add support for htmldir relative to git_exec_path()
>  + Move code interpreting path relative to exec-dir to new function
>    system_path()
> 
> The earlier parts are obvious; Dscho seemed to have some comments on the
> later ones that are in 'pu'.

Just one, and it seems that the next patch patched that ;-)  Not really a 
showstopper.

> * mv/merge-in-c (Sun Jul 13 08:13:55 2008 +0000) 19 commits
>  + reduce_heads(): thinkofix

Hmm.  My earlier response to Sverre was based on an old "next", it seems.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-14  5:11                                                         ` Junio C Hamano
@ 2008-07-14  6:45                                                           ` Junio C Hamano
  2008-07-14 11:53                                                           ` Johannes Schindelin
                                                                             ` (3 subsequent siblings)
  4 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-07-14  6:45 UTC (permalink / raw)
  To: Lea Wiemann; +Cc: git

Junio C Hamano <gitster@pobox.com> writes:

> * lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
>  - gitweb: use new Git::Repo API, and add optional caching
>  - Add new Git::Repo API
>  - gitweb: add test suite with Test::WWW::Mechanize::CGI
>
> This does not pass t9710, at least for me X-<.

This is getting a bit boring and tiresome.  Obviously I haven't checked
what _else_ is missing because I did not install Carp::Always myself to my
system.

 t/t9710-perl-git-repo.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t9710-perl-git-repo.sh b/t/t9710-perl-git-repo.sh
index ca67b87..2da3cd8 100755
--- a/t/t9710-perl-git-repo.sh
+++ b/t/t9710-perl-git-repo.sh
@@ -6,8 +6,8 @@
 test_description='perl interface (Git/*.pm)'
 . ./test-lib.sh
 
-perl -MTest::More -e 0 2>/dev/null || {
-	say_color skip "Perl Test::More unavailable, skipping test"
+perl -MTest::More -MTest::Exception -MCarp::Always -e 0 2>/dev/null || {
+	say_color skip "Perl Test::{More,Exception}, Carp::Always unavailable, skipping test"
 	test_done
 }
 

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-07-10  2:32                                                       ` Junio C Hamano
@ 2008-07-14  5:11                                                         ` Junio C Hamano
  2008-07-14  6:45                                                           ` Junio C Hamano
                                                                             ` (4 more replies)
  0 siblings, 5 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-07-14  5:11 UTC (permalink / raw)
  To: git

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.  The topics
meant to be merged to the maintenance series have "maint-" in their names.

I think most of the important stuff is already in 'next'.  Let's start
talking about closing the merge window for 1.6.0.

----------------------------------------------------------------
[New Topics]

* sb/dashless (Sun Jul 13 15:36:15 2008 +0200) 3 commits
 - Make usage strings dash-less
 - t/: Use "test_must_fail git" instead of "! git"
 - t/test-lib.sh: exit with small negagive int is ok with
   test_must_fail

* mv/dashless (Fri Jul 11 02:12:06 2008 +0200) 4 commits
 - make remove-dashes: apply to scripts and programs as well, not
   just to builtins
 - git-bisect: use dash-less form on git bisect log
 - t1007-hash-object.sh: use quotes for the test description
 - t0001-init.sh: change confusing directory name

* sp/maint-bash-completion-optim (Mon Jul 14 00:22:03 2008 +0000) 1 commit
 + bash completion: Append space after file names have been completed

Early parts are already merged to 'master' and need to be merged down to
maint as well, as this is about a "performance bug" that has been with us
almost forever.

* ag/rewrite_one (Sat Jul 12 22:00:57 2008 +0400) 1 commit
 + Fix quadratic performance in rewrite_one.

* sp/win (Fri Jul 11 18:52:42 2008 +0200) 3 commits
 + We need to check for msys as well as Windows in add--interactive.
 + Convert CR/LF to LF in tag signatures
 + Fixed text file auto-detection: treat EOF character 032 at the end
   of file as printable

* js/merge-rr (Sat Jul 12 15:56:19 2008 +0100) 2 commits
 + Move MERGE_RR from .git/rr-cache/ into .git/
 + builtin-rerere: more carefully find conflict markers

* sb/rerere-lib (Wed Jul 9 14:58:57 2008 +0200) 2 commits
 + rerere: Separate libgit and builtin functions
 + builtin-rerere: more carefully find conflict markers

* ls/mailinfo (Sun Jul 13 20:30:12 2008 +0200) 3 commits
 - git-mailinfo: use strbuf's instead of fixed buffers
 - Add some useful functions for strbuf manipulation.
 - Make some strbuf_*() struct strbuf arguments const.

* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
 - cherry: cache patch-ids to avoid repeating work

This does not seem to pass tests even on its own.

* js/maint-pretty-mailmap (Sat Jul 12 00:28:18 2008 +0100) 1 commit
 + Add pretty format %aN which gives the author name, respecting
   .mailmap

* js/more-win (Sun Jul 13 22:31:23 2008 +0200) 6 commits
 - Allow add_path() to add non-existent directories to the path
 - Allow the built-in exec path to be relative to the command
   invocation path
 - Fix relative built-in paths to be relative to the command
   invocation
 + help (Windows): Display HTML in default browser using Windows'
   shell API
 + help.c: Add support for htmldir relative to git_exec_path()
 + Move code interpreting path relative to exec-dir to new function
   system_path()

The earlier parts are obvious; Dscho seemed to have some comments on the
later ones that are in 'pu'.

* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
 - gitweb: use new Git::Repo API, and add optional caching
 - Add new Git::Repo API
 - gitweb: add test suite with Test::WWW::Mechanize::CGI

This does not pass t9710, at least for me X-<.

----------------------------------------------------------------
[Will merge to master soon]

* jc/rebase-orig-head (Tue Jul 8 00:12:22 2008 -0400) 2 commits
 + Documentation: mention ORIG_HEAD in am, merge, and rebase
 + Teach "am" and "rebase" to mark the original position with
   ORIG_HEAD

* jc/branch-merged (Tue Jul 8 17:55:47 2008 -0700) 3 commits
 + branch --merged/--no-merged: allow specifying arbitrary commit
 + branch --contains: default to HEAD
 + parse-options: add PARSE_OPT_LASTARG_DEFAULT flag

This builds on top of the parse-options enhancement series that
has been cooking in 'next' for some time.

* om/rerere-careful (Mon Jul 7 14:42:48 2008 +0200) 1 commit
 + builtin-rerere: more carefully find conflict markers

* ls/maint-mailinfo-patch-label (Thu Jul 10 23:41:33 2008 +0200) 1 commit
 + git-mailinfo: Fix getting the subject from the in-body [PATCH]
   line

----------------------------------------------------------------
[Actively Cooking]

* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
 + Teach git-merge -X<option> again.
 + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
 + builtin-merge.c: use parse_options_step() "incremental parsing"
   machinery
 + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next

I've described what this is in a separate message.

* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
 - Documentation: Improve documentation for git-imap-send(1)
 - imap-send.c: more style fixes
 - imap-send.c: style fixes
 - git-imap-send: Support SSL
 - git-imap-send: Allow the program to be run from subdirectories of
   a git tree

Some people seem to prefer having this feature available also with gnutls.
If such a patch materializes soon, that would be good, but otherwise I'll
merge this as-is to 'next'.  Such an enhancement can be done in-tree on
top of this series.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

* mv/merge-in-c (Sun Jul 13 08:13:55 2008 +0000) 19 commits
 + reduce_heads(): thinkofix
 + Add a new test for git-merge-resolve
 + t6021: add a new test for git-merge-resolve
 + Teach merge.log to "git-merge" again
 + Build in merge
 + Fix t7601-merge-pull-config.sh on AIX
 + git-commit-tree: make it usable from other builtins
 + Add new test case to ensure git-merge prepends the custom merge
   message
 + Add new test case to ensure git-merge reduces octopus parents when
   possible
 + Introduce reduce_heads()
 + Introduce get_merge_bases_many()
 + Add new test to ensure git-merge handles more than 25 refs.
 + Introduce get_octopus_merge_bases() in commit.c
 + git-fmt-merge-msg: make it usable from other builtins
 + Move read_cache_unmerged() to read-cache.c
 + Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 + Move parse-options's skip_prefix() to git-compat-util.h
 + Move commit_list_count() to commit.c
 + Move split_cmdline() to alias.c

Sverre seems to have a yet another fixup on top of this that came late and
I haven't looked at.

----------------------------------------------------------------
[Graduated to "master"]

* js/pick-root (Fri Jul 4 16:19:52 2008 +0100) 1 commit
 + Allow cherry-picking root commits

* ab/bundle (Sat Jul 5 17:26:40 2008 -0400) 1 commit
 + Teach git-bundle to read revision arguments from stdin like git-
   rev-list.

* sg/stash-k-i (Tue Jul 8 00:40:56 2008 -0700) 2 commits
 + Documentation: tweak use case in "git stash save --keep-index"
 + stash: introduce 'stash save --keep-index' option

One weakness of our "partial commit" workflow support used to be that the
user can incrementally build what is to be committed in the index but that
state cannot be tested as a whole in the working tree.  This allows you to
temporarily stash the remaining changes in the working tree so that the
index state before running "stash save --keep-index" can be seen in the
working tree to be tested and then committed.

* am/stash-branch (Mon Jul 7 02:50:10 2008 +0530) 2 commits
 + Add a test for "git stash branch"
 + Implement "git stash branch <newbranch> <stash>"

Creates a new branch out of the stashed state, after returning from the
interrupt that forced you to create the stash in the first place.

* tr/add-i-e (Thu Jul 3 00:00:00 2008 +0200) 3 commits
 + git-add--interactive: manual hunk editing mode
 + git-add--interactive: remove hunk coalescing
 + git-add--interactive: replace hunk recounting with apply --recount

Adds 'e/dit' action to interactive add command.

* jc/report-tracking (Sun Jul 6 02:54:56 2008 -0700) 5 commits
 + branch -r -v: do not spit out garbage
 + stat_tracking_info(): clear object flags used during counting
 + git-branch -v: show the remote tracking statistics
 + git-status: show the remote tracking statistics
 + Refactor "tracking statistics" code used by "git checkout"

Makes the "your branch is ahead of the tracked one by N commits" logic and
messages available to other commands; status and branch are updated.

* ph/parseopt-step-blame (Wed Jul 9 23:38:34 2008 +0200) 18 commits
 + revisions: refactor handle_revision_opt into parse_revision_opt.
 + git-shortlog: migrate to parse-options partially.
 + git-blame: fix lapsus
 + git-blame: migrate to incremental parse-option [2/2]
 + git-blame: migrate to incremental parse-option [1/2]
 + revisions: split handle_revision_opt() from setup_revisions()
 + Merge branch 'jc/blame' (early part) into HEAD
 + parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 + parse-opt: fake short strings for callers to believe in.
 + parse-opt: do not print errors on unknown options, return -2
   intead.
 + parse-opt: create parse_options_step.
 + parse-opt: Export a non NORETURN usage dumper.
 + parse-opt: have parse_options_{start,end}.
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

Became active again ;-) This probably is ready for 'master' already,
except for the last two which I only looked at the patch and have not
used heavily in production yet.

----------------------------------------------------------------
[On Hold]

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

----------------------------------------------------------------
[Stalled/Needs more work]

* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
 . Migrate git-am to use git-sequencer
 . Add git-sequencer test suite (t3350)
 . Add git-sequencer prototype documentation
 . Add git-sequencer shell prototype

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - [BROKEN wrt shallow clones] Ignore graft during object transfer

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output

This is for peeling to see what's behind the blamed commit, which may or
may not help applications like gitweb.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-07-08  2:46                                                     ` Junio C Hamano
@ 2008-07-10  2:32                                                       ` Junio C Hamano
  2008-07-14  5:11                                                         ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-07-10  2:32 UTC (permalink / raw)
  To: git

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.  The topics
meant to be applied to the maintenance series have "maint-" in their
names.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  Bigger changes will be:

 * Port for MinGW.

 * With the default Makefile settings, most of the programs will be
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical
   reasons.  Invoking a git subcommand as "git-xyzzy" from the command
   line has been deprecated since early 2006 (and officially announced in
   1.5.4 release notes); use of them from your scripts after adding
   output from "git --exec-path" to the $PATH will still be supported in
   1.6.0, but users are again strongly encouraged to adjust their
   scripts to use "git xyzzy" form, as we will stop installing
   "git-xyzzy" hardlinks for built-in commands in later releases.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

 * GIT_CONFIG, which was only documented as affecting "git config", but
   actually affected all git commands, now only affects "git config".
   GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
   not different from GIT_CONFIG in a useful way, is removed.

----------------------------------------------------------------
[New Topics]

* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
 + Teach git-merge -X<option> again.
 + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
 + builtin-merge.c: use parse_options_step() "incremental parsing"
   machinery
 + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next

I've described what this is in a separate message.

* jc/branch-merged (Tue Jul 8 17:55:47 2008 -0700) 3 commits
 + branch --merged/--no-merged: allow specifying arbitrary commit
 + branch --contains: default to HEAD
 + parse-options: add PARSE_OPT_LASTARG_DEFAULT flag

This builds on top of the parse-options enhancement series that
has been cooking in 'next' for some time.

* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
 + Documentation: Improve documentation for git-imap-send(1)
 + imap-send.c: more style fixes
 + imap-send.c: style fixes
 + git-imap-send: Support SSL
 + git-imap-send: Allow the program to be run from subdirectories of
   a git tree

* om/rerere-careful (Mon Jul 7 14:42:48 2008 +0200) 1 commit
 + builtin-rerere: more carefully find conflict markers

----------------------------------------------------------------
[Will merge to master soon]

* js/pick-root (Fri Jul 4 16:19:52 2008 +0100) 1 commit
 + Allow cherry-picking root commits

* ab/bundle (Sat Jul 5 17:26:40 2008 -0400) 1 commit
 + Teach git-bundle to read revision arguments from stdin like git-
   rev-list.

* sg/stash-k-i (Tue Jul 8 00:40:56 2008 -0700) 2 commits
 + Documentation: tweak use case in "git stash save --keep-index"
 + stash: introduce 'stash save --keep-index' option

One weakness of our "partial commit" workflow support used to be that the
user can incrementally build what is to be committed in the index but that
state cannot be tested as a whole in the working tree.  This allows you to
temporarily stash the remaining changes in the working tree so that the
index state before running "stash save --keep-index" can be seen in the
working tree to be tested and then committed.

* am/stash-branch (Mon Jul 7 02:50:10 2008 +0530) 2 commits
 + Add a test for "git stash branch"
 + Implement "git stash branch <newbranch> <stash>"

Creates a new branch out of the stashed state, after returning from the
interrupt that forced you to create the stash in the first place.

* tr/add-i-e (Thu Jul 3 00:00:00 2008 +0200) 3 commits
 + git-add--interactive: manual hunk editing mode
 + git-add--interactive: remove hunk coalescing
 + git-add--interactive: replace hunk recounting with apply --recount

Adds 'e/dit' action to interactive add command.

* jc/report-tracking (Sun Jul 6 02:54:56 2008 -0700) 5 commits
 + branch -r -v: do not spit out garbage
 + stat_tracking_info(): clear object flags used during counting
 + git-branch -v: show the remote tracking statistics
 + git-status: show the remote tracking statistics
 + Refactor "tracking statistics" code used by "git checkout"

Makes the "your branch is ahead of the tracked one by N commits" logic and
messages available to other commands; status and branch are updated.

----------------------------------------------------------------
[Actively Cooking]

* jc/rebase-orig-head (Tue Jul 8 00:12:22 2008 -0400) 2 commits
 + Documentation: mention ORIG_HEAD in am, merge, and rebase
 + Teach "am" and "rebase" to mark the original position with
   ORIG_HEAD

* ph/parseopt-step-blame (Wed Jul 9 23:38:34 2008 +0200) 18 commits
 + revisions: refactor handle_revision_opt into parse_revision_opt.
 + git-shortlog: migrate to parse-options partially.
 + git-blame: fix lapsus
 + git-blame: migrate to incremental parse-option [2/2]
 + git-blame: migrate to incremental parse-option [1/2]
 + revisions: split handle_revision_opt() from setup_revisions()
 + Merge branch 'jc/blame' (early part) into HEAD
 + parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 + parse-opt: fake short strings for callers to believe in.
 + parse-opt: do not print errors on unknown options, return -2
   intead.
 + parse-opt: create parse_options_step.
 + parse-opt: Export a non NORETURN usage dumper.
 + parse-opt: have parse_options_{start,end}.
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

Became active again ;-) This probably is ready for 'master' already,
except for the last two which I only looked at the patch and have not
used heavily in production yet.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

* mv/merge-in-c (Mon Jul 7 19:24:20 2008 +0200) 15 commits
 + Build in merge
 + Fix t7601-merge-pull-config.sh on AIX
 + git-commit-tree: make it usable from other builtins
 + Add new test case to ensure git-merge prepends the custom merge
   message
 + Add new test case to ensure git-merge reduces octopus parents when
   possible
 + Introduce reduce_heads()
 + Introduce get_merge_bases_many()
 + Add new test to ensure git-merge handles more than 25 refs.
 + Introduce get_octopus_merge_bases() in commit.c
 + git-fmt-merge-msg: make it usable from other builtins
 + Move read_cache_unmerged() to read-cache.c
 + Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 + Move parse-options's skip_prefix() to git-compat-util.h
 + Move commit_list_count() to commit.c
 + Move split_cmdline() to alias.c

----------------------------------------------------------------
[Graduated to "master"]

* js/apply-root (Sun Jul 6 18:36:01 2008 -0700) 3 commits
 + git-apply --directory: make --root more similar to GNU diff
 + apply --root: thinkofix.
 + Teach "git apply" to prepend a prefix with "--root=<root>"

* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
 + Make default expiration period of reflog used for stash infinite
 + Per-ref reflog expiry configuration

As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.

* jk/pager-config (Thu Jul 3 07:46:57 2008 -0400) 1 commit
 + Allow per-command pager config

----------------------------------------------------------------
[On Hold]

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

----------------------------------------------------------------
[Stalled/Needs more work]

* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
 . Migrate git-am to use git-sequencer
 . Add git-sequencer test suite (t3350)
 . Add git-sequencer prototype documentation
 . Add git-sequencer shell prototype

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - [BROKEN wrt shallow clones] Ignore graft during object transfer

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-07-06 10:04                                                   ` Junio C Hamano
  2008-07-06 11:10                                                     ` Johannes Schindelin
@ 2008-07-08  2:46                                                     ` Junio C Hamano
  2008-07-10  2:32                                                       ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-07-08  2:46 UTC (permalink / raw)
  To: git

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.  The topics
meant to be applied to the maintenance series have "maint-" in their
names.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  Bigger changes will be:

 * Port for MinGW.

 * With the default Makefile settings, most of the programs will be
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical
   reasons.  Invoking a git subcommand as "git-xyzzy" from the command
   line has been deprecated since early 2006 (and officially announced in
   1.5.4 release notes); use of them from your scripts after adding
   output from "git --exec-path" to the $PATH will still be supported in
   1.6.0, but users are again strongly encouraged to adjust their
   scripts to use "git xyzzy" form, as we will stop installing
   "git-xyzzy" hardlinks for built-in commands in later releases.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

 * GIT_CONFIG, which was only documented as affecting "git config", but
   actually affected all git commands, now only affects "git config".
   GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
   not different from GIT_CONFIG in a useful way, is removed.

----------------------------------------------------------------
[New Topics]

* jc/rebase-orig-head (Mon Jul 7 00:16:38 2008 -0700) 1 commit
 + Teach "am" and "rebase" to mark the original position with
   ORIG_HEAD

* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
 . Migrate git-am to use git-sequencer
 . Add git-sequencer test suite (t3350)
 . Add git-sequencer prototype documentation
 . Add git-sequencer shell prototype

* js/pick-root (Fri Jul 4 16:19:52 2008 +0100) 1 commit
 + Allow cherry-picking root commits

* ab/bundle (Sat Jul 5 17:26:40 2008 -0400) 1 commit
 + Teach git-bundle to read revision arguments from stdin like git-
   rev-list.

----------------------------------------------------------------
[Will merge to master soon]

* js/apply-root (Sun Jul 6 18:36:01 2008 -0700) 3 commits
 + git-apply --directory: make --root more similar to GNU diff
 + apply --root: thinkofix.
 + Teach "git apply" to prepend a prefix with "--root=<root>"

* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
 + Make default expiration period of reflog used for stash infinite
 + Per-ref reflog expiry configuration

As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.

* jk/pager-config (Thu Jul 3 07:46:57 2008 -0400) 1 commit
 + Allow per-command pager config

----------------------------------------------------------------
[Actively Cooking]

* sg/stash-k-i (Fri Jun 27 16:37:15 2008 +0200) 1 commit
 + stash: introduce 'stash save --keep-index' option

One weakness of our "partial commit" workflow support used to be that the
user can incrementally build what is to be committed in the index but that
state cannot be tested as a whole in the working tree.  This allows you to
temporarily stash the remaining changes in the working tree so that the
index state before running "stash save --keep-index" can be seen in the
working tree to be tested and then committed.

* am/stash-branch (Mon Jul 7 02:50:10 2008 +0530) 2 commits
 + Add a test for "git stash branch"
 + Implement "git stash branch <newbranch> <stash>"

Creates a new branch out of the stashed state, after returning from the
interrupt that forced you to create the stash in the first place.

* tr/add-i-e (Thu Jul 3 00:00:00 2008 +0200) 3 commits
 + git-add--interactive: manual hunk editing mode
 + git-add--interactive: remove hunk coalescing
 + git-add--interactive: replace hunk recounting with apply --recount

Adds 'e/dit' action to interactive add command.

* jc/report-tracking (Sun Jul 6 02:54:56 2008 -0700) 5 commits
 + branch -r -v: do not spit out garbage
 + stat_tracking_info(): clear object flags used during counting
 + git-branch -v: show the remote tracking statistics
 + git-status: show the remote tracking statistics
 + Refactor "tracking statistics" code used by "git checkout"

Makes the "your branch is ahead of the tracked one by N commits" logic and
messages available to other commands; status and branch are updated.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

The -X<option> part may change, Dscho mentions that a single-letter -X
that take stuck option is against syntax rules, and I think he's right.

This is more "because we can", not "because we need to".

* mv/merge-in-c (Mon Jul 7 19:24:20 2008 +0200) 15 commits
 - Build in merge
 + Fix t7601-merge-pull-config.sh on AIX
 + git-commit-tree: make it usable from other builtins
 + Add new test case to ensure git-merge prepends the custom merge
   message
 + Add new test case to ensure git-merge reduces octopus parents when
   possible
 + Introduce reduce_heads()
 + Introduce get_merge_bases_many()
 + Add new test to ensure git-merge handles more than 25 refs.
 + Introduce get_octopus_merge_bases() in commit.c
 + git-fmt-merge-msg: make it usable from other builtins
 + Move read_cache_unmerged() to read-cache.c
 + Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 + Move parse-options's skip_prefix() to git-compat-util.h
 + Move commit_list_count() to commit.c
 + Move split_cmdline() to alias.c

----------------------------------------------------------------
[Graduated to "master"]

* js/import-zip (Mon Jun 30 19:50:44 2008 +0100) 1 commit
 + Add another fast-import example, this time for .zip files

* db/no-git-config (Mon Jun 30 03:37:47 2008 -0400) 1 commit
 + Only use GIT_CONFIG in "git config", not other programs

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 + rerere.autoupdate
 + t4200: fix rerere test
 + rerere: remove dubious "tail_optimization"
 + git-rerere: detect unparsable conflicts
 + rerere: rerere_created_at() and has_resolution() abstraction

A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.

* js/maint-daemon-syslog (Thu Jul 3 16:27:24 2008 +0100) 1 commit
 + git daemon: avoid calling syslog() from a signal handler

Meant for 'maint' as well.

----------------------------------------------------------------
[On Hold]

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

----------------------------------------------------------------
[Stalled/Needs more work]

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - [BROKEN wrt shallow clones] Ignore graft during object transfer

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
 - Migrate git-blame to parse-option partially.
 + parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 + parse-opt: fake short strings for callers to believe in.
 + parse-opt: do not print errors on unknown options, return -2
   intead.
 + parse-opt: create parse_options_step.
 + parse-opt: Export a non NORETURN usage dumper.
 + parse-opt: have parse_options_{start,end}.

I recall Pierre said something about cleaning up the last one when he
finds time, but other than that vague recollection, I lost track of this
series.  I am tempted to fork a few topics off of the penúltimo one to
convert a few more commands as examples and merge the result to 'next'.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-06 11:10                                                     ` Johannes Schindelin
@ 2008-07-07  1:36                                                       ` Junio C Hamano
  0 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-07-07  1:36 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

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

> On Sun, 6 Jul 2008, Junio C Hamano wrote:
>
>> * js/apply-root (Wed Jul 2 15:28:22 2008 -0700) 2 commits
>>  + apply --root: thinkofix.
>>  + Teach "git apply" to prepend a prefix with "--root=<root>"
>
> If we want to call this "--directory=<root>" instead, we should do it 
> before that commit hits master.

Yeah, perhaps like this?

-- >8 --
git-apply --directory: make --root more similar to GNU diff

Applying a patch in the directory that is different from what the patch
records is done with --directory option in GNU diff.  The --root option we
introduced previously does the same, and we can call it the same way to
give users more familiar feel.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/git-apply.txt |    8 ++++++--
 builtin-apply.c             |    4 ++--
 t/t4128-apply-root.sh       |    8 ++++----
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index 63fce53..3cd3179 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -14,7 +14,7 @@ SYNOPSIS
 	  [--allow-binary-replacement | --binary] [--reject] [-z]
 	  [-pNUM] [-CNUM] [--inaccurate-eof] [--cached]
 	  [--whitespace=<nowarn|warn|fix|error|error-all>]
-	  [--exclude=PATH] [--root=<root>] [--verbose] [<patch>...]
+	  [--exclude=PATH] [--directory=<root>] [--verbose] [<patch>...]
 
 DESCRIPTION
 -----------
@@ -177,9 +177,13 @@ behavior:
 	current patch being applied will be printed. This option will cause
 	additional information to be reported.
 
---root=<root>::
+--directory=<root>::
 	Prepend <root> to all filenames.  If a "-p" argument was passed, too,
 	it is applied before prepending the new root.
++
+For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh`
+can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by
+running `git apply --directory=modules/git-gui`.
 
 Configuration
 -------------
diff --git a/builtin-apply.c b/builtin-apply.c
index 6c3db60..c242bbd 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -3130,8 +3130,8 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
 			inaccurate_eof = 1;
 			continue;
 		}
-		if (!prefixcmp(arg, "--root=")) {
-			arg += strlen("--root=");
+		if (!prefixcmp(arg, "--directory=")) {
+			arg += strlen("--directory=");
 			root_len = strlen(arg);
 			if (root_len && arg[root_len - 1] != '/') {
 				char *new_root;
diff --git a/t/t4128-apply-root.sh b/t/t4128-apply-root.sh
index b650245..2dd0c75 100755
--- a/t/t4128-apply-root.sh
+++ b/t/t4128-apply-root.sh
@@ -23,18 +23,18 @@ diff a/bla/blub/dir/file b/bla/blub/dir/file
 +Bello
 EOF
 
-test_expect_success 'apply --root -p (1)' '
+test_expect_success 'apply --directory -p (1)' '
 
-	git apply --root=some/sub -p3 --index patch &&
+	git apply --directory=some/sub -p3 --index patch &&
 	test Bello = $(git show :some/sub/dir/file) &&
 	test Bello = $(cat some/sub/dir/file)
 
 '
 
-test_expect_success 'apply --root -p (2) ' '
+test_expect_success 'apply --directory -p (2) ' '
 
 	git reset --hard initial &&
-	git apply --root=some/sub/ -p3 --index patch &&
+	git apply --directory=some/sub/ -p3 --index patch &&
 	test Bello = $(git show :some/sub/dir/file) &&
 	test Bello = $(cat some/sub/dir/file)
 

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-07-06 10:04                                                   ` Junio C Hamano
@ 2008-07-06 11:10                                                     ` Johannes Schindelin
  2008-07-07  1:36                                                       ` Junio C Hamano
  2008-07-08  2:46                                                     ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Johannes Schindelin @ 2008-07-06 11:10 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Sun, 6 Jul 2008, Junio C Hamano wrote:

> * js/apply-root (Wed Jul 2 15:28:22 2008 -0700) 2 commits
>  + apply --root: thinkofix.
>  + Teach "git apply" to prepend a prefix with "--root=<root>"

If we want to call this "--directory=<root>" instead, we should do it 
before that commit hits master.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-07-02  4:41                                                 ` Junio C Hamano
@ 2008-07-06 10:04                                                   ` Junio C Hamano
  2008-07-06 11:10                                                     ` Johannes Schindelin
  2008-07-08  2:46                                                     ` Junio C Hamano
  0 siblings, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-07-06 10:04 UTC (permalink / raw)
  To: git

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.  The topics
meant to be applied to the maintenance series have "maint-" in their
names.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  Bigger changes will be:

 * Port for MinGW.

 * With the default Makefile settings, most of the programs will be
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical
   reasons.  Invoking a git subcommand as "git-xyzzy" from the command
   line has been deprecated since early 2006 (and officially announced in
   1.5.4 release notes); use of them from your scripts after adding
   output from "git --exec-path" to the $PATH will still be supported in
   1.6.0, but users are again strongly encouraged to adjust their
   scripts to use "git xyzzy" form, as we will stop installing
   "git-xyzzy" hardlinks for built-in commands in later releases.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

 * GIT_CONFIG, which was only documented as affecting "git config", but
   actually affected all git commands, now only affects "git config".
   GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
   not different from GIT_CONFIG in a useful way, is removed.

----------------------------------------------------------------
[New Topics]

* js/maint-daemon-syslog (Thu Jul 3 16:27:24 2008 +0100) 1 commit
 - [PARKED improvement suggested not rolled in] git daemon: avoid
   calling syslog() from a signal handler

This will eventually appear in 'maint'; currently parked on 'pu', though.

* jc/report-tracking (Sun Jul 6 02:54:56 2008 -0700) 5 commits
 - branch -r -v: do not spit out garbage
 + stat_tracking_info(): clear object flags used during counting
 + git-branch -v: show the remote tracking statistics
 + git-status: show the remote tracking statistics
 + Refactor "tracking statistics" code used by "git checkout"

Makes the "your branch is ahead of the tracked one by N commits" logic and
messages available to other commands; status and branch are updated.

* sg/stash-k-i (Fri Jun 27 16:37:15 2008 +0200) 1 commit
 - stash: introduce 'stash save --keep-index' option

One weakness of our "partial commit" workflow support used to be that the
user can incrementally build what is to be committed in the index but that
state cannot be tested as a whole in the working tree.  This allows you to
temporarily stash the remaining changes in the working tree so that the
index state before running "stash save --keep-index" can be seen in the
working tree to be tested and then committed.  A recommended workflow to
use after that commit is made needs to be documented (and support needs to
be added if necessary).

* tr/add-i-e (Thu Jul 3 00:00:00 2008 +0200) 3 commits
 + git-add--interactive: manual hunk editing mode
 + git-add--interactive: remove hunk coalescing
 + git-add--interactive: replace hunk recounting with apply --recount

Adds 'e/dit' action to interactive add command.

* am/stash-branch (Thu Jul 3 11:46:05 2008 +0530) 1 commit
 + Implement "git stash branch <newbranch> <stash>"

Creates a new branch out of the stashed state, after returning from the
interrupt that forced you to create the stash in the first place.

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - Ignore graft during object transfer [broken wrt shallow clones]

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* jk/pager-config (Thu Jul 3 07:46:57 2008 -0400) 1 commit
 - Allow per-command pager config

----------------------------------------------------------------
[Will merge to master soon]

* js/import-zip (Mon Jun 30 19:50:44 2008 +0100) 1 commit
 + Add another fast-import example, this time for .zip files

* js/apply-root (Wed Jul 2 15:28:22 2008 -0700) 2 commits
 + apply --root: thinkofix.
 + Teach "git apply" to prepend a prefix with "--root=<root>"

* db/no-git-config (Mon Jun 30 03:37:47 2008 -0400) 1 commit
 + Only use GIT_CONFIG in "git config", not other programs

* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
 + Make default expiration period of reflog used for stash infinite
 + Per-ref reflog expiry configuration

As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

This still feels "because we can", not "because we need to", but it came
from somebody who had the need to, and I do not think it hurts people
without the environment variable set.

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 + rerere.autoupdate
 + t4200: fix rerere test
 + rerere: remove dubious "tail_optimization"
 + git-rerere: detect unparsable conflicts
 + rerere: rerere_created_at() and has_resolution() abstraction

A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.

To me, this is "because we can", but was something requested by Ingo, so
presumably some people may feel it useful in their workflow.

----------------------------------------------------------------
[Actively Cooking]

* mv/merge-in-c (Tue Jul 1 04:37:50 2008 +0200) 15 commits
 - [REJECT -- over-abuse of path-list] Build in merge
 + Fix t7601-merge-pull-config.sh on AIX
 + git-commit-tree: make it usable from other builtins
 + Add new test case to ensure git-merge prepends the custom merge
   message
 + Add new test case to ensure git-merge reduces octopus parents when
   possible
 + Introduce reduce_heads()
 + Introduce get_merge_bases_many()
 + Add new test to ensure git-merge handles more than 25 refs.
 + Introduce get_octopus_merge_bases() in commit.c
 + git-fmt-merge-msg: make it usable from other builtins
 + Move read_cache_unmerged() to read-cache.c
 + Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 + Move parse-options's skip_prefix() to git-compat-util.h
 + Move commit_list_count() to commit.c
 + Move split_cmdline() to alias.c

The last one is still not quite there, I am afraid.

----------------------------------------------------------------
[Graduated to "master"]

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
 + compat/pread.c: Add a forward declaration to fix a warning
 + Windows: Fix ntohl() related warnings about printf formatting
 + Windows: TMP and TEMP environment variables specify a temporary
   directory.
 + Windows: Make 'git help -a' work.
 + Windows: Work around an oddity when a pipe with no reader is
   written to.
 + Windows: Make the pager work.
 + When installing, be prepared that template_dir may be relative.
 + Windows: Use a relative default template_dir and ETC_GITCONFIG
 + Windows: Compute the fallback for exec_path from the program
   invocation.
 + Turn builtin_exec_path into a function.
 + Windows: Use a customized struct stat that also has the st_blocks
   member.
 + Windows: Add a custom implementation for utime().
 + Windows: Add a new lstat and fstat implementation based on Win32
   API.
 + Windows: Implement a custom spawnve().
 + Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 + Windows: Work around incompatible sort and find.
 + Windows: Implement asynchronous functions as threads.
 + Windows: Disambiguate DOS style paths from SSH URLs.
 + Windows: A rudimentary poll() emulation.
 + Windows: Implement start_command().
 + Windows: A pipe() replacement whose ends are not inherited to
   children.
 + Windows: Wrap execve so that shell scripts can be invoked.
 + Windows: Implement setitimer() and sigaction().
 + Windows: Fix PRIuMAX definition.
 + Windows: Implement gettimeofday().
 + Make my_mktime() public and rename it to tm_to_time_t()
 + Windows: Work around misbehaved rename().
 + Windows: always chmod(, 0666) before unlink().
 + Windows: A minimal implemention of getpwuid().
 + Windows: Implement a wrapper of the open() function.
 + Windows: Strip ".exe" from the program name.
 + Windows: Handle absolute paths in
   safe_create_leading_directories().
 + Windows: Treat Windows style path names.
 + setup.c: Prepare for Windows directory separators.
 + Windows: Use the Windows style PATH separator ';'.
 + Add target architecture MinGW.
 + Compile some programs only conditionally.
 + Add compat/regex.[ch] and compat/fnmatch.[ch].

----------------------------------------------------------------
[On Hold]

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

----------------------------------------------------------------
[Stalled/Needs more work]

* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
 - Migrate git-blame to parse-option partially.
 + parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 + parse-opt: fake short strings for callers to believe in.
 + parse-opt: do not print errors on unknown options, return -2
   intead.
 + parse-opt: create parse_options_step.
 + parse-opt: Export a non NORETURN usage dumper.
 + parse-opt: have parse_options_{start,end}.

I recall Pierre said something about cleaning up the last one when he
finds time, but other than that vague recollection, I lost track of this
series.  I am tempted to fork a few topics off of the penúltimo one to
convert a few more commands as examples and merge the result to 'next'.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

The -X<option> part may change, Dscho mentions that a single-letter -X
that take stuck option is against syntax rules, and I think he's right.

This is more "because we can", not "because we need to".

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-06-30  9:08                                               ` Junio C Hamano
  2008-06-30 14:09                                                 ` Kristian Høgsberg
  2008-07-01 10:11                                                 ` Jeff King
@ 2008-07-02  4:41                                                 ` Junio C Hamano
  2008-07-06 10:04                                                   ` Junio C Hamano
  2 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-07-02  4:41 UTC (permalink / raw)
  To: git

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.  The topics
meant to be applied to the maintenance series have "maint-" in their
names.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  Bigger changes will be:

 * MinGW will be in.

 * With the default Makefile settings, most of the programs will be
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical
   reasons.  Invoking a git subcommand as "git-xyzzy" from the command
   line has been deprecated since early 2006 (and officially announced in
   1.5.4 release notes); use of them from your scripts after adding
   output from "git --exec-path" to the $PATH will still be supported in
   1.6.0, but users are again strongly encouraged to adjust their
   scripts to use "git xyzzy" form, as we will stop installing
   "git-xyzzy" hardlinks for built-in commands in later releases.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

 * GIT_CONFIG, which was only documented as affecting "git config", but
   actually affected all git commands, now only affects "git config".
   GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
   not different from GIT_CONFIG in a useful way, is removed.

----------------------------------------------------------------
[New Topics]

* js/import-zip (Mon Jun 30 19:50:44 2008 +0100) 1 commit
 + Add another fast-import example, this time for .zip files

* js/apply-root (Tue Jul 1 00:44:47 2008 +0100) 1 commit
 + Teach "git apply" to prepend a prefix with "--root=<root>"

* db/no-git-config (Mon Jun 30 03:37:47 2008 -0400) 1 commit
 + Only use GIT_CONFIG in "git config", not other programs

----------------------------------------------------------------
[Will merge to master soon]

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
 + compat/pread.c: Add a forward declaration to fix a warning
 + Windows: Fix ntohl() related warnings about printf formatting
 + Windows: TMP and TEMP environment variables specify a temporary
   directory.
 + Windows: Make 'git help -a' work.
 + Windows: Work around an oddity when a pipe with no reader is
   written to.
 + Windows: Make the pager work.
 + When installing, be prepared that template_dir may be relative.
 + Windows: Use a relative default template_dir and ETC_GITCONFIG
 + Windows: Compute the fallback for exec_path from the program
   invocation.
 + Turn builtin_exec_path into a function.
 + Windows: Use a customized struct stat that also has the st_blocks
   member.
 + Windows: Add a custom implementation for utime().
 + Windows: Add a new lstat and fstat implementation based on Win32
   API.
 + Windows: Implement a custom spawnve().
 + Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 + Windows: Work around incompatible sort and find.
 + Windows: Implement asynchronous functions as threads.
 + Windows: Disambiguate DOS style paths from SSH URLs.
 + Windows: A rudimentary poll() emulation.
 + Windows: Implement start_command().
 + Windows: A pipe() replacement whose ends are not inherited to
   children.
 + Windows: Wrap execve so that shell scripts can be invoked.
 + Windows: Implement setitimer() and sigaction().
 + Windows: Fix PRIuMAX definition.
 + Windows: Implement gettimeofday().
 + Make my_mktime() public and rename it to tm_to_time_t()
 + Windows: Work around misbehaved rename().
 + Windows: always chmod(, 0666) before unlink().
 + Windows: A minimal implemention of getpwuid().
 + Windows: Implement a wrapper of the open() function.
 + Windows: Strip ".exe" from the program name.
 + Windows: Handle absolute paths in
   safe_create_leading_directories().
 + Windows: Treat Windows style path names.
 + setup.c: Prepare for Windows directory separators.
 + Windows: Use the Windows style PATH separator ';'.
 + Add target architecture MinGW.
 + Compile some programs only conditionally.
 + Add compat/regex.[ch] and compat/fnmatch.[ch].

No explanation necessary ;-)

----------------------------------------------------------------
[Actively Cooking]

* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
 - Make default expiration period of reflog used for stash infinite
 - Per-ref reflog expiry configuration

As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.

We may want to change the commit topology used to represent a stash, as
proposed in $gmane/85055 by Nana earlier.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 4 commits
 - Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

* mv/merge-in-c (Tue Jul 1 04:37:50 2008 +0200) 14 commits
 - Build in merge
 - git-commit-tree: make it usable from other builtins
 - Add new test case to ensure git-merge prepends the custom merge
   message
 - Add new test case to ensure git-merge reduces octopus parents when
   possible
 - Introduce reduce_heads()
 - Introduce get_merge_bases_many()
 - Add new test to ensure git-merge handles more than 25 refs.
 - Introduce get_octopus_merge_bases() in commit.c
 - git-fmt-merge-msg: make it usable from other builtins
 - Move read_cache_unmerged() to read-cache.c
 - Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 - Move parse-options's skip_prefix() to git-compat-util.h
 - Move commit_list_count() to commit.c
 - Move split_cmdline() to alias.c

I think this is getting there.  Will be in 'next' soon.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 + rerere.autoupdate
 + t4200: fix rerere test
 + rerere: remove dubious "tail_optimization"
 + git-rerere: detect unparsable conflicts
 + rerere: rerere_created_at() and has_resolution() abstraction

A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.

* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
 - Migrate git-blame to parse-option partially.
 - parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 - parse-opt: fake short strings for callers to believe in.
 - parse-opt: do not print errors on unknown options, return -2
   intead.
 - parse-opt: create parse_options_step.
 - parse-opt: Export a non NORETURN usage dumper.
 - parse-opt: have parse_options_{start,end}.

I recall Pierre said something about cleaning up the last one when he
finds time, but other than that vague recollection, I lost track of this
series.  I am tempted to fork a few topics off of the penúltimo one to
convert a few more commands as examples and merge the result to 'next'.

----------------------------------------------------------------
[Graduated to "master"]

* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
 + Remove the use of '--' in merge program invocation

I got tired of waiting for success reports from people who use various
backends.  We will hear breakages if this breaks things anyway, and if it
does, it is a fairly simple single patch to revert.

* nd/dashless (Tue Jun 24 19:58:11 2008 -0700) 2 commits
 + Keep some git-* programs in $(bindir)
 + Move all dashed-form commands to libexecdir

We'll leave server-side programs in $(bindir) so that ssh clients can ask
for "git-program" and find them on the $PATH.  Next major release after
1.6.0 would most likely remove the hardlinks to built-in commands, but not
yet.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 + git-shell: accept "git foo" form

The botched "client asks 'git foo'" is not included.  It will be long
after everybody runs 1.6.0.

* jk/maint-fetch-ref-hier (Fri Jun 27 00:01:41 2008 -0400) 2 commits
 + fetch: give a hint to the user when local refs fail to update
 + fetch: report local storage errors in status table

When the remote used to have "foo" branch but now has "foo/bar", fetch
refuses to delete the existing remote tracking branch "foo" to create a
new remote tracking branch "foo/bar", but the error message was
confusing.

Need to backmerge to 'maint' after a while.

* jc/maint-reset (Wed Jun 25 18:16:36 2008 -0700) 1 commit
 + Allow "git-reset path" when unambiguous

We used to require "git-reset -- path" even when there is no ambiguity
(i.e. path cannot be mistaken as a valid tree-ish and it is a filename in
the work tree).

Need to backmerge to 'maint' after a while.

* js/maint-clone-insteadof (Fri Jun 27 13:55:23 2008 +0100) 2 commits
 + clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
 + clone: respect url.insteadOf setting in global configs

"git clone" did not honor "url.InsteadOf" in $HOME/.gitconfig.  I think
Daniel's "Let's get rid of internal use of GIT_CONFIG" makes sense (even
though it feels very scary), and it would make the solution much simpler,
but these two are independently good fix for now.  I'll queue GIT_CONFIG
one in 'next' and when it graduates the unsetenv() solution in these will
become no-op.

* tr/send-email-ssl (Thu Jun 26 23:03:21 2008 +0200) 2 commits
 + git-send-email: prevent undefined variable warnings if no
   encryption is set
 + git-send-email: add support for TLS via Net::SMTP::SSL

* kb/send-email-fifo (Wed Jun 25 15:44:40 2008 -0700) 1 commit
 + git-send-email: Accept fifos as well as files

Two minor send-email feature enhancements.

* jc/checkdiff (Sun Jun 29 16:49:06 2008 -0400) 7 commits
 + Fix t4017-diff-retval for white-space from wc
 + Update sample pre-commit hook to use "diff --check"
 + diff --check: detect leftover conflict markers
 + Teach "diff --check" about new blank lines at end
 + checkdiff: pass diff_options to the callback
 + check_and_emit_line(): rename and refactor
 + diff --check: explain why we do not care whether old side is
   binary

Allows us to replace the sample pre-commit hook that was not aware of the
line termination convention per path nor newer whitespace breakage rules.

* np/pack-default (Wed Jun 25 00:25:53 2008 -0400) 2 commits
 + pack.indexversion config option now defaults to 2
 + repack.usedeltabaseoffset config option now defaults to "true"

Updates the default value for pack.indexversion to 2 and use delta-base
offset encoding of the packfiles by default.

* js/apply-recount (Fri Jun 27 18:43:09 2008 +0100) 1 commit
 + Allow git-apply to recount the lines in a hunk (AKA recountdiff)

A good ingredient for implementing "apply --edit".

* dz/apply-again (Fri Jun 27 14:39:12 2008 -0400) 1 commit
 + git-apply: handle a patch that touches the same path more than
   once better

Allows us to feed a patch that touches the same path more than once.

----------------------------------------------------------------
[On Hold]

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

----------------------------------------------------------------
[Stalled/Needs more work]

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

----------------------------------------------------------------
[Dropped for now]

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 . Introduce fast forward option only
 . Head reduction before selecting merge strategy
 . Restructure git-merge.sh
 . Introduce -ff=<fast forward option>
 . New merge tests
 . Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 . Use perl instead of tac
 . Fix t3404 assumption that `wc -l` does not use whitespace.
 . rebase -i: Use : in expr command instead of match.
 . rebase -i: update the implementation of 'mark' command
 . Add option --preserve-tags
 . Teach rebase interactive the tag command
 . Add option --first-parent
 . Do rebase with preserve merges with advanced TODO list
 . Select all lines with fake-editor
 . Unify the length of $SHORT* and the commits in the TODO list
 . Teach rebase interactive the merge command
 . Move redo merge code in a function
 . Teach rebase interactive the reset command
 . Teach rebase interactive the mark command
 . Move cleanup code into it's own function
 . Don't append default merge message to -m message
 . fake-editor: output TODO list if unchanged

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 . WIP: rethink replay merge
 . Start using replay-tree merge in cherry-pick
 . revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 . git-am --forge: add Signed-off-by: line for the author
 . git-am: clean-up Signed-off-by: lines
 . stripspace: add --log-clean option to clean up signed-off-by:
   lines
 . stripspace: use parse_options()
 . Add "git am -s" test
 . git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 . "git push": tellme-more protocol extension

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-30 22:15                                                   ` Junio C Hamano
                                                                       ` (2 preceding siblings ...)
  2008-07-01  0:57                                                     ` Stephen Rothwell
@ 2008-07-01 15:44                                                     ` Kristian Høgsberg
  3 siblings, 0 replies; 575+ messages in thread
From: Kristian Høgsberg @ 2008-07-01 15:44 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, akpm, Stephen Rothwell, pasky

On Mon, 2008-06-30 at 15:15 -0700, Junio C Hamano wrote:
> Kristian Høgsberg <krh@redhat.com> writes:
> 
> > On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote:
> > ...
> >> It already is beginning to become clear what 1.6.0 will look like.  What's
> >> already in 'next' all are well intentioned (I do not guarantee they are
> >> already bug-free --- that is what cooking them in 'next' is for) and are
> >> good set of feature enhancements.  Bigger changes will be:
> > ...
> > A small detail I've suggested scheduling for 1.6 before is removing (or
> > rather, stop creating) the empty .git/branches directory.  How does that
> > sound?
> 
> What's the benefit of the removal that outweighs the downside?  I can
> imagine two contradicting voices from new end users.
> 
>  (1) With current git, I ran "git init" and I have an empty
>      .git/branches/, but my remote information created with "git clone"
>      and "git remote add" all go to .git/config these days.  Why do I have
>      to have this empty directory that I do not use?

Yeah, that's one reason, my main problem with .git/branches is that for
a user that wants to learn about git and peeks into .git it's pretty
confusing.  "I wonder where and how git stores the information about
branches... oh look, .git/branches, that must it... hmm, wait no..."
Git is still getting a lot of bad-mouthing for being hard to learn and
inconsitent.  I think it makes sense to push git towards consistency and
simplicity (where is doesn't affect the flexibility) and this seemed
like a tiny step towards that.  As Dscho mentioned we have two other
ways of accomplishing what .git/branches did, so maybe it makes sense to
retire this one?

>  (2) It is documented that "git fetch" can use files in .git/branches/ as
>      the source specification, but when I ran "git init", it does not
>      create the directory with Kristian's git. I need to do an extra
>      "mkdir .git/branches/" myself.  Why?

We could just change the documentation to ask the user to create
the .git/branches directory if they want to use that feature.

> You are obviously coming from the former camp, but do you have a good
> answer to people from the other camp?
> 
> I do not recall if Cogito required to have .git/branches created by us or
> it can create it on demand if we don't.  If the latter, that would be
> great, otherwise remaining users would be in the latter camp as well, and
> we may have to make sure Cogito is really dead already (or wait for it to
> die), or Cogito gets updated for its remaining users to tolerate the
> initial lack of the directory (and wait for that version percolates down
> to the users).
> 
> Some people rely on (or at least "like") the convenience of being able to
> create a single-liner file in .git/branches/ to easily add, and remove
> such a file to easily remove where they integrate from.  This is
> especially so when they have dozens of source repositories to fetch from.
> I do not think we want to remove support for .git/branches as a way to
> specify fetch sources (this is why I am CC'ing Andrew who I know uses
> branches, and Stephen who is also a heavy integrator even though I do not
> know if he is in branches camp or uses more modern style), but they now
> have to do an extra "mkdir .git/branches" after "git init" to continue
> their workflow if we adopt the change you are proposing here.  It is not a
> big deal, but it still is a backward incompatible change.

Yeah... I have to confess, that when I suggested removing it, I was
under the impression that git didn't use .git/branches, but only created
it to be nice to cogito.  I just read the code in remote.c that deals
with .git/branches and understand that it's still used by git.  From the
feedback from Stephen, Andrew and Pasky, it looks like we can drop
the .git/branches from the template for 1.6 and maybe in the future, we
could drop the .git/branches support entirely.  Dunno.

cheers,
Kristian

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-30  9:08                                               ` Junio C Hamano
  2008-06-30 14:09                                                 ` Kristian Høgsberg
@ 2008-07-01 10:11                                                 ` Jeff King
  2008-07-02  4:41                                                 ` Junio C Hamano
  2 siblings, 0 replies; 575+ messages in thread
From: Jeff King @ 2008-07-01 10:11 UTC (permalink / raw)
  To: Thomas Rast; +Cc: Junio C Hamano, Johannes Schindelin, git

On Mon, Jun 30, 2008 at 02:08:56AM -0700, Junio C Hamano wrote:

> * js/apply-recount (Fri Jun 27 18:43:09 2008 +0100) 1 commit
>  + Allow git-apply to recount the lines in a hunk (AKA recountdiff)
> 
> A good ingredient for implementing "apply --edit".

Thomas,

Now that this is in next, maybe it is a good time to repost the
add--interactive patch (it should be independent of Dscho's 2/2 "add -e"
patch).

-Peff

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-30 22:15                                                   ` Junio C Hamano
  2008-06-30 22:51                                                     ` Andrew Morton
  2008-06-30 22:53                                                     ` Petr Baudis
@ 2008-07-01  0:57                                                     ` Stephen Rothwell
  2008-07-01 15:44                                                     ` Kristian Høgsberg
  3 siblings, 0 replies; 575+ messages in thread
From: Stephen Rothwell @ 2008-07-01  0:57 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Kristian Høgsberg, git, akpm, pasky

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On Mon, 30 Jun 2008 15:15:52 -0700 Junio C Hamano <gitster@pobox.com> wrote:
>
> branches, and Stephen who is also a heavy integrator even though I do not
> know if he is in branches camp or uses more modern style), but they now

I use "git remote add" for each new repository and haven't had anything
in the branches directory of any of my trees for a long time ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-30 22:51                                                     ` Andrew Morton
@ 2008-06-30 23:09                                                       ` Johannes Schindelin
  0 siblings, 0 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-06-30 23:09 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Junio C Hamano, krh, git, sfr, pasky

Hi,

On Mon, 30 Jun 2008, Andrew Morton wrote:

> - It's bad to have the same info in two places, and to have to
>   support two different ways of doing the same thing for ever.

It is actually worse: we have three places.

>   For me the biggest part of migrating would be working out what on
>   earth the format of the new files is.  Maybe it's documented
>   somewhere undiscoverable, dunno.

The easiest way is to

	git config remote.$NICKNAME.url $URL

where you said

	echo $URL > .git/branches/$NICKNAME

Actually, you might even like this command better:

	git remote add $NICKNAME $URL

Many ways to go to Rome,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-30 22:15                                                   ` Junio C Hamano
  2008-06-30 22:51                                                     ` Andrew Morton
@ 2008-06-30 22:53                                                     ` Petr Baudis
  2008-07-01  0:57                                                     ` Stephen Rothwell
  2008-07-01 15:44                                                     ` Kristian Høgsberg
  3 siblings, 0 replies; 575+ messages in thread
From: Petr Baudis @ 2008-06-30 22:53 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Kristian H??gsberg, git, akpm, Stephen Rothwell

On Mon, Jun 30, 2008 at 03:15:52PM -0700, Junio C Hamano wrote:
> I do not recall if Cogito required to have .git/branches created by us or
> it can create it on demand if we don't.  If the latter, that would be
> great, otherwise remaining users would be in the latter camp as well, and
> we may have to make sure Cogito is really dead already (or wait for it to
> die), or Cogito gets updated for its remaining users to tolerate the
> initial lack of the directory (and wait for that version percolates down
> to the users).

Cogito is getting somewhat broken by removing of the git- plumbing from
$PATH anyway (you have to hack around it; and I'm not saying it's bad
thing).

But it is actually quite resilient against this kind of stuff (as it was
constructed to be able to run on very rudimental repositories dating
early to the dawn of time). All versions supporting .git/branches [*] will
autocreate the .git/branches directory if missing.

[*] .git/branches was actually called .git/remotes even earlier; yay,
how rich our history is. ;-)

> Some people rely on (or at least "like") the convenience of being able to
> create a single-liner file in .git/branches/ to easily add, and remove
> such a file to easily remove where they integrate from.  This is
> especially so when they have dozens of source repositories to fetch from.
> I do not think we want to remove support for .git/branches as a way to
> specify fetch sources (this is why I am CC'ing Andrew who I know uses
> branches, and Stephen who is also a heavy integrator even though I do not
> know if he is in branches camp or uses more modern style), but they now
> have to do an extra "mkdir .git/branches" after "git init" to continue
> their workflow if we adopt the change you are proposing here.  It is not a
> big deal, but it still is a backward incompatible change.

Now, I think it would be nice to keep backward compatibility here. I'm
still _regularly_ running into people who still use Cogito (and it's not
because they know me :-)) and are only now doing the switch, or only
planning to yet.

(On the other hand, using Git on repositories created by old Git
versions or Cogito can be quite a confusing experience for non-expert
users - things related to remote repositories behave differently to what
the documentation describes, obviously.  Maybe it _would_ be reasonable
option to do something radical when hitting old repository, like
"(Re-)clone me for non-confusing user experience, pretty please, or
git-config force_old_repo 1 if you know what are you doing.")

-- 
				Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-30 22:15                                                   ` Junio C Hamano
@ 2008-06-30 22:51                                                     ` Andrew Morton
  2008-06-30 23:09                                                       ` Johannes Schindelin
  2008-06-30 22:53                                                     ` Petr Baudis
                                                                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 575+ messages in thread
From: Andrew Morton @ 2008-06-30 22:51 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: krh, git, sfr, pasky

On Mon, 30 Jun 2008 15:15:52 -0700
Junio C Hamano <gitster@pobox.com> wrote:

> Some people rely on (or at least "like") the convenience of being able to
> create a single-liner file in .git/branches/ to easily add, and remove
> such a file to easily remove where they integrate from.  This is
> especially so when they have dozens of source repositories to fetch from.
> I do not think we want to remove support for .git/branches as a way to
> specify fetch sources (this is why I am CC'ing Andrew who I know uses
> branches, and Stephen who is also a heavy integrator even though I do not
> know if he is in branches camp or uses more modern style), but they now
> have to do an extra "mkdir .git/branches" after "git init" to continue
> their workflow if we adopt the change you are proposing here.  It is not a
> big deal, but it still is a backward incompatible change.

I do find the more compact format of .git/branches/git-foo to be
convenient.  For example, my scripts go looking in there for the URL
and add that to the patch changelog so that people can reconstruct -mm's
git-foo.patch from the relevant git tree.

That being said,

- It wouldn't bother me to have to type `mkdir .git/branches' after
  `git init'!

- It's bad to have the same info in two places, and to have to
  support two different ways of doing the same thing for ever.  So I
  could understand a wish to remove .git/branches/ support completely. 
  I'll cope :)

  For me the biggest part of migrating would be working out what on
  earth the format of the new files is.  Maybe it's documented
  somewhere undiscoverable, dunno.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-30 14:09                                                 ` Kristian Høgsberg
  2008-06-30 15:58                                                   ` Jakub Narebski
@ 2008-06-30 22:15                                                   ` Junio C Hamano
  2008-06-30 22:51                                                     ` Andrew Morton
                                                                       ` (3 more replies)
  1 sibling, 4 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-06-30 22:15 UTC (permalink / raw)
  To: Kristian Høgsberg; +Cc: git, akpm, Stephen Rothwell, pasky

Kristian Høgsberg <krh@redhat.com> writes:

> On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote:
> ...
>> It already is beginning to become clear what 1.6.0 will look like.  What's
>> already in 'next' all are well intentioned (I do not guarantee they are
>> already bug-free --- that is what cooking them in 'next' is for) and are
>> good set of feature enhancements.  Bigger changes will be:
> ...
> A small detail I've suggested scheduling for 1.6 before is removing (or
> rather, stop creating) the empty .git/branches directory.  How does that
> sound?

What's the benefit of the removal that outweighs the downside?  I can
imagine two contradicting voices from new end users.

 (1) With current git, I ran "git init" and I have an empty
     .git/branches/, but my remote information created with "git clone"
     and "git remote add" all go to .git/config these days.  Why do I have
     to have this empty directory that I do not use?

 (2) It is documented that "git fetch" can use files in .git/branches/ as
     the source specification, but when I ran "git init", it does not
     create the directory with Kristian's git. I need to do an extra
     "mkdir .git/branches/" myself.  Why?

You are obviously coming from the former camp, but do you have a good
answer to people from the other camp?

I do not recall if Cogito required to have .git/branches created by us or
it can create it on demand if we don't.  If the latter, that would be
great, otherwise remaining users would be in the latter camp as well, and
we may have to make sure Cogito is really dead already (or wait for it to
die), or Cogito gets updated for its remaining users to tolerate the
initial lack of the directory (and wait for that version percolates down
to the users).

Some people rely on (or at least "like") the convenience of being able to
create a single-liner file in .git/branches/ to easily add, and remove
such a file to easily remove where they integrate from.  This is
especially so when they have dozens of source repositories to fetch from.
I do not think we want to remove support for .git/branches as a way to
specify fetch sources (this is why I am CC'ing Andrew who I know uses
branches, and Stephen who is also a heavy integrator even though I do not
know if he is in branches camp or uses more modern style), but they now
have to do an extra "mkdir .git/branches" after "git init" to continue
their workflow if we adopt the change you are proposing here.  It is not a
big deal, but it still is a backward incompatible change.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-30 15:58                                                   ` Jakub Narebski
@ 2008-06-30 22:15                                                     ` Junio C Hamano
  0 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-06-30 22:15 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: Kristian Høgsberg, git

Jakub Narebski <jnareb@gmail.com> writes:

> Kristian Høgsberg <krh@redhat.com> writes:
>
>> 
>> A small detail I've suggested scheduling for 1.6 before is removing (or
>> rather, stop creating) the empty .git/branches directory.  How does that
>> sound?
>
> Perhaps also stop creating .git/description (remove
> 'templates/this--description' file), now that it is mentioned in
> gitweb/README and/or gitweb/INSTALL?
>
> (Do you want a patch?)

Not yet.  I would first like to see a justification that makes sense.

I do not see much connection between your mentioning the file in README
and the file's removal.  You currently say "By default it is set to ..."
and you would have to change it to "By default it does not exist so you
have to create one".  Does it have much difference?  Either way the user
needs to open the file with the editor and edit it, and the current file
at least says "Please edit me".  I am not sure if removal is an
improvement.

The sample templates/hooks--update.sample seems to check if the contents
of the description file makes sense, without even checking if it exists.
That also needs to be updated.

Actually, the sample hook should be updated independent of this issue.
I'd suggest to simply remove the check from the sample hook.  Setting
description and installing the hook is part of the initial public
repository deployment task, and once the description is set, the hook does
not have to check it over and over again.  Allowing arrival of new commits
while the description is not set won't hurt anything (somebody would
notice and tell "please set a better description" to the repository owner,
and doing so at that point will fix things without anybody having to redo
any old pushes), and forbidding push from the hook for lack of description
does not make any sense.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-30 14:09                                                 ` Kristian Høgsberg
@ 2008-06-30 15:58                                                   ` Jakub Narebski
  2008-06-30 22:15                                                     ` Junio C Hamano
  2008-06-30 22:15                                                   ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Jakub Narebski @ 2008-06-30 15:58 UTC (permalink / raw)
  To: Kristian Høgsberg; +Cc: Junio C Hamano, git

Kristian Høgsberg <krh@redhat.com> writes:

> 
> A small detail I've suggested scheduling for 1.6 before is removing (or
> rather, stop creating) the empty .git/branches directory.  How does that
> sound?

Perhaps also stop creating .git/description (remove
'templates/this--description' file), now that it is mentioned in
gitweb/README and/or gitweb/INSTALL?

(Do you want a patch?)
-- 
Jakub Narebski
Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-29  8:55                                             ` Junio C Hamano
                                                                 ` (2 preceding siblings ...)
  2008-06-30  9:08                                               ` Junio C Hamano
@ 2008-06-30 14:59                                               ` Brandon Casey
  3 siblings, 0 replies; 575+ messages in thread
From: Brandon Casey @ 2008-06-30 14:59 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano wrote:

> * jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
>  - Make default expiration period of reflog used for stash infinite
>  - Per-ref reflog expiry configuration

Thanks.

-brandon

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-30  9:08                                               ` Junio C Hamano
@ 2008-06-30 14:09                                                 ` Kristian Høgsberg
  2008-06-30 15:58                                                   ` Jakub Narebski
  2008-06-30 22:15                                                   ` Junio C Hamano
  2008-07-01 10:11                                                 ` Jeff King
  2008-07-02  4:41                                                 ` Junio C Hamano
  2 siblings, 2 replies; 575+ messages in thread
From: Kristian Høgsberg @ 2008-06-30 14:09 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote:
> 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.  The topics
> meant to be applied to the maintenance series have "maint-" in their
> names.
> 
> It already is beginning to become clear what 1.6.0 will look like.  What's
> already in 'next' all are well intentioned (I do not guarantee they are
> already bug-free --- that is what cooking them in 'next' is for) and are
> good set of feature enhancements.  Bigger changes will be:
> 
>  * MinGW will be in.
> 
>  * With the default Makefile settings, most of the programs will be
>    installed outside your $PATH, except for "git", "gitk", "git-gui" and
>    some server side programs that need to be accessible for technical
>    reasons.  Invoking a git subcommand as "git-xyzzy" from the command
>    line has been deprecated since early 2006 (and officially announced in
>    1.5.4 release notes); use of them from your scripts after adding
>    output from "git --exec-path" to the $PATH will still be supported in
>    1.6.0, but users are again strongly encouraged to adjust their
>    scripts to use "git xyzzy" form, as we will stop installing
>    "git-xyzzy" hardlinks for built-in commands in later releases.
> 
>  * git-merge will be rewritten in C.
> 
>  * default pack and idx versions will be updated as scheduled for some
>    time ago.

A small detail I've suggested scheduling for 1.6 before is removing (or
rather, stop creating) the empty .git/branches directory.  How does that
sound?

cheers,
Kristian

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-06-29  8:55                                             ` Junio C Hamano
  2008-06-29 18:35                                               ` Linus Torvalds
  2008-06-30  3:30                                               ` Jeff King
@ 2008-06-30  9:08                                               ` Junio C Hamano
  2008-06-30 14:09                                                 ` Kristian Høgsberg
                                                                   ` (2 more replies)
  2008-06-30 14:59                                               ` Brandon Casey
  3 siblings, 3 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-06-30  9:08 UTC (permalink / raw)
  To: git

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.  The topics
meant to be applied to the maintenance series have "maint-" in their
names.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  Bigger changes will be:

 * MinGW will be in.

 * With the default Makefile settings, most of the programs will be
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical
   reasons.  Invoking a git subcommand as "git-xyzzy" from the command
   line has been deprecated since early 2006 (and officially announced in
   1.5.4 release notes); use of them from your scripts after adding
   output from "git --exec-path" to the $PATH will still be supported in
   1.6.0, but users are again strongly encouraged to adjust their
   scripts to use "git xyzzy" form, as we will stop installing
   "git-xyzzy" hardlinks for built-in commands in later releases.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

----------------------------------------------------------------
[Will merge to master soon]

* nd/dashless (Tue Jun 24 19:58:11 2008 -0700) 2 commits
 + Keep some git-* programs in $(bindir)
 + Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  We'll leave server-side programs in $(bindir) so
that ssh clients can ask for "git-program" and find them on the $PATH.
Next major release after 1.6.0 would most likely remove the hardlinks to
built-in commands, but not yet.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 4 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport
 + Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 + git-shell: accept "git foo" form

----------------------------------------------------------------
[Actively Cooking]

* jk/maint-fetch-ref-hier (Fri Jun 27 00:01:41 2008 -0400) 2 commits
 + fetch: give a hint to the user when local refs fail to update
 + fetch: report local storage errors in status table

When the remote used to have "foo" branch but now has "foo/bar", fetch
refuses to delete the existing remote tracking branch "foo" to create a
new remote tracking branch "foo/bar", but the error message was
confusing.

* jc/maint-reset (Wed Jun 25 18:16:36 2008 -0700) 1 commit
 + Allow "git-reset path" when unambiguous

We used to require "git-reset -- path" even when there is no ambiguity
(i.e. path cannot be mistaken as a valid tree-ish and it is a filename in
the work tree).

* js/maint-clone-insteadof (Fri Jun 27 13:55:23 2008 +0100) 2 commits
 + clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
 + clone: respect url.insteadOf setting in global configs

"git clone" did not honor "url.InsteadOf" in $HOME/.gitconfig.  I think
Daniel's "Let's get rid of internal use of GIT_CONFIG" makes sense (even
though it feels very scary), and it would make the solution much simpler,
but it came late and it is already past my bedtime, so...

* tr/send-email-ssl (Thu Jun 26 23:03:21 2008 +0200) 2 commits
 + git-send-email: prevent undefined variable warnings if no
   encryption is set
 + git-send-email: add support for TLS via Net::SMTP::SSL

* kb/send-email-fifo (Wed Jun 25 15:44:40 2008 -0700) 1 commit
 + git-send-email: Accept fifos as well as files

Two minor send-email feature enhancements for 1.6.0.

* jc/checkdiff (Sun Jun 29 16:49:06 2008 -0400) 7 commits
 + Fix t4017-diff-retval for white-space from wc
 + Update sample pre-commit hook to use "diff --check"
 + diff --check: detect leftover conflict markers
 + Teach "diff --check" about new blank lines at end
 + checkdiff: pass diff_options to the callback
 + check_and_emit_line(): rename and refactor
 + diff --check: explain why we do not care whether old side is
   binary

Allows us to replace the sample pre-commit hook that was not aware of the
line termination convention per path nor newer whitespace breakage rules.

* np/pack-default (Wed Jun 25 00:25:53 2008 -0400) 2 commits
 + pack.indexversion config option now defaults to 2
 + repack.usedeltabaseoffset config option now defaults to "true"

Updates the default value for pack.indexversion to 2 and use delta-base
offset encoding of the packfiles by default.

* js/apply-recount (Fri Jun 27 18:43:09 2008 +0100) 1 commit
 + Allow git-apply to recount the lines in a hunk (AKA recountdiff)

A good ingredient for implementing "apply --edit".

* dz/apply-again (Fri Jun 27 14:39:12 2008 -0400) 1 commit
 + git-apply: handle a patch that touches the same path more than
   once better

Allows us to feed a patch that touches the same path more than once.

* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
 - Make default expiration period of reflog used for stash infinite
 - Per-ref reflog expiry configuration

As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.

* jc/merge-theirs (Sat Jun 28 17:28:22 2008 -0700) 3 commits
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -s recursive other" now.

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
 + compat/pread.c: Add a forward declaration to fix a warning
 + Windows: Fix ntohl() related warnings about printf formatting
 + Windows: TMP and TEMP environment variables specify a temporary
   directory.
 + Windows: Make 'git help -a' work.
 + Windows: Work around an oddity when a pipe with no reader is
   written to.
 + Windows: Make the pager work.
 + When installing, be prepared that template_dir may be relative.
 + Windows: Use a relative default template_dir and ETC_GITCONFIG
 + Windows: Compute the fallback for exec_path from the program
   invocation.
 + Turn builtin_exec_path into a function.
 + Windows: Use a customized struct stat that also has the st_blocks
   member.
 + Windows: Add a custom implementation for utime().
 + Windows: Add a new lstat and fstat implementation based on Win32
   API.
 + Windows: Implement a custom spawnve().
 + Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 + Windows: Work around incompatible sort and find.
 + Windows: Implement asynchronous functions as threads.
 + Windows: Disambiguate DOS style paths from SSH URLs.
 + Windows: A rudimentary poll() emulation.
 + Windows: Implement start_command().
 + Windows: A pipe() replacement whose ends are not inherited to
   children.
 + Windows: Wrap execve so that shell scripts can be invoked.
 + Windows: Implement setitimer() and sigaction().
 + Windows: Fix PRIuMAX definition.
 + Windows: Implement gettimeofday().
 + Make my_mktime() public and rename it to tm_to_time_t()
 + Windows: Work around misbehaved rename().
 + Windows: always chmod(, 0666) before unlink().
 + Windows: A minimal implemention of getpwuid().
 + Windows: Implement a wrapper of the open() function.
 + Windows: Strip ".exe" from the program name.
 + Windows: Handle absolute paths in
   safe_create_leading_directories().
 + Windows: Treat Windows style path names.
 + setup.c: Prepare for Windows directory separators.
 + Windows: Use the Windows style PATH separator ';'.
 + Add target architecture MinGW.
 + Compile some programs only conditionally.
 + Add compat/regex.[ch] and compat/fnmatch.[ch].

No explanation necessary ;-)

* mv/merge-in-c (Mon Jun 30 03:39:58 2008 +0200) 13 commits
 - Build in merge
 - Add new test case to ensure git-merge prepends the custom merge
   message
 - Add new test case to ensure git-merge reduces octopus parents when
   possible
 - Introduce reduce_heads()
 - Introduce get_merge_bases_many()
 - Add new test to ensure git-merge handles more than 25 refs.
 - Introduce get_octopus_merge_bases() in commit.c
 - git-fmt-merge-msg: make it usable from other builtins
 - Move read_cache_unmerged() to read-cache.c
 - Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 - Move parse-options's skip_prefix() to git-compat-util.h
 - Move commit_list_count() to commit.c
 - Move split_cmdline() to alias.c

The last one is still in flux.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 + rerere.autoupdate
 + t4200: fix rerere test
 + rerere: remove dubious "tail_optimization"
 + git-rerere: detect unparsable conflicts
 + rerere: rerere_created_at() and has_resolution() abstraction

A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.

* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
 - Migrate git-blame to parse-option partially.
 - parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 - parse-opt: fake short strings for callers to believe in.
 - parse-opt: do not pring errors on unknown options, return -2
   intead.
 - parse-opt: create parse_options_step.
 - parse-opt: Export a non NORETURN usage dumper.
 - parse-opt: have parse_options_{start,end}.

----------------------------------------------------------------
[Graduated to "master"]

----------------------------------------------------------------
[On Hold]

* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
 + Remove the use of '--' in merge program invocation

Waiting for success reports from people who use various backends.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

----------------------------------------------------------------
[Stalled/Needs more work]

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

----------------------------------------------------------------
[Dropped for now]

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 . Introduce fast forward option only
 . Head reduction before selecting merge strategy
 . Restructure git-merge.sh
 . Introduce -ff=<fast forward option>
 . New merge tests
 . Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 . Use perl instead of tac
 . Fix t3404 assumption that `wc -l` does not use whitespace.
 . rebase -i: Use : in expr command instead of match.
 . rebase -i: update the implementation of 'mark' command
 . Add option --preserve-tags
 . Teach rebase interactive the tag command
 . Add option --first-parent
 . Do rebase with preserve merges with advanced TODO list
 . Select all lines with fake-editor
 . Unify the length of $SHORT* and the commits in the TODO list
 . Teach rebase interactive the merge command
 . Move redo merge code in a function
 . Teach rebase interactive the reset command
 . Teach rebase interactive the mark command
 . Move cleanup code into it's own function
 . Don't append default merge message to -m message
 . fake-editor: output TODO list if unchanged

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 . WIP: rethink replay merge
 . Start using replay-tree merge in cherry-pick
 . revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 . git-am --forge: add Signed-off-by: line for the author
 . git-am: clean-up Signed-off-by: lines
 . stripspace: add --log-clean option to clean up signed-off-by:
   lines
 . stripspace: use parse_options()
 . Add "git am -s" test
 . git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 . "git push": tellme-more protocol extension

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-30  5:33                                                   ` Jeff King
@ 2008-06-30  5:38                                                     ` Junio C Hamano
  0 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-06-30  5:38 UTC (permalink / raw)
  To: Jeff King; +Cc: git

Jeff King <peff@peff.net> writes:

> On Sun, Jun 29, 2008 at 10:31:00PM -0700, Junio C Hamano wrote:
>
>> > Where do we want to take this? The conversation went something like:
>> >
>> >    me: here's a patch where we hint about "remote prune"
>> >   you: why not just fix the refs, it's no worse than a rewind
>> >    me: we kill reflogs, so it is different than a rewind
>> >   you: oh, right
>> >
>> > So I'm not sure if that was "Oh, right, it's not a good idea to remove
>> > the conflicting ref" or "Oh, right, but it's probably still fine."
>> 
>> It is "Oh right, it is Ok.  Let's cook it in 'next', have it in 'master'
>> and then backmerge to 'maint'".
>
> Sorry if I'm being slow, but what is "it" here? The "warning" patch I
> sent, or a to-be-posted patch that deletes the conflicting ref?

Sorry, my fingers outpaced my brain and gave you gibberish.

	Oh right, we should hint about "remote prune" and stop there, at
	least for now, as it is not nice to just delete the refs and lose
	their reflogs without user's consent.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-30  5:31                                                 ` Junio C Hamano
@ 2008-06-30  5:33                                                   ` Jeff King
  2008-06-30  5:38                                                     ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Jeff King @ 2008-06-30  5:33 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sun, Jun 29, 2008 at 10:31:00PM -0700, Junio C Hamano wrote:

> > Where do we want to take this? The conversation went something like:
> >
> >    me: here's a patch where we hint about "remote prune"
> >   you: why not just fix the refs, it's no worse than a rewind
> >    me: we kill reflogs, so it is different than a rewind
> >   you: oh, right
> >
> > So I'm not sure if that was "Oh, right, it's not a good idea to remove
> > the conflicting ref" or "Oh, right, but it's probably still fine."
> 
> It is "Oh right, it is Ok.  Let's cook it in 'next', have it in 'master'
> and then backmerge to 'maint'".

Sorry if I'm being slow, but what is "it" here? The "warning" patch I
sent, or a to-be-posted patch that deletes the conflicting ref?

-Peff

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-30  3:30                                               ` Jeff King
@ 2008-06-30  5:31                                                 ` Junio C Hamano
  2008-06-30  5:33                                                   ` Jeff King
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-06-30  5:31 UTC (permalink / raw)
  To: Jeff King; +Cc: git

Jeff King <peff@peff.net> writes:

> On Sun, Jun 29, 2008 at 01:55:13AM -0700, Junio C Hamano wrote:
>
>> * jk/maint-fetch-ref-hier (Thu Jun 26 23:59:50 2008 -0400) 1 commit
>>  + fetch: report local storage errors in status table
>> 
>> When the remote used to have "foo" branch but now has "foo/bar", fetch
>> refuses to delete the existing remote tracking branch "foo" to create a
>> new remote tracking branch "foo/bar", but the error message was
>> confusing.
>
> Where do we want to take this? The conversation went something like:
>
>    me: here's a patch where we hint about "remote prune"
>   you: why not just fix the refs, it's no worse than a rewind
>    me: we kill reflogs, so it is different than a rewind
>   you: oh, right
>
> So I'm not sure if that was "Oh, right, it's not a good idea to remove
> the conflicting ref" or "Oh, right, but it's probably still fine."

It is "Oh right, it is Ok.  Let's cook it in 'next', have it in 'master'
and then backmerge to 'maint'".

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-29  8:55                                             ` Junio C Hamano
  2008-06-29 18:35                                               ` Linus Torvalds
@ 2008-06-30  3:30                                               ` Jeff King
  2008-06-30  5:31                                                 ` Junio C Hamano
  2008-06-30  9:08                                               ` Junio C Hamano
  2008-06-30 14:59                                               ` Brandon Casey
  3 siblings, 1 reply; 575+ messages in thread
From: Jeff King @ 2008-06-30  3:30 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sun, Jun 29, 2008 at 01:55:13AM -0700, Junio C Hamano wrote:

> * jk/maint-fetch-ref-hier (Thu Jun 26 23:59:50 2008 -0400) 1 commit
>  + fetch: report local storage errors in status table
> 
> When the remote used to have "foo" branch but now has "foo/bar", fetch
> refuses to delete the existing remote tracking branch "foo" to create a
> new remote tracking branch "foo/bar", but the error message was
> confusing.

Where do we want to take this? The conversation went something like:

   me: here's a patch where we hint about "remote prune"
  you: why not just fix the refs, it's no worse than a rewind
   me: we kill reflogs, so it is different than a rewind
  you: oh, right

So I'm not sure if that was "Oh, right, it's not a good idea to remove
the conflicting ref" or "Oh, right, but it's probably still fine."

-Peff

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-29 20:15                                                   ` Pieter de Bie
  2008-06-29 21:57                                                     ` Johannes Schindelin
@ 2008-06-29 22:00                                                     ` Steffen Prohaska
  1 sibling, 0 replies; 575+ messages in thread
From: Steffen Prohaska @ 2008-06-29 22:00 UTC (permalink / raw)
  To: Pieter de Bie; +Cc: Junio C Hamano, Linus Torvalds, Git Mailinglist


On Jun 29, 2008, at 10:15 PM, Pieter de Bie wrote:

>
> On 29 jun 2008, at 22:11, Junio C Hamano wrote:
>
>> use of them from your scripts after adding
>>  output from "git --exec-path" to the $PATH will still be supported  
>> in
>>  1.6.0, but users are again strongly encouraged to adjust their
>>  scripts to use "git xyzzy" form, as we will stop installing
>>  "git-xyzzy" hardlinks for built-in commands in later releases.
>
> I think msysgit doesn't (didn't?) install the hardlinks to conserve  
> space,
> as Windows doesn't support hard links. Perhaps we should mention that
> as well?

Windows does support hardlinks and msysgit uses them.

	Steffen

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-29 20:15                                                   ` Pieter de Bie
@ 2008-06-29 21:57                                                     ` Johannes Schindelin
  2008-06-29 22:00                                                     ` Steffen Prohaska
  1 sibling, 0 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-06-29 21:57 UTC (permalink / raw)
  To: Pieter de Bie; +Cc: Junio C Hamano, Linus Torvalds, Git Mailinglist

Hi,

On Sun, 29 Jun 2008, Pieter de Bie wrote:

> On 29 jun 2008, at 22:11, Junio C Hamano wrote:
> 
> >  use of them from your scripts after adding output from "git 
> >  --exec-path" to the $PATH will still be supported in 1.6.0, but users 
> >  are again strongly encouraged to adjust their scripts to use "git 
> >  xyzzy" form, as we will stop installing "git-xyzzy" hardlinks for 
> >  built-in commands in later releases.
> 
> I think msysgit doesn't (didn't?) install the hardlinks to conserve 
> space, as Windows doesn't support hard links.

Please do not spread FUD.  Where available, we install hardlinks.

And even if we did not, given that we do not yet actively support MinGW, I 
think your suggestion is a bit early, to say the least.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-29 20:11                                                 ` Junio C Hamano
@ 2008-06-29 20:15                                                   ` Pieter de Bie
  2008-06-29 21:57                                                     ` Johannes Schindelin
  2008-06-29 22:00                                                     ` Steffen Prohaska
  0 siblings, 2 replies; 575+ messages in thread
From: Pieter de Bie @ 2008-06-29 20:15 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailinglist


On 29 jun 2008, at 22:11, Junio C Hamano wrote:

> use of them from your scripts after adding
>   output from "git --exec-path" to the $PATH will still be supported  
> in
>   1.6.0, but users are again strongly encouraged to adjust their
>   scripts to use "git xyzzy" form, as we will stop installing
>   "git-xyzzy" hardlinks for built-in commands in later releases.

I think msysgit doesn't (didn't?) install the hardlinks to conserve  
space,
as Windows doesn't support hard links. Perhaps we should mention that
as well?

- Pieter

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-29 18:35                                               ` Linus Torvalds
  2008-06-29 19:08                                                 ` Junio C Hamano
@ 2008-06-29 20:11                                                 ` Junio C Hamano
  2008-06-29 20:15                                                   ` Pieter de Bie
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-06-29 20:11 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: git

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

> To me, the first sentence means that 'cat-file' command is gone....

Here is a replacement I am preparing, taken from the draft release notes
to 1.6.0:

 * With the default Makefile settings, most of the programs will be
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical
   reasons.  Invoking a git subcommand as "git-xyzzy" from the command
   line has been deprecated since early 2006 (and officially announced in
   1.5.4 release notes); use of them from your scripts after adding
   output from "git --exec-path" to the $PATH will still be supported in
   1.6.0, but users are again strongly encouraged to adjust their
   scripts to use "git xyzzy" form, as we will stop installing
   "git-xyzzy" hardlinks for built-in commands in later releases.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-29 18:35                                               ` Linus Torvalds
@ 2008-06-29 19:08                                                 ` Junio C Hamano
  2008-06-29 20:11                                                 ` Junio C Hamano
  1 sibling, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-06-29 19:08 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: git

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

> Maybe just say
>
>  * Do not install all git subcommands as 'git-xyzzy' files in the user 
>    path. This avoids unnecessary hardlinks (or copies on systems that do 
>    not support links), and enforces the 'git xyzzy' syntax.
>
>    Subcommands that aren't builtins now get installed in
>    /usr/libexec/git-core/ or somesuch.

Thanks.

> (I haven't looked at the series, but I _assume_ it also avoids installing 
> the builtin subcommands entirely when not necessary, ie "git-cat-file" 
> really _is_ gone, but it's not because the "cat-file" command itself is 
> gone).

It is actually a fairly long road ahead.

In 1.6.0, most of them will be moved to /usr/libexec/git-core/, so that
really old scripts end users may have can be more easily kept working by
simply saying:

	PATH=$(git --exec-path):$PATH

early, without doing "s/git-/git /g".

Current git clients run git-upload-pack and friends in "git-xyzzy" form
when accessing remote repositories directly over ssh, so in 1.6.0 we will
have to leave these server side programs in $(bindir) as well.

git-shell and gitosis is being updated to accept "git upload-pack" form as
well, and after older versions of these programs die out, we can update
the clients to ask for remote side programs without dash.

None of the server side programs is built-in, so we could start the
hardlink removal independent from this transition (iow, "Only subcommands
that aren't builtin will be installed in libexec, builtins are not on the
disk anywhere" could happen now), but I'd prefer to keep changes in each
steps small to minimize impacts to the end users' environments.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-29  8:55                                             ` Junio C Hamano
@ 2008-06-29 18:35                                               ` Linus Torvalds
  2008-06-29 19:08                                                 ` Junio C Hamano
  2008-06-29 20:11                                                 ` Junio C Hamano
  2008-06-30  3:30                                               ` Jeff King
                                                                 ` (2 subsequent siblings)
  3 siblings, 2 replies; 575+ messages in thread
From: Linus Torvalds @ 2008-06-29 18:35 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git



On Sun, 29 Jun 2008, Junio C Hamano wrote:
> 
>  * /usr/bin/git-cat-file is no more.  The bulk of the git commands will
>    move to /usr/libexec/git-core/ or somesuch.

Every time I read this note I do a double-take.

To me, the first sentence means that 'cat-file' command is gone. Then, the 
second sentence is just gibberish. And since I understand what you _want_ 
to say, I then go back and parse it properly, and know that you don't 
actually mean that git-cat-file is removed, but that it's removed from 
being accessible under that name in the path.

So to avoid my double-take, and hopefully avoid confusion for other 
people, can you please make your status report rephrase that thing.

Maybe just say

 * Do not install all git subcommands as 'git-xyzzy' files in the user 
   path. This avoids unnecessary hardlinks (or copies on systems that do 
   not support links), and enforces the 'git xyzzy' syntax.

   Subcommands that aren't builtins now get installed in
   /usr/libexec/git-core/ or somesuch.

(I haven't looked at the series, but I _assume_ it also avoids installing 
the builtin subcommands entirely when not necessary, ie "git-cat-file" 
really _is_ gone, but it's not because the "cat-file" command itself is 
gone).

Hmm? Or maybe it's just me who gets confused by the phrasing.

		Linus

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-25  9:31                                           ` Junio C Hamano
@ 2008-06-29  8:55                                             ` Junio C Hamano
  2008-06-29 18:35                                               ` Linus Torvalds
                                                                 ` (3 more replies)
  0 siblings, 4 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-06-29  8:55 UTC (permalink / raw)
  To: git

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.  The topics
meant to be applied to the maintenance series have "maint-" in their
names.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  Bigger changes will be:

 * MinGW will be in.

 * /usr/bin/git-cat-file is no more.  The bulk of the git commands will
   move to /usr/libexec/git-core/ or somesuch.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

----------------------------------------------------------------
[New Topics]

* jk/maint-fetch-ref-hier (Thu Jun 26 23:59:50 2008 -0400) 1 commit
 + fetch: report local storage errors in status table

When the remote used to have "foo" branch but now has "foo/bar", fetch
refuses to delete the existing remote tracking branch "foo" to create a
new remote tracking branch "foo/bar", but the error message was
confusing.

* jc/maint-reset (Wed Jun 25 18:16:36 2008 -0700) 1 commit
 + Allow "git-reset path" when unambiguous

We used to require "git-reset -- path" even when there is no ambiguity
(i.e. path cannot be mistaken as a valid tree-ish and it is a filename in
the work tree).

* js/maint-clone-insteadof (Fri Jun 27 13:56:05 2008 +0100) 1 commit
 . clone: respect url.insteadOf setting in global configs

"git clone" does not honor "url.InsteadOf" in $HOME/.gitconfig; Daniel
seems to have ideas for a better fix than this, but this is worth fixing
on 'maint'.

* tr/send-email-ssl (Thu Jun 26 23:03:21 2008 +0200) 2 commits
 + git-send-email: prevent undefined variable warnings if no
   encryption is set
 + git-send-email: add support for TLS via Net::SMTP::SSL

* kb/send-email-fifo (Wed Jun 25 15:44:40 2008 -0700) 1 commit
 + git-send-email: Accept fifos as well as files

Two minor send-email feature enhancements for 1.6.0.

* jc/checkdiff (Thu Jun 26 16:08:05 2008 -0700) 6 commits
 + Update sample pre-commit hook to use "diff --check"
 + diff --check: detect leftover conflict markers
 + Teach "diff --check" about new blank lines at end
 + checkdiff: pass diff_options to the callback
 + check_and_emit_line(): rename and refactor
 + diff --check: explain why we do not care whether old side is
   binary

Allows us to replace the sample pre-commit hook that was not aware of the
line termination convention per path nor newer whitespace breakage rules.

* np/pack-default (Wed Jun 25 00:25:53 2008 -0400) 2 commits
 + pack.indexversion config option now defaults to 2
 + repack.usedeltabaseoffset config option now defaults to "true"

Updates the default value for pack.indexversion to 2 and use delta-base
offset encoding of the packfiles by default.

* js/apply-recount (Fri Jun 27 18:43:09 2008 +0100) 1 commit
 + Allow git-apply to recount the lines in a hunk (AKA recountdiff)

A good ingredient for implementing "apply --edit".

* dz/apply-again (Fri Jun 27 14:39:12 2008 -0400) 1 commit
 + git-apply: handle a patch that touches the same path more than
   once better

Allows us to feed a patch that touches the same path more than once.

* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
 - Migrate git-blame to parse-option partially.
 - parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 - parse-opt: fake short strings for callers to believe in.
 - parse-opt: do not pring errors on unknown options, return -2
   intead.
 - parse-opt: create parse_options_step.
 - parse-opt: Export a non NORETURN usage dumper.
 - parse-opt: have parse_options_{start,end}.

----------------------------------------------------------------
[Will merge to master soon]

* nd/dashless (Tue Jun 24 19:58:11 2008 -0700) 2 commits
 + Keep some git-* programs in $(bindir)
 + Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  We'll leave server-side programs in $(bindir) 
so that ssh clients can ask for "git-program" and find them on the $PATH.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 4 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport
 + Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 + git-shell: accept "git foo" form

----------------------------------------------------------------
[Actively Cooking]

* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
 - Make default expiration period of reflog used for stash infinite
 - Per-ref reflog expiry configuration

As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.

* jc/merge-theirs (Sat Jun 28 17:28:22 2008 -0700) 3 commits
 - Teach git-merge to pass -X<option> to the backend strategy module
 - git-merge-recursive-{ours,theirs}
 - git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -s recursive other" now.

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
 + compat/pread.c: Add a forward declaration to fix a warning
 + Windows: Fix ntohl() related warnings about printf formatting
 + Windows: TMP and TEMP environment variables specify a temporary
   directory.
 + Windows: Make 'git help -a' work.
 + Windows: Work around an oddity when a pipe with no reader is
   written to.
 + Windows: Make the pager work.
 + When installing, be prepared that template_dir may be relative.
 + Windows: Use a relative default template_dir and ETC_GITCONFIG
 + Windows: Compute the fallback for exec_path from the program
   invocation.
 + Turn builtin_exec_path into a function.
 + Windows: Use a customized struct stat that also has the st_blocks
   member.
 + Windows: Add a custom implementation for utime().
 + Windows: Add a new lstat and fstat implementation based on Win32
   API.
 + Windows: Implement a custom spawnve().
 + Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 + Windows: Work around incompatible sort and find.
 + Windows: Implement asynchronous functions as threads.
 + Windows: Disambiguate DOS style paths from SSH URLs.
 + Windows: A rudimentary poll() emulation.
 + Windows: Implement start_command().
 + Windows: A pipe() replacement whose ends are not inherited to
   children.
 + Windows: Wrap execve so that shell scripts can be invoked.
 + Windows: Implement setitimer() and sigaction().
 + Windows: Fix PRIuMAX definition.
 + Windows: Implement gettimeofday().
 + Make my_mktime() public and rename it to tm_to_time_t()
 + Windows: Work around misbehaved rename().
 + Windows: always chmod(, 0666) before unlink().
 + Windows: A minimal implemention of getpwuid().
 + Windows: Implement a wrapper of the open() function.
 + Windows: Strip ".exe" from the program name.
 + Windows: Handle absolute paths in
   safe_create_leading_directories().
 + Windows: Treat Windows style path names.
 + setup.c: Prepare for Windows directory separators.
 + Windows: Use the Windows style PATH separator ';'.
 + Add target architecture MinGW.
 + Compile some programs only conditionally.
 + Add compat/regex.[ch] and compat/fnmatch.[ch].

No explanation necessary ;-)

* mv/merge-in-c (Sat Jun 28 04:38:19 2008 +0200) 13 commits
 - Build in merge
 - Add new test case to ensure git-merge prepends the custom merge
   message
 - Add new test case to ensure git-merge reduces octopus parents when
   possible
 - Introduce reduce_heads()
 - Introduce get_merge_bases_many()
 - Add new test to ensure git-merge handles more than 25 refs.
 - Introduce get_octopus_merge_bases() in commit.c
 - git-fmt-merge-msg: make it usable from other builtins
 - Move read_cache_unmerged() to read-cache.c
 - Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 - Move parse-options's skip_prefix() to git-compat-util.h
 - Move commit_list_count() to commit.c
 - Move split_cmdline() to alias.c

The last one is a huge patch and it will take some time to review and get
details sorted out.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 + rerere.autoupdate
 + t4200: fix rerere test
 + rerere: remove dubious "tail_optimization"
 + git-rerere: detect unparsable conflicts
 + rerere: rerere_created_at() and has_resolution() abstraction

A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.

----------------------------------------------------------------
[Graduated to "master"]

* sb/rebase (Sun Jun 22 01:55:50 2008 +0200) 2 commits
 + t3404: stricter tests for git-rebase--interactive
 + api-builtin.txt: update and fix typo

* sb/maint-rebase (Sun Jun 22 16:07:02 2008 +0200) 1 commit
 + git-rebase.sh: Add check if rebase is in progress

* lw/gitweb (Thu Jun 19 22:03:21 2008 +0200) 1 commit
 + gitweb: standarize HTTP status codes

* lt/config-fsync (Wed Jun 18 15:18:44 2008 -0700) 4 commits
 + Add config option to enable 'fsync()' of object files
 + Split up default "i18n" and "branch" config parsing into helper
   routines
 + Split up default "user" config parsing into helper routine
 + Split up default "core" config parsing into helper routine

* sr/tests (Sun Jun 8 16:04:35 2008 +0200) 3 commits
 + Hook up the result aggregation in the test makefile.
 + A simple script to parse the results from the testcases
 + Modify test-lib.sh to output stats to t/test-results/*

* jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits
 + Teach "git clone" to pack refs
 + Prepare testsuite for a "git clone" that packs refs
 + Move pack_refs() and friends into libgit
 + Incorporate fetched packs in future object traversal

This is useful when cloning from a repository with insanely large number
of refs.

* lw/perlish (Thu Jun 19 22:32:49 2008 +0200) 2 commits
 + Git.pm: add test suite
 + t/test-lib.sh: add test_external and test_external_without_stderr

Beginning of regression tests for Perl part of the system.

----------------------------------------------------------------
[On Hold]

* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
 + Remove the use of '--' in merge program invocation

Waiting for success reports from people who use various backends.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

----------------------------------------------------------------
[Stalled/Needs more work]

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

----------------------------------------------------------------
[Dropped for now]

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 . Introduce fast forward option only
 . Head reduction before selecting merge strategy
 . Restructure git-merge.sh
 . Introduce -ff=<fast forward option>
 . New merge tests
 . Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 . Use perl instead of tac
 . Fix t3404 assumption that `wc -l` does not use whitespace.
 . rebase -i: Use : in expr command instead of match.
 . rebase -i: update the implementation of 'mark' command
 . Add option --preserve-tags
 . Teach rebase interactive the tag command
 . Add option --first-parent
 . Do rebase with preserve merges with advanced TODO list
 . Select all lines with fake-editor
 . Unify the length of $SHORT* and the commits in the TODO list
 . Teach rebase interactive the merge command
 . Move redo merge code in a function
 . Teach rebase interactive the reset command
 . Teach rebase interactive the mark command
 . Move cleanup code into it's own function
 . Don't append default merge message to -m message
 . fake-editor: output TODO list if unchanged

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 . WIP: rethink replay merge
 . Start using replay-tree merge in cherry-pick
 . revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 . git-am --forge: add Signed-off-by: line for the author
 . git-am: clean-up Signed-off-by: lines
 . stripspace: add --log-clean option to clean up signed-off-by:
   lines
 . stripspace: use parse_options()
 . Add "git am -s" test
 . git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 . "git push": tellme-more protocol extension

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 19:34                                                         ` Johannes Schindelin
  2008-06-24 20:06                                                           ` Jakub Narebski
@ 2008-06-26 15:41                                                           ` Jakub Narebski
  1 sibling, 0 replies; 575+ messages in thread
From: Jakub Narebski @ 2008-06-26 15:41 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Miklos Vajna, Pieter de Bie, Junio C Hamano, git

On Tue, 24 Jun 2008, Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 24 Jun 2008, Jakub Narebski wrote:
> 
> > git-shell hackery won't solve problem, because not everybody is using 
> > git-shell.
> 
> The problem is not git-shell vs git potty.
> 
> The problem is that not everybody magically updates their clients to ask 
> for dash-less form.

With git-shell even if client uses dashed form it can find git commands
("hackery" is too strong a word for having git-shell search $GIT_EXEC_PATH).
But if one uses only SSH, server must have dashed form in a $PATH

-- 
Jakub Narebski
Poland

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-06-23  7:15                                         ` Junio C Hamano
  2008-06-23 12:15                                           ` Miklos Vajna
@ 2008-06-25  9:31                                           ` Junio C Hamano
  2008-06-29  8:55                                             ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-06-25  9:31 UTC (permalink / raw)
  To: git

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.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  But bigger changes will be:

 * MinGW will be in.

 * /usr/bin/git-cat-file is no more.  The bulk of the git commands will
   move to /usr/libexec/git-core/ or somesuch.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

----------------------------------------------------------------
[New Topics]

* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
 - Migrate git-blame to parse-option partially.
 - parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 - parse-opt: fake short strings for callers to believe in.
 - parse-opt: do not pring errors on unknown options, return -2
   intead.
 - parse-opt: create parse_options_step.
 - parse-opt: Export a non NORETURN usage dumper.
 - parse-opt: have parse_options_{start,end}.

----------------------------------------------------------------
[Will merge to master soon]

* lw/gitweb (Thu Jun 19 22:03:21 2008 +0200) 1 commit
 + gitweb: standarize HTTP status codes

* lt/config-fsync (Wed Jun 18 15:18:44 2008 -0700) 4 commits
 + Add config option to enable 'fsync()' of object files
 + Split up default "i18n" and "branch" config parsing into helper
   routines
 + Split up default "user" config parsing into helper routine
 + Split up default "core" config parsing into helper routine

* nd/dashless (Tue Jun 24 19:58:11 2008 -0700) 2 commits
 + Keep some git-* programs in $(bindir)
 + Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  We'll leave server-side programs in $(bindir) 
so that ssh clients can ask for "git-program" and find them on the $PATH.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

* sr/tests (Sun Jun 8 16:04:35 2008 +0200) 3 commits
 + Hook up the result aggregation in the test makefile.
 + A simple script to parse the results from the testcases
 + Modify test-lib.sh to output stats to t/test-results/*

* jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits
 + Teach "git clone" to pack refs
 + Prepare testsuite for a "git clone" that packs refs
 + Move pack_refs() and friends into libgit
 + Incorporate fetched packs in future object traversal

This is useful when cloning from a repository with insanely large number
of refs.

* lw/perlish (Thu Jun 19 22:32:49 2008 +0200) 2 commits
 + Git.pm: add test suite
 + t/test-lib.sh: add test_external and test_external_without_stderr

Beginning of regression tests for Perl part of the system.

----------------------------------------------------------------
[Actively Cooking]

* mv/merge-in-c (Sat Jun 21 19:15:35 2008 +0200) 12 commits
 - Add new test case to ensure git-merge reduces octopus parents when
   possible
 - Build in merge
 - Introduce reduce_heads()
 - Introduce get_merge_bases_many()
 - Add new test to ensure git-merge handles more than 25 refs.
 - Introduce get_octopus_merge_bases() in commit.c
 - git-fmt-merge-msg: make it usable from other builtins
 - Move read_cache_unmerged() to read-cache.c
 - Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 - Move parse-options's skip_prefix() to git-compat-util.h
 - Move commit_list_count() to commit.c
 - Move split_cmdline() to alias.c

I dropped the change to parseopt in this series and fixed up the caller.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 + Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 + git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 - rerere.autoupdate
 - t4200: fix rerere test
 - rerere: remove dubious "tail_optimization"
 - git-rerere: detect unparsable conflicts
 - rerere: rerere_created_at() and has_resolution() abstraction

* sb/rebase (Sun Jun 22 01:55:50 2008 +0200) 2 commits
 + t3404: stricter tests for git-rebase--interactive
 + api-builtin.txt: update and fix typo

* sb/maint-rebase (Sun Jun 22 16:07:02 2008 +0200) 1 commit
 + git-rebase.sh: Add check if rebase is in progress

----------------------------------------------------------------
[Graduated to "master"]


----------------------------------------------------------------
[On Hold]

* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
 + Remove the use of '--' in merge program invocation

Waiting for success reports from people who use various backends.

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 39 commits
 - compat/pread.c: Add a forward declaration to fix a warning
 - Windows: Fix ntohl() related warnings about printf formatting
 - Windows: TMP and TEMP environment variables specify a temporary
   directory.
 - Windows: Make 'git help -a' work.
 - Windows: Work around an oddity when a pipe with no reader is
   written to.
 - Windows: Make the pager work.
 - When installing, be prepared that template_dir may be relative.
 - Windows: Use a relative default template_dir and ETC_GITCONFIG
 - Windows: Compute the fallback for exec_path from the program
   invocation.
 - Turn builtin_exec_path into a function.
 - Windows: Use a customized struct stat that also has the st_blocks
   member.
 - Windows: Add a custom implementation for utime().
 - Windows: Add a new lstat and fstat implementation based on Win32
   API.
 - Windows: Implement a custom spawnve().
 - Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 - Windows: Work around incompatible sort and find.
 - Windows: Implement asynchronous functions as threads.
 - Windows: Disambiguate DOS style paths from SSH URLs.
 - Windows: A rudimentary poll() emulation.
 - Windows: Change the name of hook scripts to make them not
   executable.
 - Windows: Implement start_command().
 - Windows: A pipe() replacement whose ends are not inherited to
   children.
 - Windows: Wrap execve so that shell scripts can be invoked.
 - Windows: Implement setitimer() and sigaction().
 - Windows: Fix PRIuMAX definition.
 - Windows: Implement gettimeofday().
 - Make my_mktime() public and rename it to tm_to_time_t()
 - Windows: Work around misbehaved rename().
 - Windows: always chmod(, 0666) before unlink().
 - Windows: A minimal implemention of getpwuid().
 - Windows: Implement a wrapper of the open() function.
 - Windows: Strip ".exe" from the program name.
 - Windows: Handle absolute paths in
   safe_create_leading_directories().
 - Windows: Treat Windows style path names.
 - setup.c: Prepare for Windows directory separators.
 - Windows: Use the Windows style PATH separator ';'.
 - Add target architecture MinGW.
 - Compile some programs only conditionally.
 - Add compat/regex.[ch] and compat/fnmatch.[ch].

No explanation is necessary ;-).  The series is probably 'next' worthy
as-is, except that template renaming hack won't be needed anymore.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

----------------------------------------------------------------
[Stalled/Needs more work]

* jc/reflog-expire (Sun Jun 15 23:48:46 2008 -0700) 1 commit
 - Per-ref reflog expiry configuration

Perhaps a good foundation for optionally unexpirable stash.  As 1.6.0 will
be a good time to make backward incompatible changes, we might make expiry
period of stash 'never' in new repositories.  Needs a concensus.

* jc/merge-theirs (Fri Jun 20 00:17:59 2008 -0700) 2 commits
 - git-merge-recursive-{ours,theirs}
 - git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends may need to change, though.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

----------------------------------------------------------------
[Dropped for now]

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 . Introduce fast forward option only
 . Head reduction before selecting merge strategy
 . Restructure git-merge.sh
 . Introduce -ff=<fast forward option>
 . New merge tests
 . Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 . Use perl instead of tac
 . Fix t3404 assumption that `wc -l` does not use whitespace.
 . rebase -i: Use : in expr command instead of match.
 . rebase -i: update the implementation of 'mark' command
 . Add option --preserve-tags
 . Teach rebase interactive the tag command
 . Add option --first-parent
 . Do rebase with preserve merges with advanced TODO list
 . Select all lines with fake-editor
 . Unify the length of $SHORT* and the commits in the TODO list
 . Teach rebase interactive the merge command
 . Move redo merge code in a function
 . Teach rebase interactive the reset command
 . Teach rebase interactive the mark command
 . Move cleanup code into it's own function
 . Don't append default merge message to -m message
 . fake-editor: output TODO list if unchanged

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 . WIP: rethink replay merge
 . Start using replay-tree merge in cherry-pick
 . revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 . git-am --forge: add Signed-off-by: line for the author
 . git-am: clean-up Signed-off-by: lines
 . stripspace: add --log-clean option to clean up signed-off-by:
   lines
 . stripspace: use parse_options()
 . Add "git am -s" test
 . git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 . "git push": tellme-more protocol extension

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-25  0:11                                                             ` Jakub Narebski
  2008-06-25  3:32                                                               ` Shawn O. Pearce
@ 2008-06-25  7:29                                                               ` Miklos Vajna
  1 sibling, 0 replies; 575+ messages in thread
From: Miklos Vajna @ 2008-06-25  7:29 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: Junio C Hamano, Johannes Schindelin, Pieter de Bie, git

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

On Tue, Jun 24, 2008 at 05:11:44PM -0700, Jakub Narebski <jnareb@gmail.com> wrote:
> What does "git ls-remote server:/home/vmiklos/git/test" invoke on server? 

$ git ls-remote server:/home/vmiklos/git/test
bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-25  0:11                                                             ` Jakub Narebski
@ 2008-06-25  3:32                                                               ` Shawn O. Pearce
  2008-06-25  7:29                                                               ` Miklos Vajna
  1 sibling, 0 replies; 575+ messages in thread
From: Shawn O. Pearce @ 2008-06-25  3:32 UTC (permalink / raw)
  To: Jakub Narebski
  Cc: Junio C Hamano, Miklos Vajna, Johannes Schindelin, Pieter de Bie, git

Jakub Narebski <jnareb@gmail.com> wrote:
> 
> What does "git ls-remote server:/home/vmiklos/git/test" invoke on server? 

FYI, it actually runs git-upload-pack, gets the list of advertised
refs, then closes the connection immediately.  The other side sees
the client hang up and just terminates silently, since the client
didn't "want" anything packed and sent.

-- 
Shawn.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-25  3:08                                                               ` しらいしななこ
@ 2008-06-25  3:26                                                                 ` Shawn O. Pearce
  0 siblings, 0 replies; 575+ messages in thread
From: Shawn O. Pearce @ 2008-06-25  3:26 UTC (permalink / raw)
  To: しらいしななこ, Junio C Hamano
  Cc: Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git

 <nanako3@lavabit.com> wrote:
> Quoting Junio C Hamano <gitster@pobox.com>:
> > Miklos Vajna <vmiklos@frugalware.org> writes:
> >> On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> >>> It most likely makes sense to do (3) anyway.  upload-pack, receive-pack,
> >>> anything else?
> >>
> >> I think that's all.
> >
> > Then that would be this patch on top of nd/dashless topic.
> >
> >  Makefile |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 929136b..babf16b 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1268,7 +1268,7 @@ install: all
> >  	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
> >  	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
> >  	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
> > -	$(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
> > +	$(INSTALL) git$X git-upload-pack$X git-receive-pack$X '$(DESTDIR_SQ)$(bindir_SQ)'
> >  	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
> >  	$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
> >  ifndef NO_TCLTK
> 
> Doesn't "git archive --remote=<repo>" also execute git program on a remote machine?

Yes, it runs git-upload-archive on the remote side.  The three
primary services for the remote side are documented in daemon.c:

    403 static struct daemon_service daemon_service[] = {
    404     { "upload-archive", "uploadarch", upload_archive, 0, 1 },
    405     { "upload-pack", "uploadpack", upload_pack, 1, 1 },
    406     { "receive-pack", "receivepack", receive_pack, 0, 1 },
    407 };

(with git- prefixes).

IMHO all three need to be in $PATH, along with git and gitk, through
at least a major revision release cycle to give clients a chance to
upgrade to something that uses "git foo" rather than "git-foo" when
talking to the remote.

-- 
Shawn.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 23:32                                                             ` Miklos Vajna
  2008-06-25  2:57                                                               ` Junio C Hamano
@ 2008-06-25  3:08                                                               ` しらいしななこ
  2008-06-25  3:26                                                                 ` Shawn O. Pearce
  1 sibling, 1 reply; 575+ messages in thread
From: しらいしななこ @ 2008-06-25  3:08 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git

Quoting Junio C Hamano <gitster@pobox.com>:

> Miklos Vajna <vmiklos@frugalware.org> writes:
>
>> On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>>> It most likely makes sense to do (3) anyway.  upload-pack, receive-pack,
>>> anything else?
>>
>> I think that's all.
>
> Then that would be this patch on top of nd/dashless topic.
>
>  Makefile |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 929136b..babf16b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1268,7 +1268,7 @@ install: all
>  	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
>  	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
>  	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
> -	$(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
> +	$(INSTALL) git$X git-upload-pack$X git-receive-pack$X '$(DESTDIR_SQ)$(bindir_SQ)'
>  	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
>  	$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
>  ifndef NO_TCLTK

Doesn't "git archive --remote=<repo>" also execute git program on a remote machine?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 23:32                                                             ` Miklos Vajna
@ 2008-06-25  2:57                                                               ` Junio C Hamano
  2008-06-25  3:08                                                               ` しらいしななこ
  1 sibling, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-06-25  2:57 UTC (permalink / raw)
  To: Miklos Vajna; +Cc: pclouds, Johannes Schindelin, Pieter de Bie, git

Miklos Vajna <vmiklos@frugalware.org> writes:

> On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>> It most likely makes sense to do (3) anyway.  upload-pack, receive-pack,
>> anything else?
>
> I think that's all.

Then that would be this patch on top of nd/dashless topic.

 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 929136b..babf16b 100644
--- a/Makefile
+++ b/Makefile
@@ -1268,7 +1268,7 @@ install: all
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
 	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
-	$(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
+	$(INSTALL) git$X git-upload-pack$X git-receive-pack$X '$(DESTDIR_SQ)$(bindir_SQ)'
 	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
 	$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
 ifndef NO_TCLTK

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 23:16                                                           ` Junio C Hamano
  2008-06-24 23:32                                                             ` Miklos Vajna
@ 2008-06-25  0:11                                                             ` Jakub Narebski
  2008-06-25  3:32                                                               ` Shawn O. Pearce
  2008-06-25  7:29                                                               ` Miklos Vajna
  1 sibling, 2 replies; 575+ messages in thread
From: Jakub Narebski @ 2008-06-25  0:11 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Miklos Vajna, Johannes Schindelin, Pieter de Bie, git

Junio C Hamano <gitster@pobox.com> writes:

> Ah, there is not much we can do in that case then.  git-upload-pack is
> what the client asks you to run, and if you do not have it in the path,
> you can (1) either make sure it is on the path, (2) have the client be
> more explicit when asking for git-upload-pack (--upload-pack=$where), or
> (3) leave the minimum git-* binaries that can remotely be launched
> directly in the usual $PATH.
> 
> It most likely makes sense to do (3) anyway.  upload-pack, receive-pack,
> anything else?

What does "git ls-remote server:/home/vmiklos/git/test" invoke on server? 

-- 
Jakub Narebski
Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 23:16                                                           ` Junio C Hamano
@ 2008-06-24 23:32                                                             ` Miklos Vajna
  2008-06-25  2:57                                                               ` Junio C Hamano
  2008-06-25  3:08                                                               ` しらいしななこ
  2008-06-25  0:11                                                             ` Jakub Narebski
  1 sibling, 2 replies; 575+ messages in thread
From: Miklos Vajna @ 2008-06-24 23:32 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Schindelin, Pieter de Bie, git

[-- Attachment #1: Type: text/plain, Size: 197 bytes --]

On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> It most likely makes sense to do (3) anyway.  upload-pack, receive-pack,
> anything else?

I think that's all.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 22:10                                                         ` Miklos Vajna
@ 2008-06-24 23:16                                                           ` Junio C Hamano
  2008-06-24 23:32                                                             ` Miklos Vajna
  2008-06-25  0:11                                                             ` Jakub Narebski
  0 siblings, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-06-24 23:16 UTC (permalink / raw)
  To: Miklos Vajna; +Cc: Johannes Schindelin, Pieter de Bie, git

Miklos Vajna <vmiklos@frugalware.org> writes:

> On Tue, Jun 24, 2008 at 01:44:34PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>> >> bash: git-upload-pack: command not found
>> >> fatal: The remote end hung up unexpectedly
>> >
>> > Hmm.  Probably the client needs to be newer, too.  This is going to be 
>> > painful.  Junio?
>> 
>> Even with maint client accessing an account with next git-shell as its
>> login shell, I do not get the above failure.
>> 
>> Is git-shell installed and configured correctly at all in Miklos's setup?
>> Why does the other side say "bash: git-upload-pack" when login shell is
>> git-shell and not bash?
>
> Sorry for the confusion, this is not about git-shell at all. I have
> bash as the shell on the server, obviously.
>
> So, in case the server runs next, the client runs master, and I try to
> clone via ssh, I get the above error.

Ah, there is not much we can do in that case then.  git-upload-pack is
what the client asks you to run, and if you do not have it in the path,
you can (1) either make sure it is on the path, (2) have the client be
more explicit when asking for git-upload-pack (--upload-pack=$where), or
(3) leave the minimum git-* binaries that can remotely be launched
directly in the usual $PATH.

It most likely makes sense to do (3) anyway.  upload-pack, receive-pack,
anything else?

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 20:44                                                       ` Junio C Hamano
@ 2008-06-24 22:10                                                         ` Miklos Vajna
  2008-06-24 23:16                                                           ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Miklos Vajna @ 2008-06-24 22:10 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Schindelin, Pieter de Bie, git

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

On Tue, Jun 24, 2008 at 01:44:34PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> >> bash: git-upload-pack: command not found
> >> fatal: The remote end hung up unexpectedly
> >
> > Hmm.  Probably the client needs to be newer, too.  This is going to be 
> > painful.  Junio?
> 
> Even with maint client accessing an account with next git-shell as its
> login shell, I do not get the above failure.
> 
> Is git-shell installed and configured correctly at all in Miklos's setup?
> Why does the other side say "bash: git-upload-pack" when login shell is
> git-shell and not bash?

Sorry for the confusion, this is not about git-shell at all. I have
bash as the shell on the server, obviously.

So, in case the server runs next, the client runs master, and I try to
clone via ssh, I get the above error.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 19:08                                                     ` Johannes Schindelin
  2008-06-24 19:31                                                       ` Jakub Narebski
@ 2008-06-24 20:44                                                       ` Junio C Hamano
  2008-06-24 22:10                                                         ` Miklos Vajna
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-06-24 20:44 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Miklos Vajna, Pieter de Bie, git

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

>> Using fc48199 ("Merge branch 'master' into next", which includes
>> ed99a225) on the server, v1.5.6 on the client, I get: 
>> 
>> $ git clone server:/home/vmiklos/git/test next
>> Initialize next/.git
>> Initialized empty Git repository in /home/vmiklos/scm/git/next/.git/
>> vmiklos@server's password:
>> bash: git-upload-pack: command not found
>> fatal: The remote end hung up unexpectedly
>
> Hmm.  Probably the client needs to be newer, too.  This is going to be 
> painful.  Junio?

Even with maint client accessing an account with next git-shell as its
login shell, I do not get the above failure.

Is git-shell installed and configured correctly at all in Miklos's setup?
Why does the other side say "bash: git-upload-pack" when login shell is
git-shell and not bash?

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 19:34                                                         ` Johannes Schindelin
@ 2008-06-24 20:06                                                           ` Jakub Narebski
  2008-06-26 15:41                                                           ` Jakub Narebski
  1 sibling, 0 replies; 575+ messages in thread
From: Jakub Narebski @ 2008-06-24 20:06 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Miklos Vajna, Pieter de Bie, Junio C Hamano, git

Hello!

Johannes Schindelin wrote:
> On Tue, 24 Jun 2008, Jakub Narebski wrote:
> 
> > git-shell hackery won't solve problem, because not everybody is using 
> > git-shell.
> 
> The problem is not git-shell vs git potty.
> 
> The problem is that not everybody magically updates their clients to ask 
> for dash-less form.

What I meant here by "git-shell hackery" was for git-shell to
automagically redirect request for "git-receive-pack" to "git receive-pack"
(or "$GIT_EXEC_PATH/git-receive-pack").

But, as I said, it isn't complete solution.  Leaving git-*-pack in $PATH
for the time being (what I said) is.
-- 
Jakub Narebski
Poland

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 19:31                                                       ` Jakub Narebski
@ 2008-06-24 19:34                                                         ` Johannes Schindelin
  2008-06-24 20:06                                                           ` Jakub Narebski
  2008-06-26 15:41                                                           ` Jakub Narebski
  0 siblings, 2 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-06-24 19:34 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: Miklos Vajna, Pieter de Bie, Junio C Hamano, git

Hi,

On Tue, 24 Jun 2008, Jakub Narebski wrote:

> git-shell hackery won't solve problem, because not everybody is using 
> git-shell.

The problem is not git-shell vs git potty.

The problem is that not everybody magically updates their clients to ask 
for dash-less form.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 19:08                                                     ` Johannes Schindelin
@ 2008-06-24 19:31                                                       ` Jakub Narebski
  2008-06-24 19:34                                                         ` Johannes Schindelin
  2008-06-24 20:44                                                       ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Jakub Narebski @ 2008-06-24 19:31 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Miklos Vajna, Pieter de Bie, Junio C Hamano, git

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 24 Jun 2008, Miklos Vajna wrote:
> > 
> > Using fc48199 ("Merge branch 'master' into next", which includes
> > ed99a225) on the server, v1.5.6 on the client, I get: 
> > 
> > $ git clone server:/home/vmiklos/git/test next
> > Initialize next/.git
> > Initialized empty Git repository in /home/vmiklos/scm/git/next/.git/
> > vmiklos@server's password:
> > bash: git-upload-pack: command not found
> > fatal: The remote end hung up unexpectedly
> 
> Hmm.  Probably the client needs to be newer, too.  This is going to be 
> painful.  Junio?

It looks like git-upload-pack and git-receive-pack would
have to be left in $PATH, at least till old clients die
of old age ;-)

git-shell hackery won't solve problem, because not everybody is using
git-shell.
-- 
Jakub Narebski
Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 18:54                                                   ` Miklos Vajna
@ 2008-06-24 19:08                                                     ` Johannes Schindelin
  2008-06-24 19:31                                                       ` Jakub Narebski
  2008-06-24 20:44                                                       ` Junio C Hamano
  0 siblings, 2 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-06-24 19:08 UTC (permalink / raw)
  To: Miklos Vajna; +Cc: Pieter de Bie, Junio C Hamano, git

Hi,

On Tue, 24 Jun 2008, Miklos Vajna wrote:

> On Tue, Jun 24, 2008 at 05:25:57PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > Vienna:bin pieter$ git --version
> > > > git version 1.5.6.129.g274ea
> > > > Vienna:bin pieter$ git clone localhost:project/bonnenteller
> > > > Initialize bonnenteller/.git
> > > > Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/
> > > > Password:
> > > > bash: git-upload-pack: command not found
> > > > fatal: The remote end hung up unexpectedly
> > > > 
> > > > I think that is what Miklos meant.
> > > 
> > > Exactly. Thanks for the good description.
> > 
> > AFAICT these are fixed with ed99a225(Merge branch 'jc/dashless' into 
> > next).
> 
> Using fc48199 ("Merge branch 'master' into next", which includes
> ed99a225) on the server, v1.5.6 on the client, I get: 
> 
> $ git clone server:/home/vmiklos/git/test next
> Initialize next/.git
> Initialized empty Git repository in /home/vmiklos/scm/git/next/.git/
> vmiklos@server's password:
> bash: git-upload-pack: command not found
> fatal: The remote end hung up unexpectedly

Hmm.  Probably the client needs to be newer, too.  This is going to be 
painful.  Junio?

Sorry for the noise,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 16:25                                                 ` Johannes Schindelin
@ 2008-06-24 18:54                                                   ` Miklos Vajna
  2008-06-24 19:08                                                     ` Johannes Schindelin
  0 siblings, 1 reply; 575+ messages in thread
From: Miklos Vajna @ 2008-06-24 18:54 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Pieter de Bie, Junio C Hamano, git

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Tue, Jun 24, 2008 at 05:25:57PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Vienna:bin pieter$ git --version
> > > git version 1.5.6.129.g274ea
> > > Vienna:bin pieter$ git clone localhost:project/bonnenteller
> > > Initialize bonnenteller/.git
> > > Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/
> > > Password:
> > > bash: git-upload-pack: command not found
> > > fatal: The remote end hung up unexpectedly
> > > 
> > > I think that is what Miklos meant.
> > 
> > Exactly. Thanks for the good description.
> 
> AFAICT these are fixed with ed99a225(Merge branch 'jc/dashless' into 
> next).

Using fc48199 ("Merge branch 'master' into next", which includes
ed99a225) on the server, v1.5.6 on the client, I get: 

$ git clone server:/home/vmiklos/git/test next
Initialize next/.git
Initialized empty Git repository in /home/vmiklos/scm/git/next/.git/
vmiklos@server's password:
bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24 16:02                                               ` Miklos Vajna
@ 2008-06-24 16:25                                                 ` Johannes Schindelin
  2008-06-24 18:54                                                   ` Miklos Vajna
  0 siblings, 1 reply; 575+ messages in thread
From: Johannes Schindelin @ 2008-06-24 16:25 UTC (permalink / raw)
  To: Miklos Vajna; +Cc: Pieter de Bie, Junio C Hamano, git

Hi,

On Tue, 24 Jun 2008, Miklos Vajna wrote:

> On Tue, Jun 24, 2008 at 10:12:28AM +0200, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> > Vienna:bin pieter$ git --version
> > git version 1.5.6.129.g274ea
> > Vienna:bin pieter$ git clone localhost:project/bonnenteller
> > Initialize bonnenteller/.git
> > Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/
> > Password:
> > bash: git-upload-pack: command not found
> > fatal: The remote end hung up unexpectedly
> > 
> > I think that is what Miklos meant.
> 
> Exactly. Thanks for the good description.

AFAICT these are fixed with ed99a225(Merge branch 'jc/dashless' into 
next).

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24  8:12                                             ` Pieter de Bie
  2008-06-24  8:16                                               ` Pieter de Bie
@ 2008-06-24 16:02                                               ` Miklos Vajna
  2008-06-24 16:25                                                 ` Johannes Schindelin
  1 sibling, 1 reply; 575+ messages in thread
From: Miklos Vajna @ 2008-06-24 16:02 UTC (permalink / raw)
  To: Pieter de Bie; +Cc: Junio C Hamano, git

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

On Tue, Jun 24, 2008 at 10:12:28AM +0200, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> Vienna:bin pieter$ git --version
> git version 1.5.6.129.g274ea
> Vienna:bin pieter$ git clone localhost:project/bonnenteller
> Initialize bonnenteller/.git
> Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/
> Password:
> bash: git-upload-pack: command not found
> fatal: The remote end hung up unexpectedly
> 
> I think that is what Miklos meant.

Exactly. Thanks for the good description.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24  8:12                                             ` Pieter de Bie
@ 2008-06-24  8:16                                               ` Pieter de Bie
  2008-06-24 16:02                                               ` Miklos Vajna
  1 sibling, 0 replies; 575+ messages in thread
From: Pieter de Bie @ 2008-06-24  8:16 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Miklos Vajna, Git Mailinglist


On 24 jun 2008, at 10:12, Pieter de Bie wrote:

> I think that is what Miklos meant. Also, I think the client sends  
> the command to execute on the remote side. At least for v1.5.5  
> clients and before, that is "git-upload-pack". As this is not in  
> PATH, that command will fail on any server that runs v1.5.6 and has  
> the libexec dir.

That is supposed to be "v1.5.6" and "v1.6.0" respectively.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-24  7:59                                           ` Junio C Hamano
@ 2008-06-24  8:12                                             ` Pieter de Bie
  2008-06-24  8:16                                               ` Pieter de Bie
  2008-06-24 16:02                                               ` Miklos Vajna
  0 siblings, 2 replies; 575+ messages in thread
From: Pieter de Bie @ 2008-06-24  8:12 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Miklos Vajna, git


On 24 jun 2008, at 09:59, Junio C Hamano wrote:

> The idea of the "shell: accept 'git foo' form" patch is that as long  
> as
> the server end consistently use the same version (i.e. git-shell is  
> from
> 'next' and it knows where the rest of git is installed), things should
> work fine.  I've merged them to 'next' and pushed it out so that you  
> can
> try it.

Any clone / push operation fails if you use current next:

Vienna:bin pieter$ git --version
git version 1.5.6.129.g274ea
Vienna:bin pieter$ git clone localhost:project/bonnenteller
Initialize bonnenteller/.git
Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/
Password:
bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly

I think that is what Miklos meant. Also, I think the client sends the  
command to execute on the remote side. At least for v1.5.5 clients and  
before, that is "git-upload-pack". As this is not in PATH, that  
command will fail on any server that runs v1.5.6 and has the libexec  
dir.

- Pieter

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-21 12:14                                         ` Miklos Vajna
@ 2008-06-24  7:59                                           ` Junio C Hamano
  2008-06-24  8:12                                             ` Pieter de Bie
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-06-24  7:59 UTC (permalink / raw)
  To: Miklos Vajna; +Cc: git

Miklos Vajna <vmiklos@frugalware.org> writes:

> On Sat, Jun 21, 2008 at 02:44:50AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>> * nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
>>  + Move all dashed-form commands to libexecdir
>> 
>> Scheduled for 1.6.0.
>> 
>> * jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
>>  - Prepare execv_git_cmd() for removal of builtins from the
>>    filesystem
>>  - git-shell: accept "git foo" form
>> 
>> We do not plan to remove git-foo form completely from the filesystem at
>> this point, but git-shell may need to be updated.
>
> I may be wrong, but given that git-upload-pack/receive-pack is now not
> in PATH, I think it will be problematic to do a pull/push in case the
> server runs next, the client is 1.5.6 and the user has git-shell as
> shell, for example.

The idea of the "shell: accept 'git foo' form" patch is that as long as
the server end consistently use the same version (i.e. git-shell is from
'next' and it knows where the rest of git is installed), things should
work fine.  I've merged them to 'next' and pushed it out so that you can
try it.

I do not use git-shell in production setting (I do have one user account
whose login shell is git-shell from 'next' I use purely for testing), and
I do not know how much use it has seen in the real world.  My cursory
sanity-check ("cvs -d :ext:thatuser@myhost:/path/ co --help", and "git
ls-remote ssh://thatuser@myhost/path/")  seems to be Ok with $(bindir)
that has only git, gitk and nothing else.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-23  7:15                                         ` Junio C Hamano
@ 2008-06-23 12:15                                           ` Miklos Vajna
  2008-06-25  9:31                                           ` Junio C Hamano
  1 sibling, 0 replies; 575+ messages in thread
From: Miklos Vajna @ 2008-06-23 12:15 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

On Mon, Jun 23, 2008 at 12:15:35AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> * mv/merge-in-c (Sat Jun 21 19:15:35 2008 +0200) 14 commits
>  - Add new test case to ensure git-merge reduces octopus parents when
>    possible
>  - Add new test case to ensure git-merge filters for independent
>    parents
>  - Build in merge
>  - Introduce reduce_heads()
>  - Introduce get_merge_bases_many()
>  - Add new test to ensure git-merge handles more than 25 refs.
>  - Introduce get_octopus_merge_bases() in commit.c
>  - git-fmt-merge-msg: make it usable from other builtins
>  - Move read_cache_unmerged() to read-cache.c
>  - parseopt: add a new PARSE_OPT_ARGV0_IS_AN_OPTION option
>  - Add new test to ensure git-merge handles pull.twohead and
>    pull.octopus
>  - Move parse-options's skip_prefix() to git-compat-util.h
>  - Move commit_list_count() to commit.c
>  - Move split_cmdline() to alias.c

"Add new test case to ensure git-merge reduces octopus parents when
possible" does exactly the same as "Add new test case to ensure
git-merge filters for independent parents", so I think you should drop
the later. Only the name of the test and the commit message differs, and
I think we want to avoid redundancy in the testsuite. ;-)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-06-21  9:44                                       ` Junio C Hamano
  2008-06-21 12:14                                         ` Miklos Vajna
@ 2008-06-23  7:15                                         ` Junio C Hamano
  2008-06-23 12:15                                           ` Miklos Vajna
  2008-06-25  9:31                                           ` Junio C Hamano
  1 sibling, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-06-23  7:15 UTC (permalink / raw)
  To: git

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.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  But bigger changes will be:

 * MinGW will be in.

 * /usr/bin/git-cat-file is no more.  The bulk of the git commands will
   move to /usr/libexec/git-core/ or somesuch.

 * git-merge will be rewritten in C.

Currently tip of 'pu' is broken and does not pass tests, as j6t/mingw has
interaction with dr/ceiling and jc/merge-theirs has interaction with
mv/merge-in-c.

----------------------------------------------------------------
[New Topics]

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 - rerere.autoupdate
 - t4200: fix rerere test
 - rerere: remove dubious "tail_optimization"
 - git-rerere: detect unparsable conflicts
 - rerere: rerere_created_at() and has_resolution() abstraction

* sb/rebase (Sun Jun 22 01:55:50 2008 +0200) 2 commits
 + t3404: stricter tests for git-rebase--interactive
 + api-builtin.txt: update and fix typo

* sb/maint-rebase (Sun Jun 22 16:07:02 2008 +0200) 1 commit
 + git-rebase.sh: Add check if rebase is in progress

----------------------------------------------------------------
[Will merge to master soon]

* lw/gitweb (Thu Jun 19 22:03:21 2008 +0200) 1 commit
 + gitweb: standarize HTTP status codes

* lt/config-fsync (Wed Jun 18 15:18:44 2008 -0700) 4 commits
 + Add config option to enable 'fsync()' of object files
 + Split up default "i18n" and "branch" config parsing into helper
   routines
 + Split up default "user" config parsing into helper routine
 + Split up default "core" config parsing into helper routine

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 + Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

* sr/tests (Sun Jun 8 16:04:35 2008 +0200) 3 commits
 + Hook up the result aggregation in the test makefile.
 + A simple script to parse the results from the testcases
 + Modify test-lib.sh to output stats to t/test-results/*

* jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits
 + Teach "git clone" to pack refs
 + Prepare testsuite for a "git clone" that packs refs
 + Move pack_refs() and friends into libgit
 + Incorporate fetched packs in future object traversal

This is useful when cloning from a repository with insanely large number
of refs.

* lw/perlish (Thu Jun 19 22:32:49 2008 +0200) 2 commits
 + Git.pm: add test suite
 + t/test-lib.sh: add test_external and test_external_without_stderr

Beginning of regression tests for Perl part of the system.

----------------------------------------------------------------
[Actively Cooking]

* mv/merge-in-c (Sat Jun 21 19:15:35 2008 +0200) 14 commits
 - Add new test case to ensure git-merge reduces octopus parents when
   possible
 - Add new test case to ensure git-merge filters for independent
   parents
 - Build in merge
 - Introduce reduce_heads()
 - Introduce get_merge_bases_many()
 - Add new test to ensure git-merge handles more than 25 refs.
 - Introduce get_octopus_merge_bases() in commit.c
 - git-fmt-merge-msg: make it usable from other builtins
 - Move read_cache_unmerged() to read-cache.c
 - parseopt: add a new PARSE_OPT_ARGV0_IS_AN_OPTION option
 - Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 - Move parse-options's skip_prefix() to git-compat-util.h
 - Move commit_list_count() to commit.c
 - Move split_cmdline() to alias.c

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

----------------------------------------------------------------
[Graduated to "master"]

* rs/archive-ignore (Sun Jun 8 18:42:33 2008 +0200) 1 commit
 + Teach new attribute 'export-ignore' to git-archive

* lt/racy-empty (Tue Jun 10 10:44:43 2008 -0700) 1 commit
 + racy-git: an empty blob has a fixed object name

* sn/static (Thu Jun 19 08:21:11 2008 +0900) 2 commits
 + config.c: make git_env_bool() static
 + environment.c: remove unused function

* jc/maint-combine-diff-pre-context (Wed Jun 18 23:59:41 2008 -0700) 1 commit
 + diff -c/--cc: do not include uninteresting deletion before leading
   context

* lt/maint-gitdir-relative (Thu Jun 19 12:34:06 2008 -0700) 1 commit
 + Make git_dir a path relative to work_tree in setup_work_tree()

* jn/web (Tue Jun 10 19:21:44 2008 +0200) 2 commits
 + gitweb: Separate generating 'sort by' table header
 + gitweb: Separate filling list of projects info

* rg/gitweb (Fri Jun 6 09:53:32 2008 +0200) 1 commit
 + gitweb: remove git_blame and rename git_blame2 to git_blame

* kh/update-ref (Tue Jun 3 01:34:53 2008 +0200) 2 commits
 + Make old sha1 optional with git update-ref -d
 + Clean up builtin-update-ref's option parsing

* mo/status-untracked (Thu Jun 5 14:47:50 2008 +0200) 3 commits
 + Add configuration option for default untracked files mode
 + Add argument 'no' commit/status option -u|--untracked-files
 + Add an optional <mode> argument to commit/status -u|--untracked-
   files option

* jk/test (Sat Jun 14 03:28:07 2008 -0400) 5 commits
 + enable whitespace checking of test scripts
 + avoid trailing whitespace in zero-change diffstat lines
 + avoid whitespace on empty line in automatic usage message
 + mask necessary whitespace policy violations in test scripts
 + fix whitespace violations in test scripts

Tightens whitespace rules for t/*.sh scripts.

* pb/fast-export (Wed Jun 11 13:17:04 2008 +0200) 1 commit
 + builtin-fast-export: Add importing and exporting of revision marks

----------------------------------------------------------------
[On Hold]

* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
 + Remove the use of '--' in merge program invocation

Waiting for success reports from people who use various backends.

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
 - compat/pread.c: Add a forward declaration to fix a warning
 - Windows: Fix ntohl() related warnings about printf formatting
 - Windows: TMP and TEMP environment variables specify a temporary
   directory.
 - Windows: Make 'git help -a' work.
 - Windows: Work around an oddity when a pipe with no reader is
   written to.
 - Windows: Make the pager work.
 - When installing, be prepared that template_dir may be relative.
 - Windows: Use a relative default template_dir and ETC_GITCONFIG
 - Windows: Compute the fallback for exec_path from the program
   invocation.
 - Turn builtin_exec_path into a function.
 - Windows: Use a customized struct stat that also has the st_blocks
   member.
 - Windows: Add a custom implementation for utime().
 - Windows: Add a new lstat and fstat implementation based on Win32
   API.
 - Windows: Implement a custom spawnve().
 - Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 - Windows: Work around incompatible sort and find.
 - Windows: Implement asynchronous functions as threads.
 - Windows: Disambiguate DOS style paths from SSH URLs.
 - Windows: A rudimentary poll() emulation.
 - Windows: Change the name of hook scripts to make them not
   executable.
 - Windows: Implement start_command().
 - Windows: A pipe() replacement whose ends are not inherited to
   children.
 - Windows: Wrap execve so that shell scripts can be invoked.
 - Windows: Implement setitimer() and sigaction().
 - Windows: Fix PRIuMAX definition.
 - Windows: Implement gettimeofday().
 - Windows: Handle absolute paths in
   safe_create_leading_directories().
 - Windows: Treat Windows style path names.
 - setup.c: Prepare for Windows directory separators.
 - Windows: Work around misbehaved rename().
 - Windows: always chmod(, 0666) before unlink().
 - Windows: A minimal implemention of getpwuid().
 - Windows: Implement a wrapper of the open() function.
 - Windows: Strip ".exe" from the program name.
 - Windows: Use the Windows style PATH separator ';'.
 - Add target architecture MinGW.
 - Compile some programs only conditionally.
 - Add compat/regex.[ch] and compat/fnmatch.[ch].

No explanation is necessary ;-).  The series is probably 'next' worthy
as-is.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

----------------------------------------------------------------
[Stalled/Needs more work]

* jc/reflog-expire (Sun Jun 15 23:48:46 2008 -0700) 1 commit
 - Per-ref reflog expiry configuration

Perhaps a good foundation for optionally unexpirable stash.  As 1.6.0 will
be a good time to make backward incompatible changes, we might make expiry
period of stash 'never' in new repositories.  Needs a concensus.

* jc/merge-theirs (Fri Jun 20 00:17:59 2008 -0700) 2 commits
 - git-merge-recursive-{ours,theirs}
 - git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends may need to change, though.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

----------------------------------------------------------------
[Dropped for now]

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 . Introduce fast forward option only
 . Head reduction before selecting merge strategy
 . Restructure git-merge.sh
 . Introduce -ff=<fast forward option>
 . New merge tests
 . Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 . Use perl instead of tac
 . Fix t3404 assumption that `wc -l` does not use whitespace.
 . rebase -i: Use : in expr command instead of match.
 . rebase -i: update the implementation of 'mark' command
 . Add option --preserve-tags
 . Teach rebase interactive the tag command
 . Add option --first-parent
 . Do rebase with preserve merges with advanced TODO list
 . Select all lines with fake-editor
 . Unify the length of $SHORT* and the commits in the TODO list
 . Teach rebase interactive the merge command
 . Move redo merge code in a function
 . Teach rebase interactive the reset command
 . Teach rebase interactive the mark command
 . Move cleanup code into it's own function
 . Don't append default merge message to -m message
 . fake-editor: output TODO list if unchanged

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 . WIP: rethink replay merge
 . Start using replay-tree merge in cherry-pick
 . revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 . git-am --forge: add Signed-off-by: line for the author
 . git-am: clean-up Signed-off-by: lines
 . stripspace: add --log-clean option to clean up signed-off-by:
   lines
 . stripspace: use parse_options()
 . Add "git am -s" test
 . git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 . "git push": tellme-more protocol extension

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-21  9:44                                       ` Junio C Hamano
@ 2008-06-21 12:14                                         ` Miklos Vajna
  2008-06-24  7:59                                           ` Junio C Hamano
  2008-06-23  7:15                                         ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Miklos Vajna @ 2008-06-21 12:14 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

On Sat, Jun 21, 2008 at 02:44:50AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> * nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
>  + Move all dashed-form commands to libexecdir
> 
> Scheduled for 1.6.0.
> 
> * jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
>  - Prepare execv_git_cmd() for removal of builtins from the
>    filesystem
>  - git-shell: accept "git foo" form
> 
> We do not plan to remove git-foo form completely from the filesystem at
> this point, but git-shell may need to be updated.

I may be wrong, but given that git-upload-pack/receive-pack is now not
in PATH, I think it will be problematic to do a pull/push in case the
server runs next, the client is 1.5.6 and the user has git-shell as
shell, for example.

Or have I missed something?

Thanks

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-06-18  7:31                                     ` Junio C Hamano
  2008-06-19  8:58                                       ` Johan Herland
@ 2008-06-21  9:44                                       ` Junio C Hamano
  2008-06-21 12:14                                         ` Miklos Vajna
  2008-06-23  7:15                                         ` Junio C Hamano
  1 sibling, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-06-21  9:44 UTC (permalink / raw)
  To: git

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.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  But bigger changes will be:

 * MinGW will be in.

 * /usr/bin/git-cat-file is no more.  The bulk of the git commands will
   move to /usr/libexec/git-core/ or somesuch.

 * git-merge will be rewritten in C.

Currently tip of 'pu' is broken and does not pass tests, as j6t/mingw has
interaction with dr/ceiling and jc/merge-theirs has interaction with
mv/merge-in-c.

----------------------------------------------------------------
[New Topics]

* jc/merge-theirs (Fri Jun 20 00:17:59 2008 -0700) 2 commits
 - git-merge-recursive-{ours,theirs}
 - git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends may need to change, though.

* lt/racy-empty (Tue Jun 10 10:44:43 2008 -0700) 1 commit
 + racy-git: an empty blob has a fixed object name

* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
 + Remove the use of '--' in merge program invocation

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
 - compat/pread.c: Add a forward declaration to fix a warning
 - Windows: Fix ntohl() related warnings about printf formatting
 - Windows: TMP and TEMP environment variables specify a temporary
   directory.
 - Windows: Make 'git help -a' work.
 - Windows: Work around an oddity when a pipe with no reader is
   written to.
 - Windows: Make the pager work.
 - When installing, be prepared that template_dir may be relative.
 - Windows: Use a relative default template_dir and ETC_GITCONFIG
 - Windows: Compute the fallback for exec_path from the program
   invocation.
 - Turn builtin_exec_path into a function.
 - Windows: Use a customized struct stat that also has the st_blocks
   member.
 - Windows: Add a custom implementation for utime().
 - Windows: Add a new lstat and fstat implementation based on Win32
   API.
 - Windows: Implement a custom spawnve().
 - Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 - Windows: Work around incompatible sort and find.
 - Windows: Implement asynchronous functions as threads.
 - Windows: Disambiguate DOS style paths from SSH URLs.
 - Windows: A rudimentary poll() emulation.
 - Windows: Change the name of hook scripts to make them not
   executable.
 - Windows: Implement start_command().
 - Windows: A pipe() replacement whose ends are not inherited to
   children.
 - Windows: Wrap execve so that shell scripts can be invoked.
 - Windows: Implement setitimer() and sigaction().
 - Windows: Fix PRIuMAX definition.
 - Windows: Implement gettimeofday().
 - Windows: Handle absolute paths in
   safe_create_leading_directories().
 - Windows: Treat Windows style path names.
 - setup.c: Prepare for Windows directory separators.
 - Windows: Work around misbehaved rename().
 - Windows: always chmod(, 0666) before unlink().
 - Windows: A minimal implemention of getpwuid().
 - Windows: Implement a wrapper of the open() function.
 - Windows: Strip ".exe" from the program name.
 - Windows: Use the Windows style PATH separator ';'.
 - Add target architecture MinGW.
 - Compile some programs only conditionally.
 - Add compat/regex.[ch] and compat/fnmatch.[ch].

No explanation is necessary ;-).

* sn/static (Thu Jun 19 08:21:11 2008 +0900) 2 commits
 + config.c: make git_env_bool() static
 + environment.c: remove unused function

* lt/config-fsync (Wed Jun 18 15:18:44 2008 -0700) 4 commits
 + Add config option to enable 'fsync()' of object files
 + Split up default "i18n" and "branch" config parsing into helper
   routines
 + Split up default "user" config parsing into helper routine
 + Split up default "core" config parsing into helper routine

* lw/gitweb (Thu Jun 19 22:03:21 2008 +0200) 1 commit
 + gitweb: standarize HTTP status codes

* mv/merge-in-c (Fri Jun 20 01:22:36 2008 +0200) 11 commits
 - Add new test to ensure git-merge handles more than 25 refs.
 - Build in merge
 - Introduce filter_independent() in commit.c
 - Introduce get_octopus_merge_bases() in commit.c
 - git-fmt-merge-msg: make it usable from other builtins
 - Move read_cache_unmerged() to read-cache.c
 - parseopt: add a new PARSE_OPT_ARGV0_IS_AN_OPTION option
 - Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 - Move parse-options's skip_prefix() to git-compat-util.h
 - Move commit_list_count() to commit.c
 - Move split_cmdline() to alias.c

* jc/maint-combine-diff-pre-context (Wed Jun 18 23:59:41 2008 -0700) 1 commit
 + diff -c/--cc: do not include uninteresting deletion before leading
   context

* lt/maint-gitdir-relative (Thu Jun 19 12:34:06 2008 -0700) 1 commit
 + Make git_dir a path relative to work_tree in setup_work_tree()

----------------------------------------------------------------
[Actively Cooking]

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 + Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

* jn/web (Tue Jun 10 19:21:44 2008 +0200) 2 commits
 + gitweb: Separate generating 'sort by' table header
 + gitweb: Separate filling list of projects info

* rs/archive-ignore (Sun Jun 8 18:42:33 2008 +0200) 1 commit
 + Teach new attribute 'export-ignore' to git-archive

* rg/gitweb (Fri Jun 6 09:53:32 2008 +0200) 1 commit
 + gitweb: remove git_blame and rename git_blame2 to git_blame

* kh/update-ref (Tue Jun 3 01:34:53 2008 +0200) 2 commits
 + Make old sha1 optional with git update-ref -d
 + Clean up builtin-update-ref's option parsing

* mo/status-untracked (Thu Jun 5 14:47:50 2008 +0200) 3 commits
 + Add configuration option for default untracked files mode
 + Add argument 'no' commit/status option -u|--untracked-files
 + Add an optional <mode> argument to commit/status -u|--untracked-
   files option

* sr/tests (Sun Jun 8 16:04:35 2008 +0200) 3 commits
 + Hook up the result aggregation in the test makefile.
 + A simple script to parse the results from the testcases
 + Modify test-lib.sh to output stats to t/test-results/*

* jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits
 + Teach "git clone" to pack refs
 + Prepare testsuite for a "git clone" that packs refs
 + Move pack_refs() and friends into libgit
 + Incorporate fetched packs in future object traversal

This is useful when cloning from a repository with insanely large number
of refs.

* jc/reflog-expire (Sun Jun 15 23:48:46 2008 -0700) 1 commit
 - Per-ref reflog expiry configuration

Perhaps a good foundation for optionally unexpirable stash.  As 1.6.0 will
be a good time to make backward incompatible changes, we might make expiry
period of stash 'never' in new repositories.  Needs a concensus.

* lw/perlish (Thu Jun 19 22:32:49 2008 +0200) 2 commits
 + Git.pm: add test suite
 + t/test-lib.sh: add test_external and test_external_without_stderr

Beginning of regression tests for Perl part of the system.

* jk/test (Sat Jun 14 03:28:07 2008 -0400) 5 commits
 + enable whitespace checking of test scripts
 + avoid trailing whitespace in zero-change diffstat lines
 + avoid whitespace on empty line in automatic usage message
 + mask necessary whitespace policy violations in test scripts
 + fix whitespace violations in test scripts

Tightens whitespace rules for t/*.sh scripts.

* pb/fast-export (Wed Jun 11 13:17:04 2008 +0200) 1 commit
 + builtin-fast-export: Add importing and exporting of revision marks

----------------------------------------------------------------
[Graduated to "master"]

Nothing today but expect many small ones to come out of 'next' this
weekend.

----------------------------------------------------------------
[On Hold]

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 - "git push": tellme-more protocol extension

Kicked back to 'pu' for now.

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 - Use perl instead of tac
 - Fix t3404 assumption that `wc -l` does not use whitespace.
 - rebase -i: Use : in expr command instead of match.
 - rebase -i: update the implementation of 'mark' command
 - Add option --preserve-tags
 - Teach rebase interactive the tag command
 - Add option --first-parent
 - Do rebase with preserve merges with advanced TODO list
 - Select all lines with fake-editor
 - Unify the length of $SHORT* and the commits in the TODO list
 - Teach rebase interactive the merge command
 - Move redo merge code in a function
 - Teach rebase interactive the reset command
 - Teach rebase interactive the mark command
 - Move cleanup code into it's own function
 - Don't append default merge message to -m message
 - fake-editor: output TODO list if unchanged

It is very likely that this whole thing will be reverted from 'next' and
be replaced with the new sequenser series during 1.6.0 cycle.

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 - Introduce fast forward option only
 - Head reduction before selecting merge strategy
 - Restructure git-merge.sh
 - Introduce -ff=<fast forward option>
 - New merge tests
 - Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-18  7:31                                     ` Junio C Hamano
@ 2008-06-19  8:58                                       ` Johan Herland
  2008-06-21  9:44                                       ` Junio C Hamano
  1 sibling, 0 replies; 575+ messages in thread
From: Johan Herland @ 2008-06-19  8:58 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

On Wednesday 18 June 2008, Junio C Hamano wrote:
> [New Topics]
>
> * jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits
>  - Teach "git clone" to pack refs
>  - Prepare testsuite for a "git clone" that packs refs
>  - Move pack_refs() and friends into libgit
>  - Incorporate fetched packs in future object traversal
>
> Would be helpful cloning from a repository with insanely large number of
> refs.

The first 3 patches (i.e. the bottom 3 in the above list) might be 
considered general cleanup patches, and are independent of each other (i.e. 
you might want to include them on their own merit, independently of patch 
#4).

The final patch doesn't make any difference for "regular" repos (e.g. 
git.git with ~200 refs) on Linux (see below). But once the number of refs 
increase, the difference becomes obvious.

Here are some numbers to give some more context:

All tests done on 64-bit quad-core Linux, cloning locally (hard-linked):

~200 refs (git.git):
current next:    0.2s
w/above patches: 0.2s

~1000 refs (test repo):
current next:    0.16s
w/above patches: 0.05s

~11000 refs (test repo):
current next:    1.3s
w/above patches: 0.3s

~26000 refs (actual repo at $dayjob):
current next:    3.2s
w/above patches: 0.8s


Regards,

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-06-13 10:16                                   ` Junio C Hamano
@ 2008-06-18  7:31                                     ` Junio C Hamano
  2008-06-19  8:58                                       ` Johan Herland
  2008-06-21  9:44                                       ` Junio C Hamano
  0 siblings, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-06-18  7:31 UTC (permalink / raw)
  To: git

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.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * 1.5.6 Final (late this week).

----------------------------------------------------------------
[New Topics]

* jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits
 - Teach "git clone" to pack refs
 - Prepare testsuite for a "git clone" that packs refs
 - Move pack_refs() and friends into libgit
 - Incorporate fetched packs in future object traversal

Would be helpful cloning from a repository with insanely large number of
refs.

* jc/reflog-expire (Sun Jun 15 23:48:46 2008 -0700) 1 commit
 - Per-ref reflog expiry configuration

Perhaps a good foundation for optionally unexpirable stash.

* lw/perlish (Tue Jun 17 08:59:51 2008 +0200) 2 commits
 - Git.pm: add test suite
 - t/test-lib.sh: add test_external and test_external_without_stderr

IO::String dependency is a bit worrysome, and the error diagnostic could
hopefully be made more obvious, but I do not have a fundamental objection
to this series.

* jk/test (Sat Jun 14 03:28:07 2008 -0400) 5 commits
 + enable whitespace checking of test scripts
 + avoid trailing whitespace in zero-change diffstat lines
 + avoid whitespace on empty line in automatic usage message
 + mask necessary whitespace policy violations in test scripts
 + fix whitespace violations in test scripts

Tightens whitespace rules for t/*.sh scripts.

* pb/fast-export (Wed Jun 11 13:17:04 2008 +0200) 1 commit
 - builtin-fast-export: Add importing and exporting of revision marks

----------------------------------------------------------------
[Graduated to "master"]

* rs/attr (Sun Jun 8 17:16:11 2008 +0200) 1 commit
 + Ignore .gitattributes in bare repositories

----------------------------------------------------------------
[On Hold]

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 + "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

It is very likely that this whole thing will be reverted from 'next' and
be replaced with the new sequenser series during 1.6.0 cycle.

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 - Introduce fast forward option only
 - Head reduction before selecting merge strategy
 - Restructure git-merge.sh
 - Introduce -ff=<fast forward option>
 - New merge tests
 - Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.  There is no
fundamental reason to favor one over the other, so I'll be torn after
1.5.6 happens, but not before.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 - Eliminate an unnecessary chdir("..")
 - Add support for GIT_CEILING_DIRECTORIES
 - Fold test-absolute-path into test-path-utils
 - Implement normalize_absolute_path

* jn/web (Tue Jun 10 19:21:44 2008 +0200) 2 commits
 - gitweb: Separate generating 'sort by' table header
 - gitweb: Separate filling list of projects info

* rs/archive-ignore (Sun Jun 8 18:42:33 2008 +0200) 1 commit
 + Teach new attribute 'export-ignore' to git-archive

* rg/gitweb (Fri Jun 6 09:53:32 2008 +0200) 1 commit
 + gitweb: remove git_blame and rename git_blame2 to git_blame

* kh/update-ref (Tue Jun 3 01:34:53 2008 +0200) 2 commits
 + Make old sha1 optional with git update-ref -d
 + Clean up builtin-update-ref's option parsing

* mo/status-untracked (Thu Jun 5 14:47:50 2008 +0200) 3 commits
 - Add configuration option for default untracked files mode
 - Add argument 'no' commit/status option -u|--untracked-files
 - Add an optional <mode> argument to commit/status -u|--untracked-
   files option

* sr/tests (Sun Jun 8 16:04:35 2008 +0200) 3 commits
 + Hook up the result aggregation in the test makefile.
 + A simple script to parse the results from the testcases
 + Modify test-lib.sh to output stats to t/test-results/*

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-06-02  7:58                                 ` Junio C Hamano
                                                     ` (2 preceding siblings ...)
  2008-06-02 15:17                                   ` Johannes Schindelin
@ 2008-06-13 10:16                                   ` Junio C Hamano
  2008-06-18  7:31                                     ` Junio C Hamano
  3 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-06-13 10:16 UTC (permalink / raw)
  To: git

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.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * 1.5.6-rc3 this weekend.

 * 1.5.6 Final (2008-06-20).

----------------------------------------------------------------
[New Topics]

* jn/web (Tue Jun 10 19:21:44 2008 +0200) 2 commits
 - gitweb: Separate generating 'sort by' table header
 - gitweb: Separate filling list of projects info

* rs/archive-ignore (Sun Jun 8 18:42:33 2008 +0200) 1 commit
 + Teach new attribute 'export-ignore' to git-archive

* rg/gitweb (Fri Jun 6 09:53:32 2008 +0200) 1 commit
 + gitweb: remove git_blame and rename git_blame2 to git_blame

* kh/update-ref (Tue Jun 3 01:34:53 2008 +0200) 2 commits
 + Make old sha1 optional with git update-ref -d
 + Clean up builtin-update-ref's option parsing

* mo/status-untracked (Thu Jun 5 14:47:50 2008 +0200) 3 commits
 - Add configuration option for default untracked files mode
 - Add argument 'no' commit/status option -u|--untracked-files
 - Add an optional <mode> argument to commit/status -u|--untracked-
   files option

* rs/attr (Sun Jun 8 17:16:11 2008 +0200) 1 commit
 + Ignore .gitattributes in bare repositories

* sr/tests (Sun Jun 8 16:04:35 2008 +0200) 3 commits
 + Hook up the result aggregation in the test makefile.
 + A simple script to parse the results from the testcases
 + Modify test-lib.sh to output stats to t/test-results/*

None of the above are 1.5.6 material, except for the "ignore
.gitattributes file in bare repositories" from René, which I think we
should have.

----------------------------------------------------------------
[Graduated to "master"]

Nothing this week.

----------------------------------------------------------------
[Stalled]

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 + "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

It is very likely that this whole thing will be reverted from 'next' and
be replaced with the new sequenser series during 1.6.0 cycle.

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 - Introduce fast forward option only
 - Head reduction before selecting merge strategy
 - Restructure git-merge.sh
 - Introduce -ff=<fast forward option>
 - New merge tests
 - Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C but it appears
neither will happen by 1.5.6 anyway.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 - Eliminate an unnecessary chdir("..")
 - Add support for GIT_CEILING_DIRECTORIES
 - Fold test-absolute-path into test-path-utils
 - Implement normalize_absolute_path

----------------------------------------------------------------
[On Hold]

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-02 19:17                                           ` Johannes Schindelin
@ 2008-06-02 19:25                                             ` Johannes Schindelin
  0 siblings, 0 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-06-02 19:25 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Shawn O. Pearce, git

Hi,

On Mon, 2 Jun 2008, Johannes Schindelin wrote:

> On Mon, 2 Jun 2008, Junio C Hamano wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > After sending the mail, I actually got an idea:
> > >
> > > 	.git/logs/attic/<timestamp>/<refname>

Just tried that, and for obvious reasons it fails the testsuite: Git is 
just too darned fast.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-02 18:13                                         ` Junio C Hamano
@ 2008-06-02 19:17                                           ` Johannes Schindelin
  2008-06-02 19:25                                             ` Johannes Schindelin
  0 siblings, 1 reply; 575+ messages in thread
From: Johannes Schindelin @ 2008-06-02 19:17 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Shawn O. Pearce, git

Hi,

On Mon, 2 Jun 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > After sending the mail, I actually got an idea:
> >
> > 	.git/logs/attic/<timestamp>/<refname>
> >
> > I think this should work without problems.  In that case, git-gc also 
> > handles the garbage collection.
> 
> I do not like that particular color of the bikeshed, but I'd agree that 
> it certainly is the easiest route from both the implementation and the 
> design point of view.

Okay, how about "deleted-%d.%m.%Y-%H:%M:%S" instead of "attic/%s"?

> All of the "hard stuff" Shawn mentions goes away, and you are left with 
> only one new "hard stuff", which is much easier to solve:
> 
>  - Should there be a way to really remove the archived reflog?
> 
> And my answer is "yes, a new subcommand to 'git-reflog' to list and
> another subcommand to remove one".

You mean a subcommand to list just the refs that exist in the deleted-* 
namespace?

As to remove one, how about:

	 git reflog --expire=now --expire-unreachable=now \
		deleted-<date>/<refname>

Hmm?

> As to default behaviour, probably we would by default archive any local 
> branches, and _not_ archive other things like remote trackers and tags.  

Unfortunately, this is exactly what I need: remote trackers and tags.  
Since I have to delete branches from repo.or.cz as long as the pruning of 
forked projects' objects does not work correctly.

> A new configuration variable reflog.archive = {none,heads,all} would be 
> honored and absense of it defaults to reflog.archive = heads.

Sure, that makes sense.  I'd just "git config --global reflog.archive 
all".

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-02 16:14                                       ` Johannes Schindelin
@ 2008-06-02 18:13                                         ` Junio C Hamano
  2008-06-02 19:17                                           ` Johannes Schindelin
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-06-02 18:13 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Shawn O. Pearce, git

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

> After sending the mail, I actually got an idea:
>
> 	.git/logs/attic/<timestamp>/<refname>
>
> I think this should work without problems.  In that case, git-gc also 
> handles the garbage collection.

I do not like that particular color of the bikeshed, but I'd agree that it
certainly is the easiest route from both the implementation and the design
point of view.  All of the "hard stuff" Shawn mentions goes away, and you 
are left with only one new "hard stuff", which is much easier to solve:

 - Should there be a way to really remove the archived reflog?

And my answer is "yes, a new subcommand to 'git-reflog' to list and
another subcommand to remove one".

As to default behaviour, probably we would by default archive any local
branches, and _not_ archive other things like remote trackers and tags.  A
new configuration variable reflog.archive = {none,heads,all} would be
honored and absense of it defaults to reflog.archive = heads.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-02 15:43                                     ` Shawn O. Pearce
@ 2008-06-02 16:14                                       ` Johannes Schindelin
  2008-06-02 18:13                                         ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Johannes Schindelin @ 2008-06-02 16:14 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: Junio C Hamano, git

Hi,

On Mon, 2 Jun 2008, Shawn O. Pearce wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > _However_, I still try to come up with some attic for deleted refs.  
> > It is not just a matter of moving the logs to a different namespace 
> > because of D/F conflicts.
> 
> Record the delete at the end of the reflog so we have a date/time record 
> and the last SHA-1 value, just in case it doesn't match up with the most 
> recent reflog entry (e.g. user ran some legacy tool that just redirect 
> git-commit-tree output to the branch itself).

That's obvious.

> Take the SHA-1 hash of the reflog now that the final entry is written.  
> Rename the file to .git/attic/$sha1 and call it a day. I thought about 
> compressing the file too, but its not worth saving the disk space here 
> and it would make tools that inspect the attic expensive to run.
> 
> The attic can be easily cleaned out by looking at the timestamp of the 
> last record of each file.  Attic log files older than X days can be 
> removed.  This is better than reading the modification time of the file 
> as we don't have to worry about some copy tool not saving the 
> modification time if the user moves/copies the repository.

I actually would prefer to have the logs in the .git/logs/ directory, so 
that I can easily reuse all existing reflog handling.

After sending the mail, I actually got an idea:

	.git/logs/attic/<timestamp>/<refname>

I think this should work without problems.  In that case, git-gc also 
handles the garbage collection.

> The hard stuff is:
> 
> - Should the commits listed in attic reflogs be considered reachable 
>   when we pack, prune or fsck?  Commits in a reflog are, even if they 
>   aren't reachable from a transport perspective.

Yes, they should.  That is the whole purpose of keeping the reflogs: I 
want to be able to resurrect the branch, if I deleted it by accident.

> - What command gets the extra options to see what branches are in the 
>   attic and when they got there?

I'd like to have them listed with the other reflogs.

> - What command gets the extra option to recover a branch from the attic?

None.  It is the user's responsibility to use the information wisely.

git branch resurrected attic/<bla>/refs/heads/accidentally-deleted@{1}

> - When we recover a branch from the attic is it sufficient to recover it 
>   to the name it had at time of deletion?  Should we allow you to 
>   recover it to a different name?

See above.  I think resurrecting under the same name would not necessarily 
be the most frequent operation on deleted refs.

> - Is it sufficient to make you recover the branch from the attic before 
>   you can access the rest of its reflog with porcelain?
> 
> - What do we do if we recover a branch with stale reflog entries
>   and the attic is deemed to not be reachable (see above).

I'll just go with my idea, implement it, and post it here for discussion.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-02 15:17                                   ` Johannes Schindelin
@ 2008-06-02 15:43                                     ` Shawn O. Pearce
  2008-06-02 16:14                                       ` Johannes Schindelin
  0 siblings, 1 reply; 575+ messages in thread
From: Shawn O. Pearce @ 2008-06-02 15:43 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> _However_, I still try to come up with some attic for deleted refs.  It is 
> not just a matter of moving the logs to a different namespace because of 
> D/F conflicts.

Record the delete at the end of the reflog so we have a date/time
record and the last SHA-1 value, just in case it doesn't match up
with the most recent reflog entry (e.g. user ran some legacy tool
that just redirect git-commit-tree output to the branch itself).

Take the SHA-1 hash of the reflog now that the final entry is
written.  Rename the file to .git/attic/$sha1 and call it a day.
I thought about compressing the file too, but its not worth saving
the disk space here and it would make tools that inspect the attic
expensive to run.

The attic can be easily cleaned out by looking at the timestamp of
the last record of each file.  Attic log files older than X days can
be removed.  This is better than reading the modification time of
the file as we don't have to worry about some copy tool not saving
the modification time if the user moves/copies the repository.

That's all the easy stuff.

The hard stuff is:

- Should the commits listed in attic reflogs be considered reachable
  when we pack, prune or fsck?  Commits in a reflog are, even if
  they aren't reachable from a transport perspective.

- What command gets the extra options to see what branches are in
  the attic and when they got there?

- What command gets the extra option to recover a branch from the
  attic?

- When we recover a branch from the attic is it sufficient to recover
  it to the name it had at time of deletion?  Should we allow you to
  recover it to a different name?

- Is it sufficient to make you recover the branch from the attic
  before you can access the rest of its reflog with porcelain?

- What do we do if we recover a branch with stale reflog entries
  and the attic is deemed to not be reachable (see above).

-- 
Shawn.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-02  7:58                                 ` Junio C Hamano
  2008-06-02  8:10                                   ` Jakub Narebski
  2008-06-02 11:56                                   ` Sebastian Bober
@ 2008-06-02 15:17                                   ` Johannes Schindelin
  2008-06-02 15:43                                     ` Shawn O. Pearce
  2008-06-13 10:16                                   ` Junio C Hamano
  3 siblings, 1 reply; 575+ messages in thread
From: Johannes Schindelin @ 2008-06-02 15:17 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Mon, 2 Jun 2008, Junio C Hamano wrote:

> * sp/remote (Sun Jun 1 00:28:04 2008 -0400) 3 commits
>  + Make "git-remote rm" delete refs acccording to fetch specs
>  + Make "git-remote prune" delete refs according to fetch specs
>  + Remove unused remote_prefix member in builtin-remote
> 
> "git-remote" had an unwarranted assumption that everybody uses 
> refs/remotes/$it namespace to track remote repository called $it.  This 
> series is a reasonable fix to it.

AFAIR this limitation was already in the scripted version, and I tried to 
wrap my head around lifting it.  However, I did not end up with the 
brillian analysis of Shawn, and was almost sending a reply contradicting 
his logic.  However, I agree with Shawn that it is the same issue as 
contradicting fetches, so if it leads to problems, it is a pilot error.

_However_, I still try to come up with some attic for deleted refs.  It is 
not just a matter of moving the logs to a different namespace because of 
D/F conflicts.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-02  7:58                                 ` Junio C Hamano
  2008-06-02  8:10                                   ` Jakub Narebski
@ 2008-06-02 11:56                                   ` Sebastian Bober
  2008-06-02 15:17                                   ` Johannes Schindelin
  2008-06-13 10:16                                   ` Junio C Hamano
  3 siblings, 0 replies; 575+ messages in thread
From: Sebastian Bober @ 2008-06-02 11:56 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Mon, Jun 02, 2008 at 12:58:03AM -0700, Junio C Hamano wrote:
> 
> I've looked at the Git.pm testsuite that uses Test::More briefly but
> hadn't really reviewed it.  Is Test::More commonly used, considered solid
> and widely available?

yes it is on all three points. It is the most commonly used test module
for Perl, used by thousands of CPAN distributions. Test::More is
delivered as core module since 5.8.0 or 5.6.2, so is widely deployed. It
is actively maintained and is integrated in a test framework that allows
the use and development of further "plug-in" test modules. With that
it's conceivable to write a test module specifically for git and its
usage scenarios.

Regards,
  Sebastian

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-06-02  7:58                                 ` Junio C Hamano
@ 2008-06-02  8:10                                   ` Jakub Narebski
  2008-06-02 11:56                                   ` Sebastian Bober
                                                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 575+ messages in thread
From: Jakub Narebski @ 2008-06-02  8:10 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <gitster@pobox.com> writes:

> I've looked at the Git.pm testsuite that uses Test::More briefly but
> hadn't really reviewed it.  Is Test::More commonly used, considered solid
> and widely available?

It is part of perl-5.8.6-24 RPM package in Fedora Core 4.
It is mentioned in http://www.perlfoundation.org/perl5/index.cgi?testing
 
> ----------------------------------------------------------------
> [Graduated to "master"]
> 
> * lr/init-bare (Wed May 28 19:53:57 2008 +0100) 1 commit
>  + git-init: accept --bare option
> 
> This makes both "git --bare init" and "git init --bare" work, which would
> reduce confusion.

Nice.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-05-30 20:44                               ` Junio C Hamano
  2008-05-30 21:10                                 ` Jon Loeliger
  2008-05-30 22:00                                 ` Steven Grimm
@ 2008-06-02  7:58                                 ` Junio C Hamano
  2008-06-02  8:10                                   ` Jakub Narebski
                                                     ` (3 more replies)
  2 siblings, 4 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-06-02  7:58 UTC (permalink / raw)
  To: git

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.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * Fixes of 'master' continues, with newer -rcX tagged every once in a
   while.  I'd like to tag -rc1 in a few days.

 * 1.5.6 Final (2008-06-08 -- likely to slip by a week or so, though).

----------------------------------------------------------------
[New Topics]

* lw/gitweb (Sat May 31 16:19:24 2008 +0200) 2 commits
 - gitweb: use Git.pm, and use its parse_rev method for
   git_get_head_hash
 - perl/Git.pm: add parse_rev method

I do not necessarily think it is an improvement to name the operation
called as "rev-parse" at the plumbing layer with a different name
"get_hash" as the later round of this series does.

As I mentioned on the list, I think the "PERL5LIB fix" I squashed in was a
misguided workaround to a wrong problem; if we are making gitweb.perl to
use Git.pm, I think we should do the same GITPERLLIB trick we do to other
perl scripts for consistency.

I've looked at the Git.pm testsuite that uses Test::More briefly but
hadn't really reviewed it.  Is Test::More commonly used, considered solid
and widely available?

----------------------------------------------------------------
[Graduated to "master"]

* lw/test-fix (Sat May 31 23:11:21 2008 +0200) 1 commit
 + t/test-lib.sh: resolve symlinks in working directory, for pathname
   comparisons

* sb/am-tests (Sun Jun 1 00:11:43 2008 +0200) 2 commits
 + Merge t4150-am-subdir.sh and t4151-am.sh into t4150-am.sh
 + Add test cases for git-am

* lt/pack-sync (Fri May 30 08:54:46 2008 -0700) 2 commits
 + Remove now unnecessary 'sync()' calls
 + Make pack creation always fsync() the result

* sp/remote (Sun Jun 1 00:28:04 2008 -0400) 3 commits
 + Make "git-remote rm" delete refs acccording to fetch specs
 + Make "git-remote prune" delete refs according to fetch specs
 + Remove unused remote_prefix member in builtin-remote

"git-remote" had an unwarranted assumption that everybody uses
refs/remotes/$it namespace to track remote repository called $it.  This
series is a reasonable fix to it.

* np/pack-check (Thu May 29 17:34:50 2008 -0400) 1 commit
 + make verify-pack a bit more useful with bad packs

* lr/init-bare (Wed May 28 19:53:57 2008 +0100) 1 commit
 + git-init: accept --bare option

This makes both "git --bare init" and "git init --bare" work, which would
reduce confusion.

* jc/checkout (Wed May 28 16:11:16 2008 -0700) 4 commits
 + checkout: "best effort" checkout
 + unpack_trees(): allow callers to differentiate worktree errors
   from merge errors
 + checkout: consolidate reset_{to_new,clean_to_new|()
 + checkout: make reset_clean_to_new() not die by itself

This "fix" seems to help real-world users.

* jb/reset-q (Sat May 31 18:10:58 2008 -0700) 1 commit
 + git-reset: honor -q and do not show progress message

----------------------------------------------------------------
[Stalled]

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 + "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the tip commit on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 - Introduce fast forward option only
 - Head reduction before selecting merge strategy
 - Restructure git-merge.sh
 - Introduce -ff=<fast forward option>
 - New merge tests
 - Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C but it appears
neither will happen by 1.5.6 anyway.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 - Eliminate an unnecessary chdir("..")
 - Add support for GIT_CEILING_DIRECTORIES
 - Fold test-absolute-path into test-path-utils
 - Implement normalize_absolute_path

----------------------------------------------------------------
[On Hold]

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-05-30 21:10                                 ` Jon Loeliger
@ 2008-05-31  1:25                                   ` Stephan Beyer
  0 siblings, 0 replies; 575+ messages in thread
From: Stephan Beyer @ 2008-05-31  1:25 UTC (permalink / raw)
  To: git; +Cc: Jon Loeliger

Hi,

> One suggestion was to make a procedural model out of
> the commit graph and allow something like this:
>
>    b :- pick(B)
>    x :- merge(pick(A), b)
>    y :- merge(pick(C), b)
>    z :- merge(x, y)

Nice idea.  But imho too hard for casual users.
Someone who has to learn a new language won't use the tool.

> My second and semi-equivallent suggestion was to
> allow a lisp-like notation:
>
>    (merge (merge (pick A)
>                  (pick B)
>           (merge (pick B)
>                  (pick C)

You forgot some right parenthesis here ;-)
...which shows, that it is also not easy enough for users.

Or is it intentional?

:)
Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-05-30 20:44                               ` Junio C Hamano
  2008-05-30 21:10                                 ` Jon Loeliger
@ 2008-05-30 22:00                                 ` Steven Grimm
  2008-06-02  7:58                                 ` Junio C Hamano
  2 siblings, 0 replies; 575+ messages in thread
From: Steven Grimm @ 2008-05-30 22:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On May 30, 2008, at 1:44 PM, Junio C Hamano wrote:
> [Stalled]
>
> * dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
> - Eliminate an unnecessary chdir("..")
> - Add support for GIT_CEILING_DIRECTORIES
> - Fold test-absolute-path into test-path-utils
> - Implement normalize_absolute_path


The most recent version of this patch seemed to come and go without  
any commentary one way or the other. What are people's objections to  
it as it stands now?

-Steve

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-05-30 20:44                               ` Junio C Hamano
@ 2008-05-30 21:10                                 ` Jon Loeliger
  2008-05-31  1:25                                   ` Stephan Beyer
  2008-05-30 22:00                                 ` Steven Grimm
  2008-06-02  7:58                                 ` Junio C Hamano
  2 siblings, 1 reply; 575+ messages in thread
From: Jon Loeliger @ 2008-05-30 21:10 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano wrote:
> Here are the topics that have been cooking.  Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'.
> 
>
> * js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
>  + Use perl instead of tac
>  + Fix t3404 assumption that `wc -l` does not use whitespace.
>  + rebase -i: Use : in expr command instead of match.
>  + rebase -i: update the implementation of 'mark' command
>  + Add option --preserve-tags
>  + Teach rebase interactive the tag command
>  + Add option --first-parent
>  + Do rebase with preserve merges with advanced TODO list
>  + Select all lines with fake-editor
>  + Unify the length of $SHORT* and the commits in the TODO list
>  + Teach rebase interactive the merge command
>  + Move redo merge code in a function
>  + Teach rebase interactive the reset command
>  + Teach rebase interactive the mark command
>  + Move cleanup code into it's own function
>  + Don't append default merge message to -m message
>  + fake-editor: output TODO list if unchanged
> 
> This may complement the proposed "sequencer" GSoC project.  Dscho seems to
> have quite a strong objection to the 'mark' syntax and mechanism being
> unnecessarily complex.  Let's wait and see if a less complex but equally
> expressive alternative materializes...


Well, there are the two not-quite facetious suggestions
I made off list to Junio.  Granted, he though they would
be overkill (too), but I guess I could make them here for
the general record in any case.

One suggestion was to make a procedural model out of
the commit graph and allow something like this:

    b :- pick(B)
    x :- merge(pick(A), b)
    y :- merge(pick(C), b)
    z :- merge(x, y)

My second and semi-equivallent suggestion was to
allow a lisp-like notation:

    (merge (merge (pick A)
                  (pick B)
           (merge (pick B)
                  (pick C)

As Junio observed, even that could be beyond what most
casual git rebase -i users are willing to do to a sequencer
edit stream before getting down to business.

Ah well. :-)

jdl

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-05-26  1:22                             ` Junio C Hamano
@ 2008-05-30 20:44                               ` Junio C Hamano
  2008-05-30 21:10                                 ` Jon Loeliger
                                                   ` (2 more replies)
  0 siblings, 3 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-05-30 20:44 UTC (permalink / raw)
  To: git

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.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * Fixes of 'master' continues, with newer -rcX tagged every once in a
   while.

 * 1.5.6 Final (2008-06-08 -- likely to slip by a week or so, though).

There are a few known breakages I want to see addressed that are not in
here before 1.5.6 (no not any new features but pure bugfixes).

----------------------------------------------------------------
[New Topics]

* jc/checkout (Wed May 28 16:11:16 2008 -0700) 5 commits
 - PARK: NUL hack to entry
 - checkout: "best effort" checkout
 - unpack_trees(): allow callers to differentiate worktree errors
   from merge errors
 - checkout: consolidate reset_{to_new,clean_to_new|()
 - checkout: make reset_clean_to_new() not die by itself

* lr/init-bare (Wed May 28 19:53:57 2008 +0100) 1 commit
 - git-init: accept --bare option

This makes both "git --bare init" and "git init --bare" work, which would
reduce confusion.  I am tempted to include it in 1.5.6.  Comments?

----------------------------------------------------------------
[Graduated to "master"]

* jc/diff-no-no-index (Mon May 26 22:35:07 2008 -0700) 5 commits
 + git diff --no-index: default to page like other diff frontends
 + git-diff: allow  --no-index semantics a bit more
 + "git diff": do not ignore index without --no-index
 + diff-files: do not play --no-index games
 + tests: do not use implicit "git diff --no-index"

This was done in response to recently discovered interaction with stgit;
we were too eater to invoke --no-index behaviour without being asked.

----------------------------------------------------------------
[Stalled]

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 + "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the tip commit on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 - Introduce fast forward option only
 - Head reduction before selecting merge strategy
 - Restructure git-merge.sh
 - Introduce -ff=<fast forward option>
 - New merge tests
 - Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C but it appears
neither will happen by 1.5.6 anyway.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 - Eliminate an unnecessary chdir("..")
 - Add support for GIT_CEILING_DIRECTORIES
 - Fold test-absolute-path into test-path-utils
 - Implement normalize_absolute_path

----------------------------------------------------------------
[On Hold]

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-05-22  1:18                           ` Junio C Hamano
  2008-05-22 11:35                             ` Johannes Schindelin
@ 2008-05-26  1:22                             ` Junio C Hamano
  2008-05-30 20:44                               ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-05-26  1:22 UTC (permalink / raw)
  To: git

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.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * 1.5.6-rc0 has been tagged.  Expect a few minor breakages ;-)

 * Fixes of 'master' continues, with newer -rcX tagged every once in a
   while.

 * 1.5.6 Final (2008-06-08).

There are a few known breakages I want to see addressed that are not in
here before 1.5.6 (no not any new features but pure bugfixes).

----------------------------------------------------------------
[New Topics]

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 - Introduce fast forward option only
 - Head reduction before selecting merge strategy
 - Restructure git-merge.sh
 - Introduce -ff=<fast forward option>
 - New merge tests
 - Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C but it appears
neither will happen by 1.5.6 anyway.

* jc/diff-no-no-index (Fri May 23 22:28:56 2008 -0700) 3 commits
 + "git diff": do not ignore index without --no-index
 + diff-files: do not play --no-index games
 + tests: do not use implicit "git diff --no-index"

This was done in response to recently discovered interaction with stgit;
we were too eater to invoke --no-index behaviour without being asked.
Currently it even drops the behaviour when you ask to compare two paths
that are outside of git work tree if your current directory is inside it,
which I think could safely resurrect, and then the whole thing will be
ready for 1.5.6.

----------------------------------------------------------------
[Graduated to "master"]

* js/config-cb (Wed May 14 18:46:53 2008 +0100) 1 commit
 + Provide git_config with a callback-data parameter

* jc/apply-whitespace (Sat May 17 02:02:44 2008 -0700) 3 commits
 + builtin-apply: do not declare patch is creation when we do not
   know it
 + builtin-apply: accept patch to an empty file
 + builtin-apply: typofix

We were loose when parsing a patch that adds contents to an empty file.
This fix would be nice to have in 1.5.6.

* js/mailinfo (Fri May 16 14:03:30 2008 +0100) 3 commits
 + mailsplit: minor clean-up in read_line_with_nul()
 + mailinfo: apply the same fix not to lose NULs in BASE64 and QP
   codepaths
 + mailsplit and mailinfo: gracefully handle NUL characters

When "am" processes a patch that modifies a line with NUL, we used to
chomp the patch line there, resulting in rejects.  This patch fixes the
issue partially, only when the message is not encoded in BASE64 nor
Quoted-Printable.  I suspect its handling of a MIME attachment may still
wrong, but otherwise this should fix the breakage reported earlier.

* mo/cvsserver (Wed May 14 22:35:48 2008 -0600) 3 commits
 + git-cvsserver: add ability to guess -kb from contents
 + implement gitcvs.usecrlfattr
 + git-cvsserver: add mechanism for managing working tree and current
   directory

* js/cvsexportcommit (Wed May 14 15:29:49 2008 +0100) 2 commits
 + cvsexportcommit: introduce -W for shared working trees (between
   Git and CVS)
 + cvsexportcommit: chomp only removes trailing whitespace

CVS interoperability improvements.

* ar/t6031 (Sun May 18 16:57:27 2008 +0200) 1 commit
 + Fix t6031 on filesystems without working exec bit

* jc/unpack-trees-reword (Sat May 17 12:03:49 2008 -0700) 1 commit
 + unpack-trees: allow Porcelain to give different error messages

Makes safety message from "git checkout switch-to-this-branch" a bit
easier to read, and opens up the possibility to reword messages from other
commands that use unpack-trees machinery.

* jc/add-n-u (Wed May 21 12:04:34 2008 -0700) 1 commit
 + "git-add -n -u" should not add but just report

* js/ignore-submodule (Wed May 14 18:03:59 2008 +0100) 3 commits
 + Ignore dirty submodule states during rebase and stash
 + Teach update-index about --ignore-submodules
 + diff options: Introduce --ignore-submodules

* sp/ignorecase (Thu May 15 07:19:54 2008 +0200) 5 commits
 + t0050: Fix merge test on case sensitive file systems
 + t0050: Add test for case insensitive add
 + t0050: Set core.ignorecase case to activate case insensitivity
 + t0050: Test autodetect core.ignorecase
 + git-init: autodetect core.ignorecase

* bc/repack (Thu May 15 22:37:31 2008 -0400) 6 commits
 + Documentation/git-repack.txt: document new -A behaviour
 + let pack-objects do the writing of unreachable objects as loose
   objects
 + add a force_object_loose() function
 + builtin-gc.c: deprecate --prune, it now really has no effect
 + git-gc: always use -A when manually repacking
 + repack: modify behavior of -A option to leave unreferenced objects
   unpacked

* db/clone-in-c (Tue May 20 14:15:14 2008 -0400) 11 commits
 + clone: fall back to copying if hardlinking fails
 + builtin-clone.c: Need to closedir() in copy_or_link_directory()
 + builtin-clone: fix initial checkout
 + Build in clone
 + Provide API access to init_db()
 + Add a function to set a non-default work tree
 + Allow for having for_each_ref() list extra refs
 + Have a constant extern refspec for "--tags"
 + Add a library function to add an alternate to the alternates file
 + Add a lockfile function to append to a file
 + Mark the list of refs to fetch as const

* pb/push (Mon Apr 28 11:32:12 2008 -0400) 1 commit
 + add special "matching refs" refspec

This first patch is a good enhancement without hurting any existing users.
We need a staged introduction of the second and later patches, and many
people including me did not agree the later ones in the series are
desirable.

* ap/svn (Mon May 12 17:09:49 2008 -0700) 4 commits
 + git-svn: add test for --add-author-from and --use-log-author
 + git-svn: add documentation for --add-author-from option.
 + git-svn: Add --add-author-from option.
 + git-svn: add documentation for --use-log-author option.

Some tweak for output might be needed, but I'll leave that to actual
git-svn users.

* ar/batch-cat (Wed Apr 23 15:17:47 2008 -0400) 13 commits
 + change quoting in test t1006-cat-file.sh
 + builtin-cat-file.c: use parse_options()
 + git-svn: Speed up fetch
 + Git.pm: Add hash_and_insert_object and cat_blob
 + Git.pm: Add command_bidi_pipe and command_close_bidi_pipe
 + git-hash-object: Add --stdin-paths option
 + Add more tests for git hash-object
 + Move git-hash-object tests from t5303 to t1007
 + git-cat-file: Add --batch option
 + git-cat-file: Add --batch-check option
 + git-cat-file: Make option parsing a little more flexible
 + git-cat-file: Small refactor of cmd_cat_file
 + Add tests for git cat-file

The series is meant to speed up git-svn by avoiding many individual
invocations of git-cat-file, started by Adam Roben and finished by Michele
Ballabio.

----------------------------------------------------------------
[Stalled]

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 + "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the tip commit on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

----------------------------------------------------------------
[On Hold]

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 - Eliminate an unnecessary chdir("..")
 - Add support for GIT_CEILING_DIRECTORIES
 - Fold test-absolute-path into test-path-utils
 - Implement normalize_absolute_path

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

* jc/diff-words (Sun May 11 12:33:48 2008 -0700) 2 commits
 - diff --color-words: a bit of tweak
 - diff --color-words reimplementation

This series did not pan out well.  I briefly thought that perhaps I should
discard them and replace with the "not just whitespace" one from Ping Yin
first, hoping that we can clean the overall logic up later, but perhaps
the whole thing can get a fresh restart after 1.5.6.  I'll drop this
altogether the next round.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-05-22 11:35                             ` Johannes Schindelin
  2008-05-22 18:17                               ` Junio C Hamano
@ 2008-05-25 21:29                               ` Stephan Beyer
  1 sibling, 0 replies; 575+ messages in thread
From: Stephan Beyer @ 2008-05-25 21:29 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

Hi,

> > * js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
esp.
> >  + Teach rebase interactive the merge command
> >  + Teach rebase interactive the reset command
> >  + Teach rebase interactive the mark command
[...]
>
> Yeah, I know.  My backlog is growing and growing.

I think, this week we get the git-sequencer "spec" ready to be sent
to the list.
Then there's a new thread to discuss ;-)

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-05-22 18:17                               ` Junio C Hamano
@ 2008-05-22 22:02                                 ` Daniel Barkalow
  0 siblings, 0 replies; 575+ messages in thread
From: Daniel Barkalow @ 2008-05-22 22:02 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Schindelin, git

On Thu, 22 May 2008, Junio C Hamano wrote:

> >> * db/clone-in-c (Tue May 20 14:15:14 2008 -0400) 11 commits
> >>  + clone: fall back to copying if hardlinking fails
> >>  + builtin-clone.c: Need to closedir() in copy_or_link_directory()
> >>  + builtin-clone: fix initial checkout
> >>  + Build in clone
> >>  + Provide API access to init_db()
> >>  + Add a function to set a non-default work tree
> >>  + Allow for having for_each_ref() list extra refs
> >>  + Have a constant extern refspec for "--tags"
> >>  + Add a library function to add an alternate to the alternates file
> >>  + Add a lockfile function to append to a file
> >>  + Mark the list of refs to fetch as const
> >
> > Fingers crossed.
> 
> Rather, uncross them and type a few more tests ;-)?

There are a few tests from Johan that didn't get in, which I'd had in my 
tree but didn't send because I don't have a good process in place for 
sending patches I'm not the author of. I'm pretty sure they pass, but I 
haven't checked recently. I'll send them in a moment.

	-Daniel
*This .sig left intentionally blank*

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-05-22 11:35                             ` Johannes Schindelin
@ 2008-05-22 18:17                               ` Junio C Hamano
  2008-05-22 22:02                                 ` Daniel Barkalow
  2008-05-25 21:29                               ` Stephan Beyer
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-05-22 18:17 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

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

>> * js/config-cb (Wed May 14 18:46:53 2008 +0100) 1 commit
>>  - Provide git_config with a callback-data parameter
>> 
>> This needs to wait until most of the other things graduate for 1.5.6; 
>> luckily, unlike the other "path-list" changes, misconversions is much 
>> easier to catch for this change and I am not worried about it.
>
> Just let me know when to resubmit, and against what branch(es).

It is probably easier for me to munge the original submission from you
when I decide to tag -rc0, adjusting any potential new callers (I do not
think of any offhand in diff between master and next).  We will need a
quiescent time for this kind of change, and that way we will get such a
quiescent window by definition.

>> * js/mailinfo (Fri May 16 14:03:30 2008 +0100) 1 commit
>>  - <<PARK - BASE64 and QP still broken>> mailsplit and mailinfo:
>>    gracefully handle NUL characters
>> 
>> When "am" processes a patch that modifies a line with NUL, we used to
>> chomp the patch line there, resulting in rejects.  This patch fixes the
>> issue partially, only when the message is not encoded in BASE64 nor
>> Quoted-Printable.

> Like I said, I would be happy if Tommy took care of that patch.

I dunno.  Is it likely to happen?  I'd take a look at it myself when I
have a chance.

>> * js/ignore-submodule (Wed May 14 18:03:59 2008 +0100) 3 commits
>>  + Ignore dirty submodule states during rebase and stash
>>  + Teach update-index about --ignore-submodules
>>  + diff options: Introduce --ignore-submodules
>
> I haven't heard back from you about renaming that option.  I think I 
> suggested --non-gitlinks or something equally discouraging for 
> porcelain users.

The name is fine.  I had more trouble with what it does, rather, what it
doesn't --- it does not ignore typechange that involve a gitlink if I
recall correctly.

>> * db/clone-in-c (Tue May 20 14:15:14 2008 -0400) 11 commits
>>  + clone: fall back to copying if hardlinking fails
>>  + builtin-clone.c: Need to closedir() in copy_or_link_directory()
>>  + builtin-clone: fix initial checkout
>>  + Build in clone
>>  + Provide API access to init_db()
>>  + Add a function to set a non-default work tree
>>  + Allow for having for_each_ref() list extra refs
>>  + Have a constant extern refspec for "--tags"
>>  + Add a library function to add an alternate to the alternates file
>>  + Add a lockfile function to append to a file
>>  + Mark the list of refs to fetch as const
>
> Fingers crossed.

Rather, uncross them and type a few more tests ;-)?

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-05-22  1:18                           ` Junio C Hamano
@ 2008-05-22 11:35                             ` Johannes Schindelin
  2008-05-22 18:17                               ` Junio C Hamano
  2008-05-25 21:29                               ` Stephan Beyer
  2008-05-26  1:22                             ` Junio C Hamano
  1 sibling, 2 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-05-22 11:35 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Wed, 21 May 2008, Junio C Hamano wrote:

> * js/config-cb (Wed May 14 18:46:53 2008 +0100) 1 commit
>  - Provide git_config with a callback-data parameter
> 
> This needs to wait until most of the other things graduate for 1.5.6; 
> luckily, unlike the other "path-list" changes, misconversions is much 
> easier to catch for this change and I am not worried about it.

Just let me know when to resubmit, and against what branch(es).

> * js/mailinfo (Fri May 16 14:03:30 2008 +0100) 1 commit
>  - <<PARK - BASE64 and QP still broken>> mailsplit and mailinfo:
>    gracefully handle NUL characters
> 
> When "am" processes a patch that modifies a line with NUL, we used to
> chomp the patch line there, resulting in rejects.  This patch fixes the
> issue partially, only when the message is not encoded in BASE64 nor
> Quoted-Printable.

Like I said, I would be happy if Tommy took care of that patch.

> * js/ignore-submodule (Wed May 14 18:03:59 2008 +0100) 3 commits
>  + Ignore dirty submodule states during rebase and stash
>  + Teach update-index about --ignore-submodules
>  + diff options: Introduce --ignore-submodules

I haven't heard back from you about renaming that option.  I think I 
suggested --non-gitlinks or something equally discouraging for 
porcelain users.

> * as/graph (Mon May 5 00:57:03 2008 -0700) 4 commits
>  + graph API: eliminate unnecessary indentation
>  + log and rev-list: add --graph option
>  + Add history graph API
>  + revision API: split parent rewriting and parent printing options
> 
> Draw "tig 'g'" graph without tig ;-)

I am a big fan of this feature.

> * db/clone-in-c (Tue May 20 14:15:14 2008 -0400) 11 commits
>  + clone: fall back to copying if hardlinking fails
>  + builtin-clone.c: Need to closedir() in copy_or_link_directory()
>  + builtin-clone: fix initial checkout
>  + Build in clone
>  + Provide API access to init_db()
>  + Add a function to set a non-default work tree
>  + Allow for having for_each_ref() list extra refs
>  + Have a constant extern refspec for "--tags"
>  + Add a library function to add an alternate to the alternates file
>  + Add a lockfile function to append to a file
>  + Mark the list of refs to fetch as const

Fingers crossed.

> * js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
>  + Use perl instead of tac
>  + Fix t3404 assumption that `wc -l` does not use whitespace.
>  + rebase -i: Use : in expr command instead of match.
>  + rebase -i: update the implementation of 'mark' command
>  + Add option --preserve-tags
>  + Teach rebase interactive the tag command
>  + Add option --first-parent
>  + Do rebase with preserve merges with advanced TODO list
>  + Select all lines with fake-editor
>  + Unify the length of $SHORT* and the commits in the TODO list
>  + Teach rebase interactive the merge command
>  + Move redo merge code in a function
>  + Teach rebase interactive the reset command
>  + Teach rebase interactive the mark command
>  + Move cleanup code into it's own function
>  + Don't append default merge message to -m message
>  + fake-editor: output TODO list if unchanged
> 
> This may complement the proposed "sequencer" GSoC project.  Dscho seems 
> to have quite a strong objection to the 'mark' syntax and mechanism 
> being unnecessarily complex.  Let's wait and see if a less complex but 
> equally expressive alternative materializes...

Yeah, I know.  My backlog is growing and growing.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-05-14 22:30                         ` Junio C Hamano
  2008-05-14 22:55                           ` Daniel Barkalow
  2008-05-15  5:51                           ` Steffen Prohaska
@ 2008-05-22  1:18                           ` Junio C Hamano
  2008-05-22 11:35                             ` Johannes Schindelin
  2008-05-26  1:22                             ` Junio C Hamano
  2 siblings, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-05-22  1:18 UTC (permalink / raw)
  To: git

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.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21 -- need
   to slip til the weekend).

 * 1.5.6 Final (2008-06-08).

There are a few known breakages I want to see addressed that are not in
here before 1.5.6 (no not any new features but pure bugfixes).

----------------------------------------------------------------
[New Topics]

* js/config-cb (Wed May 14 18:46:53 2008 +0100) 1 commit
 - Provide git_config with a callback-data parameter

This needs to wait until most of the other things graduate for 1.5.6;
luckily, unlike the other "path-list" changes, misconversions is much
easier to catch for this change and I am not worried about it.

* jc/apply-whitespace (Sat May 17 02:02:44 2008 -0700) 3 commits
 + builtin-apply: do not declare patch is creation when we do not
   know it
 + builtin-apply: accept patch to an empty file
 + builtin-apply: typofix

We were loose when parsing a patch that adds contents to an empty file.
This fix would be nice to have in 1.5.6.

* js/mailinfo (Fri May 16 14:03:30 2008 +0100) 1 commit
 - <<PARK - BASE64 and QP still broken>> mailsplit and mailinfo:
   gracefully handle NUL characters

When "am" processes a patch that modifies a line with NUL, we used to
chomp the patch line there, resulting in rejects.  This patch fixes the
issue partially, only when the message is not encoded in BASE64 nor
Quoted-Printable.

* mo/cvsserver (Wed May 14 22:35:48 2008 -0600) 3 commits
 + git-cvsserver: add ability to guess -kb from contents
 + implement gitcvs.usecrlfattr
 + git-cvsserver: add mechanism for managing working tree and current
   directory

CVS interoperability improvements, for 1.5.6

* js/cvsexportcommit (Wed May 14 15:29:49 2008 +0100) 2 commits
 + cvsexportcommit: introduce -W for shared working trees (between
   Git and CVS)
 + cvsexportcommit: chomp only removes trailing whitespace

CVS interoperability improvements, for 1.5.6

* ar/t6031 (Sun May 18 16:57:27 2008 +0200) 1 commit
 + Fix t6031 on filesystems without working exec bit

* jc/unpack-trees-reword (Sat May 17 12:03:49 2008 -0700) 1 commit
 + unpack-trees: allow Porcelain to give different error messages

* jc/add-n-u (Wed May 21 12:04:34 2008 -0700) 1 commit
 + "git-add -n -u" should not add but just report

* js/ignore-submodule (Wed May 14 18:03:59 2008 +0100) 3 commits
 + Ignore dirty submodule states during rebase and stash
 + Teach update-index about --ignore-submodules
 + diff options: Introduce --ignore-submodules

The above are all fixes, meant for 1.5.6.

* dr/ceiling (Fri May 16 00:27:28 2008 +0100) 1 commit
 - Add support for GIT_CEILING_DIRECTORIES

I haven't had a chance to take a look at the updated series myself.

* jc/diff-words (Sun May 11 12:33:48 2008 -0700) 2 commits
 - diff --color-words: a bit of tweak
 - diff --color-words reimplementation

This series did not pan out well.  I briefly thought that perhaps I should
discard them and replace with the "not just whitespace" one from Ping Yin
first, hoping that we can clean the overall logic up later, but perhaps
the whole thing can get a fresh restart after 1.5.6.

----------------------------------------------------------------
[Graduated to "master"]

* ar/add-unreadable (Mon May 12 19:59:23 2008 +0200) 5 commits
 + Add a config option to ignore errors for git-add
 + Add a test for git-add --ignore-errors
 + Add --ignore-errors to git-add to allow it to skip files with read
   errors
 + Extend interface of add_files_to_cache to allow ignore indexing
   errors
 + Make the exit code of add_file_to_index actually useful

When you sometimes have unreadable path in your own work tree, this allows
you to ignore failures to index such path with "git add".  Philosophically
that whole notion is wrong ("why should you be adding such a file to begin
with"), but this has practical value of working around insane systems that
locks out the access by the user to a file when the file is in use by
somebody else.

I am somewhat skeptical about the last one that enables such a workaround
on a permanent basis, though.

* ds/branch-auto-rebase (Sat May 10 15:36:29 2008 -0700) 1 commit
 + Allow tracking branches to set up rebase by default.

For 1.5.6.

* as/graph (Mon May 5 00:57:03 2008 -0700) 4 commits
 + graph API: eliminate unnecessary indentation
 + log and rev-list: add --graph option
 + Add history graph API
 + revision API: split parent rewriting and parent printing options

Draw "tig 'g'" graph without tig ;-)

* np/pack (Fri May 2 15:11:51 2008 -0400) 7 commits
 + pack-objects: fix early eviction for max depth delta objects
 + pack-objects: allow for early delta deflating
 + pack-objects: move compression code in a separate function
 + pack-objects: clean up write_object() a bit
 + pack-objects: simplify the condition associated with --all-
   progress
 + pack-objects: remove some double negative logic
 + pack-objects: small cleanup

Every time Nico tweaks pack generation, something good comes out ;-).

* sv/first-parent (Mon May 12 17:12:36 2008 +0200) 2 commits
 + revision.c: really honor --first-parent
 + Simplify and fix --first-parent implementation


----------------------------------------------------------------
[Will merge to "master" soonish]

* sp/ignorecase (Thu May 15 07:19:54 2008 +0200) 5 commits
 + t0050: Fix merge test on case sensitive file systems
 + t0050: Add test for case insensitive add
 + t0050: Set core.ignorecase case to activate case insensitivity
 + t0050: Test autodetect core.ignorecase
 + git-init: autodetect core.ignorecase

For 1.5.6.

* bc/repack (Thu May 15 22:37:31 2008 -0400) 6 commits
 + Documentation/git-repack.txt: document new -A behaviour
 + let pack-objects do the writing of unreachable objects as loose
   objects
 + add a force_object_loose() function
 + builtin-gc.c: deprecate --prune, it now really has no effect
 + git-gc: always use -A when manually repacking
 + repack: modify behavior of -A option to leave unreferenced objects
   unpacked

For 1.5.6.

* db/clone-in-c (Tue May 20 14:15:14 2008 -0400) 11 commits
 + clone: fall back to copying if hardlinking fails
 + builtin-clone.c: Need to closedir() in copy_or_link_directory()
 + builtin-clone: fix initial checkout
 + Build in clone
 + Provide API access to init_db()
 + Add a function to set a non-default work tree
 + Allow for having for_each_ref() list extra refs
 + Have a constant extern refspec for "--tags"
 + Add a library function to add an alternate to the alternates file
 + Add a lockfile function to append to a file
 + Mark the list of refs to fetch as const

For 1.5.6.

* pb/push (Mon Apr 28 11:32:12 2008 -0400) 1 commit
 + add special "matching refs" refspec

This first patch is a good enhancement without hurting any existing users.
We need a staged introduction of the second and later patches, and many
people including me did not agree the later ones in the series are
desirable.

----------------------------------------------------------------
[Stalled]

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 + "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* ap/svn (Mon May 12 17:09:49 2008 -0700) 4 commits
 + git-svn: add test for --add-author-from and --use-log-author
 + git-svn: add documentation for --add-author-from option.
 + git-svn: Add --add-author-from option.
 + git-svn: add documentation for --use-log-author option.

Some tweak for output might be needed, I dunno.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the tip commit on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

* ar/batch-cat (Wed Apr 23 15:17:47 2008 -0400) 5 commits
 - git-cat-file: Add --batch option
 - git-cat-file: Add --batch-check option
 - git-cat-file: Make option parsing a little more flexible
 - git-cat-file: Small refactor of cmd_cat_file
 - Add tests for git cat-file

The series was meant to speed up git-svn by avoiding many individual
invocations of git-cat-file.

I fixed up the problematic shell script in the first patch in the series
but later one introduced the same problematic constructs in another file,
at which point I gave up and discarded the rest.  At least it now passes
its own testsuite without breaking others.  The remainder needs to be
resubmit for the entire series to be usable for git-svn.

----------------------------------------------------------------
[On Hold]

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

----------------------------------------------------------------
[Dropped]

* bc/tag (Fri May 9 00:03:35 2008 -0500) 3 commits
 - ident.c: New function valid_ident for checking ident string
   formatting
 - Make mktag a builtin
 - mktag.c: adjust verify_tag parameters

The goal of the series was to unify the internal implementation of
git-mktag and git-tag but the patches did not quite apply.  Needs
rebase/resubmit.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-05-14 22:30                         ` Junio C Hamano
  2008-05-14 22:55                           ` Daniel Barkalow
@ 2008-05-15  5:51                           ` Steffen Prohaska
  2008-05-22  1:18                           ` Junio C Hamano
  2 siblings, 0 replies; 575+ messages in thread
From: Steffen Prohaska @ 2008-05-15  5:51 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wed, 14 May 2008, Junio C Hamano wrote:

> 
> For 1.5.6.
> 
> * sp/ignorecase (Sun May 11 18:16:42 2008 +0200) 4 commits
>  - t0050: Add test for case insensitive add
>  - t0050: Set core.ignorecase case to activate case insensitivity
>  - t0050: Test autodetect core.ignorecase
>  - git-init: autodetect core.ignorecase
> 
> This unfortunately seems to break on natively case sensitive filesystems.


>From 92ec8c8a12cdc45a69f6612af340a8ce50976ab1 Mon Sep 17 00:00:00 2001
From: Steffen Prohaska <prohaska@zib.de>
Date: Thu, 15 May 2008 07:19:54 +0200
Subject: [PATCH] t0050: Fix merge test on case sensitive file systems

On a case sensitive filesystem, "git reset --hard" might refuse to
overwrite a file whose name differs only by case, even if
core.ignorecase is set.  It is not clear which circumstances cause this
behavior.  This commit simply works around the problem by removing
the case changing file before running "git reset --hard".

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 t/t0050-filesystem.sh |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index 0e33c4b..c5360e2 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -72,6 +72,8 @@ $test_case 'rename (case change)' '
 
 $test_case 'merge (case change)' '
 
+	rm -f CamelCase &&
+	rm -f camelcase &&
 	git reset --hard initial &&
 	git merge topic
 
-- 
1.5.5.1.349.g99d0

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-05-14 22:55                           ` Daniel Barkalow
@ 2008-05-15  4:30                             ` Junio C Hamano
  0 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-05-15  4:30 UTC (permalink / raw)
  To: Daniel Barkalow; +Cc: git

Daniel Barkalow <barkalow@iabervon.org> writes:

> Last time, you said you were going to review this again; did you review it 
> and find nothing to comment on, decide to just make sure it gets a 
> beating, or are you still planning to review it more? (Just wondering so I 
> can try to arrange to have time to respond to comments if there's going to 
> be a bunch)

I did not have any further nitpicks on either design nor code in particular.

But keep in mind that I won't be the single source of review comments ;-).
.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-05-14 22:30                         ` Junio C Hamano
@ 2008-05-14 22:55                           ` Daniel Barkalow
  2008-05-15  4:30                             ` Junio C Hamano
  2008-05-15  5:51                           ` Steffen Prohaska
  2008-05-22  1:18                           ` Junio C Hamano
  2 siblings, 1 reply; 575+ messages in thread
From: Daniel Barkalow @ 2008-05-14 22:55 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wed, 14 May 2008, Junio C Hamano wrote:

> * db/clone-in-c (Sun Apr 27 13:39:30 2008 -0400) 8 commits
>  + Build in clone
>  + Provide API access to init_db()
>  + Add a function to set a non-default work tree
>  + Allow for having for_each_ref() list extra refs
>  + Have a constant extern refspec for "--tags"
>  + Add a library function to add an alternate to the alternates file
>  + Add a lockfile function to append to a file
>  + Mark the list of refs to fetch as const
> 
> For 1.5.6; please give it a good beating.

Last time, you said you were going to review this again; did you review it 
and find nothing to comment on, decide to just make sure it gets a 
beating, or are you still planning to review it more? (Just wondering so I 
can try to arrange to have time to respond to comments if there's going to 
be a bunch)

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-05-06  6:38                       ` Junio C Hamano
  2008-05-12 22:03                         ` Junio C Hamano
@ 2008-05-14 22:30                         ` Junio C Hamano
  2008-05-14 22:55                           ` Daniel Barkalow
                                             ` (2 more replies)
  1 sibling, 3 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-05-14 22:30 UTC (permalink / raw)
  To: git

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.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * Will merge the remaining topics already on 'next', and perhaps accept a
   handful minor topics that are not yet in.

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

----------------------------------------------------------------
[New Topics]

* bc/tag (Fri May 9 00:03:35 2008 -0500) 3 commits
 - ident.c: New function valid_ident for checking ident string
   formatting
 - Make mktag a builtin
 - mktag.c: adjust verify_tag parameters

I stopped looking at this after hitting an unappliable patch --- will need
to take a look at it again.

* js/config-cb (Wed May 14 18:46:53 2008 +0100) 1 commit
 - Provide git_config with a callback-data parameter

This needs to wait until most of the other things graduate for 1.5.6;
luckily, unlike the other "path-list" changes, misconversions is much
easier to catch for this change and I am not worried about it.

* ds/branch-auto-rebase (Sat May 10 15:36:29 2008 -0700) 1 commit
 + Allow tracking branches to set up rebase by default.

For 1.5.6.

* bc/repack (Wed May 14 01:33:53 2008 -0400) 5 commits
 + let pack-objects do the writing of unreachable objects as loose
   objects
 + add a force_object_loose() function
 + builtin-gc.c: deprecate --prune, it now really has no effect
 + git-gc: always use -A when manually repacking
 + repack: modify behavior of -A option to leave unreferenced objects
   unpacked

For 1.5.6.

* sp/ignorecase (Sun May 11 18:16:42 2008 +0200) 4 commits
 - t0050: Add test for case insensitive add
 - t0050: Set core.ignorecase case to activate case insensitivity
 - t0050: Test autodetect core.ignorecase
 - git-init: autodetect core.ignorecase

This unfortunately seems to break on natively case sensitive filesystems.

* ar/add-unreadable (Mon May 12 19:59:23 2008 +0200) 5 commits
 + Add a config option to ignore errors for git-add
 + Add a test for git-add --ignore-errors
 + Add --ignore-errors to git-add to allow it to skip files with read
   errors
 + Extend interface of add_files_to_cache to allow ignore indexing
   errors
 + Make the exit code of add_file_to_index actually useful

* jc/diff-words (Sun May 11 12:33:48 2008 -0700) 2 commits
 - diff --color-words: a bit of tweak
 - diff --color-words reimplementation


----------------------------------------------------------------
[Graduated to "master"]

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

* db/learn-HEAD (Sat Apr 26 15:53:12 2008 -0400) 2 commits
 + Make ls-remote http://... list HEAD, like for git://...
 + Make walker.fetch_ref() take a struct ref.

* cc/help (Fri Apr 25 08:25:41 2008 +0200) 5 commits
 + documentation: web--browse: add a note about konqueror
 + documentation: help: add info about "man.<tool>.cmd" config var
 + help: use "man.<tool>.cmd" as custom man viewer command
 + documentation: help: add "man.<tool>.path" config variable
 + help: use man viewer path from "man.<tool>.path" config var

* dm/cherry-pick-s (Sat Apr 26 15:14:28 2008 -0500) 1 commit
 + Allow cherry-pick (and revert) to add signoff line

* lt/dirmatch-optim (Sat Apr 19 14:22:38 2008 -0700) 1 commit
 + Optimize match_pathspec() to avoid fnmatch()

* jn/webfeed (Sun Apr 20 22:09:48 2008 +0200) 1 commit
 + gitweb: Use feed link according to current view

* gp/bisect-fix (Mon May 5 07:43:00 2008 +0000) 1 commit
 + git-bisect.sh: don't accidentally override existing branch
   "bisect"

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 3 commits
 + diff: make "too many files" rename warning optional
 + bump rename limit defaults
 + add merge.renamelimit config option

* py/diff-submodule (Sat May 3 17:24:28 2008 -0700) 5 commits
 + is_racy_timestamp(): do not check timestamp for gitlinks
 + diff-lib.c: rename check_work_tree_entity()
 + diff: a submodule not checked out is not modified
 + Add t7506 to test submodule related functions for git-status
 + t4027: test diff for submodule with empty directory

A submodule that is not checked out is not modified, but was mistaken as
being removed.  Thanks Ping for tests and fixes.

* cc/hooks-doc (Fri May 2 05:30:47 2008 +0200) 1 commit
 + Documentation: rename "hooks.txt" to "githooks.txt" and make it a
   man page

* mv/format-cc (Tue Apr 29 12:56:47 2008 +0200) 3 commits
 + Add tests for sendemail.cc configuration variable
 + git-send-email: add a new sendemail.cc configuration variable
 + git-format-patch: add a new format.cc configuration variable

* bd/tests (Sun May 4 01:38:00 2008 -0400) 10 commits
 + Rename the test trash directory to contain spaces.
 + Fix tests breaking when checkout path contains shell
   metacharacters
 + Don't use the 'export NAME=value' in the test scripts.
 + lib-git-svn.sh: Fix quoting issues with paths containing shell
   metacharacters
 + test-lib.sh: Fix some missing path quoting
 + Use test_set_editor in t9001-send-email.sh
 + test-lib.sh: Add a test_set_editor function to safely set $VISUAL
 + git-send-email.perl: Handle shell metacharacters in $EDITOR
   properly
 + config.c: Escape backslashes in section names properly
 + git-rebase.sh: Fix --merge --abort failures when path contains
   whitespace

Making sure the tools quote paths correctly and work inside a directory
whose pathname contains whitespace.  Thanks Bryan, and thanks J6t for
reviewing and testing.

* sb/committer (Sun May 4 18:04:51 2008 +0200) 3 commits
 + commit: Show committer if automatic
 + commit: Show author if different from committer
 + Preparation to call determine_author_info from prepare_to_commit

----------------------------------------------------------------
[Will merge to "master" soonish]

* as/graph (Mon May 5 00:57:03 2008 -0700) 4 commits
 + graph API: eliminate unnecessary indentation
 + log and rev-list: add --graph option
 + Add history graph API
 + revision API: split parent rewriting and parent printing options

Draw "tig 'g'" graph without tig ;-)

* np/pack (Fri May 2 15:11:51 2008 -0400) 7 commits
 + pack-objects: fix early eviction for max depth delta objects
 + pack-objects: allow for early delta deflating
 + pack-objects: move compression code in a separate function
 + pack-objects: clean up write_object() a bit
 + pack-objects: simplify the condition associated with --all-
   progress
 + pack-objects: remove some double negative logic
 + pack-objects: small cleanup

Every time Nico tweaks pack generation, something good comes out ;-).

* db/clone-in-c (Sun Apr 27 13:39:30 2008 -0400) 8 commits
 + Build in clone
 + Provide API access to init_db()
 + Add a function to set a non-default work tree
 + Allow for having for_each_ref() list extra refs
 + Have a constant extern refspec for "--tags"
 + Add a library function to add an alternate to the alternates file
 + Add a lockfile function to append to a file
 + Mark the list of refs to fetch as const

For 1.5.6; please give it a good beating.

----------------------------------------------------------------
[Actively Cooking]

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 + "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* ap/svn (Mon May 12 17:09:49 2008 -0700) 4 commits
 + git-svn: add test for --add-author-from and --use-log-author
 + git-svn: add documentation for --add-author-from option.
 + git-svn: Add --add-author-from option.
 + git-svn: add documentation for --use-log-author option.

Some tweak for output might be needed, I dunno.

* sv/first-parent (Mon May 12 17:12:36 2008 +0200) 2 commits
 + revision.c: really honor --first-parent
 + Simplify and fix --first-parent implementation

----------------------------------------------------------------
[Stalled]

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the tip commit on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

* ar/batch-cat (Wed Apr 23 15:17:47 2008 -0400) 5 commits
 - git-cat-file: Add --batch option
 - git-cat-file: Add --batch-check option
 - git-cat-file: Make option parsing a little more flexible
 - git-cat-file: Small refactor of cmd_cat_file
 - Add tests for git cat-file

I fixed up the problematic shell script in the first patch in the series
but later one introduced the same problematic constructs in another file,
at which point I gave up and discarded the rest.  At least it now passes
its own testsuite without breaking others.

----------------------------------------------------------------
[On Hold]

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* pb/push (Mon Apr 28 11:32:12 2008 -0400) 1 commit
 + add special "matching refs" refspec

This first patch is a good enhancement without hurting any existing users.
We need a staged introduction of the second and later patches, and many
people including me did not agree the later ones in the series are
desirable.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-05-12 22:03                         ` Junio C Hamano
@ 2008-05-13  0:02                           ` Junio C Hamano
  0 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-05-13  0:02 UTC (permalink / raw)
  To: Adam Roben; +Cc: git, Eric Wong

Adam, I am very sorry, but the message was misdirected.

I'm resending it now to ask for comments from Avery.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-05-06  6:38                       ` Junio C Hamano
@ 2008-05-12 22:03                         ` Junio C Hamano
  2008-05-13  0:02                           ` Junio C Hamano
  2008-05-14 22:30                         ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-05-12 22:03 UTC (permalink / raw)
  To: Adam Roben; +Cc: git, Eric Wong

Junio C Hamano <gitster@pobox.com> writes:

> [Dropped]
>
> * ap/svn (Tue Apr 15 21:04:18 2008 -0400) 3 commits
>  . git-svn: add documentation for --add-author-from option.
>  . git-svn: Add --add-author-from option.
>  . git-svn: add documentation for --use-log-author option.
>
> Eric requested a new set of tests for this series which never came.  I am
> still holding onto the tip of the topic in case we can resurrect it, but
> it is not merged to 'pu'.

I usually try hard not to do this kind of thing as it would encourage a
misconception that I'll tie any and all loose ends (which I obviously do
not have infinite amount of time and energy that is necessary), but I've
decided to add a skeleton for necessary tests to get the ball rolling.

Here is a sample output from the test sequence (the log message from the
last one):

    commit 0bc699cbd72810f85a0200c7197022b50e8298ed
    Author: A U Thor <author@example.com>
    Date:   Mon May 12 21:28:26 2008 +0000

        fourth

        From: A U Thor <author@example.com>


        git-svn-id: file:///git.git/t/trash directory/svnrepo@4 23bf1e2a-19bf-478a-b023-e66a9e40421e

I am not sure if adding the "From: " line as a trailer, with two blank
line after it before the git-svn-id line, is the intended format for the
final log message.  Maybe it is meant to go before the commit log message
with a blank line after it.  Maybe it is meant to be a trailer, one blank
line before and after it and then git-svn-id line (in whcih case we have
one blank after it too many).  I genuinely do not know what is intended.

If this is the intended output, please say so.  Otherwise please fix it as
needed, and add tests for the final format specification as well, so that
later changes will not break it.

Thanks.

-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 12 May 2008 14:53:40 -0700
Subject: [PATCH] git-svn: add test for --add-author-from and --use-log-author

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 t/t9122-git-svn-author.sh |   73 +++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 73 insertions(+), 0 deletions(-)
 create mode 100755 t/t9122-git-svn-author.sh

diff --git a/t/t9122-git-svn-author.sh b/t/t9122-git-svn-author.sh
new file mode 100755
index 0000000..d9a784b
--- /dev/null
+++ b/t/t9122-git-svn-author.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+
+test_description='git svn authorship'
+. ./lib-git-svn.sh
+
+test_expect_success 'setup svn repository' '
+	svn checkout "$svnrepo" work.svn &&
+	(
+		cd work.svn &&
+		echo >file
+		svn add file
+		svn commit -m "first commit" file
+	)
+
+'
+
+test_expect_success 'interact with it via git-svn' '
+
+	mkdir work.git &&
+	(
+		cd work.git &&
+		git svn init "$svnrepo"
+		git svn fetch &&
+
+		echo modification >file &&
+		test_tick &&
+		git commit -a -m second &&
+
+		test_tick &&
+		git svn dcommit &&
+
+		echo "further modification" >file &&
+		test_tick &&
+		git commit -a -m third &&
+
+		test_tick &&
+		git svn --add-author-from dcommit &&
+
+		echo "yet further modification" >file &&
+		test_tick &&
+		git commit -a -m fourth &&
+
+		test_tick &&
+		git svn --add-author-from --use-log-author dcommit &&
+
+		git log &&
+
+		git show -s HEAD^^ >../actual.2 &&
+		git show -s HEAD^  >../actual.3 &&
+		git show -s HEAD   >../actual.4
+
+	) &&
+
+	# Make sure that --add-author-from without --use-log-author
+	# did not affect the authorship information
+	myself=$(grep "^Author: " actual.2) &&
+	unaffected=$(grep "^Author: " actual.3) &&
+	test "z$myself" = "z$unaffected" &&
+
+	# Make sure lack of --add-author-from did not add cruft
+	! grep "^    From: A U Thor " actual.2 &&
+
+	# Make sure --add-author-from added cruft
+	grep "^    From: A U Thor " actual.3 &&
+	grep "^    From: A U Thor " actual.4 &&
+
+	# Make sure --add-author-from with --use-log-author affected
+	# the authorship information
+	grep "^Author: A U Thor " actual.4
+
+'
+
+test_done
-- 
1.5.5.1.328.g8abfd

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-04-27  6:04                     ` Junio C Hamano
  2008-04-27  6:44                       ` Ping Yin
@ 2008-05-06  6:38                       ` Junio C Hamano
  2008-05-12 22:03                         ` Junio C Hamano
  2008-05-14 22:30                         ` Junio C Hamano
  1 sibling, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-05-06  6:38 UTC (permalink / raw)
  To: git

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.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A good news is that the tip of 'pu' tonight passes all the test --- it has
been broken for some time.

A rough timeline from now on.

 * Discussion and review on new feature and enhancement patch series
   begins.  Please resubmit things that you were cooking in your head
   during 1.5.5-rc period after cleaning up and retesting.

 * 1.5.6 merge window closes (2008-05-14).

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

----------------------------------------------------------------
[New Topics]

* bd/tests (Sun May 4 01:38:00 2008 -0400) 10 commits
 + Rename the test trash directory to contain spaces.
 + Fix tests breaking when checkout path contains shell
   metacharacters
 + Don't use the 'export NAME=value' in the test scripts.
 + lib-git-svn.sh: Fix quoting issues with paths containing shell
   metacharacters
 + test-lib.sh: Fix some missing path quoting
 + Use test_set_editor in t9001-send-email.sh
 + test-lib.sh: Add a test_set_editor function to safely set $VISUAL
 + git-send-email.perl: Handle shell metacharacters in $EDITOR
   properly
 + config.c: Escape backslashes in section names properly
 + git-rebase.sh: Fix --merge --abort failures when path contains
   whitespace

Making sure the tools quote paths correctly and work inside a directory
whose pathname contains whitespace.  Thanks Bryan, and thanks J6t for
reviewing and testing.

* np/pack (Fri May 2 15:11:51 2008 -0400) 7 commits
 + pack-objects: fix early eviction for max depth delta objects
 + pack-objects: allow for early delta deflating
 + pack-objects: move compression code in a separate function
 + pack-objects: clean up write_object() a bit
 + pack-objects: simplify the condition associated with --all-
   progress
 + pack-objects: remove some double negative logic
 + pack-objects: small cleanup

Every time Nico tweaks pack generation, something good comes out ;-).

* py/diff-submodule (Sat May 3 17:24:28 2008 -0700) 5 commits
 + is_racy_timestamp(): do not check timestamp for gitlinks
 + diff-lib.c: rename check_work_tree_entity()
 + diff: a submodule not checked out is not modified
 + Add t7506 to test submodule related functions for git-status
 + t4027: test diff for submodule with empty directory

A submodule that is not checked out is not modified, but was mistaken as
being removed.  Thanks Ping for tests and fixes.

* cc/hooks-doc (Fri May 2 05:30:47 2008 +0200) 1 commit
 - Documentation: rename "hooks.txt" to "githooks.txt" and make it a
   man page

I've looked at but not applied most of the patches in the series that
built on top of this.  I think it probably is a good goal to make
everything _accessible_ as manual pages, but at the same time I do not
exactly like the HTML rendered results of material that are not really
manual pages.  E.g. "Everyday" looks much worse to me.

At least, the categorization of sections 1/5/7 should be straightened
out.  diffcore is not about "file format" at all and do not belong to
section 5, for example.

* pb/push (Mon Apr 28 11:32:12 2008 -0400) 1 commit
 - add special "matching refs" refspec

This first patch is a good enhancement without hurting any existing users.
We need a staged introduction of the second and later patches, and many
people including me did not agree the later ones in the series are
desirable.

* mv/format-cc (Tue Apr 29 12:56:47 2008 +0200) 3 commits
 + Add tests for sendemail.cc configuration variable
 + git-send-email: add a new sendemail.cc configuration variable
 + git-format-patch: add a new format.cc configuration variable

* as/graph (Mon May 5 00:57:03 2008 -0700) 4 commits
 - graph API: eliminate unnecessary indentation
 - log and rev-list: add --graph option
 - Add history graph API
 - revision API: split parent rewriting and parent printing options

Draw "tig 'g'" graph without tig ;-)

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 4 commits
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for
 + diff: make "too many files" rename warning optional
 + bump rename limit defaults
 + add merge.renamelimit config option

The documentation part of this series partly depends on another series,
but I am expecting both to graduate smoothly to 'master' reasonably soon.

* sv/first-parent (Sun Apr 27 19:32:46 2008 +0200) 1 commit
 + Simplify and fix --first-parent implementation

* gp/bisect-fix (Mon May 5 07:43:00 2008 +0000) 1 commit
 + git-bisect.sh: don't accidentally override existing branch
   "bisect"

----------------------------------------------------------------
[Graduated to "master"]

* pb/remote-mirror-config (Thu Apr 17 13:17:20 2008 +0200) 1 commit
 + Add a remote.*.mirror configuration option

* lh/branch-merged (Fri Apr 18 18:30:15 2008 +0200) 3 commits
 + Add tests for `branch --[no-]merged`
 + git-branch.txt: compare --contains, --merged and --no-merged
 + git-branch: add support for --merged and --no-merged

* jk/fetch-status (Wed Apr 9 20:11:52 2008 -0400) 1 commit
 + git-fetch: always show status of non-tracking-ref fetches

This changes reporting behaviour of one-shot "git pull $url $branch",
which would affect long-time users in integrator role (that's you, Linus
;-).  Let's see if we hear anybody screaming.

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 + Teach GIT-VERSION-GEN about the .git file
 + Teach git-submodule.sh about the .git file
 + Teach resolve_gitlink_ref() about the .git file
 + Add platform-independent .git "symlink"

There was a GSoC project idea to enhance "git submodule" to take advantage
of this facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was bound to
the superproject, but it appears nobody took it.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 + filter-branch.sh: support nearly proper tag name filtering

Instead of discarding annotated and/or signed tags, this keeps them and
demotes the signed ones to simply annotated.  It issues warning when it
does this demotion.  I think the behaviour is sensible.

* jc/lstat (Sun Mar 30 12:39:25 2008 -0700) 2 commits
 + diff-files: mark an index entry we know is up-to-date as such
 + write_index(): optimize ce_smudge_racily_clean_entry() calls with
   CE_UPTODATE

Further reduce redundant lstat(2) calls during "git status" and other
common operations.

----------------------------------------------------------------
[Will merge to "master" soonish]

* lt/dirmatch-optim (Sat Apr 19 14:22:38 2008 -0700) 1 commit
 + Optimize match_pathspec() to avoid fnmatch()

* dm/cherry-pick-s (Sat Apr 26 15:14:28 2008 -0500) 1 commit
 + Allow cherry-pick (and revert) to add signoff line

* cc/help (Fri Apr 25 08:25:41 2008 +0200) 5 commits
 + documentation: web--browse: add a note about konqueror
 + documentation: help: add info about "man.<tool>.cmd" config var
 + help: use "man.<tool>.cmd" as custom man viewer command
 + documentation: help: add "man.<tool>.path" config variable
 + help: use man viewer path from "man.<tool>.path" config var

* jn/webfeed (Sun Apr 20 22:09:48 2008 +0200) 1 commit
 + gitweb: Use feed link according to current view

----------------------------------------------------------------
[Actively Cooking]

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

* db/learn-HEAD (Sat Apr 26 15:53:12 2008 -0400) 2 commits
 + Make ls-remote http://... list HEAD, like for git://...
 + Make walker.fetch_ref() take a struct ref.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 6 commits
 - merge: remove deprecated summary and diffstat options and config
   variables
 + merge, pull: add '--(no-)log' command line option
 + fmt-merge-msg: add '--(no-)log' options and 'merge.log' config
   variable
 + add 'merge.stat' config variable
 + merge, pull: introduce '--(no-)stat' option
 + doc: moved merge.* config variables into separate merge-config.txt

The last one needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.
This may help a GSoC project that wants to gather statistical overview of
the history.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 + "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.  There recently was a problem report that had a scent of this
issue which turned out to be a false alarm (it was about http-push which
does not do the native pack protocol optimization and the reporter was
pushing into an empty repository which needs full transfer anyway).

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

----------------------------------------------------------------
[Dropped]

* ap/svn (Tue Apr 15 21:04:18 2008 -0400) 3 commits
 . git-svn: add documentation for --add-author-from option.
 . git-svn: Add --add-author-from option.
 . git-svn: add documentation for --use-log-author option.

Eric requested a new set of tests for this series which never came.  I am
still holding onto the tip of the topic in case we can resurrect it, but
it is not merged to 'pu'.

----------------------------------------------------------------
[On Hold]

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* db/clone-in-c (Sun Apr 27 13:39:30 2008 -0400) 8 commits
 - Build in clone
 - Provide API access to init_db()
 - Add a function to set a non-default work tree
 - Allow for having for_each_ref() list extra refs
 - Have a constant extern refspec for "--tags"
 - Add a library function to add an alternate to the alternates file
 - Add a lockfile function to append to a file
 - Mark the list of refs to fetch as const

I'd really want this in 1.5.6; will merge to 'next' after giving a final
pass sometime this week.

* ar/batch-cat (Wed Apr 23 15:17:47 2008 -0400) 5 commits
 - git-cat-file: Add --batch option
 - git-cat-file: Add --batch-check option
 - git-cat-file: Make option parsing a little more flexible
 - git-cat-file: Small refactor of cmd_cat_file
 - Add tests for git cat-file

I fixed up the problematic shell script in the first patch in the series
but later one introduced the same problematic constructs in another file,
at which point I gave up and discarded the rest.  At least it now passes
its own testsuite without breaking others.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/lstat-debug (Thu Mar 27 16:56:53 2008 -0700) 1 commit
 - lstat: introduce a wrapper xlstat

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-27  6:04                     ` Junio C Hamano
@ 2008-04-27  6:44                       ` Ping Yin
  2008-05-06  6:38                       ` Junio C Hamano
  1 sibling, 0 replies; 575+ messages in thread
From: Ping Yin @ 2008-04-27  6:44 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sun, Apr 27, 2008 at 2:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>  * py/submodule-2 (Wed Apr 16 22:19:31 2008 +0800) 1 commit
>   - git-submodule: Extract functions module_info and module_url
>
>  Not going well.
>

Hmm, i wonder how this series can go well. Or this series is totoally
bad and should be discarded.


Ping Yin

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-04-22 10:03                   ` Junio C Hamano
  2008-04-22 13:59                     ` Ping Yin
  2008-04-22 20:51                     ` Michele Ballabio
@ 2008-04-27  6:04                     ` Junio C Hamano
  2008-04-27  6:44                       ` Ping Yin
  2008-05-06  6:38                       ` Junio C Hamano
  2 siblings, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-04-27  6:04 UTC (permalink / raw)
  To: git

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.

A rough timeline from now on.

 * Discussion and review on new feature and enhancement patch series
   begins.  Please resubmit things that you were cooking in your head
   during 1.5.5-rc period after cleaning up and retesting.

 * 1.5.6 merge window closes (2008-05-14).

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

----------------------------------------------------------------
[New Topics]

* db/learn-HEAD (Sat Apr 26 15:53:12 2008 -0400) 2 commits
 - Make ls-remote http://... list HEAD, like for git://...
 - Make walker.fetch_ref() take a struct ref.

* cc/help (Fri Apr 25 08:25:41 2008 +0200) 5 commits
 - documentation: web--browse: add a note about konqueror
 - documentation: help: add info about "man.<tool>.cmd" config var
 - help: use "man.<tool>.cmd" as custom man viewer command
 - documentation: help: add "man.<tool>.path" config variable
 - help: use man viewer path from "man.<tool>.path" config var

* jn/webfeed (Sun Apr 20 22:09:48 2008 +0200) 1 commit
 + gitweb: Use feed link according to current view

* ar/batch-cat (Wed Apr 23 15:17:53 2008 -0400) 11 commits
 - git-svn: Speed up fetch
 - Git.pm: Add hash_and_insert_object and cat_blob
 - Git.pm: Add command_bidi_pipe and command_close_bidi_pipe
 - git-hash-object: Add --stdin-paths option
 - Add more tests for git hash-object
 - Move git-hash-object tests from t5303 to t1007
 - git-cat-file: Add --batch option
 - git-cat-file: Add --batch-check option
 - git-cat-file: Make option parsing a little more flexible
 - git-cat-file: Small refactor of cmd_cat_file
 - <<REJECT>> Add tests for git cat-file

* lt/dirmatch-optim (Sat Apr 19 14:22:38 2008 -0700) 1 commit
 + Optimize match_pathspec() to avoid fnmatch()

* dm/cherry-pick-s (Sat Apr 26 15:14:28 2008 -0500) 1 commit
 + Allow cherry-pick (and revert) to add signoff line

----------------------------------------------------------------
[Graduated to "master"]

* ho/shared (Wed Apr 16 11:34:24 2008 +0300) 1 commit
 + Make core.sharedRepository more generic

----------------------------------------------------------------
[Will merge to "master" soonish]

* pb/remote-mirror-config (Thu Apr 17 13:17:20 2008 +0200) 1 commit
 + Add a remote.*.mirror configuration option

* lh/branch-merged (Fri Apr 18 18:30:15 2008 +0200) 3 commits
 + Add tests for `branch --[no-]merged`
 + git-branch.txt: compare --contains, --merged and --no-merged
 + git-branch: add support for --merged and --no-merged

* jk/fetch-status (Wed Apr 9 20:11:52 2008 -0400) 1 commit
 + git-fetch: always show status of non-tracking-ref fetches

This changes reporting behaviour of one-shot "git pull $url $branch",
which would affect long-time users in integrator role (that's you, Linus
;-).  Let's see if we hear anybody screaming.

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 + Teach GIT-VERSION-GEN about the .git file
 + Teach git-submodule.sh about the .git file
 + Teach resolve_gitlink_ref() about the .git file
 + Add platform-independent .git "symlink"

There was a GSoC project idea to enhance "git submodule" to take advantage
of this facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was bound to
the superproject, but it appears nobody took it.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 + filter-branch.sh: support nearly proper tag name filtering

Instead of discarding annotated and/or signed tags, this keeps them and
demotes the signed ones to simply annotated.  It issues warning when it
does this demotion.  I think the behaviour is sensible.

* jc/lstat (Sun Mar 30 12:39:25 2008 -0700) 2 commits
 + diff-files: mark an index entry we know is up-to-date as such
 + write_index(): optimize ce_smudge_racily_clean_entry() calls with
   CE_UPTODATE

Further reduce redundant lstat(2) calls during "git status" and other
common operations.

----------------------------------------------------------------
[Actively Cooking]

* js/rebase-i-sequencer (Fri Apr 25 22:50:53 2008 -0700) 14 commits
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 6 commits
 - merge: remove deprecated summary and diffstat options and config
   variables
 + merge, pull: add '--(no-)log' command line option
 + fmt-merge-msg: add '--(no-)log' options and 'merge.log' config
   variable
 + add 'merge.stat' config variable
 + merge, pull: introduce '--(no-)stat' option
 + doc: moved merge.* config variables into separate merge-config.txt

The last one needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 + "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.  There recently was a problem report that had a scent of this
issue which turned out to be a false alarm (it was about http-push which
does not do the native pack protocol optimization and the reporter was
pushing into an empty repository which needs full transfer anyway).

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

----------------------------------------------------------------
[Dropped]


----------------------------------------------------------------
[On Hold]

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* db/clone-in-c (Thu Apr 17 19:32:43 2008 -0400) 8 commits
 - [mess] Build in clone
 - [strdup() and other clean-ups needed] Provide API access to
   init_db()
 - [waiting for response] Add a function to set a non-default work
   tree
 - Allow for having for_each_ref() list extra refs
 - Have a constant extern refspec for "--tags"
 - Add a library function to add an alternate to the alternates file
 - Add a lockfile function to append to a file
 - Mark the list of refs to fetch as const

There were a few comments and suggestions to the ones near the tip that
need to be addressed.  Earlier ones look Ok.

* ap/svn (Tue Apr 15 21:04:18 2008 -0400) 3 commits
 - git-svn: add documentation for --add-author-from option.
 - git-svn: Add --add-author-from option.
 - git-svn: add documentation for --use-log-author option.

Eric requested a new set of tests for this series.

* py/submodule-2 (Wed Apr 16 22:19:31 2008 +0800) 1 commit
 - git-submodule: Extract functions module_info and module_url

Not going well.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/lstat-debug (Thu Mar 27 16:56:53 2008 -0700) 1 commit
 - lstat: introduce a wrapper xlstat

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-23  8:47                                 ` Robin Rosenberg
@ 2008-04-23  9:16                                   ` Fedor Sergeev
  0 siblings, 0 replies; 575+ messages in thread
From: Fedor Sergeev @ 2008-04-23  9:16 UTC (permalink / raw)
  To: Robin Rosenberg; +Cc: Ping Yin, Josef Weidendorfer, Junio C Hamano, git

On Wed, 23 Apr 2008, Robin Rosenberg wrote:

> onsdagen den 23 april 2008 09.47.57 skrev Fedor Sergeev:
>> If one manages to hack on repository one can modify it enormous amount of
>> ways, including spoofing on SHA (providing wrong contents for it - does
>> git verify that when getting a pack?), utilizing bugs in git etc...
>
> The pack transfer protocol does not transfer the SHA of objects, only the
> contents is transferred. The SHA-1 is (has to be since it is not sent)
> reconstructed on the receiving end.

Thats nice. Then I agree its difficult to spoil superproject out of 
submodule other than it just does not checkout.

regards,
   Fedor.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-23  7:47                               ` Fedor Sergeev
  2008-04-23  8:32                                 ` Ping Yin
@ 2008-04-23  8:47                                 ` Robin Rosenberg
  2008-04-23  9:16                                   ` Fedor Sergeev
  1 sibling, 1 reply; 575+ messages in thread
From: Robin Rosenberg @ 2008-04-23  8:47 UTC (permalink / raw)
  To: Fedor Sergeev; +Cc: Ping Yin, Josef Weidendorfer, Junio C Hamano, git

onsdagen den 23 april 2008 09.47.57 skrev Fedor Sergeev:
> If one manages to hack on repository one can modify it enormous amount of
> ways, including spoofing on SHA (providing wrong contents for it - does
> git verify that when getting a pack?), utilizing bugs in git etc...

The pack transfer protocol does not transfer the SHA of objects, only the 
contents is transferred. The SHA-1 is (has to be since it is not sent) 
reconstructed on the receiving end.

-- robin

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-23  7:47                               ` Fedor Sergeev
@ 2008-04-23  8:32                                 ` Ping Yin
  2008-04-23  8:47                                 ` Robin Rosenberg
  1 sibling, 0 replies; 575+ messages in thread
From: Ping Yin @ 2008-04-23  8:32 UTC (permalink / raw)
  To: Fedor Sergeev; +Cc: Josef Weidendorfer, Junio C Hamano, git

On Wed, Apr 23, 2008 at 3:47 PM, Fedor Sergeev <Fedor.Sergeev@sun.com> wrote:
> On Wed, 23 Apr 2008, Ping Yin wrote:
>
> >
> > On Wed, Apr 23, 2008 at 2:07 AM, Josef Weidendorfer
> >
> >
> > >  Hmm... At least, it can be very annoying when git fetches data from
> repositories
> > >  you did not expect, only because submodule URLs change via this
> > >  fallback mechanism. Perhaps it is a little far reached, but suppose a
> project
> > >  changes its URL, and the old one becomes occupied by a malicious
> person.
> > >  The problem is that the URL with the now malicious repository is bound
> in the
> > >  history of the project.
> > >
> >
> > It is always bound now without the fallback patch :)
> >
> >
> > >  For sure, you do not want to fetch from that old repository
> > >  by accident, after you did a checkout of an old commit. And there would
> be no
> > >  way to protect other people from this malicious repository other than
> rewriting
> > >  the whole history.
> > >
> >
> > I wonder how the *malicious* repository can hurt us since only the
> > commit recorded in commit of the super project will be checked out.
> >
>
>  If one manages to hack on repository one can modify it enormous amount of
> ways, including spoofing on SHA (providing wrong contents for it - does git
> verify that when getting a pack?), utilizing bugs in git etc...

Doable? I dunno.



-- 
Ping Yin

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-23  1:59                             ` Ping Yin
@ 2008-04-23  7:47                               ` Fedor Sergeev
  2008-04-23  8:32                                 ` Ping Yin
  2008-04-23  8:47                                 ` Robin Rosenberg
  0 siblings, 2 replies; 575+ messages in thread
From: Fedor Sergeev @ 2008-04-23  7:47 UTC (permalink / raw)
  To: Ping Yin; +Cc: Josef Weidendorfer, Junio C Hamano, git

On Wed, 23 Apr 2008, Ping Yin wrote:
> On Wed, Apr 23, 2008 at 2:07 AM, Josef Weidendorfer
>>  Hmm... At least, it can be very annoying when git fetches data from repositories
>>  you did not expect, only because submodule URLs change via this
>>  fallback mechanism. Perhaps it is a little far reached, but suppose a project
>>  changes its URL, and the old one becomes occupied by a malicious person.
>>  The problem is that the URL with the now malicious repository is bound in the
>>  history of the project.
>
> It is always bound now without the fallback patch :)
>
>>  For sure, you do not want to fetch from that old repository
>>  by accident, after you did a checkout of an old commit. And there would be no
>>  way to protect other people from this malicious repository other than rewriting
>>  the whole history.
>
> I wonder how the *malicious* repository can hurt us since only the
> commit recorded in commit of the super project will be checked out.

If one manages to hack on repository one can modify it enormous amount of 
ways, including spoofing on SHA (providing wrong contents for it - does 
git verify that when getting a pack?), utilizing bugs in git etc...

I doubt somebody would spend that much of an effort but you know,
you can not be paranoid *enough* :)

regards,
   Fedor.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-23  0:22                       ` Junio C Hamano
@ 2008-04-23  7:36                         ` Michele Ballabio
  0 siblings, 0 replies; 575+ messages in thread
From: Michele Ballabio @ 2008-04-23  7:36 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wednesday 23 April 2008, Junio C Hamano wrote:
> In the thread, addition of an extra hook to "gc --auto" wasdiscussed.  It
> was judged conditionally Ok as long as nobody assumes "gc --auto" is
> ultra-cheap.  We used to have a "gc --auto" at the end of git-commit which
> violated that condition, but we do not have that anymore.
> 
> The patch resurrects the behaviour that makes the extra hook possibly
> unacceptable again, dosn't it?

Yes. I thought there was an unwanted change in behavior in git-commit.
Sorry for the noise.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-23  1:27                             ` Ping Yin
@ 2008-04-23  2:03                               ` Ping Yin
  0 siblings, 0 replies; 575+ messages in thread
From: Ping Yin @ 2008-04-23  2:03 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Josef Weidendorfer, Junio C Hamano, git

On Wed, Apr 23, 2008 at 9:27 AM, Ping Yin <pkufranky@gmail.com> wrote:
>
> On Wed, Apr 23, 2008 at 1:28 AM, Johannes Schindelin
>  <Johannes.Schindelin@gmx.de> wrote:
>  > Hi,
>  >
>  >
>  >  On Wed, 23 Apr 2008, Ping Yin wrote:
>  >
>  >  > If we go back to a old HEAD or switch to another branch with changed
>  >  > path for a submodule, what should 'git submodule update' do? I think
>  >  > entries in .gitmodules should take precedence.
>  >
>  >  Literally the most common reason for a _different_ .gitmodules in an older
>  >  revision is that the repository was moved to another machine.
>  >
>  >  In this case, your suggestion is actively wrong.
>  >
>  Another common reason is the adjustment of repository directory in the
>  central environment

I'm wrong, this is the case that  *url* changes.

>  so i said *path*, not *url*. I agree what Josef said in the the
>  following reply: "It makes no sense to have submodule path
>  configuration in .git/config, as it has to be in sync with the current
>  commit". So it should be bettter to store path info only in
>  .gitmodules instead of $GIT_DIR/config
>

The case that *path* changes is the submodule is moved to a new path
in some commit. But it is a very rare case.


-- 
Ping Yin

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-22 18:07                           ` Josef Weidendorfer
@ 2008-04-23  1:59                             ` Ping Yin
  2008-04-23  7:47                               ` Fedor Sergeev
  0 siblings, 1 reply; 575+ messages in thread
From: Ping Yin @ 2008-04-23  1:59 UTC (permalink / raw)
  To: Josef Weidendorfer; +Cc: Junio C Hamano, git

On Wed, Apr 23, 2008 at 2:07 AM, Josef Weidendorfer
<Josef.Weidendorfer@gmx.de> wrote:
> On Tuesday 22 April 2008, Ping Yin wrote:
>
> > >  A reason you did not mention is security:
>  > >  You never want your .git/config to be changed behind your back, which
>  > >  effectivly is the case when using the versioned .gitmodules information
>  > >  (similar problem as with a .gitconfig in-tree).
>  >
>  > As discussed in another thread about in-tree .gitconfig, security
>  > issues only arise on limited configuration entries. However, there are
>  > no entries in .gitmodules falling into any of these entries.
>
>  Hmm... At least, it can be very annoying when git fetches data from repositories
>  you did not expect, only because submodule URLs change via this
>  fallback mechanism. Perhaps it is a little far reached, but suppose a project
>  changes its URL, and the old one becomes occupied by a malicious person.
>  The problem is that the URL with the now malicious repository is bound in the
>  history of the project.

It is always bound now without the fallback patch :)

>  For sure, you do not want to fetch from that old repository
>  by accident, after you did a checkout of an old commit. And there would be no
>  way to protect other people from this malicious repository other than rewriting
>  the whole history.

I wonder how the *malicious* repository can hurt us since only the
commit recorded in commit of the super project will be checked out.

>
>
>  > >  Another one:
>  > >  From a design point of view, submodule URLs are project meta information
>  > >  unrelated to source history. So, actually, I think it was wrong to put
>  > >  submodule URLs (even hints only) into the versioned .gitmodules files (*).
>  >
>  > But now it actually acts as hints and we don't find a better way. I
>  > just propose that the hints become the good default.
>
>  For me this sounds like: Now that we have made this bad decision, it does
>  not matter to make it even worse.

I should be like: Now that we have made a bad decision (if it is), we
have to improve it to make life better before we can find a better
solution.

>
>  What was the motivation for this fallback mechanism?
>
>  In any way, it is preferable to always use the correct URL for submodules.
>  Thus, when the URL ever changes in the projects livetime (covered by
>  git history), you want to have the correct URL in your .git/config
>  (not to accidently use the wrong URL when checking out an old commit).
>  But then, the fallback mechanism does not trigger anyway.

I havn't found yet how an incorrect URL can hurt us. The worst case i
can imagine is the failure of "git submodule update".

Two of the most common cases which can result in an incorrect/stale url is

 * the repository has been moved to another machine
 * the directory structure of upstream repositories has changed

However, there are also cases that the old version of url in
.gitmodules is correct.

Think about the case that the reposotory maintainer has decided to
replace current submodule with a totoally different one. In this case,
when back to the old HEAD, the url in .gitmodules is correct while url
in $GIT_DIR/config is incorrect.

So, when error happens, we can't judge which url is correct. So just
let the user make the decision by refering the change history of
.gitmodules or asking the repository maintainer.


-- 
Ping Yin

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-22 17:28                           ` Johannes Schindelin
@ 2008-04-23  1:27                             ` Ping Yin
  2008-04-23  2:03                               ` Ping Yin
  0 siblings, 1 reply; 575+ messages in thread
From: Ping Yin @ 2008-04-23  1:27 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Josef Weidendorfer, Junio C Hamano, git

On Wed, Apr 23, 2008 at 1:28 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
>  On Wed, 23 Apr 2008, Ping Yin wrote:
>
>  > If we go back to a old HEAD or switch to another branch with changed
>  > path for a submodule, what should 'git submodule update' do? I think
>  > entries in .gitmodules should take precedence.
>
>  Literally the most common reason for a _different_ .gitmodules in an older
>  revision is that the repository was moved to another machine.
>
>  In this case, your suggestion is actively wrong.
>
Another common reason is the adjustment of repository directory in the
central environment
so i said *path*, not *url*. I agree what Josef said in the the
following reply: "It makes no sense to have submodule path
configuration in .git/config, as it has to be in sync with the current
commit". So it should be bettter to store path info only in
.gitmodules instead of $GIT_DIR/config


-- 
Ping Yin

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-22 20:51                     ` Michele Ballabio
@ 2008-04-23  0:22                       ` Junio C Hamano
  2008-04-23  7:36                         ` Michele Ballabio
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-04-23  0:22 UTC (permalink / raw)
  To: Michele Ballabio; +Cc: git

Michele Ballabio <barra_cuda@katamail.com> writes:

> On Tuesday 22 April 2008, Junio C Hamano wrote:
>> * mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
>>  + contrib/hooks: add an example pre-auto-gc hook
>>  + Documentation/hooks: add pre-auto-gc hook
>>  + git-gc --auto: add pre-auto-gc hook
>> 
>> A new hook to stop "git gc --auto" from running.
>
> About "git gc --auto", there was a patch sometime ago:
>
> 	[PATCH] commit: resurrect "gc --auto" at the end
>
> http://marc.info/?l=git&m=120716427130606&w=2
>
> Was it dropped?

In the thread, addition of an extra hook to "gc --auto" wasdiscussed.  It
was judged conditionally Ok as long as nobody assumes "gc --auto" is
ultra-cheap.  We used to have a "gc --auto" at the end of git-commit which
violated that condition, but we do not have that anymore.

The patch resurrects the behaviour that makes the extra hook possibly
unacceptable again, dosn't it?

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-22 10:03                   ` Junio C Hamano
  2008-04-22 13:59                     ` Ping Yin
@ 2008-04-22 20:51                     ` Michele Ballabio
  2008-04-23  0:22                       ` Junio C Hamano
  2008-04-27  6:04                     ` Junio C Hamano
  2 siblings, 1 reply; 575+ messages in thread
From: Michele Ballabio @ 2008-04-22 20:51 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

On Tuesday 22 April 2008, Junio C Hamano wrote:
> * mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
>  + contrib/hooks: add an example pre-auto-gc hook
>  + Documentation/hooks: add pre-auto-gc hook
>  + git-gc --auto: add pre-auto-gc hook
> 
> A new hook to stop "git gc --auto" from running.

About "git gc --auto", there was a patch sometime ago:

	[PATCH] commit: resurrect "gc --auto" at the end

http://marc.info/?l=git&m=120716427130606&w=2

Was it dropped?

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-22 17:13                         ` Ping Yin
  2008-04-22 17:28                           ` Johannes Schindelin
@ 2008-04-22 18:07                           ` Josef Weidendorfer
  2008-04-23  1:59                             ` Ping Yin
  1 sibling, 1 reply; 575+ messages in thread
From: Josef Weidendorfer @ 2008-04-22 18:07 UTC (permalink / raw)
  To: Ping Yin; +Cc: Junio C Hamano, git

On Tuesday 22 April 2008, Ping Yin wrote:
> >  A reason you did not mention is security:
> >  You never want your .git/config to be changed behind your back, which
> >  effectivly is the case when using the versioned .gitmodules information
> >  (similar problem as with a .gitconfig in-tree).
> 
> As discussed in another thread about in-tree .gitconfig, security
> issues only arise on limited configuration entries. However, there are
> no entries in .gitmodules falling into any of these entries.

Hmm... At least, it can be very annoying when git fetches data from repositories
you did not expect, only because submodule URLs change via this
fallback mechanism. Perhaps it is a little far reached, but suppose a project
changes its URL, and the old one becomes occupied by a malicious person.
The problem is that the URL with the now malicious repository is bound in the
history of the project. For sure, you do not want to fetch from that old repository
by accident, after you did a checkout of an old commit. And there would be no
way to protect other people from this malicious repository other than rewriting
the whole history.

> >  Another one:
> >  From a design point of view, submodule URLs are project meta information
> >  unrelated to source history. So, actually, I think it was wrong to put
> >  submodule URLs (even hints only) into the versioned .gitmodules files (*).
> 
> But now it actually acts as hints and we don't find a better way. I
> just propose that the hints become the good default.

For me this sounds like: Now that we have made this bad decision, it does
not matter to make it even worse.

What was the motivation for this fallback mechanism?

In any way, it is preferable to always use the correct URL for submodules.
Thus, when the URL ever changes in the projects livetime (covered by
git history), you want to have the correct URL in your .git/config
(not to accidently use the wrong URL when checking out an old commit).
But then, the fallback mechanism does not trigger anyway.

> >  The main reason for .gitmodules is to store submodule information which
> >  has to be in sync with commits, such as a submodule name related to some
> >  path where the submodule happens to be checked out in a given commit, and
> >  also related to some config entry holding the URL to allow for fetch/pull.
> >  The idea is that submodules have an identity in the supermodule (in contrast
> >  to files in git), such that related configuration keeps valid when moving
> >  submodules around. This needs simultanous adjusting the path attribute in
> >  .gitmodules when a submodule is moved.
> 
> If we go back to a old HEAD or switch to another branch with changed
> path for a submodule,  what should 'git submodule update' do?
> I think entries in .gitmodules should take precedence.

Of course. It makes no sense to have submodule path configuration in .git/config,
as it has to be in sync with the current commit. That has nothing to do with
precedence. The same is true for .gitattributes, for example.

> So url in $GIT_DIR/config is authoritative, and path in .gitmodules is
> authoritative.

No.
These are totally different types of configurations.

Josef

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-22 17:13                         ` Ping Yin
@ 2008-04-22 17:28                           ` Johannes Schindelin
  2008-04-23  1:27                             ` Ping Yin
  2008-04-22 18:07                           ` Josef Weidendorfer
  1 sibling, 1 reply; 575+ messages in thread
From: Johannes Schindelin @ 2008-04-22 17:28 UTC (permalink / raw)
  To: Ping Yin; +Cc: Josef Weidendorfer, Junio C Hamano, git

Hi,

On Wed, 23 Apr 2008, Ping Yin wrote:

> If we go back to a old HEAD or switch to another branch with changed 
> path for a submodule, what should 'git submodule update' do? I think 
> entries in .gitmodules should take precedence.

Literally the most common reason for a _different_ .gitmodules in an older 
revision is that the repository was moved to another machine.

In this case, your suggestion is actively wrong.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-22 14:55                       ` Josef Weidendorfer
@ 2008-04-22 17:13                         ` Ping Yin
  2008-04-22 17:28                           ` Johannes Schindelin
  2008-04-22 18:07                           ` Josef Weidendorfer
  0 siblings, 2 replies; 575+ messages in thread
From: Ping Yin @ 2008-04-22 17:13 UTC (permalink / raw)
  To: Josef Weidendorfer; +Cc: Junio C Hamano, git

On Tue, Apr 22, 2008 at 10:55 PM, Josef Weidendorfer
<Josef.Weidendorfer@gmx.de> wrote:
> On Tuesday 22 April 2008, Ping Yin wrote:
>  > On Tue, Apr 22, 2008 at 6:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> > >  It does not help motivating me reviewing the series that the overall tone
>  > >  of it is to ignore .git/config more and make .gitmodules take more active
>  > >  role, either.  I have already said number of times why that is not a good
>  > >  idea and why it is against the overall submodule design.
>  >
>  > I summarize junio's points that says $GIT_DIR/config is authoritative.
>  >
>  > [...]
>  >
>  > Any others?
>
>  A reason you did not mention is security:
>  You never want your .git/config to be changed behind your back, which
>  effectivly is the case when using the versioned .gitmodules information
>  (similar problem as with a .gitconfig in-tree).

As discussed in another thread about in-tree .gitconfig, security
issues only arise on limited configuration entries. However, there are
no entries in .gitmodules falling into any of these entries.

>
>  Another one:
>  From a design point of view, submodule URLs are project meta information
>  unrelated to source history. So, actually, I think it was wrong to put
>  submodule URLs (even hints only) into the versioned .gitmodules files (*).

But now it actually acts as hints and we don't find a better way. I
just propose that the hints become the good default.

>
>  The main reason for .gitmodules is to store submodule information which
>  has to be in sync with commits, such as a submodule name related to some
>  path where the submodule happens to be checked out in a given commit, and
>  also related to some config entry holding the URL to allow for fetch/pull.
>  The idea is that submodules have an identity in the supermodule (in contrast
>  to files in git), such that related configuration keeps valid when moving
>  submodules around. This needs simultanous adjusting the path attribute in
>  .gitmodules when a submodule is moved.

If we go back to a old HEAD or switch to another branch with changed
path for a submodule,  what should 'git submodule update' do?
I think entries in .gitmodules should take precedence.

So url in $GIT_DIR/config is authoritative, and path in .gitmodules is
authoritative.




-- 
Ping Yin

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-22 13:59                     ` Ping Yin
@ 2008-04-22 14:55                       ` Josef Weidendorfer
  2008-04-22 17:13                         ` Ping Yin
  0 siblings, 1 reply; 575+ messages in thread
From: Josef Weidendorfer @ 2008-04-22 14:55 UTC (permalink / raw)
  To: Ping Yin; +Cc: Junio C Hamano, git

On Tuesday 22 April 2008, Ping Yin wrote:
> On Tue, Apr 22, 2008 at 6:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >  It does not help motivating me reviewing the series that the overall tone
> >  of it is to ignore .git/config more and make .gitmodules take more active
> >  role, either.  I have already said number of times why that is not a good
> >  idea and why it is against the overall submodule design.
> 
> I summarize junio's points that says $GIT_DIR/config is authoritative.
>
> [...]
> 
> Any others?

A reason you did not mention is security:
You never want your .git/config to be changed behind your back, which
effectivly is the case when using the versioned .gitmodules information
(similar problem as with a .gitconfig in-tree).

Another one:
From a design point of view, submodule URLs are project meta information
unrelated to source history. So, actually, I think it was wrong to put
submodule URLs (even hints only) into the versioned .gitmodules files (*).

The main reason for .gitmodules is to store submodule information which
has to be in sync with commits, such as a submodule name related to some
path where the submodule happens to be checked out in a given commit, and
also related to some config entry holding the URL to allow for fetch/pull.
The idea is that submodules have an identity in the supermodule (in contrast
to files in git), such that related configuration keeps valid when moving
submodules around. This needs simultanous adjusting the path attribute in
.gitmodules when a submodule is moved.

Josef

(*) IMHO, it would be far better if such project meta/policy information could
be in its own history (e.g. branch "gitconfig" to allow for easy propagation
at clone/fetch time). However, any such configuration should need
explicit interaction by the user to take over project config into the
local git config (e.g. via a "git config merge gitconfig:config" after
inspecting via "git show gitconfig:config").

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-22 10:03                   ` Junio C Hamano
@ 2008-04-22 13:59                     ` Ping Yin
  2008-04-22 14:55                       ` Josef Weidendorfer
  2008-04-22 20:51                     ` Michele Ballabio
  2008-04-27  6:04                     ` Junio C Hamano
  2 siblings, 1 reply; 575+ messages in thread
From: Ping Yin @ 2008-04-22 13:59 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Tue, Apr 22, 2008 at 6:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Here are the topics that have been cooking.  Commits prefixed
>  with '-' are only in 'pu' while commits prefixed with '+' are
>  in 'next'.
>

>
> * py/submodule-2 (Wed Apr 16 22:19:31 2008 +0800) 1 commit
>   - git-submodule: Extract functions module_info and module_url
>
>
> I only managed to queue the first one so far.
>
>  It does not help motivating me reviewing the series that the overall tone
>  of it is to ignore .git/config more and make .gitmodules take more active
>  role, either.  I have already said number of times why that is not a good
>  idea and why it is against the overall submodule design.

I summarize junio's points that says $GIT_DIR/config is authoritative.

1. .gitmodules shouldn't be authoritative and should be just a hint
   to fill $GIT_DIR/config because

   a) url may be rewritten with different protocol, such as from
     "http://" to "git://"
   b) url may be total different between .gitmodules and
      $GIT_DIR/config

2. When going back to an old HEAD of super project and do
   "git submodule update", the url recorded in .gitmodules may be
   stale or not existent anymore, so we should refer to
   $GIT_DIR/config for the right url.

3. We can record what contents we've seen in the .gitmodules, so that
   we can give users a chance to adjust what is in $GIT_DIR/config
   when we notice the entry in .gitmodules has changed.

Any others?

However, i argue the fall back strategy (say fall back to .gitmodules
when we can't find an entries in $GIT_DIR/config) doesn't break the
authority and isn't in contrast with the cases above. It just attachs
more importance to .gitmodules and can make the world better in most
cases.

For 1.a, i think we can keep these entries in .gitmodules, and use
"url.<thisurl>.insteadof = <otherurl>" to override the urls.

For 1.b, i think this is a rare case. And we can override these urls
in $GIT_DIR/config. However, in many cases, we havn't to do that.

For 2, i think it is also a rare case. And before going back, we can
override the urls in $GIT_DIR/config.

For 3, i havn't found a good way to do that. And it doesn't conflict
with the fall back strategy (say, wh

So, my conclusion

* 1.b, 2 and 3 are all rare cases, and these cases don't conflict with
  the fall back strategy

* 1.a is a usual case, and fallback + 'url insteadOf" will make things
  better

* The most common case is that most (even all) entries in .gitmodules
  are the same as entires in $GIT_DIR/config. So with fallback, we
  don't have to copy entries from .gitmodules to $GIT_DIR/config.

* And, in a central environment, i think it's common that the super
  project and sub project use the same protocol. So if we use relative
  urls in .gitmodules, when changing the url protocol the super
  project, the urls in .gitmodules needn't change and can be
  dynamically expanded with the url of the super project (Of course,
  after applying the 2nd patch of this series)


-- 
Ping Yin

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-04-19  8:19                 ` Junio C Hamano
                                     ` (2 preceding siblings ...)
  2008-04-21 16:10                   ` Brandon Casey
@ 2008-04-22 10:03                   ` Junio C Hamano
  2008-04-22 13:59                     ` Ping Yin
                                       ` (2 more replies)
  3 siblings, 3 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-04-22 10:03 UTC (permalink / raw)
  To: git

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

Note.

    Some commits on 'pu' have [comment] in front of their title, primarily
    to remind myself not to accidentally merge them to 'next' before
    issues are resolved.  They will be amended either by replacement patch
    from the author, or when the issue raised on the list gets refuted
    convincingly enough to justify the original patch (in which case only
    the comment like "[questionable???]"  will be removed without changing
    the tree of the commit).

The topics list the commits in reverse chronological order.

A rough timeline from now on.

 * Discussion and review on new feature and enhancement patch series
   begins.  Please resubmit things that you were cooking in your head
   during 1.5.5-rc period after cleaning up and retesting.

 * 1.5.6 merge window closes (2008-05-14).

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

----------------------------------------------------------------
[New Topics]

* js/rebase-i-sequencer (Mon Apr 14 02:21:09 2008 +0200) 13 commits
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.

* db/clone-in-c (Thu Apr 17 19:32:43 2008 -0400) 8 commits
 - [mess] Build in clone
 - [strdup() and other clean-ups needed] Provide API access to
   init_db()
 - [waiting for response] Add a function to set a non-default work
   tree
 - Allow for having for_each_ref() list extra refs
 - Have a constant extern refspec for "--tags"
 - Add a library function to add an alternate to the alternates file
 - Add a lockfile function to append to a file
 - Mark the list of refs to fetch as const

----------------------------------------------------------------
[Graduated to "master"]

* mk/color (Wed Apr 9 21:32:06 2008 +0200) 1 commit
 + Use color.ui variable in scripts too

* jk/remote-default-show (Wed Apr 9 11:15:51 2008 -0400) 1 commit
 + git-remote: show all remotes with "git remote show"

* jc/terminator-separator (Mon Apr 7 17:11:34 2008 -0700) 1 commit
 + log: teach "terminator" vs "separator" mode to "--pretty=format"

* py/submodule (Sat Apr 12 23:05:33 2008 +0800) 3 commits
 + builtin-status: Add tests for submodule summary
 + builtin-status: submodule summary support
 + git-submodule summary: --for-status option

* mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
 + contrib/hooks: add an example pre-auto-gc hook
 + Documentation/hooks: add pre-auto-gc hook
 + git-gc --auto: add pre-auto-gc hook

A new hook to stop "git gc --auto" from running.

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 + diff: make --dirstat binary-file safe

The current "dirstat" does totally wrong thing when the set of files
changed includes a binary one.  This uses the same similarity evaluation
code as rename heuristics uses to treat text and binary the same way.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 + sha1-lookup: make selection of 'middle' less aggressive
 + sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven, so let's prove
it or revert it by giving it a bit more exposure.

----------------------------------------------------------------
[Actively Cooking]

* pb/remote-mirror-config (Thu Apr 17 13:17:20 2008 +0200) 1 commit
 + Add a remote.*.mirror configuration option

* ho/shared (Wed Apr 16 11:34:24 2008 +0300) 1 commit
 + Make core.sharedRepository more generic

* lh/branch-merged (Fri Apr 18 18:30:15 2008 +0200) 3 commits
 + Add tests for `branch --[no-]merged`
 + git-branch.txt: compare --contains, --merged and --no-merged
 + git-branch: add support for --merged and --no-merged

* jk/fetch-status (Wed Apr 9 20:11:52 2008 -0400) 1 commit
 + git-fetch: always show status of non-tracking-ref fetches

This changes reporting behaviour of one-shot "git pull $url $branch",
which would affect long-time users in integrator role (that's you, Linus
;-).  Let's see if we hear anybody screaming.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 6 commits
 - merge: remove deprecated summary and diffstat options and config
   variables
 + merge, pull: add '--(no-)log' command line option
 + fmt-merge-msg: add '--(no-)log' options and 'merge.log' config
   variable
 + add 'merge.stat' config variable
 + merge, pull: introduce '--(no-)stat' option
 + doc: moved merge.* config variables into separate merge-config.txt

The last one needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.

* jc/lstat (Sun Mar 30 12:39:25 2008 -0700) 2 commits
 + diff-files: mark an index entry we know is up-to-date as such
 + write_index(): optimize ce_smudge_racily_clean_entry() calls with
   CE_UPTODATE

Further reduce redundant lstat(2) calls during "git status" and other
common operations.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 + "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.  There recently was a problem report that had a scent of this
issue which turned out to be a false alarm (it was about http-push which
does not do the native pack protocol optimization and the reporter was
pushing into an empty repository which needs full transfer anyway).

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 + Teach GIT-VERSION-GEN about the .git file
 + Teach git-submodule.sh about the .git file
 + Teach resolve_gitlink_ref() about the .git file
 + Add platform-independent .git "symlink"

There was a GSoC project idea to enhance "git submodule" to take advantage
of this facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was bound to
the superproject, but it appears nobody took it.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 + filter-branch.sh: support nearly proper tag name filtering

Instead of discarding annotated and/or signed tags, this keeps them and
demotes the signed ones to simply annotated.  It issues warning when it
does this demotion.  I think the behaviour is sensible.

----------------------------------------------------------------
[Dropped]

* js/decorate (Mon Apr 7 14:41:12 2008 +0100) 2 commits
 . pretty=format: Add %d to show decoration
 . decorate: use "const struct object"

Per author's lack of interest

----------------------------------------------------------------
[On Hold]

* ap/svn (Tue Apr 15 21:04:18 2008 -0400) 3 commits
 - git-svn: add documentation for --add-author-from option.
 - git-svn: Add --add-author-from option.
 - git-svn: add documentation for --use-log-author option.

Eric requested a new set of tests for this series.

* py/submodule-2 (Wed Apr 16 22:19:31 2008 +0800) 1 commit
 - git-submodule: Extract functions module_info and module_url

I only managed to queue the first one so far.

It does not help motivating me reviewing the series that the overall tone
of it is to ignore .git/config more and make .gitmodules take more active
role, either.  I have already said number of times why that is not a good
idea and why it is against the overall submodule design.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/lstat-debug (Thu Mar 27 16:56:53 2008 -0700) 1 commit
 - lstat: introduce a wrapper xlstat

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-19  8:19                 ` Junio C Hamano
  2008-04-19 14:23                   ` Johannes Schindelin
  2008-04-19 16:34                   ` Lars Hjemli
@ 2008-04-21 16:10                   ` Brandon Casey
  2008-04-22 10:03                   ` Junio C Hamano
  3 siblings, 0 replies; 575+ messages in thread
From: Brandon Casey @ 2008-04-21 16:10 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano wrote:

> * bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
>  - filter-branch.sh: support nearly proper tag name filtering
> 
> Instead of discarding signed tags, this demotes them to simply annotated,
> which is technically not that different from signed tags.

I just want to point out that this patch is not exclusively about signed
tags.

The patch is about retaining annotated tags rather than demoting them to
light-weight tag references as is done currently for _all_ annotated tags,
signed and unsigned. When rewriting signed tags, the signature is stripped
so that we don't write a tag with a bogus signature.

-brandon

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-19 16:34                   ` Lars Hjemli
@ 2008-04-20  4:08                     ` Junio C Hamano
  0 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-04-20  4:08 UTC (permalink / raw)
  To: Lars Hjemli; +Cc: git

"Lars Hjemli" <hjemli@gmail.com> writes:

> On Sat, Apr 19, 2008 at 10:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>  * lh/branch-merged (Fri Apr 18 18:30:15 2008 +0200) 3 commits
>>   - Add tests for `branch --[no-]merged`
>>   - git-branch.txt: compare --contains, --merged and --no-merged
>>   - git-branch: add support for --merged and --no-merged
>
> I notice that you moved the test script into t3201 while still adding
> t3202, which probably wasn't your intent.
>
> Would you like me to resend the patches with your fixups to tests and
> docs (and maybe even squash them into a single patch)?

Thanks, but it's easy enough for me to amend the tip of lh/branch-merged
to drop t3202 and that should be sufficient.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-19  8:19                 ` Junio C Hamano
  2008-04-19 14:23                   ` Johannes Schindelin
@ 2008-04-19 16:34                   ` Lars Hjemli
  2008-04-20  4:08                     ` Junio C Hamano
  2008-04-21 16:10                   ` Brandon Casey
  2008-04-22 10:03                   ` Junio C Hamano
  3 siblings, 1 reply; 575+ messages in thread
From: Lars Hjemli @ 2008-04-19 16:34 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sat, Apr 19, 2008 at 10:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
>  * lh/branch-merged (Fri Apr 18 18:30:15 2008 +0200) 3 commits
>   - Add tests for `branch --[no-]merged`
>   - git-branch.txt: compare --contains, --merged and --no-merged
>   - git-branch: add support for --merged and --no-merged

I notice that you moved the test script into t3201 while still adding
t3202, which probably wasn't your intent.

Would you like me to resend the patches with your fixups to tests and
docs (and maybe even squash them into a single patch)?

--
larsh

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-19  8:19                 ` Junio C Hamano
@ 2008-04-19 14:23                   ` Johannes Schindelin
  2008-04-19 16:34                   ` Lars Hjemli
                                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-04-19 14:23 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Sat, 19 Apr 2008, Junio C Hamano wrote:

> ----------------------------------------------------------------
> [On Hold]
> 
> * js/decorate (Mon Apr 7 14:41:12 2008 +0100) 2 commits
>  - pretty=format: Add %d to show decoration
>  - decorate: use "const struct object"
> 
> This has stalled, after a petered-out discussion.

I am not personally interested, but I thought that it was easy enough to 
do.  So let's just scrap it, the mailing list has it should anybody need 
it in the future.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-04-14  7:00               ` Junio C Hamano
  2008-04-15 19:23                 ` Jeff King
@ 2008-04-19  8:19                 ` Junio C Hamano
  2008-04-19 14:23                   ` Johannes Schindelin
                                     ` (3 more replies)
  1 sibling, 4 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-04-19  8:19 UTC (permalink / raw)
  To: git

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.

Caution. "next" has been rebuilt with the remaining topics on top of
"master".

A rough timeline from now on.

 * 1.5.5.1 this Sunday, with what's in 'maint' tonight.

 * Discussion and review on new feature and enhancement patch series
   begins.  Please resubmit things that you were cooking in your head
   during 1.5.5-rc period after cleaning up and retesting.

 * 1.5.6 merge window closes (2008-05-14).

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

----------------------------------------------------------------
[New Topics]

* ho/shared (Wed Apr 16 11:34:24 2008 +0300) 1 commit
 + Make core.sharedRepository more generic

Looked Ok, and will start cooking soon.

* pb/remote-mirror-config (Thu Apr 17 13:17:20 2008 +0200) 1 commit
 - Add a remote.*.mirror configuration option

I haven't gave this very careful review yet.

* ap/svn (Tue Apr 15 21:04:18 2008 -0400) 3 commits
 - git-svn: add documentation for --add-author-from option.
 - git-svn: Add --add-author-from option.
 - git-svn: add documentation for --use-log-author option.

Eric requested a new set of tests for this series.

* lh/branch-merged (Fri Apr 18 18:30:15 2008 +0200) 3 commits
 - Add tests for `branch --[no-]merged`
 - git-branch.txt: compare --contains, --merged and --no-merged
 - git-branch: add support for --merged and --no-merged

Looked Ok, and will start cooking soon.

* py/submodule-2 (Wed Apr 16 22:19:31 2008 +0800) 1 commit
 - git-submodule: Extract functions module_info and module_url

I am a bit slow reviewing this series; only managed to queue the first one
so far.

----------------------------------------------------------------
[Graduated to "master"]

----------------------------------------------------------------
[Actively Cooking]

* mk/color (Wed Apr 9 21:32:06 2008 +0200) 1 commit
 + Use color.ui variable in scripts too

* jk/remote-default-show (Wed Apr 9 11:15:51 2008 -0400) 1 commit
 + git-remote: show all remotes with "git remote show"

* jc/terminator-separator (Mon Apr 7 17:11:34 2008 -0700) 1 commit
 + log: teach "terminator" vs "separator" mode to "--pretty=format"

* jk/fetch-status (Wed Apr 9 20:11:52 2008 -0400) 1 commit
 + git-fetch: always show status of non-tracking-ref fetches

* py/submodule (Sat Apr 12 23:05:33 2008 +0800) 3 commits
 + builtin-status: Add tests for submodule summary
 + builtin-status: submodule summary support
 + git-submodule summary: --for-status option

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 6 commits
 - merge: remove deprecated summary and diffstat options and config
   variables
 + merge, pull: add '--(no-)log' command line option
 + fmt-merge-msg: add '--(no-)log' options and 'merge.log' config
   variable
 + add 'merge.stat' config variable
 + merge, pull: introduce '--(no-)stat' option
 + doc: moved merge.* config variables into separate merge-config.txt

I fixed its too-eager deprecation.  The last one needs to be held back, as
it actually removes the support for features that the main part of the
series deprecates, until 1.6.0 or later.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.

* jc/lstat (Sun Mar 30 12:39:25 2008 -0700) 2 commits
 + diff-files: mark an index entry we know is up-to-date as such
 + write_index(): optimize ce_smudge_racily_clean_entry() calls with
   CE_UPTODATE

Further reduce redundant lstat(2) calls during "git status" and other
common operations.

* mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
 + contrib/hooks: add an example pre-auto-gc hook
 + Documentation/hooks: add pre-auto-gc hook
 + git-gc --auto: add pre-auto-gc hook

A new hook to stop "git gc --auto" from running.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 + "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.  There recently was a problem report that had a scent of this
issue which turned out to be a false alarm (it was about http-push which
does not do the native pack protocol optimization and the reporter was
pushing into an empty repository which needs full transfer anyway).

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 + diff: make --dirstat binary-file safe

The current "dirstat" does totally wrong thing when the set of files
changed includes a binary one.  This uses the same similarity evaluation
code as rename heuristics uses to treat text and binary the same way.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 + Teach GIT-VERSION-GEN about the .git file
 + Teach git-submodule.sh about the .git file
 + Teach resolve_gitlink_ref() about the .git file
 + Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 + sha1-lookup: make selection of 'middle' less aggressive
 + sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven, so let's prove
it or revert it by giving it a bit more exposure.

----------------------------------------------------------------
[On Hold]

* js/decorate (Mon Apr 7 14:41:12 2008 +0100) 2 commits
 - pretty=format: Add %d to show decoration
 - decorate: use "const struct object"

This has stalled, after a petered-out discussion.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 - filter-branch.sh: support nearly proper tag name filtering

Instead of discarding signed tags, this demotes them to simply annotated,
which is technically not that different from signed tags.  There was an
objection if what this claims to do is the right thing to do to begin
with.  Also I haven't verified if it does what it claims to do.

Comments?

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* jc/rename-file-table (Fri Mar 7 14:03:19 2008 -0800) 1 commit
 - diffcore-rename: make file_table available outside exact rename
   detection

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/lstat-debug (Thu Mar 27 16:56:53 2008 -0700) 3 commits
 - lstat: introduce a wrapper xlstat

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-14  7:00               ` Junio C Hamano
@ 2008-04-15 19:23                 ` Jeff King
  2008-04-19  8:19                 ` Junio C Hamano
  1 sibling, 0 replies; 575+ messages in thread
From: Jeff King @ 2008-04-15 19:23 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Mon, Apr 14, 2008 at 12:00:50AM -0700, Junio C Hamano wrote:

> * jk/fetch-status (Wed Apr 9 20:11:52 2008 -0400) 1 commit
>  + git-fetch: always show status of non-tracking-ref fetches

I have been out of touch for a few days. My plan had been to come back
with a new version that suppressed the status on pull, but I haven't
seen anyone screaming about the change, so maybe it should just be left.

-Peff

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-04-09  9:43             ` Junio C Hamano
@ 2008-04-14  7:00               ` Junio C Hamano
  2008-04-15 19:23                 ` Jeff King
  2008-04-19  8:19                 ` Junio C Hamano
  0 siblings, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-04-14  7:00 UTC (permalink / raw)
  To: git

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.

Caution. "next" has been rebuilt with the remaining topics on top of
"master".

A rough timeline from now on.

 * Brown paper back fixes, if any, for 1.5.5.1 (2008-04-16).

 * Discussion and review on new feature and enhancement patch series
   begins.  Please resubmit things that you were cooking in your head
   during 1.5.5-rc period after cleaning up and retesting.

 * 1.5.6 merge window closes (2008-05-14).

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

----------------------------------------------------------------
[New Topics]

* mk/color (Wed Apr 9 21:32:06 2008 +0200) 1 commit
 + Use color.ui variable in scripts too

* jk/remote-default-show (Wed Apr 9 11:15:51 2008 -0400) 1 commit
 + git-remote: show all remotes with "git remote show"

* jc/terminator-separator (Mon Apr 7 17:11:34 2008 -0700) 1 commit
 + log: teach "terminator" vs "separator" mode to "--pretty=format"

* js/decorate (Mon Apr 7 14:41:12 2008 +0100) 2 commits
 - pretty=format: Add %d to show decoration
 - decorate: use "const struct object"

* jk/fetch-status (Wed Apr 9 20:11:52 2008 -0400) 1 commit
 + git-fetch: always show status of non-tracking-ref fetches

* py/submodule (Sat Apr 12 23:05:33 2008 +0800) 3 commits
 + builtin-status: Add tests for submodule summary
 + builtin-status: submodule summary support
 + git-submodule summary: --for-status option

----------------------------------------------------------------
[Graduated to "master"]


----------------------------------------------------------------
[Actively Cooking]

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 6 commits
 - merge: remove deprecated summary and diffstat options and config
   variables
 + merge, pull: add '--(no-)log' command line option
 + fmt-merge-msg: add '--(no-)log' options and 'merge.log' config
   variable
 + add 'merge.stat' config variable
 + merge, pull: introduce '--(no-)stat' option
 + doc: moved merge.* config variables into separate merge-config.txt

I fixed its too-eager deprecation.  The last one needs to be held back, as
it actually removes the support for features that the main part of the
series deprecates, until 1.6.0 or later.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.

* jc/lstat (Sun Mar 30 12:39:25 2008 -0700) 2 commits
 + diff-files: mark an index entry we know is up-to-date as such
 + write_index(): optimize ce_smudge_racily_clean_entry() calls with
   CE_UPTODATE

Further reduce redundant lstat(2) calls during "git status" and other
common operations.

* mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
 + contrib/hooks: add an example pre-auto-gc hook
 + Documentation/hooks: add pre-auto-gc hook
 + git-gc --auto: add pre-auto-gc hook

A new hook to stop "git gc --auto" from running.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 + "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.  There recently was a problem report that had a scent of this
issue which turned out to be a false alarm (it was about http-push which
does not do the native pack protocol optimization and the reporter was
pushing into an empty repository which needs full transfer anyway).

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 + diff: make --dirstat binary-file safe

The current "dirstat" does totally wrong thing when the set of files
changed includes a binary one.  This uses the same similarity evaluation
code as rename heuristics uses to treat text and binary the same way.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 + Teach GIT-VERSION-GEN about the .git file
 + Teach git-submodule.sh about the .git file
 + Teach resolve_gitlink_ref() about the .git file
 + Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 + sha1-lookup: make selection of 'middle' less aggressive
 + sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven, so let's prove
it or revert it by giving it a bit more exposure.

----------------------------------------------------------------
[On Hold]

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 - filter-branch.sh: support nearly proper tag name filtering

Instead of discarding signed tags, this demotes them to simply annotated,
which is technically not that different from signed tags.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* jc/rename-file-table (Fri Mar 7 14:03:19 2008 -0800) 1 commit
 - diffcore-rename: make file_table available outside exact rename
   detection

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/lstat-debug (Thu Mar 27 16:56:53 2008 -0700) 3 commits
 - lstat: introduce a wrapper xlstat

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-04-04 18:24           ` Junio C Hamano
  2008-04-04 20:21             ` Kristian Høgsberg
@ 2008-04-09  9:43             ` Junio C Hamano
  2008-04-14  7:00               ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-04-09  9:43 UTC (permalink / raw)
  To: git

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.

Caution. "next" has been rebuilt with the remaining topics on top of
"master".  "maint" is still for 1.5.4.X maintenance track for tonight.

A rough timeline from now on.

 * Brown paper back fixes, if any, for 1.5.5.1 (2008-04-16).

 * Discussion and review on new feature and enhancement patch series
   begins.  Please resubmit things that you were cooking in your head
   during 1.5.5-rc period after cleaning up and retesting.

 * 1.5.6 merge window closes (2008-05-14).

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

----------------------------------------------------------------
[New Topics]

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 6 commits
 - merge: remove deprecated summary and diffstat options and config
   variables
 - merge, pull: add '--(no-)log' command line option
 - fmt-merge-msg: add '--(no-)log' options and 'merge.log' config
   variable
 - add 'merge.stat' config variable
 - merge, pull: introduce '--(no-)stat' option
 - doc: moved merge.* config variables into separate merge-config.txt

I tried to fix its too-eager deprecation.  The last one needs re-review;
it should remove "these are still supported but will be removed" comments
that earlier ones add, and must be held back until 1.6.0 or later.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 - git-blame --reverse
 - builtin-blame.c: allow more than 16 parents
 - builtin-blame.c: move prepare_final() into a separate function.
 - rev-list --children
 - revision traversal: --children option

The reverse blame I talked about earlier.

* jc/lstat (Sun Mar 30 12:39:25 2008 -0700) 3 commits
 - diff-files: mark an index entry we know is up-to-date as such
 - write_index(): optimize ce_smudge_racily_clean_entry() calls with
   CE_UPTODATE
 - lstat: introduce a wrapper xlstat

Further reduce redundant lstat(2) calls during "git status" and other
common operations.

----------------------------------------------------------------
[Graduated to "master"]

* jc/rebase (Sat Mar 15 13:17:42 2008 -0700) 1 commit
 + rebase [--onto O] A B: omit needless checkout

We used to "git checkout B && git rebase A" internally to implement this,
which meant the work tree was smudged one time too many.

* gs/pretty-hexval (Fri Mar 21 10:05:06 2008 -0500) 1 commit
 + pretty.c: add %x00 format specifier.

Adds a generic "insert any byte value" to --pretty=format:<> specifier.

* jk/add-i-mode (Thu Mar 27 03:32:25 2008 -0400) 2 commits
 + add--interactive: allow user to choose mode update
 + add--interactive: ignore mode change in 'p'atch command

Allows mode change "pseudo hunk" to be staged separately.

NOTE NOTE NOTE!  It might be interesting to extend the idea of this patch
to treat "new file" as a pseudo hunk to record the much talked about
"intent to add".  That is, add a new command (or a new submode to patch
subcommand) that lets you add a file that is so far untracked, but only
with its mode and e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 which is the
blob object name for an _empty_ blob.  After such an operation is done,
"git diff" will show the new contents of the file you build in your work
tree that you _could_ commit with "git commit -a".

* fl/send-email-outside (Fri Mar 14 18:29:30 2008 +0100) 4 commits
 + send-email: Don't require to be called in a repository
 + Git.pm: Don't require repository instance for ident
 + Git.pm: Don't require a repository instance for config
 + var: Don't require to be in a git repository.

People couldn't invoke "git send-email" from outside their repositories,
but this series allows them to.

* mk/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict".

* gp/gitweb (Sat Apr 5 16:37:18 2008 +0000) 2 commits
 + gitweb: fallback to system-wide config file (fixup)
 + gitweb: fallback to system-wide config file if default config does
   not exist

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 1 commit
 + Optimize rename detection for a huge diff

This makes memory consumption of the rename detection operation for a huge
diff (that is, a change that touches many many files).  I've been running
with this for quite a while in my day-job repository without adverse
effects.

----------------------------------------------------------------
[Actively Cooking]

* mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
 + contrib/hooks: add an example pre-auto-gc hook
 + Documentation/hooks: add pre-auto-gc hook
 + git-gc --auto: add pre-auto-gc hook

A new hook to stop "git gc --auto" from running.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 + "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.  There recently was a problem report that had a scent of this
issue which turned out to be a false alarm (it was about http-push which
does not do the native pack protocol optimization and the reporter was
pushing into an empty repository which needs full transfer anyway).

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 + diff: make --dirstat binary-file safe

The current "dirstat" does totally wrong thing when the set of files
changed includes a binary one.  This uses the same similarity evaluation
code as rename heuristics uses to treat text and binary the same way.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 + Teach GIT-VERSION-GEN about the .git file
 + Teach git-submodule.sh about the .git file
 + Teach resolve_gitlink_ref() about the .git file
 + Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 + sha1-lookup: make selection of 'middle' less aggressive
 + sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven, so let's prove
it or revert it by giving it a bit more exposure.

----------------------------------------------------------------
[On Hold]

Some of these will start moving to "next", some I may have to ask for
clean-up and resubmission for further discussion.  Also the topics raised
during the 1.5.5-rc freeze period should be rebased, cleaned-up and
resubmit for discussion and review for inclusion in 1.5.6.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 - filter-branch.sh: support nearly proper tag name filtering

Instead of discarding signed tags, this demotes them to simply annotated,
which is technically not that different from signed tags.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* jc/rename-file-table (Fri Mar 7 14:03:19 2008 -0800) 1 commit
 - diffcore-rename: make file_table available outside exact rename
   detection

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-05  0:26                 ` Johannes Schindelin
@ 2008-04-05  5:51                   ` Junio C Hamano
  0 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-04-05  5:51 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Kristian Høgsberg, git

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

> On Fri, 4 Apr 2008, Junio C Hamano wrote:
>
>> Judging from the fact that we recently had to deal with the fallouts of 
>> C rewrites that happened during the 1.5.4 timeframe, I would have to say 
>> that any C rewrite of a substantial and important program needs to be 
>> cooked at least for one (or preferably two cycles, especially we are 
>> trying to have shorter cycles) in 'next'.
>
> That would mean that you'd have to merge it into 'next'.  And rather 
> sooner than later, since everything else would lead to a dragging out of 
> the timeline.

Yes, which means somebody needs to present a mergeable history rather
sooner than later, and that somebody does not have to be me ;-)

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-04 20:52               ` Junio C Hamano
@ 2008-04-05  0:26                 ` Johannes Schindelin
  2008-04-05  5:51                   ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Johannes Schindelin @ 2008-04-05  0:26 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Kristian Høgsberg, git

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1314 bytes --]

Hi,

On Fri, 4 Apr 2008, Junio C Hamano wrote:

> Kristian Høgsberg <krh@redhat.com> writes:
> 
> > ... I know I just threw it over the fence, but Daniel picked it up and 
> > got it a lot closer to working?  Did it fall through the cracks or is 
> > it just 1.5.6 material?
> 
> If I recall correctly, "a lot closer to working" happened way after 
> 1.5.5 merge window closed, so it definitely is not 1.5.5 material.
> 
> Judging from the fact that we recently had to deal with the fallouts of 
> C rewrites that happened during the 1.5.4 timeframe, I would have to say 
> that any C rewrite of a substantial and important program needs to be 
> cooked at least for one (or preferably two cycles, especially we are 
> trying to have shorter cycles) in 'next'.

That would mean that you'd have to merge it into 'next'.  And rather 
sooner than later, since everything else would lead to a dragging out of 
the timeline.

As it happens, until you called out the 'please test master' phase, I was 
running with builtin clone, and did not find it lacking.  Although I have 
to admit that I have some cleanups, and I haven't merged with Daniel in a 
long time.  And I do not do anything particularly fancy, such as shallow 
clone or shared clone.

Ciao,
Dscho "who hopes that the please-test-master phase is over soon"

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-04 20:21             ` Kristian Høgsberg
@ 2008-04-04 20:52               ` Junio C Hamano
  2008-04-05  0:26                 ` Johannes Schindelin
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-04-04 20:52 UTC (permalink / raw)
  To: Kristian Høgsberg; +Cc: git

Kristian Høgsberg <krh@redhat.com> writes:

> On Fri, 2008-04-04 at 11:24 -0700, Junio C Hamano wrote:
>> 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.
>> 
>> With a handful topics graduated to "master", we hopefully will have the
>> final 1.5.5 soon.
>
> What happened to builtin-clone?

Nothing.

> ... I know I just threw it over the fence,
> but Daniel picked it up and got it a lot closer to working?  Did it fall
> through the cracks or is it just 1.5.6 material?

If I recall correctly, "a lot closer to working" happened way after 1.5.5
merge window closed, so it definitely is not 1.5.5 material.

Judging from the fact that we recently had to deal with the fallouts of C
rewrites that happened during the 1.5.4 timeframe, I would have to say
that any C rewrite of a substantial and important program needs to be
cooked at least for one (or preferably two cycles, especially we are
trying to have shorter cycles) in 'next'.

So at this point, I optimistically say that it has a good chance of being
deeply in 'next' and all the active git people would hopefully be using
it, by the time 1.5.6 (or perhaps that is named 1.6.0, depending on what
else we will do) ships, but I cannot say much more than that.  It very
much depends on how hard the code has been scrutinized already at this
point; I haven't personally looked at it in any serious depth yet.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-04-04 18:24           ` Junio C Hamano
@ 2008-04-04 20:21             ` Kristian Høgsberg
  2008-04-04 20:52               ` Junio C Hamano
  2008-04-09  9:43             ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Kristian Høgsberg @ 2008-04-04 20:21 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Fri, 2008-04-04 at 11:24 -0700, Junio C Hamano wrote:
> 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.
> 
> With a handful topics graduated to "master", we hopefully will have
> the
> final 1.5.5 soon.

What happened to builtin-clone?  I know I just threw it over the fence,
but Daniel picked it up and got it a lot closer to working?  Did it fall
through the cracks or is it just 1.5.6 material?

Kristian

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-03-31  8:40         ` Junio C Hamano
@ 2008-04-04 18:24           ` Junio C Hamano
  2008-04-04 20:21             ` Kristian Høgsberg
  2008-04-09  9:43             ` Junio C Hamano
  0 siblings, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-04-04 18:24 UTC (permalink / raw)
  To: git

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.

With a handful topics graduated to "master", we hopefully will have the
final 1.5.5 soon.

----------------------------------------------------------------
[New Topics]

* mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
 - contrib/hooks: add an example pre-auto-gc hook
 - Documentation/hooks: add pre-auto-gc hook
 - git-gc --auto: add pre-auto-gc hook

A new hook to stop "git gc --auto" from running.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 - filter-branch.sh: support nearly proper tag name filtering

New feature, will probably be part of the release after 1.5.5

----------------------------------------------------------------
[Graduated to "master"]

* bc/mktag (Thu Mar 27 11:16:04 2008 -0500) 1 commit
 + mktag.c: improve verification of tagger field and tests

* je/cvsserver (Thu Mar 27 14:02:14 2008 -0700) 1 commit
 + Allow git-cvsserver database table name prefix to be specified.

* dd/cvsserver (Thu Mar 27 23:18:35 2008 +0100) 7 commits
 + cvsserver: Use the user part of the email in log and annotate
   results
 + cvsserver: Add test for update -p
 + cvsserver: Implement update -p (print to stdout)
 + cvsserver: Add a few tests for 'status' command
 + cvsserver: Do not include status output for subdirectories if -l
   is passed
 + cvsserver: Only print the file part of the filename in status
   header
 + cvsserver: Respond to the 'editors' and 'watchers' commands

* pb/cvsserver (Sun Mar 16 20:00:21 2008 +0100) 1 commit
 + git-cvsserver: handle change type T

* js/filter-branch (Mon Mar 31 09:14:15 2008 +0200) 2 commits
 + filter-branch: Fix renaming a directory in the tree-filter
 + filter-branch: Test renaming directories in a tree-filter

----------------------------------------------------------------
[On Hold]

* jk/add-i-mode (Thu Mar 27 03:32:25 2008 -0400) 2 commits
 + add--interactive: allow user to choose mode update
 + add--interactive: ignore mode change in 'p'atch command

New feature, will probably be part of the release after 1.5.5

* gp/gitweb (Wed Mar 26 18:11:19 2008 +0000) 1 commit
 + gitweb: fallback to system-wide config file if default config does
   not exist

New feature, will probably be part of the release after 1.5.5

* gs/pretty-hexval (Fri Mar 21 10:05:06 2008 -0500) 1 commit
 + pretty.c: add %x00 format specifier.

Adds a generic "insert any byte value" to --pretty=format:<> specifier.
New feature, will probably be part of the release after 1.5.5

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 - "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this, but because I have met no real user with shared repository
workflow who complained on this issue, I think this is not urgent.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* fl/send-email-outside (Fri Mar 14 18:29:30 2008 +0100) 4 commits
 + send-email: Don't require to be called in a repository
 + Git.pm: Don't require repository instance for ident
 + Git.pm: Don't require a repository instance for config
 + var: Don't require to be in a git repository.

People couldn't invoke "git send-email" from outside their repositories,
but this series allows them to.  I do not think it is urgent, though.
This does not look risky, even though it touches Git.pm that is shared
with other things.  This has been cooking in 'next' for some time and we
haven't heard about breakages caused by this.  Will probably be the first
thing to be merged in 'master' post 1.5.5.

* jc/rebase (Sat Mar 15 13:17:42 2008 -0700) 1 commit
 + rebase [--onto O] A B: omit needless checkout

We used to "git checkout B && git rebase A" internally to implement this,
which meant the work tree was smudged one time too many.  This is probably
a safe optimization, but it case after -rc0 and is not really a must-have
fix.  One of the first after post 1.5.5.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 - Make git-add behave more sensibly in a case-insensitive
   environment
 - When adding files to the index, add support for case-independent
   matches
 - Make unpack-tree update removed files before any updated files
 - Make branch merging aware of underlying case-insensitive
   filsystems
 - Add 'core.ignorecase' option
 - Make hash_name_lookup able to do case-independent lookups
 - Make "index_name_exists()" return the cache_entry it found
 - Move name hashing functions into a file of its own
 - Make unpack_trees_options bit flags actual bitfields

The beginning of ASCII-only case insensitive filesystem support.

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-03-28  1:45       ` Junio C Hamano
@ 2008-03-31  8:40         ` Junio C Hamano
  2008-04-04 18:24           ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-03-31  8:40 UTC (permalink / raw)
  To: git

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.

----------------------------------------------------------------
[New Topics]

* bc/mktag (Thu Mar 27 11:16:04 2008 -0500) 1 commit
 + mktag.c: improve verification of tagger field and tests

This is not very urgent but not complex nor risky enough to be worth
holding back.  Will merge before 1.5.5.

* je/cvsserver (Thu Mar 27 14:02:14 2008 -0700) 1 commit
 + Allow git-cvsserver database table name prefix to be specified.

The changes seem clean; even though this is a new _feature_, I am inclined
to merge this in 1.5.5.  Testing by interested parties are encouraged.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 - filter-branch.sh: support nearly proper tag name filtering

New feature, will probably be part of the release after 1.5.5

* js/filter-branch (Mon Mar 31 09:14:15 2008 +0200) 2 commits
 + filter-branch: Fix renaming a directory in the tree-filter
 + filter-branch: Test renaming directories in a tree-filter

Fix for 1.5.5; I ran out of time this weekend to merge this.

----------------------------------------------------------------
[Graduated to "master"]

* mb/prune (Mon Mar 24 23:20:51 2008 -0700) 4 commits
 + builtin-prune: protect objects listed on the command line
 + builtin-prune.c: use parse_options()
 + Add tests for git-prune
 + parse-options.c: introduce OPT_DATE

"git prune $this $that" lost its ability to protect $this and $that from
getting pruned when it was rewritten in C; this attempts to resurrect it.
This maybe is 1.5.5 material.

----------------------------------------------------------------
[Actively cooking]

* dd/cvsserver (Thu Mar 27 23:18:35 2008 +0100) 7 commits
 + cvsserver: Use the user part of the email in log and annotate
   results
 + cvsserver: Add test for update -p
 + cvsserver: Implement update -p (print to stdout)
 + cvsserver: Add a few tests for 'status' command
 + cvsserver: Do not include status output for subdirectories if -l
   is passed
 + cvsserver: Only print the file part of the filename in status
   header
 + cvsserver: Respond to the 'editors' and 'watchers' commands

The changes seem clean and should affect only locking related client
commands, so even though this is a new _feature_, I am inclined to merge
this in 1.5.5.  Testing by interested parties are encouraged.

* pb/cvsserver (Sun Mar 16 20:00:21 2008 +0100) 1 commit
 + git-cvsserver: handle change type T

This should be 1.5.5 material.

----------------------------------------------------------------
[On Hold]

* jk/add-i-mode (Thu Mar 27 03:32:25 2008 -0400) 2 commits
 + add--interactive: allow user to choose mode update
 + add--interactive: ignore mode change in 'p'atch command

New feature, will probably be part of the release after 1.5.5

* gp/gitweb (Wed Mar 26 18:11:19 2008 +0000) 1 commit
 + gitweb: fallback to system-wide config file if default config does
   not exist

New feature, will probably be part of the release after 1.5.5

* gs/pretty-hexval (Fri Mar 21 10:05:06 2008 -0500) 1 commit
 + pretty.c: add %x00 format specifier.

Adds a generic "insert any byte value" to --pretty=format:<> specifier.
New feature, will probably be part of the release after 1.5.5

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 - "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this, but because I have met no real user with shared repository
workflow who complained on this issue, I think this is not urgent.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* fl/send-email-outside (Fri Mar 14 18:29:30 2008 +0100) 4 commits
 + send-email: Don't require to be called in a repository
 + Git.pm: Don't require repository instance for ident
 + Git.pm: Don't require a repository instance for config
 + var: Don't require to be in a git repository.

People couldn't invoke "git send-email" from outside their repositories,
but this series allows them to.  I do not think it is urgent, though.
This does not look risky, even though it touches Git.pm that is shared
with other things.  This has been cooking in 'next' for some time and we
haven't heard about breakages caused by this.  Will probably be the first
thing to be merged in 'master' post 1.5.5.

* jc/rebase (Sat Mar 15 13:17:42 2008 -0700) 1 commit
 + rebase [--onto O] A B: omit needless checkout

We used to "git checkout B && git rebase A" internally to implement this,
which meant the work tree was smudged one time too many.  This is probably
a safe optimization, but it case after -rc0 and is not really a must-have
fix.  One of the first after post 1.5.5.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 - Make git-add behave more sensibly in a case-insensitive
   environment
 - When adding files to the index, add support for case-independent
   matches
 - Make unpack-tree update removed files before any updated files
 - Make branch merging aware of underlying case-insensitive
   filsystems
 - Add 'core.ignorecase' option
 - Make hash_name_lookup able to do case-independent lookups
 - Make "index_name_exists()" return the cache_entry it found
 - Move name hashing functions into a file of its own
 - Make unpack_trees_options bit flags actual bitfields

The beginning of ASCII-only case insensitive filesystem support.

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-03-23 10:08     ` Junio C Hamano
                         ` (2 preceding siblings ...)
  2008-03-23 21:06       ` Govind Salinas
@ 2008-03-28  1:45       ` Junio C Hamano
  2008-03-31  8:40         ` Junio C Hamano
  3 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-03-28  1:45 UTC (permalink / raw)
  To: git

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.

----------------------------------------------------------------
[New Topics]

* dd/cvsserver (Thu Mar 27 23:18:35 2008 +0100) 7 commits
 - cvsserver: Use the user part of the email in log and annotate
   results
 - cvsserver: Add test for update -p
 - cvsserver: Implement update -p (print to stdout)
 - cvsserver: Add a few tests for 'status' command
 - cvsserver: Do not include status output for subdirectories if -l
   is passed
 - cvsserver: Only print the file part of the filename in status
   header
 - cvsserver: Respond to the 'editors' and 'watchers' commands

The changes seem clean and should affect only locking related client
commands, so even though this is a new _feature_, I am inclined to merge
this in 1.5.5.  Testing by interested parties are encouraged.

* mb/prune (Mon Mar 24 23:20:51 2008 -0700) 4 commits
 + builtin-prune: protect objects listed on the command line
 + builtin-prune.c: use parse_options()
 + Add tests for git-prune
 + parse-options.c: introduce OPT_DATE

"git prune $this $that" lost its ability to protect $this and $that from
getting pruned when it was rewritten in C; this attempts to resurrect it.
This maybe is 1.5.5 material.

* jk/add-i-mode (Thu Mar 27 03:32:25 2008 -0400) 2 commits
 + add--interactive: allow user to choose mode update
 + add--interactive: ignore mode change in 'p'atch command

New feature, will probably be part of the release after 1.5.5

* gp/gitweb (Wed Mar 26 18:11:19 2008 +0000) 1 commit
 + gitweb: fallback to system-wide config file if default config does
   not exist

New feature, will probably be part of the release after 1.5.5

----------------------------------------------------------------
[On Hold]

* gs/pretty-hexval (Fri Mar 21 10:05:06 2008 -0500) 1 commit
 + pretty.c: add %x00 format specifier.

Adds a generic "insert any byte value" to --pretty=format:<> specifier.
New feature, will probably be part of the release after 1.5.5

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 - "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this, but because I have met no real user with shared repository
workflow who complained on this issue, I think this is not urgent.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* fl/send-email-outside (Fri Mar 14 18:29:30 2008 +0100) 4 commits
 + send-email: Don't require to be called in a repository
 + Git.pm: Don't require repository instance for ident
 + Git.pm: Don't require a repository instance for config
 + var: Don't require to be in a git repository.

People couldn't invoke "git send-email" from outside their repositories,
but this series allows them to.  I do not think it is urgent, though.
This does not look risky, even though it touches Git.pm that is shared
with other things.  This has been cooking in 'next' for some time and we
haven't heard about breakages caused by this.  Will probably be the first
thing to be merged in 'master' post 1.5.5.

* jc/rebase (Sat Mar 15 13:17:42 2008 -0700) 1 commit
 + rebase [--onto O] A B: omit needless checkout

We used to "git checkout B && git rebase A" internally to implement this,
which meant the work tree was smudged one time too many.  This is probably
a safe optimization, but it case after -rc0 and is not really a must-have
fix.  One of the first after post 1.5.5.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 - Make git-add behave more sensibly in a case-insensitive
   environment
 - When adding files to the index, add support for case-independent
   matches
 - Make unpack-tree update removed files before any updated files
 - Make branch merging aware of underlying case-insensitive
   filsystems
 - Add 'core.ignorecase' option
 - Make hash_name_lookup able to do case-independent lookups
 - Make "index_name_exists()" return the cache_entry it found
 - Move name hashing functions into a file of its own
 - Make unpack_trees_options bit flags actual bitfields

The beginning of ASCII-only case insensitive filesystem support.

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-03-23 21:06       ` Govind Salinas
@ 2008-03-24  3:01         ` Junio C Hamano
  0 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-03-24  3:01 UTC (permalink / raw)
  To: Govind Salinas; +Cc: git

"Govind Salinas" <blix@sophiasuchtig.com> writes:

> I also sent out the following patch that could be put in instead of...

I had an impression that that change would break the existing output that
somebody other than you are depending on.

I personally think it is plausible that everybody wants the new behaviour
your patch propose, but that kind of change is not appropriate for 1.5.5
cycle (might be Ok for 1.6.0 after we see agreements on the list), and
definitely not something we would want to apply after -rc0.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-03-23 17:15         ` Junio C Hamano
@ 2008-03-23 22:34           ` Samuel Tardieu
  0 siblings, 0 replies; 575+ messages in thread
From: Samuel Tardieu @ 2008-03-23 22:34 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

>>>>> "Junio" == Junio C Hamano <gitster@pobox.com> writes:

Junio> Do you mean 6bf4f1b (format-patch: generate MIME header as
Junio> needed even when there is format.header, 2008-03-14)?

Yup. I hadn't seen it was in master and main already :)

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-03-23 10:08     ` Junio C Hamano
  2008-03-23 12:00       ` Samuel Tardieu
  2008-03-23 12:39       ` Steffen Prohaska
@ 2008-03-23 21:06       ` Govind Salinas
  2008-03-24  3:01         ` Junio C Hamano
  2008-03-28  1:45       ` Junio C Hamano
  3 siblings, 1 reply; 575+ messages in thread
From: Govind Salinas @ 2008-03-23 21:06 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sun, Mar 23, 2008 at 5:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>  * gs/pretty-hexval (Fri Mar 21 10:05:06 2008 -0500) 1 commit
>   + pretty.c: add %x00 format specifier.
>
>  Adds a generic "insert any byte value" to --pretty=format:<> specifier.
>
I also sent out the following patch that could be put in instead of or in
addition to this one.  The both solve my problem in different ways.

Thanks,
Govind.

---
From: Govind Salinas <blix@sophiasuchtig.com>
Date: Sun, 23 Mar 2008 16:02:11 -0500
Subject: [PATCH] log-tree.c:  Make log_tree_diff_flush() honor line_termination.

Signed-off-by: Govind Salinas <blix@sophiasuchtig.com>
---
 log-tree.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/log-tree.c b/log-tree.c
index 608f697..5f55683 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -338,7 +338,7 @@ int log_tree_diff_flush(struct rev_info *opt)
 			int pch = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_PATCH;
 			if ((pch & opt->diffopt.output_format) == pch)
 				printf("---");
-			putchar('\n');
+			putchar(opt->diffopt.line_termination);
 		}
 	}
 	diff_flush(&opt->diffopt);
-- 
1.5.4.4.550.g77e21.dirty

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-03-23 12:39       ` Steffen Prohaska
@ 2008-03-23 17:37         ` Junio C Hamano
  0 siblings, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-03-23 17:37 UTC (permalink / raw)
  To: Steffen Prohaska; +Cc: git

Steffen Prohaska <prohaska@zib.de> writes:

> The merge test passes for me (on hfs+).  The "git mv" test still fails;
> Linus made clear that "git mv" is not yet fixed.

I was actually talking about the case with your patch applied to t0050 on
case sensitive systems.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-03-23 12:00       ` Samuel Tardieu
@ 2008-03-23 17:15         ` Junio C Hamano
  2008-03-23 22:34           ` Samuel Tardieu
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-03-23 17:15 UTC (permalink / raw)
  To: Samuel Tardieu; +Cc: git

Samuel Tardieu <sam@rfc1149.net> writes:

> I don't see your MIME/Content-Type fix in the list (adding the
> required headers even in presence of user headers). Did I overlook
> something?

Do you mean 6bf4f1b (format-patch: generate MIME header as needed even
when there is format.header, 2008-03-14)?

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-03-23 10:08     ` Junio C Hamano
  2008-03-23 12:00       ` Samuel Tardieu
@ 2008-03-23 12:39       ` Steffen Prohaska
  2008-03-23 17:37         ` Junio C Hamano
  2008-03-23 21:06       ` Govind Salinas
  2008-03-28  1:45       ` Junio C Hamano
  3 siblings, 1 reply; 575+ messages in thread
From: Steffen Prohaska @ 2008-03-23 12:39 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sun, 23 Mar 2008, Junio C Hamano wrote:

> * lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
>  - Make git-add behave more sensibly in a case-insensitive
>    environment
>  - When adding files to the index, add support for case-independent
>    matches
>  - Make unpack-tree update removed files before any updated files
>  - Make branch merging aware of underlying case-insensitive
>    filsystems
>  - Add 'core.ignorecase' option
>  - Make hash_name_lookup able to do case-independent lookups
>  - Make "index_name_exists()" return the cache_entry it found
>  - Move name hashing functions into a file of its own
>  - Make unpack_trees_options bit flags actual bitfields
> 
> The beginning of ASCII-only case insensitive filesystem support.  It is
> not complete yet, though.  E.g. if you enable core.ignorecase in t0050,
> the merge test fails.

The merge test passes for me (on hfs+).  The "git mv" test still fails;
Linus made clear that "git mv" is not yet fixed.

            Steffen

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-03-23 10:08     ` Junio C Hamano
@ 2008-03-23 12:00       ` Samuel Tardieu
  2008-03-23 17:15         ` Junio C Hamano
  2008-03-23 12:39       ` Steffen Prohaska
                         ` (2 subsequent siblings)
  3 siblings, 1 reply; 575+ messages in thread
From: Samuel Tardieu @ 2008-03-23 12:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

I don't see your MIME/Content-Type fix in the list (adding the
required headers even in presence of user headers). Did I overlook
something?

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-03-14  9:00   ` Junio C Hamano
@ 2008-03-23 10:08     ` Junio C Hamano
  2008-03-23 12:00       ` Samuel Tardieu
                         ` (3 more replies)
  0 siblings, 4 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-03-23 10:08 UTC (permalink / raw)
  To: git

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.

Since we tagged -rc0, we've seen regression fixes at a reasonable rate.
At -rc1 tonight, I think we are fairly in good shape.

----------------------------------------------------------------
[New Topics]

* fl/send-email-outside (Fri Mar 14 18:29:30 2008 +0100) 4 commits
 + send-email: Don't require to be called in a repository
 + Git.pm: Don't require repository instance for ident
 + Git.pm: Don't require a repository instance for config
 + var: Don't require to be in a git repository.

People couldn't invoke "git send-email" from outside their repositories,
but this series allows them to.  I do not think it is urgent, though.
This does not look risky, even though it touches Git.pm that is shared
with other things.  This has been cooking in 'next' for some time and we
haven't heard about breakages caused by this.  Will probably be the first
thing to be merged in 'master' post 1.5.5.

* jc/rebase (Sat Mar 15 13:17:42 2008 -0700) 1 commit
 + rebase [--onto O] A B: omit needless checkout

We used to "git checkout B && git rebase A" internally to implement this,
which meant the work tree was smudged one time too many.  This is probably
a safe optimization, but it case after -rc0 and is not really a must-have
fix.  One of the first after post 1.5.5.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 - Make git-add behave more sensibly in a case-insensitive
   environment
 - When adding files to the index, add support for case-independent
   matches
 - Make unpack-tree update removed files before any updated files
 - Make branch merging aware of underlying case-insensitive
   filsystems
 - Add 'core.ignorecase' option
 - Make hash_name_lookup able to do case-independent lookups
 - Make "index_name_exists()" return the cache_entry it found
 - Move name hashing functions into a file of its own
 - Make unpack_trees_options bit flags actual bitfields

The beginning of ASCII-only case insensitive filesystem support.  It is
not complete yet, though.  E.g. if you enable core.ignorecase in t0050,
the merge test fails.

* gs/pretty-hexval (Fri Mar 21 10:05:06 2008 -0500) 1 commit
 + pretty.c: add %x00 format specifier.

Adds a generic "insert any byte value" to --pretty=format:<> specifier.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 - "git push": tellme-more protocol extension

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this, but because I have met no real user with shared repository
workflow who complained on this issue, I think this is not urgent.

----------------------------------------------------------------
[Graduated to 'master']

* cc/help (Thu Mar 13 19:15:30 2008 -0700) 6 commits
 + Documentation/git-help: typofix
 + help: warn if specified 'man.viewer' is unsupported, instead of
   erroring out
 + Documentation: help: explain 'man.viewer' multiple values
 + help: implement multi-valued "man.viewer" config option
 + Documentation: help: describe 'man.viewer' config variable
 + help: add "man.viewer" config var to use "woman" or "konqueror"

There are some leftover bits posted after -rc0, but I think they can
wait.

* db/diff-to-fp (Mon Mar 10 13:58:26 2008 -0400) 2 commits
 + wt-status.c: no need for dup() dance anymore
 + Write diff output to a file in struct diff_options

* py/submodule (Wed Mar 12 09:30:01 2008 +0100) 6 commits
 + git-submodule summary: fix that some "wc" flavors produce leading
   spaces
 + git-submodule summary: test
 + git-submodule summary: documentation
 + git-submodule summary: limit summary size
 + git-submodule summary: show commit summary
 + git-submodule summary: code framework

I didn't see anybody very supportive for this series, but I do not think
this regresses existing other subcommands to "git submodule", so let's see
how useful submodule users find this.  Maybe they have improvement ideas
for its output before we decide post 1.5.5 if it is a good idea to include
it in "git status" output.

* jc/makefile (Wed Mar 12 01:46:26 2008 -0700) 2 commits
 - Makefile: flatten enumeration of headers, objects and programs
 - Makefile: DIFF_OBJS is not special at all these days

I promised to do this immediately after -rc0, so this will shortly be in
'next' and then in 'master'.

* jk/portable (Wed Mar 12 17:42:43 2008 -0400) 13 commits
 + t7505: use SHELL_PATH in hook
 + t9112: add missing #!/bin/sh header
 + filter-branch: use $SHELL_PATH instead of 'sh'
 + filter-branch: don't use xargs -0
 + add NO_EXTERNAL_GREP build option
 + t6000lib: tr portability fix
 + t4020: don't use grep -a
 + add test_cmp function for test scripts
 + remove use of "tail -n 1" and "tail -1"
 + grep portability fix: don't use "-e" or "-q"
 + more tr portability test script fixes
 + t0050: perl portability fix
 + tr portability fixes

Initially triggered by Solaris porting effort but these are harmless
portability changes.  Perhaps in 1.5.5, perhaps immediately after that.

----------------------------------------------------------------
[Dropped]

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 . tests: convert "cmp" and "cmp -s" to test_cmp
 . tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
 . Additional tests to capture worktree special cases
 . Documentation: update api-builtin and api-setup
 . Make setup_git_directory() auto-setup worktree if found
 . builtin-archive: mark unused prefix "unused_prefix"
 . Completely move out worktree setup from
   setup_git_directory_gently()
 . http-push: Avoid calling setup_git_directory() twice
 . Make setup_work_tree() return new prefix
 . Make get_git_dir() and 'git rev-parse --git-dir' absolute path
 . Make sure setup_git_directory is called before accessing
   repository
 . "git read-tree -m" and the like require worktree

Every time we touch work-tree stuff we seem to have unstabilized things.
This is excluded from 'pu' for now although I still have copies.

----------------------------------------------------------------
[On Hold]

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-03-12  7:50 ` Junio C Hamano
  2008-03-12 12:18   ` Johannes Schindelin
@ 2008-03-14  9:00   ` Junio C Hamano
  2008-03-23 10:08     ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-03-14  9:00 UTC (permalink / raw)
  To: git

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.

The merge window for 1.5.5 is closed as of tonight, except for the
promised git-gui (0.10) and gitk updates, and topics still cooking in
'next', and 1.5.5-rc0 will be tagged shortly.

After that we will have quite a lot of regression fixes ahead of us, I am
afraid.  Since v1.5.4, a few commands have been reimplemented or made
built-ins (checkout, remote, merge-recursive), and these inevitably
involve "growing pains".

While I am reasonably confident that we have long caught showstopper
regressions in key features of these commands while they were cooking in
'next', I am sure there would remain regressions here and there in the
periphery.  It is unavoidable.  POSIX-only people may say "why rewrite, if
it involves this much pain", but like it or not, there are people stuck on
unfortunate platforms that cannot run scripted versions well enough.

Let's see if our regular contributors are as good at fixing their own
screw-ups as they are good at coming up with new code, and hope that we
can keep this rc cycle manageably short.  Touch wood...

----------------------------------------------------------------
[New Topics]

* jc/makefile (Wed Mar 12 01:46:26 2008 -0700) 2 commits
 - Makefile: flatten enumeration of headers, objects and programs
 - Makefile: DIFF_OBJS is not special at all these days

I promised to do this immediately after -rc0, so this will shortly be in
'next' and then in 'master'.

* jk/portable (Wed Mar 12 17:42:43 2008 -0400) 13 commits
 + t7505: use SHELL_PATH in hook
 + t9112: add missing #!/bin/sh header
 + filter-branch: use $SHELL_PATH instead of 'sh'
 + filter-branch: don't use xargs -0
 + add NO_EXTERNAL_GREP build option
 + t6000lib: tr portability fix
 + t4020: don't use grep -a
 + add test_cmp function for test scripts
 + remove use of "tail -n 1" and "tail -1"
 + grep portability fix: don't use "-e" or "-q"
 + more tr portability test script fixes
 + t0050: perl portability fix
 + tr portability fixes

Initially triggered by Solaris porting effort but these are harmless
portability changes.  Perhaps in 1.5.5, perhaps immediately after that.

----------------------------------------------------------------
[Dropped]

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 . tests: convert "cmp" and "cmp -s" to test_cmp
 . tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

----------------------------------------------------------------
[Graduated to 'master']

* ph/maint-quiltimport (Wed Mar 12 21:07:19 2008 -0700) 2 commits
 + quiltimport: fix misquoting of parsed -p<num> parameter
 + git-quiltimport: better parser to grok "enhanced" series files.

* mr/autoconf-fread (Tue Mar 11 09:48:34 2008 +0100) 1 commit
 + autoconf: Test FREAD_READS_DIRECTORIES

----------------------------------------------------------------
[Actively Cooking]

* cc/help (Thu Mar 13 19:15:30 2008 -0700) 6 commits
 + Documentation/git-help: typofix
 + help: warn if specified 'man.viewer' is unsupported, instead of
   erroring out
 + Documentation: help: explain 'man.viewer' multiple values
 + help: implement multi-valued "man.viewer" config option
 + Documentation: help: describe 'man.viewer' config variable
 + help: add "man.viewer" config var to use "woman" or "konqueror"

* db/diff-to-fp (Mon Mar 10 13:58:26 2008 -0400) 2 commits
 + wt-status.c: no need for dup() dance anymore
 + Write diff output to a file in struct diff_options

* py/submodule (Wed Mar 12 09:30:01 2008 +0100) 6 commits
 + git-submodule summary: fix that some "wc" flavors produce leading
   spaces
 + git-submodule summary: test
 + git-submodule summary: documentation
 + git-submodule summary: limit summary size
 + git-submodule summary: show commit summary
 + git-submodule summary: code framework

I didn't see anybody very supportive for this series, but I do not think
this regresses existing other subcommands to "git submodule", so let's
merge this to 'master' before 1.5.5 and see how useful submodule users
find this.

----------------------------------------------------------------
[On Hold]

* nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
 - Additional tests to capture worktree special cases
 - Documentation: update api-builtin and api-setup
 - Make setup_git_directory() auto-setup worktree if found
 - builtin-archive: mark unused prefix "unused_prefix"
 - Completely move out worktree setup from
   setup_git_directory_gently()
 - http-push: Avoid calling setup_git_directory() twice
 - Make setup_work_tree() return new prefix
 - Make get_git_dir() and 'git rev-parse --git-dir' absolute path
 - Make sure setup_git_directory is called before accessing
   repository
 - "git read-tree -m" and the like require worktree

Every time we touch work-tree stuff we seem to unstabilize; this round
seems more solid but I am still treading cautiously.  Not sure if we want
this for 1.5.5.

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-03-12  7:50 ` Junio C Hamano
@ 2008-03-12 12:18   ` Johannes Schindelin
  2008-03-14  9:00   ` Junio C Hamano
  1 sibling, 0 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-03-12 12:18 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Wed, 12 Mar 2008, Junio C Hamano wrote:

> * nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
>  - Additional tests to capture worktree special cases
>  - Documentation: update api-builtin and api-setup
>  - Make setup_git_directory() auto-setup worktree if found
>  - builtin-archive: mark unused prefix "unused_prefix"
>  - Completely move out worktree setup from
>    setup_git_directory_gently()
>  - http-push: Avoid calling setup_git_directory() twice
>  - Make setup_work_tree() return new prefix
>  - Make get_git_dir() and 'git rev-parse --git-dir' absolute path
>  - Make sure setup_git_directory is called before accessing
>    repository
>  - "git read-tree -m" and the like require worktree
> 
> Every time we touch work-tree stuff we seem to unstabilize; this round 
> seems more solid but I am still treading cautiously.  Not sure if we 
> want this for 1.5.5.

I am sure we do not want this for 1.5.5.

It is too complicated a patch series to be obviously correct, and as I 
said earlier, a few design goals are not to my liking, such as trying to 
separate git_dir from work_tree logic with a sledgehammer.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-03-09 10:46 Junio C Hamano
@ 2008-03-12  7:50 ` Junio C Hamano
  2008-03-12 12:18   ` Johannes Schindelin
  2008-03-14  9:00   ` Junio C Hamano
  0 siblings, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-03-12  7:50 UTC (permalink / raw)
  To: git

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.

----------------------------------------------------------------
[New Topics]

* cc/help (Tue Mar 11 08:51:12 2008 +0100) 3 commits
 + help: implement multi-valued "man.viewer" config option
 + Documentation: help: describe 'man.viewer' config variable
 + help: add "man.viewer" config var to use "woman" or "konqueror"

* ph/maint-quiltimport (Sat Mar 8 19:27:09 2008 +0100) 1 commit
 + git-quiltimport: better parser to grok "enhanced" series files.

* mr/autoconf-fread (Tue Mar 11 09:48:34 2008 +0100) 1 commit
 + autoconf: Test FREAD_READS_DIRECTORIES

* db/diff-to-fp (Mon Mar 10 13:58:26 2008 -0400) 2 commits
 - wt-status.c: no need for dup() dance anymore
 - Write diff output to a file in struct diff_options

All of these can be in 1.5.5 (they may or may not need fix-ups); let's
close the 1.5.5 merge window now with these.

----------------------------------------------------------------
[Graduated to 'master']

* lt/unpack-trees (Fri Mar 7 13:48:40 2008 -0800) 10 commits
 + unpack_trees(): minor memory leak fix in unused destination index
 + Make 'unpack_trees()' have a separate source and destination index
 + Make 'unpack_trees()' take the index to work on as an argument
 + Add 'const' where appropriate to index handling functions
 + Fix tree-walking compare_entry() in the presense of --prefix
 + Move 'unpack_trees()' over to 'traverse_trees()' interface
 + Make 'traverse_trees()' traverse conflicting DF entries in
   parallel
 + Add return value to 'traverse_tree()' callback
 + Make 'traverse_tree()' use linked structure rather than 'const
   char *base'
 + Add 'df_name_compare()' helper function

* js/remote (Sat Mar 8 23:40:42 2008 +0100) 9 commits
 + "remote update": print remote name being fetched from
 + builtin remote rm: remove symbolic refs, too
 + remote: fix "update [group...]"
 + remote show: Clean up connection correctly if object fetch wasn't
   done
 + builtin-remote: prune remotes correctly that were added with --
   mirror
 + Make git-remote a builtin
 + Test "git remote show" and "git remote prune"
 + parseopt: add flag to stop on first non option
 + path-list: add functions to work with unsorted lists

----------------------------------------------------------------
[Actively Cooking]

* py/submodule (Tue Mar 11 21:52:19 2008 +0800) 5 commits
 + git-submodule summary: test
 + git-submodule summary: documentation
 + git-submodule summary: limit summary size
 + git-submodule summary: show commit summary
 + git-submodule summary: code framework

I didn't see anybody very supportive for this series, but I do not think
this regresses existing other subcommands to "git submodule", so let's
merge this to 'master' before 1.5.5 and see how useful submodule users
find this.

----------------------------------------------------------------
[On Hold]

* nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
 - Additional tests to capture worktree special cases
 - Documentation: update api-builtin and api-setup
 - Make setup_git_directory() auto-setup worktree if found
 - builtin-archive: mark unused prefix "unused_prefix"
 - Completely move out worktree setup from
   setup_git_directory_gently()
 - http-push: Avoid calling setup_git_directory() twice
 - Make setup_work_tree() return new prefix
 - Make get_git_dir() and 'git rev-parse --git-dir' absolute path
 - Make sure setup_git_directory is called before accessing
   repository
 - "git read-tree -m" and the like require worktree

Every time we touch work-tree stuff we seem to unstabilize; this round
seems more solid but I am still treading cautiously.  Not sure if we want
this for 1.5.5.

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
@ 2008-03-09 10:46 Junio C Hamano
  2008-03-12  7:50 ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-03-09 10:46 UTC (permalink / raw)
  To: git

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.

----------------------------------------------------------------
[New Topics]

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

Just my toy at this moment.

----------------------------------------------------------------
[Graduated to 'master']

* dp/clean-fix (Fri Mar 7 21:56:56 2008 -0800) 7 commits
 + git-clean: add tests for relative path
 + git-clean: correct printing relative path
 + Make private quote_path() in wt-status.c available as
   quote_path_relative()
 + Revert part of d089eba (setup: sanitize absolute and funny paths
   in get_pathspec())
 + Revert part of 1abf095 (git-add: adjust to the get_pathspec()
   changes)
 + Revert part of 744dacd (builtin-mv: minimum fix to avoid losing
   files)
 + get_pathspec(): die when an out-of-tree path is given

* sp/fetch-optim (Mon Mar 3 22:27:40 2008 -0500) 11 commits
 + Teach git-fetch to exploit server side automatic tag following
 + Teach fetch-pack/upload-pack about --include-tag
 + git-pack-objects: Automatically pack annotated tags if object was
   packed
 + Teach git-fetch to grab a tag at the same time as a commit
 + Make git-fetch follow tags we already have objects for sooner
 + Teach upload-pack to log the received need lines to an fd
 + Free the path_lists used to find non-local tags in git-fetch
 + Allow builtin-fetch's find_non_local_tags to append onto a list
 + Ensure tail pointer gets setup correctly when we fetch HEAD only
 + Remove unnecessary delaying of free_refs(ref_map) in builtin-fetch
 + Remove unused variable in builtin-fetch find_non_local_tags

* ml/submodule-add-existing (Tue Mar 4 20:15:02 2008 -0500) 1 commit
 + git-submodule - Allow adding a submodule in-place

* jc/describe-always (Sun Mar 2 08:51:57 2008 -0800) 1 commit
 + describe --always: fall back to showing an abbreviated object name

* aw/maint-shortlog-blank-lines (Wed Mar 5 14:24:10 2008 +0000) 1 commit
 + shortlog: take the first populated line of the description

* jn/gitweb-pickaxe (Wed Mar 5 09:31:55 2008 +0100) 1 commit
 + gitweb: Fix and simplify pickaxe search

* cr/reset-parseopt (Tue Mar 4 23:11:34 2008 +0100) 1 commit
 + Make builtin-reset.c use parse_options.

* mr/compat-snprintf (Wed Mar 5 16:46:13 2008 +0100) 1 commit
 + Add compat/snprintf.c for systems that return bogus

* jc/am (Tue Mar 4 00:25:06 2008 -0800) 3 commits
 + am: --rebasing
 + am: remove support for -d .dotest
 + am: read from the right mailbox when started from a subdirectory

* ph/parseopt (Sun Mar 2 11:35:56 2008 +0100) 2 commits
 + parse-options: new option type to treat an option-like parameter
   as an argument.
 + parse-opt: bring PARSE_OPT_HIDDEN and NONEG to git-rev-parse --
   parseopt

----------------------------------------------------------------
[Actively Cooking]

* lt/unpack-trees (Fri Mar 7 13:48:40 2008 -0800) 10 commits
 + unpack_trees(): minor memory leak fix in unused destination index
 + Make 'unpack_trees()' have a separate source and destination index
 + Make 'unpack_trees()' take the index to work on as an argument
 + Add 'const' where appropriate to index handling functions
 + Fix tree-walking compare_entry() in the presense of --prefix
 + Move 'unpack_trees()' over to 'traverse_trees()' interface
 + Make 'traverse_trees()' traverse conflicting DF entries in
   parallel
 + Add return value to 'traverse_tree()' callback
 + Make 'traverse_tree()' use linked structure rather than 'const
   char *base'
 + Add 'df_name_compare()' helper function

* js/remote (Sat Mar 8 23:40:42 2008 +0100) 8 commits
 + builtin remote rm: remove symbolic refs, too
 + remote: fix "update [group...]"
 + remote show: Clean up connection correctly if object fetch wasn't
   done
 + builtin-remote: prune remotes correctly that were added with --
   mirror
 + Make git-remote a builtin
 + Test "git remote show" and "git remote prune"
 + parseopt: add flag to stop on first non option
 + path-list: add functions to work with unsorted lists

Slated for 1.5.5, but probably needs more time to mature.

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* py/submodule (Sat Mar 8 02:27:19 2008 +0800) 4 commits
 - git-submodule summary: documentation
 - git-submodule summary: limit summary size
 - git-submodule summary: show commit summary
 - git-submodule summary: code framework

Looking better.  With tests it should be mergeable to 'next'.

----------------------------------------------------------------
[On Hold]

* nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
 - Additional tests to capture worktree special cases
 - Documentation: update api-builtin and api-setup
 - Make setup_git_directory() auto-setup worktree if found
 - builtin-archive: mark unused prefix "unused_prefix"
 - Completely move out worktree setup from
   setup_git_directory_gently()
 - http-push: Avoid calling setup_git_directory() twice
 - Make setup_work_tree() return new prefix
 - Make get_git_dir() and 'git rev-parse --git-dir' absolute path
 - Make sure setup_git_directory is called before accessing
   repository
 - "git read-tree -m" and the like require worktree

Every time we touch work-tree stuff we seem to unstabilize; this round
seems more solid but I am still treading cautiously.  Not sure if we want
this for 1.5.5.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 5 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive
 + expose a helper function peel_to_type().
 + merge-recursive: split low-level merge functions out.

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-03-06  5:49                     ` Junio C Hamano
  2008-03-06 17:01                       ` Johannes Schindelin
@ 2008-03-08  9:38                       ` Junio C Hamano
  1 sibling, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-03-08  9:38 UTC (permalink / raw)
  To: git

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.

----------------------------------------------------------------
[New Topics]

* lt/unpack-trees (Fri Mar 7 13:48:40 2008 -0800) 10 commits
 - unpack_trees(): minor memory leak fix in unused destination index
 - Make 'unpack_trees()' have a separate source and destination index
 - Make 'unpack_trees()' take the index to work on as an argument
 - Add 'const' where appropriate to index handling functions
 - Fix tree-walking compare_entry() in the presense of --prefix
 - Move 'unpack_trees()' over to 'traverse_trees()' interface
 - Make 'traverse_trees()' traverse conflicting DF entries in
   parallel
 - Add return value to 'traverse_tree()' callback
 - Make 'traverse_tree()' use linked structure rather than 'const
   char *base'
 - Add 'df_name_compare()' helper function

* dp/clean-fix (Fri Mar 7 21:56:56 2008 -0800) 7 commits
 + git-clean: add tests for relative path
 + git-clean: correct printing relative path
 + Make private quote_path() in wt-status.c available as
   quote_path_relative()
 + Revert part of d089eba (setup: sanitize absolute and funny paths
   in get_pathspec())
 + Revert part of 1abf095 (git-add: adjust to the get_pathspec()
   changes)
 + Revert part of 744dacd (builtin-mv: minimum fix to avoid losing
   files)
 + get_pathspec(): die when an out-of-tree path is given

----------------------------------------------------------------
[Graduated to 'master']

* ar/sgid-bsd (Wed Mar 5 00:15:39 2008 +0100) 1 commit
 + Do not use GUID on dir in git init --shared=all on FreeBSD

* cc/run-command (Wed Mar 5 08:35:16 2008 +0100) 1 commit
 + run-command: Redirect stderr to a pipe before redirecting stdout
   to stderr

* cb/mergetool (Thu Feb 21 23:31:56 2008 +0000) 4 commits
 + Add a very basic test script for git mergetool
 + Teach git mergetool to use custom commands defined at config time
 + Changed an internal variable of mergetool to support custom
   commands
 + Tidy up git mergetool's backup file behaviour

The series looked Ok, and Ted seems to be busy, so I queued them myself.
Hopefully nobody would see breakages and we can have this in 1.5.5.
To give it a wider exposure early, I am merging it to 'master' now.

* dc/format-pretty (Sun Mar 2 17:05:53 2008 +0800) 3 commits
 + log/show/whatchanged: introduce format.pretty configuration
 + specify explicit "--pretty=medium" with `git log/show/whatchanged`
 + whatchanged documentation: share description of --pretty with
   others

* js/reflog-delete (Sun Mar 2 14:58:51 2008 -0600) 13 commits
 + t3903-stash.sh: Add tests for new stash commands drop and pop
 + git-reflog.txt: Document new commands --updateref and --rewrite
 + t3903-stash.sh: Add missing '&&' to body of testcase
 + Merge commit '74359821' into js/reflog-delete
 + git-stash: add new 'pop' subcommand
 + git-stash: add new 'drop' subcommand
 + git-reflog: add option --updateref to write the last reflog sha1
   into the ref
 + refs.c: make close_ref() and commit_ref() non-static
 + git-reflog: add option --rewrite to update reflog entries while
   expiring
 + reflog-delete: parse standard reflog options
 + Merge branch 'bc/reflog-fix' into js/reflog-delete
 + builtin-reflog.c: fix typo that accesses an unset variable
 + Teach "git reflog" a subcommand to delete single entries

----------------------------------------------------------------
[Actively Cooking]

* js/remote (Tue Mar 4 11:23:53 2008 +0000) 7 commits
 + remote: fix "update [group...]"
 + remote show: Clean up connection correctly if object fetch wasn't
   done
 + builtin-remote: prune remotes correctly that were added with --
   mirror
 + Make git-remote a builtin
 + Test "git remote show" and "git remote prune"
 + parseopt: add flag to stop on first non option
 + path-list: add functions to work with unsorted lists

Slated for 1.5.5, but probably needs more time to mature.

* sp/fetch-optim (Mon Mar 3 22:27:40 2008 -0500) 11 commits
 + Teach git-fetch to exploit server side automatic tag following
 + Teach fetch-pack/upload-pack about --include-tag
 + git-pack-objects: Automatically pack annotated tags if object was
   packed
 + Teach git-fetch to grab a tag at the same time as a commit
 + Make git-fetch follow tags we already have objects for sooner
 + Teach upload-pack to log the received need lines to an fd
 + Free the path_lists used to find non-local tags in git-fetch
 + Allow builtin-fetch's find_non_local_tags to append onto a list
 + Ensure tail pointer gets setup correctly when we fetch HEAD only
 + Remove unnecessary delaying of free_refs(ref_map) in builtin-fetch
 + Remove unused variable in builtin-fetch find_non_local_tags

Slated for 1.5.5, but probably needs more time to mature.

* ml/submodule-add-existing (Tue Mar 4 20:15:02 2008 -0500) 1 commit
 + git-submodule - Allow adding a submodule in-place

* jc/describe-always (Sun Mar 2 08:51:57 2008 -0800) 1 commit
 + describe --always: fall back to showing an abbreviated object name

* aw/maint-shortlog-blank-lines (Wed Mar 5 14:24:10 2008 +0000) 1 commit
 + shortlog: take the first populated line of the description

* jn/gitweb-pickaxe (Wed Mar 5 09:31:55 2008 +0100) 1 commit
 + gitweb: Fix and simplify pickaxe search

* cr/reset-parseopt (Tue Mar 4 23:11:34 2008 +0100) 1 commit
 + Make builtin-reset.c use parse_options.

* mr/compat-snprintf (Wed Mar 5 16:46:13 2008 +0100) 1 commit
 + Add compat/snprintf.c for systems that return bogus

The above 6 topics should be fine for 1.5.5 after cooking for a few more
days in 'next'.

* jc/am (Tue Mar 4 00:25:06 2008 -0800) 3 commits
 + am: --rebasing
 + am: remove support for -d .dotest
 + am: read from the right mailbox when started from a subdirectory

The first one is probably a good fix to what is already in 'master';
after the entire series, bash completion can tell between rebase and
am in progress.  Probably Ok for 1.5.5.

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* ph/parseopt (Sun Mar 2 11:35:56 2008 +0100) 2 commits
 + parse-options: new option type to treat an option-like parameter
   as an argument.
 + parse-opt: bring PARSE_OPT_HIDDEN and NONEG to git-rev-parse --
   parseopt

* py/submodule (Sat Mar 8 02:27:19 2008 +0800) 4 commits
 - git-submodule summary: documentation
 - git-submodule summary: limit summary size
 - git-submodule summary: show commit summary
 - git-submodule summary: code framework

----------------------------------------------------------------
[On Hold]

* nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
 - Additional tests to capture worktree special cases
 - Documentation: update api-builtin and api-setup
 - Make setup_git_directory() auto-setup worktree if found
 - builtin-archive: mark unused prefix "unused_prefix"
 - Completely move out worktree setup from
   setup_git_directory_gently()
 - http-push: Avoid calling setup_git_directory() twice
 - Make setup_work_tree() return new prefix
 - Make get_git_dir() and 'git rev-parse --git-dir' absolute path
 - Make sure setup_git_directory is called before accessing
   repository
 - "git read-tree -m" and the like require worktree

Every time we touch work-tree stuff we seem to unstabilize; this round
seems more solid but I am still treading cautiously.  Not sure if we want
this for 1.5.5.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 5 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive
 + expose a helper function peel_to_type().
 + merge-recursive: split low-level merge functions out.

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-03-06  5:49                     ` Junio C Hamano
@ 2008-03-06 17:01                       ` Johannes Schindelin
  2008-03-08  9:38                       ` Junio C Hamano
  1 sibling, 0 replies; 575+ messages in thread
From: Johannes Schindelin @ 2008-03-06 17:01 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Wed, 5 Mar 2008, Junio C Hamano wrote:

> [On Hold]
> 
> * nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
>  - Additional tests to capture worktree special cases
>  - Documentation: update api-builtin and api-setup
>  - Make setup_git_directory() auto-setup worktree if found
>  - builtin-archive: mark unused prefix "unused_prefix"
>  - Completely move out worktree setup from
>    setup_git_directory_gently()
>  - http-push: Avoid calling setup_git_directory() twice
>  - Make setup_work_tree() return new prefix
>  - Make get_git_dir() and 'git rev-parse --git-dir' absolute path
>  - Make sure setup_git_directory is called before accessing
>    repository
>  - "git read-tree -m" and the like require worktree
> 
> Every time we touch work-tree stuff we seem to unstabilize; this round 
> seems more solid but I am still treading cautiously.  Not sure if we 
> want this for 1.5.5.

I think this needs a much closer look.  Being as large as the patch series 
is right now does not help at all.  And I am awfully short on time, 
_especially_ since I get sidetracked by things that are more fun, such as 
strbuf_vaddf().

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-03-03  2:06                   ` Junio C Hamano
@ 2008-03-06  5:49                     ` Junio C Hamano
  2008-03-06 17:01                       ` Johannes Schindelin
  2008-03-08  9:38                       ` Junio C Hamano
  0 siblings, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-03-06  5:49 UTC (permalink / raw)
  To: git

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.

----------------------------------------------------------------
[New Topics]

Most of these are for 1.5.5 but parked in 'next' or 'pu' for now.

* ml/submodule-add-existing (Tue Mar 4 20:15:02 2008 -0500) 1 commit
 + git-submodule - Allow adding a submodule in-place

* jc/describe-always (Sun Mar 2 08:51:57 2008 -0800) 1 commit
 + describe --always: fall back to showing an abbreviated object name

* aw/maint-shortlog-blank-lines (Wed Mar 5 14:24:10 2008 +0000) 1 commit
 + shortlog: take the first populated line of the description

* ar/sgid-bsd (Wed Mar 5 00:15:39 2008 +0100) 1 commit
 + Do not use GUID on dir in git init --shared=all on FreeBSD

* jn/gitweb-pickaxe (Wed Mar 5 09:31:55 2008 +0100) 1 commit
 + gitweb: Fix and simplify pickaxe search

* cr/reset-parseopt (Tue Mar 4 23:11:34 2008 +0100) 1 commit
 + Make builtin-reset.c use parse_options.

* mr/compat-snprintf (Wed Mar 5 16:46:13 2008 +0100) 1 commit
 + Add compat/snprintf.c for systems that return bogus

* jc/am (Tue Mar 4 00:25:06 2008 -0800) 3 commits
 + am: --rebasing
 + am: remove support for -d .dotest
 + am: read from the right mailbox when started from a subdirectory

* cc/run-command (Wed Mar 5 08:35:16 2008 +0100) 1 commit
 + run-command: Redirect stderr to a pipe before redirecting stdout
   to stderr

* jc/unpack-careful (Mon Feb 25 22:46:13 2008 +0100) 4 commits
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* py/submodule (Mon Mar 3 02:15:10 2008 +0800) 4 commits
 - git-submodule summary: documentation
 - git-submodule summary: limit summary size
 - git-submodule summary: show commit summary
 - git-submodule summary: code framework

----------------------------------------------------------------
[Actively Cooking]

* cb/mergetool (Thu Feb 21 23:31:56 2008 +0000) 4 commits
 + Add a very basic test script for git mergetool
 + Teach git mergetool to use custom commands defined at config time
 + Changed an internal variable of mergetool to support custom
   commands
 + Tidy up git mergetool's backup file behaviour

The series looked Ok, and Ted seems to be busy, so I queued them myself.
Hopefully nobody would see breakages and we can have this in 1.5.5.

* dc/format-pretty (Sun Mar 2 17:05:53 2008 +0800) 3 commits
 + log/show/whatchanged: introduce format.pretty configuration
 + specify explicit "--pretty=medium" with `git log/show/whatchanged`
 + whatchanged documentation: share description of --pretty with
   others

Slated for 1.5.5.

* js/remote (Tue Mar 4 11:23:53 2008 +0000) 7 commits
 + remote: fix "update [group...]"
 + remote show: Clean up connection correctly if object fetch wasn't
   done
 + builtin-remote: prune remotes correctly that were added with --
   mirror
 + Make git-remote a builtin
 + Test "git remote show" and "git remote prune"
 + parseopt: add flag to stop on first non option
 + path-list: add functions to work with unsorted lists

Slated for 1.5.5.

* sp/fetch-optim (Mon Mar 3 22:27:40 2008 -0500) 11 commits
 + Teach git-fetch to exploit server side automatic tag following
 + Teach fetch-pack/upload-pack about --include-tag
 + git-pack-objects: Automatically pack annotated tags if object was
   packed
 + Teach git-fetch to grab a tag at the same time as a commit
 + Make git-fetch follow tags we already have objects for sooner
 + Teach upload-pack to log the received need lines to an fd
 + Free the path_lists used to find non-local tags in git-fetch
 + Allow builtin-fetch's find_non_local_tags to append onto a list
 + Ensure tail pointer gets setup correctly when we fetch HEAD only
 + Remove unnecessary delaying of free_refs(ref_map) in builtin-fetch
 + Remove unused variable in builtin-fetch find_non_local_tags

Slated for 1.5.5.

* js/reflog-delete (Sun Mar 2 14:58:51 2008 -0600) 13 commits
 + t3903-stash.sh: Add tests for new stash commands drop and pop
 + git-reflog.txt: Document new commands --updateref and --rewrite
 + t3903-stash.sh: Add missing '&&' to body of testcase
 + Merge commit '74359821' into js/reflog-delete
 + git-stash: add new 'pop' subcommand
 + git-stash: add new 'drop' subcommand
 + git-reflog: add option --updateref to write the last reflog sha1
   into the ref
 + refs.c: make close_ref() and commit_ref() non-static
 + git-reflog: add option --rewrite to update reflog entries while
   expiring
 + reflog-delete: parse standard reflog options
 + Merge branch 'bc/reflog-fix' into js/reflog-delete
 + builtin-reflog.c: fix typo that accesses an unset variable
 + Teach "git reflog" a subcommand to delete single entries

Slated for 1.5.5.

----------------------------------------------------------------
[On Hold]

* nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
 - Additional tests to capture worktree special cases
 - Documentation: update api-builtin and api-setup
 - Make setup_git_directory() auto-setup worktree if found
 - builtin-archive: mark unused prefix "unused_prefix"
 - Completely move out worktree setup from
   setup_git_directory_gently()
 - http-push: Avoid calling setup_git_directory() twice
 - Make setup_work_tree() return new prefix
 - Make get_git_dir() and 'git rev-parse --git-dir' absolute path
 - Make sure setup_git_directory is called before accessing
   repository
 - "git read-tree -m" and the like require worktree

Every time we touch work-tree stuff we seem to unstabilize; this round
seems more solid but I am still treading cautiously.  Not sure if we want
this for 1.5.5.

* ph/parseopt (Sun Mar 2 11:35:56 2008 +0100) 2 commits
 + parse-options: new option type to treat an option-like parameter
   as an argument.
 + parse-opt: bring PARSE_OPT_HIDDEN and NONEG to git-rev-parse --
   parseopt

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

* jc/rename (Tue Jan 29 20:54:56 2008 -0800) 1 commit
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 5 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive
 + expose a helper function peel_to_type().
 + merge-recursive: split low-level merge functions out.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-03-01 20:15                 ` Junio C Hamano
  2008-03-02 14:02                   ` Shawn O. Pearce
@ 2008-03-03  2:06                   ` Junio C Hamano
  2008-03-06  5:49                     ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-03-03  2:06 UTC (permalink / raw)
  To: git

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.

----------------------------------------------------------------
[New Topics]

* cb/mergetool (Thu Feb 21 23:31:56 2008 +0000) 4 commits
 - Add a very basic test script for git mergetool
 - Teach git mergetool to use custom commands defined at config time
 - Changed an internal variable of mergetool to support custom
   commands
 - Tidy up git mergetool's backup file behaviour

* dc/format-pretty (Sun Mar 2 17:05:53 2008 +0800) 3 commits
 - log/show/whatchanged: introduce format.pretty configuration
 - specify explicit "--pretty=medium" with `git log/show/whatchanged`
 - whatchanged documentation: share description of --pretty with
   others

* ph/parseopt (Sun Mar 2 11:35:56 2008 +0100) 2 commits
 + parse-options: new option type to treat an option-like parameter
   as an argument.
 + parse-opt: bring PARSE_OPT_HIDDEN and NONEG to git-rev-parse --
   parseopt

* nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
 - Additional tests to capture worktree special cases
 - Documentation: update api-builtin and api-setup
 - Make setup_git_directory() auto-setup worktree if found
 - builtin-archive: mark unused prefix "unused_prefix"
 - Completely move out worktree setup from
   setup_git_directory_gently()
 - http-push: Avoid calling setup_git_directory() twice
 - Make setup_work_tree() return new prefix
 - Make get_git_dir() and 'git rev-parse --git-dir' absolute path
 - Make sure setup_git_directory is called before accessing
   repository
 - "git read-tree -m" and the like require worktree

Replaced from the early ones in 'pu'.

----------------------------------------------------------------
[Graduated to "master"]

* np/verify-pack (Thu Feb 28 00:25:20 2008 -0500) 4 commits
 + add storage size output to 'git verify-pack -v'
 + fix unimplemented packed_object_info_detail() features
 + make verify_one_pack() a bit less wrong wrt packed_git structure
 + factorize revindex code out of builtin-pack-objects.c

* sp/describe-tag (Thu Feb 28 01:22:36 2008 -0500) 1 commit
 - Teach git-describe to verify annotated tag names before output

* jc/maint-log-merge-left-right (Tue Feb 26 23:18:38 2008 -0800) 1 commit
 + Fix "git log --merge --left-right"

* pb/cvsimport (Thu Feb 28 11:18:23 2008 +0100) 3 commits
 + cvsimport: document that -M can be used multiple times
 + cvsimport: allow for multiple -M options
 + cvsimport: have default merge regex allow for dashes in the branch
   name

* js/maint-daemon (Tue Feb 26 13:00:55 2008 +0100) 2 commits
 + daemon: ensure that base-path is an existing directory
 + daemon: send more error messages to the syslog

* ew/maint-svn-cert-fileprovider (Mon Feb 25 15:56:28 2008 +0100) 1 commit
 + git-svn: Don't prompt for client cert password everytime.

* sb/describe-long (Mon Feb 25 10:43:33 2008 +0100) 1 commit
 + git-describe: --long shows the object name even for a tagged
   commit

* mk/maint-parse-careful (Mon Feb 25 22:46:13 2008 +0100) 10 commits
 + receive-pack: use strict mode for unpacking objects
 + index-pack: introduce checking mode
 + unpack-objects: prevent writing of inconsistent objects
 + unpack-object: cache for non written objects
 + add common fsck error printing function
 + builtin-fsck: move common object checking code to fsck.c
 + builtin-fsck: reports missing parent commits
 + Remove unused object-ref code
 + builtin-fsck: move away from object-refs to fsck_walk
 + add generic, type aware object chain walker

* jn/gitweb-grep (Tue Feb 26 13:22:08 2008 +0100) 3 commits
 + gitweb: Clearly distinguish regexp / exact match searches
 + gitweb: Simplify fixed string search
 + gitweb: Change parse_commits signature to allow for multiple
   options

* jc/remote-multi-url (Wed Feb 27 13:50:44 2008 -0800) 1 commit
 + git-remote: do not complain on multiple URLs for a remote

* cb/http-test (Wed Feb 27 20:28:45 2008 +0100) 2 commits
 + http-push: add regression tests
 + http-push: push <remote> :<branch> deletes remote branch

* mh/maint-http-proxy-fix (Wed Feb 27 21:35:50 2008 +0100) 1 commit
 + Set proxy override with http_init()

----------------------------------------------------------------
[Actively Cooking]

* js/remote (Sun Mar 2 05:31:59 2008 +0000) 6 commits
 - remote show: Clean up connection correctly if object fetch wasn't
   done
 + builtin-remote: prune remotes correctly that were added with --
   mirror
 + Make git-remote a builtin
 + Test "git remote show" and "git remote prune"
 + parseopt: add flag to stop on first non option
 + path-list: add functions to work with unsorted lists

Slated for 1.5.5.

* sp/fetch-optim (Sat Mar 1 00:25:38 2008 -0500) 7 commits
 - Teach git-fetch to grab a tag at the same time as a commit
 - Make git-fetch follow tags we already have objects for sooner
 - Teach upload-pack to log the received need lines to fd 3
 - Allow builtin-fetch's find_non_local_tags to append onto a list
 - Ensure tail pointer gets setup correctly when we fetch HEAD only
 - Remove unnecessary delaying of free_refs(ref_map) in builtin-fetch
 - Remove unused variable in builtin-fetch find_non_local_tags

A few existing tests in 5515 need to be adjusted as they expect tags not
to be fetched early, but the point of this series is to optimize to allow
them to, under some conditions.  Otherwise slated for 1.5.5.

* js/reflog-delete (Sun Mar 2 14:58:51 2008 -0600) 13 commits
 - t3903-stash.sh: Add tests for new stash commands drop and pop
 - git-reflog.txt: Document new commands --updateref and --rewrite
 - t3903-stash.sh: Add missing '&&' to body of testcase
 - Merge commit '7435982102093179474a128648179a44042d8a1c' into
   bc/stash
 + git-stash: add new 'pop' subcommand
 + git-stash: add new 'drop' subcommand
 + git-reflog: add option --updateref to write the last reflog sha1
   into the ref
 + refs.c: make close_ref() and commit_ref() non-static
 + git-reflog: add option --rewrite to update reflog entries while
   expiring
 + reflog-delete: parse standard reflog options
 + Merge branch 'bc/reflog-fix' into js/reflog-delete
 + builtin-reflog.c: fix typo that accesses an unset variable
 + Teach "git reflog" a subcommand to delete single entries

Slated for 1.5.5.

----------------------------------------------------------------
[On Hold]

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

* jc/rename (Tue Jan 29 20:54:56 2008 -0800) 1 commit
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* jc/bulk-allocate (Wed Feb 13 18:37:27 2008 -0800) 2 commits
 - Bulk allocate diff_filepair
 - patch freeable-bulk-alloc

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 5 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive
 + expose a helper function peel_to_type().
 + merge-recursive: split low-level merge functions out.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-03-01 20:15                 ` Junio C Hamano
@ 2008-03-02 14:02                   ` Shawn O. Pearce
  2008-03-03  2:06                   ` Junio C Hamano
  1 sibling, 0 replies; 575+ messages in thread
From: Shawn O. Pearce @ 2008-03-02 14:02 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <gitster@pobox.com> wrote:
> * sp/fetch-optim (Sat Mar 1 00:25:38 2008 -0500) 7 commits
>  - Teach git-fetch to grab a tag at the same time as a commit
>  - Make git-fetch follow tags we already have objects for sooner
>  - Teach upload-pack to log the received need lines to fd 3
>  - Allow builtin-fetch's find_non_local_tags to append onto a list
>  - Ensure tail pointer gets setup correctly when we fetch HEAD only
>  - Remove unnecessary delaying of free_refs(ref_map) in builtin-fetch
>  - Remove unused variable in builtin-fetch find_non_local_tags
> 
> A few existing tests in 5515 need to be adjusted as they expect tags not
> to be fetched early, but the point of this series is to optimize to allow
> them to, under some conditions.  Otherwise slated for 1.5.5.

Really?  I thought 5515 was passing when I sent the v2 series in.
I'll double check it later today.  Prior to my "Teach upload-pack
to log" change I'm not sure *how* the tests in 5515 would notice
that tags were fetched on the first connection and not the second.
Its still in the same git-fetch process.
 
-- 
Shawn.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-02-28  0:45               ` Junio C Hamano
@ 2008-03-01 20:15                 ` Junio C Hamano
  2008-03-02 14:02                   ` Shawn O. Pearce
  2008-03-03  2:06                   ` Junio C Hamano
  0 siblings, 2 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-03-01 20:15 UTC (permalink / raw)
  To: git

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.

----------------------------------------------------------------
[New Topics]

* sp/fetch-optim (Sat Mar 1 00:25:38 2008 -0500) 7 commits
 - Teach git-fetch to grab a tag at the same time as a commit
 - Make git-fetch follow tags we already have objects for sooner
 - Teach upload-pack to log the received need lines to fd 3
 - Allow builtin-fetch's find_non_local_tags to append onto a list
 - Ensure tail pointer gets setup correctly when we fetch HEAD only
 - Remove unnecessary delaying of free_refs(ref_map) in builtin-fetch
 - Remove unused variable in builtin-fetch find_non_local_tags

A few existing tests in 5515 need to be adjusted as they expect tags not
to be fetched early, but the point of this series is to optimize to allow
them to, under some conditions.  Otherwise slated for 1.5.5.

* pb/cvsimport (Thu Feb 28 11:18:23 2008 +0100) 3 commits
 + cvsimport: document that -M can be used multiple times
 + cvsimport: allow for multiple -M options
 + cvsimport: have default merge regex allow for dashes in the branch
   name

Slated for 1.5.5.

* nd/worktree (Wed Feb 27 23:40:45 2008 +0700) 9 commits
 - Documentation: update api-builtin and api-setup
 - Make setup_git_directory() auto-setup worktree if found
 - builtin-archive: mark unused prefix "unused_prefix"
 - Completely move out worktree setup from
   setup_git_directory_gently()
 - http-push: Avoid calling setup_git_directory() twice
 - Make setup_work_tree() return new prefix
 - Make get_git_dir() and 'git rev-parse --git-dir' absolute path
 - Make sure setup_git_directory is called before accessing
   repository
 - "git read-tree -m" and the like require worktree

The first one needs replacement as it breaks "read-tree -i", I think.

* sp/describe-tag (Thu Feb 28 01:22:36 2008 -0500) 1 commit
 - Teach git-describe to verify annotated tag names before output

Slated for 1.5.5.

* jc/maint-log-merge-left-right (Tue Feb 26 23:18:38 2008 -0800) 1 commit
 + Fix "git log --merge --left-right"

Soon to be in 'master' and then 'maint'.

* np/verify-pack (Thu Feb 28 00:25:20 2008 -0500) 4 commits
 + add storage size output to 'git verify-pack -v'
 + fix unimplemented packed_object_info_detail() features
 + make verify_one_pack() a bit less wrong wrt packed_git structure
 + factorize revindex code out of builtin-pack-objects.c

Slated for 1.5.5.

* js/remote (Fri Feb 29 01:46:07 2008 +0000) 5 commits
 + builtin-remote: prune remotes correctly that were added with --
   mirror
 + Make git-remote a builtin
 + Test "git remote show" and "git remote prune"
 + parseopt: add flag to stop on first non option
 + path-list: add functions to work with unsorted lists

Slated for 1.5.5.

----------------------------------------------------------------
[Merge to "master" soon, Slated for 1.5.5]

* js/maint-daemon (Tue Feb 26 13:00:55 2008 +0100) 2 commits
 + daemon: ensure that base-path is an existing directory
 + daemon: send more error messages to the syslog

* ew/maint-svn-cert-fileprovider (Mon Feb 25 15:56:28 2008 +0100) 1 commit
 + git-svn: Don't prompt for client cert password everytime.

* sb/describe-long (Mon Feb 25 10:43:33 2008 +0100) 1 commit
 + git-describe: --long shows the object name even for a tagged
   commit

* mk/maint-parse-careful (Mon Feb 25 22:46:13 2008 +0100) 10 commits
 + receive-pack: use strict mode for unpacking objects
 + index-pack: introduce checking mode
 + unpack-objects: prevent writing of inconsistent objects
 + unpack-object: cache for non written objects
 + add common fsck error printing function
 + builtin-fsck: move common object checking code to fsck.c
 + builtin-fsck: reports missing parent commits
 + Remove unused object-ref code
 + builtin-fsck: move away from object-refs to fsck_walk
 + add generic, type aware object chain walker

* jn/gitweb-grep (Tue Feb 26 13:22:08 2008 +0100) 3 commits
 + gitweb: Clearly distinguish regexp / exact match searches
 + gitweb: Simplify fixed string search
 + gitweb: Change parse_commits signature to allow for multiple
   options

* jc/remote-multi-url (Wed Feb 27 13:50:44 2008 -0800) 1 commit
 + git-remote: do not complain on multiple URLs for a remote

* cb/http-test (Wed Feb 27 20:28:45 2008 +0100) 2 commits
 + http-push: add regression tests
 + http-push: push <remote> :<branch> deletes remote branch

* mh/maint-http-proxy-fix (Wed Feb 27 21:35:50 2008 +0100) 1 commit
 + Set proxy override with http_init()

----------------------------------------------------------------
[Actively Cooking]

* js/reflog-delete (Fri Feb 22 16:52:50 2008 -0600) 9 commits
 + git-stash: add new 'pop' subcommand
 + git-stash: add new 'drop' subcommand
 + git-reflog: add option --updateref to write the last reflog sha1
   into the ref
 + refs.c: make close_ref() and commit_ref() non-static
 + git-reflog: add option --rewrite to update reflog entries while
   expiring
 + reflog-delete: parse standard reflog options
 + Merge branch 'bc/reflog-fix' into js/reflog-delete
 + builtin-reflog.c: fix typo that accesses an unset variable
 + Teach "git reflog" a subcommand to delete single entries

I think this needs tests for both high-level ("stash drop" and
"stash pop") and low-level ("reflog delete --rewrite" and
"reflog delete --updateref"), but otherwise the series looks in
a very good shape.  Slated for 1.5.5 iff tests materialize.

----------------------------------------------------------------
[On Hold]

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

* jc/rename (Tue Jan 29 20:54:56 2008 -0800) 1 commit
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* jc/bulk-allocate (Wed Feb 13 18:37:27 2008 -0800) 2 commits
 - Bulk allocate diff_filepair
 - patch freeable-bulk-alloc

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 5 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive
 + expose a helper function peel_to_type().
 + merge-recursive: split low-level merge functions out.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-02-25  8:40             ` Junio C Hamano
@ 2008-02-28  0:45               ` Junio C Hamano
  2008-03-01 20:15                 ` Junio C Hamano
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-02-28  0:45 UTC (permalink / raw)
  To: git

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.

----------------------------------------------------------------
[New Topics]

* js/maint-daemon (Tue Feb 26 13:00:55 2008 +0100) 2 commits
 + daemon: ensure that base-path is an existing directory
 + daemon: send more error messages to the syslog

* ew/maint-svn-cert-fileprovider (Mon Feb 25 15:56:28 2008 +0100) 1 commit
 + git-svn: Don't prompt for client cert password everytime.

* sb/describe-long (Mon Feb 25 10:43:33 2008 +0100) 1 commit
 + git-describe: --long shows the object name even for a tagged
   commit

* mk/maint-parse-careful (Mon Feb 25 22:46:13 2008 +0100) 10 commits
 - receive-pack: use strict mode for unpacking objects
 - index-pack: introduce checking mode
 - unpack-objects: prevent writing of inconsistent objects
 - unpack-object: cache for non written objects
 - add common fsck error printing function
 - builtin-fsck: move common object checking code to fsck.c
 - builtin-fsck: reports missing parent commits
 - Remove unused object-ref code
 - builtin-fsck: move away from object-refs to fsck_walk
 - add generic, type aware object chain walker

* jn/gitweb-grep (Tue Feb 26 13:22:08 2008 +0100) 3 commits
 + gitweb: Clearly distinguish regexp / exact match searches
 + gitweb: Simplify fixed string search
 + gitweb: Change parse_commits signature to allow for multiple
   options

* jc/remote-multi-url (Wed Feb 27 13:50:44 2008 -0800) 1 commit
 + git-remote: do not complain on multiple URLs for a remote

* cb/http-test (Wed Feb 27 20:28:45 2008 +0100) 2 commits
 - http-push: add regression tests
 - http-push: push <remote> :<branch> deletes remote branch

* mh/maint-http-proxy-fix (Wed Feb 27 21:35:50 2008 +0100) 1 commit
 - Set proxy override with http_init()

----------------------------------------------------------------
[Graduated to "master"]

* ae/pack-autothread (Fri Feb 22 20:12:58 2008 -0600)

Adds runtime detection of online CPU's

* sp/describe (Sun Feb 24 03:07:33 2008 -0500)

A new --exact-match option describes only tagged commits

* bc/reflog-fix (Fri Feb 22 12:47:08 2008 -0600)

* db/host-alias (Sun Feb 24 22:25:04 2008 -0800)

Allows URLs used in pushing and fetching to be rewritten.

* db/push-single-with-HEAD (Wed Feb 20 12:54:05 2008 -0500)

Kills two birds with a commit by (1) fixing "git push $there +HEAD"
to force the single push, and (2) allowing you to set
"remote.$there.push = HEAD" so that "git push $there" will push
only the current branch.

* db/checkout (Sat Feb 23 15:45:19 2008 -0800)

Checkout rewritten in C.

* gp/hash-stdin (Thu Feb 21 10:06:47 2008 +0000)

* jc/diff-relative (Wed Feb 13 00:34:39 2008 -0800) 2 commits

"diff --relative" outputs paths as relative to the current
subdirectory.

* js/run-command (Thu Feb 21 23:42:56 2008 +0100) 2 commits

API clean-ups.

* jk/help-alias (Sun Feb 24 17:17:37 2008 -0500) 3 commits

Shows aliases in "git help"

* cw/bisect (Sat Feb 23 17:14:17 2008 -0800) 1 commit

Fixes "won't bisect on seeked tree".

* js/branch-track (Tue Feb 19 11:24:38 2008 -0500) 2 commits

This allows you to automatically set up tracking even when forking
from a local branch; it builds on top of Daniel's "checkout in C".

* js/merge (Sun Feb 17 19:07:40 2008 +0000) 2 commits

This makes conflicting merges that have hunks separated by only
a few common lines much easier to read.

* db/cover-letter (Sat Feb 23 09:41:56 2008 +0100) 9 commits

Teaches format-patch to optionally generate cover letters.

* jm/free (Thu Jan 31 18:26:32 2008 +0100)

Drops unnecessary "if-before-free" tests.

----------------------------------------------------------------
[Actively Cooking]

* js/reflog-delete (Fri Feb 22 16:52:50 2008 -0600) 9 commits
 + git-stash: add new 'pop' subcommand
 + git-stash: add new 'drop' subcommand
 + git-reflog: add option --updateref to write the last reflog sha1
   into the ref
 + refs.c: make close_ref() and commit_ref() non-static
 + git-reflog: add option --rewrite to update reflog entries while
   expiring
 + reflog-delete: parse standard reflog options
 + Merge branch 'bc/reflog-fix' into js/reflog-delete
 + builtin-reflog.c: fix typo that accesses an unset variable
 + Teach "git reflog" a subcommand to delete single entries

I think this needs tests for both high-level ("stash drop" and
"stash pop") and low-level ("reflog delete --rewrite" and
"reflog delete --updateref"), but otherwise the series looks in
a very good shape.

----------------------------------------------------------------
[On Hold]

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* jc/rename (Tue Jan 29 20:54:56 2008 -0800) 1 commit
 + Optimize rename detection for a huge diff

* jc/bulk-allocate (Wed Feb 13 18:37:27 2008 -0800) 2 commits
 - Bulk allocate diff_filepair
 - patch freeable-bulk-alloc

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 5 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive
 + expose a helper function peel_to_type().
 + merge-recursive: split low-level merge functions out.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* What's cooking in git.git (topics)
  2008-02-21  4:16           ` Junio C Hamano
  2008-02-21 10:40             ` Johannes Schindelin
@ 2008-02-25  8:40             ` Junio C Hamano
  2008-02-28  0:45               ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-02-25  8:40 UTC (permalink / raw)
  To: git

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.

----------------------------------------------------------------
[New Topics]

* sp/describe (Sun Feb 24 03:07:33 2008 -0500) 5 commits
 + Use git-describe --exact-match in bash prompt on detached HEAD
 + Teach git-describe --exact-match to avoid expensive tag searches
 + Avoid accessing non-tag refs in git-describe unless --all is
   requested
 + Teach git-describe to use peeled ref information when scanning
   tags
 + Optimize peel_ref for the current ref of a for_each_ref callback

 (should go to 'master' soon)

* bc/reflog-fix (Fri Feb 22 12:47:08 2008 -0600) 1 commit
 + builtin-reflog.c: don't install new reflog on write failure

 (should go to 'master' soon)

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

* ae/pack-autothread (Fri Feb 22 20:12:58 2008 -0600) 2 commits
 + pack-objects: Print a message describing the number of threads for
   packing
 + pack-objects: Add runtime detection of online CPU's

 (should go to 'master' soon)

* jm/free (Thu Jan 31 18:26:32 2008 +0100) 1 commit
 + Avoid unnecessary "if-before-free" tests.

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

----------------------------------------------------------------
[Graduated to "master"]

* jc/apply-whitespace (Mon Feb 11 15:32:29 2008 -0800) 14 commits

Further work on "apply --whitespace=fix".

* lt/dirstat (Tue Feb 12 17:06:58 2008 -0800) 2 commits

----------------------------------------------------------------
[Will merge to "master" soon]

* db/host-alias (Sun Feb 24 22:25:04 2008 -0800) 3 commits
 + url rewriting: take longest and first match
 + Add support for url aliases in config files
 + Use ALLOC_GROW in remote.{c,h}

Allows URLs used in pushing and fetching to be rewritten.

* db/push-single-with-HEAD (Wed Feb 20 12:54:05 2008 -0500) 1 commit
 + Resolve value supplied for no-colon push refspecs

Kills two birds with a commit by (1) fixing "git push $there +HEAD"
to force the single push, and (2) allowing you to set
"remote.$there.push = HEAD" so that "git push $there" will push
only the current branch.

* db/checkout (Sat Feb 23 15:45:19 2008 -0800) 21 commits
 + checkout: error out when index is unmerged even with -m
 + checkout: show progress when checkout takes long time while
   switching branches
 + Add merge-subtree back
 + checkout: updates to tracking report
 + builtin-checkout.c: Remove unused prefix arguments in
   switch_branches path
 + checkout: work from a subdirectory
 + checkout: tone down the "forked status" diagnostic messages
 + Clean up reporting differences on branch switch
 + builtin-checkout.c: fix possible usage segfault
 + checkout: notice when the switched branch is behind or forked
 + Build in checkout
 + Move code to clean up after a branch change to branch.c
 + Library function to check for unmerged index entries
 + Use diff -u instead of diff in t7201
 + Move create_branch into a library file
 + Build-in merge-recursive
 + Add "skip_unmerged" option to unpack_trees.
 + Discard "deleted" cache entries after using them to update the
   working tree
 + Send unpack-trees debugging output to stderr
 + Add flag to make unpack_trees() not print errors.
 + Allow callers of unpack_trees() to handle failure

Checkout rewritten in C.

* gp/hash-stdin (Thu Feb 21 10:06:47 2008 +0000) 1 commit
 + hash-object: cleanup handling of command line options

* jc/diff-relative (Wed Feb 13 00:34:39 2008 -0800) 2 commits
 + diff --relative: help working in a bare repository
 + diff --relative: output paths as relative to the current
   subdirectory

* js/run-command (Thu Feb 21 23:42:56 2008 +0100) 2 commits
 + start_command(), if .in/.out > 0, closes file descriptors, not the
   callers
 + start_command(), .in/.out/.err = -1: Callers must close the file
   descriptor

* jk/help-alias (Sun Feb 24 17:17:37 2008 -0500) 3 commits
 + help: respect aliases
 + make alias lookup a public, procedural function
 + help: use parseopt

* cw/bisect (Sat Feb 23 17:14:17 2008 -0800) 1 commit
 + Eliminate confusing "won't bisect on seeked tree" failure

* js/branch-track (Tue Feb 19 11:24:38 2008 -0500) 2 commits
 + doc: documentation update for the branch track changes
 + branch: optionally setup branch.*.merge from upstream local
   branches

This allows you to automatically set up tracking even when forking
from a local branch; it builds on top of Daniel's "checkout in C".

* js/merge (Sun Feb 17 19:07:40 2008 +0000) 2 commits
 + xdl_merge(): introduce XDL_MERGE_ZEALOUS_ALNUM
 + xdl_merge(): make XDL_MERGE_ZEALOUS output simpler

This makes conflicting merges that have hunks separated by only
a few common lines much easier to read.

* db/cover-letter (Sat Feb 23 09:41:56 2008 +0100) 9 commits
 + t4014: Replace sed's non-standard 'Q' by standard 'q'
 + Support a --cc=<email> option in format-patch
 + Combine To: and Cc: headers
 + Fix format.headers not ending with a newline
 + Add tests for extra headers in format-patch
 + Add a --cover-letter option to format-patch
 + Export some email and pretty-printing functions
 + Improve message-id generation flow control for format-patch
 + Add more tests for format-patch

Teaches format-patch to optionally generate cover letters.
Several people on the list have had good success stories to
tell, which is very encouraging.

----------------------------------------------------------------
[Actively Cooking]

* js/reflog-delete (Fri Feb 22 16:52:50 2008 -0600) 10 commits
 + git-stash: add new 'pop' subcommand
 + git-stash: add new 'drop' subcommand
 + git-reflog: add option --updateref to write the last reflog sha1
   into the ref
 + refs.c: make close_ref() and commit_ref() non-static
 + git-reflog: add option --rewrite to update reflog entries while
   expiring
 + reflog-delete: parse standard reflog options
 + Merge branch 'bc/reflog-fix' into js/reflog-delete
 + builtin-reflog.c: don't install new reflog on write failure
 + builtin-reflog.c: fix typo that accesses an unset variable
 + Teach "git reflog" a subcommand to delete single entries

I think this needs tests for both high-level ("stash drop" and
"stash pop") and low-level ("reflog delete --rewrite" and
"reflog delete --updateref"), but otherwise the series looks in
a very good shape.

----------------------------------------------------------------
[On Hold]

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* jc/rename (Tue Jan 29 20:54:56 2008 -0800) 1 commit
 + Optimize rename detection for a huge diff

* jc/bulk-allocate (Wed Feb 13 18:37:27 2008 -0800) 2 commits
 - Bulk allocate diff_filepair
 - patch freeable-bulk-alloc

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 5 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive
 + expose a helper function peel_to_type().
 + merge-recursive: split low-level merge functions out.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-02-23  0:51                     ` Junio C Hamano
@ 2008-02-23  2:43                       ` Brandon Casey
  0 siblings, 0 replies; 575+ messages in thread
From: Brandon Casey @ 2008-02-23  2:43 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Schindelin, git

Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
> 
>> Junio C Hamano wrote:
>>
>>>  Also we may want to introduce a stash per branch if we do this.
>> This isn't necessary for how I use stash.
> 
> That's what I thought initially.  But after thinking about it a
> bit, I do not think so anymore.
> 
> It feels limiting not to be able to stash here and unstash
> there.  You cannot stash on one branch and apply on another as
> easily (you should still be able to, by naming the stash
> explicitly, if you really wanted to).
> 
> But why would one even want to?  "What I've been hacking on is
> getting into a good shape but now I noticed I was on a wrong
> branch", is probably the only reason.  But that is what branch
> switching "git checkout" (and its -m variant) does.  If your
> changes are something that would make "checkout -m" conflict,
> stashing and unstashing will result in the same conflict anyway,
> so nothing is lost.

Ok, I had to read that more than once, but you've convinced me.
per-branch stash is interesting.

-brandon

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-02-23  0:19                   ` Brandon Casey
  2008-02-23  0:29                     ` Junio C Hamano
@ 2008-02-23  0:51                     ` Junio C Hamano
  2008-02-23  2:43                       ` Brandon Casey
  1 sibling, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-02-23  0:51 UTC (permalink / raw)
  To: Brandon Casey; +Cc: Johannes Schindelin, git

Brandon Casey <casey@nrlssc.navy.mil> writes:

> Junio C Hamano wrote:
>
>>  Also we may want to introduce a stash per branch if we do this.
>
> This isn't necessary for how I use stash.

That's what I thought initially.  But after thinking about it a
bit, I do not think so anymore.

It feels limiting not to be able to stash here and unstash
there.  You cannot stash on one branch and apply on another as
easily (you should still be able to, by naming the stash
explicitly, if you really wanted to).

But why would one even want to?  "What I've been hacking on is
getting into a good shape but now I noticed I was on a wrong
branch", is probably the only reason.  But that is what branch
switching "git checkout" (and its -m variant) does.  If your
changes are something that would make "checkout -m" conflict,
stashing and unstashing will result in the same conflict anyway,
so nothing is lost.

And there are obvious advantages to per-branch stash.  "stash
list" would contain only changes related to the current branch
by default for one thing.  "stash apply" without parameter would
be context sensitive as well.

By the way, I also thought that "pop instead of delete" was too
limiting.  I tried to like "pop" and wanted to justify it, but I
suspect it would invite user grief in this sequence:

        hack hack, gets interrupted
        git stash
        switch to another branch, service interrupt, and come back
        git stash pop
        hack hack, oops, I made a mess.

And earlier stash point was in a much better shape, but it has already
been lost.

While the workflow with the current stash would be:
        
        hack hack, gets interrupted
        git stash
        switch to another branch, service interrupt, and come back
        git stash apply
        hack hack, oops, I made a mess.
        git reset --hard
        git stash apply
        git commit
        git stash clear

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-02-23  0:19                   ` Brandon Casey
@ 2008-02-23  0:29                     ` Junio C Hamano
  2008-02-23  0:51                     ` Junio C Hamano
  1 sibling, 0 replies; 575+ messages in thread
From: Junio C Hamano @ 2008-02-23  0:29 UTC (permalink / raw)
  To: Brandon Casey; +Cc: Johannes Schindelin, git

Brandon Casey <casey@nrlssc.navy.mil> writes:

> Junio C Hamano wrote:
>
>> We might need to introduce "stash push" which would be a synonym
>> for "stash pop" for symmetry.
>
> I like "stash push" if you mean _antonym_ and not _synonym_.

Heh, I obviously meant synonym "push == save", to give feeling
of symmetry between "push" and "pop", instead of "save" and "pop".

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-02-22 22:26                 ` Junio C Hamano
@ 2008-02-23  0:19                   ` Brandon Casey
  2008-02-23  0:29                     ` Junio C Hamano
  2008-02-23  0:51                     ` Junio C Hamano
  0 siblings, 2 replies; 575+ messages in thread
From: Brandon Casey @ 2008-02-23  0:19 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Schindelin, git

Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
> 
>> Johannes Schindelin wrote:
>>> Hi,
>>>
>>> On Wed, 20 Feb 2008, Junio C Hamano wrote:
>>>> * js/reflog-delete (Fri Jan 4 19:11:37 2008 -0600) 2 commits
>>>>  + builtin-reflog.c: fix typo that accesses an unset variable
>>>>  + Teach "git reflog" a subcommand to delete single entries
>>>>
>>>> There was a patch that uses this to implement "git-stash drop",
>>>> which I didn't queue, as the command name and the UI was
>>>> undecided yet.  Dscho was in favor of "pop" without "drop".
>>> Maybe it is time to "drop" this topic?
>> The issue with drop or pop (for me) was that deleting a reflog
>> entry was causing error messages to be printed.
> 
> I agree with your analysis, and I am tempted to suggest just the
> simplest option.
> 
> The thing is, unless it is a reflog used to implement stash,
> removing an entry in the middle and adjusting an entry before
> and after it, just to fool and squelch the consistency mechanism
> we explicitly have for safety, feels quite wrong.  Especially
> given that the whole point of the reflog is to allow you to
> recover your branch to a particular point in time safely.

Just to clarify, only the entry _after_ has to be adjusted.

If the primary reason for the old sha1 field is to be able to check
the reflog for consistency, then maybe it makes sense to adjust this
field. It's not used when resetting to a particular reflog entry is it?

We do lose something. The reflog entry conveys a transition _from_
a state _to_ a state. If the reflog entry is adjusted, the _from_
state is modified. But I think you would have to manually read the
reflog file to see this information right? The fact that this
information is lost is why I didn't feel comfortable adjusting the
reflog entries by default. In the case of stash, this information
is uninteresting.

> So I'd rather see us remove "reflog delete" and add "reflog pop"
> which resets the ref itself to the previous point and deletes
> the last reflog entry.  Then "stash pop" would become simply
> "stash apply" followed by "reflog pop".

The patch series I sent would allow this with

    git reflog delete --updateref stash@{0}

I don't think that satisfies the requests though. People wanted to
be able to delete any entries in the stash list.

Is any of this currently useful outside of stash? I don't know
enough to know why someone would want to modify the ref without
resetting at least the index and that is what git-reset is for.
Also, outside of stash, I don't know why someone would want to
delete individual reflog entries.

> We might need to introduce "stash push" which would be a synonym
> for "stash pop" for symmetry.

I like "stash push" if you mean _antonym_ and not _synonym_.

"stash pop" and "stash push" would be antonyms (opposite meaning).
"stash push" and "stash save" would be synonyms (same meaning).

>  Also we may want to introduce a stash per branch if we do this.

This isn't necessary for how I use stash.

-brandon

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-02-22 18:47               ` Brandon Casey
@ 2008-02-22 22:26                 ` Junio C Hamano
  2008-02-23  0:19                   ` Brandon Casey
  0 siblings, 1 reply; 575+ messages in thread
From: Junio C Hamano @ 2008-02-22 22:26 UTC (permalink / raw)
  To: Brandon Casey; +Cc: Johannes Schindelin, git

Brandon Casey <casey@nrlssc.navy.mil> writes:

> Johannes Schindelin wrote:
>> Hi,
>> 
>> On Wed, 20 Feb 2008, Junio C Hamano wrote:
>
>>> * js/reflog-delete (Fri Jan 4 19:11:37 2008 -0600) 2 commits
>>>  + builtin-reflog.c: fix typo that accesses an unset variable
>>>  + Teach "git reflog" a subcommand to delete single entries
>>>
>>> There was a patch that uses this to implement "git-stash drop",
>>> which I didn't queue, as the command name and the UI was
>>> undecided yet.  Dscho was in favor of "pop" without "drop".
>> 
>> Maybe it is time to "drop" this topic?
>
> The issue with drop or pop (for me) was that deleting a reflog
> entry was causing error messages to be printed.

I agree with your analysis, and I am tempted to suggest just the
simplest option.

The thing is, unless it is a reflog used to implement stash,
removing an entry in the middle and adjusting an entry before
and after it, just to fool and squelch the consistency mechanism
we explicitly have for safety, feels quite wrong.  Especially
given that the whole point of the reflog is to allow you to
recover your branch to a particular point in time safely.

So I'd rather see us remove "reflog delete" and add "reflog pop"
which resets the ref itself to the previous point and deletes
the last reflog entry.  Then "stash pop" would become simply
"stash apply" followed by "reflog pop".

We might need to introduce "stash push" which would be a synonym
for "stash pop" for symmetry.  Also we may want to introduce a
stash per branch if we do this.

^ permalink raw reply	[flat|nested] 575+ messages in thread

* Re: What's cooking in git.git (topics)
  2008-02-21 10:40             ` Johannes Schindelin
  2008-02-21 16:47               ` Junio C Hamano
@ 2008-02-22 18:47               ` Brandon Casey
  2008-02-22 22:26                 ` Junio C Hamano
  1 sibling, 1 reply; 575+ messages in thread
From: Brandon Casey @ 2008-02-22 18:47 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git

Johannes Schindelin wrote:
> Hi,
> 
> On Wed, 20 Feb 2008, Junio C Hamano wrote:

>> * js/reflog-delete (Fri Jan 4 19:11:37 2008 -0600) 2 commits
>>  + builtin-reflog.c: fix typo that accesses an unset variable
>>  + Teach "git reflog" a subcommand to delete single entries
>>
>> There was a patch that uses this to implement "git-stash drop",
>> which I didn't queue, as the command name and the UI was
>> undecided yet.  Dscho was in favor of "pop" without "drop".
> 
> Maybe it is time to "drop" this topic?

The issue with drop or pop (for me) was that deleting a reflog
entry was causing error messages to be printed.

'reflog delete' can cause read_ref_at() to print an e