What's cooking in git.git (topics)

What's cooking in git.git (topics)

[Junio C Hamano]

Here is a list of topics that are cooking; the commits marked
with '+' are in 'next', '-' are in 'pu'.  Dates are when the
topic was last touched [*1*].

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

* ap/clone-origin (Wed Dec 6 12:07:23 2006 +0000)
 + Explicitly add the default "git pull" behaviour to .git/config on clone

 This makes 'git clone' to mark the local 'master' to explicitly
 merge with the corresponding remote branch, which would be a
 sensible default.

 As discussed on the list earlier, I think it also would make
 sense to forbid 'git pull' to make a merge when:

 (1) branch.*.merge entries exist in $GIT_DIR/config (which
     signals that the user is using this new mechanism), and
 (2) branch.<current-branch>.merge entry does not exist for the
     current branch.

 I think it is sensible to merge to 'master' after that change.

* jc/3way (Wed Nov 29 18:53:13 2006 -0800)
 + git-merge: preserve and merge local changes when doing fast forward

 This allows you to run a 'git merge' (or 'git pull') that
 results in a fast-forward merge that updates a path your
 working tree has modified locally; it merges your local changes
 into the updated version, in the same way the branch switching
 'git checkout -m' works.  It has been in next for some time and
 unless we hear somebody scream I think it is Ok to merge to
 'master'.
 
* jc/blame-boundary (Fri Dec 1 20:45:45 2006 -0800)
 - git-blame: show lines attributed to boundary commits differently.

 This was discussed in a thread on grouping the short-log entries
 differently and measuring the importance of each commit.  While
 it does not break things per-se, nobody seems to want to use it
 for scripting yet, so it is staying in 'pu'.

* jc/commit-careful (Tue Oct 24 21:48:55 2006 -0700)
 + git-commit: show --summary after successful commit.

 I think this is safe to merge to 'master'.

* jc/diff (Mon Sep 25 23:03:34 2006 -0700)
 - para-walk: walk n trees, index and working tree in parallel

 This has been backburnered for a long time.  No time to work on
 and no immediate need to use it for scripts myself yet.

* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700)
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)

 This changes the output of "git diff" for a filename with
 embedded SP and requires everybody to switch to its predecessor
 commit ce74618d (which is in v1.4.4 but not in v1.4.3 series)
 which prepared for this change.  Perhaps sometime in February.

* jc/explain (Mon Dec 4 19:35:04 2006 -0800)
 - git-explain

 This was just a discussion starter.  I tried to reuse existing
 status markers various existing command leaves, but it might be
 a good idea to invent a unified status marker to help 'git
 explain' (or 'git wtf') command, so that everybody can write
 into the same file and 'explain' has to know only about that
 file.  I dunno.

* jc/fpc (Sun Nov 26 16:29:07 2006 -0800)
 - (experimental) per-topic shortlog.

 This was my attempt to give a different grouping of the
 short-log entries.  Will drop soon from 'pu'.

* jc/leftright (Sun Oct 22 17:32:47 2006 -0700)
 - rev-list --left-right.

 When reviewing "git log --merge" I often wish which side each
 of the commits comes from, and this is to achieve that.  I
 haven't met with an enthusiastic support for it, though.
 Perhaps people do not find need for that, or do not do
 complicated merges, or have other tools that I do not regularly
 use that is better than this approach; in which case I should
 probably drop this.

* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800)
 - blame: --show-stats for easier optimization work.

* jc/read-tree-ignore (Tue Dec 5 23:44:23 2006 -0800)
 + read-tree: document --exclude-per-directory
 + Loosen "working file will be lost" check in Porcelain-ish
 + read-tree: further loosen "working file will be lost" check.

 I think this is a 'master' material modulo bugs.  Will cook
 further in 'next'.

* jc/web (Wed Nov 8 14:54:09 2006 -0800)
 - gitweb: steal loadavg throttle from kernel.org

* js/merge (Wed Dec 6 16:45:42 2006 +0100)
 + merge-file: support -p and -q; fix compile warnings
 + Add builtin merge-file, a minimal replacement for RCS merge
 + xdl_merge(): fix and simplify conflict handling
 + xdl_merge(): fix thinko
 + xdl_merge(): fix an off-by-one bug
 + merge-recursive: use xdl_merge().
 + xmerge: make return value from xdl_merge() more usable.
 + xdiff: add xdl_merge()

 merge-recursive that does not rely on RCS "merge".  I use this
 exclusively these days.  Perhaps cook a little further and
 merge to 'master'.

* js/shallow (Fri Nov 24 16:00:13 2006 +0100)
 + fetch-pack: Do not fetch tags for shallow clones.
 + get_shallow_commits: Avoid memory leak if a commit has been reached already.
 + git-fetch: Reset shallow_depth before auto-following tags.
 + upload-pack: Check for NOT_SHALLOW flag before sending a shallow to the client.
 + fetch-pack: Properly remove the shallow file when it becomes empty.
 + shallow clone: unparse and reparse an unshallowed commit
 + Why didn't we mark want_obj as ~UNINTERESTING in the old code?
 + Why does it mean we do not have to register shallow if we have one?
 + We should make sure that the protocol is still extensible.
 + add tests for shallow stuff
 + Shallow clone: do not ignore shallowness when following tags
 + allow deepening of a shallow repository
 + allow cloning a repository "shallowly"
 + support fetching into a shallow repository
 + upload-pack: no longer call rev-list

 The shallow clone.  I do not use it myself but it does not seem
 to break the system for users that do not use shallow
 repositories.  Probably with a better documentation of its
 limitations and caveats, this should be mergeable to 'master'.

* lh/branch-rename (Thu Nov 30 03:16:56 2006 +0100)
 + git-branch: let caller specify logmsg
 + rename_ref: use lstat(2) when testing for symlink
 + git-branch: add options and tests for branch renaming

 I do not rename branches myself and do not see a need for this
 nor I have tested it in real-world setting.  The code seemed
 clean and may be 'master' material.

* np/addcommit (Mon Dec 4 11:13:39 2006 -0500)
 + make 'git add' a first class user friendly interface to the index

* sv/git-svn (Tue Dec 5 16:17:38 2006 +1100)
 - git-svn: re-map repository URLs and UUIDs on SVK mirror paths
 - git-svn: collect revision properties when fetching
 - git-svn: collect SVK source URL on mirror paths
 - git-svn: let libsvn_ls_fullurl return properties too
 - git-svn: make test for SVK mirror path import

 Eric already commented on them but no progress since then.
 Parked in 'pu' only for discussion and these will be replaced
 when resubmitted.


[Footnote]

*1* I am trying out an alternative to short-log.  I think the
above format is easier to see what is going on than separate
short-log for 'next' and 'pu'.  It is based on the "TO" script
found in 'todo' branch but hand edited.

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

[Jakub Narebski]

Junio C Hamano wrote:

> Here is a list of topics that are cooking; the commits marked
> with '+' are in 'next', '-' are in 'pu'.  Dates are when the
> topic was last touched [*1*].
> 
> ----------------------------------------------------------------

> * jc/3way (Wed Nov 29 18:53:13 2006 -0800)
>  + git-merge: preserve and merge local changes when doing fast forward
> 
>  This allows you to run a 'git merge' (or 'git pull') that
>  results in a fast-forward merge that updates a path your
>  working tree has modified locally; it merges your local changes
>  into the updated version, in the same way the branch switching
>  'git checkout -m' works.  It has been in next for some time and
>  unless we hear somebody scream I think it is Ok to merge to
>  'master'.

Very nice. Less suprises for CVS users (with "update then commit"
mentality/habits).
  
> * jc/explain (Mon Dec 4 19:35:04 2006 -0800)
>  - git-explain
> 
>  This was just a discussion starter.  I tried to reuse existing
>  status markers various existing command leaves, but it might be
>  a good idea to invent a unified status marker to help 'git
>  explain' (or 'git wtf') command, so that everybody can write
>  into the same file and 'explain' has to know only about that
>  file.  I dunno.

I think it would be nice to have... but as it is very fresh
it probably should cook for a while in next.
 
> * jc/leftright (Sun Oct 22 17:32:47 2006 -0700)
>  - rev-list --left-right.
> 
>  When reviewing "git log --merge" I often wish which side each
>  of the commits comes from, and this is to achieve that.  I
>  haven't met with an enthusiastic support for it, though.
>  Perhaps people do not find need for that, or do not do
>  complicated merges, or have other tools that I do not regularly
>  use that is better than this approach; in which case I should
>  probably drop this.

Looks nice, as an alternative to git-cherry-pick (which sometimes
doesn't do - because it cannot - it's work).
 
> * jc/web (Wed Nov 8 14:54:09 2006 -0800)
>  - gitweb: steal loadavg throttle from kernel.org

Is having loadavg in gitweb, and not configured in server good idea?
What next, log generation in gitweb? Just kidding.
 
> * js/merge (Wed Dec 6 16:45:42 2006 +0100)
>  + merge-file: support -p and -q; fix compile warnings
>  + Add builtin merge-file, a minimal replacement for RCS merge
>  + xdl_merge(): fix and simplify conflict handling
>  + xdl_merge(): fix thinko
>  + xdl_merge(): fix an off-by-one bug
>  + merge-recursive: use xdl_merge().
>  + xmerge: make return value from xdl_merge() more usable.
>  + xdiff: add xdl_merge()
> 
>  merge-recursive that does not rely on RCS "merge".  I use this
>  exclusively these days.  Perhaps cook a little further and
>  merge to 'master'.

Very nice, especially with zealous (tight) merge conflicts.

> * lh/branch-rename (Thu Nov 30 03:16:56 2006 +0100)
>  + git-branch: let caller specify logmsg
>  + rename_ref: use lstat(2) when testing for symlink
>  + git-branch: add options and tests for branch renaming
> 
>  I do not rename branches myself and do not see a need for this
>  nor I have tested it in real-world setting.  The code seemed
>  clean and may be 'master' material.

I'd like to have this, but it MUST work well with reflogs for me.
 
> [Footnote]
> 
> *1* I am trying out an alternative to short-log.  I think the
> above format is easier to see what is going on than separate
> short-log for 'next' and 'pu'.  It is based on the "TO" script
> found in 'todo' branch but hand edited.

It looks and reads better. I usually read only description,
as shortlog is not that useful unless you are interested in
given topic. At least for me.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

>> * jc/3way (Wed Nov 29 18:53:13 2006 -0800)
>>  + git-merge: preserve and merge local changes when doing fast forward
>> 
>>  This allows you to run a 'git merge' (or 'git pull') that
>>  results in a fast-forward merge that updates a path your
>>  working tree has modified locally; it merges your local changes
>>  into the updated version, in the same way the branch switching
>>  'git checkout -m' works.  It has been in next for some time and
>>  unless we hear somebody scream I think it is Ok to merge to
>>  'master'.
>
> Very nice. Less suprises for CVS users (with "update then commit"
> mentality/habits).

This only makes "update; edit; update; commit" to work.  "edit;
commit; edit; commit; edit; update; commit" would not work,
because you would be faced to resolving the conflicts upon the
last update while your working tree is already contaminated with
your own changes (it can be done and experienced people have
done so, but you are talking about "CVS users" here).

We'd be much better off to encourage users to shake "update then
commit" habit, especially if they are on a slow link.

>> * jc/web (Wed Nov 8 14:54:09 2006 -0800)
>>  - gitweb: steal loadavg throttle from kernel.org
>
> Is having loadavg in gitweb, and not configured in server good idea?

Have you looked at the code to see what it does?

>> * lh/branch-rename (Thu Nov 30 03:16:56 2006 +0100)
>>  + git-branch: let caller specify logmsg
>>  + rename_ref: use lstat(2) when testing for symlink
>>  + git-branch: add options and tests for branch renaming
>> 
>>  I do not rename branches myself and do not see a need for this
>>  nor I have tested it in real-world setting.  The code seemed
>>  clean and may be 'master' material.
>
> I'd like to have this, but it MUST work well with reflogs for me.

Then test it and fix breakage if any please.

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

[Johannes Schindelin]

Hi,

On Wed, 6 Dec 2006, Junio C Hamano wrote:

> Here is a list of topics that are cooking; the commits marked
> with '+' are in 'next', '-' are in 'pu'.  Dates are when the
> topic was last touched [*1*].

I like the combined pu/next "What's new".

> * ap/clone-origin (Wed Dec 6 12:07:23 2006 +0000)
> [...]
>  I think it is sensible to merge to 'master' after that change.

Me, too. I really would like this to go in.

> * jc/3way (Wed Nov 29 18:53:13 2006 -0800)
>  + git-merge: preserve and merge local changes when doing fast forward
> [...]
>  It has been in next for some time and unless we hear somebody scream I 
>  think it is Ok to merge to 'master'.

This is something I am looking forward to to test. Maybe in "next" for 
while before putting it into "master"?

> * jc/explain (Mon Dec 4 19:35:04 2006 -0800)
>  - git-explain

I vote for putting this into "next" for a wider audience. It also would 
help people to submit patches (it is kind of a hassle to branch "pu", so I 
rarely do it myself, whereas my git is based on "next" at all times).

> * js/merge (Wed Dec 6 16:45:42 2006 +0100)
>
>  merge-recursive that does not rely on RCS "merge".  I use this
>  exclusively these days.  Perhaps cook a little further and
>  merge to 'master'.

Yes, definitely cook it for at least a week; maybe I find the time to 
check the conflicted merges in git.git at least.

> * js/shallow (Fri Nov 24 16:00:13 2006 +0100)
> 
>  Probably with a better documentation of its limitations and caveats, 
>  this should be mergeable to 'master'.

The more I see the missing reaction, the less sure I am this is a sensible 
thing to do.

And it would need more safety valves, not just documentation. For example, 
I am not sure if a push from/to a shalow repo is safe.

Ciao,
Dscho

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

[Alexandre Julliard]

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

>> * js/shallow (Fri Nov 24 16:00:13 2006 +0100)
>> 
>>  Probably with a better documentation of its limitations and caveats, 
>>  this should be mergeable to 'master'.
>
> The more I see the missing reaction, the less sure I am this is a sensible 
> thing to do.

I'm not sure what reaction you expect, but this is something a lot of
our occasional Wine users are requesting. The Wine full history is
80Mb, and that's a big download if you just want to try a quick
patch. Now of course you won't see these users around here hacking on
shallow clone, most likely they just went and downloaded Wine from the
CVS mirror instead. But it's a shame to have to maintain a CVS mirror
just for that purpose...

-- 
Alexandre Julliard

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

[Andy Parkins]

On Wednesday 2006, December 06 23:42, Johannes Schindelin wrote:

> > * js/shallow (Fri Nov 24 16:00:13 2006 +0100)
> >
> >  Probably with a better documentation of its limitations and caveats,
> >  this should be mergeable to 'master'.
>
> The more I see the missing reaction, the less sure I am this is a sensible
> thing to do.

Don't be too downhearted.  I am certainly looking forward to using shallow 
clones; but by their very nature they are going to be used on big established 
projects (otherwise why would one need a shallow clone?), so until those 
projects upgrade their servers the news will be quiet

Also; it's probably going to be casual developers that find shallow clones 
useful, as the main developers will clone the whole repository.  This might 
also mean that they aren't going to be around on the git mailing list.

I certainly wouldn't say that the shallow clone work is not being appreciated.  
It's just being appreciated quietly.


Andy


-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

What's cooking in git.git (topics)

[Junio C Hamano]

Things that I feel should be done need to be done to complete
v1.5.0 are:

 - 'git-rm' needs to be fixed up as Linus outlined; remove
   working tree file and index entry but have a sanity check to
   make sure the working tree file match the index and HEAD.

 - tutorials and other Porcelain documentation pages need to be
   updated to match the updated 'git-add' and 'git-rm' (to be
   updated), and their description should be made much less
   about implementation; they should talk in terms of end-user
   workflows.

   We need a full sweep on Porcelain-ish documentation.

 - now reflog is enabled by default for user repositories, I
   have two worries about its effect, fortunately can be killed
   with a single stone.

   * the reflog grows unbounded;

   * revisions recorded in the reflog can be pruned out,
     rendering some entries in reflog useless.

   I am thinking about teaching fsck-objects and prune to keep
   revisions recorded in the reflog; we would need an end-user
   way to prune older reflog entries and I would appreciate
   somebody codes it up, but even without it, people can always
   use "vi" or "ed" on reflog files ;-).

 - 'git-add' might want to do 'update-index --replace'; probably
   needs a sanity-checking discussion before implementing it.

 - 'git-svn' users should speak out about two issues:

   * use of svn command line client as the backend is being
     removed;

   * 'git-svn commit' command is being renamed to avoid
     confusion, and potentially 'dcommit' will be renamed to 
     'commit'.

   Please discuss these with Eric.

 - we might want to address the issue that 'git-status' output
   does not make it easy to tell mode changes from content
   changes.  Personally I do not like cryptic "M+" output format
   proposed by Lars and find the current output more readable.

----------------------------------------------------------------
As usual, '+' are both in 'next' and 'pu', '-' are in 'pu' only.

*  jn/web (Sat Dec 16 17:12:55 2006 +0100) 9 commits
 - gitweb: Add some mod_perl specific support
 + gitweb: Add "next" link to commit view
 + gitweb: Add title attribute to ref marker with full ref name
 + gitweb: Do not show difftree for merges in "commit" view
 + gitweb: SHA-1 in commit log message links to "object" view
 + gitweb: Hyperlink target of symbolic link in "tree" view (if
   possible)
 + gitweb: Add generic git_object subroutine to display object of any
   type
 + gitweb: Show target of symbolic link in "tree" view
 + gitweb: Don't use Content-Encoding: header in git_snapshot

All except the tip (mod_perl) looked good and should be in
v1.5.0; I haven't formed an opinion on mod_perl change yet.

*  js/branch-config (Sat Dec 16 15:15:02 2006 +0100) 2 commits
 + git-branch: rename config vars branch.<branch>.*, too
 + add a function to rename sections in the config

This moves branch.$foo.* variables to branch.$bar.* when $foo
branch is renamed to $bar.  Because we already have branch -m
(stands for "mv"), this series is a must-have in v1.5.0.

*  jc/clone (Sat Dec 16 01:53:10 2006 -0800) 4 commits
 + git-clone: lose the traditional 'no-separate-remote' layout
 + git-clone: lose the artificial "first" fetch refspec
 + git-pull: refuse default merge without branch.*.merge
 + git-clone: use wildcard specification for tracking branches

Fixes the workflow wart and removes the traditional layout that
maps remote 'master' to refs/heads/origin.  Also 'git pull' and
'git pull origin' would not merge the ref on the first Pull:
line (nor remote.*.fetch item) anymore.  You either have to give
an explicit command line parameter or branch.$currbranch.merge
item.  With blessing from Linus, this will be in v1.5.0.

*  ew/svn-pm (Fri Dec 15 23:58:08 2006 -0800) 3 commits
 + git-svn: rename 'commit' command to 'set-tree'
 + git-svn: remove support for the svn command-line client
 + git-svn: convert to using Git.pm

It is in 'next' because I agree it is in the right direction in
the longer term, but not in 'master' because this might be
controvertial for shorter term.  The users should decide.

** jc/reflog (Thu Dec 14 15:58:56 2006 -0800) 1 commit
 - Teach show-branch how to show ref-log data.

A strawman to make reflog data a bit more browsable; it would be
useful while recovering from a mistake you made recently.  Not
essential and can wait or be dropped if people do not find it
useful.

** jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
 - git-add --interactive: hunk splitting
 - git-add --interactive

I've thought about further allowing to edit the patches in the
'patch' subcommand, but the more I think about it, the less it
makes sense from the workflow point of view.  Will be the topic
for a separate message.

** sv/git-svn (Tue Dec 5 16:17:38 2006 +1100) 5 commits
 . git-svn: re-map repository URLs and UUIDs on SVK mirror paths
 . git-svn: collect revision properties when fetching
 . git-svn: collect SVK source URL on mirror paths
 . git-svn: let libsvn_ls_fullurl return properties too
 . git-svn: make test for SVK mirror path import

Still held but dropped from 'pu' for now (depends on "sub sys"
that was removed from git-svn).

** jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain

Backburnered.

*  jc/blame-boundary (Fri Dec 1 20:45:45 2006 -0800) 1 commit
 + git-blame: show lines attributed to boundary commits differently.

Will merge.

*  jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward

Will merge, if only to see what breaks.

*  js/shallow (Fri Nov 24 16:00:13 2006 +0100) 15 commits
 + fetch-pack: Do not fetch tags for shallow clones.
 + get_shallow_commits: Avoid memory leak if a commit has been
   reached already.
 + git-fetch: Reset shallow_depth before auto-following tags.
 + upload-pack: Check for NOT_SHALLOW flag before sending a shallow
   to the client.
 + fetch-pack: Properly remove the shallow file when it becomes
   empty.
 + shallow clone: unparse and reparse an unshallowed commit
 + Why didn't we mark want_obj as ~UNINTERESTING in the old code?
 + Why does it mean we do not have to register shallow if we have
   one?
 + We should make sure that the protocol is still extensible.
 + add tests for shallow stuff
 + Shallow clone: do not ignore shallowness when following tags
 + allow deepening of a shallow repository
 + allow cloning a repository "shallowly"
 + support fetching into a shallow repository
 + upload-pack: no longer call rev-list

Undecided but not likely to be in v1.5.0.  Needs more real
project testing.

** jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org

Undecided.

** jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.

Developer only.

** jc/leftright (Sun Oct 22 17:32:47 2006 -0700) 1 commit
 - rev-list --left-right

Backburnered.

** jc/diff (Mon Sep 25 23:03:34 2006 -0700) 1 commit
 - para-walk: walk n trees, index and working tree in parallel

Backburnered.

*  jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

Not in v1.5.0.

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

[Jakub Narebski]

Junio C Hamano wrote:

> Things that I feel should be done need to be done to complete
> v1.5.0 are:
[...]
>  - now reflog is enabled by default for user repositories, I
>    have two worries about its effect, fortunately can be killed
>    with a single stone.
> 
>    * the reflog grows unbounded;
> 
>    * revisions recorded in the reflog can be pruned out,
>      rendering some entries in reflog useless.
> 
>    I am thinking about teaching fsck-objects and prune to keep
>    revisions recorded in the reflog; we would need an end-user
>    way to prune older reflog entries and I would appreciate
>    somebody codes it up, but even without it, people can always
>    use "vi" or "ed" on reflog files ;-).

I'd rather not have prune keep revisions recorded in reflog. Reflog
keeps also amended commits, and blobs from incrementally staged
commits. Or perhaps make it an configuration option, default to
true for new users (or have an option to git-prune to ignore reflog).

As of "reflog grows unbounded"... perhaps we should encourage to use
logrotate for that (well, perhaps git-prune and porcelains which deal
with reflog should be able to uncompress reflog if needed).

>  - 'git-svn' users should speak out about two issues:
> 
>    * use of svn command line client as the backend is being
>      removed;
> 
>    * 'git-svn commit' command is being renamed to avoid
>      confusion, and potentially 'dcommit' will be renamed to 
>      'commit'.
> 
>    Please discuss these with Eric.

What about remote.<repo>.url = svn://ser.ver/repo/ idea?
 
> ** jc/reflog (Thu Dec 14 15:58:56 2006 -0800) 1 commit
>  - Teach show-branch how to show ref-log data.
> 
> A strawman to make reflog data a bit more browsable; it would be
> useful while recovering from a mistake you made recently.  Not
> essential and can wait or be dropped if people do not find it
> useful.

Looks useful.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
>
>> Things that I feel should be done need to be done to complete
>> v1.5.0 are:
> [...]
>>  - now reflog is enabled by default for user repositories, I
>>    have two worries about its effect, fortunately can be killed
>>    with a single stone.
>> 
>>    * the reflog grows unbounded;
>> 
>>    * revisions recorded in the reflog can be pruned out,
>>      rendering some entries in reflog useless.
>> 
>>    I am thinking about teaching fsck-objects and prune to keep
>>    revisions recorded in the reflog; we would need an end-user
>>    way to prune older reflog entries and I would appreciate
>>    somebody codes it up, but even without it, people can always
>>    use "vi" or "ed" on reflog files ;-).
>
> I'd rather not have prune keep revisions recorded in reflog. Reflog
> keeps also amended commits, and blobs from incrementally staged
> commits.

That is exactly why I would want to protect them from pruning;
the current alternative, git-lost-found, is usable but not so
nice from the point of view of end users .  The user should be
able to use show-branch --reflog, or use a different mode of
operation in the log family [*1*] to inspect the otherwise lost
commits, and as you prune unneeded reflog entries you could
prune those objects.

You could certainly arrange things the other way around.  As a
part of prune, you can prune the reflog entries that refer to
commits that were pruned away and no longer available.

HOWEVER, that is very unfriendly to the end users, because they
do not have much control in what 'prune' removes.  If you want
to keep a dozen or so recent states just in case you may have to
salvage rewound states (e.g. you may realize your amended commit
was faulty), how would you tell 'prune' to keep only those
objects from getting pruned?

That's right -- by holding references to them.  And that is
exactly how making prune to take reflog into account would help
the user.  If the user has unwanted commits (say, everything
that are more than 7 days old, plus this and that commits you
rewound an hour ago), they can be pruned away from reflog and
prune will take care of the rest.

So doing it in the way I described makes a lot more sense than
doing the other way around.

[Footnote]

*1* I have to warn you that this would require quite different
code to walk the commits, but certainly a lot simpler than the
ancestry traversal.  If you are interested in learning the
internals, this may be a good project to start with.

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

[Brian Gernhardt]

> ** jc/reflog (Thu Dec 14 15:58:56 2006 -0800) 1 commit
>  - Teach show-branch how to show ref-log data.
>
> A strawman to make reflog data a bit more browsable; it would be
> useful while recovering from a mistake you made recently.  Not
> essential and can wait or be dropped if people do not find it
> useful.

I'd prefer not to add clutter into show-branch.  I use it on a  
regular basis to see what I've added to what topic branch recently,  
and to look at branches before rebasing.  It also just seems like the  
wrong place to have that kind of data, although I guess it's more  
useful for people who do merges more often than I do.

What about a "git reflog [<branch>]" command instead?  Would show  
output similar to "git log" (or "git show-branch" for brevity).

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

[Shawn Pearce]

Brian Gernhardt <benji@silverinsanity.com> wrote:
> >** jc/reflog (Thu Dec 14 15:58:56 2006 -0800) 1 commit
> > - Teach show-branch how to show ref-log data.
> 
> What about a "git reflog [<branch>]" command instead?  Would show  
> output similar to "git log" (or "git show-branch" for brevity).

It has been proposed on the list.  I even sketched out what such
a command would look like, how it should present the data, etc.
But I never wrote it.  Nobody else has taken up the task either.  :-)

-- 

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

[Yann Dirson]

On Sun, Dec 17, 2006 at 12:29:25AM +0100, Jakub Narebski wrote:
> >    I am thinking about teaching fsck-objects and prune to keep
> >    revisions recorded in the reflog; we would need an end-user
> >    way to prune older reflog entries and I would appreciate
> >    somebody codes it up, but even without it, people can always
> >    use "vi" or "ed" on reflog files ;-).
> 
> I'd rather not have prune keep revisions recorded in reflog. Reflog
> keeps also amended commits, and blobs from incrementally staged
> commits. Or perhaps make it an configuration option, default to
> true for new users (or have an option to git-prune to ignore reflog).

I think that is quite near to other issues: we already have other pieces
of information that we would like to sometimes have ignored and
sometimes not, when running fsck-objects/prune.  Namely, revisions
hidden by grafts, as already discussed on this list.

An idea I had to handle that case, and which could be useful with the
current problem, as well as others, like dealing with stgit's patch
logging, would be to define "reachable commits" using a modular
architecture.  That way we would be able to select what we want
fsck-object/prune to consider reachable, in objects reachable from:

- raw "parents" field of commit objects
- the latter as modified by info/grafts
- reflogs
- stgit patchlogs

The set of rules to consider could be declared in repo-config, thus
stgit would be able to declare that its patchlogs should not be ignored,
and people wishing to prune commits hidden by grafts in one repo could
just remove the "raw-parents" rule from their repo's config.

Obviously, mentionning stgit-specific rules here immediately suggests a
plugin-based architecture.

Does that make any sense ?

-- 

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

[Josef Weidendorfer]

On Sunday 17 December 2006 18:35, Yann Dirson wrote:
> An idea I had to handle that case, and which could be useful with the
> current problem, as well as others, like dealing with stgit's patch
> logging, would be to define "reachable commits" using a modular
> architecture.  That way we would be able to select what we want
> fsck-object/prune to consider reachable, in objects reachable from:
> 
> - raw "parents" field of commit objects
> - the latter as modified by info/grafts
> - reflogs
> - stgit patchlogs

Could be interesting for pruning support in submodules, too.

> The set of rules to consider could be declared in repo-config, thus
> stgit would be able to declare that its patchlogs should not be ignored,
> and people wishing to prune commits hidden by grafts in one repo could
> just remove the "raw-parents" rule from their repo's config.
> 
> Obviously, mentionning stgit-specific rules here immediately suggests a
> plugin-based architecture.

Isn't it enough to specify further subdirectories of .git/, holding
references which should be taken into account while pruning?
Hmm.. Grafting would be a special case.

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

[Andy Parkins]

On Saturday 2006, December 16 23:10, Junio C Hamano wrote:

>    * revisions recorded in the reflog can be pruned out,
>      rendering some entries in reflog useless.

Can I suggest that it should be fine to prune reflog entries but that the act 
of pruning be a log entry itself?

Andy
-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics cooking in git.git and their status.

*  jc/leftright (Sat Dec 16 16:07:20 2006 -0800) 3 commits
 + Make left-right automatic.
 + Teach all of log family --left-right output.
 + rev-list --left-right
*  jc/clone (Sat Dec 16 01:53:10 2006 -0800) 4 commits
 + git-clone: lose the traditional 'no-separate-remote' layout
 + git-clone: lose the artificial "first" fetch refspec
 + git-pull: refuse default merge without branch.*.merge
 + git-clone: use wildcard specification for tracking branches

Will likely to be in 'master' soonish.

*  ew/svn-pm (Fri Dec 15 23:58:08 2006 -0800) 3 commits
 + git-svn: rename 'commit' command to 'set-tree'
 + git-svn: remove support for the svn command-line client
 + git-svn: convert to using Git.pm

On hold -- the users will decide.

*^ jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
 - git-add --interactive: hunk splitting
 - git-add --interactive
*^ jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
*  jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward
*^ jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org

Undecided.

*^ jc/reflog (Sat Dec 16 18:35:00 2006 -0800) 1 commit
 - revision: introduce ref@{N..M} syntax.

I do not think this is of general use enough, so I'd shelve this
for now.

*^ jn/web (Sat Dec 16 17:12:55 2006 +0100) 1 commit
 - gitweb: Add some mod_perl specific support

Jakub says this needs review, so it is on hold for now.

*  js/shallow (Fri Nov 24 16:00:13 2006 +0100) 15 commits
 + fetch-pack: Do not fetch tags for shallow clones.
 + get_shallow_commits: Avoid memory leak if a commit has been
   reached already.
 + git-fetch: Reset shallow_depth before auto-following tags.
 + upload-pack: Check for NOT_SHALLOW flag before sending a shallow
   to the client.
 + fetch-pack: Properly remove the shallow file when it becomes
   empty.
 + shallow clone: unparse and reparse an unshallowed commit
 + Why didn't we mark want_obj as ~UNINTERESTING in the old code?
 + Why does it mean we do not have to register shallow if we have
   one?
 + We should make sure that the protocol is still extensible.
 + add tests for shallow stuff
 + Shallow clone: do not ignore shallowness when following tags
 + allow deepening of a shallow repository
 + allow cloning a repository "shallowly"
 + support fetching into a shallow repository
 + upload-pack: no longer call rev-list

Post v1.5.0

*  jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)
*^ jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.
*^ jc/diff (Mon Sep 25 23:03:34 2006 -0700) 1 commit
 - para-walk: walk n trees, index and working tree in parallel

On hold.

*^ sv/git-svn (Tue Dec 5 16:17:38 2006 +1100) 5 commits
 . git-svn: re-map repository URLs and UUIDs on SVK mirror paths
 . git-svn: collect revision properties when fetching
 . git-svn: collect SVK source URL on mirror paths
 . git-svn: let libsvn_ls_fullurl return properties too
 . git-svn: make test for SVK mirror path import

On hold -- waiting for updates or responses to Eric's comment; I
am holding onto this series but it is temporarily dropped from
'pu'.

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

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

> On Saturday 2006, December 16 23:10, Junio C Hamano wrote:
>
>>    * revisions recorded in the reflog can be pruned out,
>>      rendering some entries in reflog useless.
>
> Can I suggest that it should be fine to prune reflog entries but that the act 
> of pruning be a log entry itself?

I do not understand.  What would that "pruning event" log entry
would say?

By definition each reflog entry says "it was pointing at this
object before, and it was changed by this user to point at that
object at this time and the reason for the change was this".

I personally do not think recording "at this point these things
were pruned" makes _any_ sense whatsoever --- if you care about
the pruned objects that simply means you pruned them before you
are ready to lose them.  But even if for whatever reason you
choose to log that anyway, I have a feeling that that record
does not belong to the reflog itself.

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

[Andy Parkins]

On Monday 2006 December 18 08:09, Junio C Hamano wrote:

> By definition each reflog entry says "it was pointing at this
> object before, and it was changed by this user to point at that
> object at this time and the reason for the change was this".

I'm daft.  I've realised, pruning doesn't remove the ref, it removes one of 
the hashes in the reflog.  I withdraw my comment.

I'd imagined it' as the opposite of a creation.

000000 abcdef  branch created
abcdef 000000  branch deleted

Which is fine, except that isn't what prune is doing at all.

> I personally do not think recording "at this point these things
> were pruned" makes _any_ sense whatsoever --- if you care about

I think you're right. :-)


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE

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

[Shawn Pearce]

Andy Parkins <andyparkins@gmail.com> wrote:
> I'm daft.  I've realised, pruning doesn't remove the ref, it removes one of 
> the hashes in the reflog.  I withdraw my comment.
> 
> I'd imagined it' as the opposite of a creation.
> 
> 000000 abcdef  branch created
> abcdef 000000  branch deleted

Except that branch deletion also deletes the reflog.  So yes, we
could log it as you show above, but right after we appended it to
the log we'd delete the log anyway.  :-)

The immediate log deletion is necessary to support something like:

	git branch foo
	git branch -d foo
	git branch foo/bar

as foo switches from being a file to a directory, which means that
.git/logs/refs/heads/foo also needs to switch from being a file to
being a directory.


The only way to fix the above situation is to make the reflog a
single log for the entire repository, rather than one log per ref.
This may cause locking problems for us as we need to lock not only
the ref but also the repository-wide reflog lock.  Note that right
now the reflog is also protected by the ref lock itself, killing
two birds with one stone.  :-)

-- 

What's cooking in git.git (topics)

[Junio C Hamano]

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

* js/rerere (Wed Dec 20 17:39:41 2006 +0100) 3 commits
 - Make git-rerere a builtin
 - Add a test for git-rerere
 - move read_mmfile() into xdiff-interface

Rewrite of rerere in C by Johannes; this is supposed to contain
no feature change, and I should be able to merge it anytime when
it is shown to be correct.  We'll see.

* jc/skip-count (Tue Dec 19 18:25:32 2006 -0800) 1 commit
 + revision: --skip=<n>

This could help gitweb, but otherwise no strong reason to merge
to 'master' yet.

* jc/leftright (Tue Dec 19 02:28:16 2006 -0800) 4 commits
 + Revert "Make left-right automatic."
 + Make left-right automatic.
 + Teach all of log family --left-right output.
 + rev-list --left-right

Since I reverted the 'automatic' bits, this is ready to be
merged to 'master'.  Perhaps in v1.5.0.

* jc/fsck-reflog (Tue Dec 19 00:23:12 2006 -0800) 6 commits
 - git reflog expire
 - Move in_merge_bases() to commit.c
 - reflog: fix warning message.
 - Teach git-repack to preserve objects referred to by reflog
   entries.
 - Protect commits recorded in reflog from pruning.
 - add for_each_reflog_ent() iterator

Because reflogs are enabled by default in end user repositories
now, this series will be needed sooner or later.  The earlier
ones prevent commits lost by reset/rebase from getting pruned
while reflogs point at them, while the latter ones allow reflogs
to be pruned.  Earlier parts cannot be merged without the expiry
mechanism in the later ones, because doing so would mean crufts
will accumulate not just in reflogs but in object database,
without an easy way to prune them.

* jc/clone (Tue Dec 19 01:39:07 2006 +0100) 10 commits
 + Move "no merge candidate" warning into git-pull
 + Use preprocessor constants for environment variable names.
 + Do not create $GIT_DIR/remotes/ directory anymore.
 + Introduce GIT_TEMPLATE_DIR
 + Revert "fix testsuite: make sure they use templates freshly built
   from the source"
 + fix testsuite: make sure they use templates freshly built from the
   source
 + git-clone: lose the traditional 'no-separate-remote' layout
 + git-clone: lose the artificial "first" fetch refspec
 + git-pull: refuse default merge without branch.*.merge
 + git-clone: use wildcard specification for tracking branches

This is to conclude the move of the default repository layout
created by git-clone to separate-remote layout.  I think this is
ready and the next push would include this in the 'master'.

* jc/branch-remove-remote (Tue Dec 19 09:42:16 2006 +1100) 2 commits
 + git-branch -d: do not stop at the first failure.
 + Teach git-branch to delete tracking branches with -r -d

Will merge.

* jc/blame (Mon Dec 18 14:04:38 2006 -0800) 1 commit
 + blame: -b (blame.blankboundary) and --root (blame.showroot)

Will merge.

* jn/web (Sat Dec 16 17:12:55 2006 +0100) 1 commit
 - gitweb: Add some mod_perl specific support

On hold, Jakub's call.

* ew/svn-pm (Fri Dec 15 23:58:08 2006 -0800) 3 commits
 + git-svn: rename 'commit' command to 'set-tree'
 + git-svn: remove support for the svn command-line client
 + git-svn: convert to using Git.pm

I've heard a few comments that renaming 'commit' to 'set-tree'
are received favorably by users, so this might be ready to be
merged.  Eric's call, but I am not in the rush.

* jc/git-add--interactive (Wed Dec 20 13:06:46 2006 -0800) 3 commits
 . git-add: error out when given no arguments.
 + git-add --interactive: hunk splitting
 + git-add --interactive

This is a bit too young and I am not sure how useful it is in
practice.  I might cherry-pick its tip to 'master' first without
adding the --interactive bits.

* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain

Probably not in v1.5.0.

* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward

Not in v1.5.0.

* js/shallow (Fri Nov 24 16:00:13 2006 +0100) 15 commits
 + fetch-pack: Do not fetch tags for shallow clones.
 + get_shallow_commits: Avoid memory leak if a commit has been
   reached already.
 + git-fetch: Reset shallow_depth before auto-following tags.
 + upload-pack: Check for NOT_SHALLOW flag before sending a shallow
   to the client.
 + fetch-pack: Properly remove the shallow file when it becomes
   empty.
 + shallow clone: unparse and reparse an unshallowed commit
 + Why didn't we mark want_obj as ~UNINTERESTING in the old code?
 + Why does it mean we do not have to register shallow if we have
   one?
 + We should make sure that the protocol is still extensible.
 + add tests for shallow stuff
 + Shallow clone: do not ignore shallowness when following tags
 + allow deepening of a shallow repository
 + allow cloning a repository "shallowly"
 + support fetching into a shallow repository
 + upload-pack: no longer call rev-list

Post v1.5.0.

* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.
* jc/diff (Mon Sep 25 23:03:34 2006 -0700) 1 commit
 - para-walk: walk n trees, index and working tree in parallel
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

The above four are on hold.

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

[Eric Wong]

Junio C Hamano <junkio@cox.net> wrote:
> * ew/svn-pm (Fri Dec 15 23:58:08 2006 -0800) 3 commits
>  + git-svn: rename 'commit' command to 'set-tree'
>  + git-svn: remove support for the svn command-line client
>  + git-svn: convert to using Git.pm
> 
> I've heard a few comments that renaming 'commit' to 'set-tree'
> are received favorably by users, so this might be ready to be
> merged.  Eric's call, but I am not in the rush.

Yes, please merge these for 1.5.0.  I have more on the way that depend
on these patches.  The coming changes to git-svn should make life easier
for Sam's svm/svk patches, too.

-- 

What's cooking in git.git (topics)

[Junio C Hamano]

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

* jc/rm (Fri Dec 22 01:02:59 2006 -0800) 2 commits
 - t3600: update the test for updated git rm
 - git-rm: update to saner semantics

This still needs 'require -r to descend into directories'
safety.  I'd really want to have this in v1.5.0.

* jc/fsck-reflog (Fri Dec 22 00:46:33 2006 -0800) 8 commits
 + reflog expire: prune commits that are not incomplete
 + Don't crash during repack of a reflog with pruned commits.
 + git reflog expire
 + Move in_merge_bases() to commit.c
 + reflog: fix warning message.
 + Teach git-repack to preserve objects referred to by reflog
   entries.
 + Protect commits recorded in reflog from pruning.
 + add for_each_reflog_ent() iterator

The latest 'reflog expire' hopefully should revive Shawn's
repository and make prune or repack working again for him.

Tip for 'next' users.  fsck and prune consider commits that are
referenced by reflog entries reachable, but your repositories
may have been pruned by earlier 'prune' already, which may cause
repack to barf and refuse.  Please use 'reflog expire --all' to
prune out reflog entries that refer to commits that are already
lost if repack fails in your repository and try again.

Because we have made the reflog enabled by default, I really
would want to have this in v1.5.0 to prevent unbounded growth of
reflog files.

I think none of the rest are 'must have's for v1.5.0.  Perhaps
except for js/rerere series.

* js/rerere (Wed Dec 20 17:39:41 2006 +0100) 3 commits
 + Make git-rerere a builtin
 + Add a test for git-rerere
 + move read_mmfile() into xdiff-interface
* jc/skip-count (Tue Dec 19 18:25:32 2006 -0800) 1 commit
 + revision: --skip=<n>
* jn/web (Sat Dec 16 17:12:55 2006 +0100) 1 commit
 - gitweb: Add some mod_perl specific support
* jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
 + git-add --interactive: hunk splitting
 + git-add --interactive
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward
* js/shallow (Fri Nov 24 16:00:13 2006 +0100) 15 commits
 + fetch-pack: Do not fetch tags for shallow clones.
 + get_shallow_commits: Avoid memory leak if a commit has been
   reached already.
 + git-fetch: Reset shallow_depth before auto-following tags.
 + upload-pack: Check for NOT_SHALLOW flag before sending a shallow
   to the client.
 + fetch-pack: Properly remove the shallow file when it becomes
   empty.
 + shallow clone: unparse and reparse an unshallowed commit
 + Why didn't we mark want_obj as ~UNINTERESTING in the old code?
 + Why does it mean we do not have to register shallow if we have
   one?
 + We should make sure that the protocol is still extensible.
 + add tests for shallow stuff
 + Shallow clone: do not ignore shallowness when following tags
 + allow deepening of a shallow repository
 + allow cloning a repository "shallowly"
 + support fetching into a shallow repository
 + upload-pack: no longer call rev-list
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.
* jc/diff (Mon Sep 25 23:03:34 2006 -0700) 1 commit
 - para-walk: walk n trees, index and working tree in parallel
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

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

[Andy Parkins]

On Friday 2006 December 22 09:37, Junio C Hamano wrote:

> * jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
>  + git-add --interactive: hunk splitting
>  + git-add --interactive

I used this to disentangle a load of changes that I made under pressure and 
turned them into lovely isolated commits.  I didn't have any trouble with it, 
and thought it was incredibly useful.

I'd vote for putting it in 1.5 - it's in keeping with the usability theme - 
people love interactive stuff.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

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

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

> On Friday 2006 December 22 09:37, Junio C Hamano wrote:
>
>> * jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
>>  + git-add --interactive: hunk splitting
>>  + git-add --interactive
>
> I used this to disentangle a load of changes that I made under pressure and 
> turned them into lovely isolated commits.  I didn't have any trouble with it, 
> and thought it was incredibly useful.
>
> I'd vote for putting it in 1.5 - it's in keeping with the usability theme - 
> people love interactive stuff.

Seconds?  Thirds?  Vetoes?

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

[Johannes Schindelin]

Hi,

On Fri, 22 Dec 2006, Junio C Hamano wrote:

> Andy Parkins <andyparkins@gmail.com> writes:
> 
> > On Friday 2006 December 22 09:37, Junio C Hamano wrote:
> >
> >> * jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
> >>  + git-add --interactive: hunk splitting
> >>  + git-add --interactive
> >
> > I used this to disentangle a load of changes that I made under pressure and 
> > turned them into lovely isolated commits.  I didn't have any trouble with it, 
> > and thought it was incredibly useful.
> >
> > I'd vote for putting it in 1.5 - it's in keeping with the usability theme - 
> > people love interactive stuff.
> 
> Seconds?  Thirds?  Vetoes?

Obviously, I like git-hunk-commit better ;-)

Seriously again, I will play with it in the next days.

Ciao,
Dscho

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

[Josef Weidendorfer]

On Saturday 23 December 2006 00:40, you wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
> 
> > On Friday 2006 December 22 09:37, Junio C Hamano wrote:
> >
> >> * jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
> >>  + git-add --interactive: hunk splitting
> >>  + git-add --interactive
> >
> > I used this to disentangle a load of changes that I made under pressure and 
> > turned them into lovely isolated commits.  I didn't have any trouble with it, 
> > and thought it was incredibly useful.
> >
> > I'd vote for putting it in 1.5 - it's in keeping with the usability theme - 
> > people love interactive stuff.
> 
> Seconds?  Thirds?  Vetoes?

Seconds. I like it.

Andy: Did you check whether your disentangled commits each actually did compile
on their own? If yes, how did you do it?

Josef

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

[Andy Parkins]

On Saturday 2006, December 23 00:12, Josef Weidendorfer wrote:

> Andy: Did you check whether your disentangled commits each actually did
> compile on their own? If yes, how did you do it?

I didn't; they were easily separable and independent fortunately.  I don't 
have a good way of doing what you ask other than making the commits then 
testing each of those individually; then again there have been plenty of 
ocassions when a git guru tells me some magic that suddenly does exactly what 
I want.

In the case of testing my split commits I suppose it would need some way of 
pushing the working directory into a kind of alternate index temporarily.


Andy
-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com

What's cooking in git.git (topics)

[Junio C Hamano]

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


* jc/fsck-reflog (Fri Dec 22 23:42:30 2006 -0800) 9 commits
 + reflog expire: do not punt on tags that point at non commits.
 + reflog expire: prune commits that are not incomplete
 + Don't crash during repack of a reflog with pruned commits.
 + git reflog expire
 + Move in_merge_bases() to commit.c
 + reflog: fix warning message.
 + Teach git-repack to preserve objects referred to by reflog
   entries.
 + Protect commits recorded in reflog from pruning.
 + add for_each_reflog_ent() iterator

I'd like to push this out before we go -rc1, since the reflogs
are now enabled by default, and otherwise would grow unbounded.


* jc/utf8 (Mon Dec 25 11:48:35 2006 -0800) 3 commits
 - Teach log family --encoding
 - i18n.logToUTF8: convert commit log message to UTF-8
 - Move encoding conversion routine out of mailinfo to utf8.c

This allows repositories to have commit messages in "wrong"
encodings, and converts them to UTF-8 upon "git log" output.  I
think it is much nicer solution than insisting the commit log
message to always be in UTF-8, especially with automated
conversion when making a commit.  If the conversion is botched
(or involves non-reversible conversion) at commit time, the
information is lost forever, but even if the conversion at the
output time fails or loses information, the log message can be
recovered in the original encoding, and conversion can later be
fixed/improved.

This is not a must-have for v1.5.0, but I feel it would be
better to push it out as it can introduce slight backward
incompatibility to people's scripts, if they are expecting to
get messages in original encodings.  If we are going to break
them, we would be better off breaking them at a major revision
boundary than later.


* sp/mmap (Sun Dec 24 00:47:23 2006 -0500) 20 commits
 - Replace mmap with xmmap, better handling MAP_FAILED.
 - Release pack windows before reporting out of memory.
 - Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
 - Test suite for sliding window mmap implementation.
 - Create pack_report() as a debugging aid.
 - Support unmapping windows on 'temporary' packfiles.
 - Improve error message when packfile mmap fails.
 - Ensure core.packedGitWindowSize cannot be less than 2 pages.
 - Load core configuration in git-verify-pack.
 - Fully activate the sliding window pack access.
 - Unmap individual windows rather than entire files.
 - Document why header parsing won't exceed a window.
 - Loop over pack_windows when inflating/accessing data.
 - Replace use_packed_git with window cursors.
 - Refactor how we open pack files to prepare for multiple windows.
 - Create read_or_die utility routine.
 - Use off_t for index and pack file lengths.
 - Refactor packed_git to prepare for sliding mmap windows.
 - Introduce new config option for mmap limit.
 - Replace unpack_entry_gently with unpack_entry.

I wanted to have this in 'next' but it appears that this makes
git-push with a non-trivial amount of data to fail.  v1.5.0 does
not have to wait for this because this should not change any UI.


All the rest are post v1.5.0; some of them will never be merged.

* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward
* js/shallow (Fri Nov 24 16:00:13 2006 +0100) 15 commits
 + fetch-pack: Do not fetch tags for shallow clones.
 + get_shallow_commits: Avoid memory leak if a commit has been
   reached already.
 + git-fetch: Reset shallow_depth before auto-following tags.
 + upload-pack: Check for NOT_SHALLOW flag before sending a shallow
   to the client.
 + fetch-pack: Properly remove the shallow file when it becomes
   empty.
 + shallow clone: unparse and reparse an unshallowed commit
 + Why didn't we mark want_obj as ~UNINTERESTING in the old code?
 + Why does it mean we do not have to register shallow if we have
   one?
 + We should make sure that the protocol is still extensible.
 + add tests for shallow stuff
 + Shallow clone: do not ignore shallowness when following tags
 + allow deepening of a shallow repository
 + allow cloning a repository "shallowly"
 + support fetching into a shallow repository
 + upload-pack: no longer call rev-list

* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

* 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
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
* jn/web (Sat Dec 16 17:12:55 2006 +0100) 1 commit
 - gitweb: Add some mod_perl specific support
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.

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

[Shawn Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> * sp/mmap (Sun Dec 24 00:47:23 2006 -0500) 20 commits
>
> I wanted to have this in 'next' but it appears that this makes
> git-push with a non-trivial amount of data to fail.  v1.5.0 does
> not have to wait for this because this should not change any UI.

Really?  Not good.  Do you have some sort of test case that has
caused this?  I'll try to reproduce it here on my own.

-- 
Shawn.

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

[Shawn Pearce]

Shawn Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> > * sp/mmap (Sun Dec 24 00:47:23 2006 -0500) 20 commits
> >
> > I wanted to have this in 'next' but it appears that this makes
> > git-push with a non-trivial amount of data to fail.  v1.5.0 does
> > not have to wait for this because this should not change any UI.
> 
> Really?  Not good.  Do you have some sort of test case that has
> caused this?  I'll try to reproduce it here on my own.

I've pushed all of git.git into an empty repository, and then
pushed another 1639 objects on top of that, without any errors.
So I can't seem to reproduce the problem here in my Mac OS X system.

BTW, I do agree that sp/mmap should not be in v1.5.0.

-- 
Shawn.

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

[Jakub Narebski]

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.
> 
> 
> * jc/fsck-reflog (Fri Dec 22 23:42:30 2006 -0800) 9 commits
>  + reflog expire: do not punt on tags that point at non commits.
>  + reflog expire: prune commits that are not incomplete
>  + Don't crash during repack of a reflog with pruned commits.
>  + git reflog expire
>  + Move in_merge_bases() to commit.c
>  + reflog: fix warning message.
>  + Teach git-repack to preserve objects referred to by reflog
>    entries.
>  + Protect commits recorded in reflog from pruning.
>  + add for_each_reflog_ent() iterator
> 
> I'd like to push this out before we go -rc1, since the reflogs
> are now enabled by default, and otherwise would grow unbounded.

I'd still like the preserving reflogged data during pruning and
repacking to be optional (default to on). But failing that I'd
like to have option to "reflog expire" to remove only specific
(pattern match, prefix match?) entries, for example to remove
all the "commit --amend" and StGIT work, but leaving rebases,
resets, merges and other stuff.

> * jn/web (Sat Dec 16 17:12:55 2006 +0100) 1 commit
>  - gitweb: Add some mod_perl specific support

I'm about to send improved series of patches, few first ready to
be applied, the rest for review.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> I'd still like the preserving reflogged data during pruning and
> repacking to be optional (default to on).

What does that really _mean_?

Some time after reflog was introduced, you started talking about
it on #git channel saying "you could refer to master@{yesterday}
to get it back, but only unless you pruned".

I think that behaviour was a bug, which was there only because
reflog was bolted onto the plumbing as an afterthought.  If the
data reflog keeps is integral part of git (and in v1.5.0 we are
making it so by turning it on by default), you should not have
to say "but only unless" part, which indicates loss of useful
information.

So you either keep objects that reflog entries need, or you
discard reflog entries that point at them when you discard
certain objects you do not need anymore.  Removing objects
without removing reflog entries that become stale because of
missing objects takes us back to the "bolted on, not really
integrated" situation.  It makes reflog "sometimes work but only
sometimes", and most likely it does not work when the user most
wants it to.

With the current code in 'next', you can discard unwanted reflog
entries using "reflog expire", and then do prune/repack, and can
be assured that the objects that remaining reflog entries want
are still there (modulo bugs -- at least that is the intent).
You could update prune/repack so that they do not look at reflog
data, and have them also remove reflog entries that have become
stale after they do their primary things (either pruning or
repacking), as part of the same invocation.  I will not code
that for you because I do not think it is an improvement over
what we have now (for one thing, you cannot prune selectively,
as I already said).

> But failing that I'd
> like to have option to "reflog expire" to remove only specific
> (pattern match, prefix match?) entries, for example to remove
> all the "commit --amend" and StGIT work, but leaving rebases,
> resets, merges and other stuff.

I would say "Patches welcome"; this is not from my sarcastic
side but because I suspect there might be a remote chance that
it might turn out to be useful in some situation.  It is just
that my suspicion is not strong enough to tempt me to do so
myself, because I think that even with such an elaborate
selection mechanism in place, what the users would do in
practice would boil down to what --expire-unreachable does.

What's cooking in git.git (topics)

[Junio C Hamano]

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

* sp/merge (Thu Dec 28 02:35:34 2006 -0500) 5 commits
 - Improve merge performance by avoiding in-index merges.
 - Avoid git-fetch in `git-pull .` when possible.
 + Use merge-recursive in git-am -3.
 + Allow merging bare trees in merge-recursive.
 + Move better_branch_name above get_ref in merge-recursive.

Good intentions, very attractive, somewhat disruptive and might
be risky breaking existing users.  I'd like at least the earlier
parts to be in v1.5.0-rc1.

* jc/curl (Wed Dec 27 13:59:26 2006 -0800) 1 commit
 + Work around http-fetch built with cURL 7.16.0

Waiting for an Ack.

* sp/mmap (Wed Dec 27 02:46:23 2006 -0500) 22 commits
 - Fix random segfaults in pack-objects.
 - Cleanup read_cache_from error handling.
 - Replace mmap with xmmap, better handling MAP_FAILED.
 - Release pack windows before reporting out of memory.
 - Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
 - Test suite for sliding window mmap implementation.
 - Create pack_report() as a debugging aid.
 - Support unmapping windows on 'temporary' packfiles.
 - Improve error message when packfile mmap fails.
 - Ensure core.packedGitWindowSize cannot be less than 2 pages.
 - Load core configuration in git-verify-pack.
 - Fully activate the sliding window pack access.
 - Unmap individual windows rather than entire files.
 - Document why header parsing won't exceed a window.
 - Loop over pack_windows when inflating/accessing data.
 - Replace use_packed_git with window cursors.
 - Refactor how we open pack files to prepare for multiple windows.
 - Create read_or_die utility routine.
 - Use off_t for index and pack file lengths.
 - Refactor packed_git to prepare for sliding mmap windows.
 - Introduce new config option for mmap limit.
 - Replace unpack_entry_gently with unpack_entry.

Known breakage exists that this series is highly suspected.
Will diagnose and merge to 'next' after fixing.

* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

I promised this to wait until February.  Most likely to be in
v1.5.1.   

* 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
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.

These are on hold or will not be merged ever.

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

[Johannes Schindelin]

Hi,

On Thu, 28 Dec 2006, Junio C Hamano wrote:

> * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
>  + git-merge: preserve and merge local changes when doing fast
>    forward

I'd like this, but behind a command line switch. And in addition to saying 
"cannot merge, blabla needs update", git could spit out "if you want to 
risk a 3way merge, go ahead and add the --preserve-local flag to 
git-merge".

Comments?

Ciao,
Dscho

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

[Jakub Narebski]

Johannes Schindelin wrote:

> Hi,
> 
> On Thu, 28 Dec 2006, Junio C Hamano wrote:
> 
>> * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
>>  + git-merge: preserve and merge local changes when doing fast
>>    forward
> 
> I'd like this, but behind a command line switch. And in addition to saying 
> "cannot merge, blabla needs update", git could spit out "if you want to 
> risk a 3way merge, go ahead and add the --preserve-local flag to 
> git-merge".
> 
> Comments?

Good idea.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Junio C Hamano]

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

> On Thu, 28 Dec 2006, Junio C Hamano wrote:
>
>> * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
>>  + git-merge: preserve and merge local changes when doing fast
>>    forward
>
> I'd like this, but behind a command line switch. And in addition to saying 
> "cannot merge, blabla needs update", git could spit out "if you want to 
> risk a 3way merge, go ahead and add the --preserve-local flag to 
> git-merge".
>
> Comments?

I think what you propose is in line is what I originally wanted
to do, but I backburnered it exactly because I did not like the
"if you want to risk a 3-way" phrase.  It's not the wording, but
the fact that I have to say "risk" bothers me.  No matter how
you cut it, it _is_ risky, and indicates to me that we are
somehow doing this in a wrong way. I have a nagging suspicion
that there may be a better approach, but I haven't found one.

But you are welcome to take a crack at it.

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

[Nicolas Pitre]

On Fri, 29 Dec 2006, Johannes Schindelin wrote:

> Hi,
> 
> On Thu, 28 Dec 2006, Junio C Hamano wrote:
> 
> > * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
> >  + git-merge: preserve and merge local changes when doing fast
> >    forward
> 
> I'd like this, but behind a command line switch. And in addition to saying 
> "cannot merge, blabla needs update", git could spit out "if you want to 
> risk a 3way merge, go ahead and add the --preserve-local flag to 
> git-merge".
> 
> Comments?

Is there really a point for not always doing it?

IOW, if you really want a command line switch, maybe it should be used 
to prevent the above not to allow it?


Nicolas

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

[Johannes Schindelin]

Hi,

On Fri, 29 Dec 2006, Nicolas Pitre wrote:

> On Fri, 29 Dec 2006, Johannes Schindelin wrote:
> 
> > On Thu, 28 Dec 2006, Junio C Hamano wrote:
> > 
> > > * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
> > >  + git-merge: preserve and merge local changes when doing fast
> > >    forward
> > 
> > I'd like this, but behind a command line switch. And in addition to 
> > saying "cannot merge, blabla needs update", git could spit out "if you 
> > want to risk a 3way merge, go ahead and add the --preserve-local flag 
> > to git-merge".
> > 
> > Comments?
> 
> Is there really a point for not always doing it?
> 
> IOW, if you really want a command line switch, maybe it should be used 
> to prevent the above not to allow it?

There is a drawback to enabling this all the time. If the merge screws up 
with gazillions of conflicts, because I pulled the wrong branch, I am so 
used to "git reset --hard". Bummer. All my changes lost.

That is why we encourage commit-before-pull, to have a saved state.

(Of course, the correct thing would not be "git reset --hard", but rather 
"git diff --ours | git apply -R; git reset", but that's a tad long, no?)

Ciao,
Dscho

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

[Raimund Bauer]

* Johannes Schindelin wrote, On 30.12.2006 12:22:
> (Of course, the correct thing would not be "git reset --hard", but rather 
> "git diff --ours | git apply -R; git reset", but that's a tad long, no?)
Then maybe introduce "git reset --ours" which does exactly that?

-- 
best regards

  Ray

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

[Johannes Schindelin]

Hi,

On Sat, 30 Dec 2006, Raimund Bauer wrote:

> * Johannes Schindelin wrote, On 30.12.2006 12:22:
> > (Of course, the correct thing would not be "git reset --hard", but rather
> > "git diff --ours | git apply -R; git reset", but that's a tad long, no?)
> Then maybe introduce "git reset --ours" which does exactly that?

That is possible.

But does it make sense? 

It is a volatile state, and errors are too easy. So I think it makes sense 
to have to _ask_ for such a state.

(Having said that, I think that it actually might make sense for bisecting 
an error where you _need_ a local patch to get it running to begin with.)

Ciao,
Dscho

What's cooking in git.git (topics)

[Junio C Hamano]

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

* jc/send-pack-pipeline (Fri Dec 29 12:14:30 2006 -0800) 2 commits
 + Documentation: illustrate send-pack pipeline.
 + send-pack: fix pipeline.

There was a longstanding bug that was exposed only by accident
when used with Shawn's sliding mmap changes (sp/mmap), and these
are to fix it.  I'll merge this to 'master' before v1.5.0-rc1.

* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
 + Update packedGit config option documentation.
 + mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()
 + pack-objects: fix use of use_pack().
 + Fix random segfaults in pack-objects.
 + Cleanup read_cache_from error handling.
 + Replace mmap with xmmap, better handling MAP_FAILED.
 + Release pack windows before reporting out of memory.
 + Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
 + Test suite for sliding window mmap implementation.
 + Create pack_report() as a debugging aid.
 + Support unmapping windows on 'temporary' packfiles.
 + Improve error message when packfile mmap fails.
 + Ensure core.packedGitWindowSize cannot be less than 2 pages.
 + Load core configuration in git-verify-pack.
 + Fully activate the sliding window pack access.
 + Unmap individual windows rather than entire files.
 + Document why header parsing won't exceed a window.
 + Loop over pack_windows when inflating/accessing data.
 + Replace use_packed_git with window cursors.
 + Refactor how we open pack files to prepare for multiple windows.
 + Create read_or_die utility routine.
 + Use off_t for index and pack file lengths.
 + Refactor packed_git to prepare for sliding mmap windows.
 + Introduce new config option for mmap limit.
 + Replace unpack_entry_gently with unpack_entry.

This is Shawn's sliding mmap series to allow smaller virtual
memory footprint to access larger packfiles.  I started using
this series in production tonight.  Although the size of the
series is somewhat intimidating, they are sane changes and I
think it may be worth considering for 'master'.  This does not
change the user experience majorly as has almost no UI elements,
so it could go in either before or after v1.5.0.

* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward

A few people wanted to have this in v1.5.0, but I am a bit
reluctant to do so --- I think the behaviour of its failure mode
is rather nasty, even though it tries to help the user by
dropping the local diff in .git/LOCAL_DIFF file.

* sp/merge (Sun Dec 31 00:02:13 2006 -0500) 6 commits
 - Refresh the index before starting merge-recursive.
 - Improve merge performance by avoiding in-index merges.
 - Avoid git-fetch in `git-pull .` when possible.
 + Use merge-recursive in git-am -3.
 + Allow merging bare trees in merge-recursive.
 + Move better_branch_name above get_ref in merge-recursive.

I'm reasonably happy with the earlier three of this series but
not really about the latter, and I've already described why.

* 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
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

These are not for 'master' for now.

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

[Juergen Ruehle]

Junio C Hamano writes:
 > * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 >  + git-merge: preserve and merge local changes when doing fast
 >    forward
 > 
 > A few people wanted to have this in v1.5.0, but I am a bit
 > reluctant to do so --- I think the behaviour of its failure mode
 > is rather nasty, even though it tries to help the user by
 > dropping the local diff in .git/LOCAL_DIFF file.

It happened to me (not really an experienced user) for the first time
on the last pull. Though unexpected it wasn't an unpleasant
experience. The failure mode doesn't feel smooth, but after thinking
about possible improvements I couldn't come up with anything better.
It already states explicitly what it's doing including telling the
user about LOCAL_DIFF. The only thing I wasn't sure about was how to
get rid of the unmerged index entries after I fixed the conflicts
without adding the local change to the index. In the end I did an
update-index/reset combination, but perhaps repeating the list of
files with conflicting local changes after the merge and cleaning the
index instead of leaving unmerged entries in the index would be
better.

I think (because of LOCAL_DIFF) it is safe to have this in 1.5 even in
its current incarnation.

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

[Johannes Schindelin]

Hi,

On Sun, 31 Dec 2006, Junio C Hamano wrote:

> * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
>  + git-merge: preserve and merge local changes when doing fast
>    forward
> 
> A few people wanted to have this in v1.5.0, but I am a bit reluctant to 
> do so --- I think the behaviour of its failure mode is rather nasty, 
> even though it tries to help the user by dropping the local diff in 
> .git/LOCAL_DIFF file.

I am not urging the inclusion in 1.5.0, but how about storing not the 
diff, but the _state_ in .git/UNCOMMITTED_TREE? This would work with all 
the git tools without any problem, and git-gc would eventually clean up 
older intermediate stages.

Ciao,
Dscho

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

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> * sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
> 
> This is Shawn's sliding mmap series to allow smaller virtual
> memory footprint to access larger packfiles.  I started using
> this series in production tonight.  Although the size of the
> series is somewhat intimidating, they are sane changes and I
> think it may be worth considering for 'master'.  This does not
> change the user experience majorly as has almost no UI elements,
> so it could go in either before or after v1.5.0.

I know your testing is saying this series may be slightly faster than
the prior code in 'master', and at least on Linux can be so without
using a lot of virtual address space as mmap() is so fast there.
(Nice job kernel people!)  Anyway, I haven't done any performance
testing on this myself.  It would be nice to know more about how
it behaves.
 
> * sp/merge (Sun Dec 31 00:02:13 2006 -0500) 6 commits
>  - Refresh the index before starting merge-recursive.
>  - Improve merge performance by avoiding in-index merges.
>  - Avoid git-fetch in `git-pull .` when possible.
>  + Use merge-recursive in git-am -3.
>  + Allow merging bare trees in merge-recursive.
>  + Move better_branch_name above get_ref in merge-recursive.
> 
> I'm reasonably happy with the earlier three of this series but
> not really about the latter, and I've already described why.

I know you've stated a number of good reasons against "Avoid
git-fetch in `git-pull .` when possible.".  One way I've thought
of trying to resolve that would be to verify the arguments to
`git pull .` are refs only (and not SHA1 expressions) which makes
the behavior the same as `git pull .` and *might* still save time,
as the fetch can still get bypassed.

The only objection I know of to "Improve merge performance by
avoiding in-index merges." was that it needs more testing to ensure
its doing the same thing as before, which basically means we hold it
out until post v1.5.0.  Since it is only a performance improvement
I think that's reasonable.

-- 
Shawn.

What's cooking in git.git (topics)

[Junio C Hamano]

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

* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
 + Update packedGit config option documentation.
 + mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()
 + pack-objects: fix use of use_pack().
 + Fix random segfaults in pack-objects.
 + Cleanup read_cache_from error handling.
 + Replace mmap with xmmap, better handling MAP_FAILED.
 + Release pack windows before reporting out of memory.
 + Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
 + Test suite for sliding window mmap implementation.
 + Create pack_report() as a debugging aid.
 + Support unmapping windows on 'temporary' packfiles.
 + Improve error message when packfile mmap fails.
 + Ensure core.packedGitWindowSize cannot be less than 2 pages.
 + Load core configuration in git-verify-pack.
 + Fully activate the sliding window pack access.
 + Unmap individual windows rather than entire files.
 + Document why header parsing won't exceed a window.
 + Loop over pack_windows when inflating/accessing data.
 + Replace use_packed_git with window cursors.
 + Refactor how we open pack files to prepare for multiple windows.
 + Create read_or_die utility routine.
 + Use off_t for index and pack file lengths.
 + Refactor packed_git to prepare for sliding mmap windows.
 + Introduce new config option for mmap limit.
 + Replace unpack_entry_gently with unpack_entry.

This is what I was looking at on Cygwin on my wife's box today
(I do not have an easy access to Windows boxes otherwise so my
Cygwin testing is limited to only weekends when I am at home).

* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward

Johannes's suggestion to record a tree object instead of
LOCAL_DIFF is roger but not wilco yet --- I haven't thought
through the issue to see an improvement in the suggestion.  We
will be clobbering both index and the working tree, and I think
"diff --binary HEAD" and "write-tree" record the equivalent
amount of information given a HEAD for recovery.

* sp/merge (Sun Dec 31 00:02:13 2006 -0500) 3 commits
 - Refresh the index before starting merge-recursive.
 - Improve merge performance by avoiding in-index merges.
 - Avoid git-fetch in `git-pull .` when possible.

Three patches in the earlier part of this series have graduated
to 'master' as I think they are useful.

* 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
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

These are on hold.

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

[Johannes Schindelin]

Hi,

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

> * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
>  + git-merge: preserve and merge local changes when doing fast
>    forward
> 
> Johannes's suggestion to record a tree object instead of LOCAL_DIFF is 
> roger but not wilco yet --- I haven't thought through the issue to see 
> an improvement in the suggestion.  We will be clobbering both index and 
> the working tree, and I think "diff --binary HEAD" and "write-tree" 
> record the equivalent amount of information given a HEAD for recovery.

For recovery, yes. The difference comes in

- that you can use the familiar git operations to recover (git read-tree 
  PRE_MERGE_TREE), and
- that you can do other git operations on the tree, but not on the diff.

Hth,
Dscho

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

[Alex Riesen]

On 1/2/07, Junio C Hamano <junkio@cox.net> 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.
>
> * sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits

Running this and the merge-recursive speedup I sent today locally.
sp/mmap needs relatively recent cygwin library (otherwise pread
is broken). No other ill effects noticed. Perfomance is bearable.

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

[Shawn O. Pearce]

Alex Riesen <raa.lkml@gmail.com> wrote:
> On 1/2/07, Junio C Hamano <junkio@cox.net> 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.
> >
> >* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
> 
> Running this and the merge-recursive speedup I sent today locally.
> sp/mmap needs relatively recent cygwin library (otherwise pread
> is broken). No other ill effects noticed. Perfomance is bearable.

The default on Cygwin is now NO_MMAP.  I've disabled that default
in my own Cygwin environment and continue to use mmap() rather than
pread(), but I'm also running my sp/mmap change there.  I haven't
noticed a performance difference, but I also haven't tested for one.
IOW if there is a difference its close enough to noise to not be
visible to me as a user.

-- 
Shawn.

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

[Alex Riesen]

On 1/5/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> > >* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
> >
> > Running this and the merge-recursive speedup I sent today locally.
> > sp/mmap needs relatively recent cygwin library (otherwise pread
> > is broken). No other ill effects noticed. Perfomance is bearable.
>
> The default on Cygwin is now NO_MMAP.  I've disabled that default

I left it at NO_MMAP: wanted to see how bad pread performs.
No worse than mmap, as it seems.

> in my own Cygwin environment and continue to use mmap() rather than
> pread(), but I'm also running my sp/mmap change there.  I haven't
> noticed a performance difference, but I also haven't tested for one.
> IOW if there is a difference its close enough to noise to not be
> visible to me as a user.

Confirm that.

What's cooking in git.git (topics)

[Junio C Hamano]

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

I will start merging some topics from 'next' to 'master' this
weekend.  Probably will declare -rc1 next weekend.

* jc/reflog (Sat Jan 6 22:32:41 2007 -0800) 5 commits
 + reflog --fix-stale: do not check the same trees and commits
   repeatedly.
 + reflog expire --fix-stale
 + Move traversal of reachable objects into a separate library.
 + builtin-prune: separate ref walking from reflog walking.
 + builtin-prune: make file-scope static struct to an argument.

We would want to do more interesting things on reflog data (such
as bisecting) and need to make reflog reliable for that.  We
allowed reflog to point at missing commits for too long, and
this is to clean up entries that point at commits removed with
older versions of git.

This needs to be in v1.5.0 final.

* jc/reset-remove (Fri Jan 5 01:38:56 2007 -0800) 2 commits
 + git-reset <tree> -- <path> restores absense of <path> in <tree>
 + diff-index --cached --raw: show tree entry on the LHS for unmerged
   entries.

Will merge to master.

* sp/mmap (Thu Jan 4 22:28:08 2007 -0500) 26 commits
 + Increase packedGit{Limit,WindowSize} on 64 bit systems.
 + Update packedGit config option documentation.
 + mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()
 + pack-objects: fix use of use_pack().
 + Fix random segfaults in pack-objects.
 + Cleanup read_cache_from error handling.
 + Replace mmap with xmmap, better handling MAP_FAILED.
 + Release pack windows before reporting out of memory.
 + Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
 + Test suite for sliding window mmap implementation.
 + Create pack_report() as a debugging aid.
 + Support unmapping windows on 'temporary' packfiles.
 + Improve error message when packfile mmap fails.
 + Ensure core.packedGitWindowSize cannot be less than 2 pages.
 + Load core configuration in git-verify-pack.
 + Fully activate the sliding window pack access.
 + Unmap individual windows rather than entire files.
 + Document why header parsing won't exceed a window.
 + Loop over pack_windows when inflating/accessing data.
 + Replace use_packed_git with window cursors.
 + Refactor how we open pack files to prepare for multiple windows.
 + Create read_or_die utility routine.
 + Use off_t for index and pack file lengths.
 + Refactor packed_git to prepare for sliding mmap windows.
 + Introduce new config option for mmap limit.
 + Replace unpack_entry_gently with unpack_entry.

Will merge to 'master'.

* jc/remote (Wed Jan 3 12:13:04 2007 -0800) 1 commit
 + git-remote

I described what's still missing in this, and the list may have
ideas to enhance it.  Will merge to 'master' and people can hack
on it there.

* jc/detached-head (Wed Jan 3 21:10:10 2007 +0100) 3 commits
 - git-branch: show detached HEAD
 - git-status: show detached HEAD
 - Detached HEAD (experimental)

I personally feel this should be in v1.5.0.final, but it is not
yet ready, unfortunately...

* jr/status (Tue Jan 2 20:26:21 2007 +0100) 4 commits
 + Improve cached content header of status output
 + Support --amend on initial commit in status output
 + Improve "nothing to commit" part of status output
 + Clarify syntax and role of git-add in status output

Will merge to 'master'.

* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward

* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

* sp/merge (Sun Dec 31 00:02:13 2006 -0500) 3 commits
 - Refresh the index before starting merge-recursive.
 - Improve merge performance by avoiding in-index merges.
 - Avoid git-fetch in `git-pull .` when possible.
* 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
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.

What's cooking in git.git (topics)

[Junio C Hamano]

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

* jc/detached-head (Tue Jan 9 20:39:09 2007 -0800) 9 commits
 + git-checkout: handle local changes sanely when detaching HEAD
 + git-checkout: safety check for detached HEAD checks existing refs
 + git-checkout: fix branch name output from the command
 + git-checkout: safety when coming back from the detached HEAD
   state.
 + git-checkout: rewording comments regarding detached HEAD.
 + git-checkout: do not warn detaching HEAD when it is already
   detached.
 + Detached HEAD (experimental)
 + git-branch: show detached HEAD
 + git-status: show detached HEAD

This is intended for v1.5.0; will merge to "master" by the weekend.

* jc/merge-base (Tue Jan 9 02:23:42 2007 -0800) 6 commits
 - Teach "git-merge-base --check-ancestry" about refs.
 - git-merge-base: --check-ancestry option
 + in_merge_bases(): optimization
 + merge_base(): move traversal into a separate function.
 + Allow in_merge_bases() to take more than one reference commits.
 + Make merge-base a built-in.

The early parts are just clean-up and optimization.  It's not
worth disrupt v1.5.0 process with potential bugs, so I would say
this is on-hold. 

* js/reflog (Mon Jan 8 01:59:54 2007 +0100) 1 commit
 + Sanitize for_each_reflog_ent()

I think this makes sense and is a good clean-up.

* jc/bare (Sun Jan 7 02:17:52 2007 -0800) 3 commits
 + git-fetch: allow updating the current branch in a bare repository.
 + Introduce is_bare_repository() and core.bare configuration
   variable
 + Move initialization of log_all_ref_updates

I'd like to take a serious look at Shawn's RFC patch to make
Porcelain-ish commands that require working tree refuse to
operate in a bare repository and rebuild it on top of these;
intended for v1.5.0.

* sp/merge (Sun Dec 31 00:02:13 2006 -0500) 3 commits
 - Refresh the index before starting merge-recursive.
 - Improve merge performance by avoiding in-index merges.
 - Avoid git-fetch in `git-pull .` when possible.
* 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
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

What's cooking in git.git (topics)

[Junio C Hamano]

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

* jc/detached-head (Tue Jan 9 20:39:09 2007 -0800) 9 commits
 + git-checkout: handle local changes sanely when detaching HEAD
 + git-checkout: safety check for detached HEAD checks existing refs
 + git-checkout: fix branch name output from the command
 + git-checkout: safety when coming back from the detached HEAD
   state.
 + git-checkout: rewording comments regarding detached HEAD.
 + git-checkout: do not warn detaching HEAD when it is already
   detached.
 + Detached HEAD (experimental)
 + git-branch: show detached HEAD
 + git-status: show detached HEAD

Will be merged to 'master' in a few days for v1.5.0-rc1.

* jc/bare (Sat Dec 30 23:32:38 2006 -0500) 4 commits
 + Disallow working directory commands in a bare repository.
 + git-fetch: allow updating the current branch in a bare repository.
 + Introduce is_bare_repository() and core.bare configuration
   variable
 + Move initialization of log_all_ref_updates

I munged Shawn's RFC patch and placed on top of this series.
Will be merged to 'master' in a few days for v1.5.0-rc1.

* ar/merge-recursive (Wed Jan 10 11:20:58 2007 -0800) 2 commits
 + merge-recursive: do not use on-file index when not needed.
 + Speed-up recursive by flushing index only once for all entries

I did not see much improvement (maybe a largish kernel merge
going from 2.5 seconds to slightly less than one second) but
this seems safe and the change removes a lot more code than it
adds which must mean it is good.  Perhaps in v1.5.0-rc1 but I do
not think it is a must-have.  Comments?


* sp/merge (Thu Dec 28 02:35:17 2006 -0500) 2 commits
 - Avoid git-fetch in `git-pull .` when possible.
 + Improve merge performance by avoiding in-index merges.

I fliped the patches around and the one that avoids the
"read-tree then merge-recursive" sequence is now in 'next'.  I
haven't done any measurements yet.  It looks obviously correct
but I am not sure if it is a v1.5.0 material.  Comments?


* sp/describe (Wed Jan 10 06:39:47 2007 -0500) 1 commit
 - Chose better tag names in git-describe after merges.

Slowing it down by 4x is very unfortunate.  I think there is a
better way to walk the ancestry than doing one at a time to
count the commits, but I did not have enough time to look at
this today.

* jc/merge-base (Tue Jan 9 02:23:42 2007 -0800) 6 commits
 - Teach "git-merge-base --check-ancestry" about refs.
 - git-merge-base: --check-ancestry option
 + in_merge_bases(): optimization
 + merge_base(): move traversal into a separate function.
 + Allow in_merge_bases() to take more than one reference commits.
 + Make merge-base a built-in.

* 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
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

These are on-hold.

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

[Nicolas Pitre]

On Wed, 10 Jan 2007, Junio C Hamano wrote:

> * jc/detached-head (Tue Jan 9 20:39:09 2007 -0800) 9 commits

I want to say that this is really great and well done.

> * sp/describe (Wed Jan 10 06:39:47 2007 -0500) 1 commit
>  - Chose better tag names in git-describe after merges.
> 
> Slowing it down by 4x is very unfortunate.  I think there is a
> better way to walk the ancestry than doing one at a time to
> count the commits, but I did not have enough time to look at
> this today.

However git-describe is certainly not a frequent and speed critical 
operation, and 
even if it cannot be sped up then waiting 300 ms more won't really 
affect one's workflow that badly.


Nicolas

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

[Shawn O. Pearce]

Nicolas Pitre <nico@cam.org> wrote:
> On Wed, 10 Jan 2007, Junio C Hamano wrote:
> > * sp/describe (Wed Jan 10 06:39:47 2007 -0500) 1 commit
> >  - Chose better tag names in git-describe after merges.
> > 
> > Slowing it down by 4x is very unfortunate.  I think there is a
> > better way to walk the ancestry than doing one at a time to
> > count the commits, but I did not have enough time to look at
> > this today.
> 
> However git-describe is certainly not a frequent and speed critical 
> operation, and 
> even if it cannot be sped up then waiting 300 ms more won't really 
> affect one's workflow that badly.

My thoughts exactly.  I spent a few hours trying to determine
an algorithm that produced the right answer and did not require
generating the revlist between the tag and the requested commit
for every possibly matching tag.  I did not come up with one.
If someone else does it would obviously be a welcome replacement
to my own patch.  :-)

There is almost no additional penalty for a simple strand of pearls
with the tag placed along that strand; only one possible tag will be
found.  But my code does an unnecessary revision list in this case.

Where we really get hit is the large number of possible tags.  The
master branch is turning up 14 tags, some dating back to v1.4.1-rc1.
I do try to abort the revision list as soon as one of those tags
cannot give me a better selection than the one I have currently,
but I still had to generate a revision list to reach that point.

-- 
Shawn.

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

[Johannes Schindelin]

Hi,

On Wed, 10 Jan 2007, Junio C Hamano wrote:

> * ar/merge-recursive (Wed Jan 10 11:20:58 2007 -0800) 2 commits
>  + merge-recursive: do not use on-file index when not needed.
>  + Speed-up recursive by flushing index only once for all entries
> 
> I did not see much improvement (maybe a largish kernel merge
> going from 2.5 seconds to slightly less than one second)

That is a heck of an improvement. It is only uses 40% of the time it used 
before! On other machines, with other OSes, this makes the difference 
between 10 minutes and 4 minutes.

BTW I am not quite sure if you missed this patch: 
http://thread.gmane.org/gmane.comp.version-control.git/36212/, or if you 
did not like it, want enhancements, ...

Ciao,
Dscho

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

[Andreas Ericsson]

Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
>> On Wed, 10 Jan 2007, Junio C Hamano wrote:
>>> * sp/describe (Wed Jan 10 06:39:47 2007 -0500) 1 commit
>>>  - Chose better tag names in git-describe after merges.
>>>
>>> Slowing it down by 4x is very unfortunate.  I think there is a
>>> better way to walk the ancestry than doing one at a time to
>>> count the commits, but I did not have enough time to look at
>>> this today.
>> However git-describe is certainly not a frequent and speed critical 
>> operation, and 
>> even if it cannot be sped up then waiting 300 ms more won't really 
>> affect one's workflow that badly.
> 
> My thoughts exactly.  I spent a few hours trying to determine
> an algorithm that produced the right answer and did not require
> generating the revlist between the tag and the requested commit
> for every possibly matching tag.  I did not come up with one.
> If someone else does it would obviously be a welcome replacement
> to my own patch.  :-)
> 
> There is almost no additional penalty for a simple strand of pearls
> with the tag placed along that strand; only one possible tag will be
> found.  But my code does an unnecessary revision list in this case.
> 
> Where we really get hit is the large number of possible tags.  The
> master branch is turning up 14 tags, some dating back to v1.4.1-rc1.
> I do try to abort the revision list as soon as one of those tags
> cannot give me a better selection than the one I have currently,
> but I still had to generate a revision list to reach that point.
> 

It could be worth skipping tags more than 6 months older than current 
branch-head. That would, at least for the git case, cut the number of 
tags down by a considerable amount.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> There is almost no additional penalty for a simple strand of pearls
> with the tag placed along that strand; only one possible tag will be
> found.  But my code does an unnecessary revision list in this case.
>
> Where we really get hit is the large number of possible tags.  The
> master branch is turning up 14 tags, some dating back to v1.4.1-rc1.
> I do try to abort the revision list as soon as one of those tags
> cannot give me a better selection than the one I have currently,
> but I still had to generate a revision list to reach that point.

I looked at the algorithm, and after scratching my head for a
while, I finally found it sane (modulo leaks, which I think I
fixed with the attached patch).

One minor problem that you inherited from the original algorithm
is the name priority.  If you have an annotated tag A and a
lightweight tag b, and ask "git describe --tags" in this graph:

    ---o---o---o---o---x
           A   b

you would still want to describe 'x' with A, not b.
Unfortunately you don't (and the original doesn't either).

I think this is probably easy to solve in the loop that finds
"all_matches"; once you hit an annotated tag, your traversal
should stop in any case.  But if you were asked for --tags, and
if your "initialized" piece did find both lightweight and
annotated tags, you do not stop when you saw a lightweight one,
but keep looking for an annotated one, ignoring any further
lightweight ones.

Another thought.  I often do "git describe maint master next
pu", and I see an opportunity for optimizing for such a
multi-ref query.  Once you traversed the commits in
"all_matches" loop, you know which strands of pearls are
reachable to what tags, so you could hang that information
somewhere (perhaps ->utils) in each commit.  But I think
optimizing for a multi-ref query is probably not worth it.


-- >8 --
[PATCH] plug a few leaks in revision walking used in describe.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 builtin-describe.c |    1 +
 revision.c         |    8 +++++---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/builtin-describe.c b/builtin-describe.c
index d65c7d2..a8c98ce 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -183,6 +183,7 @@ static void describe(const char *arg, int last_one)
 			cur_match->depth++;
 		if (!min_match || cur_match->depth < min_match->depth)
 			min_match = cur_match;
+		free_commit_list(revs.commits);
 	}
 	printf("%s-g%s\n", min_match->name->path,
 		   find_unique_abbrev(cmit->object.sha1, abbrev));
diff --git a/revision.c b/revision.c
index 1e3b29a..f2ddd95 100644
--- a/revision.c
+++ b/revision.c
@@ -1121,21 +1121,23 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
 void prepare_revision_walk(struct rev_info *revs)
 {
 	int nr = revs->pending.nr;
-	struct object_array_entry *list = revs->pending.objects;
+	struct object_array_entry *e, *list;
 
+	e = list = revs->pending.objects;
 	revs->pending.nr = 0;
 	revs->pending.alloc = 0;
 	revs->pending.objects = NULL;
 	while (--nr >= 0) {
-		struct commit *commit = handle_commit(revs, list->item, list->name);
+		struct commit *commit = handle_commit(revs, e->item, e->name);
 		if (commit) {
 			if (!(commit->object.flags & SEEN)) {
 				commit->object.flags |= SEEN;
 				insert_by_date(commit, &revs->commits);
 			}
 		}
-		list++;
+		e++;
 	}
+	free(list);
 
 	if (revs->no_walk)
 		return;

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

[Junio C Hamano]

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

> BTW I am not quite sure if you missed this patch: 
> http://thread.gmane.org/gmane.comp.version-control.git/36212/, or if you 
> did not like it, want enhancements, ...

It is still sitting in my in-box; I tend to agree with Shawn in
that mixing the reflog sequence and true parenthood in the same
traversal is kind of insane.  I vaguely recall you thought
dropping that would make the code simpler, and was kind of
waiting for that to happen to review the results.

Also I did not quite understand your comment about circular log
entries.

When you walk the reflog, the entries are by definition a single
strand of pearls (reflog itself is a flat text file which you
read linearly).  The commits adjacent entries talk about may or
may not be related at all, and two entries may happen to point
at the same commit.  But I do not think the appearance of
another reflog entry in an earlier call to get_revision() should
not cause a reflog entry to be dropped from the output only
because it points at the same commit.

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

[Johannes Schindelin]

Hi,

On Thu, 11 Jan 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > BTW I am not quite sure if you missed this patch: 
> > http://thread.gmane.org/gmane.comp.version-control.git/36212/, or if you 
> > did not like it, want enhancements, ...
> 
> It is still sitting in my in-box; I tend to agree with Shawn in
> that mixing the reflog sequence and true parenthood in the same
> traversal is kind of insane.

Okay.

> I vaguely recall you thought dropping that would make the code simpler, 
> and was kind of waiting for that to happen to review the results.

I was kind of waiting if somebody actually cares.

> Also I did not quite understand your comment about circular log
> entries.

But you did! My comment was only that I did not test if it actually works 
as expected.

Ciao,
Dscho

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

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> I looked at the algorithm, and after scratching my head for a
> while, I finally found it sane (modulo leaks, which I think I
> fixed with the attached patch).

Thanks.  I don't think it says much for the quality of my code
if you had to scratch your head before you understood it.  But
at least you finally got it.  :)
 
> One minor problem that you inherited from the original algorithm
> is the name priority.  If you have an annotated tag A and a
> lightweight tag b, and ask "git describe --tags" in this graph:
> 
>     ---o---o---o---o---x
>            A   b
> 
> you would still want to describe 'x' with A, not b.
> Unfortunately you don't (and the original doesn't either).

Actually I think you want to describe it with b.  If you ask
'--tags' then you want the lightweight ones too.  In the case above
the lightweight tag b better describes x as it has more in common
with x than A has.

> I think this is probably easy to solve in the loop that finds
> "all_matches"; once you hit an annotated tag, your traversal
> should stop in any case.  But if you were asked for --tags, and
> if your "initialized" piece did find both lightweight and
> annotated tags, you do not stop when you saw a lightweight one,
> but keep looking for an annotated one, ignoring any further
> lightweight ones.

I just implemented this in that loop, and then realized what
I wrote above.  The lower loop that performs the revision list
traversal would have both A and b in all_matches and b would win,
as its closer to x.  So having the first loop abort when it does
is the right thing to do, and so is describing x with b.

> Another thought.  I often do "git describe maint master next
> pu", and I see an opportunity for optimizing for such a
> multi-ref query.  Once you traversed the commits in
> "all_matches" loop, you know which strands of pearls are
> reachable to what tags, so you could hang that information
> somewhere (perhaps ->utils) in each commit.  But I think
> optimizing for a multi-ref query is probably not worth it.

Without my patch its ~170ms; with my patch its ~1000ms.  That is
a huge difference for such a simple program.  I'm not sure your
optimization will make a big difference.  The bulk of the cost
appears to be in the later loop, not in the earlier one that
produces all_matches.

-- 
Shawn.

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

[Nicolas Pitre]

On Thu, 11 Jan 2007, Andreas Ericsson wrote:

> Shawn O. Pearce wrote:
> > Where we really get hit is the large number of possible tags.  The
> > master branch is turning up 14 tags, some dating back to v1.4.1-rc1.
> > I do try to abort the revision list as soon as one of those tags
> > cannot give me a better selection than the one I have currently,
> > but I still had to generate a revision list to reach that point.
> > 
> 
> It could be worth skipping tags more than 6 months older than current
> branch-head. That would, at least for the git case, cut the number of tags
> down by a considerable amount.

This is bound to be wrong in some cases if a project is very active with 
many tags, or if there was a long period of inactivity. And what would 
be the benefit?  Saving 250ms on git-describe output latency?


Nicolas

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

[Andreas Ericsson]

Nicolas Pitre wrote:
> On Thu, 11 Jan 2007, Andreas Ericsson wrote:
> 
>> Shawn O. Pearce wrote:
>>> Where we really get hit is the large number of possible tags.  The
>>> master branch is turning up 14 tags, some dating back to v1.4.1-rc1.
>>> I do try to abort the revision list as soon as one of those tags
>>> cannot give me a better selection than the one I have currently,
>>> but I still had to generate a revision list to reach that point.
>>>
>> It could be worth skipping tags more than 6 months older than current
>> branch-head. That would, at least for the git case, cut the number of tags
>> down by a considerable amount.
> 
> This is bound to be wrong in some cases if a project is very active with 
> many tags, or if there was a long period of inactivity. And what would 
> be the benefit?  Saving 250ms on git-describe output latency?
> 

Output latency will grow with number of tags though, won't it? I was 
thinking of the repo which users had reported problems fetching tags 
from, as there was more than 2k tags. If my memory serves me correctly, 
this report led to the packed-refs stuff.

Unless there's some bogosity going on that leads to it finding the 14 
tags in the above case.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

>> One minor problem that you inherited from the original algorithm
>> is the name priority.  If you have an annotated tag A and a
>> lightweight tag b, and ask "git describe --tags" in this graph:
>> 
>>     ---o---o---o---o---x
>>            A   b
>> 
>> you would still want to describe 'x' with A, not b.
>> Unfortunately you don't (and the original doesn't either).
>
> Actually I think you want to describe it with b.  If you ask
> '--tags' then you want the lightweight ones too.  In the case above
> the lightweight tag b better describes x as it has more in common
> with x than A has.

The reason why I would run the command with --tags is to cope
with this kind of graph.

             o---o---o---x
            /
    ---o---o---o---o---o---y
       b       A

in order to use lightweight ones as a back-up.  Otherwise we
would not have had the "prio" business there.

And I would prefer if the presense of lightweight 'c' tag did
not change how 'y' is described:


             o---o---o---x
            /
    ---o---o---o---o---o---y
       b       A       c

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

[Shawn O. Pearce]

Andreas Ericsson <ae@op5.se> wrote:
> Output latency will grow with number of tags though, won't it? I was 
> thinking of the repo which users had reported problems fetching tags 
> from, as there was more than 2k tags. If my memory serves me correctly, 
> this report led to the packed-refs stuff.

Only on tags which are considered possible matches.  What we do
now is we walk back along the commit history until we find a commit
which has a tag pointing at it.  As soon as we find that commit we
enqueue its corresponding tag into a list and completely ignore its
parents, aborting listing any further back.  So we really only pay
the bare minimum price here.

Unfortunately the tag matching is O(n*m*q) where:

  n == number of tags,
  m == number of commits we have to walk back before we find a tag,
  q == number of possible tags that will match for this lineage.

Storing the tags in a hash structure would accelerate this matching,
especially for high values of n.  m and q we cannot do anything
about, except to recommend to projects that they tag more than
often then never.

> Unless there's some bogosity going on that leads to it finding the 14 
> tags in the above case.

Yea, its a bogosity in the way the branches are merged together.
I haven't dug into what is causing this specifically in git.git
but I know the code is doing the best it can to select the smallest
set of possible matches.

There is however a better algorithm for the revision list generation;
I think I can fold it into the main walkback loop and still get the
right result.  I have to read a stack of papers tonight but I'll
see if I can try to code up the algorithm.  It would accelerate
git-describe right back to where it was before my change.

-- 
Shawn.

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

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> The reason why I would run the command with --tags is to cope
> with this kind of graph.
> 
>              o---o---o---x
>             /
>     ---o---o---o---o---o---y
>        b       A

Why isn't that the default?
 
> in order to use lightweight ones as a back-up.  Otherwise we
> would not have had the "prio" business there.
> 
> And I would prefer if the presense of lightweight 'c' tag did
> not change how 'y' is described:
> 
> 
>              o---o---o---x
>             /
>     ---o---o---o---o---o---y
>        b       A       c

If we just make '--tags' the default and fix the priority to always
pick an annotated tag over a lightweight one then things make sense.
We'd automatically pickup b above for x but always A for y.

-- 
Shawn.

What's cooking in git.git (topics)

[Junio C Hamano]

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

* js/reflog (Thu Jan 11 11:47:48 2007 +0100) 1 commit
 - Teach the revision walker to walk by reflogs with --walk-reflogs

It appears to show list of commits with reflog messages, but I
am not sure how useful it is until I get used to its output.

One question I keep asking reflog has been:

	When was commit X pushed out as part of 'master'?

I have reflog on a tracking branch that I fetch from the public
git.git repository immediately after I push into it, so it is a
matter of walking the reflog for that branch and see which one
is the earliest one that is a descendant of the commit in
question.  It does not tell me about the mirroring lags, but at
least let me keep track of when I pushed something out.


* jc/merge-base (Tue Jan 9 02:23:42 2007 -0800) 6 commits
 - Teach "git-merge-base --check-ancestry" about refs.
 - git-merge-base: --check-ancestry option
 + in_merge_bases(): optimization
 + merge_base(): move traversal into a separate function.
 + Allow in_merge_bases() to take more than one reference commits.
 + Make merge-base a built-in.
* sp/merge (Thu Dec 28 02:35:17 2006 -0500) 2 commits
 - Avoid git-fetch in `git-pull .` when possible.
 + Improve merge performance by avoiding in-index merges.
* 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
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

These are on hold.

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

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Only on tags which are considered possible matches.  What we do
> now is we walk back along the commit history until we find a commit
> which has a tag pointing at it.  As soon as we find that commit we
> enqueue its corresponding tag into a list and completely ignore its
> parents, aborting listing any further back.  So we really only pay
> the bare minimum price here.

This actually is QUITE bad.

With the tip of linux-2.6 repository, v1.4.4 series takes 0.03s
while v1.5.0-rc1 takes about 3.6s.  That is 100x fold, not just
4x.

It turns out that to describe 0404f87f (tip of linux-2.6) the
new one picks up 61 tags in the posible-tag loop.

Since this loop uses the usual date-order, we can limit the
number of candidate tags without losing too much precision.
When limiting the candidates to only 6 (attached patch), the
time drops to 0.25s.

--- 
diff --git a/builtin-describe.c b/builtin-describe.c
index a8c98ce..a1ecec2 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -12,6 +12,7 @@ static const char describe_usage[] =
 
 static int all;	/* Default to annotated tags only */
 static int tags;	/* But allow any tags if --tags is specified */
+static int debug;
 
 static int abbrev = DEFAULT_ABBREV;
 
@@ -113,6 +114,7 @@ static void describe(const char *arg, int last_one)
 	static int initialized = 0;
 	struct commit_name *n;
 	struct possible_tag *all_matches, *min_match, *cur_match;
+	int cnt;
 
 	if (get_sha1(arg, sha1))
 		die("Not a valid object name %s", arg);
@@ -136,6 +138,7 @@ static void describe(const char *arg, int last_one)
 	all_matches = NULL;
 	cur_match = NULL;
 	commit_list_insert(cmit, &list);
+	cnt = 6;
 	while (list) {
 		struct commit *c = pop_commit(&list);
 		n = match(c);
@@ -148,6 +151,8 @@ static void describe(const char *arg, int last_one)
 			else
 				all_matches = p;
 			cur_match = p;
+			if (--cnt <= 0)
+				break;
 		} else {
 			struct commit_list *parents = c->parents;
 			while (parents) {
@@ -161,6 +166,18 @@ static void describe(const char *arg, int last_one)
 			}
 		}
 	}
+	if (list)
+		free_commit_list(list);
+
+	if (debug) {
+		int cnt = 0;
+		for (cur_match = all_matches;
+		     cur_match;
+		     cur_match = cur_match->next)
+			cnt++;
+		fprintf(stderr, "%d candidates for %s\n", cnt,
+			sha1_to_hex(cmit->object.sha1));
+	}
 
 	if (!all_matches)
 		die("cannot describe '%s'", sha1_to_hex(cmit->object.sha1));
@@ -210,6 +227,8 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
 			all = 1;
 		else if (!strcmp(arg, "--tags"))
 			tags = 1;
+		else if (!strcmp(arg, "--debug"))
+			debug = 1;
 		else if (!strncmp(arg, "--abbrev=", 9)) {
 			abbrev = strtoul(arg + 9, NULL, 10);
 			if (abbrev < MINIMUM_ABBREV || 40 < abbrev)

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

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> With the tip of linux-2.6 repository, v1.4.4 series takes 0.03s
> while v1.5.0-rc1 takes about 3.6s.  That is 100x fold, not just
> 4x.
> 
> It turns out that to describe 0404f87f (tip of linux-2.6) the
> new one picks up 61 tags in the posible-tag loop.
> 
> Since this loop uses the usual date-order, we can limit the
> number of candidate tags without losing too much precision.
> When limiting the candidates to only 6 (attached patch), the
> time drops to 0.25s.

OK.  Apply your patch to master.  3.6s is insane, even for
git-describe. I think your guess of 6 is reasonable, but I'd
obviously like to remove the need for it entirely.

I think I have a sketch in my head for an algorithm that can
compute the revision counts while in the possible-tag loop, which
would completely remove the huge cost of the per-tag revision
list later on.  I can't work on it right now (need to get other
stuff done before 1 pm Friday) but I will try to code and test it
tomorrow afternoon.  If I'm right I'll send a patch.

-- 
Shawn.

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

[Jakub Narebski]

Shawn O. Pearce wrote:

>> One minor problem that you inherited from the original algorithm
>> is the name priority.  If you have an annotated tag A and a
>> lightweight tag b, and ask "git describe --tags" in this graph:
>> 
>>     ---o---o---o---o---x
>>            A   b
>> 
>> you would still want to describe 'x' with A, not b.
>> Unfortunately you don't (and the original doesn't either).
> 
> Actually I think you want to describe it with b.  If you ask
> '--tags' then you want the lightweight ones too.  In the case above
> the lightweight tag b better describes x as it has more in common
> with x than A has.

Actually I very often want to describe with _annotated_ tags only.
I have few lightweight tags which are former heads (former branches),
few lightweight tags which are branch points or before-merge points,
and are _not_ version tags.

Although perhaps command line switch (to prefer annotated tags to
lightweight tags) would be better...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

What's cooking in git.git (topics)

[Junio C Hamano]

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

* sp/describe (Sat Jan 27 01:54:21 2007 -0500) 3 commits
 - Compute accurate distances in git-describe before output.
 - Update describe documentation.
 - Teach git-describe to display distances from tags.

Meant for 1.5.0, but I haven't reviewed the code fully yet, so
it is parked in 'pu' for now.

* np/dreflog (Fri Jan 26 17:26:11 2007 -0500) 8 commits
 - add reflog when moving HEAD to a new branch
 - create_symref(): do not assume pathname from git_path() persists
   long enough
 - add logref support to git-symbolic-ref
 - move create_symref() past log_ref_write()
 - add reflog entries for HEAD when detached
 - enable separate reflog for HEAD
 - lock_ref_sha1_basic(): remember the original name of a ref when
   resolving it
 - make reflog filename independent from struct ref_lock

Perhaps 1.5.0 material, but I do not think anybody in the
current code pays attention to reflog for HEAD ("HEAD@{....}"
syntax and log or show-branch with -g option would look at the
underlying ref and prune and friends do not protect its
entries), so merge it post 1.5.0 after these issues are fixed.

* jc/fetch (Tue Jan 16 13:43:28 2007 -0800) 5 commits
 - git-fetch: rewrite expand_ref_wildcard in C
 - git-fetch: rewrite another shell loop in C
 - git-fetch: move more code into C.
 - git-fetch--tool: start rewriting parts of git-fetch in C.
 - git-fetch: split fetch_main into fetch_dumb and fetch_native

This is an early attempt to make "fetch between repositories
with thousand refs" go faster, and it seems to work as
advertised.  Backburnered as I do not personally have need for
it and haven't heard much feedback on it.

* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

I kept saying this will wait until February, 6 months after its
counterpart, "part 1", was merged.  That time is just around the
corner and it is becoming tempting to have it in 1.5.0.

* js/reverse (Sat Jan 20 23:04:02 2007 +0100) 1 commit
 + Teach revision machinery about --reverse
* jc/merge-base (Tue Jan 9 02:23:42 2007 -0800) 6 commits
 - Teach "git-merge-base --check-ancestry" about refs.
 - git-merge-base: --check-ancestry option
 + in_merge_bases(): optimization
 + merge_base(): move traversal into a separate function.
 + Allow in_merge_bases() to take more than one reference commits.
 + Make merge-base a built-in.
* sp/merge (Thu Dec 28 02:35:17 2006 -0500) 1 commit
 - Avoid git-fetch in `git-pull .` when possible.
* 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
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.

Will rehash post 1.5.0

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

[Nicolas Pitre]

On Sat, 27 Jan 2007, Junio C Hamano wrote:

> * np/dreflog (Fri Jan 26 17:26:11 2007 -0500) 8 commits
>  - add reflog when moving HEAD to a new branch
>  - create_symref(): do not assume pathname from git_path() persists
>    long enough
>  - add logref support to git-symbolic-ref
>  - move create_symref() past log_ref_write()
>  - add reflog entries for HEAD when detached
>  - enable separate reflog for HEAD
>  - lock_ref_sha1_basic(): remember the original name of a ref when
>    resolving it
>  - make reflog filename independent from struct ref_lock
> 
> Perhaps 1.5.0 material, but I do not think anybody in the
> current code pays attention to reflog for HEAD ("HEAD@{....}"
> syntax and log or show-branch with -g option would look at the
> underlying ref and prune and friends do not protect its
> entries), so merge it post 1.5.0 after these issues are fixed.

I might be partial of course, but I think it is preferable to merge it 
before 1.5.0 since this causes a behavior change.  Currently HEAD@{n} 
inherits the reflog of the branch HEAD is currently on.  With this patch 
serie HEAD@{n} is the true reflog for HEAD regardless of where it is now 
and where it has been independently of the current branch.  Of course I 
consider the later behavior to be more sensible and it might be a good 
idea to give it to 1.5.0 users at the same time as the detached head 
support rather than creating a behavior change later on when reflogs are 
more popular.

I'll look at prune and friend for teaching them about the new reflog 
entries.


Nicolas

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

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Sat, 27 Jan 2007, Junio C Hamano wrote:
>
>> * np/dreflog (Fri Jan 26 17:26:11 2007 -0500) 8 commits
>
> I might be partial of course, but I think it is preferable to merge it 
> before 1.5.0 since this causes a behavior change.  Currently HEAD@{n} 
> inherits the reflog of the branch HEAD is currently on.  With this patch 
> serie HEAD@{n} is the true reflog for HEAD regardless of where it is now 
> and where it has been independently of the current branch.  Of course I 
> consider the later behavior to be more sensible and it might be a good 
> idea to give it to 1.5.0 users at the same time as the detached head 
> support rather than creating a behavior change later on when reflogs are 
> more popular.

My understanding of the situation after your patch (disregarding
the problem that prune and friends may happily break the logs
for detached HEAD), is that if you say "git show HEAD@{...}",
while on a branch, it looks at the log of the current branch but
while on a detached HEAD it shows the log from .git/logs/HEAD.
I have a feeling that this would be confusing.  Ideally, while
on a branch, say 'master', these two should behave differently:

	$ git show 'master@{5.minutes.ago}'
        $ git show 'HEAD@{5.minutes.ago}'

The former talks only about where the tip of that particular
branch were while the latter also should tell you on which
branch you were on.

But then that raises two new problems:

 - We always said: 'HEAD' means the same thing as your current branch.
   This is not true anymore.

 - You do not record which branch you were on in the log for
   HEAD itself (it is merely a dup), so while the latter would
   report which commit you were at, you cannot tell which branch
   you were on (or if your head was detached).

While I am sure that prune problem is solvable, I have a feeling
that it would take some time to iron out the semantic issues
like the above (and I suspect there might be even more).

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

[Nicolas Pitre]

On Sat, 27 Jan 2007, Junio C Hamano wrote:

> My understanding of the situation after your patch (disregarding
> the problem that prune and friends may happily break the logs
> for detached HEAD), is that if you say "git show HEAD@{...}",
> while on a branch, it looks at the log of the current branch but
> while on a detached HEAD it shows the log from .git/logs/HEAD.
> I have a feeling that this would be confusing.  

It would indeed.  But that's not exactly what's happening.

> Ideally, while
> on a branch, say 'master', these two should behave differently:
> 
> 	$ git show 'master@{5.minutes.ago}'
>         $ git show 'HEAD@{5.minutes.ago}'
> 
> The former talks only about where the tip of that particular
> branch were while the latter also should tell you on which
> branch you were on.

Exactly!

Try this script:

git init
echo 1 > foo
git add foo
git commit -m 1
echo 2 > foo
git add foo
git commit -m 2
echo 3 > foo
git add foo
git commit -m 3
git checkout -b otherbranch
echo 4 > foo
git add foo
git commit -m 4
echo 5 > foo
git add foo
git commit -m 5
echo 6 > foo
git add foo
git commit -m 6
git checkout master
echo 7 > foo
git add foo
git commit -m 7
echo 8 > foo
git add foo
git commit -m 8
git checkout otherbranch
git checkout master

Then you should get the following results:

$ git log -g --pretty=oneline master
58cc540d459fc0c796c2eef796b84cb003ebbf3e master@{0}: 8
b68b1cd29ad2d6157174338a3e9f871c59b5aedd master@{1}: 7
9dfb1ec50c44d0057981cccda90ee29c644ae336 master@{2}: 3
014bdcf6604056e1cda8b6d8d88d6c846db73826 master@{3}: 2
007ed39dd47696c4ab8e8ccdfcb536b8e21ec8e7 master@{4}: 1

$ git log -g --pretty=oneline otherbranch
2483023022b3167343670b209a5d98e4f192430a otherbranch@{0}: 6
3ae298d1b258c24dd2180de9b6cdb93148399920 otherbranch@{1}: 5
ca18ea0eb4e1aabde80add1761f74da9136c59ec otherbranch@{2}: 4
9dfb1ec50c44d0057981cccda90ee29c644ae336 otherbranch@{3}: 3

And finally:

$ git log -g --pretty=oneline HEAD
58cc540d459fc0c796c2eef796b84cb003ebbf3e HEAD@{0}: 8
b68b1cd29ad2d6157174338a3e9f871c59b5aedd HEAD@{1}: 7
9dfb1ec50c44d0057981cccda90ee29c644ae336 HEAD@{2}: 3
3ae298d1b258c24dd2180de9b6cdb93148399920 HEAD@{3}: 5
ca18ea0eb4e1aabde80add1761f74da9136c59ec HEAD@{4}: 4
9dfb1ec50c44d0057981cccda90ee29c644ae336 HEAD@{5}: 3
014bdcf6604056e1cda8b6d8d88d6c846db73826 HEAD@{6}: 2
007ed39dd47696c4ab8e8ccdfcb536b8e21ec8e7 HEAD@{7}: 1

OK there is kind of a screw-up with HEAD@{2} since it should have shown 
"6", and I think it should have shown the movement between branches as 
well, but clearly the output for HEAD doesn't depend on the current 
branch already.

> But then that raises two new problems:
> 
>  - We always said: 'HEAD' means the same thing as your current branch.
>    This is not true anymore.

I think reflogs are a different concept from branch history and that we 
should make sure this is well understood.  And since we seem to agree on 
what the ideal behavior should be I think this has to go in before 
1.5.0 in order to avoid changing this behavior later when more people 
are accustomed to reflogs.

>  - You do not record which branch you were on in the log for
>    HEAD itself (it is merely a dup), so while the latter would
>    report which commit you were at, you cannot tell which branch
>    you were on (or if your head was detached).

Well, it _is_ recorded:

$ sed 's/.*\t//' < .git/logs/HEAD
commit (initial): 1
commit: 2
commit: 3
checkout: moving to otherbranch
commit: 4
commit: 5
commit: 6
checkout: moving to master
commit: 7
commit: 8
checkout: moving to otherbranch
checkout: moving to master

> While I am sure that prune problem is solvable, I have a feeling
> that it would take some time to iron out the semantic issues
> like the above (and I suspect there might be even more).

I think that the problem with HEAD@{n} is that it doesn't take all 
entries into account.  For example the log output skips over the "moving 
to" entries.  If that can be fixed then the difference in semantic 
between git-log HEAD and git-log -g HEAD should be obvious enough simply 
looking at the reflog message lines.

The --pretty=oneline output when using -g should probably display the 
reflog message instead of the commit message as well.


Nicolas

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

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> Well, it _is_ recorded:

It is recorded but not in a readily accessible way.  You have to
scan it.

I think the --pretty=oneline change to the git-log walker you
did would help it somewhat.

By the way, I think there is something wrong for an anonymous
user when coming back from detached HEAD to an existing branch.

An user 'u' (who has empty Gecos) on machine 'git.ster' did:

	$ git checkout master^
        $ git checkout -f master

and got these two entries:

9414... f491... u <u@git.ster> 1169971276 -0800 checkout: moving to master^
f491... 9414... u <>        checkout: moving to master

The latter entry is corrupt; adding setup_ident() before
git_config() in builtin-symbolic-ref.c would fix it.

diff --git a/builtin-symbolic-ref.c b/builtin-symbolic-ref.c
index d41b406..c184679 100644
--- a/builtin-symbolic-ref.c
+++ b/builtin-symbolic-ref.c
@@ -27,6 +27,7 @@ int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)
 	int quiet = 0;
 	const char *msg = NULL;
 
+	setup_ident();
 	git_config(git_default_config);
 
 	while (1 < argc) {

But now I am thinking maybe we should rearrange things so that
we do not have to do setup_ident() in each and every programs.

It used to be a sensible way because only commit and tag making
program needed to do so, but with reflog leaving the committer
names from everywhere, it does not make much sense anymore.

-- >8 --
[PATCH] don't force everybody to call setup_ident().

Back when only handful commands that created commit and tag were
the only users of committer identity information it made sense
to explicitly calling setup_ident() to pre-fill the default
value from the gecos information.  But it is much simpler for
programs to make the call automatic when get_ident() is called.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 ident.c                |   51 ++++++++++++++++++++++++++++++++---------------
 builtin-branch.c       |    1 -
 builtin-commit-tree.c  |    1 -
 builtin-log.c          |    1 -
 builtin-update-ref.c   |    1 -
 cache.h                |    1 -
 fetch-pack.c           |    1 -
 http-fetch.c           |    1 -
 http-push.c            |    1 -
 local-fetch.c          |    1 -
 receive-pack.c         |    1 -
 ssh-fetch.c            |    1 -
 var.c                  |    1 -
 13 files changed, 35 insertions(+), 28 deletions(-)

diff --git a/ident.c b/ident.c
index f967790..6de7eea 100644
--- a/ident.c
+++ b/ident.c
@@ -43,19 +43,13 @@ static void copy_gecos(struct passwd *w, char *name, int sz)
 
 }
 
-int setup_ident(void)
+static void copy_email(struct passwd *pw)
 {
-	int len;
-	struct passwd *pw = getpwuid(getuid());
-
-	if (!pw)
-		die("You don't exist. Go away!");
-
-	/* Get the name ("gecos") */
-	copy_gecos(pw, git_default_name, sizeof(git_default_name));
-
-	/* Make up a fake email address (name + '@' + hostname [+ '.' + domainname]) */
-	len = strlen(pw->pw_name);
+	/*
+	 * Make up a fake email address
+	 * (name + '@' + hostname [+ '.' + domainname])
+	 */
+	int len = strlen(pw->pw_name);
 	if (len > sizeof(git_default_email)/2)
 		die("Your sysadmin must hate you!");
 	memcpy(git_default_email, pw->pw_name, len);
@@ -68,13 +62,37 @@ int setup_ident(void)
 		len = strlen(git_default_email);
 		git_default_email[len++] = '.';
 		if (he && (domainname = strchr(he->h_name, '.')))
-			strlcpy(git_default_email + len, domainname + 1, sizeof(git_default_email) - len);
+			strlcpy(git_default_email + len, domainname + 1,
+				sizeof(git_default_email) - len);
 		else
-			strlcpy(git_default_email + len, "(none)", sizeof(git_default_email) - len);
+			strlcpy(git_default_email + len, "(none)",
+				sizeof(git_default_email) - len);
 	}
+}
+
+static void setup_ident(void)
+{
+	struct passwd *pw = NULL;
+
+	/* Get the name ("gecos") */
+	if (!git_default_name[0]) {
+		pw = getpwuid(getuid());
+		if (!pw)
+			die("You don't exist. Go away!");
+		copy_gecos(pw, git_default_name, sizeof(git_default_name));
+	}
+
+	if (!git_default_email[0]) {
+		if (!pw)
+			pw = getpwuid(getuid());
+		if (!pw)
+			die("You don't exist. Go away!");
+		copy_email(pw);
+	}
+
 	/* And set the default date */
-	datestamp(git_default_date, sizeof(git_default_date));
-	return 0;
+	if (!git_default_date[0])
+		datestamp(git_default_date, sizeof(git_default_date));
 }
 
 static int add_raw(char *buf, int size, int offset, const char *str)
@@ -174,6 +192,7 @@ static const char *get_ident(const char *name, const char *email,
 	char date[50];
 	int i;
 
+	setup_ident();
 	if (!name)
 		name = git_default_name;
 	if (!email)
diff --git a/builtin-branch.c b/builtin-branch.c
index b709b2f..869e753 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -395,7 +395,6 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 	int kinds = REF_LOCAL_BRANCH;
 	int i;
 
-	setup_ident();
 	git_config(git_branch_config);
 
 	for (i = 1; i < argc; i++) {
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index 0651e59..2a818a0 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -94,7 +94,6 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
 	unsigned int size;
 	int encoding_is_utf8;
 
-	setup_ident();
 	git_config(git_default_config);
 
 	if (argc < 2)
diff --git a/builtin-log.c b/builtin-log.c
index 56acc13..982d871 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -380,7 +380,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 	char message_id[1024];
 	char ref_message_id[1024];
 
-	setup_ident();
 	git_config(git_format_config);
 	init_revisions(&rev, prefix);
 	rev.commit_format = CMIT_FMT_EMAIL;
diff --git a/builtin-symbolic-ref.c b/builtin-symbolic-ref.c
diff --git a/builtin-update-ref.c b/builtin-update-ref.c
index b34e598..1461937 100644
--- a/builtin-update-ref.c
+++ b/builtin-update-ref.c
@@ -13,7 +13,6 @@ int cmd_update_ref(int argc, const char **argv, const char *prefix)
 	int i, delete;
 
 	delete = 0;
-	setup_ident();
 	git_config(git_default_config);
 
 	for (i = 1; i < argc; i++) {
diff --git a/cache.h b/cache.h
index 2873f9f..3902a14 100644
--- a/cache.h
+++ b/cache.h
@@ -320,7 +320,6 @@ int parse_date(const char *date, char *buf, int bufsize);
 void datestamp(char *buf, int bufsize);
 unsigned long approxidate(const char *);
 
-extern int setup_ident(void);
 extern const char *git_author_info(int);
 extern const char *git_committer_info(int);
 
diff --git a/fetch-pack.c b/fetch-pack.c
index 83a1d7b..c787106 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -670,7 +670,6 @@ int main(int argc, char **argv)
 	struct stat st;
 
 	setup_git_directory();
-	setup_ident();
 	git_config(fetch_pack_config);
 
 	if (0 <= transfer_unpack_limit)
diff --git a/http-fetch.c b/http-fetch.c
index 67dfb0a..efd494a 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -1003,7 +1003,6 @@ int main(int argc, const char **argv)
 	int arg = 1;
 	int rc = 0;
 
-	setup_ident();
 	setup_git_directory();
 	git_config(git_default_config);
 
diff --git a/http-push.c b/http-push.c
index 0a15f53..b128c01 100644
--- a/http-push.c
+++ b/http-push.c
@@ -2299,7 +2299,6 @@ int main(int argc, char **argv)
 	struct ref *ref;
 
 	setup_git_directory();
-	setup_ident();
 
 	remote = xcalloc(sizeof(*remote), 1);
 
diff --git a/local-fetch.c b/local-fetch.c
index cf99cb7..7cfe8b3 100644
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -210,7 +210,6 @@ int main(int argc, const char **argv)
 	char **commit_id;
 	int arg = 1;
 
-	setup_ident();
 	setup_git_directory();
 	git_config(git_default_config);
 
diff --git a/receive-pack.c b/receive-pack.c
index c4a4757..c51f417 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -429,7 +429,6 @@ int main(int argc, char **argv)
 	if (is_repository_shallow())
 		die("attempt to push into a shallow repository");
 
-	setup_ident();
 	git_config(receive_pack_config);
 
 	if (0 <= transfer_unpack_limit)
diff --git a/ssh-fetch.c b/ssh-fetch.c
index 4c172b6..bdf51a7 100644
--- a/ssh-fetch.c
+++ b/ssh-fetch.c
@@ -124,7 +124,6 @@ int main(int argc, char **argv)
 	prog = getenv("GIT_SSH_PUSH");
 	if (!prog) prog = "git-ssh-upload";
 
-	setup_ident();
 	setup_git_directory();
 	git_config(git_default_config);
 
diff --git a/var.c b/var.c
index 39977b9..e585e59 100644
--- a/var.c
+++ b/var.c
@@ -56,7 +56,6 @@ int main(int argc, char **argv)
 	}
 
 	setup_git_directory();
-	setup_ident();
 	val = NULL;
 
 	if (strcmp(argv[1], "-l") == 0) {

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

[Nicolas Pitre]

On Sat, 27 Jan 2007, Nicolas Pitre wrote:

> On Sat, 27 Jan 2007, Junio C Hamano wrote:
> 
> > My understanding of the situation after your patch (disregarding
> > the problem that prune and friends may happily break the logs
> > for detached HEAD), is that if you say "git show HEAD@{...}",
> > while on a branch, it looks at the log of the current branch but
> > while on a detached HEAD it shows the log from .git/logs/HEAD.
> > I have a feeling that this would be confusing.  
> 
> It would indeed.  But that's not exactly what's happening.

Well... It is a mess.  That's not what's happening for git-log 
obviously, but what you describe is indeed the case for git-rev-parse.

There needs to be a dwim_reflog() function that looks for a matching 
reflog file by itself instead of using dwim_ref() and simply prefixing 
the resolved ref with "logs/".  Unfortunately this tackling of reflog 
path built on top of resolve_ref() seems to be a popular assumption and 
chasing and fixing all those cases properly would require more time than 
I can spare right now.


Nicolas

What's cooking in git.git (topics)

[Junio C Hamano]

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

* np/dreflog (Sat Feb 3 23:31:47 2007 -0800) 12 commits
 + show-branch -g: default to the current branch.
 + Let git-checkout always drop any detached head
 + Enable HEAD@{...} and make it independent from the current branch
 + scan reflogs independently from refs
 + add reflog when moving HEAD to a new branch
 + create_symref(): do not assume pathname from git_path() persists
   long enough
 + add logref support to git-symbolic-ref
 + move create_symref() past log_ref_write()
 + add reflog entries for HEAD when detached
 + enable separate reflog for HEAD
 + lock_ref_sha1_basic(): remember the original name of a ref when
   resolving it
 + make reflog filename independent from struct ref_lock

Earlier I predicted that this will not stabilize before 1.5.0
happens, but I was wrong.  I'd like to have this in 1.5.0.  Will
merge to 'master' soon.

Big thanks to Nico.

* ml/gitk (Thu Feb 1 08:46:38 2007 -0500) 2 commits
 - Make gitk work reasonably well on Cygwin.
 - gitk - remove trailing whitespace from a few lines.

Waiting for Paul's blessing, but I might just go ahead and apply
them to my tree before 1.5.0 happens.

* jc/blame (Tue Jan 30 01:11:08 2007 -0800) 1 commit
 - git-blame: no rev means start from the working tree file.

This changes the semantics of "git blame" without the revision
parameter.  It does not annotate HEAD version but annotates the
working tree changes as well.  Since it is a behaviour change,
it might make sense to have it in 1.5.0 if we ever want to do
this.

All the rest are outside of the scope of 1.5.0 and are on hold.

* js/reverse (Sat Jan 20 23:04:02 2007 +0100) 1 commit
 + Teach revision machinery about --reverse
* jc/fetch (Tue Jan 16 13:43:28 2007 -0800) 5 commits
 - git-fetch: rewrite expand_ref_wildcard in C
 - git-fetch: rewrite another shell loop in C
 - git-fetch: move more code into C.
 - git-fetch--tool: start rewriting parts of git-fetch in C.
 - git-fetch: split fetch_main into fetch_dumb and fetch_native
* jc/merge-base (Tue Jan 9 01:32:25 2007 -0800) 4 commits
 + in_merge_bases(): optimization
 + merge_base(): move traversal into a separate function.
 + Allow in_merge_bases() to take more than one reference commits.
 + Make merge-base a built-in.
* sp/merge (Thu Dec 28 02:35:17 2006 -0500) 1 commit
 - Avoid git-fetch in `git-pull .` when possible.
* 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
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

What's cooking in git.git (topics)

[Junio C Hamano]

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

* lt/crlf (Wed Feb 14 14:54:00 2007 -0800) 3 commits
 + t0020: add test for auto-crlf
 + Make AutoCRLF ternary variable.
 + Lazy man's auto-CRLF

I suspect this has quite a long way to go, since the code to do
stacked .gitignore is tightly coupled with the directory walking
code, and the proposed .gitattribute needs to redo that logic;
which hopefully would result in nicer code that can then be used
for handing .gitignore -- so we'll all win.  I think git-apply
codepath needs to be fixed independently from what Linus already
did, but I haven't looked into it deeply yet.

* ap/cvsserver (Tue Feb 13 15:12:45 2007 +0000) 1 commit
 + Have git-cvsserver call hooks/update before really altering the
   ref

This I think is Ok.  Just waiting for Acks from third-party
git-cvsserver users.

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

Stalled.  I think the subroutines in git-fetch--tool are
reusable for rewriting git-fetch entirely in C, but I estimate
I've covered only 30% or so of what is necessary.

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

Stalled.

What's cooking in git.git (topics)

[Junio C Hamano]

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

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

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

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

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

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

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

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

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

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

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

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

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

Stalled.

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

Stalled.

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

[Eric Wong]

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

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

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

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

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

[Alexander Litvinov]

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

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

All other sides of git I am using works well.

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

[Junio C Hamano]

Eric Wong <normalperson@yhbt.net> writes:

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

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

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

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

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

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

This should graduate to 'master' soon.

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

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

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

Cute, but probably can be cleaned up.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Stalled.

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

[Johannes Schindelin]

Hi,

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

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

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

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

Ciao,
Dscho

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

[Junio C Hamano]

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

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

Yes.

What's cooking in git.git (topics)

[Junio C Hamano]

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

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

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

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

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

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

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

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

This is to output logs in the GNU ChangeLog format.

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

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

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

Will cook for some time.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Johannes Schindelin]

Hi,

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

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

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

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

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

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

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

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

Thank you.

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

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

Ciao,
Dscho

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

[Marco Costalba]

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

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

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

[Linus Torvalds]

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

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

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

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

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

		Linus

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

[Junio C Hamano]

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

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

Oh, I certainly would not disagree.

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

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

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

That part I 100% agree ;-).

What's cooking in git.git (topics)

[Junio C Hamano]

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


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

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

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

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

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

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

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

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

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

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

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

Same as above.

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

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

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

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

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

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

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

Stalled.

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

Stalled.

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

Just a reference code.

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

[Matthias Lederhofer]

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

Will you apply the git-init patch too?

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

Here is what I thought about:

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

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

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

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

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

[Julian Phillips]

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

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

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

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

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

-- 
Julian

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

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

[Junio C Hamano]

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

> Here are the topics that have been cooking.

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

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

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

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

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

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

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

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

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

so that you can say:

	$ git checkout foo
        $ git pull

to merge from the local 'master' branch.

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

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

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

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

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


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

rm -fr origin clone

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

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

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

cd clone
echo '* fetching'
time git fetch origin

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

[Junio C Hamano]

Matthias Lederhofer <matled@gmx.net> writes:

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

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

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

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

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

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

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

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

[Matthias Lederhofer]

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

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

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

[Santi Béjar]

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

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

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

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

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

Santi

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

[Junio C Hamano]

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

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

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

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

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

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

[Santi Béjar]

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

[...]

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

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

Santi

What's cooking in git.git (topics)

[Junio C Hamano]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The above are stalled.

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

[Johannes Schindelin]

Hi,

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

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

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

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

Ciao,
Dscho

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

[Junio C Hamano]

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

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

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

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

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

[Johannes Schindelin]

Hi,

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

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

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

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

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

Ciao,
Dscho

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

[Florian Weimer]

* Junio C. Hamano:

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

I think it's still missing documentation.

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

[Junio C Hamano]

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

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

Patches welcome.

What's cooking in git.git (topics)

[Junio C Hamano]

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

All of them are post 1.5.1, as I've tagged -rc3 already.

* fl/doc (Mon Mar 26 23:45:23 2007 -0700) 3 commits
 + Documentation: unbreak user-manual.
 + Documentation: Add version information to man pages
 + Documentation: Replace @@GIT_VERSION@@ in documentation

* post1.5.1/tcltk (Wed Mar 28 04:22:02 2007 -0700) 3 commits
 - Rewrite Tcl/Tk interpreter path for the GUI tools.
 - Add --with-tcltk and --without-tcltk to configure.
 - NO_TCLTK

* post1.5.1/p4 (Tue Mar 27 12:03:43 2007 -0400) 3 commits
 - Remove unused WITH_OWN_SUBPROCESS_PY from RPM spec
 - Added git-p4 package to the list of git RPMs.
 - Add the WITH_P4IMPORT knob to the Makefile.

I think all of the above three are good, but I do not want to
risk changes to the build/release infrastructure after -rc.

* post1.5.1/workdir (Tue Mar 27 00:15:32 2007 +0100) 1 commit
 - contrib/workdir: add a simple script to create a working directory

Nobody is clamoring to have this, although I do not think there
is anything wrong with it (and it is a contrib/ thing).  I just
haven't had time to look at it closely for 'master'/'next' yet.

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

This improves "rev-list --bisect" performance, sometimes
significantly, especially in a repository with long lines of
single-parent commits.

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

This is a beginning of supporting use of different database
backends, other than sqlite, with git-cvsserver.

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

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

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

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

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

The above are stalled.

* jc/blame (Wed Mar 28 02:06:06 2007 -0700) 3 commits
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up

This is so-far-not-so-fruitful optimization attempt to blame.
In oprofile, I see same_suspect() show up quite high; after
experimenting with these (I have another on top of it which is
not in 'pu'), I am starting to suspect that same_suspect() can
just compare the address of two origins --- we need to make sure
nobody creates two origin structure with the same address in a
single scoreboard, which is needed before that happen.  That
makes assign_blame() spend about 5% less time than it currently
does.

What's cooking in git.git (topics)

[Junio C Hamano]

Being in the pre-release freeze, nothing should be cooking in
'next' nor 'pu', and you should not be reading this ;-)

In any case, on the 'master' front there is only one fix since
the last -rc.  Will tag and declare 1.5.1 this Wednesday.  And
after that happens, here is a list of what will come.

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

=======================================
=== To merge immediately post 1.5.1 ===
=======================================

* lt/dirwalk (Fri Mar 30 20:39:30 2007 -0700) 1 commit
 + Optimize directory listing with pathspec limiter.

This is to help "git add single-path" in a huge directory that
does not have .gitignore.

* post1.5.1/tcltk (Fri Mar 30 00:59:43 2007 -0700) 5 commits
 + Optional Tck/Tk: ignore generated files.
 + Eliminate checks of user-specified Tcl/Tk interpreter.
 + Rewrite Tcl/Tk interpreter path for the GUI tools.
 + Add --with-tcltk and --without-tcltk to configure.
 + NO_TCLTK

* post1.5.1/p4 (Thu Mar 29 14:07:47 2007 +0400) 4 commits
 + Added correct Python path to the RPM specfile.
 + Remove unused WITH_OWN_SUBPROCESS_PY from RPM spec
 + Added git-p4 package to the list of git RPMs.
 + Add the WITH_P4IMPORT knob to the Makefile.

Build tweaks.

* post1.5.1/blame.el (Wed Mar 28 18:44:34 2007 +0200) 2 commits
 + git-blame.el: pick a set of random colors for each git-blame turn
 + git-blame.el: separate git-blame-mode to ease maintenance

Emacs.

* fl/doc (Mon Mar 26 23:45:23 2007 -0700) 3 commits
 + Documentation: unbreak user-manual.
 + Documentation: Add version information to man pages
 + Documentation: Replace @@GIT_VERSION@@ in documentation

Add autogenerated version stamp in documentation.

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

Speeding up bisection between v2.6.18..v2.6.20 in the kernel
repository from 22 seconds down to 4 seconds.

===============================
=== Will cook a bit further ===
===============================

* jc/index-output (Sat Mar 31 23:27:41 2007 -0700) 2 commits
 - git-read-tree --index-output=<file>
 - _GIT_INDEX_OUTPUT: allow plumbing to output to an alternative
   index file.

This is to avoid an extra copy during index-jumping commit.
Will merge to 'next' post 1.5.1, and hopefully 'master' soon.

* fl/cvsserver (Sat Mar 31 15:57:47 2007 +0200) 6 commits
 + cvsserver: Use DBI->table_info instead of DBI->tables
 + cvsserver: Abort if connect to database fails
 + cvsserver: Make the database backend configurable
 + cvsserver: Allow to override the configuration per access method
 + cvsserver: Handle three part keys in git config correctly
 + cvsserver: Introduce new state variable 'method'

I do think there is no need to rush this without positive
reports by people who tested with backends other than SQLite.

* jc/checkout (Thu Mar 29 01:23:12 2007 -0700) 4 commits
 - Use BASE index extension in git-commit and git-merge.
 - update-index --{set,get}-base
 - Add BASE index extension.
 - checkout -d: explicitly detach HEAD even when switching to the tip
   of a branch

This lays the foundation to detect and warn cases where the tip
of the current branch is modified underneath you.  Will merge to
'next' post 1.5.1, but this has to wait for motivated people to 
the cases the series currently does not record and/or check the
base where it should, before graduating to 'master'.

* jc/read-tree-df (Thu Mar 15 23:25:22 2007 -0700) 6 commits
 - Fix switching to a branch with D/F when current branch has file D.
 - Fix twoway_merge that passed d/f conflict marker to
   merged_entry().
 - Fix read-tree --prefix=dir/.
 - unpack-trees: get rid of *indpos parameter.
 - unpack_trees.c: pass unpack_trees_options structure to
   keep_entry() as well.
 - add_cache_entry(): removal of file foo does not conflict with
   foo/bar

This series is almost re-done since I sent the initial patch.
The code is much nicer, and I think it is safer.

* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 7 commits
 - Make read-cache.c "the_index" free.
 - Move index-related variables into a structure.
 - Rename add_file_to_index() to add_file_to_cache()
 - Rename static variable write_index to update_index in builtin-
   apply.c
 - Rename internal function "add_file_to_cache" in builtin-update-
   index.c
 - Propagate cache error internal to refresh_cache() via parameter.
 - Fix bogus error message from merge-recursive error path

This defines a structure that bundles active_cache, active_nr,
active_cache_tree and friends, defines a single instance of such
structure "the_index".  All cache access/manipulation functions
in read-cache.c are updated to take a pointer to this structure
to specify which index to operate on.  The traditional functions
are redefined as macros, e.g.

    #define add_cache_entry(ce,opt) add_index_entry(&the_index, (ce), (opt))

This fell out by accident while I was working on jc/read-tree-df
topic.  The largest problem there was that we lose sight of what
was originally in the index, after replacing a set of paths
(e.g. path/a path/b path/c) in the current index with a single
parent path (e.g. "path" becomes a blob) from the other tree.
To solve this, I initially planned to modify unpack_trees() to
read from the current index and build into a separate index, and
that is why I needed this conversion.

But it turns out that I can use a single index to solve that, so
this series is not needed.  But people into libification may
find it interesting.

==========================
=== not ready for next ===
==========================

* jc/blame (Tue Mar 27 01:58:01 2007 -0700) 3 commits
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up

I've been trying to optimize this on and off but haven't made
much progress.

* jc/pathattr (Thu Mar 1 01:20:21 2007 -0800) 5 commits
 - pathattr: allow piping to external program.
 - pathattr: read from git_config().
 - git-show: use pathattr to run "display"
 - pathattr: path based configuration of various attributes.
 + convert: add scaffolding for path based selection of conversion
   routines.
* js/fetch-progress (Sun Feb 25 13:13:17 2007 -0800) 1 commit
 + git-fetch: add --quiet
* jc/merge-subtree (Thu Feb 15 16:32:45 2007 -0800) 1 commit
 - A new merge stragety 'subtree'.
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
 - test-para: combined diff between HEAD, index and working tree.
 - para-walk: walk n trees, index and working tree in parallel

Stalled.

What's cooking in git.git (topics)

[Junio C Hamano]

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

* cc/bisect (Thu Apr 5 05:33:53 2007 +0200) 2 commits
 + Documentation: bisect: "start" accepts one bad and many good
   commits
 + Bisect: teach "bisect start" to optionally use one bad and many
   good revs.

This allows "git bisect start <bad> <good1> <good2>... -- <paths>".

Being able to give more than one good commits upfront may not
happen very often, but when you are, this makes it unnecessary
to avoid an extra whole-tree checkout that happens when you give
a new good commit every time.

Being able to bisect without any good commit is outside of the
scope of this series, but I suspect that it probably is a simple
matter of making "git bisect next", after getting a <bad> commit
but before gettingt a <good> commit, not to barf but warn
(because it would pick an ancient commit and wastes one checkout
if done by mistake), ask confirmation if interactive, and drive
"git-rev-list --bisect".

* fp/make-j (Wed Apr 4 22:42:33 2007 +0200) 1 commit
 + Makefile: Add '+' to QUIET_SUBDIR0 to fix parallel make.

This makes our Makefile more dependent on GNU make, but I think
it already is.

* jc/index-output (Sat Mar 31 23:27:41 2007 -0700) 2 commits
 + git-read-tree --index-output=<file>
 + _GIT_INDEX_OUTPUT: allow plumbing to output to an alternative
   index file.

This is primarily to make index manipulation more efficient and
safer in the codepath to do "git commit <paths>".  Although I
tested the results, I do not know if it breaks things for other
people in real life projects, as I almost never do this "index
jumping" commit myself.  Testing and feedback is appreciated.

I think the above three series are ready for 'master'.

* fl/cvsserver (Sat Mar 31 15:57:47 2007 +0200) 6 commits
 + cvsserver: Use DBI->table_info instead of DBI->tables
 + cvsserver: Abort if connect to database fails
 + cvsserver: Make the database backend configurable
 + cvsserver: Allow to override the configuration per access method
 + cvsserver: Handle three part keys in git config correctly
 + cvsserver: Introduce new state variable 'method'

Although the code looked sane, I do not interact with git
repositories over CVS protocol in real life, so I haven't
personally tested it.  I cannot push this out to 'master'
without positive feedbacks.  Testing needed.

* jc/checkout (Thu Mar 29 01:23:12 2007 -0700) 4 commits
 + Use BASE index extension in git-commit and git-merge.
 + update-index --{set,get}-base
 + Add BASE index extension.
 + checkout: allow detaching to HEAD even when switching to the tip
   of a branch

I've rewritten the bottom commit not to require an explicit -d
option when detaching.  You can say "git checkout master^0"
instead to get a detached head that is at the tip of master.  I
may make that one commit graduate to 'master' earlier than
others.

This series is primarily to make it safer when somebody else
updates the tip of the branch you have currently checked out.
As I said in previous messages, I think the series covers basic
operations fine but there probably are gaps in the coverage.
Motivated volunteers are needed to fill them.

* jc/read-tree-df (Thu Mar 15 23:25:22 2007 -0700) 6 commits
 + Fix switching to a branch with D/F when current branch has file D.
 + Fix twoway_merge that passed d/f conflict marker to
   merged_entry().
 + Fix read-tree --prefix=dir/.
 + unpack-trees: get rid of *indpos parameter.
 + unpack_trees.c: pass unpack_trees_options structure to
   keep_entry() as well.
 + add_cache_entry(): removal of file foo does not conflict with
   foo/bar

I think this fixes the "my branch has foo/bar and I cannot
switch to another branch that has foo as a file" issue better
than the previous attempts.  Heavy testing and reporting is
needed until it graduates to 'master'.

* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits
 - Make read-cache.c "the_index" free.
 - Move index-related variables into a structure.

This libifies the "cache" part of the system.  Parked in 'pu' as
there is no immediate need.

* jc/blame (Tue Mar 27 01:58:01 2007 -0700) 3 commits
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
* jc/pathattr (Thu Mar 1 01:20:21 2007 -0800) 5 commits
 - pathattr: allow piping to external program.
 - pathattr: read from git_config().
 - git-show: use pathattr to run "display"
 - pathattr: path based configuration of various attributes.
 + convert: add scaffolding for path based selection of conversion
   routines.
* js/fetch-progress (Sun Feb 25 13:13:17 2007 -0800) 1 commit
 + git-fetch: add --quiet
* jc/merge-subtree (Thu Feb 15 16:32:45 2007 -0800) 1 commit
 - A new merge stragety 'subtree'.
* 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

These are stalled.

What's cooking in git.git (topics)

[Junio C Hamano]

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

* jc/checkout (Sun Apr 8 22:08:31 2007 -0700) 7 commits
 + Teach git-reset to use index BASE extension.
 + git-read-tree --set-base=<sha1>
 + Use BASE index extension in git-am.
 + Move check_base() shell function to git-sh-setup
 + Use BASE index extension in git-commit and git-merge.
 + update-index --{set,get}-base
 + Add BASE index extension.

This series is primarily to make it safer when somebody else
updates the tip of the branch you have currently checked out.
As I said in previous messages, I think the series covers basic
operations fine but there probably are gaps in the coverage.
Motivated volunteers are needed to fill them.

* fl/cvsserver (Sat Apr 7 16:58:10 2007 +0200) 8 commits
 - cvsserver: Add asciidoc documentation for new database backend
   configuration
 + cvsserver: Corrections to the database backend configuration
 + cvsserver: Use DBI->table_info instead of DBI->tables
 + cvsserver: Abort if connect to database fails
 + cvsserver: Make the database backend configurable
 + cvsserver: Allow to override the configuration per access method
 + cvsserver: Handle three part keys in git config correctly
 + cvsserver: Introduce new state variable 'method'

Although the code looked sane, I do not interact with git
repositories over CVS protocol in real life, so I haven't
personally tested it.  I cannot push this out to 'master'
without positive feedbacks.  Testing needed.

* jc/read-tree-df (Sat Apr 7 07:17:35 2007 -0700) 5 commits
 - t3030: merge-recursive backend test.
 - merge-recursive: handle D/F conflict case more carefully.
 - merge-recursive: do not barf on "to be removed" entries.
 - Treat D/F conflict entry more carefully in unpack-
   trees.c::threeway_merge()
 - t1000: fix case table.

This is a follow-up to "my branch has foo/bar and I cannot
switch to another branch that has foo as a file" series.  It
deals with three-way merges that involve D/F conflicts.  Again,
heavy testing and reporting is needed until it graduates to
'master'.

* jc/quickfetch (Thu Apr 5 03:22:55 2007 -0700) 2 commits
 - git-fetch: use fetch--tool pick-rref to avoid local fetch from
   alternate
 - git-fetch--tool pick-rref

This is to alleviate Linus's worries about "git fetch" from a
repository whose object store is your alternate consuming too
much cycles in the new "SHA-1 collision detection" code, at the
same time avoiding to create a pack that has duplicate objects
in the repository due to the recent "keep" behaviour of
fetch-pack.

* js/wrap-log (Sun Apr 8 01:28:00 2007 -0700) 2 commits
 - shortlog -w: make wrap-line behaviour optional.
 - Use print_wrapped_text() in shortlog

This teaches "git shortlog" to wrap lines that are too long (by
default, 76 columns) when "-w" option is given.

This was resurrected from my held-box.  I do not have an
immediate need for it but somebody might.  Cheering-on and
documentation updates are needed for it to go anywhere.

* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits
 - Make read-cache.c "the_index" free.
 - Move index-related variables into a structure.

This libifies the "cache" part of the system.  Parked in 'pu' as
there is no immediate need, at least for me.

* jc/blame (Tue Mar 27 01:58:01 2007 -0700) 3 commits
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
* jc/pathattr (Thu Mar 1 01:20:21 2007 -0800) 5 commits
 - pathattr: allow piping to external program.
 - pathattr: read from git_config().
 - git-show: use pathattr to run "display"
 - pathattr: path based configuration of various attributes.
 + convert: add scaffolding for path based selection of conversion
   routines.
* 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

These are stalled...

What's cooking in git.git (topics)

[Junio C Hamano]

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

* lt/gitlink (Sun Apr 15 11:14:28 2007 -0700) 17 commits
 + Expose subprojects as special files to "git diff" machinery
 + Fix some "git ls-files -o" fallout from gitlinks
 + Teach "git-read-tree -u" to check out submodules as a directory
 + Teach git list-objects logic to not follow gitlinks
 + Fix gitlink index entry filesystem matching
 + Teach "git-read-tree -u" to check out submodules as a directory
 + Teach git list-objects logic not to follow gitlinks
 + Don't show gitlink directories when we want "other" files
 + Teach git-update-index about gitlinks
 + Teach directory traversal about subprojects
 + Fix thinko in subproject entry sorting
 + Teach core object handling functions about gitlinks
 + Teach "fsck" not to follow subproject links
 + Add "S_IFDIRLNK" file mode infrastructure for git links
 + Add 'resolve_gitlink_ref()' helper function
 + Avoid overflowing name buffer in deep directory structures
 + diff-lib: use ce_mode_from_stat() rather than messing with modes
   manually

Everybody loves when Linus jumps in and gets the ball rolling
for a topic that has been only an idle-talk wishlist with a
minimum set of patches.  Let's see where this goes.

* jc/attr (Sat Apr 14 21:27:20 2007 -0400) 10 commits
 - Document git-check-attr
 - Change attribute negation marker from '!' to '-'.
 - Define a built-in attribute macro "binary".
 - attribute macro support
 + Makefile: add patch-ids.h back in.
 + Fix 'diff' attribute semantics.
 + Fix 'crlf' attribute semantics.
 + Teach 'diff' about 'diff' attribute.
 + Define 'crlf' attribute.
 + Add basic infrastructure to assign attributes to paths

... and I tried to learn from that.  I do not know how
successful I was, though.

But I earlier said that one of the focus of 1.5.2 should be the
gitattributes support.

* fl/cvsserver (Fri Apr 13 18:13:42 2007 +0200) 12 commits
 + config.txt: Add gitcvs.db* variables
 + cvsserver: Document the GIT branches -> CVS modules mapping more
   prominently
 + cvsserver: Reword documentation on necessity of write access
 + cvsserver: Allow to "add" a removed file
 + cvsserver: Add asciidoc documentation for new database backend
   configuration
 + cvsserver: Corrections to the database backend configuration
 + cvsserver: Use DBI->table_info instead of DBI->tables
 + cvsserver: Abort if connect to database fails
 + cvsserver: Make the database backend configurable
 + cvsserver: Allow to override the configuration per access method
 + cvsserver: Handle three part keys in git config correctly
 + cvsserver: Introduce new state variable 'method'

Waiting for Ack's from the field, which unfortunately I haven't
seen any yet.

* np/pack (Tue Apr 10 22:54:36 2007 -0400) 16 commits
 + clean up add_object_entry()
 + tests for various pack index features
 + use test-genrandom in tests instead of /dev/urandom
 + simple random data generator for tests
 + validate reused pack data with CRC when possible
 + allow forcing index v2 and 64-bit offset treshold
 + pack-redundant.c: learn about index v2
 + show-index.c: learn about index v2
 + sha1_file.c: learn about index version 2
 + index-pack: learn about pack index version 2
 + pack-objects: learn about pack index version 2
 + compute object CRC32 with index-pack
 + compute a CRC32 for each object as stored in a pack
 + add overflow tests on pack offset variables
 + make overflow test on delta base offset work regardless of
   variable size
 + get rid of num_packed_objects()

Haven't seen any breakage report so far.  After giving them a
final look, let's push this out to 'master' soonish.

* js/wrap-log (Sun Apr 8 01:28:00 2007 -0700) 2 commits
 + shortlog -w: make wrap-line behaviour optional.
 + Use print_wrapped_text() in shortlog

I do not think it breaks anything but I do not think we are in a
hurry, either.

* jc/read-tree-df (Sat Apr 7 07:17:35 2007 -0700) 5 commits
 + t3030: merge-recursive backend test.
 + merge-recursive: handle D/F conflict case more carefully.
 + merge-recursive: do not barf on "to be removed" entries.
 + Treat D/F conflict entry more carefully in unpack-
   trees.c::threeway_merge()
 + t1000: fix case table.

This series should not matter in practice as I do not think any
project that changes between directory and file is sane, but
people are known to do insane things, and this would help them.

Any comments for or against their graduation to 'master'?

* jc/quickfetch (Thu Apr 5 03:22:55 2007 -0700) 2 commits
 + git-fetch: use fetch--tool pick-rref to avoid local fetch from
   alternate
 + git-fetch--tool pick-rref

This would make fetching from your alternate more efficient by
not fetching any objects (because by definition it is not
necessary).  It doubly matters in this case performance-wise as
the recent code verifies fetched objects that were already in
the repository, which tends to be expensive.

* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits
 - Make read-cache.c "the_index" free.
 - Move index-related variables into a structure.

Sort of "libification", which nobody seems to need right now,
but I did it already and there is no reason to throw away.

* jc/blame (Tue Mar 27 01:58:01 2007 -0700) 4 commits
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
 - blame -s: suppress author name and time.
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
 - test-para: combined diff between HEAD, index and working tree.
 - para-walk: walk n trees, index and working tree in parallel

Stalled.

What's cooking in git.git (topics)

[Junio C Hamano]

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

* np/pack (Mon Apr 16 12:32:13 2007 -0400) 25 commits
 + pack-objects: better check_object() performances
 + add get_size_from_delta()
 + pack-objects: make in_pack_header_size a variable of its own
 + pack-objects: get rid of create_final_object_list()
 + pack-objects: get rid of reuse_cached_pack
 + pack-objects: clean up list sorting
 + pack-objects: rework check_delta_limit usage
 + pack-objects: equal objects in size should delta against newer
   objects
 + pack-objects: optimize preferred base handling a bit
 + clean up add_object_entry()
 + tests for various pack index features
 + use test-genrandom in tests instead of /dev/urandom
 + simple random data generator for tests
 + validate reused pack data with CRC when possible
 + allow forcing index v2 and 64-bit offset treshold
 + pack-redundant.c: learn about index v2
 + show-index.c: learn about index v2
 + sha1_file.c: learn about index version 2
 + index-pack: learn about pack index version 2
 + pack-objects: learn about pack index version 2
 + compute object CRC32 with index-pack
 + compute a CRC32 for each object as stored in a pack
 + add overflow tests on pack offset variables
 + make overflow test on delta base offset work regardless of
   variable size
 + get rid of num_packed_objects()

Nico's "optionally 64-bit pack idx" aka idx format version 2.
I've taken another pass at them and am planning to push them out
on 'master' hopefully this weekend, but a documentation update
that mention the new --index-version option to git-pack-objects
would be nice to have before that happens.

* lt/objalloc (Mon Apr 16 22:13:09 2007 -0700) 3 commits
 - Make the object lookup hash use a "object index" instead of a
   pointer
 + Clean up object creation to use more common code
 + Use proper object allocators for unknown object nodes too

The bottom 2 are genuine clean-ups, and I'd like to push them
out to 'master' this weekend after giving them one last look.

* jc/attr (Wed Apr 18 16:16:37 2007 -0700) 19 commits
 + Fix funny types used in attribute value representation
 + Allow low-level driver to specify different behaviour during
   internal merge.
 + Custom low-level merge driver: change the configuration scheme.
 + Allow the default low-level merge driver to be configured.
 + Custom low-level merge driver support.
 + Add a demonstration/test of customized merge.
 + Allow specifying specialized merge-backend per path.
 + merge-recursive: separate out xdl_merge() interface.
 + Allow more than true/false to attributes.
 + Document git-check-attr
 + Change attribute negation marker from '!' to '-'.
 + Define a built-in attribute macro "binary".
 + attribute macro support
 + Makefile: add patch-ids.h back in.
 + Fix 'diff' attribute semantics.
 + Fix 'crlf' attribute semantics.
 + Teach 'diff' about 'diff' attribute.
 + Define 'crlf' attribute.
 + Add basic infrastructure to assign attributes to paths

You've heard a lot of noises between me and Linus on this one
for the past few days.  Remaining tasks before it can graduate
to 'master' are:

 (1) I haven't decided how to allow the merge driver override
     the decision to punt on symlinks and some other minor
     policy decision merge-recursive hardcodes yet;

 (2) Not enough test coverage;

 (3) No documentation other than my e-mail messages to the list
     and commit log messages as to how you use this stuff;

 (4) Example "low level merge driver" scripts; covering the same
     set of tools git-mergetool knows about would be good.

Help from the list, probably starting from (3) and (4), would
help polish the series and squash any remaining bugs.

We could do $blobid$ only keywords by hooking into this, but
that would involve philosophical discussion and I'd rather
postpone that and have the infrastructure in 'master' first.

* jp/refs (Tue Apr 17 02:42:50 2007 +0100) 1 commit
 + refs.c: add a function to sort a ref list, rather then sorting on
   add
* jc/quickfetch (Mon Apr 16 00:42:29 2007 -0700) 3 commits
 + Make sure quickfetch is not fooled with a previous, incomplete
   fetch.
 + git-fetch: use fetch--tool pick-rref to avoid local fetch from
   alternate
 + git-fetch--tool pick-rref

I think these two topics should graduate to 'master' this
weekend, as I haven't heard any breakage from anybody, and they
do seem to help.

* lt/gitlink (Sun Apr 15 11:14:28 2007 -0700) 17 commits
 + Expose subprojects as special files to "git diff" machinery
 + Fix some "git ls-files -o" fallout from gitlinks
 + Teach "git-read-tree -u" to check out submodules as a directory
 + Teach git list-objects logic to not follow gitlinks
 + Fix gitlink index entry filesystem matching
 + Teach "git-read-tree -u" to check out submodules as a directory
 + Teach git list-objects logic not to follow gitlinks
 + Don't show gitlink directories when we want "other" files
 + Teach git-update-index about gitlinks
 + Teach directory traversal about subprojects
 + Fix thinko in subproject entry sorting
 + Teach core object handling functions about gitlinks
 + Teach "fsck" not to follow subproject links
 + Add "S_IFDIRLNK" file mode infrastructure for git links
 + Add 'resolve_gitlink_ref()' helper function
 + Avoid overflowing name buffer in deep directory structures
 + diff-lib: use ce_mode_from_stat() rather than messing with modes
   manually

Stalled; Alex has a set of tests that should go on top of this
series but I haven't taken a look at it yet.  I think we should
have enough for interested people to start futzing with, and I
am wondering why nobody has sent a note saying "Hey, I did this
using tree objects with commits in it, it works nicely for these
operations but these things are still cumbersome to do and I
need to polish it more".

* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits
 - Make read-cache.c "the_index" free.
 - Move index-related variables into a structure.

A small part of libification; nobody seems to want it.

* jc/blame (Tue Mar 27 01:58:01 2007 -0700) 4 commits
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
 - blame -s: suppress author name and time.

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

Stalled.

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

[Alex Riesen]

Junio C Hamano, Thu, Apr 19, 2007 02:04:13 +0200:
> 
> Stalled; Alex has a set of tests that should go on top of this
> series but I haven't taken a look at it yet.  I think we should
> have enough for interested people to start futzing with, and I
> am wondering why nobody has sent a note saying "Hey, I did this
> using tree objects with commits in it, it works nicely for these
> operations but these things are still cumbersome to do and I
> need to polish it more".
> 

I am setting up a super-repo for my own very private use (small home
server setup). Still working on what _recursive_ tools do I really
need (and fsck is not the most interesting one: git-diff-files is. Am
afraid of releasing a system I wont ever be able to get to the source
of).

It is, as predicted, becoming mostly work on build infrastructure and
integrity checks in the super-project. Being the sole user of this
project I'll definitely miss all the issues of really big modularized
projects, though.

> 
> * jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits
>  - Make read-cache.c "the_index" free.
>  - Move index-related variables into a structure.
> 
> A small part of libification; nobody seems to want it.
> 

No user _can_ want it. We need to make the future less a nightmare (it
may not even become one).

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

[Nicolas Pitre]

On Wed, 18 Apr 2007, Junio C Hamano wrote:

> * np/pack (Mon Apr 16 12:32:13 2007 -0400) 25 commits
> 
> Nico's "optionally 64-bit pack idx" aka idx format version 2.
> I've taken another pass at them and am planning to push them out
> on 'master' hopefully this weekend, but a documentation update
> that mention the new --index-version option to git-pack-objects
> would be nice to have before that happens.

Well... In fact I didn't intend for that option to ever be used by 
anything but test scripts in order to trigger some code paths without 
generating jumbo packs (don't know what people would think of me if I 
created a 8GB pack in my test ;-)).  Therefore I didn't think that 
option was worth documenting.

But if you insist I'll send you a patch.


Nicolas

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

[Martin Waitz]

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

hoi :)

On Wed, Apr 18, 2007 at 05:04:13PM -0700, Junio C Hamano wrote:
> * lt/gitlink (Sun Apr 15 11:14:28 2007 -0700) 17 commits
> 
> Stalled; Alex has a set of tests that should go on top of this
> series but I haven't taken a look at it yet.  I think we should
> have enough for interested people to start futzing with, and I
> am wondering why nobody has sent a note saying "Hey, I did this
> using tree objects with commits in it, it works nicely for these
> operations but these things are still cumbersome to do and I
> need to polish it more".

You know that I am interested, but sadly I don't have as much time to
really have a look / work on it as I'd liked.  But Linus' series
looks very good from what I've seen now.
Conceptually Linus approach is very much identical my prototyping work
and I am convinced that it is the right way to go.  Only his code is
much better (hey, it's Linus after all ;-) and about our branch-vs-HEAD
discussion, well we'll see how it works out.

Now, how to go on?
The next thing we need is a real checkout & merge support -- but that
is not that hard.
Then we need to think about how to handle the submodule object database,
e.g. when fetching.

I'd also like to be able to support bare supermodule repositories which
include all neccessary submodule objects.  But I guess we need some
more experience with submodules before we can solve that in a scalable
way.

-- 
Martin Waitz

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

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

[Junio C Hamano]

Martin Waitz <tali@admingilde.org> writes:

> Now, how to go on?
> The next thing we need is a real checkout & merge support -- but that
> is not that hard.

As git.git is the project that everybody who is interested in
making the feature to materialize fetches, looks at and works on
anyway, once the support at the plumbing level is complete, an
obvious thing to do is to use it in git.git tree itself.

For example, I would like to eventually be able to remove
git-gui/ subdirectory and bind git-gui.git as a subproject.
Another possibility that is probably of a smaller impact is to
bind what is known as 'todo' branch at Meta/ directory, as that
is where I have the branch checked out in my worktree.  People
who are not interested in what are in 'todo' would not mind
having an empty directory there in their checkout, and
interested ones can use the same layout as I do.

Making git.git the first guinea pig has a unique bootstrapping
problem involved, however.  These kind of changes in git.git
itself has to wait at least until what we have in 'next' today
is in everybody's hands.  Otherwise, people who want to use git
for their real work need to first grab a tarball snapshot that
has the plumbing subproject support, and then update to
'master', because we are still too fast moving for any distro
binary packaged version to be satisfactory solution for people
who want to have all the bells and whistles.  Also, I cannot
have subproject in git.git until kernel.org starts running git
with subproject support -- otherwise nobody can clone or pull
from git.git X-<.

If there was a project of lessor importance that can afford to
say "if you want to track this project, you have to use git from
'next', which has not yet been officially released, but we are a
small closely knit group and we can live with this limitation",
it would be easier, but that would not be as effective guinea
pig as git.git itself would be.

Eating our own dog food is how git has evolved since its early
days.  There was no Porcelain to speak of back then; Linus gave
a recipe for keeping track of your work using 'update-index',
'write-tree', 'commit-tree' and 'echo' (we did not even have
'update-ref' to advance the tip of the branch; instead we did
"commit=$(commit-tree) && echo $commit >.git/HEAD"), and people
first followed that recipe, and later wrote a set of thin shell
wrappers around that recipe.

> Then we need to think about how to handle the submodule object
> database, e.g. when fetching.

With the clear separation of connectivity rules between modules,
I do not think this is an issue at all.

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

[Alex Riesen]

On 4/20/07, Junio C Hamano <junkio@cox.net> wrote:
> Making git.git the first guinea pig has a unique bootstrapping
> problem involved, however.  These kind of changes in git.git
> itself has to wait at least until what we have in 'next' today
> is in everybody's hands.

Have you any plans as to when that should begin to happen?
We can warn user if he tries to add a subproject until
porcelain support can be considered usable. It certainly
wont be a problem for early adopters, they know what they're
doing, and an accidental git add of a directory (which by accident
is a git repo all by itself) does not go unnoticed.
Or even disallow it by default (unset dir_struct:dir_links), and
give git add/update-index an option to allow them. We can
reconsider the default later.

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

[Sam Ravnborg]

On Fri, Apr 20, 2007 at 04:14:01AM -0700, Junio C Hamano wrote:
> 
> Making git.git the first guinea pig has a unique bootstrapping
> problem involved, however.  These kind of changes in git.git
> itself has to wait at least until what we have in 'next' today
> is in everybody's hands.  Otherwise, people who want to use git
> for their real work need to first grab a tarball snapshot that
> has the plumbing subproject support, and then update to
> 'master', because we are still too fast moving for any distro
> binary packaged version to be satisfactory solution for people
> who want to have all the bells and whistles.  Also, I cannot
> have subproject in git.git until kernel.org starts running git
> with subproject support -- otherwise nobody can clone or pull
> from git.git X-<.

The bootstrapping issue could be fixed by having a separate
git-subproject.git on kernel.org.

But I see no easy solution for the requireent for kernel.org to
a new git (and I doubt kernel.org sysadmin is too keen to
update to a next-based git).

	Sam

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

[Martin Waitz]

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

hoi :)

On Fri, Apr 20, 2007 at 09:31:42PM +0200, Sam Ravnborg wrote:
> On Fri, Apr 20, 2007 at 04:14:01AM -0700, Junio C Hamano wrote:
> > 
> > Making git.git the first guinea pig has a unique bootstrapping
> > problem involved, however.  These kind of changes in git.git
> > itself has to wait at least until what we have in 'next' today
> > is in everybody's hands.  Otherwise, people who want to use git
> > for their real work need to first grab a tarball snapshot that
> > has the plumbing subproject support, and then update to
> > 'master', because we are still too fast moving for any distro
> > binary packaged version to be satisfactory solution for people
> > who want to have all the bells and whistles.  Also, I cannot
> > have subproject in git.git until kernel.org starts running git
> > with subproject support -- otherwise nobody can clone or pull
> > from git.git X-<.
> 
> The bootstrapping issue could be fixed by having a separate
> git-subproject.git on kernel.org.
> 
> But I see no easy solution for the requireent for kernel.org to
> a new git (and I doubt kernel.org sysadmin is too keen to
> update to a next-based git).

Well, it only needs to be new enough to understand enough of
submodules so that it can play the server part.
So once we are in that part to be stable we can merge it to master,
so that kernel.org can use it.
Full submodule support should then mature until the next major version
after which git.git could use it itself.

-- 
Martin Waitz

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

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

[Linus Torvalds]

On Sat, 21 Apr 2007, Martin Waitz wrote:
> On Fri, Apr 20, 2007 at 09:31:42PM +0200, Sam Ravnborg wrote:
> > 
> > But I see no easy solution for the requireent for kernel.org to
> > a new git (and I doubt kernel.org sysadmin is too keen to
> > update to a next-based git).
> 
> Well, it only needs to be new enough to understand enough of
> submodules so that it can play the server part.

Yes. I don't think kernel.org itself really needs more than already exists 
in 'next': it needs the ability to *serve* projects (and that means doing 
the tree traversal properly and know to stop traversing at gitlink 
entries), but kernel.org itself wouldn't actually need any of the 
porcelain at all. The porcelain would all be used on the client sides.

> So once we are in that part to be stable we can merge it to master,
> so that kernel.org can use it.
> Full submodule support should then mature until the next major version
> after which git.git could use it itself.

Yes. I *think* that the gitlink stuff in 'next' is ready to be merged, if 
only because (a) there really hasn't been any disagreement about it (yeah, 
partly probably simply because it was me writing the patches, but I think 
largely because the patches simply were pretty clean!) and (b) there 
aren't any real downsides either, since it won't actually affect any 
non-gitlink use.

So there's certainly the *possible* downside that the whole approach is 
broken and won't work, and merging something broken is pointless. However, 
we've had people thinking about this for quite so time, and I don't think 
anybody seriously believes that it's not a fairly straightforward 
(although probably time-consuming and painful) thing to do all the 
porcelain stuff and it will "just work". So it's _possible_ that there is 
some roadblock that everybody has just ignored, but that just doesn't seem 
very likely.

So it could stay in 'next' until we have everything else in place too, and
the argument for getting it into master literally boils down to the fact 
that it's probably already in a good enough shape for the server side 
(even if the client side is obviously totally missing, and we may find 
*bugs* that are just hiding because it's not used very actively as a 
result). 

I don't really have a huge strong personal feeling either way. I've not 
thought about the patches lately, partly because I'm just fairly happy 
with the core, and partly because I'm just waiting for somebody else to 
start working on it, and then I'll happily jump in and fix any issues that 
come up.

So I would kind of prefer to get it merged sooner rather than later, but 
it's not a huge deal for me - what's more important is probably that 
somebody else rolls up his sleeves and gets dirty with it too ;)

			Linus

What's cooking in git.git (topics)

[Junio C Hamano]

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

* jc/attr (Sat Apr 21 19:09:02 2007 -0700) 2 commits
 - Add 'ident' conversion.
 - Add 'filter' attribute and external filter driver definition.

This is the remaining "controversial" bits.

* lt/objalloc (Mon Apr 16 22:13:09 2007 -0700) 1 commit
 . Make the object lookup hash use a "object index" instead of a
   pointer
* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits
 - Make read-cache.c "the_index" free.
 - Move index-related variables into a structure.
* jc/blame (Tue Mar 27 01:58:01 2007 -0700) 4 commits
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
 - blame -s: suppress author name and time.
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
 - test-para: combined diff between HEAD, index and working tree.
 - para-walk: walk n trees, index and working tree in parallel

The rest are stalled.

What's cooking in git.git (topics)

[Junio C Hamano]

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

* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits
 + Make read-cache.c "the_index" free.
 + Move index-related variables into a structure.

I gave a brief look at the beginning of libification in
lcapitulino's repository at repo.or.cz, and I think this is
related to his topic, so instead of leaving this in limbo, I'm
planning to merge this in v1.5.2-rc1, hopefully to make the
later merge easier.

* mk/diff (Sun Apr 22 23:56:22 2007 -0700) 6 commits
 - Diff between two blobs should take mode changes into account now.
 - use mode of the tree in git-diff, if <tree>:<file> syntax is used
 - store mode in rev_list, if <tree>:<filename> syntax is used
 - add add_object_array_with_mode
 - add get_sha1_with_mode
 - Add S_IFINVALID mode

This attempts to do something we wanted to do for a long time
(the comment removed from the top of builtin-diff.c with this
series has been there for almost a year).  I haven't tried it
yet myself; it needs a few test.  This may help some parts of
gitweb so it would be desirable if we can fast-track this by
v1.5.2-rc1.

* jc/attr (Sat Apr 21 03:14:13 2007 -0700) 2 commits
 - Add 'filter' attribute and external filter driver definition.
 - Add 'ident' conversion.

As 'ident' conversion is stateless, I do not mind too much
including it in v1.5.2-rc1.  On the other hand, the arbitrary
'filter' is quite contentious, although the character-code
conversion example I gave myself might be a good enough reason
for people to want it.  Undecided.

* lt/objalloc (Mon Apr 16 22:13:09 2007 -0700) 1 commit
 - Make the object lookup hash use a "object index" instead of a
   pointer
* jc/blame (Tue Mar 27 01:58:01 2007 -0700) 4 commits
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
 - blame -s: suppress author name and time.
* 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

These are not considered for v1.5.2.

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

[Nicolas Pitre]

On Mon, 23 Apr 2007, Junio C Hamano wrote:

> As 'ident' conversion is stateless, I do not mind too much
> including it in v1.5.2-rc1.  On the other hand, the arbitrary
> 'filter' is quite contentious, although the character-code
> conversion example I gave myself might be a good enough reason
> for people to want it.  Undecided.

Like I said there are certainly plenty of good (and bad) reasons for 
using this facility, and many of them we might not imagine now.  Since 
the code is already written I think you should include it.


Nicolas

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

[Alex Riesen]

On 4/23/07, Junio C Hamano <junkio@cox.net> wrote:
> * jc/attr (Sat Apr 21 03:14:13 2007 -0700) 2 commits
>  - Add 'filter' attribute and external filter driver definition.
>  - Add 'ident' conversion.
>
> As 'ident' conversion is stateless, I do not mind too much
> including it in v1.5.2-rc1.  On the other hand, the arbitrary
> 'filter' is quite contentious, although the character-code
> conversion example I gave myself might be a good enough reason
> for people to want it.  Undecided.

Can I suggest a config option to completely disable content
munging code? So that people who really care about the
real content, or just don't have the tools for the filters still
can checkout the repos depending on the filters.

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

[Junio C Hamano]

"Alex Riesen" <raa.lkml@gmail.com> writes:

> On 4/23/07, Junio C Hamano <junkio@cox.net> wrote:
>> * jc/attr (Sat Apr 21 03:14:13 2007 -0700) 2 commits
>>  - Add 'filter' attribute and external filter driver definition.
>>  - Add 'ident' conversion.
>>
>> As 'ident' conversion is stateless, I do not mind too much
>> including it in v1.5.2-rc1.  On the other hand, the arbitrary
>> 'filter' is quite contentious, although the character-code
>> conversion example I gave myself might be a good enough reason
>> for people to want it.  Undecided.
>
> Can I suggest a config option to completely disable content
> munging code? So that people who really care about the
> real content, or just don't have the tools for the filters still
> can checkout the repos depending on the filters.

The code may have bugs, but the intent is that you can have this
line in your $GIT_DIR/info/attributes to override whatever
attribute settings used in .gitattributes files that are
in-tree:

	*	!ident !filter

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

[Johannes Schindelin]

Hi,

On Mon, 23 Apr 2007, Alex Riesen wrote:

> On 4/23/07, Junio C Hamano <junkio@cox.net> wrote:
> > * jc/attr (Sat Apr 21 03:14:13 2007 -0700) 2 commits
> >  - Add 'filter' attribute and external filter driver definition.
> >  - Add 'ident' conversion.
> >
> > As 'ident' conversion is stateless, I do not mind too much
> > including it in v1.5.2-rc1.  On the other hand, the arbitrary
> > 'filter' is quite contentious, although the character-code
> > conversion example I gave myself might be a good enough reason
> > for people to want it.  Undecided.
> 
> Can I suggest a config option to completely disable content
> munging code? So that people who really care about the
> real content, or just don't have the tools for the filters still
> can checkout the repos depending on the filters.

In my worldview, these filters are a local thing. Exactly like crlf. So, 
no need for a config option.

Ciao,
Dscho

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

[Alex Riesen]

Junio C Hamano, Mon, Apr 23, 2007 19:15:16 +0200:
> >> As 'ident' conversion is stateless, I do not mind too much
> >> including it in v1.5.2-rc1.  On the other hand, the arbitrary
> >> 'filter' is quite contentious, although the character-code
> >> conversion example I gave myself might be a good enough reason
> >> for people to want it.  Undecided.
> >
> > Can I suggest a config option to completely disable content
> > munging code? So that people who really care about the
> > real content, or just don't have the tools for the filters still
> > can checkout the repos depending on the filters.
> 
> The code may have bugs, but the intent is that you can have this
> line in your $GIT_DIR/info/attributes to override whatever
> attribute settings used in .gitattributes files that are
> in-tree:
> 
> 	*	!ident !filter
> 

Imagine a project which started using the attributes at some point of
time. And imagine developers whose repos suddenly start breaking
because of clueless integrator created a filter which does not work
anywere but his system (typical, really) and didn't tell anyone to
update their configuration (whereas .gitattribute files are in working
trees already).

How do you suggest to distribute filter configurations, BTW?
They are not cloned (can they?)
How about checkout performance impact? (in case they are not active,
of course. You're hosed anyway if the filters used. Especially if you
happen to have real big files).

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

[Junio C Hamano]

Alex Riesen <raa.lkml@gmail.com> writes:

> Imagine a project which started using the attributes at some point of
> time. And imagine developers whose repos suddenly start breaking
> because of clueless integrator created a filter which does not work
> anywere but his system (typical, really) and didn't tell anyone to
> update their configuration (whereas .gitattribute files are in working
> trees already).

That's one of the reasons why only the filter names are assigned
to paths using gitattributes mechanism and what action to take
when a specific filter name is attached to a path is determined
by the config.  Missing filter driver definition in the config
is not an error but makes the filter a no-op passthru.

The content filtering is to massage the content into a shape
that is more convenient for the platform/filesystem/the user to
use.  The keyword here is "more convenient" and not "usable"; in
other words, it is "hanging yourself because we gave you a long
rope" if your project tries to do something with the filtering
mechanism to make your project unusable unless the checkout is
done with specific filter in effect.  So defaulting to passthru
is meant to fall-back on the plain-old inconvenient checkout,
which is not a bad thing.

> How do you suggest to distribute filter configurations, BTW?

The same project description message the participant learn about
the project that says the public repository locations and such,
and perhaps in-tree READ.ME file.

The earlier example I gave would fit this pattern rather well.
If somebody (me) cannot deal with UTF-8 encoded Japanese text
very well, that user personally can mark such a file in
$GIT_DIR/info/attributes as 'filter=utf8-japanese-text' and
define the iconv based filtering driver in $GIT_DIR/config in
the repository that he (me) uses for editing.

In addition, I would most likely have another repository that
does not have the filtering driver defined, and that would be
where I would run the build tools for documentation part, since
the project documentation is supposed to be in UTF-8.  

This is a "purely personal" setting that does not have to be
known to the outside world.  But the filter=utf8-japanese-text
attribute could be shared in-tree if the project has more then
one person with difficulty dealing with UTF-8 encoded Japanese
text.  I may personally edit the file after having iconv convert
to EUC-JP and convert it back to UTF-8 when checking in, but the
other person may use local encoding different from EUC-JP for
editing.  In such a case, only the definition in our config
files are different, and in-tree Documentation/.gitattributes
file would have

	git-lost-found.txt	filter=utf8-japanese-text

which is distributed project-wide.

Repositories used by people who do not have trouble handling
UTF-8 encoded Japanese text would not have any filtering driver
defined for utf8-japanese-text in their $GIT_DIR/config, and
their checkout would be in UTF-8, because of this passthru
behaviour.

> How about checkout performance impact?

Measurement would be interesting; I haven't done it, and that is
one of the smaller reasons I am not particularly keen on pushing
the 'filter' attribute.  Hawk-eyed people might have noticed
that I swapped the order of the series in 'pu' to have 'ident'
first and then 'filter'.

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

[Alex Riesen]

On 4/23/07, Junio C Hamano <junkio@cox.net> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > Imagine a project which started using the attributes at some point of
> > time. And imagine developers whose repos suddenly start breaking
> > because of clueless integrator created a filter which does not work
> > anywere but his system (typical, really) and didn't tell anyone to
> > update their configuration (whereas .gitattribute files are in working
> > trees already).
>
> That's one of the reasons why only the filter names are assigned
> to paths using gitattributes mechanism and what action to take
> when a specific filter name is attached to a path is determined
> by the config.  Missing filter driver definition in the config
> is not an error but makes the filter a no-op passthru.

Fragile. What if content is useless without filter? How does
the user know about the fact so he can work the problem
around?

What if you have multiple filters matching the same path?
(does not seem to be possible. Someone will ask you why)

> The content filtering is to massage the content into a shape
> that is more convenient for the platform/filesystem/the user to
> use.  The keyword here is "more convenient" and not "usable"; in

how can "not usable" be "more convenient"?

> > How do you suggest to distribute filter configurations, BTW?
>
> The same project description message the participant learn about
> the project that says the public repository locations and such,
> and perhaps in-tree READ.ME file.

But there seem to be no way to notice that the READ.ME should
be reread by project participants downstream.

> The earlier example I gave would fit this pattern rather well.
> If somebody (me) cannot deal with UTF-8 encoded Japanese text
> very well, that user personally can mark such a file in
> $GIT_DIR/info/attributes as 'filter=utf8-japanese-text' and
> define the iconv based filtering driver in $GIT_DIR/config in
> the repository that he (me) uses for editing.

which will be a PITA to setup in each and every clone of the
repository, unless it is cloned with the repo.

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

[Johannes Schindelin]

Hi,

On Tue, 24 Apr 2007, Alex Riesen wrote:

> On 4/23/07, Junio C Hamano <junkio@cox.net> wrote:
>
> > The earlier example I gave would fit this pattern rather well.
> > If somebody (me) cannot deal with UTF-8 encoded Japanese text
> > very well, that user personally can mark such a file in
> > $GIT_DIR/info/attributes as 'filter=utf8-japanese-text' and
> > define the iconv based filtering driver in $GIT_DIR/config in
> > the repository that he (me) uses for editing.
> 
> which will be a PITA to setup in each and every clone of the
> repository, unless it is cloned with the repo.

Not if you do it with templates. If it is such a special case that you 
absolutely _need_ filters, and cannot use it without filters, it is 
probably in a very small group. And there, you just setup the templates, 
and voila: you have your filters without much ado.

Ciao,
Dscho

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

[Alex Riesen]

On 4/24/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > which will be a PITA to setup in each and every clone of the
> > repository, unless it is cloned with the repo.
>
> Not if you do it with templates. If it is such a special case that you
> absolutely _need_ filters, and cannot use it without filters, it is
> probably in a very small group. And there, you just setup the templates,
> and voila: you have your filters without much ado.

It can be a very big group. Than, even if it is the only group in the world,
it can complain loud and long enough to become a major annoyance.

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

[Johannes Schindelin]

Hi,

On Tue, 24 Apr 2007, Alex Riesen wrote:

> On 4/24/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > which will be a PITA to setup in each and every clone of the
> > > repository, unless it is cloned with the repo.
> >
> > Not if you do it with templates. If it is such a special case that you 
> > absolutely _need_ filters, and cannot use it without filters, it is 
> > probably in a very small group. And there, you just setup the 
> > templates, and voila: you have your filters without much ado.
> 
> It can be a very big group. Than, even if it is the only group in the 
> world, it can complain loud and long enough to become a major annoyance.

Yes, they can.

And if we can prove that it would have been cleaner and better and more 
stable to do the same without attributes, they will look like a big group 
of total morons.

Ciao,
Dscho

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

[Junio C Hamano]

"Alex Riesen" <raa.lkml@gmail.com> writes:

> On 4/23/07, Junio C Hamano <junkio@cox.net> wrote:
>> ...
>> That's one of the reasons why only the filter names are assigned
>> to paths using gitattributes mechanism and what action to take
>> when a specific filter name is attached to a path is determined
>> by the config.  Missing filter driver definition in the config
>> is not an error but makes the filter a no-op passthru.
>
> Fragile. What if content is useless without filter?

In that case, the project screwed itself and it is not our
problem anymore ;-).

>> The content filtering is to massage the content into a shape
>> that is more convenient for the platform/filesystem/the user to
>> use.  The keyword here is "more convenient" and not "usable"; in
>
> how can "not usable" be "more convenient"?

I think I worded it incorrectly to be misunderstood, but I
couldn't word them better then, I do not know I can word them
better now.

Something could be 1. unusable, or 2. usable.  Among usable
shapes, there are 2-a. inconvenient but usable and 2-b. very
convenient to use.

What I tried to say was that if you use filtering mechanism to
massage contents that is unusable into usable (i.e. crossing
from 1 to 2), you are already misusing the mechanism (but we do
not prevent you because we are only "giving you a long rope").
The filter is meant to be used to cross from 2-a to 2-b.

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

[Alex Riesen]

On 4/24/07, Junio C Hamano <junkio@cox.net> wrote:
> >> The content filtering is to massage the content into a shape
> >> that is more convenient for the platform/filesystem/the user to
> >> use.  The keyword here is "more convenient" and not "usable"; in
> >
> > how can "not usable" be "more convenient"?
>
> I think I worded it incorrectly to be misunderstood, but I
> couldn't word them better then, I do not know I can word them
> better now.
>

You don't have to. I just can't force myself to believe it can be
made useful. I'll shut up for now, and wait until I or someone else
proves the code has negligible negative impact on the normal
usage scenarios.

What's cooking in git.git (topics)

[Junio C Hamano]

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

* jc/attr (Sat Apr 21 03:14:13 2007 -0700) 2 commits
 + Add 'filter' attribute and external filter driver definition.
 + Add 'ident' conversion.

As two people on the list whose judgement on design issues I
trust both say "give them rope is Ok", perhaps I should push
this out to 'master' before v1.5.2-rc1.  I am still worried
about the rope being too long, though, and tried to describe the
intent and limitation in the documentation to prevent users from
hurting themselves, but I do not think the descriptions I have
are good enough yet.

* jc/blame (Fri Apr 27 00:42:15 2007 -0700) 7 commits
 - Apply mailmap in git-blame output.
 - Split out mailmap handling out of shortlog
 - blame: show log as it goes
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
 - blame -s: suppress author name and time.

In addition to the update to use .mailmap, this has the "log"
output that uses the blame machinery Linus suggested.  I think I
know what more are needed to make it more pleasant to use, but
the necessary changes seem a bit too involved.  I might advance
the topic a bit more during the stabilization period for v1.5.2,
but I am planning to leave the actual merge until v1.5.3 cycle.

* lt/objalloc (Mon Apr 16 22:13:09 2007 -0700) 1 commit
 - Make the object lookup hash use a "object index" instead of a
   pointer
* 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

These are stalled.

What's cooking in git.git (topics)

[Junio C Hamano]

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

Well, everything meant for v1.5.2 is in 'master' now.  There is
nothing to see here.

* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
 - blame: show log as it goes
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
* lt/objalloc (Mon Apr 16 22:13:09 2007 -0700) 1 commit
 - Make the object lookup hash use a "object index" instead of a
   pointer
* 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

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

[Linus Torvalds]

On Sun, 29 Apr 2007, Junio C Hamano wrote:
>
> * lt/objalloc (Mon Apr 16 22:13:09 2007 -0700) 1 commit
>  - Make the object lookup hash use a "object index" instead of a
>    pointer

I think you should just drop this. 

You merged the two patches that made this possible, and the third in the 
series isn't really worth it. I can re-create it at will (maybe better) 
now that the core object allocations are all cleaned up, and that patch 
simply didn't give enough of an advantage to be worth it.

Maybe inlining the object index -> ptr conversion would have solved the 
performance regression, but it migth also be something more fundamental, 
like the potential extra cache miss in the converstion part (when looking 
up the allocation block).

So it was interesting to try, but I don't think it's worth carrying around 
considering the results.

		Linus

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

[Junio C Hamano]

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

> On Sun, 29 Apr 2007, Junio C Hamano wrote:
>>
>> * lt/objalloc (Mon Apr 16 22:13:09 2007 -0700) 1 commit
>>  - Make the object lookup hash use a "object index" instead of a
>>    pointer
>
> I think you should just drop this. 

Yeah.  I was mostly concentrating on maint/master for the past
several days, and blindly carrying it around was cheaper than
deciding to drop it in my workflow.

What's cooking in git.git (topics)

[Junio C Hamano]

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

As I have been sick and am mostly concentrating on fixes on
'master' anyway, there aren't much to see here.  Indeed,
'master' and 'next' still have identical trees.

* fl/cvsserver (Wed May 2 02:45:22 2007 +0200) 1 commit
 - cvsserver: Add test cases for git-cvsserver

I need to ask k.org people to install sqlite and
libdvd-sqlite-perl before I can advance this to 'next'.

* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
 - blame: show log as it goes
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up

What's cooking in git.git (topics)

[Junio C Hamano]

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

As before, there is nothing to see here, before v1.5.2 final.

* dh/repack (Tue May 8 13:05:04 2007 -0700) 5 commits
 - git-repack --max-pack-size: add option parsing to enable feature
 - git-repack --max-pack-size: split packs as asked by
   write_{object,one}()
 - git-repack --max-pack-size: write_{object,one}() respect pack
   limit
 - git-repack --max-pack-size: new file statics and code
   restructuring
 - Alter sha1close() 3rd argument to request flush only
* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
 - blame: show log as it goes
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
* 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

What's cooking in git.git (topics)

[Junio C Hamano]

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

* sp/cvsexport (Thu May 10 01:06:36 2007 +0200) 1 commit
 - Optimized cvsexportcommit: calling 'cvs status' once instead of
   once per touched file.

This is waiting for Ack/Nack to make sure there is no unexpected
side effects but I am hoping we can ship v1.5.2 with this.

* dh/pack (Wed May 9 13:56:50 2007 -0700) 3 commits
 + Custom compression levels for objects and packs
 + make "repack -f" imply "pack-objects --no-reuse-object"
 + allow for undeltified objects not to be reused
* tt/gc (Wed May 9 15:48:39 2007 -0400) 1 commit
 + Add --aggressive option to 'git gc'
* np/pack (Wed May 9 14:42:42 2007 -0400) 3 commits
 + deprecate the new loose object header format
 + make "repack -f" imply "pack-objects --no-reuse-object"
 + allow for undeltified objects not to be reused
* sv/checkout (Wed May 9 12:33:20 2007 +0200) 1 commit
 + git-update-ref: add --no-deref option for overwriting/detaching
   ref
* jb/statcolor (Sat May 5 16:48:54 2007 -0400) 1 commit
 + Add colour support in rebase and merge tree diff stats output.

New features, all deemed to be safe.  To merge early after v1.5.2.

* db/remote (Sat May 12 11:46:03 2007 -0400) 3 commits
 - Add handlers for fetch-side configuration of remotes.
 - Move refspec parser from connect.c and cache.h to remote.{c,h}
 - Move remote parsing into a library file out of builtin-push.

Hopefully be in 'next' after v1.5.2; I haven't really played
with it.  The next step would probably be to add some stuff that
use this series in fetch--tool, to further rewrite git-fetch
itself in C, or maybe wholesale rewrite of git-fetch in C.

* dh/repack (Tue May 8 13:05:04 2007 -0700) 5 commits
 - git-repack --max-pack-size: add option parsing to enable feature
 - git-repack --max-pack-size: split packs as asked by
   write_{object,one}()
 - git-repack --max-pack-size: write_{object,one}() respect pack
   limit
 - git-repack --max-pack-size: new file statics and code
   restructuring
 - Alter sha1close() 3rd argument to request flush only

Hopefully will have a series rebased on top of 'master' after
the first batch after v1.5.2 graduates.

* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
 - blame: show log as it goes
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
 - test-para: combined diff between HEAD, index and working tree.
 - para-walk: walk n trees, index and working tree in parallel

Stalled.

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

[Julian Phillips]

On Sun, 13 May 2007, Junio C Hamano wrote:

> * db/remote (Sat May 12 11:46:03 2007 -0400) 3 commits
> - Add handlers for fetch-side configuration of remotes.
> - Move refspec parser from connect.c and cache.h to remote.{c,h}
> - Move remote parsing into a library file out of builtin-push.
>
> Hopefully be in 'next' after v1.5.2; I haven't really played
> with it.  The next step would probably be to add some stuff that
> use this series in fetch--tool, to further rewrite git-fetch
> itself in C, or maybe wholesale rewrite of git-fetch in C.

FWIW, I've got a largely functional C version of git-fetch ... the main 
functionality is there - but it's not complete yet.  In 
addition to some of the non-core functionality being missing 
(e.g. --tags or --no-tags in tagopt), I haven't been keeping 
up with recent updates to fetch/fetch-tool.  I was hoping to 
have it ready for post-1.5.2 - unfortunately I've been rather busy the 
last couple of weeks, and haven't managed to get as far as I'd hoped.

-- 
Julian

  ---
byob, v:
 	Believing Your Own Bull

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

[Junio C Hamano]

Julian Phillips <julian@quantumfyre.co.uk> writes:

> On Sun, 13 May 2007, Junio C Hamano wrote:
>
>> * db/remote (Sat May 12 11:46:03 2007 -0400) 3 commits
>> - Add handlers for fetch-side configuration of remotes.
>> - Move refspec parser from connect.c and cache.h to remote.{c,h}
>> - Move remote parsing into a library file out of builtin-push.
>>
>> Hopefully be in 'next' after v1.5.2; I haven't really played
>> with it.  The next step would probably be to add some stuff that
>> use this series in fetch--tool, to further rewrite git-fetch
>> itself in C, or maybe wholesale rewrite of git-fetch in C.
>
> FWIW, I've got a largely functional C version of git-fetch ... the
> main functionality is there - but it's not complete yet.  In addition
> to some of the non-core functionality being missing (e.g. --tags or
> --no-tags in tagopt), I haven't been keeping up with recent updates to
> fetch/fetch-tool.  I was hoping to have it ready for post-1.5.2 -
> unfortunately I've been rather busy the last couple of weeks, and
> haven't managed to get as far as I'd hoped.

Thanks for the status updates.  Although I do not recall Daniel
saying it explicitly, I have been assuming that his series was
aiming for the same all along.  It might be a good idea for you
two to compare notes sometime between now and v1.5.2?

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

[Julian Phillips]

On Sun, 13 May 2007, Junio C Hamano wrote:

> Julian Phillips <julian@quantumfyre.co.uk> writes:
>
>> On Sun, 13 May 2007, Junio C Hamano wrote:
>>
>>> * db/remote (Sat May 12 11:46:03 2007 -0400) 3 commits
>>> - Add handlers for fetch-side configuration of remotes.
>>> - Move refspec parser from connect.c and cache.h to remote.{c,h}
>>> - Move remote parsing into a library file out of builtin-push.
>>>
>>> Hopefully be in 'next' after v1.5.2; I haven't really played
>>> with it.  The next step would probably be to add some stuff that
>>> use this series in fetch--tool, to further rewrite git-fetch
>>> itself in C, or maybe wholesale rewrite of git-fetch in C.
>>
>> FWIW, I've got a largely functional C version of git-fetch ... the
>> main functionality is there - but it's not complete yet.  In addition
>> to some of the non-core functionality being missing (e.g. --tags or
>> --no-tags in tagopt), I haven't been keeping up with recent updates to
>> fetch/fetch-tool.  I was hoping to have it ready for post-1.5.2 -
>> unfortunately I've been rather busy the last couple of weeks, and
>> haven't managed to get as far as I'd hoped.
>
> Thanks for the status updates.  Although I do not recall Daniel
> saying it explicitly, I have been assuming that his series was
> aiming for the same all along.  It might be a good idea for you
> two to compare notes sometime between now and v1.5.2?

Well, it can't be a bad idea, can it? ;)

Apart from the code itself (which can be found at 
http://git.q42.co.uk/w/fetch2.git), I don't have any actual notes, and 
since I haven't had a chance to work on it for a couple of weeks I'm 
not 100% sure of where I was at - due to lack of time I have tended to 
just spend a few hours adding some missing part when I found the time but 
I don't actually have a TODO list or similar (though I really should).

I'm also out of town with work for the first half of the coming week ... 
but I'm certainly willing to talk about what I have and haven't done.

(Daniel, hope you don't mind me adding you to CC ...)

-- 
Julian

  ---
The cable TV sex channels don't expand our horizons, don't make us better
people, and don't come in clearly enough.
 		-- Bill Maher

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

[Daniel Barkalow]

On Mon, 14 May 2007, Julian Phillips wrote:

> On Sun, 13 May 2007, Junio C Hamano wrote:
> 
> > Thanks for the status updates.  Although I do not recall Daniel
> > saying it explicitly, I have been assuming that his series was
> > aiming for the same all along.  It might be a good idea for you
> > two to compare notes sometime between now and v1.5.2?
> 
> Well, it can't be a bad idea, can it? ;)
> 
> Apart from the code itself (which can be found at
> http://git.q42.co.uk/w/fetch2.git), I don't have any actual notes, and since I
> haven't had a chance to work on it for a couple of weeks I'm not 100% sure of
> where I was at - due to lack of time I have tended to just spend a few hours
> adding some missing part when I found the time but I don't actually have a
> TODO list or similar (though I really should).
> 
> I'm also out of town with work for the first half of the coming week ... but
> I'm certainly willing to talk about what I have and haven't done.

I've actually been largely unsuccessful in figuring out how to do most of 
the fetch logic in C, but I was expecting that somebody would write it if 
the library were available.

I've been working on various little things that are a lot easier if the 
parsing is centralized:

 * update tracking refs on push
 * handle refspec patterns in match_refs so that send-pack/http-push can 
   take them and builtin-push doesn't need to do anything, and can also
   turn --tags into +refs/tags/*:refs/tags/*.

I've also been looking at doing something like your remote_ops, but also 
including something for push, and doing it in another library file (so 
push, fetch, and ls-remote can all share the same dispatch on type of 
url).

> (Daniel, hope you don't mind me adding you to CC ...)

Not at all; I hadn't noticed this thread yet, and it's quite related to 
what I'm working on.

	-Daniel
*This .sig left intentionally blank*

What's cooking in git.git (topics)

[Junio C Hamano]

It probably would be more interesting to look at the earlier
"What's not in 1.5.2" messages, but here is the current status
of my tree on the 'next' and 'pu' front.

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.

* mst/connect (Wed May 16 20:09:41 2007 +0300) 1 commit
 + connect: display connection progress
* db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits
 - Update local tracking refs when pushing
 - Add handlers for fetch-side configuration of remotes.
 - Move refspec parser from connect.c and cache.h to remote.{c,h}
 - Move remote parsing into a library file out of builtin-push.
 + git-update-ref: add --no-deref option for overwriting/detaching
   ref
* dh/repack (Sun May 13 12:47:09 2007 -0700) 9 commits
 - git-repack --max-pack-size: add option parsing to enable feature
 - git-repack --max-pack-size: split packs as asked by
   write_{object,one}()
 - git-repack --max-pack-size: write_{object,one}() respect pack
   limit
 - git-repack --max-pack-size: new file statics and code
   restructuring
 - Alter sha1close() 3rd argument to request flush only
 + Custom compression levels for objects and packs
 + deprecate the new loose object header format
 + make "repack -f" imply "pack-objects --no-reuse-object"
 + allow for undeltified objects not to be reused
* sp/cvsexport (Thu May 10 01:06:36 2007 +0200) 1 commit
 + Optimized cvsexportcommit: calling 'cvs status' once instead of
   once per touched file.
* dh/pack (Wed May 9 13:56:50 2007 -0700) 3 commits
 + Custom compression levels for objects and packs
 + make "repack -f" imply "pack-objects --no-reuse-object"
 + allow for undeltified objects not to be reused
* tt/gc (Wed May 9 15:48:39 2007 -0400) 1 commit
 + Add --aggressive option to 'git gc'
* np/pack (Wed May 9 14:42:42 2007 -0400) 3 commits
 + deprecate the new loose object header format
 + make "repack -f" imply "pack-objects --no-reuse-object"
 + allow for undeltified objects not to be reused
* sv/checkout (Wed May 9 12:33:20 2007 +0200) 1 commit
 + git-update-ref: add --no-deref option for overwriting/detaching
   ref
* jb/statcolor (Sat May 5 16:48:54 2007 -0400) 1 commit
 + Add colour support in rebase and merge tree diff stats output.
* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
 - blame: show log as it goes
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
* 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

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

[Daniel Barkalow]

On Wed, 16 May 2007, Junio C Hamano wrote:

> It probably would be more interesting to look at the earlier
> "What's not in 1.5.2" messages, but here is the current status
> of my tree on the 'next' and 'pu' front.
> 
> 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.
> 
> * db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits
>  - Update local tracking refs when pushing
>  - Add handlers for fetch-side configuration of remotes.
>  - Move refspec parser from connect.c and cache.h to remote.{c,h}
>  - Move remote parsing into a library file out of builtin-push.
>  + git-update-ref: add --no-deref option for overwriting/detaching
>    ref

AFAICT, this isn't really in my topic. Rebased too much, perhaps?

I've also got one more patch ready, which moves refspec pattern matching 
into match_refs, for a net reduction of 50 lines and much simpler logic.

I've also started making Julian Phillips' builtin-fetch use my parser, so 
I might have something ready before too long.

	-Daniel
*This .sig left intentionally blank*

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

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> On Wed, 16 May 2007, Junio C Hamano wrote:
> ...
>> * db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits
>>  - Update local tracking refs when pushing
>>  - Add handlers for fetch-side configuration of remotes.
>>  - Move refspec parser from connect.c and cache.h to remote.{c,h}
>>  - Move remote parsing into a library file out of builtin-push.
>>  + git-update-ref: add --no-deref option for overwriting/detaching
>>    ref
>
> AFAICT, this isn't really in my topic. Rebased too much, perhaps?

You have a new call to lock_any_ref_for_update() in the last
patch in your series, whose function signature is changed by
Sven's "add --no-deref".

Because the latter is already scheduled for 'master' post 1.5.2,
I rebased the remote series on top of it, to adjust to the
change early (i.e. while my memory is still fresh).

That's what

	This was rebased on to Sven's change to lock_any_ref_for_update();

comment was about in the earlier "[2/4] What's not in 1.5.2" message.

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

[Daniel Barkalow]

On Wed, 16 May 2007, Junio C Hamano wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > On Wed, 16 May 2007, Junio C Hamano wrote:
> > ...
> >> * db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits
> >>  - Update local tracking refs when pushing
> >>  - Add handlers for fetch-side configuration of remotes.
> >>  - Move refspec parser from connect.c and cache.h to remote.{c,h}
> >>  - Move remote parsing into a library file out of builtin-push.
> >>  + git-update-ref: add --no-deref option for overwriting/detaching
> >>    ref
> >
> > AFAICT, this isn't really in my topic. Rebased too much, perhaps?
> 
> You have a new call to lock_any_ref_for_update() in the last
> patch in your series, whose function signature is changed by
> Sven's "add --no-deref".
> 
> Because the latter is already scheduled for 'master' post 1.5.2,
> I rebased the remote series on top of it, to adjust to the
> change early (i.e. while my memory is still fresh).
> 
> That's what
> 
> 	This was rebased on to Sven's change to lock_any_ref_for_update();
> 
> comment was about in the earlier "[2/4] What's not in 1.5.2" message.

Oh, okay. I noticed the change, but missed that what it was rebased 
onto wasn't simply in the implicit base for the series, and also didn't 
realize that it was supposed to get listed that way. (I think it would be 
more clear to list merges of depended-on series rather than the contents 
of the series, when the depended-on series is also listed)

	-Daniel
*This .sig left intentionally blank*

What's cooking in git.git (topics)

[Junio C Hamano]

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

------------------------
To graduate immediately after 1.5.2, after 'maint' forks from
it.

* jb/statcolor (Sat May 5 16:48:54 2007 -0400) 1 commit
 + Add colour support in rebase and merge tree diff stats output.

* tt/gc (Wed May 9 15:48:39 2007 -0400) 1 commit
 + Add --aggressive option to 'git gc'

* np/pack (Wed May 9 14:42:42 2007 -0400) 3 commits
 + deprecate the new loose object header format
 + make "repack -f" imply "pack-objects --no-reuse-object"
 + allow for undeltified objects not to be reused

* sv/checkout (Wed May 9 12:33:20 2007 +0200) 1 commit
 + git-update-ref: add --no-deref option for overwriting/detaching
   ref

* mst/connect (Wed May 16 20:09:41 2007 +0300) 1 commit
 + connect: display connection progress

* dh/pack (Wed May 9 13:56:50 2007 -0700) 3 commits
 + Custom compression levels for objects and packs
 + make "repack -f" imply "pack-objects --no-reuse-object"
 + allow for undeltified objects not to be reused

------------------------
To be re-reviewed and then merged to 'next' after 1.5.2.

* db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits
 - Update local tracking refs when pushing
 - Add handlers for fetch-side configuration of remotes.
 - Move refspec parser from connect.c and cache.h to remote.{c,h}
 - Move remote parsing into a library file out of builtin-push.

* dh/repack (Sun May 13 12:47:09 2007 -0700) 9 commits
 - git-repack --max-pack-size: add option parsing to enable feature
 - git-repack --max-pack-size: split packs as asked by
   write_{object,one}()
 - git-repack --max-pack-size: write_{object,one}() respect pack
   limit
 - git-repack --max-pack-size: new file statics and code
   restructuring
 - Alter sha1close() 3rd argument to request flush only

------------------------
I've queued this series only because I trust Pasky, not because I
looked at the code deeply.  I am not sure about this one's use
of JavaScript is acceptable (I haven't looked at the code and do
not even know if that is optional X-<  Yes, I know, My Bad).

* pb/web (Sat May 19 02:13:39 2007 +0200) 6 commits
 - gitweb: Clearly distinguish regexp / exact match searches
 - gitweb: Lift any characters restriction on searched strings
 - git-rev-list: Add regexp tuning options
 - gitweb: Remove git_blame (superseded by git_blame2)
 - gitweb: Extra columns in blame
 - gitweb: Incremental blame

------------------------
On hold.

* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
 - blame: show log as it goes
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up

* 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

What's cooking in git.git (topics)

[Junio C Hamano]

Nothing controversial has been queued since v1.5.2 yet.

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.

* fl/cvsserver (Mon May 21 00:31:58 2007 +0200) 3 commits
 + t9400: Add some basic pserver tests
 + t9400: Add some more cvs update tests
 + t9400: Add test cases for config file handling

Will push this out on 'master' by the end of this week.

* dh/repack (Wed May 23 10:11:33 2007 -0700) 6 commits
 + pack-objects: clarification & option checks for --max-pack-size
 + git-repack --max-pack-size: add option parsing to enable feature
 + git-repack --max-pack-size: split packs as asked by
   write_{object,one}()
 + git-repack --max-pack-size: write_{object,one}() respect pack
   limit
 + git-repack --max-pack-size: new file statics and code
   restructuring
 + Alter sha1close() 3rd argument to request flush only

I've commented on this series in a separate message.  Looks
quite clean modulo a few minor details, which was fixed up this
morning.  Will be in 'master' shortly.

* db/remote (Tue May 15 22:50:19 2007 -0400) 4 commits
 + Update local tracking refs when pushing
 + Add handlers for fetch-side configuration of remotes.
 + Move refspec parser from connect.c and cache.h to remote.{c,h}
 + Move remote parsing into a library file out of builtin-push.

Will need to look at this once more; I do not expect too much
problems with it.

* jc/nodelta (Tue May 22 23:04:49 2007 -0700) 3 commits
 + builtin-pack-objects: remove unnecessary code for no-delta
 + Teach "delta" attribute to pack-objects.
 + pack-objects: pass fullname down to add_object_entry()

I am a bit worried about potential performance penalty that can
come from attribute look-up on big trees, which I've never
measured so far.  Independent measurement would be very much
appreciated, and if it turns out to be too bad, we might want to
discard this.

The remainder is backburnered.

* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits

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

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> * db/remote (Tue May 15 22:50:19 2007 -0400) 4 commits
>  + Update local tracking refs when pushing
>  + Add handlers for fetch-side configuration of remotes.
>  + Move refspec parser from connect.c and cache.h to remote.{c,h}
>  + Move remote parsing into a library file out of builtin-push.
> 
> Will need to look at this once more; I do not expect too much
> problems with it.

I spent all day today working with this series.  Lots of pushing new
branches, deleting existing branches, updating existing branches
across many repositories.  Its an *awesome* change.  I'm really
happy with it.

-- 
Shawn.

What's cooking in git.git (topics)

[Junio C Hamano]

Tonight's 'next' is broken in that it does not seem to be able
to do "git cat-file -t aba170cdb4874b72dd619e6f7bbc13c33295f83".
If you add "1" to the end, it becomes the commit v1.5.2^0.
Bisecting shows "Lazily open pack index files on demand" is the
culprit, so I've reverted it locally (and made sure things
starts working again), but I haven't got around to pushing out
the results yet.  I won't, until tomorrow evening.

I'm a bit tired and it is getting late, so I won't comment on
each of the series.  I am seriously considering about merging
Pasky's applypatch removal soon to 'master'.

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

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

* sp/pack (Tue May 29 02:49:08 2007 -0700) 4 commits
 . Revert "Lazily open pack index files on demand"
 + Attempt to delay prepare_alt_odb during get_sha1
 + Micro-optimize prepare_alt_odb
 + Lazily open pack index files on demand

* pb/am (Thu May 24 19:25:25 2007 -0700) 2 commits
 + Remove git-applypatch
 + git-applymbox: Remove command

* mk/pack (Mon May 28 23:20:59 2007 +0200) 3 commits
 + builtin-pack-object: cache small deltas
 + git-pack-objects: cache small deltas between big objects
 + builtin-pack-objects: don't fail, if delta is not possible

* lh/submodules (Sat May 26 15:56:40 2007 +0200) 1 commit
 + Add git-submodule command

* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
 - Enhance unpack-objects for live repo and large objects

* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
 - blame: show log as it goes
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up

* 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

What's cooking in git.git (topics)

[Junio C Hamano]

Again, 'next' is getting quite lightweight compared to 'master'.
Good time to do "war on whitespace" Marco suggested myself.

'pu' has Shawn's 'pu' from git-gui, to help people experiment
with the proposed blame viewer improvements more easily.  I
personally like it quite a bit.

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

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.

* lh/submodules (Sat Jun 2 03:27:42 2007 +0200) 2 commits
 + Add basic test-script for git-submodule
 + Add git-submodule command

I find this a 'master' material already.  Will merge soon.

* gb/idx (Fri Jun 1 15:18:05 2007 -0400) 1 commit
 + Unify write_index_file functions

Should graduate to 'master' by mid next week.

* pb/am (Thu May 24 19:25:25 2007 -0700) 2 commits
 + Remove git-applypatch
 + git-applymbox: Remove command

Will push out to 'master' soon to see if anybody screams.

* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
 - Enhance unpack-objects for live repo and large objects

I saw nobody other than Dana jump up and down and say we must
have this, so I still parked this in 'pu' without merging it to
'next'.  Maybe a time for a quick poll?

* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
 - blame: show log as it goes
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up

* 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

Backburnered.  Further work on the latter, or something like
that, or something based on (disused) git-merge-tree, is needed
to exonerate Linus from having lied in the following part of his
talk (there is a transcript at http://git.or.cz/gitwiki of his
talk by the way):

    The source code may sometimes look complicated because we
    are very performance centric, I am.  I really care, and
    sometimes to make things go really fast, you have to use
    more complicated algorithms than just checking one file at a
    time.  When you are doing 22,000 file merges, you do not
    want to check one file at a time, you want to check the
    whole tree in one go and say, "Ah they are the same, I do
    not have to do anything".

as we _DO_ currently merge one path at a time.

You _could_ interpret "merge" in his message as applying
millions of patches from Andrew, in which case it is true ---
the cache-tree optimization in the index does help us skipping
the unchanged tree recomputation.  But that does not apply to a
true merge, even when it is a trivial tree-level merge.

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

[Johannes Schindelin]

Hi,

On Sat, 2 Jun 2007, Junio C Hamano wrote:

> * lh/submodules (Sat Jun 2 03:27:42 2007 +0200) 2 commits
>  + Add basic test-script for git-submodule
>  + Add git-submodule command
> 
> I find this a 'master' material already.  Will merge soon.

I agree. Even if I had not time to review it closely, from a cursory look 
it is clean enough. I don't expect any regressions from that.

> * pb/am (Thu May 24 19:25:25 2007 -0700) 2 commits
>  + Remove git-applypatch
>  + git-applymbox: Remove command
> 
> Will push out to 'master' soon to see if anybody screams.

Ack.

> * 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
> 
> Backburnered.

I actually like those two commits, and I always wanted to work on top of 
these, but my new boss keeps me away from Git :-(

Will review, and try to work some more on them in the next three weeks. 
Don't drop them!

As for the complicated source code: I cannot agree. If you have _any_ idea 
about what data structures are about, you will readily recognize what it 
is about. We _could_ be more explicit, but by a huge margin.

(IMHO too many people try to chime in without _any_ clue about the 
difference of hash tables and binary search, and no notion of Landau's 
symbol. We should not necessarily try to accomodate people who are _that_ 
unwilling to work up their theory.)

Ciao,
Dscho

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

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> 'pu' has Shawn's 'pu' from git-gui, to help people experiment
> with the proposed blame viewer improvements more easily.  I
> personally like it quite a bit.

For what its worth, my 'pu' has the same policy as Junio's; it
rebases freely and topics can come and go from it at any time.
But that said, it is certainly suitable for Junio's 'pu'.  :-)

I just pushed an even newer version out a couple of minutes ago.
Now I'm running two passes of git-blame:

	*) Pass 1:  git-blame --incremental
	*) Pass 2:  git-blame -M -C -C --incremental

and the viewer shows them in two columns.  This gives you pretty
quick information about why a change exists, as you get both who
moved the block to where it is, and who originally wrote it.  ;-)

Lots of things still to be worked on in blame, like having it
keep track of what line(s) you are at or are trying to jump to.
I'll try to get to that stuff tonight or tomorrow.

-- 
Shawn.

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

[Nicolas Pitre]

On Sat, 2 Jun 2007, Junio C Hamano wrote:

> * dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
>  - Enhance unpack-objects for live repo and large objects
> 
> I saw nobody other than Dana jump up and down and say we must
> have this, so I still parked this in 'pu' without merging it to
> 'next'.  Maybe a time for a quick poll?

I did provide a followup comment to this patch.  If the concerns I 
raised are addressed then I won't be against such a patch.


Nicolas

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

[Dana How]

On 6/3/07, Nicolas Pitre <nico@cam.org> wrote:
> On Sat, 2 Jun 2007, Junio C Hamano wrote:
> > * dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
> >  - Enhance unpack-objects for live repo and large objects
> >
> > I saw nobody other than Dana jump up and down and say we must
> > have this, so I still parked this in 'pu' without merging it to
> > 'next'.  Maybe a time for a quick poll?
>
> I did provide a followup comment to this patch.  If the concerns I
> raised are addressed then I won't be against such a patch.

Hmm, I thought only your comments about incoherency were
still unaddressed and they applied only to the degunking patch,
but in any case I was planning to improve both patches in similar ways.
I won't be able to do this for a week or two (crunch time here).
I will first review the discussion for each patch in case my memory is wrong.

Thanks,
-- 
Dana L. How  danahow@gmail.com  +1 650 804 5991 cell

What's cooking in git.git (topics)

[Junio C Hamano]

Probably a few topics from the following will graduate to
'master' this weekend, but otherwise I expect that I'll be
extremely slow and won't be doing much git next week.

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.

"pu" also contains "pu" from git-gui as of tonight.

* ar/clone (Wed Jun 6 16:39:05 2007 -0700) 1 commit
 - Fix clone to setup the origin if its name ends with .git

This is meant to be merged to 'maint' as part of 1.5.2.2, but I
am taking things slowly.

* js/merge (Tue Jun 5 03:37:13 2007 +0100) 1 commit
 + git-merge-file: refuse to merge binary files

This series needs to be cherry-picked to 'maint' at some point.

* js/filter (Wed Jun 6 20:38:35 2007 +0200) 8 commits
 + filter-branch: also don't fail in map() if a commit cannot be
   mapped
 + filter-branch: Use rev-list arguments to specify revision ranges.
 + filter-branch: fix behaviour of '-k'
 + filter-branch: use $(($i+1)) instead of $((i+1))
 + chmod +x git-filter-branch.sh
 + filter-branch: prevent filters from reading from stdin
 + t7003: make test repeatable
 + Add git-filter-branch

Johannes & Johannes work well together ;-).  Will push out to
'master' shortly.

* lh/submodule (Wed Jun 6 11:13:02 2007 +0200) 2 commits
 + git-submodule: clone during update, not during init
 + git-submodule: move cloning into a separate function

Will push out to 'master' shortly.

* aj/pack (Sun Jun 3 20:21:41 2007 +0200) 1 commit
 + pack-check: Sort entries by pack offset before unpacking them.

Makes "git fsck --full" go a lot faster.  Will push out to
'master' shortly.

* aw/cvs (Mon Jun 4 10:01:49 2007 +0100) 3 commits
 + cvsimport: add <remote>/HEAD reference in separate remotes more
 + cvsimport: update documentation to include separate remotes option
 + cvsimport: add support for new style remote layout

Makes the ref layout consistent with git managed branches;
git-svn already does this, I think.

* ep/cvstag (Sun Jun 3 02:56:36 2007 -0400) 1 commit
 + Use git-tag in git-cvsimport

Instead of handrolling a tag using lower-level mktag, this uses
git-tag.

* jh/tag (Mon Jun 4 02:54:56 2007 +0200) 6 commits
 + Add fsck_verify_ref_to_tag_object() to verify that refname matches
   name stored in tag object
 + git-mktag tests: Fix and expand the mktag tests according to the
   new tag object structure
 + Documentation/git-mktag: Document the changes in tag object
   structure
 + git-fsck: Do thorough verification of tag objects.
 + git-show: When showing tag objects with no tag name, show tag
   object's SHA1 instead of an empty string
 + Refactor git tag objects; make "tag" header optional; introduce
   new optional "keywords" header

Tag refactoring.  Looking good.

* ml/worktree (Wed Jun 6 23:29:59 2007 +0200) 8 commits
 - setup_git_directory: fix segfault if repository is found in cwd
 - test GIT_WORK_TREE
 - extend rev-parse test for --is-inside-work-tree
 - Use new semantics of is_bare/inside_git_dir/inside_work_tree
 - introduce GIT_WORK_TREE to specify the work tree
 - test git rev-parse
 - rev-parse: introduce --is-bare-repository
 - rev-parse: document --is-inside-git-dir

Allows you to have GIT_DIR environment that points at a
repository at an unrelated location, and still lets you work in
a working tree subdirectory by pointing its root with another
environment variable.  It is an intrusive set of changes.

* ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) 1 commit
 - filter-branch: always export GIT_DIR if it is set

This is "early integration" that depends on two other topics
(GIT_WORK_TREE and filter-branch).  This needs to be merged when
both topics graduate to 'master'.

* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
 - Enhance unpack-objects for live repo and large objects

* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
 - blame: show log as it goes
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up

* 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

What's cooking in git.git (topics)

[Junio C Hamano]

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

* lh/submodule (Tue Jun 12 09:05:21 2007 +0200) 5 commits
 + Add gitmodules(5)
 + git-submodule: give submodules proper names
 + Rename sections from "module" to "submodule" in .gitmodules
 + git-submodule: remember to checkout after clone
 + t7400: barf if git-submodule removes or replaces a file

Soon to be merged to 'master' as 1.5.3 material, but still needs a
trivial fix to the Documentation/gitmodules.txt, though.

* js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits
 + filter-branch: subdirectory filter needs --full-history
 + filter-branch: Simplify parent computation.
 + Teach filter-branch about subdirectory filtering
 + filter-branch: also don't fail in map() if a commit cannot be
   mapped
 + filter-branch: Use rev-list arguments to specify revision ranges.
 + filter-branch: fix behaviour of '-k'
 + filter-branch: use $(($i+1)) instead of $((i+1))
 + chmod +x git-filter-branch.sh
 + filter-branch: prevent filters from reading from stdin
 + t7003: make test repeatable
 + Add git-filter-branch

Soon to be merged to 'master' as 1.5.3 material, but still needs
documentation, and culling of empty side branches.

* fl/cvsserver (Thu Jun 7 16:57:01 2007 +0200) 1 commit
 + cvsserver: Add some useful commandline options

To merge.

* gp/branch (Sat Jun 9 12:40:35 2007 +0000) 1 commit
 + git-branch: cleanup config file when deleting branches

To merge.

* jc/remote (Sat Jun 9 11:01:23 2007 -0700) 6 commits
 + git-push: Update description of refspecs and add examples
 + remote.c: "git-push frotz" should update what matches at the
   source.
 + remote.c: fix "git push" weak match disambiguation
 + remote.c: minor clean-up of match_explicit()
 + remote.c: refactor creation of new dst ref
 + remote.c: refactor match_explicit_refs()

To merge; this is an fix to fairly annoying breakage.

* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit
 + git-svn: allow dcommit to retain local merge information

Hoping to be able to merge it to 'master', as it would be a big
usability improvement for people who use "git to merge because
SVN cannot" (without this, life ater such a merge will
unfortunately be miserable).

* jk/add-empty (Tue Jun 12 23:42:14 2007 +0200) 2 commits
 + builtin-add: simplify (and increase accuracy of) exclude handling
 + dir_struct: add collect_ignored option

Hoping to be able to merge them to 'master', but haven't
convinced myself that these changes are correct.  Help is
appreciated.

* jc/oneline (Mon Jun 11 22:10:55 2007 -0700) 2 commits
 + Extend --pretty=oneline to cover the first paragraph,
 + Lift 16kB limit of log message output

Hoping to be able to merge them to 'master', but haven't
convinced myself that these changes are correct.  Help is
appreciated.

* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits
 - Quiet the output from git-init when cloning, if requested.
 - Add an option to quiet git-init.

Undecided.  I do not have anything against these two patches, as
they are obviously correct.  It's just the fact that nobody
complained my keeping these packed on 'pu' suggests there is not
much desire, and it is an extra option we need to maintain.

* ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200)
 - filter-branch: always export GIT_DIR if it is set
* ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
 - make git barf when an alias changes environment variables
 - setup_git_directory: fix segfault if repository is found in cwd
 - test GIT_WORK_TREE
 - extend rev-parse test for --is-inside-work-tree
 - Use new semantics of is_bare/inside_git_dir/inside_work_tree
 - introduce GIT_WORK_TREE to specify the work tree
 - test git rev-parse
 - rev-parse: introduce --is-bare-repository
 - rev-parse: document --is-inside-git-dir

Undecided.  Some people would want to have a way to have GIT_DIR
point at somewhere unusual and still want to work from within a
subdirectory, which is probably a valid thing to support.  This
is not something I would use myself, so I am mostly worried
about the impact these changes may have on people who do not use
this feature.

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

[Johannes Schindelin]

Hi,

On Wed, 13 Jun 2007, Junio C Hamano wrote:

> * js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits

Isn't that convenient? That's already the second project the two JS'es are 
working together...

> * jc/oneline (Mon Jun 11 22:10:55 2007 -0700) 2 commits
>  + Extend --pretty=oneline to cover the first paragraph,
>  + Lift 16kB limit of log message output
> 
> Hoping to be able to merge them to 'master', but haven't
> convinced myself that these changes are correct.  Help is
> appreciated.

I haven't had a chance to look at the patch yet, but the intention is 
sound.

> * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200)
>  - filter-branch: always export GIT_DIR if it is set
> * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
>  - make git barf when an alias changes environment variables
>  - setup_git_directory: fix segfault if repository is found in cwd
>  - test GIT_WORK_TREE
>  - extend rev-parse test for --is-inside-work-tree
>  - Use new semantics of is_bare/inside_git_dir/inside_work_tree
>  - introduce GIT_WORK_TREE to specify the work tree
>  - test git rev-parse
>  - rev-parse: introduce --is-bare-repository
>  - rev-parse: document --is-inside-git-dir
> 
> Undecided.  Some people would want to have a way to have GIT_DIR
> point at somewhere unusual and still want to work from within a
> subdirectory, which is probably a valid thing to support.  This
> is not something I would use myself, so I am mostly worried
> about the impact these changes may have on people who do not use
> this feature.

Yeah, it is something to worry about. As far as I am concerned, these 
changes are too deep for too obscure a feature.

But then, I see that people need it.

And I can't think of a better way to implement it. So unless somebody 
comes up with a nice solution, I think we should live with it, rather than 
let it simmer in pu.

Ciao,
Dscho

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

[Linus Torvalds]

On Wed, 13 Jun 2007, Johannes Schindelin wrote:
> 
> > * js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits
> 
> Isn't that convenient?

Heh. I heard a perfect Dana Carvey "Isn't that conveeenient" in my head on 
that line (SNL "Church Lady" skits, in case people don't make the 
connection).

Was that intentional, or is it just my brain that is fried?

"Isn't that speecial?"

> That's already the second project the two JS'es are working together...

There's clearly something deeper to this notion of two-letter naming that 
Junio uses.  I used to think it was obviously flawed, but Junio may really 
be onto something here..

			Linus

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

[Matthias Lederhofer]

Junio C Hamano <gitster@pobox.com> wrote:
> * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200)
>  - filter-branch: always export GIT_DIR if it is set
> * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
>  - make git barf when an alias changes environment variables
>  - setup_git_directory: fix segfault if repository is found in cwd
>  - test GIT_WORK_TREE
>  - extend rev-parse test for --is-inside-work-tree
>  - Use new semantics of is_bare/inside_git_dir/inside_work_tree
>  - introduce GIT_WORK_TREE to specify the work tree
>  - test git rev-parse
>  - rev-parse: introduce --is-bare-repository
>  - rev-parse: document --is-inside-git-dir
> 
> Undecided.  Some people would want to have a way to have GIT_DIR
> point at somewhere unusual and still want to work from within a
> subdirectory, which is probably a valid thing to support.  This
> is not something I would use myself, so I am mostly worried
> about the impact these changes may have on people who do not use
> this feature.

The only problem I know of up to now seems the one which happened with
git-filter-branch: if GIT_DIR is set and GIT_WORK_TREE/core.worktree is
set the specified working tree is used instead of cwd.

So for users not using GIT_WORK_TREE/core.worktree there should be no
problem.  There might be problems if someone distributes scripts for
git which expect the old behaviour and the user specified the
worktree.  OTOH the fix is to export GIT_WORK_TREE=. which does not
break the script for older versions of git versions and is quite
short (i.e. should not require any restructuring of the script).

What's cooking in git.git (topics)

[Junio C Hamano]

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

* lt/follow (Tue Jun 19 14:22:46 2007 -0700) 1 commit
 + Finally implement "git log --follow"

Has leaks, and it won't graduate to 'master' without
documentation.

Also I am not convinced its handling of merges is sane.  If you
have an ancestry graph like this, and the commit A renames the
followed path, it would show the file _before_ rename, which is
very good.

      o-------B---A---o----o
                     /  
        o----C------'
    
But the code changes pathspec globally, so when we are looking
at C, it may or may not have that (before-renamed) path there.

At least, the patch is small and would not affect codepath that
does not use this option, so in that sense it is relatively safe
change, though.

* jc/oneline (Fri Jun 15 13:19:07 2007 +0100) 4 commits
 + pp_header(): work around possible memory corruption
 + Fix ALLOC_GROW off-by-one
 + Extend --pretty=oneline to cover the first paragraph,
 + Lift 16kB limit of log message output
* jk/add-empty (Tue Jun 12 23:42:14 2007 +0200) 2 commits
 + builtin-add: simplify (and increase accuracy of) exclude handling
 + dir_struct: add collect_ignored option

Will merge this weekend.

* ns/clone (Sat Jun 16 15:26:08 2007 -0700) 1 commit
 + Cloning from a repo without "current branch"

Will merge this weekend.

* js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits
 + filter-branch: subdirectory filter needs --full-history
 + filter-branch: Simplify parent computation.
 + Teach filter-branch about subdirectory filtering
 + filter-branch: also don't fail in map() if a commit cannot be
   mapped
 + filter-branch: Use rev-list arguments to specify revision ranges.
 + filter-branch: fix behaviour of '-k'
 + filter-branch: use $(($i+1)) instead of $((i+1))
 + chmod +x git-filter-branch.sh
 + filter-branch: prevent filters from reading from stdin
 + t7003: make test repeatable
 + Add git-filter-branch

Will merge this weekend.

* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit
 + git-svn: allow dcommit to retain local merge information

Haven't heard major breakage report, so hopefully can merge by
the end of the month.

* ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
 + make git barf when an alias changes environment variables
 + setup_git_directory: fix segfault if repository is found in cwd
 + test GIT_WORK_TREE
 + extend rev-parse test for --is-inside-work-tree
 + Use new semantics of is_bare/inside_git_dir/inside_work_tree
 + introduce GIT_WORK_TREE to specify the work tree
 + test git rev-parse
 + rev-parse: introduce --is-bare-repository
 + rev-parse: document --is-inside-git-dir

I've been resisting this but I think its definition of is-bare
is a bit saner than what we have in 'master', and I think it is
the right direction in the longer term.  HOWEVER, I am not sure
about the implementation and corner cases, e.g. what should it
do in receive-pack?  You cannot rely on user setting GIT_WORK_TREE
environment -- rather, receive-pack is responsible for setting
up a sane environment for other commands to work in.

* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits
 - Quiet the output from git-init when cloning, if requested.
 - Add an option to quiet git-init.

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

[Linus Torvalds]

On Thu, 21 Jun 2007, Junio C Hamano wrote:
> 
> Also I am not convinced its handling of merges is sane.  If you
> have an ancestry graph like this, and the commit A renames the
> followed path, it would show the file _before_ rename, which is
> very good.
> 
>       o-------B---A---o----o
>                      /  
>         o----C------'

I agree. That's even what I tried to explain (but your graph is better) in 
my commit message, when I was talking about how it linearizes the history 
in "git log" order, and decides that renames happen "within that 
linearized" world.

You can actually see an *example* of this by doing

	git log --stat --follow arch/i386/pci/common.c

on the old historical Linux archive (the BK import one, not the bkcvs 
import - the latter has been linearized by bkcvs so won't show concurrent 
development anyway). 

What you get is:

	[ ... ]

	commit f9001d4262148fbfb7ecdcb88c73d9791c1ac0ad
	Author: Greg Kroah-Hartman <greg@kroah.com>
	Date:   Mon May 6 20:18:16 2002 -0700
	
	    Move arch/i386/kernel/pci/ to arch/i386/pci/
	
	 arch/i386/{kernel => }/pci/common.c |    0
	 1 files changed, 0 insertions(+), 0 deletions(-)
	
	commit bbb283cca10b2d2c935ae35327620ebae07f7d80
	Author: Patrick Mochel <mochel@segfault.osdl.org>
	Date:   Mon May 6 20:09:44 2002 -0700
	
	    Move arch/i386/kernel/pci/ to arch/i386/pci/
	
	 arch/i386/kernel/pci/common.c |  206 -----------------------------------------
	 1 files changed, 0 insertions(+), 206 deletions(-)

	[ ... ]

and this is an artifact of two _concurrent_ directory moves, and look at 
what "git log --follow" did: it actually found the rename (we looked at 
Greg's version first), but then *because* it found the rename, it is now 
starting to look at the *previous* name, which was

	arch/i386/kernel/pci/common.c

and when it then sees the rename in Pat's commit, it's no longer finding 
that previous entry as a "new file that got created" (which triggers the 
rename logic), but now it finds that filename has being *removed* (because 
the _old_ filename really did go away - it got renamed!)

This is 100% logical within that linearized history, but it's a bit 
surprising. But it's how "git log --follow" just works.

If you want to see the real history, you need to do it with "git blame", 
which actually understands about merges, or with some graphical viewer 
that would be extended to follow renames when it notices that a filename 
goes away.

But "git log" itself really fundamentally has no clue, and you really 
should see "git log" as a *linearization* thing. It linearizes the history 
by creating a one-dimensional streaming log. And within that linearized 
history, there can not be anything like "concurrent renames".

			Linus

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

[Linus Torvalds]

On Thu, 21 Jun 2007, Linus Torvalds wrote:
> 
> But "git log" itself really fundamentally has no clue, and you really 
> should see "git log" as a *linearization* thing. It linearizes the history 
> by creating a one-dimensional streaming log. And within that linearized 
> history, there can not be anything like "concurrent renames".

Btw, just to clarify:

	This is absolutely not somethign unique to "--follow" and rename 
	detection!

when you do a simple "git log -p", you will very commonly see the issue of 
the same patch being applied twice, and if you think of the linearized 
"git log" output is somehow "the Truth" with a capital "T", then you'd 
obviously believe that the thing shows up twice in the end result.

It doesn't even have to be the same patch: you can have a patch that shows 
up in one branch, and that *never* makes it into the end result, even 
though the other branch didn't "undo" it. A merge may have chosen just the 
one side (not necessarily due to "-s ours" or anythign like that: a merge 
conflict may have been resoled that way). 

So the individual logs of changes are not "meaningful" in that sense. Not 
with --follow, and not without. They are a locally linearized version of 
history, and as such you cannot put the world together just based on them. 
You need to have the bigger picture to get the end result.

Does that mean that linearization is meaningless? No, obviously not. Does 
it mean that you *can* get confused by it? Yes, absolutely. Does rename 
detection add new _ways_ of getting confused? Oh, YES! The example from 
the kernel is a great one.

I still think "git log --follow" is actually a really good thing. People 
will find places like this where they are confused, and maybe we'll have 
to teach them about the effects of linearizing their history, but 
especially if you come from the CVS/SVN world, your history has _always_ 
been linear, so git will always get that case right. 

And once you get used to merges, you'll start understanding why git does 
what git does more, and then the "git log --follow" behaviour will still 
perhaps not be what you might always want at any particular point in time, 
but it's something you can understand and deal with.

And it's still hugely preferable to "file identities", which have their 
own (and much more fundamental) problems over merges.

		Linus

What's cooking in git.git (topics)

[Junio C Hamano]

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

* js/rebase (Mon Jun 25 01:11:14 2007 +0100) 2 commits
 + Teach rebase an interactive mode
 + Move the pick_author code to git-sh-setup

Will merge.

* rs/diff (Mon Jun 25 00:23:34 2007 +0200) 2 commits
 + diff: round down similarity index
 + diffcore-rename: don't change similarity index based on basename
   equality

Will merge.

* lt/run (Sun Jun 24 10:29:33 2007 -0700) 2 commits
 + Check for IO errors after running a command
 + Clean up internal command handling

Will merge.

* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit
 + git-svn: allow dcommit to retain local merge information

Haven't heard major breakage report, so hopefully can merge by
the end of the month.

* mk/svn (Fri Jun 22 11:15:03 2007 +0200) 1 commit
 - git-svn: honor ~/.subversion/ client cert file settings.

Waiting for ACK from git-svn people.

* ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
 + make git barf when an alias changes environment variables
 + setup_git_directory: fix segfault if repository is found in cwd
 + test GIT_WORK_TREE
 + extend rev-parse test for --is-inside-work-tree
 + Use new semantics of is_bare/inside_git_dir/inside_work_tree
 + introduce GIT_WORK_TREE to specify the work tree
 + test git rev-parse
 + rev-parse: introduce --is-bare-repository
 + rev-parse: document --is-inside-git-dir
* ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) 9 commits
 + filter-branch: always export GIT_DIR if it is set

I've been resisting these due to the size of the series, but I
think the definition of is-bare is a bit saner than what we have
in 'master', and I think it is the right direction in the longer
term.  HOWEVER, I am not sure about the implementation and
corner cases, e.g. what should it do in receive-pack?  You
cannot rely on user setting GIT_WORK_TREE environment -- rather,
receive-pack is responsible for setting up a sane environment
for other commands to work in.

* jc/quote (Sun Jun 24 15:11:24 2007 -0700) 1 commit
 + Add core.quotepath configuration variable.

This will get rid of "Why is my UTF-8 pathnames are munged"
complaints.  Will wait for a while, maybe merge after 1.5.3.  I
believe the output from this is still readable by an unpatched
git-apply, but I would want to be absolutely sure.

* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits
 - Quiet the output from git-init when cloning, if requested.
 - Add an option to quiet git-init.

I am not very much interested in this but I do not have any
strong or otherwise feeling against it either.

* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
 - Enhance unpack-objects for live repo and large objects
* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
 - blame: show log as it goes
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
* 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

Backburnered.

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

[Jeffrey C. Ollie]

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

On Mon, 2007-06-25 at 02:43 -0700, Junio C Hamano wrote:
>
> * jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits
>  - Quiet the output from git-init when cloning, if requested.
>  - Add an option to quiet git-init.
> 
> I am not very much interested in this but I do not have any
> strong or otherwise feeling against it either.

It seems to me that this series is more about "DWIM" than anything.  A
naïve user would expect "git clone -q" to silcence _all_ non-error
output. The output "Initialized empty Git repository in .git/" that you
get from "git init" isn't an error...

Jeff

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Matthias Lederhofer]

Junio C Hamano <gitster@pobox.com> wrote:
> * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
>  + make git barf when an alias changes environment variables
>  + setup_git_directory: fix segfault if repository is found in cwd
>  + test GIT_WORK_TREE
>  + extend rev-parse test for --is-inside-work-tree
>  + Use new semantics of is_bare/inside_git_dir/inside_work_tree
>  + introduce GIT_WORK_TREE to specify the work tree
>  + test git rev-parse
>  + rev-parse: introduce --is-bare-repository
>  + rev-parse: document --is-inside-git-dir
> * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) 9 commits
>  + filter-branch: always export GIT_DIR if it is set
> 
> I've been resisting these due to the size of the series, but I
> think the definition of is-bare is a bit saner than what we have
> in 'master', and I think it is the right direction in the longer
> term.  HOWEVER, I am not sure about the implementation and
> corner cases, e.g. what should it do in receive-pack?  You
> cannot rely on user setting GIT_WORK_TREE environment -- rather,
> receive-pack is responsible for setting up a sane environment
> for other commands to work in.

Thanks.  I'll have a look at receive-pack this week.  Is there
anything in receive-pack yet which helps to use a working tree in the
hooks?  Or is this something for which the behaviour of git still has
to be defined?

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

[Junio C Hamano]

Matthias Lederhofer <matled@gmx.net> writes:

> Thanks.  I'll have a look at receive-pack this week.  Is there
> anything in receive-pack yet which helps to use a working tree in the
> hooks?  Or is this something for which the behaviour of git still has
> to be defined?

I think the behaviour for receive-pack and the environment the
hooks run in have been pretty well defined.  You start in the
repository (the directory $GIT_DIR), GIT_DIR is set and points
at it.

The issue is that the introduction of WORK_TREE enviornment and
core.worktree mechanism might want to update the semantics.  For
example, some people seem to run checkout (or perhaps "merge")
to update the associated working tree.  Can they find out where
the root of the working tree is (because they would want to
chdir to it before saying "git checkout"), given the current
environment receive-pack sets up for them?

Earlier we said that people who use only GIT_DIR without
GIT_WORK_TREE nor core.worktree should get exactly the same
semantics with or without the WORK_TREE topic, so the above may
not be an issue.

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

[Matthias Lederhofer]

Junio C Hamano <gitster@pobox.com> wrote:
> I think the behaviour for receive-pack and the environment the
> hooks run in have been pretty well defined.  You start in the
> repository (the directory $GIT_DIR), GIT_DIR is set and points
> at it.
> 
> The issue is that the introduction of WORK_TREE enviornment and
> core.worktree mechanism might want to update the semantics.  For
> example, some people seem to run checkout (or perhaps "merge")
> to update the associated working tree.  Can they find out where
> the root of the working tree is (because they would want to
> chdir to it before saying "git checkout"), given the current
> environment receive-pack sets up for them?
>
> Earlier we said that people who use only GIT_DIR without
> GIT_WORK_TREE nor core.worktree should get exactly the same
> semantics with or without the WORK_TREE topic, so the above may
> not be an issue.

When GIT_WORK_TREE/core.worktree are not set the only difference with
the patch series should be that cwd may be used as working tree in more
cases than before.

I think these are the ways git-receive-pack is executed (in normal
setups):
 * local pushes: git_connect() unsets GIT_WORK_TREE.
 * ssh: the user might set GIT_WORK_TREE in his shell
   configuration, .ssh/environments, .ssh/authorized_keys etc.
   git-receive-pack is then executed with GIT_WORK_TREE set.
 * git-daemon: git-daemon with --enable=receive-pack allows pushing
   and does not unset GIT_WORK_TREE, so a git-daemon started with
   GIT_WORK_TREE exported will also have it exported when receive-pack
   is executed.

I think it makes sense to unset GIT_WORK_TREE when receive-pack is
started.  In the first case GIT_WORK_TREE is unset already and in the
latter two cases I don't think we really need to support that
GIT_WORK_TREE stays exported in the hooks, it could rather happen
accidentally.

When doing more stuff in receive-pack old hooks might stop working
break.

For example receive-pack could set up GIT_WORK_TREE with a sane
default value if a working tree can be found, i.e.
    $ export GIT_WORK_TREE=$(dirname $(pwd))
if the working tree is in the parent directory
    $ export GIT_WORK_TREE=$(git config core.worktree)
if core.worktree is set and otherwise GIT_WORK_TREE is not exported.
This way hooks can just use GIT_WORK_TREE for the working tree if
they don't need anything special.

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

[Junio C Hamano]

Matthias Lederhofer <matled@gmx.net> writes:

> When doing more stuff in receive-pack old hooks might stop working
> break.
>
> For example receive-pack could set up GIT_WORK_TREE with a sane
> default value if a working tree can be found, i.e.
>     $ export GIT_WORK_TREE=$(dirname $(pwd))
> if the working tree is in the parent directory
>     $ export GIT_WORK_TREE=$(git config core.worktree)
> if core.worktree is set and otherwise GIT_WORK_TREE is not exported.
> This way hooks can just use GIT_WORK_TREE for the working tree if
> they don't need anything special.

Your analysis looks good.  Probably we can start without doing
anything to see if anybody screams.

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking in 'next'.

* ns/stash (Sun Jul 1 15:29:01 2007 -0700) 3 commits
 + git-stash: require "save" to be explicit and update documentation
 + Document git-stash
 + Add git-stash script

I am hoping this would appear in 1.5.3; it would help what many
people asked (and later we probably would want to invoke it in
git-merge to have an option to automated the process further).

* js/rebase (Mon Jun 25 18:59:43 2007 +0100) 6 commits
 + Teach rebase -i about --preserve-merges
 + rebase -i: provide reasonable reflog for the rebased branch
 + rebase -i: several cleanups
 + ignore git-rebase--interactive
 + Teach rebase an interactive mode
 + Move the pick_author code to git-sh-setup

Will merge.

* jc/diffcore (Thu Jun 28 23:14:13 2007 -0700) 4 commits
 + diffcore-delta.c: Ignore CR in CRLF for text files
 + diffcore-delta.c: update the comment on the algorithm.
 + diffcore_filespec: add is_binary
 + diffcore_count_changes: pass diffcore_filespec

Will merge; although the CRLF stuff itself would probably not
help anybody in real-life, the change in the interface to allow
further enhancement would be a good thing.

* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit
 + git-svn: allow dcommit to retain local merge information

Any negative feedback on this?  Otherwise will merge.

* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits
 + Quiet the output from git-init when cloning, if requested.
 + Add an option to quiet git-init.

Opinions?

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

[Junio C Hamano]

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

* bs/lock (Thu Jul 26 22:13:12 2007 -0700) 3 commits
 + Add test for symlinked configuration file updates.
 + use lockfile.c routines in git_commit_set_multivar()
 + fully resolve symlinks when creating lockfiles

I would like to have this in 1.5.3, as it appears to be
obviously and trivially correct, and resolves real issues we saw
reported on the list and #git channel.

* js/worktree (Thu Jul 26 07:32:49 2007 +0100) 5 commits
 . With work-trees possibly inside git-dir, be more generous
 . Add test for sanitized work-tree behaviour
 . Clean up work-tree handling
 . Add functions get_relative_cwd() and is_inside_dir()
 . Add is_absolute_path(), make_absolute_path() and normalize_path()

Dscho is dead set fixing broken WORK_TREE series that is already
in 'master'.  The series so far unfortunately has still been
untestable state, but the basic approach of cleaning up seems
sound, and knowing him I am reasonably confident that this will
be at least 'next' quality soon enough.

* cr/tag (Mon Jul 23 12:58:27 2007 +0100) 5 commits
 + Teach "git stripspace" the --strip-comments option
 + Make verify-tag a builtin.
 + builtin-tag.c: Fix two memory leaks and minor notation changes.
 + launch_editor(): Heed GIT_EDITOR and core.editor settings
 + Make git tag a builtin.

Carlos did a good job at very carefully crafting this series,
under Dscho's supervision.  Judging from the quality of the
series, I would personally love to have this in 1.5.3.  But as a
matter of principle, replacing an implementation with a totally
different one post -rc is not something I'd want to make a
precedent of.  This will be merged early after 1.5.3.

* mc/logsize (Fri Jul 20 20:15:13 2007 +0200) 1 commit
 - Add --log-size to git log to print message size

This adds a new option --log-size that is to primarily help
loading "git log --pretty=raw" output by qgit.  It is probably
not useful with any other combination of options, with "-p",
"--stat", "--pretty={email,oneline}", etc., as the "length
indicator" is at the wrong place (it should be the first line of
each record, not on the second line), but it is good enough for
helping qgit.  This (or improvement of it if one comes up) will
most likely to be in 'master' after 1.5.3.

* js/recursive-fix (Tue Jul 17 18:14:48 2007 +0100) 2 commits
 . Add tests for cherry-pick d/f conflict which should be none
 . merge-recursive: sometimes, d/f conflict is not an issue

This is to paper over a design bug in merge-recursive d/f
conflict checking code.  I'd expect we would want to rethink the
whole merge datapath after 1.5.3 and prefer to leave this series
out of 1.5.3.

* jc/blame (Thu Jul 12 10:49:08 2007 -0700) 4 commits
 - git-log --follow?
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up

The tip of this is Linus's "follow single file".  I will
cherry-pick and put it in 'next' after 1.5.3.

* db/fetch-pack (Tue Jul 10 00:38:42 2007 -0400) 1 commit
 . Make fetch-pack a builtin with an internal API

Daniel has a few more patches in this series we have already
seen on the list; I'll ask him to rebase/repost after 1.5.3.

* 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 did this just for fun, but come to think of it, the user can
run git-stash himself when git-rebase complains the working tree
is dirty anyway, so this may probably not so useful.

* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
 . Enhance unpack-objects for live repo and large objects

This is to deliberately avoid placing large blob to packfile.
Nico had objections on this type of special purpose hacks, and I
agree with him.

* 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

What's cooking in git.git (topics)

[Junio C Hamano]

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

* jc/diff-files (Fri Aug 3 13:33:31 2007 -0700) 1 commit
 - git-diff: squelch "empty" diffs

It appears that people like the idea; I re-did the patch and
removed the option like Steve did.  I'll look at it again and
probably merge it to 'master' over the weekend.

* mc/logsize (Fri Jul 20 20:15:13 2007 +0200) 1 commit
 - Add --log-size to git log to print message size
* js/recursive-fix (Tue Jul 17 18:14:48 2007 +0100) 2 commits
 . Add tests for cherry-pick d/f conflict which should be none
 . merge-recursive: sometimes, d/f conflict is not an issue
* jc/blame (Thu Jul 12 10:49:08 2007 -0700) 4 commits
 - git-log --follow?
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
* db/fetch-pack (Tue Jul 10 00:38:42 2007 -0400) 1 commit
 . Make fetch-pack a builtin with an internal API
* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
 - rebase: allow starting from a dirty tree.
 - stash: implement "stash create"
* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
 - Enhance unpack-objects for live repo and large objects
* 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

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

[Jakub Narebski]

Junio C Hamano wrote:

> * jc/diff-files (Fri Aug 3 13:33:31 2007 -0700) 1 commit
>  - git-diff: squelch "empty" diffs
> 
> It appears that people like the idea; I re-did the patch and
> removed the option like Steve did.  I'll look at it again and
> probably merge it to 'master' over the weekend.

What about using config variable for that instead?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

What's cooking in git.git (topics)

[Junio C Hamano]

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

* js/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.

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

[Shawn O. Pearce]

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.

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

[Johannes Schindelin]

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

* 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'.

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

[Carlos Rica]

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

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

[Johannes Schindelin]

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

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

[Tom Clarke]

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

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

[Jeff King]

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

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

[David Kastrup]

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

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

[David Kastrup]

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

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

[Jeff King]

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

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

[David Kastrup]

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

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

[Daniel Barkalow]

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*

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

[Jeff King]

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

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

[Junio C Hamano]

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.

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

[Jeff King]

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

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

[Jeff King]

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

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

* 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.

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

[David Kastrup]

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

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

[Steven Grimm]

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

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

[Steffen Prohaska]

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

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

[Matthieu Moy]

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

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

[Junio C Hamano]

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"

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

[David Kågedal]

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

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

[Matthieu Moy]

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

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

[Johannes Schindelin]

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

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

[Jeff King]

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

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

[David Kastrup]

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

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

[Daniel Barkalow]

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*

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

[Jeff King]

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

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

[Junio C Hamano]

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"

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

[David Kastrup]

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

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

[Linus Torvalds]

[ 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)

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

[Jeff King]

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

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

[David Kastrup]

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

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

[Linus Torvalds]

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

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

[Jeff King]

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

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

[Linus Torvalds]

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

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

[David Kastrup]

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

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

[Junio C Hamano]

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.

What's cooking in git.git (topics)

[Junio C Hamano]

Thanks to Shawn who was a terrific interim maintainer while I
was away, there are quite a few new topics in 'pu'.  The ones in
'next' look safe enough to me, and may graduate to 'master' by
the end of the month.  We'll see.

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.

* cc/skip (Mon Oct 22 07:49:39 2007 +0200) 9 commits
 - Bisect: add a "bisect replay" test case.
 - Bisect: add "bisect skip" to the documentation.
 - Bisect: refactor "bisect_{bad,good,skip}" into "bisect_state".
 - Bisect: refactor some logging into "bisect_write".
 - Bisect: refactor "bisect_write_*" functions.
 - Bisect: implement "bisect skip" to mark untestable revisions.
 - Bisect: fix some white spaces and empty lines breakages.
 - rev-list documentation: add "--bisect-all".
 - rev-list: implement --bisect-all

Still "just parked" as Shawn described, but three patches were
replaced and as a result the series has a single liner fix since
the last "What's cooking".

* ds/gitweb (Mon Oct 22 10:28:03 2007 +1000) 1 commit
 + gitweb: Provide title attributes for abbreviated author names.

* lt/rename (Mon Oct 22 10:29:16 2007 -0700) 2 commits
 - Linear-time/space rename logic (exact renames only)
 - Split out "exact content match" phase of rename detection

The tip commit has been replaced with a new one (actually,
squash of a few commits) since Shawn's announcement and now
t4001 passes.

* js/PATH (Sun Oct 21 22:59:01 2007 +0100) 1 commit
 - execv_git_cmd(): also try PATH if everything else fails.

I do not quite get why this is needed; need to go back to the
discussion myself.  On the other hand, I found the alternative
approach suggested on the list very interesting (i.e. instead of
"also try", just letting exec*p use PATH, relying on the fact
that we do prepend-to-path anyway).  What happened to it?  Was
there a downside?

* ja/shorthelp (Sun Oct 21 01:41:41 2007 +0300) 1 commit
 + On error, do not list all commands, but point to --help option

Shawn says he likes this, and I tend to agree.

* db/fetch-pack (Sat Oct 20 16:03:49 2007 -0400) 60 commits
 + Define compat version of mkdtemp for systems lacking it
 + Avoid scary errors about tagged trees/blobs during git-fetch
 + fetch: if not fetching from default remote, ignore default merge
 + Support 'push --dry-run' for http transport
 + Support 'push --dry-run' for rsync transport
 + Fix 'push --all branch...' error handling
 + Fix compilation when NO_CURL is defined
 + Added a test for fetching remote tags when there is not tags.
 + Fix a crash in ls-remote when refspec expands into nothing
 ...

This has been cooking forever in git timescale.  Judging from
the type of fixes going in, I can see people are using this in
production and the topic is not terribly broken.

* js/forkexec (Fri Oct 19 21:48:06 2007 +0200) 74 commits
 + Use the asyncronous function infrastructure to run the content
   filter.
 + Avoid a dup2(2) in apply_filter() - start_command() can do it for
   us.
 + t0021-conversion.sh: Test that the clean filter really cleans
   content.
 + upload-pack: Run rev-list in an asynchronous function.
 + upload-pack: Move the revision walker into a separate function.
 + Use the asyncronous function infrastructure in builtin-fetch-
   pack.c.
 + Add infrastructure to run a function asynchronously.
 + upload-pack: Use start_command() to run pack-objects in
   create_pack_file().
 + Have start_command() create a pipe to read the stderr of the
   child.
 + Use start_comand() in builtin-fetch-pack.c instead of explicit
   fork/exec.
 + Use run_command() to spawn external diff programs instead of
   fork/exec.
 + Use start_command() to run content filters instead of explicit
   fork/exec.
 + Use start_command() in git_connect() instead of explicit
   fork/exec.
 + Change git_connect() to return a struct child_process instead of a
   pid_t.

Gave a cursory look at a few of the patches but they all looked
fine.

* tf/afs (Fri Oct 19 07:38:16 2007 -0500) 1 commit
 - Better support AFS hardlinking across object directories

I share Shawn's concern of breaking the "never replace existing
object" security.  Will probably drop this patch in the current
shape.

* jk/terse-fetch (Fri Oct 19 03:40:57 2007 -0400) 62 commits
 - park
 - git-fetch: mega-terse fetch output

Haven't caught up with the output format discussion.  Hopefully
somebody will implement the list concensus and resend a
replacement patch, at which time I can drop these two before
looking at these two patches ;-).

* np/progress (Fri Oct 19 01:01:40 2007 -0400) 9 commits
 + Stop displaying "Pack pack-$ID created." during git-gc
 + Teach prune-packed to use the standard progress meter
 + Change 'Deltifying objects' to 'Compressing objects'
 + fix for more minor memory leaks
 + fix const issues with some functions
 + pack-objects.c: fix some global variable abuse and memory leaks
 + pack-objects: no delta possible with only one object in the list
 + cope with multiple line breaks within sideband progress messages
 + more compact progress display

"Compressing objects" caught my eye, but it all makes sense.

* sp/mergetool (Thu Oct 18 12:25:34 2007 +0200) 3 commits
 + mergetool: avoid misleading message "Resetting to default..."
 + mergetool: add support for ECMerge
 + mergetool: use path to mergetool in config var
   mergetool.<tool>.path

* jk/send-pack (Thu Oct 18 02:17:46 2007 -0400) 2 commits
 + t5516: test update of local refs on push
 + send-pack: don't update tracking refs on error

* js/rebase (Wed Oct 17 10:31:35 2007 +0100) 1 commit
 + Fixing path quoting in git-rebase

I have a feeling that this should have forked off of 'maint'.
The change looks obvious and trivial, so perhaps after getting a
testcase (hint, hint) merge to 'master' and then cherry-pick to
'maint' as well.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

Obviously this was meant for git-stash, but I am not sure if
allowing to drop reflog entries in the middle is a good idea in
general.  If we are going to change the UI and the end-user view
for stash _anyway_, we may be better off reimplementing stash as
separate, numbered and/or named refs (e.g. refs/stash/stash-$n).

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

As I already said earlier, I do not think unstashing always on
top of rebased state is the right thing to do anyway, we would
want to change the behaviour of the tip one, but the question is
how.

* dz/color-addi (Tue Oct 16 21:42:23 2007 -0400) 1 commit
 - Add color support to git-add--interactive

* jc/revert-merge (Tue Oct 23 13:33:26 2007 -0700) 1 commit
 - revert/cherry-pick: work on merge commits as well

Allowing to revert/cherry-pick a merge commit.  I got my first
exposure to the new option parser because I had to adjust to the
new "--mainline" option.  The option is supposed to take positive
integer as a value but I left it as a generic OPT_INTEGER for
now and as a result you may get funny error messages if you give
nonsense input.

* ph/parseopt (Mon Oct 15 23:06:02 2007 +0200) 22 commits
 - Make builtin-pack-refs.c use parse_options.
 - Make builtin-name-rev.c use parse_options.
 - Make builtin-count-objects.c use parse_options.
 - Make builtin-fsck.c use parse_options.
 - Update manpages to reflect new short and long option aliases
 - Make builtin-for-each-ref.c use parse-opts.
 - Make builtin-symbolic-ref.c use parse_options.
 - Make builtin-update-ref.c use parse_options
 - Make builtin-revert.c use parse_options.
 - Make builtin-describe.c use parse_options
 - Make builtin-branch.c use parse_options.
 - Make builtin-mv.c use parse-options
 - Make builtin-rm.c use parse_options.
 - Port builtin-add.c to use the new option parser.
 - parse-options: allow callbacks to take no arguments at all.
 - parse-options: Allow abbreviated options when unambiguous
 - Add shortcuts for very often used options.
 - parse-options: make some arguments optional, add callbacks.
 - Rework make_usage to print the usage message immediately
 - Add tests for parse-options.c
 - parse-options: be able to generate usages automatically
 - Add a simple option parser.

* sp/push-refspec (Sun Oct 14 10:54:45 2007 +0200) 6 commits
 - push, send-pack: use same rules as git-rev-parse to resolve
   refspecs
 - add ref_cmp_full_short() comparing full ref name with a short name
 - push, send-pack: support pushing HEAD to real ref name
 - rev-parse: teach "git rev-parse --symbolic" to print the full ref
   name
 - add get_sha1_with_real_ref() returning full name of ref on demand
 - push, send-pack: fix test if remote branch exists for colon-less
   refspec

* kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits
 + Export rerere() and launch_editor().
 + Introduce entry point add_interactive and add_files_to_cache
 + Enable wt-status to run against non-standard index file.
 + Enable wt-status output to a given FILE pointer.

* jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit
 - git-diff: complain about >=8 consecutive spaces in initial indent
* jc/nu (Mon Oct 1 19:35:12 2007 -0700) 2 commits
 - PARK a bit more work
 - (PARK) WIP
* 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.

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

[David Symonds]

On 10/24/07, Junio C Hamano <gitster@pobox.com> wrote:
>
> * ds/gitweb (Mon Oct 22 10:28:03 2007 +1000) 1 commit
>  + gitweb: Provide title attributes for abbreviated author names.

I was hoping you could include my other two related patches on top of
that one, since they clean it up somewhat.


Dave.

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

[Scott Parish]

On Wed, Oct 24, 2007 at 05:51:28AM -0700, Junio C Hamano wrote:

> * js/PATH (Sun Oct 21 22:59:01 2007 +0100) 1 commit
>  - execv_git_cmd(): also try PATH if everything else fails.
> 
> I do not quite get why this is needed; need to go back to the
> discussion myself.  On the other hand, I found the alternative
> approach suggested on the list very interesting (i.e. instead of
> "also try", just letting exec*p use PATH, relying on the fact
> that we do prepend-to-path anyway).  What happened to it?  Was
> there a downside?

The main downside that was raised was MingW compatibility, but
Schindelin and Sixt both said that it could wait until further
work is done porting to MingW.

Should i resend my string of patches? I've seen people numbering
their patches, should i do that as well?

Thanks
sRp

-- 
Scott Parish
http://srparish.net/

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

[Andreas Ericsson]

Scott Parish wrote:
> On Wed, Oct 24, 2007 at 05:51:28AM -0700, Junio C Hamano wrote:
> 
>> * js/PATH (Sun Oct 21 22:59:01 2007 +0100) 1 commit
>>  - execv_git_cmd(): also try PATH if everything else fails.
>>
>> I do not quite get why this is needed; need to go back to the
>> discussion myself.  On the other hand, I found the alternative
>> approach suggested on the list very interesting (i.e. instead of
>> "also try", just letting exec*p use PATH, relying on the fact
>> that we do prepend-to-path anyway).  What happened to it?  Was
>> there a downside?
> 
> The main downside that was raised was MingW compatibility, but
> Schindelin and Sixt both said that it could wait until further
> work is done porting to MingW.
> 
> Should i resend my string of patches? I've seen people numbering
> their patches, should i do that as well?
> 

'git format-patch -n' will do it for you. I take it you've found
out about git-send-email already?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Scott Parish]

On Wed, Oct 24, 2007 at 08:27:44PM +0200, Andreas Ericsson wrote:

> > Should i resend my string of patches? I've seen people numbering
> > their patches, should i do that as well?
> 
>  'git format-patch -n' will do it for you. I take it you've found
>  out about git-send-email already?

I actually hadn't seen either of those. Thanks!

sRp

-- 
Scott Parish
http://srparish.net/

What's cooking in git.git (topics)

[Junio C Hamano]

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

I think it is time to plan freezing for 1.5.4 and this list is a
good place to start.

* js/forkexec (Fri Oct 19 21:48:06 2007 +0200) 14 commits
 + Use the asyncronous function infrastructure to run the content
   filter.
 + Avoid a dup2(2) in apply_filter() - start_command() can do it for
   us.
 + t0021-conversion.sh: Test that the clean filter really cleans
   content.
 + upload-pack: Run rev-list in an asynchronous function.
 + upload-pack: Move the revision walker into a separate function.
 + Use the asyncronous function infrastructure in builtin-fetch-
   pack.c.
 + Add infrastructure to run a function asynchronously.
 + upload-pack: Use start_command() to run pack-objects in
   create_pack_file().
 + Have start_command() create a pipe to read the stderr of the
   child.
 + Use start_comand() in builtin-fetch-pack.c instead of explicit
   fork/exec.
 + Use run_command() to spawn external diff programs instead of
   fork/exec.
 + Use start_command() to run content filters instead of explicit
   fork/exec.
 + Use start_command() in git_connect() instead of explicit
   fork/exec.
 + Change git_connect() to return a struct child_process instead of a
   pid_t.

I haven't seen anything wrong with this series and we haven't
heard breakages from people on 'next' who have been running with
this for the past ten days.  Will merge to 'master'.

* db/remote-builtin (Mon Oct 29 22:03:42 2007 -0400) 4 commits
 - Use built-in send-pack.
 - Build-in send-pack, with an API for other programs to call.
 - Build-in peek-remote, using transport infrastructure.
 - Miscellaneous const changes and utilities

Will be in 'next' soon after reviewing it again; hopefully in
'master' before 1.5.4.

* ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits
 + Fixed a command line option type for builtin-fsck.c
 + Make builtin-pack-refs.c use parse_options.
 + Make builtin-name-rev.c use parse_options.
 + Make builtin-count-objects.c use parse_options.
 + Make builtin-fsck.c use parse_options.
 + Update manpages to reflect new short and long option aliases
 + Make builtin-for-each-ref.c use parse-opts.
 + Make builtin-symbolic-ref.c use parse_options.
 + Make builtin-update-ref.c use parse_options
 + Make builtin-revert.c use parse_options.
 + Make builtin-describe.c use parse_options
 + Make builtin-branch.c use parse_options.
 + Make builtin-mv.c use parse-options
 + Make builtin-rm.c use parse_options.
 + Port builtin-add.c to use the new option parser.
 + parse-options: allow callbacks to take no arguments at all.
 + parse-options: Allow abbreviated options when unambiguous
 + Add shortcuts for very often used options.
 + parse-options: make some arguments optional, add callbacks.
 + Rework make_usage to print the usage message immediately
 + Add tests for parse-options.c
 + parse-options: be able to generate usages automatically
 + Add a simple option parser.

It appears 1.5.4 will be, to a certain extent, a "Let's clean up
the internal implementation" release.  This series should become
part of it.  Hopefully will merge to 'master' soon, but I
haven't looked this series very closely yet.

* kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits
 + Export rerere() and launch_editor().
 + Introduce entry point add_interactive and add_files_to_cache
 + Enable wt-status to run against non-standard index file.
 + Enable wt-status output to a given FILE pointer.

These four alone do not change anything user visible, as the
final goal of this series which is "git-commit in C" is not here
yet.  But with the other topics touching internal API left and
right that is understandable.  Will merge to 'master'.

* sp/help (Sat Oct 27 01:36:55 2007 -0700) 7 commits
 + shell should call the new setup_path() to setup $PATH
 + include $PATH in generating list of commands for "help -a"
 + use only the $PATH for exec'ing git commands
 + list_commands(): simplify code by using chdir()
 + "current_exec_path" is a misleading name, use "argv_exec_path"
 + remove unused/unneeded "pattern" argument of list_commands
 + "git" returns 1; "git help" and "git help -a" return 0

Will merge to 'master'.

* sp/mergetool (Thu Oct 18 12:25:34 2007 +0200) 3 commits
 + mergetool: avoid misleading message "Resetting to default..."
 + mergetool: add support for ECMerge
 + mergetool: use path to mergetool in config var
   mergetool.<tool>.path

Will merge to 'master'.

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

Will revert at least the latter one, but perhaps both, from
'next'.  The traditional behaviour of refusing to work in a
dirty tree is much safer, as the tool cannot decide where to
unstash for you.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

This by itself is not useful; will stay in 'next' until it is
used by selective clearing of stash or something else.

* jc/revert-merge (Tue Oct 23 13:33:26 2007 -0700) 1 commit
 + revert/cherry-pick: work on merge commits as well

This allows cherry-pick and revert to act on a merge commit if
you specify which parent to pick the changes from.  I think it
would probably be handy when the need arises, but I suspect such
a need is felt only occasionally.  I haven't heard any comment
on the list since it was posted.  I am somewhat tempted to merge
this, but I am not in a hurry.

* np/progress (Wed Oct 31 23:57:04 2007 -0400) 17 commits
 . Show total transferred as part of throughput progress display
 - add throughput display to git-push
 - add some copyright notice to the progress display code
 - add throughput display to index-pack
 - add throughput to progress display
 - relax usage of the progress API
 - make struct progress an opaque type
 - prune-packed: don't call display_progress() for every file
 + Stop displaying "Pack pack-$ID created." during git-gc
 + Teach prune-packed to use the standard progress meter
 + Change 'Deltifying objects' to 'Compressing objects'
 + fix for more minor memory leaks
 + fix const issues with some functions
 + pack-objects.c: fix some global variable abuse and memory leaks
 + pack-objects: no delta possible with only one object in the list
 + cope with multiple line breaks within sideband progress messages
 + more compact progress display

This would give us a good usability enhancement.  Will merge the
first half to 'master', cook the rest in 'next' and aim to merge
the whole thing before 1.5.4.

* jc/format-patch-encoding (Wed Oct 31 14:55:17 2007 -0700) 1 commit
 - format-patch -s: add MIME encoding header if signer's name
   requires so

Topic appeared today.  I think this is a safe and sane
fix to a real problem.  Needs cherry-pick to 'maint'.

* jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit
 - git-diff: complain about >=8 consecutive spaces in initial indent

This is a counterpart of an earlier patch from J. Bruce Fields
to change "git-apply --whitespace" to make SP{8,} at the
beginning of line a whitespace error.

Personally, I am in favor of the stricter check, but I had to
reject the "git-apply" patch because there was no way to disable
the additional check without disabling the existing check for
trailing whitespaces.  We probably would want to revisit that
one (perhaps with a new option and/or config to selectively
enable different kinds of whitespace check).

* dz/color-addi (Tue Oct 16 21:42:23 2007 -0400) 1 commit
 - Add color support to git-add--interactive

I am not a big fan of color, and Shawn's "What's cooking"
mentioned issues with the implementation.  Will not merge to
'next'.

* sp/push-refspec (Sun Oct 28 18:46:20 2007 +0100) 6 commits
 - push: teach push to pass --verbose option to transport layer
 - push: teach push to accept --verbose option
 - push: use same rules as git-rev-parse to resolve refspecs
 - add ref_abbrev_matches_full_with_rev_parse_rules() comparing
   abbrev with full ref name
 - rename ref_matches_abbrev() to
   ref_abbrev_matches_full_with_fetch_rules()
 - push: support pushing HEAD to real branch name

I have been meaning to review these again and merge to 'next'
but it seems I've been spending more time discussing the ones I
did not even pick up for 'pu'.  Will try to find time to do so.

* jk/terse-fetch (Fri Oct 19 03:40:57 2007 -0400) 2 commits
 - park
 - git-fetch: mega-terse fetch output

No change ;-)

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 - merge-nu: a new merge backend without using unpack_trees()
 - read_tree: take an explicit index structure
 - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

I was hoping that I can work on this series while in Japan, but
attending funeral and helping others to deal with the fallout
sucked all my energy and time.  This is still a wip and not
progressing.

* 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.

My pet project to unify the pathspec handling between tree-diff
family and ls-files family (one side only knows "in this
directory" match, and the other knows how to handle fnmatch
globs as well).  Stalled.

* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
 . handle renames using similarity engine
 . introduce generic similarity library
 . change hash table calling conventions

Aiming for a worthy goal, but not merged to 'pu' yet.

* tf/afs (Fri Oct 19 07:38:16 2007 -0500) 1 commit
 . Better support AFS hardlinking across object directories

Will drop from topic queue.  This is labelled as "AFS hack", but
it hacks around a problem AFS has by breaking the safety we had
from very early days of git for everybody else.

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

[Jakub Narebski]

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"
> 
> Will revert at least the latter one, but perhaps both, from
> 'next'.  The traditional behaviour of refusing to work in a
> dirty tree is much safer, as the tool cannot decide where to
> unstash for you.

One of frequently requested features is ability to rebase and merge
in a dirty tree (CVS-like). Perhaps we should advocate git-stash better,
e.g. in error message for git-rebase / git-merge / git-pull when in dirty
state.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Linus Torvalds]

On Wed, 31 Oct 2007, Junio C Hamano wrote:
> 
> * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits
>  + ...
> 
> It appears 1.5.4 will be, to a certain extent, a "Let's clean up
> the internal implementation" release.  This series should become
> part of it.  Hopefully will merge to 'master' soon, but I
> haven't looked this series very closely yet.

I certainly think this should go in, but it does make one deficiency 
painfully clear: the remaining shell scripts end up having all the old 
flags behaviour.

So while you can combine flags for *most* programs, you still won't 
be able to say things like

	git clean -qdx

just because that's still a shellscript, and doing any fancy argument 
parsing in shell is just painful.

Is somebody still working on doing the shell->C conversion?

		Linus

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

[Geert Bosch]

On Nov 1, 2007, at 14:33, Linus Torvalds wrote:
> I certainly think this should go in, but it does make one deficiency
> painfully clear: the remaining shell scripts end up having all the old
> flags behaviour.
>
> So while you can combine flags for *most* programs, you still won't
> be able to say things like
>
> 	git clean -qdx
>
> just because that's still a shellscript, and doing any fancy argument
> parsing in shell is just painful.
>
> Is somebody still working on doing the shell->C conversion?


This is by far the most dangerous command we have at this stage,
and just too easy to execute by accident. While I now have found
out that it is possible to set clean.requireForce to disarm the
command, that's the wrong way around. Only experienced users set
it, and the mere existence of the config item indicates people
do get hosed (and lose data) as a result of the poor semantics.

I often type "make clean" as well many "git xyz" commands
during development, and so it happens that at times, I type
"git clean" by accident.

So, I propose *not* converting git clean to a C builtin,
but instead adding --untracked and --ignored options to
git-rm.

This fixes two usability issues:
   1. data loss due to command typo
   2. too many git commands

Those who care about "git clean" can setup an alias
to make git clean equal to "git rm --untracked"

   -Geert

PS. No patch yet, but I wanted to prevent others from spending
     time on builtin git-clean.

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

[Junio C Hamano]

Geert Bosch <bosch@adacore.com> writes:

> I often type "make clean" as well many "git xyz" commands
> during development, and so it happens that at times, I type
> "git clean" by accident.

Happened to me once.  I hate that command.

> So, I propose *not* converting git clean to a C builtin,
> but instead adding --untracked and --ignored options to
> git-rm.

I think what you are trying to do is to deprecate or remove "git
clean".

I do not know where "git clean" came from.  I am suspecting that
it was to give counterparts to some other SCMs, but do not know
which ones.  Some people wanted to have it --- so you need to
convince them that it is a bad idea first.  Adding an equivalent
options to "git rm" alone does not solve that issue.

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

[Mike Hommey]

On Thu, Nov 01, 2007 at 01:27:55PM -0700, Junio C Hamano wrote:
> Geert Bosch <bosch@adacore.com> writes:
> 
> > I often type "make clean" as well many "git xyz" commands
> > during development, and so it happens that at times, I type
> > "git clean" by accident.
> 
> Happened to me once.  I hate that command.

Speaking of hateful commands, git stash clear is one of them.
I tend to type git stash clean, which creates a "clean" stash...
 
> > So, I propose *not* converting git clean to a C builtin,
> > but instead adding --untracked and --ignored options to
> > git-rm.
> 
> I think what you are trying to do is to deprecate or remove "git
> clean".
> 
> I do not know where "git clean" came from.  I am suspecting that
> it was to give counterparts to some other SCMs, but do not know
> which ones.  Some people wanted to have it --- so you need to
> convince them that it is a bad idea first.  Adding an equivalent
> options to "git rm" alone does not solve that issue.

Well, they could add an alias, then ;)

Mike

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> 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"
>> 
>> Will revert at least the latter one, but perhaps both, from
>> 'next'.  The traditional behaviour of refusing to work in a
>> dirty tree is much safer, as the tool cannot decide where to
>> unstash for you.
>
> One of frequently requested features is ability to rebase and merge
> in a dirty tree (CVS-like). Perhaps we should advocate git-stash better,
> e.g. in error message for git-rebase / git-merge / git-pull when in dirty
> state.

I am of two minds about that.  Suggesting to "stash first, do
your thing and unstash" certainly is helpful than not
suggesting.  But wanting to do things in a dirty state, only
because CVS did not allow you to do anything else, is a bad
inertia on the user's side in the first place, and that
helpfulness would actively _encourage_ to keep that bad inertia,
instead of educating the users to think in git-way.

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

[Geert Bosch]

On Nov 1, 2007, at 16:27, Junio C Hamano wrote:
> Geert Bosch <bosch@adacore.com> writes:
>> I often type "make clean" as well many "git xyz" commands
>> during development, and so it happens that at times, I type
>> "git clean" by accident.
>
> Happened to me once.  I hate that command.
>
>> So, I propose *not* converting git clean to a C builtin,
>> but instead adding --untracked and --ignored options to
>> git-rm.
>
> I think what you are trying to do is to deprecate or remove "git
> clean".

Yes, and in the meantime I'd like to discourage people
from spending time and effort to upgrade it to first
class built-in status.

   -Geert

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

[Theodore Tso]

On Thu, Nov 01, 2007 at 01:27:55PM -0700, Junio C Hamano wrote:
> I think what you are trying to do is to deprecate or remove "git
> clean".
> 
> I do not know where "git clean" came from.  I am suspecting that
> it was to give counterparts to some other SCMs, but do not know
> which ones.  Some people wanted to have it --- so you need to
> convince them that it is a bad idea first.  Adding an equivalent
> options to "git rm" alone does not solve that issue.

There's this great SCM tool called git that we can use to investigate
the history of changes....  :-)

Looks like it came from Cogito's cg-clean.  No one else has it as far
as I know, and I agree with others that it's a really not such a great
idea.  Fortunately most of the damage can be mitigated with "git
config --global clean.requireForce true", but the newbies won't know
to do that.  

							- Ted

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

[Junio C Hamano]

Mike Hommey <mh@glandium.org> writes:

> On Thu, Nov 01, 2007 at 01:27:55PM -0700, Junio C Hamano wrote:
> ...
>> I do not know where "git clean" came from.  I am suspecting that
>> it was to give counterparts to some other SCMs, but do not know
>> which ones.  Some people wanted to have it --- so you need to
>> convince them that it is a bad idea first.  Adding an equivalent
>> options to "git rm" alone does not solve that issue.
>
> Well, they could add an alias, then ;)

Why do people talk about forcing different behaviour on existing
users before proving that the new behaviour is good for
everybody, including existing ones?

I am personally very much in favor of removing "git clean", but
having many people on the list saying loudly that it is a bad
command is not good enough justification, as people who are
content with the status quo tend to be silent.

The steps I think is sensible to transition to that goal would
be:

 - Change clean.requireForce to default to 'true' in the next
   (or one after) version of git, to make 'clean' even safer.
   See if anybody complains (I do not expect any).

 - Implement the same functionarity as a new option to "git rm",
   which is already in C.

 - Do "git clean" in C, but sharing the code with "git rm"
   implementation above.

 - Discuss deprecation and removal of redundant commands.  Ship
   a version of git with deprecation and future removal notice.
   Outline how to achieve the same thing as the deprecated
   command used to do (or give convincing argument why what the
   deprecated command used to do was a bad thing and do not
   offer an alternative).

 - Wait for a while (6 months to 1 year) and then remove them.

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

[Melchior FRANZ]

* Theodore Tso -- Thursday 01 November 2007:
> Looks like it came from Cogito's cg-clean.  No one else has it as far
> as I know, [...]

Not built-in. But there are cvs-clean and svn-clean scripts
floating around (and part of KDE), which can be quite useful.
The svn-clean script prompts the user with the number of files
it is about to delete, and asks for confirmation.

m.

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

[Johan Herland]

On Thursday 01 November 2007, Junio C Hamano wrote:
> Geert Bosch <bosch@adacore.com> writes:
> 
> > I often type "make clean" as well many "git xyz" commands
> > during development, and so it happens that at times, I type
> > "git clean" by accident.
> 
> Happened to me once.  I hate that command.
> 
> > So, I propose *not* converting git clean to a C builtin,
> > but instead adding --untracked and --ignored options to
> > git-rm.
> 
> I think what you are trying to do is to deprecate or remove "git
> clean".
> 
> I do not know where "git clean" came from.  I am suspecting that
> it was to give counterparts to some other SCMs, but do not know
> which ones.  Some people wanted to have it --- so you need to
> convince them that it is a bad idea first.  Adding an equivalent
> options to "git rm" alone does not solve that issue.

What about making "git clean" _stash_ your changes instead of deleting them 
(so that you can undo the clean)? Preferably they should be stashed 
somewhere _other_ than where "git stash" does its thing. "git clean" could 
even delete the stash immediately, but keep the reflog around so that 
the "clean" at least could be undone within 30 days (or whatever is the 
current default).

Thoughts?


Have fun! :)

...Johan


-- 
Johan Herland, <johan@herland.net>
www.herland.net

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

[Brian Downing]

On Wed, Oct 31, 2007 at 10:41:06PM -0700, Junio C Hamano wrote:
> * jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit
>  - git-diff: complain about >=8 consecutive spaces in initial indent
> 
> This is a counterpart of an earlier patch from J. Bruce Fields
> to change "git-apply --whitespace" to make SP{8,} at the
> beginning of line a whitespace error.
> 
> Personally, I am in favor of the stricter check, but I had to
> reject the "git-apply" patch because there was no way to disable
> the additional check without disabling the existing check for
> trailing whitespaces.  We probably would want to revisit that
> one (perhaps with a new option and/or config to selectively
> enable different kinds of whitespace check).

Just to throw in my two cents, I would be strongly opposed to this
going in without some form of configuration to make it work for
spaces-only-indent projects.  I appreciate having whitespace checking,
and I think trailing whitespace and tabs-following-spaces are obviously
bad enough that they should always be flagged.  But flagging leading
spaces makes a legitimate and common coding style yield incredibly
obnoxious-looking diffs.

I don't want to get into another stupid holy war about the superiority
of indent styles (the last one was quite enough, thank you), but there
are real projects out there that have a spaces-only-indent policy and
use Git, and this change as is isn't good for them.

-bcd

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

[Pierre Habouzit]

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

On Thu, Nov 01, 2007 at 08:27:55PM +0000, Junio C Hamano wrote:
> Geert Bosch <bosch@adacore.com> writes:
> 
> > I often type "make clean" as well many "git xyz" commands
> > during development, and so it happens that at times, I type
> > "git clean" by accident.
> 
> Happened to me once.  I hate that command.
> 
> > So, I propose *not* converting git clean to a C builtin,
> > but instead adding --untracked and --ignored options to
> > git-rm.
> 
> I think what you are trying to do is to deprecate or remove "git
> clean".
> 
> I do not know where "git clean" came from.  I am suspecting that
> it was to give counterparts to some other SCMs, but do not know
> which ones.  Some people wanted to have it --- so you need to
> convince them that it is a bad idea first.  Adding an equivalent
> options to "git rm" alone does not solve that issue.

  FWIW I do use git clean a _lot_. I don't mind if it's doable from
another kind of command, but I do use git clean and even git clean -x a
lot, because it achives cleansing my repository faster (and sometimes
faster) than a `make distclean` would do.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

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

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

[Pierre Habouzit]

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

On Thu, Nov 01, 2007 at 08:47:55PM +0000, Mike Hommey wrote:
> On Thu, Nov 01, 2007 at 01:27:55PM -0700, Junio C Hamano wrote:
> > Geert Bosch <bosch@adacore.com> writes:
> > 
> > > I often type "make clean" as well many "git xyz" commands
> > > during development, and so it happens that at times, I type
> > > "git clean" by accident.
> > 
> > Happened to me once.  I hate that command.
> 
> Speaking of hateful commands, git stash clear is one of them.
> I tend to type git stash clean, which creates a "clean" stash...

  I agree, the most itching issue is that usually, this action in git is
called `prune'. So it's inconsistant. I would have much prefered that
git stash would take its actions as options so that if you mistakenly
type a wrong command, the options parsers sees that and fails.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

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

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

[Pierre Habouzit]

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

On Thu, Nov 01, 2007 at 09:41:31PM +0000, Brian Downing wrote:
> On Wed, Oct 31, 2007 at 10:41:06PM -0700, Junio C Hamano wrote:
> > * jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit
> >  - git-diff: complain about >=8 consecutive spaces in initial indent
> > 
> > This is a counterpart of an earlier patch from J. Bruce Fields
> > to change "git-apply --whitespace" to make SP{8,} at the
> > beginning of line a whitespace error.
> > 
> > Personally, I am in favor of the stricter check, but I had to
> > reject the "git-apply" patch because there was no way to disable
> > the additional check without disabling the existing check for
> > trailing whitespaces.  We probably would want to revisit that
> > one (perhaps with a new option and/or config to selectively
> > enable different kinds of whitespace check).

> I don't want to get into another stupid holy war about the superiority
> of indent styles (the last one was quite enough, thank you), but there
> are real projects out there that have a spaces-only-indent policy and
> use Git, and this change as is isn't good for them.

  Seconded.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

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

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

[Junio C Hamano]

Johan Herland <johan@herland.net> writes:

> What about making "git clean" _stash_ your changes instead of deleting them 
> (so that you can undo the clean)? Preferably they should be stashed 
> somewhere _other_ than where "git stash" does its thing. "git clean" could 
> even delete the stash immediately, but keep the reflog around so that 
> the "clean" at least could be undone within 30 days (or whatever is the 
> current default).
>
> Thoughts?

Unthoughts.  That does not mesh with the way how world works.

"git clean" is about things that git usually do not care about
(i.e. things not in .gitignore, or even in .gitignore when -x is
given).  Everything else including "git stash" is all about what
git cares about (i.e. tracked paths).

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

[Pierre Habouzit]

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

On Thu, Nov 01, 2007 at 06:33:13PM +0000, Linus Torvalds wrote:
> 
> 
> On Wed, 31 Oct 2007, Junio C Hamano wrote:
> > 
> > * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits
> >  + ...
> > 
> > It appears 1.5.4 will be, to a certain extent, a "Let's clean up
> > the internal implementation" release.  This series should become
> > part of it.  Hopefully will merge to 'master' soon, but I
> > haven't looked this series very closely yet.
> 
> I certainly think this should go in, but it does make one deficiency 
> painfully clear: the remaining shell scripts end up having all the old 
> flags behaviour.

  Those are not the only commands with issues: not all builtins are
migrated on the new option parser, and those with recursive options (I
mean the ones that use diff options e.g.) are not migrated yet either,
because the option parser does not supports a mechanism to deal with
them.

  The issue is not to let parse_option recurse into anoter option
structure, it's that if you do so, you want to express the address of
the "options" to patch in a relative and not absolute way, and I've not
decided myself mind about a way to do that yet.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

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

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

[Linus Torvalds]

On Thu, 1 Nov 2007, Junio C Hamano wrote:
> 
> "git clean" is about things that git usually do not care about
> (i.e. things not in .gitignore, or even in .gitignore when -x is
> given).  Everything else including "git stash" is all about what
> git cares about (i.e. tracked paths).

Right. I *love* "git clean". Real men have everything they care about 
tracked by git, and thus by definition "git clean" is the safest operation 
possible. I don't understand how anybody can call it "unsafe".

I just wish it was quiet by default - right now it takes a _loong_ time to 
clean out your crud just because it scrolls forever talking about all 
those girly files you don't want to keep - and that it had -x and -d on by 
default, so that us *real* men wouldn't have to type so much.

But making it accept combined options, so that you can do "git clean -xdq" 
would certainly already be a huge improvement.

But yeah, I guess we could make the "clean.Imagirlyman" option (or however 
the "please-don't-hurt-me-by-default" option is spelled) the default. That 
way I'd just feel *extra* manly for immediately disabling it, and laughing 
at you wimps.

			Linus

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

[Bill Lear]

On Thursday, November 1, 2007 at 15:05:44 (-0700) Linus Torvalds writes:
>...
>But yeah, I guess we could make the "clean.Imagirlyman" option (or however 
>the "please-don't-hurt-me-by-default" option is spelled) the default. That 
>way I'd just feel *extra* manly for immediately disabling it, and laughing 
>at you wimps.

Precisely my sentiments.


Bill

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

[Junio C Hamano]

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

> But yeah, I guess we could make the "clean.Imagirlyman" option (or however 
> the "please-don't-hurt-me-by-default" option is spelled) the default. That 
> way I'd just feel *extra* manly for immediately disabling it, and laughing 
> at you wimps.

That makes me a girly man, I would guess, as I just suggested
making clean.requireForce default to true in the next (or one
after) version of git ;-).

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

[Jonas Fonseca]

On Nov 1, 2007 10:17 PM, Geert Bosch <bosch@adacore.com> wrote:
> On Nov 1, 2007, at 16:27, Junio C Hamano wrote:
> > I think what you are trying to do is to deprecate or remove "git
> > clean".
>
> Yes, and in the meantime I'd like to discourage people
> from spending time and effort to upgrade it to first
> class built-in status.

If you search the archive you will find that a builtin-clean.c has already
been offered.

-- 
Jonas Fonseca

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

[Jakub Narebski]

Linus Torvalds wrote:

> On Wed, 31 Oct 2007, Junio C Hamano wrote:
>> 
>> * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits
>>  + ...
>> 
>> It appears 1.5.4 will be, to a certain extent, a "Let's clean up
>> the internal implementation" release.  This series should become
>> part of it.  Hopefully will merge to 'master' soon, but I
>> haven't looked this series very closely yet.
> 
> I certainly think this should go in, but it does make one deficiency 
> painfully clear: the remaining shell scripts end up having all the old 
> flags behaviour.

Is 'getopts' bash-ism, or is it in POSIX?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Junio C Hamano]

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

> I am personally very much in favor of removing "git clean", but
> having many people on the list saying loudly that it is a bad
> command is not good enough justification, as people who are
> content with the status quo tend to be silent.
>
> The steps I think is sensible to transition to that goal would
> be:
>
>  - Change clean.requireForce to default to 'true' in the next
>    (or one after) version of git, to make 'clean' even safer.
>    See if anybody complains (I do not expect any).
>
>  - Implement the same functionarity as a new option to "git rm",
>    which is already in C.
>
>  - Do "git clean" in C, but sharing the code with "git rm"
>    implementation above.
>
>  - Discuss deprecation and removal of redundant commands.  Ship
>    a version of git with deprecation and future removal notice.
>    Outline how to achieve the same thing as the deprecated
>    command used to do (or give convincing argument why what the
>    deprecated command used to do was a bad thing and do not
>    offer an alternative).
>
>  - Wait for a while (6 months to 1 year) and then remove them.

And this is the first step.

---

 Documentation/config.txt |    4 ++--
 git-clean.sh             |    6 +++++-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index edf50cd..2144855 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -345,8 +345,8 @@ branch.<name>.mergeoptions::
 	supported.
 
 clean.requireForce::
-	A boolean to make git-clean do nothing unless given -f or -n.  Defaults
-	to false.
+	A boolean to make git-clean do nothing unless given -f
+	or -n.   Defaults to true.
 
 color.branch::
 	A boolean to enable/disable color in the output of
diff --git a/git-clean.sh b/git-clean.sh
index 4491738..f4965b8 100755
--- a/git-clean.sh
+++ b/git-clean.sh
@@ -20,12 +20,16 @@ require_work_tree
 ignored=
 ignoredonly=
 cleandir=
-disabled="`git config --bool clean.requireForce`"
 rmf="rm -f --"
 rmrf="rm -rf --"
 rm_refuse="echo Not removing"
 echo1="echo"
 
+# requireForce used to default to false but now it defaults to true.
+# IOW, lack of explicit "clean.requireForce = false" is taken as
+# "clean.requireForce = true".
+disabled=$(git config --bool clean.requireForce || echo true)
+
 while test $# != 0
 do
 	case "$1" in

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

[Petr Baudis]

On Thu, Nov 01, 2007 at 03:05:44PM -0700, Linus Torvalds wrote:
> On Thu, 1 Nov 2007, Junio C Hamano wrote:
> > 
> > "git clean" is about things that git usually do not care about
> > (i.e. things not in .gitignore, or even in .gitignore when -x is
> > given).  Everything else including "git stash" is all about what
> > git cares about (i.e. tracked paths).

BTW, it comes from Cogito. Pavel Roskin is the author of the original
Cogito script and I'm not sure if it came there from anywhere else or is
an original "invention".

> Right. I *love* "git clean". Real men have everything they care about 
> tracked by git, and thus by definition "git clean" is the safest operation 
> possible. I don't understand how anybody can call it "unsafe".

I agree! If you want to keep anything around in git-tracked tree, tell
git about it! (Either marking it as ignored or adding it to the index.)
I think I wasn't too fond of it originally but now tend to use it a lot
to keep my trees clean of temporary cruft.

> I just wish it was quiet by default - right now it takes a _loong_ time to 
> clean out your crud just because it scrolls forever talking about all 
> those girly files you don't want to keep - and that it had -x and -d on by 
> default, so that us *real* men wouldn't have to type so much.

I do not agree with either, though. Having it verbose by default makes
it at least obvious that something potentially, uh, surprising is going
on; and I _prefer_ the non-x behaviour. If I told git that it should
ignore $file, it better not touch it.

> But yeah, I guess we could make the "clean.Imagirlyman" option (or however 
> the "please-don't-hurt-me-by-default" option is spelled) the default. That 
> way I'd just feel *extra* manly for immediately disabling it, and laughing 
> at you wimps.

Yeah!

-- 
				Petr "Pasky, laughing at the wimps" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish.		-- Marshall McLuhan

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

[Petr Baudis]

On Fri, Nov 02, 2007 at 01:04:03AM +0100, Jakub Narebski wrote:
> Is 'getopts' bash-ism, or is it in POSIX?

	http://www.opengroup.org/onlinepubs/009695399/utilities/getopts.html

(Also, most modern distributions have manpage section 1p (3p, ...) with
the same contents, so you can check for this stuff pretty easily.)

-- 
				Petr "Pasky" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish.		-- Marshall McLuhan

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

[Miles Bader]

Linus Torvalds <torvalds@linux-foundation.org> writes:
> So while you can combine flags for *most* programs, you still won't 
> be able to say things like
>
> 	git clean -qdx
>
> just because that's still a shellscript, and doing any fancy argument 
> parsing in shell is just painful.

Indeed... but for my personal shell scripts I like to use a construct
like the following for parsing args:

   while :; do
     case "$1" in
        ... lots of cases to handle normal args ...

       -[!-]?*)
         # split concatenated single-letter options apart
         FIRST="$1"; shift
         set -- `echo $FIRST | $SED 's/-\(.\)\(.*\)/-\1 -\2/'` "$@"
         ;;

       -*)
         # unrecognized option
         unrec_opt "$1"; exit 1;;
       *)
         # non-option
         break;
     esac
   done

I'm sure there are problems with it, but it generally seems to work
pretty reasonably for short options.

-Miles
-- 
97% of everything is grunge

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

[Jakub Narebski]

Petr Baudis napisał:
> On Fri, Nov 02, 2007 at 01:04:03AM +0100, Jakub Narebski wrote:

>> Is 'getopts' bash-ism, or is it in POSIX?
> 
> 	http://www.opengroup.org/onlinepubs/009695399/utilities/getopts.html
> 
> (Also, most modern distributions have manpage section 1p (3p, ...) with
> the same contents, so you can check for this stuff pretty easily.)

Thanks.

I have just realized however that it doesn't help any (option parser
not only for C builtin, but also for shell scripts, Perl scripts and
Python scripts). First, we (the git development community) do not
consider fact that something is in POSIX as indicator that we can use
the construct. Second, getopts delas IIRC only with _short_ options.

-- 
Jakub Narebski
Poland

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

[Jakub Narebski]

Jakub Narebski wrote:
> Petr Baudis wrote:
> > On Fri, Nov 02, 2007 at 01:04:03AM +0100, Jakub Narebski wrote:
> 
> >> Is 'getopts' bash-ism, or is it in POSIX?
> > 
> > 	http://www.opengroup.org/onlinepubs/009695399/utilities/getopts.html
> > 
> > (Also, most modern distributions have manpage section 1p (3p, ...) with
> > the same contents, so you can check for this stuff pretty easily.)
> 
> Thanks.
> 
> I have just realized however that it doesn't help any (option parser
> not only for C builtin, but also for shell scripts, Perl scripts and
> Python scripts). First, we (the git development community) do not
> consider fact that something is in POSIX as indicator that we can use
> the construct. Second, getopts delas IIRC only with _short_ options.

Just a thought:
  http://www.systhread.net/texts/200704optparse.php

-- 
Jakub Narebski
Poland

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

[Pierre Habouzit]

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

On Fri, Nov 02, 2007 at 07:28:30AM +0000, Jakub Narebski wrote:
> Jakub Narebski wrote:
> > Petr Baudis wrote:
> > > On Fri, Nov 02, 2007 at 01:04:03AM +0100, Jakub Narebski wrote:
> > 
> > >> Is 'getopts' bash-ism, or is it in POSIX?
> > > 
> > > 	http://www.opengroup.org/onlinepubs/009695399/utilities/getopts.html
> > > 
> > > (Also, most modern distributions have manpage section 1p (3p, ...) with
> > > the same contents, so you can check for this stuff pretty easily.)
> > 
> > Thanks.
> > 
> > I have just realized however that it doesn't help any (option parser
> > not only for C builtin, but also for shell scripts, Perl scripts and
> > Python scripts). First, we (the git development community) do not
> > consider fact that something is in POSIX as indicator that we can use
> > the construct. Second, getopts delas IIRC only with _short_ options.
> 
> Just a thought:
>   http://www.systhread.net/texts/200704optparse.php

Well, I'm sure we could probably do the same with our own `git-parseopt`
tool, couldn't we ?

I'll try to give it a shot, and it'll have all the features shell-script
currently have at great costs of code length (like the lazy way to type
long options: -q|--q|--qu|--qui|...)

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

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

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

[Andreas Ericsson]

Linus Torvalds wrote:
> 
> On Wed, 31 Oct 2007, Junio C Hamano wrote:
>> * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits
>>  + ...
>>
>> It appears 1.5.4 will be, to a certain extent, a "Let's clean up
>> the internal implementation" release.  This series should become
>> part of it.  Hopefully will merge to 'master' soon, but I
>> haven't looked this series very closely yet.
> 
> I certainly think this should go in, but it does make one deficiency 
> painfully clear: the remaining shell scripts end up having all the old 
> flags behaviour.
> 
> So while you can combine flags for *most* programs, you still won't 
> be able to say things like
> 
> 	git clean -qdx
> 
> just because that's still a shellscript, and doing any fancy argument 
> parsing in shell is just painful.
> 
> Is somebody still working on doing the shell->C conversion?
> 

Me, although my git work is happening with the speed of continental drift
at the moment.

git-merge and git-pull are (slowly) being converted. It's more in the
nature of a learning experience for me than "oh shit I need this fast"
though. Hence the blazing speed with which I work ;-)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Andreas Ericsson]

Pierre Habouzit wrote:
> On Thu, Nov 01, 2007 at 08:27:55PM +0000, Junio C Hamano wrote:
>> Geert Bosch <bosch@adacore.com> writes:
>>
>>> I often type "make clean" as well many "git xyz" commands
>>> during development, and so it happens that at times, I type
>>> "git clean" by accident.
>> Happened to me once.  I hate that command.
>>
>>> So, I propose *not* converting git clean to a C builtin,
>>> but instead adding --untracked and --ignored options to
>>> git-rm.
>> I think what you are trying to do is to deprecate or remove "git
>> clean".
>>
>> I do not know where "git clean" came from.  I am suspecting that
>> it was to give counterparts to some other SCMs, but do not know
>> which ones.  Some people wanted to have it --- so you need to
>> convince them that it is a bad idea first.  Adding an equivalent
>> options to "git rm" alone does not solve that issue.
> 
>   FWIW I do use git clean a _lot_. I don't mind if it's doable from
> another kind of command, but I do use git clean and even git clean -x a
> lot, because it achives cleansing my repository faster (and sometimes
> faster) than a `make distclean` would do.
> 

I'm of two minds about this. On the one hand, it's incredibly useful to
clear out an imported repository where distlcean doesn't quite distclean.
We also use it for our autobuild tools (although that's just us being lazy).

On the other hand, I've been bit by the brain-bug once and done a git clean
when I really meant make clean.

Changing it to the wimpy 'rm -i' equivalent would reduce risk substantially
while maintaining its usefulness, so +1 to Junio's patch, I guess.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Wincent Colaiuta]

El 1/11/2007, a las 22:41, Brian Downing escribió:

> On Wed, Oct 31, 2007 at 10:41:06PM -0700, Junio C Hamano wrote:
>> * jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit
>> - git-diff: complain about >=8 consecutive spaces in initial indent
>>
>> This is a counterpart of an earlier patch from J. Bruce Fields
>> to change "git-apply --whitespace" to make SP{8,} at the
>> beginning of line a whitespace error.
>>
>> Personally, I am in favor of the stricter check, but I had to
>> reject the "git-apply" patch because there was no way to disable
>> the additional check without disabling the existing check for
>> trailing whitespaces.  We probably would want to revisit that
>> one (perhaps with a new option and/or config to selectively
>> enable different kinds of whitespace check).
>
> Just to throw in my two cents, I would be strongly opposed to this
> going in without some form of configuration to make it work for
> spaces-only-indent projects.

Ditto, I also work on some projects which have a spaces-only policy,  
and the proposed change would be quite painful when working on those  
projects, so configurability would be very important to me.

Cheers,
Wincent

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

[Johannes Schindelin]

Hi,

On Fri, 2 Nov 2007, Andreas Ericsson wrote:

> Linus Torvalds wrote:
> > 
> > On Wed, 31 Oct 2007, Junio C Hamano wrote:
> > > * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits
> > >  + ...
> > > 
> > > It appears 1.5.4 will be, to a certain extent, a "Let's clean up
> > > the internal implementation" release.  This series should become
> > > part of it.  Hopefully will merge to 'master' soon, but I
> > > haven't looked this series very closely yet.
> > 
> > I certainly think this should go in, but it does make one deficiency
> > painfully clear: the remaining shell scripts end up having all the old
> > flags behaviour.
> > 
> > So while you can combine flags for *most* programs, you still won't be able
> > to say things like
> > 
> > 	git clean -qdx
> > 
> > just because that's still a shellscript, and doing any fancy argument
> > parsing in shell is just painful.
> > 
> > Is somebody still working on doing the shell->C conversion?
> > 
> 
> Me, although my git work is happening with the speed of continental drift
> at the moment.
> 
> git-merge and git-pull are (slowly) being converted. It's more in the
> nature of a learning experience for me than "oh shit I need this fast"
> though. Hence the blazing speed with which I work ;-)

If you would share what you have on repo.or.cz, others could help at a 
faster pace, instead of duplicating your work or waiting for you to 
finish.

Ciao,
Dscho

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

[Miles Bader]

I previously wrote:
> Indeed... but for my personal shell scripts I like to use a construct
> like the following for parsing args:

In a little more detail, the arg-splitting case:

>        -[!-]?*)
>          # split concatenated single-letter options apart
>          FIRST="$1"; shift
>          set -- `echo $FIRST | $SED 's/-\(.\)\(.*\)/-\1 -\2/'` "$@"
>          ;;

Just strips off the first short option and stuffs it back into the list
of args to parse, so "-xyz" becomes "-x -yz".  That way short args get
split by default, but short-args with an appended value still work
correctly.

So, for instance, if in the above example, "-y" takes an argument, then
there'd be a switch case case for "-y*") which would consume the "-yz"
before it reached the arg-splitting case; if "-y" _doesn't_ take an
argument, then "-yz" would get split in turn, becoming "-y -z".

-Miles

-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.

What's cooking in git.git (topics)

[Junio C Hamano]

(Note.  I haven't dealt with the patch queue from today yet)

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.

* cp/p4 (Thu Nov 1 20:43:14 2007 -0700) 2 commits
 + git-p4: Detect changes to executable bit and include them in p4
   submit.
 + git-p4: Add a helper function to parse the full git diff-tree
   output.

I would like to get success stories from p4 users before pushing
this out.

* rr/cvsexportcommit-w (Wed Oct 31 23:12:20 2007 +0100) 1 commit
 + cvsexportcommit: Add switch to specify CVS workdir

I would like to get success stories from CVS users before
pushing this out.

* db/remote-builtin (Mon Oct 29 22:03:42 2007 -0400) 4 commits
 + Use built-in send-pack.
 + Build-in send-pack, with an API for other programs to call.
 + Build-in peek-remote, using transport infrastructure.
 + Miscellaneous const changes and utilities

Looked Ok.  Hopefully will be in 'master' shortly.

* np/fetch (Sat Nov 3 01:32:48 2007 -0400) 1 commit
 + git-fetch: more terse fetch output

Will merge to 'master'.

* jn/gitweb (Sat Nov 3 00:41:20 2007 +0100) 9 commits
 + gitweb: Use config file for repository description and URLs
 + gitweb: Read repo config using 'git config -z -l'
 + gitweb: Add tests for overriding gitweb config with repo config
 + gitweb: Use href(-replay=>1, action=>...) to generate alternate
   views
 + gitweb: Use href(-replay=>1, page=>...) to generate pagination
   links
 + gitweb: Easier adding/changing parameters to current URL
 + gitweb: Remove CGI::Carp::set_programname() call from t9500 gitweb
   test
 + gitweb: Add 'status_str' to parse_difftree_raw_line output
 + gitweb: Always set 'from_file' and 'to_file' in
   parse_difftree_raw_line

Will push these out to 'master' over the weekend.

* jc/format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
 + test format-patch -s: make sure MIME content type is shown as
   needed
 + format-patch -s: add MIME encoding header if signer's name
   requires so

This hopefully fixes a real issue we had at vger recently.

	http://article.gmane.org/gmane.comp.version-control.git/62689

Will merge to 'master' shortly, and then cherry-pick to 'maint'.

* np/pack (Thu Nov 1 23:43:24 2007 -0400) 2 commits
 + pack-objects: get rid of an ugly cast
 + make the pack index version configurable

Will merge to 'master'.

* ss/mailsplit (Thu Nov 1 23:57:45 2007 +0100) 1 commit
 + Make mailsplit and mailinfo strip whitespace from the start of the
   input

Will merge to 'master'.

* lt/rev-list-replay (Fri Nov 2 13:35:17 2007 -0700) 2 commits
 - Support "history replay" for git log commands
 - Simplify topo-sort logic

Need to drop the second one and replace it with today's "Final
output" patch.  The first one should be mergeable to 'master'
immediately and independently.

* dz/color-addi (Mon Oct 22 16:08:01 2007 -0500) 2 commits
 - Let git-add--interactive read colors from .gitconfig
 - Added basic color support to git add --interactive

Further comments on minor issues sent back to the author.

* jc/revert-merge (Fri Nov 2 17:25:24 2007 -0700) 2 commits
 + cherry-pick/revert -m: add tests
 + revert/cherry-pick: work on merge commits as well

Will merge to 'master'.

* jc/stash-create (Thu Nov 1 14:30:30 2007 -0700) 4 commits
 + git-merge: no reason to use cpio anymore
 + Revert "rebase: allow starting from a dirty tree."
 + rebase: allow starting from a dirty tree.
 + stash: implement "stash create"

Dropped the unconditional auto-stash-unstash, but "stash create"
turns out to be a useful alternative to cpio in the git-merge
implementation.

* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits
 + core.whitespace: add test for diff whitespace error highlighting
 + git-diff: complain about >=8 consecutive spaces in initial indent
 + War on whitespace: first, a bit of retreat.

I actually like the idea of tying this to gitattributes by J
Bruce Fields.  We would want to have such an update before
pushing this out to 'master'.  "diff" alone would not do any
harm but "apply" can reject and/or munge the user input, and we
really would want to get the semantics right with the first
version that appears on 'master'.

* kh/commit (Fri Nov 2 11:33:09 2007 -0400) 3 commits
 - Implement git commit and status as a builtin commands.
 - Export launch_editor() and make it accept ':' as a no-op editor.
 - Add testcase for ammending and fixing author in git commit.

There may be still some glitches left, but it is hopefully
gettng into a "testable without breaking things too much" shape
(which is the definition of 'next').

* ph/parseopt-sh (Fri Nov 2 23:39:52 2007 +0100) 5 commits
 - Migrate git-am.sh to use git-rev-parse --parseopt
 - Migrate git-clone to use git-rev-parse --parseopt
 - Migrate git-clean.sh to use git-rev-parse --parseopt.
 - Update git-sh-setup(1) to allow transparent use of git-rev-parse -
   -parseopt
 - Add a parseopt mode to git-rev-parse to bring parse-options to
   shell scripts.

Together with today's batch which is missing from the above
list, hopefully merge to 'next' over the weekend.

* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
 - Make git-svn rebase --dirty pass along --dirty to git-rebase.
 - Implement --dirty for git-rebase--interactive.
 - Introduce --dirty option to git-rebase, allowing you to start from
   a dirty state.

This needs tests to primarily make sure that it does not regress
non --dirty case.

* sp/push-refspec (Sun Oct 28 18:46:20 2007 +0100) 6 commits
 - push: teach push to pass --verbose option to transport layer
 - push: teach push to accept --verbose option
 - push: use same rules as git-rev-parse to resolve refspecs
 - add ref_abbrev_matches_full_with_rev_parse_rules() comparing
   abbrev with full ref name
 - rename ref_matches_abbrev() to
   ref_abbrev_matches_full_with_fetch_rules()
 - push: support pushing HEAD to real branch name

Will need to review first.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 - merge-nu: a new merge backend without using unpack_trees()
 - read_tree: take an explicit index structure
 - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

* 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.

* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
 - handle renames using similarity engine
 - introduce generic similarity library
 - change hash table calling conventions

Unchanged.

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

[Jakub Narebski]

[Cc: Junio C Hamano <gitster@pobox.com>, git @vger.kernel.org]

Junio C Hamano wrote:

> * jn/gitweb (Sat Nov 3 00:41:20 2007 +0100) 9 commits

Now that I have sned those patches ;-) I have a few doubts about them

>  + gitweb: Use config file for repository description and URLs
>  + gitweb: Read repo config using 'git config -z -l'

I'd like some comments on that series, preferably by someone better 
with Perl than me, but I think this is a good change performance wise.

>  + gitweb: Add tests for overriding gitweb config with repo config

More tests is always good.

>  + gitweb: Use href(-replay=>1, action=>...) to generate alternate
>    views
>  + gitweb: Use href(-replay=>1, page=>...) to generate pagination
>    links
>  + gitweb: Easier adding/changing parameters to current URL

Now I'm not so sure about this, because it changes semantics of "next page"
and alternate view links: after this series they count from current
version, not from the displayed version.

But perhaps those doubts are unnecessary...

>  + gitweb: Remove CGI::Carp::set_programname() call from t9500 gitweb
>    test

This removes unnecessary code, which can cause mysterious errors.

>  + gitweb: Add 'status_str' to parse_difftree_raw_line output
>  + gitweb: Always set 'from_file' and 'to_file' in
>    parse_difftree_raw_line

This simplifies gitweb code, and I think there aren't any issues with those
patches.
 
> Will push these out to 'master' over the weekend.

Thanks.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Pierre Habouzit]

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

On Sun, Nov 04, 2007 at 04:14:19AM +0000, Junio C Hamano wrote:
> * ph/parseopt-sh (Fri Nov 2 23:39:52 2007 +0100) 5 commits
>  - Migrate git-am.sh to use git-rev-parse --parseopt
>  - Migrate git-clone to use git-rev-parse --parseopt
>  - Migrate git-clean.sh to use git-rev-parse --parseopt.
>  - Update git-sh-setup(1) to allow transparent use of git-rev-parse -
>    -parseopt
>  - Add a parseopt mode to git-rev-parse to bring parse-options to
>    shell scripts.
> 
> Together with today's batch which is missing from the above
> list, hopefully merge to 'next' over the weekend.

  Please note that the last resend has the issues you raised fixed and
that it modifies git-clone and git-sh-setup commits from above.

  Someone proposed many fixes in the documentation too, I wont do it
because (again) I'm not a native speaker so I let that ungrateful job to
someone actually able to do it.

Cheers,
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

----------------------------------------------------------------
[Will merge to 'master' this weekend]

* js/parseopt-abbrev-fix (Mon Nov 5 13:15:21 2007 +0000) 1 commit
 + parse-options: abbreviation engine fix.

* js/reset (Sat Nov 3 15:21:21 2007 +0000) 2 commits
 + builtin-reset: avoid forking "update-index --refresh"
 + builtin-reset: do not call "ls-files --unmerged"

* js/upload-pack (Sun Nov 4 20:46:48 2007 +0100) 1 commit
 + upload-pack: Use finish_{command,async}() instead of waitpid().

----------------------------------------------------------------
[Will cook til next week and then merge to 'master']

* bg/format-patch-N (Tue Nov 6 10:04:24 2007 +1100) 3 commits
 + Rearrange git-format-patch synopsis to improve clarity.
 + format-patch: Test --[no-]numbered and format.numbered
 + format-patch: Add configuration and off switch for --numbered

* db/remote-builtin (Tue Nov 6 20:29:20 2007 -0500) 6 commits
 + Reteach builtin-ls-remote to understand remotes
 + Build in ls-remote
 + Use built-in send-pack.
 + Build-in send-pack, with an API for other programs to call.
 + Build-in peek-remote, using transport infrastructure.
 + Miscellaneous const changes and utilities

* jc/stash-create (Wed Nov 7 15:10:27 2007 -0600) 5 commits
 + git-stash: Fix listing stashes
 + git-merge: no reason to use cpio anymore
 + Revert "rebase: allow starting from a dirty tree."
 + rebase: allow starting from a dirty tree.
 + stash: implement "stash create"

* lt/rev-list-interactive (Mon Nov 5 13:22:34 2007 -0800) 4 commits
 + revision walker: mini clean-up
 + Enhance --early-output format
 + Add "--early-output" log flag for interactive GUI use
 + Simplify topo-sort logic

* jk/terse-push (Mon Nov 5 00:12:18 2007 -0500) 6 commits
 + send-pack: require --verbose to show update of tracking refs
 + receive-pack: don't mention successful updates
 + more terse push output
 + Build-in send-pack, with an API for other programs to call.
 + Build-in peek-remote, using transport infrastructure.
 + Miscellaneous const changes and utilities

* mh/retag (Sun Nov 4 01:11:15 2007 +0100) 2 commits
 + Add tests for git tag
 + Reuse previous annotation when overwriting a tag

* np/progress (Tue Nov 6 16:30:28 2007 -0500) 6 commits
 + make display of total transferred fully accurate
 + remove dead code from the csum-file interface
 + git-fetch: be even quieter.
 + make display of total transferred more accurate
 + sideband.c: ESC is spelled '\033' not '\e' for portability.
 + fix display overlap between remote and local progress

----------------------------------------------------------------
[Actively cooking]

* ph/parseopt-sh (Wed Nov 7 23:04:38 2007 -0800) 14 commits
 + git-sh-setup: fix parseopt `eval` string underquoting
 + Give git-am back the ability to add Signed-off-by lines.
 + git-rev-parse --parseopt
 + scripts: Add placeholders for OPTIONS_SPEC
 + Migrate git-repack.sh to use git-rev-parse --parseopt
 + Migrate git-quiltimport.sh to use git-rev-parse --parseopt
 + Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-
   dashdash
 + Migrate git-instaweb.sh to use git-rev-parse --parseopt
 + Migrate git-merge.sh to use git-rev-parse --parseopt
 + Migrate git-am.sh to use git-rev-parse --parseopt
 + Migrate git-clone to use git-rev-parse --parseopt
 + Migrate git-clean.sh to use git-rev-parse --parseopt.
 + Update git-sh-setup(1) to allow transparent use of git-rev-parse -
   -parseopt
 + Add a parseopt mode to git-rev-parse to bring parse-options to
   shell scripts.

We are still finding breakages and applying fixes.

* rs/pretty (Wed Nov 7 00:17:14 2007 +0100) 1 commit
 - pretty=format: Avoid some expensive calculations when not needed

The numbers are impressive and the code is reasonably clean, but
René seems to have further improvements to the API?

* sb/clean (Sun Nov 4 13:02:21 2007 -0600) 1 commit
 - Make git-clean a builtin

I ran out of time to look at the replacement patch.  Sorry.

* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
 - Make git-svn rebase --dirty pass along --dirty to git-rebase.
 - Implement --dirty for git-rebase--interactive.
 - Introduce --dirty option to git-rebase, allowing you to start from
   a dirty state.

Really need to look at this series to merge to 'next'.  Sorry.

* sp/push-refspec (Sun Oct 28 18:46:20 2007 +0100) 5 commits
 - push: teach push to pass --verbose option to transport layer
 - push: use same rules as git-rev-parse to resolve refspecs
 - add ref_abbrev_matches_full_with_rev_parse_rules() comparing
   abbrev with full ref name
 - rename ref_matches_abbrev() to
   ref_abbrev_matches_full_with_fetch_rules()
 - push: support pushing HEAD to real branch name

Really need to look at this series to merge to 'next'.  Sorry.

----------------------------------------------------------------
[Stalled]

* bs/maint-commit-options (Mon Nov 5 20:36:33 2007 +0100) 1 commit
 - git-commit.sh: Fix usage checks regarding paths given when they do
   not make sense

This is waiting for tests.  Then merge to 'next', 'master' and
then to 'maint'.

* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
 + Add missing inside_work_tree setting in setup_git_directory_gently

This is waiting for tests.  Then merge to 'next', 'master' and
then to 'maint'.

* rr/cvsexportcommit-w (Wed Oct 31 23:12:20 2007 +0100) 1 commit
 + cvsexportcommit: Add switch to specify CVS workdir

Need success stories, but pushing it out to 'master' may be the
only way to get users' attention.

* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits
 + core.whitespace: add test for diff whitespace error highlighting
 + git-diff: complain about >=8 consecutive spaces in initial indent
 + War on whitespace: first, a bit of retreat.

Remaining tasks are:

 1. teach "git-apply --whitespace=[warn|strip]" the same;
 2. (possibly) use gitattributes instead of config.

* dz/color-addi (Mon Oct 22 16:08:01 2007 -0500) 2 commits
 - Let git-add--interactive read colors from .gitconfig
 - Added basic color support to git add --interactive

There was a RFH to avoid "require Term::ANSIColor" in Git.pm and
a suggestion in response to it, but I do not recall
anything happened afterwards.  Stalled.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

This does not have a in-tree user yet.

* kh/commit (Fri Nov 2 11:33:09 2007 -0400) 3 commits
 - Implement git commit and status as a builtin commands.
 - Export launch_editor() and make it accept ':' as a no-op editor.
 - Add testcase for ammending and fixing author in git commit.

This does not pass tests.

* sp/fetch-fix (Tue Nov 6 21:41:18 2007 -0500) 2 commits
 - git-fetch: avoid local fetching from alternate (again)
 - run-command: allow discarding the standard error output

This does not pass tests (breaks shallow clone deepening).

* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
 - handle renames using similarity engine
 - introduce generic similarity library
 - change hash table calling conventions

This does not pass tests.

* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
 - test format-patch -s: make sure MIME content type is shown as
   needed
 - format-patch -s: add MIME encoding header if signer's name
   requires so

This is already in 'master' but rebased for 'maint', just in
case we would want a maint release with this series.

* jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit
 - git-branch --with=commit

This was just for fun.

* 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.

My pet peeve.  Completely stalled.

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 - merge-nu: a new merge backend without using unpack_trees()
 - read_tree: take an explicit index structure
 - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

Seriously stalled.

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

[Steffen Prohaska]

On Nov 8, 2007, at 9:08 AM, Junio C Hamano wrote:

> * sp/push-refspec (Sun Oct 28 18:46:20 2007 +0100) 5 commits
>  - push: teach push to pass --verbose option to transport layer
>  - push: use same rules as git-rev-parse to resolve refspecs
>  - add ref_abbrev_matches_full_with_rev_parse_rules() comparing
>    abbrev with full ref name
>  - rename ref_matches_abbrev() to
>    ref_abbrev_matches_full_with_fetch_rules()
>  - push: support pushing HEAD to real branch name
>
> Really need to look at this series to merge to 'next'.  Sorry.

Take your time. There is a slight chance that I'll unify
ref_abbrev_matches_full_with_rev_parse_rules() and  
ref_abbrev_matches_full_with_fetch_rules() over the weekend.

	Steffen

What's cooking in git.git (topics)

[Junio C Hamano]

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

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

* rs/pretty (Sat Nov 10 12:55:48 2007 +0100) 6 commits
 + Simplify strchrnul() compat code
 + --format=pretty: avoid calculating expensive expansions twice
 + add strbuf_adddup()
 + --pretty=format: parse commit message only once
 + --pretty=format: on-demand format expansion
 + Add strchrnul()

* np/progress (Thu Nov 8 15:45:41 2007 -0500) 7 commits
 + nicer display of thin pack completion
 + make display of total transferred fully accurate
 + remove dead code from the csum-file interface
 + git-fetch: be even quieter.
 + make display of total transferred more accurate
 + sideband.c: ESC is spelled '\033' not '\e' for portability.
 + fix display overlap between remote and local progress

* bg/format-patch-N (Tue Nov 6 10:04:24 2007 +1100) 3 commits
 + Rearrange git-format-patch synopsis to improve clarity.
 + format-patch: Test --[no-]numbered and format.numbered
 + format-patch: Add configuration and off switch for --numbered

* lt/rev-list-interactive (Mon Nov 5 13:22:34 2007 -0800) 4 commits
 + revision walker: mini clean-up
 + Enhance --early-output format
 + Add "--early-output" log flag for interactive GUI use
 + Simplify topo-sort logic

* db/remote-builtin (Tue Nov 6 20:29:20 2007 -0500) 6 commits
 + Reteach builtin-ls-remote to understand remotes
 + Build in ls-remote
 + Use built-in send-pack.
 + Build-in send-pack, with an API for other programs to call.
 + Build-in peek-remote, using transport infrastructure.
 + Miscellaneous const changes and utilities

With the "ls-remote origin" fix at its tip, this should be
ready.

* jk/terse-push (Thu Nov 8 01:38:12 2007 -0800) 7 commits
 + send-pack: segfault fix on forced push
 + send-pack: require --verbose to show update of tracking refs
 + receive-pack: don't mention successful updates
 + more terse push output

With the segfault fix at its tip, I think this is ready.  This
depends on the early parts of db/remote-builtin series.

* jc/stash-create (Wed Nov 7 15:10:27 2007 -0600) 5 commits
 + git-stash: Fix listing stashes
 + git-merge: no reason to use cpio anymore
 + Revert "rebase: allow starting from a dirty tree."
 + rebase: allow starting from a dirty tree.
 + stash: implement "stash create"

The end result of this series is just to remove one use of cpio
in our scripts; this should be ready.

* gh/cvsimport-user (Thu Nov 8 13:15:20 2007 -0700) 1 commit
 + git-cvsimport: fix handling of user name when it is not set in
   CVSROOT

* rr/cvsexportcommit-w (Wed Oct 31 23:12:20 2007 +0100) 1 commit
 + cvsexportcommit: Add switch to specify CVS workdir

* ds/checkout-upper (Fri Nov 9 20:12:28 2007 +1100) 2 commits
 + git-checkout: Test for relative path use.
 + git-checkout: Support relative paths containing "..".

This will allow you to stay in a subdirectory and checking out
paths in directories outside.  With Dscho's "git status" that
shows relatives paths (in kh/commit series), this would make
cutting and pasting easier.

* mh/retag (Sun Nov 4 01:11:15 2007 +0100) 2 commits
 + Add tests for git tag
 + Reuse previous annotation when overwriting a tag

* jc/maint-add-sync-stat (Sun Nov 11 18:44:16 2007 -0800) 3 commits
 + t2200: test more cases of "add -u"
 + git-add: make the entry stat-clean after re-adding the same
   contents
 + ce_match_stat, run_diff_files: use symbolic constants for
   readability

Meant to eventually go to 'maint'.  I added tests so now this
series can go to 'next'.

* bs/maint-t7005 (Sun Nov 11 18:38:11 2007 +0100) 1 commit
 + t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH

Meant to eventually go to 'maint'.

* sp/maint-plug-traverse-commit-list-leak (Fri Nov 9 06:06:10 2007 -0500) 1 commit
 + Fix memory leak in traverse_commit_list

Meant to eventually go to 'maint'.

* rv/maint-index-commit (Sun Nov 11 13:28:08 2007 +0100) 1 commit
 + Make GIT_INDEX_FILE apply to git-commit

Meant to eventually go to 'maint'.  The test needs to be run
with Kristian's rewrite in C to catch any regression.


----------------------------------------------------------------
[Still actively cooking]

* ph/parseopt-sh (Thu Nov 8 23:04:31 2007 -0800) 16 commits
 + git-am: -i does not take a string parameter.
 + sh-setup: don't let eval output to be shell-expanded.
 + git-sh-setup: fix parseopt `eval` string underquoting
 + Give git-am back the ability to add Signed-off-by lines.
 + git-rev-parse --parseopt
 + scripts: Add placeholders for OPTIONS_SPEC
 + Migrate git-repack.sh to use git-rev-parse --parseopt
 + Migrate git-quiltimport.sh to use git-rev-parse --parseopt
 + Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-
   dashdash
 + Migrate git-instaweb.sh to use git-rev-parse --parseopt
 + Migrate git-merge.sh to use git-rev-parse --parseopt
 + Migrate git-am.sh to use git-rev-parse --parseopt
 + Migrate git-clone to use git-rev-parse --parseopt
 + Migrate git-clean.sh to use git-rev-parse --parseopt.
 + Update git-sh-setup(1) to allow transparent use of git-rev-parse -
   -parseopt
 + Add a parseopt mode to git-rev-parse to bring parse-options to
   shell scripts.

The rate of incoming changes to fix breakage with this topic has
slowed down, which is a good indication that this is getting
ready.

* sp/fetch-fix (Sun Nov 11 02:29:47 2007 -0500) 6 commits
 + git-fetch: avoid local fetching from alternate (again)
 + rev-list: Introduce --quiet to avoid /dev/null redirects
 + run-command: Support sending stderr to /dev/null
 + git-fetch: Always fetch tags if the object they reference exists
 + Merge branch 'sp/maint-plug-traverse-commit-list-leak' into
   sp/fetch-fix

This should restore the traditional behaviour of git-fetch in
the C rewrite series.

* js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
 + rebase: operate on a detached HEAD

----------------------------------------------------------------
[Approaching 'next']

* kh/commit (Sun Nov 11 17:36:52 2007 +0000) 12 commits
 - builtin-commit: Add newline when showing which commit was created
 - builtin-commit: resurrect behavior for multiple -m options
 - builtin-commit --s: add a newline if the last line was not a S-o-b
 - builtin-commit: fix --signoff
 - git status: show relative paths when run in a subdirectory
 - builtin-commit: fix author date with --amend --author=<author>
 - builtin-commit: Refresh cache after adding files.
 - builtin-commit: fix reflog message generation
 - launch_editor(): read the file, even when EDITOR=:
 - Port git commit to C.
 - Export launch_editor() and make it accept ':' as a no-op editor.
 - Add testcase for ammending and fixing author in git commit.

Dscho fixed a handful obvious glitches.  I am hoping that this
series should be in "testable" shape now.  Will merge to "next"
after giving it a final round of eyeballing.

* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
 - refactor fetch's ref matching to use refname_match()
 - push: use same rules as git-rev-parse to resolve refspecs
 - add refname_match()
 - push: support pushing HEAD to real branch name

This changes the semantics slightly but I think it is a move in
the right direction.

* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
 - Added diff hunk coloring to git-add--interactive
 - Let git-add--interactive read colors from .gitconfig
 - Added basic color support to git add --interactive

* aw/mirror-push (Fri Nov 9 23:32:57 2007 +0000) 16 commits
 - git-push: add documentation for the newly added --mirror mode
 - Add tests for git push'es mirror mode
 - git-push: plumb in --mirror mode
 - Teach send-pack a mirror mode

Looking good.

This depends on Jeff's "even terser push output" series which in
turn depends on Daniel's "rewrite ls-remote and send-pack to
build them in" series, both of which should graduate to 'master'
hopefully shortly.

* ph/diffopts (Wed Nov 7 11:20:32 2007 +0100) 6 commits
 - Reorder diff_opt_parse options more logically per topics.
 - Make the diff_options bitfields be an unsigned with explicit
   masks.
 + Use OPT_BIT in builtin-pack-refs
 + Use OPT_BIT in builtin-for-each-ref
 + Use OPT_SET_INT and OPT_BIT in builtin-branch
 + parse-options new features.

Although I found the whole series reasonable, I parked the later
parts of the series in 'pu' because diff is one of the more
important parts of the system.

* cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit
 - Make builtin-tag.c use parse_options.

This changes the handling of multiple -m option without much
good reason.  It should be a simple fix, once we know what we
want.  I think the existing behaviour of refusing multiple -m
is probably the most sane at this point.

* sb/clean (Tue Nov 6 23:18:51 2007 -0600) 1 commit
 - Make git-clean a builtin

----------------------------------------------------------------
[Stalled]

* bs/maint-commit-options (Mon Nov 5 20:36:33 2007 +0100) 1 commit
 - git-commit.sh: Fix usage checks regarding paths given when they do
   not make sense

This is meant to go to 'maint' but needs test script to exhibit
the existing breakage and demonstrate the fix.

The test will help catching future regression even after we
replace git-commit with Kristian's rewrite in C.

* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
 + Add missing inside_work_tree setting in setup_git_directory_gently

This is meant to go to 'maint' but needs test script to exhibit
the existing breakage and demonstrate the fix.

* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits
 + core.whitespace: add test for diff whitespace error highlighting
 + git-diff: complain about >=8 consecutive spaces in initial indent
 + War on whitespace: first, a bit of retreat.

Teaching "git apply --whitespace=[warn|strip]" to honor the same
configuration would be a good addition, but this could go to
'master' as is.

----------------------------------------------------------------
[Others]

* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
 - Do git reset --hard HEAD when using git rebase --skip

Some people on the list may find this debatable.

* jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit
 - git-branch --with=commit

I did this just for my own fun.

* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
 - test format-patch -s: make sure MIME content type is shown as
   needed
 - format-patch -s: add MIME encoding header if signer's name
   requires so

This is to apply to 'maint' later; the equivalent fix is already
in 'master'.

* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
 - Make git-svn rebase --dirty pass along --dirty to git-rebase.
 - Implement --dirty for git-rebase--interactive.
 - Introduce --dirty option to git-rebase, allowing you to start from
   a dirty state.

This seems to be optimized for the --dirty case too much.  I'd
prefer an implementation that make rebases without --dirty to
pay no penalty (if that is possible, otherwise "as little as
possible").

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 - merge-nu: a new merge backend without using unpack_trees()
 - read_tree: take an explicit index structure
 - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

* 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.

* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
 - handle renames using similarity engine
 - introduce generic similarity library
 - change hash table calling conventions

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

[Johannes Schindelin]

Hi,

On Sun, 11 Nov 2007, Junio C Hamano wrote:

> * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
>  + rebase: operate on a detached HEAD

Note: this might have a subtle bug when the last patch in the series 
failed.  If I was not too tired this morning (which might well have been 
the case), rebase could not switch back to the branch correctly with this.

> ----------------------------------------------------------------
> [Approaching 'next']
> 
> * kh/commit (Sun Nov 11 17:36:52 2007 +0000) 12 commits
>  - builtin-commit: Add newline when showing which commit was created
>  - builtin-commit: resurrect behavior for multiple -m options
>  - builtin-commit --s: add a newline if the last line was not a S-o-b
>  - builtin-commit: fix --signoff
>  - git status: show relative paths when run in a subdirectory
>  - builtin-commit: fix author date with --amend --author=<author>
>  - builtin-commit: Refresh cache after adding files.
>  - builtin-commit: fix reflog message generation
>  - launch_editor(): read the file, even when EDITOR=:
>  - Port git commit to C.
>  - Export launch_editor() and make it accept ':' as a no-op editor.
>  - Add testcase for ammending and fixing author in git commit.
> 
> Dscho fixed a handful obvious glitches.  I am hoping that this
> series should be in "testable" shape now.  Will merge to "next"
> after giving it a final round of eyeballing.

FWIW I am running 'next'+builtin-commit+a couple of other patches I am 
brewing.  These issues are on my TODO list (most pressing first):

- commit --amend <file> erroneously commits other files that were
  git-add'ed
- under certain circumstances (my maildir update script) does not
  show newly created and deleted files anymore.
- do not rebuild the whole index when committing just one file,
  instead use the old index, and then adjust it to the HEAD.
- remove "launching editor, logfile (null)" message
- forward port 6d4bbebd35e3a6e8091d7188f1c4d49af7f054e3 to builtin-commit
- when a message is given and no editor should be launched, avoid
  lengthy runstatus calculation

Clarification for the "do not rebuild" thingie:  ATM it seems that there 
is a lengthy calculation going on, even if the index is clean and you only 
passed one single filename on the command line.

> * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
>  - refactor fetch's ref matching to use refname_match()
>  - push: use same rules as git-rev-parse to resolve refspecs
>  - add refname_match()
>  - push: support pushing HEAD to real branch name
> 
> This changes the semantics slightly but I think it is a move in
> the right direction.

We could add a "--matching" option and output a warning when it is not 
passed.  I would like this pretty soon, and would not be sad if it went 
into 'next' before this topic.

> * cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit
>  - Make builtin-tag.c use parse_options.
> 
> This changes the handling of multiple -m option without much
> good reason.  It should be a simple fix, once we know what we
> want.  I think the existing behaviour of refusing multiple -m
> is probably the most sane at this point.

I tend to agree.

> * sb/clean (Tue Nov 6 23:18:51 2007 -0600) 1 commit
>  - Make git-clean a builtin

Time is fleeting, so I could not yet look into the ambiguity problem where 
help was requested.

> ----------------------------------------------------------------
> [Others]
> 
> * jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit
>  - git-branch --with=commit
> 
> I did this just for my own fun.

As I already said, I'd like this, but renamed to --containing=.  In fact, 
I just scrapped a script of mine to do the same, in excited expectation of 
this feature.

Ciao,
Dscho

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

[Pierre Habouzit]

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

On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Sun, 11 Nov 2007, Junio C Hamano wrote:
> 
> > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
> >  + rebase: operate on a detached HEAD
> 
> Note: this might have a subtle bug when the last patch in the series 
> failed.  If I was not too tired this morning (which might well have been 
> the case), rebase could not switch back to the branch correctly with this.

  OOOH so this was what happened to me today then. I did a rebase, there
was a commit to skip, the last one, and I ended up on a detached head.
As I didn't had my coffee yet, I assumed this was my fault and did
something stupid. So after all it seems it wasn't the case then :)


-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

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

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

[Johannes Schindelin]

Hi,

On Mon, 12 Nov 2007, Pierre Habouzit wrote:

> On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin wrote:
> 
> > On Sun, 11 Nov 2007, Junio C Hamano wrote:
> > 
> > > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
> > >  + rebase: operate on a detached HEAD
> > 
> > Note: this might have a subtle bug when the last patch in the series 
> > failed.  If I was not too tired this morning (which might well have 
> > been the case), rebase could not switch back to the branch correctly 
> > with this.
> 
>   OOOH so this was what happened to me today then. I did a rebase, there 
> was a commit to skip, the last one, and I ended up on a detached head. 
> As I didn't had my coffee yet, I assumed this was my fault and did 
> something stupid. So after all it seems it wasn't the case then :)

Thanks for acknowleding, and sorry for the bug.

Will work on a fix,
Dscho

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

[Steffen Prohaska]

On Nov 12, 2007, at 1:21 PM, Johannes Schindelin wrote:

>> * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
>>  - refactor fetch's ref matching to use refname_match()
>>  - push: use same rules as git-rev-parse to resolve refspecs
>>  - add refname_match()
>>  - push: support pushing HEAD to real branch name
>>
>> This changes the semantics slightly but I think it is a move in
>> the right direction.
>
> We could add a "--matching" option and output a warning when it is not
> passed.  I would like this pretty soon, and would not be sad if it  
> went
> into 'next' before this topic.

Is this the road towards
1) "git push --matching" push matching branches.
2) "git push --current" push only current branch.
3) "git push" report error if the config does not contain a Push line.
    (after it reported a warning for a while).

I'd like to see this too. Unfortunately it's unlikely that I'll start
working on it before next weekend.

"--matching" would be a no-op at this time. Only a warning would be  
printed
if it is missing. Right?

	Steffen

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

[Pierre Habouzit]

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

On Mon, Nov 12, 2007 at 12:33:19PM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 12 Nov 2007, Pierre Habouzit wrote:
> 
> > On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin wrote:
> > 
> > > On Sun, 11 Nov 2007, Junio C Hamano wrote:
> > > 
> > > > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
> > > >  + rebase: operate on a detached HEAD
> > > 
> > > Note: this might have a subtle bug when the last patch in the series 
> > > failed.  If I was not too tired this morning (which might well have 
> > > been the case), rebase could not switch back to the branch correctly 
> > > with this.
> > 
> >   OOOH so this was what happened to me today then. I did a rebase, there 
> > was a commit to skip, the last one, and I ended up on a detached head. 
> > As I didn't had my coffee yet, I assumed this was my fault and did 
> > something stupid. So after all it seems it wasn't the case then :)
> 
> Thanks for acknowleding, and sorry for the bug.

  well, shit happens, I'm running next especially to spot those :)

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

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

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

[Johannes Schindelin]

Hi,

On Mon, 12 Nov 2007, Steffen Prohaska wrote:

> On Nov 12, 2007, at 1:21 PM, Johannes Schindelin wrote:
> 
> > > * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
> > > - refactor fetch's ref matching to use refname_match()
> > > - push: use same rules as git-rev-parse to resolve refspecs
> > > - add refname_match()
> > > - push: support pushing HEAD to real branch name
> > > 
> > > This changes the semantics slightly but I think it is a move in
> > > the right direction.
> > 
> > We could add a "--matching" option and output a warning when it is not
> > passed.  I would like this pretty soon, and would not be sad if it went
> > into 'next' before this topic.
> 
> Is this the road towards
> 1) "git push --matching" push matching branches.
> 2) "git push --current" push only current branch.
> 3) "git push" report error if the config does not contain a Push line.
>   (after it reported a warning for a while).

AFAIAC yes.  Maybe in two years (that's twice an eternity in git time 
scales):

4) make "git push --current" the default.

> I'd like to see this too. Unfortunately it's unlikely that I'll start 
> working on it before next weekend.
> 
> "--matching" would be a no-op at this time. Only a warning would be printed
> if it is missing. Right?

Right.

Ciao,
Dscho

What's cooking in git.git (topics)

[Junio C Hamano]

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

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

* lt/rev-list-interactive (Mon Nov 12 23:16:08 2007 -0800) 5 commits
 + Fix parent rewriting in --early-output
 + revision walker: mini clean-up
 + Enhance --early-output format
 + Add "--early-output" log flag for interactive GUI use
 + Simplify topo-sort logic

* lt/rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit
 + Fix rev-list when showing objects involving submodules

This fix from Dscho and Linus will need to be cherry-picked to
'maint' as well.

* ds/checkout-upper (Fri Nov 9 20:12:28 2007 +1100) 2 commits
 + git-checkout: Test for relative path use.
 + git-checkout: Support relative paths containing "..".

This will allow you to stay in a subdirectory and check out
paths in directories outside.  With Dscho's "git status" that
shows relatives paths (in kh/commit series), this would make
cutting and pasting paths you forgot to "git add" easier.

* ph/parseopt-sh (Mon Nov 12 12:07:40 2007 +0000) 17 commits
 + git-quiltimport.sh fix --patches handling
 + git-am: -i does not take a string parameter.
 + sh-setup: don't let eval output to be shell-expanded.
 + git-sh-setup: fix parseopt `eval` string underquoting
 + Give git-am back the ability to add Signed-off-by lines.
 + git-rev-parse --parseopt
 + scripts: Add placeholders for OPTIONS_SPEC
 + Migrate git-repack.sh to use git-rev-parse --parseopt
 + Migrate git-quiltimport.sh to use git-rev-parse --parseopt
 + Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-
   dashdash
 + Migrate git-instaweb.sh to use git-rev-parse --parseopt
 + Migrate git-merge.sh to use git-rev-parse --parseopt
 + Migrate git-am.sh to use git-rev-parse --parseopt
 + Migrate git-clone to use git-rev-parse --parseopt
 + Migrate git-clean.sh to use git-rev-parse --parseopt.
 + Update git-sh-setup(1) to allow transparent use of git-rev-parse -
   -parseopt
 + Add a parseopt mode to git-rev-parse to bring parse-options to
   shell scripts.

The rate of incoming fix with this topic has slowed down, which
is a good indication that this is getting ready.

----------------------------------------------------------------
[Actively cooking]

* jk/send-pack (Tue Nov 13 06:37:10 2007 -0500) 24 commits
 - send-pack: assign remote errors to each ref
 - send-pack: check ref->status before updating tracking refs
 - send-pack: track errors for each ref
 - Merge branch 'aw/mirror-push' into jk/send-pack
 - Merge branch 'ar/send-pack-remote-track' into jk/send-pack
 - Merge branch 'db/remote-builtin' into jk/send-pack
 + git-push: add documentation for the newly added --mirror mode
 + Add tests for git push'es mirror mode
 + Update the tracking references only if they were succesfully
   updated on remote
 + Add a test checking if send-pack updated local tracking branches
   correctly
 + git-push: plumb in --mirror mode
 + Teach send-pack a mirror mode
 + Merge master into aw/mirror-push
 + Merge branch 'jk/terse-push' into aw/mirror-push
 + send-pack: segfault fix on forced push
 + Reteach builtin-ls-remote to understand remotes
 + send-pack: require --verbose to show update of tracking refs
 + receive-pack: don't mention successful updates
 + more terse push output
 + Build in ls-remote
 + Build-in send-pack, with an API for other programs to call.
 + Use built-in send-pack.
 + Build-in peek-remote, using transport infrastructure.
 + Miscellaneous const changes and utilities

This three-patch series is built on top of four other topics and
is meant to fix issues in built-in send-pack.  I dropped
individial topics from Alex, Daniel, Andy and another from Jeff
that this series depends on.  IOW, they all will graduate to
"master" at the same time when this series proves to be stable.

Will wait for a few days to hear opinions from the list, and
then merge to "next" and start cooking.

* js/mingw-fallouts (Tue Nov 13 21:05:06 2007 +0100) 11 commits
 + Allow ETC_GITCONFIG to be a relative path.
 + Introduce git_etc_gitconfig() that encapsulates access of
   ETC_GITCONFIG.
 + Allow a relative builtin template directory.
 + Close files opened by lock_file() before unlinking.
 + builtin run_command: do not exit with -1.
 + Move #include <sys/select.h> and <sys/ioctl.h> to git-compat-
   util.h.
 + Use is_absolute_path() in sha1_file.c.
 + Skip t3902-quoted.sh if the file system does not support funny
   names.
 + t5302-pack-index: Skip tests of 64-bit offsets if necessary.
 + t7501-commit.sh: Not all seds understand option -i
 + t5300-pack-object.sh: Split the big verify-pack test into smaller
   parts.

A set of good general clean-up patches.

* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits
 + core.whitespace: add test for diff whitespace error highlighting
 + git-diff: complain about >=8 consecutive spaces in initial indent
 + War on whitespace: first, a bit of retreat.

Teaching "git apply --whitespace=[warn|strip]" to honor the same
configuration would be a good addition, but this could go to
'master' as is.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits
 + Remove hint to use "git help -a"
 + Make the list of common commands more exclusive

Some people on the list may find the exact list of commands
somewhat debatable.  We can fine-tune that in-tree ('pu' does
not count as "in-tree").

* ph/diffopts (Wed Nov 7 11:20:32 2007 +0100) 6 commits
 + Reorder diff_opt_parse options more logically per topics.
 + Make the diff_options bitfields be an unsigned with explicit
   masks.
 + Use OPT_BIT in builtin-pack-refs
 + Use OPT_BIT in builtin-for-each-ref
 + Use OPT_SET_INT and OPT_BIT in builtin-branch
 + parse-options new features.

Further code clean-ups.

----------------------------------------------------------------
[Approaching 'next']

* kh/commit (Wed Nov 14 10:31:53 2007 -0500) 13 commits
 - builtin-commit: Clean up an unused variable and a debug fprintf().
 - Call refresh_cache() when updating the user index for --only
   commits.
 - builtin-commit: Add newline when showing which commit was created
 - builtin-commit: resurrect behavior for multiple -m options
 - builtin-commit --s: add a newline if the last line was not a S-o-b
 - builtin-commit: fix --signoff
 - git status: show relative paths when run in a subdirectory
 - builtin-commit: Refresh cache after adding files.
 - builtin-commit: fix reflog message generation
 - launch_editor(): read the file, even when EDITOR=:
 - Port git commit to C.
 - Export launch_editor() and make it accept ':' as a no-op editor.
 - Add testcase for amending and fixing author in git commit.

Dscho fixed a few obvious glitches, but indicated he has a
handful more issues with the series.  I have been hoping that
this series should be in "testable" shape now.  Will need to
look at it again.

* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
 - refactor fetch's ref matching to use refname_match()
 - push: use same rules as git-rev-parse to resolve refspecs
 - add refname_match()
 - push: support pushing HEAD to real branch name

This changes the semantics slightly but I think it is a move in
the right direction.

* sb/clean (Mon Nov 12 21:13:05 2007 -0800) 2 commits
 - git-clean: Fix error message if clean.requireForce is not set.
 - Make git-clean a builtin

It has a subtle change in behaviour but it does not quite
qualify as a regression.  Will merge to "next" shortly.  We can
fix the corner case semantics in-tree.  I also adjusted the
error message to match the fix from Hannes on 'master'.

----------------------------------------------------------------
[Stalled]

* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
 - Do git reset --hard HEAD when using git rebase --skip

Some people on the list may find this debatable.  Opinions?

* cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit
 - Make builtin-tag.c use parse_options.

This changes the handling of multiple -m options without much
good reason.  It should be a simple fix, once we know what we
want.  I think the existing behaviour of refusing multiple -m
is probably the most sane at this point.

* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
 - Added diff hunk coloring to git-add--interactive
 - Let git-add--interactive read colors from .gitconfig
 - Added basic color support to git add --interactive

This series has improved quite a bit since the last round, but
another round was requested from the list.  Waiting for
refinements.

* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
 + Add missing inside_work_tree setting in setup_git_directory_gently

There was an additional patch, which still had issues Dscho
pointed out.  Waiting for refinements.

* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
 - Make git-svn rebase --dirty pass along --dirty to git-rebase.
 - Implement --dirty for git-rebase--interactive.
 - Introduce --dirty option to git-rebase, allowing you to start from
   a dirty state.

This seems to be optimized for the --dirty case too much.  I'd
prefer an implementation that make rebases without --dirty to
pay no penalty (if that is possible, otherwise "as little as
possible").

----------------------------------------------------------------
[Others]

* jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit
 - git-branch --with=commit

I did this just for my own fun.  --contains might be more
consistent with git-describe but --with is shorter to type ;-)

Besides, it needs documentation and tests.

* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
 - test format-patch -s: make sure MIME content type is shown as
   needed
 - format-patch -s: add MIME encoding header if signer's name
   requires so

This is to apply to 'maint' later; the equivalent fix is already
in 'master'.

* 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.

* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
 - handle renames using similarity engine
 - introduce generic similarity library
 - change hash table calling conventions

* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
 - revert/cherry-pick: start refactoring call to merge_recursive

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 - merge-nu: a new merge backend without using unpack_trees()
 - read_tree: take an explicit index structure
 - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

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

[Johannes Schindelin]

Hi,

On Wed, 14 Nov 2007, Junio C Hamano wrote:

> ----------------------------------------------------------------
> [Approaching 'next']
> 
> * kh/commit (Wed Nov 14 10:31:53 2007 -0500) 13 commits
>  - builtin-commit: Clean up an unused variable and a debug fprintf().
>  - Call refresh_cache() when updating the user index for --only
>    commits.
>  - builtin-commit: Add newline when showing which commit was created
>  - builtin-commit: resurrect behavior for multiple -m options
>  - builtin-commit --s: add a newline if the last line was not a S-o-b
>  - builtin-commit: fix --signoff
>  - git status: show relative paths when run in a subdirectory
>  - builtin-commit: Refresh cache after adding files.
>  - builtin-commit: fix reflog message generation
>  - launch_editor(): read the file, even when EDITOR=:
>  - Port git commit to C.
>  - Export launch_editor() and make it accept ':' as a no-op editor.
>  - Add testcase for amending and fixing author in git commit.
> 
> Dscho fixed a few obvious glitches, but indicated he has a
> handful more issues with the series.  I have been hoping that
> this series should be in "testable" shape now.  Will need to
> look at it again.

Well, it _is_ in testable shape.  My working setup is using builtin-commit 
since a week.  One glitch is serious: "git add a1 && git commit b1" will 
commit a1, too.

Another glitch is only mildly annoying to me (but I have not investigated 
in detail yet): when you commit new files in a subsubdirectory, no summary 
"created file" is printed for them.

Other than that, I am pretty happy with it, and the other issues I listed 
should be easily fixable.

> ----------------------------------------------------------------
> [Stalled]
> 
> * mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
>  - Do git reset --hard HEAD when using git rebase --skip
> 
> Some people on the list may find this debatable.  Opinions?

I run with it, and like it.  Sometimes when I rebase to 'next', a patch 
has subtle differences compared to the patch which was applied, and then I 
see in the conflict handling that it was applied already.  So I do the 
obvious: I --skip, and it Just Works.

But you _can_ mistakenly say "--skip".  That's why I pushed for the 
detached HEAD when rebasing.

> * cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit
>  - Make builtin-tag.c use parse_options.
> 
> This changes the handling of multiple -m options without much good 
> reason.  It should be a simple fix, once we know what we want.  I think 
> the existing behaviour of refusing multiple -m is probably the most sane 
> at this point.

Agree.

> * nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
>  + Add missing inside_work_tree setting in setup_git_directory_gently
> 
> There was an additional patch, which still had issues Dscho pointed out.  
> Waiting for refinements.

This might be something pretty painful, though, speaking from my own 
experience with the work-tree stuff.

> ----------------------------------------------------------------
> [Others]
> 
> * jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit
>  - git-branch --with=commit
> 
> I did this just for my own fun.  --contains might be more
> consistent with git-describe but --with is shorter to type ;-)

--with might confuse people who know that you can use "git branch" to 
create branches, but do not quite know how.

Besides, "--con" would be enough, and you can always add '-c'.  Or use 
completions.

Ciao,
Dscho

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

[Jeff King]

On Wed, Nov 14, 2007 at 04:18:25PM -0800, Junio C Hamano wrote:

> * jk/send-pack (Tue Nov 13 06:37:10 2007 -0500) 24 commits
> [...]
> This three-patch series is built on top of four other topics and
> is meant to fix issues in built-in send-pack.  I dropped
> individial topics from Alex, Daniel, Andy and another from Jeff
> that this series depends on.  IOW, they all will graduate to
> "master" at the same time when this series proves to be stable.

Thank you, it was getting confusing with so many people working in the
same area. :)

> Will wait for a few days to hear opinions from the list, and
> then merge to "next" and start cooking.

I am about to send out an improved patch set that incorporates some of
the test fixes from Alex, some new tests from me, and a few code
cleanups.

-Peff

What's cooking in git.git (topics)

[Junio C Hamano]

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

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

* jc/move-gitk (Sat Nov 17 10:51:16 2007 -0800) 1 commit
 - Move gitk to its own subdirectory

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

* sh/p4 (Thu Nov 15 10:38:45 2007 +0100) 1 commit
 + git-p4: Fix direct import from perforce after fetching changes
   through git from origin

* lt/rev-list-interactive (Mon Nov 12 23:16:08 2007 -0800) 5 commits
 + Fix parent rewriting in --early-output
 + revision walker: mini clean-up
 + Enhance --early-output format
 + Add "--early-output" log flag for interactive GUI use
 + Simplify topo-sort logic

* lt/rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit
 + Fix rev-list when showing objects involving submodules

This fix from Dscho and Linus will need to be cherry-picked to
'maint' as well.

* ds/checkout-upper (Fri Nov 9 20:12:28 2007 +1100) 2 commits
 + git-checkout: Test for relative path use.
 + git-checkout: Support relative paths containing "..".

This will allow you to stay in a subdirectory and check out
paths in directories outside.  With Dscho's "git status" that
shows relatives paths (in kh/commit series), this would make
cutting and pasting paths you forgot to "git add" easier.

* ph/parseopt-sh (Mon Nov 12 12:07:40 2007 +0000) 17 commits
 + git-quiltimport.sh fix --patches handling
 + git-am: -i does not take a string parameter.
 + sh-setup: don't let eval output to be shell-expanded.
 + git-sh-setup: fix parseopt `eval` string underquoting
 + Give git-am back the ability to add Signed-off-by lines.
 + git-rev-parse --parseopt
 + scripts: Add placeholders for OPTIONS_SPEC
 + Migrate git-repack.sh to use git-rev-parse --parseopt
 + Migrate git-quiltimport.sh to use git-rev-parse --parseopt
 + Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-
   dashdash
 + Migrate git-instaweb.sh to use git-rev-parse --parseopt
 + Migrate git-merge.sh to use git-rev-parse --parseopt
 + Migrate git-am.sh to use git-rev-parse --parseopt
 + Migrate git-clone to use git-rev-parse --parseopt
 + Migrate git-clean.sh to use git-rev-parse --parseopt.
 + Update git-sh-setup(1) to allow transparent use of git-rev-parse -
   -parseopt
 + Add a parseopt mode to git-rev-parse to bring parse-options to
   shell scripts.

The rate of incoming fix with this topic has slowed down, which
is a good indication that this is getting ready.

* js/mingw-fallouts (Thu Nov 15 12:24:17 2007 -0500) 12 commits
 + rehabilitate some t5302 tests on 32-bit off_t machines
 + Allow ETC_GITCONFIG to be a relative path.
 + Introduce git_etc_gitconfig() that encapsulates access of
   ETC_GITCONFIG.
 + Allow a relative builtin template directory.
 + Close files opened by lock_file() before unlinking.
 + builtin run_command: do not exit with -1.
 + Move #include <sys/select.h> and <sys/ioctl.h> to git-compat-
   util.h.
 + Use is_absolute_path() in sha1_file.c.
 + Skip t3902-quoted.sh if the file system does not support funny
   names.
 + t5302-pack-index: Skip tests of 64-bit offsets if necessary.
 + t7501-commit.sh: Not all seds understand option -i
 + t5300-pack-object.sh: Split the big verify-pack test into smaller
   parts.

A set of good general clean-up patches.

* ph/diffopts (Wed Nov 7 11:20:32 2007 +0100) 6 commits
 + Reorder diff_opt_parse options more logically per topics.
 + Make the diff_options bitfields be an unsigned with explicit
   masks.
 + Use OPT_BIT in builtin-pack-refs
 + Use OPT_BIT in builtin-for-each-ref
 + Use OPT_SET_INT and OPT_BIT in builtin-branch
 + parse-options new features.

Further code clean-ups.

* cc/bisect (Sat Nov 17 14:35:25 2007 +0100) 5 commits
 + Bisect visualize: use "for-each-ref" to list all good refs.
 + git-bisect: modernize branch shuffling hack
 + git-bisect: use update-ref to mark good/bad commits
 + git-bisect: war on "sed"
 + Bisect reset: remove bisect refs that may have been packed.

----------------------------------------------------------------
[Actively cooking]

* jk/send-pack (Sat Nov 17 07:56:03 2007 -0500) 24 commits
 + send-pack: assign remote errors to each ref
 + send-pack: check ref->status before updating tracking refs
 + send-pack: track errors for each ref
 + Merge branch 'aw/mirror-push' into jk/send-pack
 + Merge branch 'ar/send-pack-remote-track' into jk/send-pack
 + Merge branch 'db/remote-builtin' into jk/send-pack
 + git-push: add documentation for the newly added --mirror mode
 + Add tests for git push'es mirror mode
 + Update the tracking references only if they were succesfully
   updated on remote
 + Add a test checking if send-pack updated local tracking branches
   correctly
 + git-push: plumb in --mirror mode
 + Teach send-pack a mirror mode
 + Merge master into aw/mirror-push
 + Merge branch 'jk/terse-push' into aw/mirror-push
 + send-pack: segfault fix on forced push
 + Reteach builtin-ls-remote to understand remotes
 + send-pack: require --verbose to show update of tracking refs
 + receive-pack: don't mention successful updates
 + more terse push output
 + Build in ls-remote
 + Build-in send-pack, with an API for other programs to call.
 + Use built-in send-pack.
 + Build-in peek-remote, using transport infrastructure.
 + Miscellaneous const changes and utilities

Looking good.

* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits
 + core.whitespace: add test for diff whitespace error highlighting
 + git-diff: complain about >=8 consecutive spaces in initial indent
 + War on whitespace: first, a bit of retreat.

Teaching "git apply --whitespace=[warn|strip]" to honor the same
configuration would be a good addition, but this could go to
'master' as is.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits
 + Remove hint to use "git help -a"
 + Make the list of common commands more exclusive

Some people on the list may find the exact list of commands
somewhat debatable.  We can fine-tune that in-tree ('pu' does
not count as "in-tree").

----------------------------------------------------------------
[Approaching 'next']

* kh/commit (Sat Nov 17 00:46:33 2007 -0800) 16 commits
 - PARK: cruft next-index clean-up
 - Replace "runstatus" with "status" in the tests
 - t7501-commit: Add test for git commit <file> with dirty index.
 - builtin-commit: Clean up an unused variable and a debug fprintf().
 - Call refresh_cache() when updating the user index for --only
   commits.
 - builtin-commit: Add newline when showing which commit was created
 - builtin-commit: resurrect behavior for multiple -m options
 - builtin-commit --s: add a newline if the last line was not a S-o-b
 - builtin-commit: fix --signoff
 - git status: show relative paths when run in a subdirectory
 - builtin-commit: Refresh cache after adding files.
 - builtin-commit: fix reflog message generation
 - launch_editor(): read the file, even when EDITOR=:
 - Port git commit to C.
 - Export launch_editor() and make it accept ':' as a no-op editor.
 - Add testcase for amending and fixing author in git commit.

Dscho fixed a few obvious glitches, but indicated he has a
handful more issues with the series.  Partial commit is
seriously broken.

* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
 - refactor fetch's ref matching to use refname_match()
 - push: use same rules as git-rev-parse to resolve refspecs
 - add refname_match()
 - push: support pushing HEAD to real branch name

This changes the semantics slightly but I think it is a move in
the right direction.

* sb/clean (Wed Nov 14 23:00:54 2007 -0600) 3 commits
 - Teach git clean to use setup_standard_excludes()
 - git-clean: Fix error message if clean.requireForce is not set.
 - Make git-clean a builtin

It has a subtle change in behaviour but it does not quite
qualify as a regression.  Will merge to "next" shortly.  We can
fix the corner case semantics in-tree.  I also adjusted the
error message to match the fix from Hannes on 'master'.

----------------------------------------------------------------
[Stalled]

* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
 - Do git reset --hard HEAD when using git rebase --skip

Some people on the list may find this debatable.  Opinions?

* cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit
 - Make builtin-tag.c use parse_options.

This changes the handling of multiple -m options without much
good reason.  It should be a simple fix, once we know what we
want.  I think the existing behaviour of refusing multiple -m
is probably the most sane at this point.

* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
 - Added diff hunk coloring to git-add--interactive
 - Let git-add--interactive read colors from .gitconfig
 - Added basic color support to git add --interactive

This series has improved quite a bit since the last round, but
another round was requested from the list.  Waiting for
refinements.

* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
 + Add missing inside_work_tree setting in setup_git_directory_gently

There was an additional patch, which still had issues Dscho
pointed out.  Waiting for refinements.

* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
 - Make git-svn rebase --dirty pass along --dirty to git-rebase.
 - Implement --dirty for git-rebase--interactive.
 - Introduce --dirty option to git-rebase, allowing you to start from
   a dirty state.

This seems to be optimized for the --dirty case too much.  I'd
prefer an implementation that make rebases without --dirty to
pay no penalty (if that is possible, otherwise "as little as
possible").

----------------------------------------------------------------
[Others]

* jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit
 - git-branch --with=commit

I did this just for my own fun.  --contains might be more
consistent with git-describe but --with is shorter to type ;-)

Besides, it needs documentation and tests.

* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
 - test format-patch -s: make sure MIME content type is shown as
   needed
 - format-patch -s: add MIME encoding header if signer's name
   requires so

This is to apply to 'maint' later; the equivalent fix is already
in 'master'.

* lt/maint-rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit
 - Fix rev-list when showing objects involving submodules

This is to apply to 'maint' later; the equivalent fix is already
in 'next' and will be merged to 'master' soon.

* 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.

* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
 - handle renames using similarity engine
 - introduce generic similarity library
 - change hash table calling conventions

* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
 - revert/cherry-pick: start refactoring call to merge_recursive

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 - merge-nu: a new merge backend without using unpack_trees()
 - read_tree: take an explicit index structure
 - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

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

[Alex Riesen]

Junio C Hamano, Sat, Nov 17, 2007 21:51:04 +0100:
> * mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
>  - Do git reset --hard HEAD when using git rebase --skip
> 
> Some people on the list may find this debatable.  Opinions?

I like it (and didn't like the previous behaviour). Anyway, it is not
obvious what to do when --skip refuses to continue rebase because of
dirty index.

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

[Junio C Hamano]

Alex Riesen <raa.lkml@gmail.com> writes:

> Junio C Hamano, Sat, Nov 17, 2007 21:51:04 +0100:
>> * mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
>>  - Do git reset --hard HEAD when using git rebase --skip
>> 
>> Some people on the list may find this debatable.  Opinions?
>
> I like it (and didn't like the previous behaviour). Anyway, it is not
> obvious what to do when --skip refuses to continue rebase because of
> dirty index.

True.  Let's have it in 'next' then.

What's cooking in git.git (topics)

[Junio C Hamano]

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

Just in case anybody is wondering, this message is updated with
the help with a new script UWC in 'todo' branch these days (I
have 'todo' checked out in Meta/ directory, so the script is
called Meta/UWC and uses Meta/git-topic.perl script etc.)

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

* jc/move-gitk (Sat Nov 17 10:51:16 2007 -0800) 1 commit
 + Move gitk to its own subdirectory

I have a phoney Makefile under the subdirectory for gitk, but
hopefully with the next pull from Paulus I can replace it with
the real thing, along with the i18n stuff.

* cc/bisect (Tue Nov 20 06:39:53 2007 +0100) 7 commits
 + Bisect reset: do nothing when not bisecting.
 + Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.
 + Bisect visualize: use "for-each-ref" to list all good refs.
 + git-bisect: modernize branch shuffling hack
 + git-bisect: use update-ref to mark good/bad commits
 + git-bisect: war on "sed"
 + Bisect reset: remove bisect refs that may have been packed.

Will merge by the weekend (if I can find time, that is).

* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
 + Do git reset --hard HEAD when using git rebase --skip

After seeing a conflicted rebase, you may decide to skip that
patch but then you would need "git reset --hard" before saying
"git rebase --skip".  This teaches "git rebase --skip" to
automatically discard the conflicted rebase for you.

Will merge by the weekend.

* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits
 + Remove hint to use "git help -a"
 + Make the list of common commands more exclusive

Some people on the list may find the exact list of commands
somewhat debatable.  We can fine-tune that in-tree ('pu' does
not count as "in-tree").

* js/mingw-fallouts (Sat Nov 17 23:09:28 2007 +0100) 13 commits
 + fetch-pack: Prepare for a side-band demultiplexer in a thread.
 + rehabilitate some t5302 tests on 32-bit off_t machines
 + Allow ETC_GITCONFIG to be a relative path.
 + Introduce git_etc_gitconfig() that encapsulates access of
   ETC_GITCONFIG.
 + Allow a relative builtin template directory.
 + Close files opened by lock_file() before unlinking.
 + builtin run_command: do not exit with -1.
 + Move #include <sys/select.h> and <sys/ioctl.h> to git-compat-
   util.h.
 + Use is_absolute_path() in sha1_file.c.
 + Skip t3902-quoted.sh if the file system does not support funny
   names.
 + t5302-pack-index: Skip tests of 64-bit offsets if necessary.
 + t7501-commit.sh: Not all seds understand option -i
 + t5300-pack-object.sh: Split the big verify-pack test into smaller
   parts.

A set of good general clean-up patches.

----------------------------------------------------------------
[Actively cooking]

* jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits
 - send-pack: cluster ref status reporting
 + send-pack: fix "everything up-to-date" message
 + send-pack: tighten remote error reporting
 + make "find_ref_by_name" a public function
 + Fix warning about bitfield in struct ref
 + send-pack: assign remote errors to each ref
 + send-pack: check ref->status before updating tracking refs
 + send-pack: track errors for each ref
 + Merge branch 'aw/mirror-push' into jk/send-pack
 + Merge branch 'ar/send-pack-remote-track' into jk/send-pack
 + Merge branch 'db/remote-builtin' into jk/send-pack
 + git-push: add documentation for the newly added --mirror mode
 + Add tests for git push'es mirror mode
 + Update the tracking references only if they were succesfully
   updated on remote
 + Add a test checking if send-pack updated local tracking branches
   correctly
 + git-push: plumb in --mirror mode
 + Teach send-pack a mirror mode
 + Merge master into aw/mirror-push
 + Merge branch 'jk/terse-push' into aw/mirror-push
 + send-pack: segfault fix on forced push
 + Reteach builtin-ls-remote to understand remotes
 + send-pack: require --verbose to show update of tracking refs
 + receive-pack: don't mention successful updates
 + more terse push output
 + Build in ls-remote
 + Build-in send-pack, with an API for other programs to call.
 + Use built-in send-pack.
 + Build-in peek-remote, using transport infrastructure.
 + Miscellaneous const changes and utilities

Various improvements on status reporting and error handling by
send-pack, and implementation of "mirror" pushing.

* sb/clean (Wed Nov 14 23:00:54 2007 -0600) 3 commits
 + Teach git clean to use setup_standard_excludes()
 + git-clean: Fix error message if clean.requireForce is not set.
 + Make git-clean a builtin

It has a subtle change in behaviour but it does not quite
qualify as a regression.  Will merge to "next" shortly.  We can
fix the corner case semantics in-tree.  I also adjusted the
error message to match the fix from Hannes on 'master'.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

----------------------------------------------------------------
[Approaching 'next']

* kh/commit (Sun Nov 18 01:52:55 2007 -0800) 21 commits
 - builtin-commit: fix partial-commit support
 - Fix add_files_to_cache() to take pathspec, not user specified list
   of files
 - Export three helper functions from ls-files
 - builtin-commit: run commit-msg hook with correct message file
 - builtin-commit: do not color status output shown in the message
   template
 - file_exists(): dangling symlinks do exist
 - Replace "runstatus" with "status" in the tests
 - t7501-commit: Add test for git commit <file> with dirty index.
 - builtin-commit: Clean up an unused variable and a debug fprintf().
 - Call refresh_cache() when updating the user index for --only
   commits.
 - builtin-commit: Add newline when showing which commit was created
 - builtin-commit: resurrect behavior for multiple -m options
 - builtin-commit --s: add a newline if the last line was not a S-o-b
 - builtin-commit: fix --signoff
 - git status: show relative paths when run in a subdirectory
 - builtin-commit: Refresh cache after adding files.
 - builtin-commit: fix reflog message generation
 - launch_editor(): read the file, even when EDITOR=:
 - Port git commit to C.
 - Export launch_editor() and make it accept ':' as a no-op editor.
 - Add testcase for amending and fixing author in git commit.

There are still a few regressions that keep this series out of
'next', including the lossage of "-v" (final diff review).

By the way, I am meaning to squash the part that introduces and
then fixes builtin-commit.c into a smaller number of commits for
future readability and bisectability (currently the series is
not bisectable).

----------------------------------------------------------------
[Stalled]

* sp/refspec-match (Sun Nov 18 17:13:08 2007 +0100) 6 commits
 - push: Add '--current', which pushes only the current branch
 - push: Add '--matching' option and print warning if it should be
   used
 - refactor fetch's ref matching to use refname_match()
 - push: use same rules as git-rev-parse to resolve refspecs
 - add refname_match()
 - push: support pushing HEAD to real branch name

("Stalled" is my fault, not the author's) This changes the
semantics slightly but I think it is a move in the right
direction.  Perhaps merge the early parts to 'next'; I am not
entirely happy with the updated --current patch which does not
appear in this queue.

* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits
 + core.whitespace: add test for diff whitespace error highlighting
 + git-diff: complain about >=8 consecutive spaces in initial indent
 + War on whitespace: first, a bit of retreat.

Teaching "git apply --whitespace=[warn|strip]" to honor the same
configuration would be a good addition, but this could go to
'master' as is.

* cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit
 - Make builtin-tag.c use parse_options.

This changes the handling of multiple -m options without much
good reason.  It should be a simple fix, once we know what we
want.  I think the existing behaviour of refusing multiple -m
is probably the most sane at this point.

* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
 - Added diff hunk coloring to git-add--interactive
 - Let git-add--interactive read colors from .gitconfig
 - Added basic color support to git add --interactive

This series has improved quite a bit since the last round, but
another round was requested from the list.  Waiting for
refinements.

* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
 + Add missing inside_work_tree setting in setup_git_directory_gently

There was an additional patch, which still had issues Dscho
pointed out.  Waiting for refinements.

* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
 - Make git-svn rebase --dirty pass along --dirty to git-rebase.
 - Implement --dirty for git-rebase--interactive.
 - Introduce --dirty option to git-rebase, allowing you to start from
   a dirty state.

This seems to be optimized for the --dirty case too much.  I'd
prefer an implementation that make rebases without --dirty to
pay no penalty (if that is possible, otherwise "as little as
possible").

----------------------------------------------------------------
[Others]

* jc/branch-contains (Sun Nov 18 22:22:00 2007 -0800) 3 commits
 - git-branch --contains: doc and test
 - git-branch --contains=commit
 - parse-options: Allow to hide options from the default usage.

Contains Pierre's "hidable options with --help-all" patch.  I
think this is ready to be in 'next'.

* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
 - test format-patch -s: make sure MIME content type is shown as
   needed
 - format-patch -s: add MIME encoding header if signer's name
   requires so

This is to apply to 'maint' later; the equivalent fix is already
in 'master'.

* lt/maint-rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit
 - Fix rev-list when showing objects involving submodules

This is to apply to 'maint' later; the equivalent fix is already
in 'next' and will be merged to 'master' soon.

* 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.

* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
 - handle renames using similarity engine
 - introduce generic similarity library
 - change hash table calling conventions

* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
 - revert/cherry-pick: start refactoring call to merge_recursive

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 - merge-nu: a new merge backend without using unpack_trees()
 - read_tree: take an explicit index structure
 - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

The second one could probably be used to replace the use of
path-list in the tip commit on the kh/commit series.

What's cooking in git.git (topics)

[Junio C Hamano]

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

I ran out of time while re-reviewing the stalled topics to
decide what to do with them, and many of them are left out of
'pu' branch for tonight, even though I haven't dropped them
entirely from my repository yet.

A funny thing is, 'pu' passes most of the testsuite thanks to
this temporary droppage.  The tip of 'pu' hasn't passed the
tests for quite some time.

New tests for svn-info seem to be failing in my private
repository at k.org; I haven't tried to look into it yet.

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

* jc/move-gitk (Sat Nov 17 10:51:16 2007 -0800) 1 commit
 + Move gitk to its own subdirectory

I have a phoney Makefile under the subdirectory for gitk, but
hopefully with the next pull from Paulus I can replace it with
the real thing, along with the i18n stuff.

* cc/bisect (Tue Nov 20 06:39:53 2007 +0100) 7 commits
 + Bisect reset: do nothing when not bisecting.
 + Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.
 + Bisect visualize: use "for-each-ref" to list all good refs.
 + git-bisect: modernize branch shuffling hack
 + git-bisect: use update-ref to mark good/bad commits
 + git-bisect: war on "sed"
 + Bisect reset: remove bisect refs that may have been packed.

Will merge by the weekend (if I can find time, that is).

* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
 + Do git reset --hard HEAD when using git rebase --skip

After seeing a conflicted rebase, you may decide to skip that
patch but then you would need "git reset --hard" before saying
"git rebase --skip".  This teaches "git rebase --skip" to
automatically discard the conflicted rebase for you.

Will merge by the weekend.

* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits
 + Remove hint to use "git help -a"
 + Make the list of common commands more exclusive

Some people on the list may find the exact list of commands
somewhat debatable.  We can fine-tune that in-tree ('pu' does
not count as "in-tree").

* js/mingw-fallouts (Sat Nov 17 23:09:28 2007 +0100) 13 commits
 + fetch-pack: Prepare for a side-band demultiplexer in a thread.
 + rehabilitate some t5302 tests on 32-bit off_t machines
 + Allow ETC_GITCONFIG to be a relative path.
 + Introduce git_etc_gitconfig() that encapsulates access of
   ETC_GITCONFIG.
 + Allow a relative builtin template directory.
 + Close files opened by lock_file() before unlinking.
 + builtin run_command: do not exit with -1.
 + Move #include <sys/select.h> and <sys/ioctl.h> to git-compat-
   util.h.
 + Use is_absolute_path() in sha1_file.c.
 + Skip t3902-quoted.sh if the file system does not support funny
   names.
 + t5302-pack-index: Skip tests of 64-bit offsets if necessary.
 + t7501-commit.sh: Not all seds understand option -i
 + t5300-pack-object.sh: Split the big verify-pack test into smaller
   parts.

A set of good general clean-up patches.

* sb/clean (Wed Nov 14 23:00:54 2007 -0600) 3 commits
 + Teach git clean to use setup_standard_excludes()
 + git-clean: Fix error message if clean.requireForce is not set.
 + Make git-clean a builtin

* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits
 + core.whitespace: add test for diff whitespace error highlighting
 + git-diff: complain about >=8 consecutive spaces in initial indent
 + War on whitespace: first, a bit of retreat.

Teaching "git apply --whitespace=[warn|strip]" to honor the same
configuration would be a good addition, but this could go to
'master' as is.

* jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits
 + send-pack: cluster ref status reporting
 + send-pack: fix "everything up-to-date" message
 + send-pack: tighten remote error reporting
 + make "find_ref_by_name" a public function
 + Fix warning about bitfield in struct ref
 + send-pack: assign remote errors to each ref
 + send-pack: check ref->status before updating tracking refs
 + send-pack: track errors for each ref
 + Merge branch 'aw/mirror-push' into jk/send-pack
 + Merge branch 'ar/send-pack-remote-track' into jk/send-pack
 + Merge branch 'db/remote-builtin' into jk/send-pack
 + git-push: add documentation for the newly added --mirror mode
 + Add tests for git push'es mirror mode
 + Update the tracking references only if they were succesfully
   updated on remote
 + Add a test checking if send-pack updated local tracking branches
   correctly
 + git-push: plumb in --mirror mode
 + Teach send-pack a mirror mode
 + Merge master into aw/mirror-push
 + Merge branch 'jk/terse-push' into aw/mirror-push
 + send-pack: segfault fix on forced push
 + Reteach builtin-ls-remote to understand remotes
 + send-pack: require --verbose to show update of tracking refs
 + receive-pack: don't mention successful updates
 + more terse push output
 + Build in ls-remote
 + Build-in send-pack, with an API for other programs to call.
 + Use built-in send-pack.
 + Build-in peek-remote, using transport infrastructure.
 + Miscellaneous const changes and utilities

Various improvements on status reporting and error handling by
send-pack, and implementation of "mirror" pushing.

----------------------------------------------------------------
[Actively cooking]

* kh/commit (Thu Nov 22 16:21:49 2007 -0800) 23 commits
 + Add a few more tests for git-commit
 + builtin-commit: Include the diff in the commit message when
   verbose.
 + builtin-commit: fix partial-commit support
 + Fix add_files_to_cache() to take pathspec, not user specified list
   of files
 + Export three helper functions from ls-files
 + builtin-commit: run commit-msg hook with correct message file
 + builtin-commit: do not color status output shown in the message
   template
 + file_exists(): dangling symlinks do exist
 + Replace "runstatus" with "status" in the tests
 + t7501-commit: Add test for git commit <file> with dirty index.
 + builtin-commit: Clean up an unused variable and a debug fprintf().
 + Call refresh_cache() when updating the user index for --only
   commits.
 + builtin-commit: Add newline when showing which commit was created
 + builtin-commit: resurrect behavior for multiple -m options
 + builtin-commit --s: add a newline if the last line was not a S-o-b
 + builtin-commit: fix --signoff
 + git status: show relative paths when run in a subdirectory
 + builtin-commit: Refresh cache after adding files.
 + builtin-commit: fix reflog message generation
 + launch_editor(): read the file, even when EDITOR=:
 + Port git commit to C.
 + Export launch_editor() and make it accept ':' as a no-op editor.
 + Add testcase for amending and fixing author in git commit.

Although I found the fd shuffling somewhat distasteful, overall
the series seems reasonably stable so it is in 'next'.

* cr/tag-options (Thu Nov 22 23:16:51 2007 -0800) 2 commits
 + builtin-tag: accept and process multiple -m just like git-commit
 + Make builtin-tag.c use parse_options.

The handling of multiple -m options are made consistent with
what git-commit does; i.e. they are concatenated as separate
paragraphs.

* wc/add-i (Thu Nov 22 01:47:13 2007 -0800) 3 commits
 + git-add -i: allow multiple selection in patch subcommand
 + Add path-limiting to git-add--interactive
 + Teach builtin-add to pass multiple paths to git-add--interactive

This still does not have the "directly invoke 'patch' subcommand
and exit after the interaction without coming back to the menu"
part.

* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
 + refactor fetch's ref matching to use refname_match()
 + push: use same rules as git-rev-parse to resolve refspecs
 + add refname_match()
 + push: support pushing HEAD to real branch name

These are the uncontroversial bits from the series.

The "--matching" patch was dropped; I do not know what will
happen to the "--current" thing.  I'd prefer to postpone the
discussion until jk/send-pack topic stabilizes and graduates.

* jc/branch-contains (Sun Nov 18 22:22:00 2007 -0800) 3 commits
 + git-branch --contains: doc and test
 + git-branch --contains=commit
 + parse-options: Allow to hide options from the default usage.

Contains Pierre's "hidable options with --help-all" patch.

----------------------------------------------------------------
[Approaching 'next']

----------------------------------------------------------------
[Others]

* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
 - test format-patch -s: make sure MIME content type is shown as
   needed
 - format-patch -s: add MIME encoding header if signer's name
   requires so

This is to apply to 'maint' later; the equivalent fix is already
in 'master'.

* lt/maint-rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit
 - Fix rev-list when showing objects involving submodules

This is to apply to 'maint' later; the equivalent fix is already
in 'next' and will be merged to 'master' soon.

----------------------------------------------------------------
[Stalled]

* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
 - revert/cherry-pick: start refactoring call to merge_recursive

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 - merge-nu: a new merge backend without using unpack_trees()
 - read_tree: take an explicit index structure
 - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

The second one could probably be used to replace the use of
path-list in the tip commit on the kh/commit series.

* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
 - Added diff hunk coloring to git-add--interactive
 - Let git-add--interactive read colors from .gitconfig
 - Added basic color support to git add --interactive

There were many good suggestions by Jeff to the updated series;
hopefully we can replace these three with it.

* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
 + Add missing inside_work_tree setting in setup_git_directory_gently

There was an additional patch, which still had issues Dscho
pointed out.  Waiting for refinements.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* 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.

* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
 . Make git-svn rebase --dirty pass along --dirty to git-rebase.
 . Implement --dirty for git-rebase--interactive.
 . Introduce --dirty option to git-rebase, allowing you to start from
   a dirty state.

This seems to be optimized for the --dirty case too much.  I'd
prefer an implementation that make rebases without --dirty to
pay no penalty (if that is possible, otherwise "as little as
possible").

* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
 . handle renames using similarity engine
 . introduce generic similarity library
 . change hash table calling conventions

This was an attempt to use different strategy to speed up
similarity computation, but does not work quite well as is.

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

[Jeff King]

On Fri, Nov 23, 2007 at 12:48:25AM -0800, Junio C Hamano wrote:

> * jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits
>  + send-pack: cluster ref status reporting

Did we decide that printing the "maybe you need to pull" hint is not
worth doing?

> * jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
>  . handle renames using similarity engine
>  . introduce generic similarity library
>  . change hash table calling conventions
> 
> This was an attempt to use different strategy to speed up
> similarity computation, but does not work quite well as is.

This is still on my long-term todo list, but obviously needs quite a bit
of cleanup. Eventually I will get around to it.

I wonder if it is worth dropping from 'pu'. It doesn't pass the tests,
making it harder to play with other pu topics, and it is not being
actively worked on or tested by anyone.

-Peff

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

[Johannes Schindelin]

Hi,

On Fri, 23 Nov 2007, Jeff King wrote:

> On Fri, Nov 23, 2007 at 12:48:25AM -0800, Junio C Hamano wrote:
> 
> > * jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits
> >  + send-pack: cluster ref status reporting
> 
> Did we decide that printing the "maybe you need to pull" hint is not 
> worth doing?

Maybe we could change the (non-fast forward) message into (non-fast 
forward; need to pull?).

Just an idea.

Ciao,
Dscho

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

[Jeff King]

On Fri, Nov 23, 2007 at 01:23:44PM +0000, Johannes Schindelin wrote:

> Maybe we could change the (non-fast forward) message into (non-fast 
> forward; need to pull?).

Not unreasonable, although I think our line length is getting a bit
long.  Rejected refs would look something like (actually they say
"[rejected]" but the text is column-aligned with the X's):

 ! XXXXXXX...XXXXXXX ref_name -> ref_name (non-fast forward; need to pull?)

There's 58 characters of text not including the two ref_names, leaving
about 11 characters for each ref name. The name of this topic,
jk/send-pack, would overflow an 80-character terminal:

 ! [rejected]        jk/send-pack -> jk/send-pack (non-fast forward; need to pull?)

-Peff

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

[Nicolas Pitre]

On Sat, 24 Nov 2007, Jeff King wrote:

> On Fri, Nov 23, 2007 at 01:23:44PM +0000, Johannes Schindelin wrote:
> 
> > Maybe we could change the (non-fast forward) message into (non-fast 
> > forward; need to pull?).
> 
> Not unreasonable, although I think our line length is getting a bit
> long.  Rejected refs would look something like (actually they say
> "[rejected]" but the text is column-aligned with the X's):
> 
>  ! XXXXXXX...XXXXXXX ref_name -> ref_name (non-fast forward; need to pull?)
> 
> There's 58 characters of text not including the two ref_names, leaving
> about 11 characters for each ref name. The name of this topic,
> jk/send-pack, would overflow an 80-character terminal:
> 
>  ! [rejected]        jk/send-pack -> jk/send-pack (non-fast forward; need to pull?)

I personally think this is a bad idea, especially after all the efforts 
that has been put into making those lines not to wrap.

Yet the message itself is not totally accurate either, since "need to 
pull" might have to be "need to force" in some cases.

I think that would be better to append a single line at the end of the 
display with a clue about what "non fast forward" means.


Nicolas

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

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> Yet the message itself is not totally accurate either, since "need to 
> pull" might have to be "need to force" in some cases.

We used to say only "this is not a fast-forward", and did not
mention "what next".  Later we added "maybe you want to pull
first?" without making it clear enough that the reason why the
suggestion may or may not apply to the user is because it
depended largely on the user's workflow.  It probably was a
mistake and not mentioning "what next" at all might have been
less confusion-prone.  I dunno.

> I think that would be better to append a single line at the end of the 
> display with a clue about what "non fast forward" means.

I'd agree, but having said all the above, I am not entirely
happy not mentioning "what next" at all.

There are two equally valid "what next" after your push is
rejected due to non-fast-forwardness.

 (1) You know what you are doing.

   - You are pushing into a "back-up" repository, not for a
     public consumption.

   - You are pushing a branch that are advertised to rebase and
     rewind into your own publishing repository, and other
     people interacting with the branch know about this.

   - You pushed a wrong head there very recently and are fairly
     confident that nobody has seen that mistake, and pushing
     the correct one to fix the mistake.

     In these cases, forcing the push is the right solution
     (except that the third one is dubious, because it depends
     heavily on the "fairly confident" part).

 (2) You were building on a stale head, and were indeed about to
     lose others' changes with a non-fast-forward push.

     The right solution is to rebuild what you push so that you
     will not lose others' changes.  Rebuilding can take two
     different forms:

   - You may want to git-fetch and rebase your work on top of
     others'.

   - You may want to git-pull, which will merge your work with
     what others did.

But of couse the above is way too long as the help text.

Does the user-manual talk about this?  It has a really good
description of how to notice when a merge is not resolved
automatically and what to do next ("Resolving a merge" section).
Perhaps we can enhance "Pushing changes to a public repository"
section to include "what if the push is refused" information.

What's cooking in git.git (topics)

[Junio C Hamano]

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

----------------------------------------------------------------
[Graduated to 'master']

* cc/bisect (Tue Nov 20 06:39:53 2007 +0100) 7 commits
* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
* js/mingw-fallouts (Sat Nov 17 23:09:28 2007 +0100) 13 commits
* sb/clean (Wed Nov 14 23:00:54 2007 -0600) 3 commits
* jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits

----------------------------------------------------------------
[Graduated to 'maint']

* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
* lt/maint-rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit

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

* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit
 - Start preparing the API documents.

This currently consists of mostly stubs, although I wrote about a few
topics as examples.

* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
 - Making ce_path_match() more useful by accepting globs

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

* jc/move-gitk (Sat Nov 17 10:51:16 2007 -0800) 1 commit
 + Move gitk to its own subdirectory

I have a phoney Makefile under the subdirectory for gitk, but
hopefully with the next pull from Paulus I can replace it with
the real thing, along with the i18n stuff.

* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits
 + Remove hint to use "git help -a"
 + Make the list of common commands more exclusive

Some people on the list may find the exact list of commands
somewhat debatable.  We can fine-tune that in-tree ('pu' does
not count as "in-tree").

* kh/commit (Thu Nov 22 16:21:49 2007 -0800) 23 commits
 + Add a few more tests for git-commit
 + builtin-commit: Include the diff in the commit message when
   verbose.
 + builtin-commit: fix partial-commit support
 + Fix add_files_to_cache() to take pathspec, not user specified list
   of files
 + Export three helper functions from ls-files
 + builtin-commit: run commit-msg hook with correct message file
 + builtin-commit: do not color status output shown in the message
   template
 + file_exists(): dangling symlinks do exist
 + Replace "runstatus" with "status" in the tests
 + t7501-commit: Add test for git commit <file> with dirty index.
 + builtin-commit: Clean up an unused variable and a debug fprintf().
 + Call refresh_cache() when updating the user index for --only
   commits.
 + builtin-commit: Add newline when showing which commit was created
 + builtin-commit: resurrect behavior for multiple -m options
 + builtin-commit --s: add a newline if the last line was not a S-o-b
 + builtin-commit: fix --signoff
 + git status: show relative paths when run in a subdirectory
 + builtin-commit: Refresh cache after adding files.
 + builtin-commit: fix reflog message generation
 + launch_editor(): read the file, even when EDITOR=:
 + Port git commit to C.
 + Export launch_editor() and make it accept ':' as a no-op editor.
 + Add testcase for amending and fixing author in git commit.

I've been running with this, and so are people following 'next', for a
few days.  The series seems to be in a good shape.

* cr/tag-options (Thu Nov 22 23:16:51 2007 -0800) 2 commits
 + builtin-tag: accept and process multiple -m just like git-commit
 + Make builtin-tag.c use parse_options.

The handling of multiple -m options are made consistent with
what git-commit does; i.e. they are concatenated as separate
paragraphs.

* jc/branch-contains (Sun Nov 18 22:22:00 2007 -0800) 3 commits
 + git-branch --contains: doc and test
 + git-branch --contains=commit
 + parse-options: Allow to hide options from the default usage.

Contains Pierre's "hidable options with --help-all" patch.

----------------------------------------------------------------
[Actively cooking]

* jc/spht (Sat Nov 24 11:57:41 2007 -0800) 6 commits
 + core.whitespace: documentation updates.
 + builtin-apply: teach whitespace_rules
 + builtin-apply: rename "whitespace" variables and fix styles
 + core.whitespace: add test for diff whitespace error highlighting
 + git-diff: complain about >=8 consecutive spaces in initial indent
 + War on whitespace: first, a bit of retreat.

Now apply also knows about the customizable definition of what
whitespace breakages are, and I was reasonably happy. But Bruce kicked
it back from "scheduled to merge" to "still cooking" status, reminding
that we would want to have this not a tree-wide configuration but
per-path attribute.  And I agree with him.

* wc/add-i (Sun Nov 25 14:15:42 2007 +0100) 30 commits
 - Add "--patch" option to git-add--interactive
 + add -i: Fix running from a subdirectory
 + builtin-add: fix command line building to call interactive
 + Merge branch 'kh/commit' into wc/add-i
 + Add a few more tests for git-commit
 + git-add -i: allow multiple selection in patch subcommand
 + builtin-commit: Include the diff in the commit message when
   verbose.
 + builtin-commit: fix partial-commit support
 + Fix add_files_to_cache() to take pathspec, not user specified list
   of files
 + Export three helper functions from ls-files
 + builtin-commit: run commit-msg hook with correct message file
 + builtin-commit: do not color status output shown in the message
   template
 + file_exists(): dangling symlinks do exist
 + Replace "runstatus" with "status" in the tests
 + t7501-commit: Add test for git commit <file> with dirty index.
 + builtin-commit: Clean up an unused variable and a debug fprintf().
 + Call refresh_cache() when updating the user index for --only
   commits.
 + builtin-commit: Add newline when showing which commit was created
 + builtin-commit: resurrect behavior for multiple -m options
 + builtin-commit --s: add a newline if the last line was not a S-o-b
 + builtin-commit: fix --signoff
 + git status: show relative paths when run in a subdirectory
 + builtin-commit: Refresh cache after adding files.
 + builtin-commit: fix reflog message generation
 + launch_editor(): read the file, even when EDITOR=:
 + Port git commit to C.
 + Export launch_editor() and make it accept ':' as a no-op editor.
 + Add testcase for amending and fixing author in git commit.
 + Add path-limiting to git-add--interactive
 + Teach builtin-add to pass multiple paths to git-add--interactive

This looks larger than it really is, as I merged in the builtin commit
series near the tip (they interact with each other somewhat, and it is
very likely that builtin commit series will graduate to 'master' before
this series).

I also adjusted the "git add -p" patch from Wincent and have it at the
tip.  It is parked in 'pu' for now.

* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
 + refactor fetch's ref matching to use refname_match()
 + push: use same rules as git-rev-parse to resolve refspecs
 + add refname_match()
 + push: support pushing HEAD to real branch name

I think the "git push HEAD" is a good change, and also using the same
short refname resolving as rev-parse does for matching the destination
of push.  I am having second thoughts on the last one.  The changed
semantics is somewhat less safe:

    * We did not allow fetching outside refs/ (except HEAD), but now we
      allow any random string.

    * We used to restrict fetching names that do not begin with refs/ to
      heads, tags and remotes, but now the code grabs anything underneath
      refs/.

which could invite mistakes by letting typos slip through.

Having said that, I probably "fetch" much less often than other people
do and these are non issues in the real-world usecases.  It could be
that I am worried too much needlessly.  If anybody who is following
'next' has been bitten by the change, please speak up.

----------------------------------------------------------------
[Stalled]

* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
 - revert/cherry-pick: start refactoring call to merge_recursive

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 - merge-nu: a new merge backend without using unpack_trees()
 - read_tree: take an explicit index structure
 - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

The second one could probably be used to replace the use of
path-list in the tip commit on the kh/commit series.

* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
 - Added diff hunk coloring to git-add--interactive
 - Let git-add--interactive read colors from .gitconfig
 - Added basic color support to git add --interactive

There were many good suggestions by Jeff to the updated series;
hopefully we can replace these three with it.

* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
 + Add missing inside_work_tree setting in setup_git_directory_gently

There was an additional patch, which still had issues Dscho
pointed out.  Waiting for refinements.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* 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.

* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
 . Make git-svn rebase --dirty pass along --dirty to git-rebase.
 . Implement --dirty for git-rebase--interactive.
 . Introduce --dirty option to git-rebase, allowing you to start from
   a dirty state.

This seems to be optimized for the --dirty case too much.  I'd
prefer an implementation that make rebases without --dirty to
pay no penalty (if that is possible, otherwise "as little as
possible").

* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
 . handle renames using similarity engine
 . introduce generic similarity library
 . change hash table calling conventions

This was an attempt to use different strategy to speed up
similarity computation, but does not work quite well as is.

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

[Jakub Narebski]

Junio C Hamano wrote:

> [Actively cooking]
> 
> * jc/spht (Sat Nov 24 11:57:41 2007 -0800) 6 commits
>  + core.whitespace: documentation updates.
>  + builtin-apply: teach whitespace_rules
>  + builtin-apply: rename "whitespace" variables and fix styles
>  + core.whitespace: add test for diff whitespace error highlighting
>  + git-diff: complain about >=8 consecutive spaces in initial indent
>  + War on whitespace: first, a bit of retreat.
> 
> Now apply also knows about the customizable definition of what
> whitespace breakages are, and I was reasonably happy. But Bruce kicked
> it back from "scheduled to merge" to "still cooking" status, reminding
> that we would want to have this not a tree-wide configuration but
> per-path attribute.  And I agree with him.

Currently apply.whitespace is per repository - would this be changed
as well, i.e. would it be moved to gitattributes together with custom
diff drivers (or at least custom funcnames), custom merge drivers,
making it per-project (if put under version control) and per-path?


By the way, i18n.commitEncoding is per repository, and used to affect
repository; not so with the "encoding" header in commit object.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[J. Bruce Fields]

On Sun, Nov 25, 2007 at 09:36:14PM +0100, Jakub Narebski wrote:
> Junio C Hamano wrote:
> 
> > [Actively cooking]
> > 
> > * jc/spht (Sat Nov 24 11:57:41 2007 -0800) 6 commits
> >  + core.whitespace: documentation updates.
> >  + builtin-apply: teach whitespace_rules
> >  + builtin-apply: rename "whitespace" variables and fix styles
> >  + core.whitespace: add test for diff whitespace error highlighting
> >  + git-diff: complain about >=8 consecutive spaces in initial indent
> >  + War on whitespace: first, a bit of retreat.
> > 
> > Now apply also knows about the customizable definition of what
> > whitespace breakages are, and I was reasonably happy. But Bruce kicked
> > it back from "scheduled to merge" to "still cooking" status, reminding
> > that we would want to have this not a tree-wide configuration but
> > per-path attribute.  And I agree with him.
> 
> Currently apply.whitespace is per repository - would this be changed
> as well,

There's a difference between the choice of preferred whitespace style
and the choice of action to take when encountering "bad" whitespace.

The former is (I think) obviously a property of the project (or perhaps
of individual paths within the project).  The latter may depend on what
you're doing with it at any given moment--for example, if I'm applying
patches to submit, I generally want to fix whitespace, but if I'm just
examining someone else's patches temporarily then I might want to import
them quickly without fixing up everything.

So, no, I don't think there should be a .gitattribute equivalent to
apply.whitespace.

--b.

> i.e. would it be moved to gitattributes together with custom
> diff drivers (or at least custom funcnames), custom merge drivers,
> making it per-project (if put under version control) and per-path?

> 
> 
> By the way, i18n.commitEncoding is per repository, and used to affect
> repository; not so with the "encoding" header in commit object.
> 
> -- 
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[J. Bruce Fields]

On Sat, Nov 24, 2007 at 11:09:59AM -0800, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
> > I think that would be better to append a single line at the end of the 
> > display with a clue about what "non fast forward" means.
> 
> I'd agree, but having said all the above, I am not entirely
> happy not mentioning "what next" at all.
> 
> There are two equally valid "what next" after your push is
> rejected due to non-fast-forwardness.
> 
>  (1) You know what you are doing.
> 
>    - You are pushing into a "back-up" repository, not for a
>      public consumption.
> 
>    - You are pushing a branch that are advertised to rebase and
>      rewind into your own publishing repository, and other
>      people interacting with the branch know about this.
> 
>    - You pushed a wrong head there very recently and are fairly
>      confident that nobody has seen that mistake, and pushing
>      the correct one to fix the mistake.
> 
>      In these cases, forcing the push is the right solution
>      (except that the third one is dubious, because it depends
>      heavily on the "fairly confident" part).
> 
>  (2) You were building on a stale head, and were indeed about to
>      lose others' changes with a non-fast-forward push.
> 
>      The right solution is to rebuild what you push so that you
>      will not lose others' changes.  Rebuilding can take two
>      different forms:
> 
>    - You may want to git-fetch and rebase your work on top of
>      others'.
> 
>    - You may want to git-pull, which will merge your work with
>      what others did.
> 
> But of couse the above is way too long as the help text.
> 
> Does the user-manual talk about this?  It has a really good
> description of how to notice when a merge is not resolved
> automatically and what to do next ("Resolving a merge" section).
> Perhaps we can enhance "Pushing changes to a public repository"
> section to include "what if the push is refused" information.

There's a very brief mention of this:

	"As with git-fetch, git-push will complain if this does not
	result in a <<fast-forwards,fast forward>>.  Normally this is a
	sign of something wrong.  However, if you are sure you know what
	you're doing, you may force git-push to perform the update
	anyway by preceding the branch name by a plus sign:

But it'd probably be better to have a separate section.  That makes it
possible to say a little more, and also gets a section called "what to
do when a push fails" into the table of contents.

(Though that's a little vague--push can also fail just because you
mispell the url or something.  A more precise reference to the
particular error might be better, but we'll have to agree on the error
message first....)

Anyway, here's a first draft.

--b.

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 8355cce..7544715 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1929,15 +1929,9 @@ or just
 $ git push ssh://yourserver.com/~you/proj.git master
 -------------------------------------------------
 
-As with git-fetch, git-push will complain if this does not result in
-a <<fast-forwards,fast forward>>.  Normally this is a sign of
-something wrong.  However, if you are sure you know what you're
-doing, you may force git-push to perform the update anyway by
-proceeding the branch name by a plus sign:
-
--------------------------------------------------
-$ git push ssh://yourserver.com/~you/proj.git +master
--------------------------------------------------
+As with git-fetch, git-push will complain if this does not result in a
+<<fast-forwards,fast forward>>; see the following section for details on
+handling this case.
 
 Note that the target of a "push" is normally a
 <<def_bare_repository,bare>> repository.  You can also push to a
@@ -1965,6 +1959,55 @@ See the explanations of the remote.<name>.url, branch.<name>.remote,
 and remote.<name>.push options in gitlink:git-config[1] for
 details.
 
+[[forcing-push]]
+What to do when a push fails
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If the push does not result in a <<fast-forwards,fast forward>> of the
+remote branch, then it will fail with an error like:
+
+-------------------------------------------------
+error: remote 'refs/heads/master' is not an ancestor of
+ local  'refs/heads/master'.
+ Maybe you are not up-to-date and need to pull first?
+error: failed to push to 'ssh://yourserver.com/~you/proj.git'
+-------------------------------------------------
+
+The most likely reason for this is that you have replaced some of the
+history that you already pushed, so that your "master" is no longer a
+descendant of upstream's "master",  This could happen, for example, if
+you:
+
+	- use `git reset --hard` to remove already-published commits, or
+	- use `git commit --amend` to replace already-published commits
+	  (as in <<fixing-a-mistake-by-editing-history>>), or
+	- use `git rebase` to rebase any already-published commits (as
+	  in <<using-git-rebase>>).
+
+If you are sure you want to replace the branch in the public repository
+by your branch, you may force git-push to perform the update anyway by
+preceding the branch name with a plus sign:
+
+-------------------------------------------------
+$ git push ssh://yourserver.com/~you/proj.git +master
+-------------------------------------------------
+
+Normally whenever a branch head in a public repository is modified, it
+is modified to point to a descendent of the commit that it pointed to
+before.  By forcing a push in this situation, you break that convention.
+(See <<problems-with-rewriting-history>>).
+
+Nevertheless, this is a common practice for people that need a simple
+way to publish a work-in-progress patch series, and it is an acceptable
+compromise as long as you warn other developers that this is how you
+intend to manage the branch.
+
+It's also possible for a push to fail in this way when other people have
+the right to push to the same repository.  In that case, the correct
+solution is to update your work by either a pull or a fetch followed by
+a rebase; see the <<setting-up-a-shared-repository,next section>> for
+more.
+
 [[setting-up-a-shared-repository]]
 Setting up a shared repository
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

[Junio C Hamano]

"J. Bruce Fields" <bfields@fieldses.org> writes:

> Anyway, here's a first draft.
>
> --b.
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 8355cce..7544715 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> ...
> +Normally whenever a branch head in a public repository is modified, it
> +is modified to point to a descendent of the commit that it pointed to
> +before.  By forcing a push in this situation, you break that convention.
> +(See <<problems-with-rewriting-history>>).
> +
> +Nevertheless, this is a common practice for people that need a simple
> +way to publish a work-in-progress patch series, and it is an acceptable
> +compromise as long as you warn other developers that this is how you
> +intend to manage the branch.

Note that modern git allows repository owners to forbid such a forced
non fast forward push at the receiving end.  In such a case, you cannot
even force a push.

Instead, you would need to fetch the current branch tip from the remote
and merge it into the branch you were tring to push, possibly using the
"ours" merge strategy, before pushing it again.  Use of "ours" merge in
such a case:

 - makes the next fetch by other people properly fast-forwarding;

 - records your admission of guilt: "I screwed up the last push and
   this is a replacement --- this is what I really should have pushed
   the last time".

 - makes the resulting tree exactly the same as what you tried to push
   unsuccessfully.  This is a valid substitute to a forced push in that
   it reverts the mistakes _you_ made with the previous push.

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

[J. Bruce Fields]

On Sun, Nov 25, 2007 at 02:42:08PM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> 
> > Anyway, here's a first draft.
> >
> > --b.
> >
> > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > index 8355cce..7544715 100644
> > --- a/Documentation/user-manual.txt
> > +++ b/Documentation/user-manual.txt
> > ...
> > +Normally whenever a branch head in a public repository is modified, it
> > +is modified to point to a descendent of the commit that it pointed to
> > +before.  By forcing a push in this situation, you break that convention.
> > +(See <<problems-with-rewriting-history>>).
> > +
> > +Nevertheless, this is a common practice for people that need a simple
> > +way to publish a work-in-progress patch series, and it is an acceptable
> > +compromise as long as you warn other developers that this is how you
> > +intend to manage the branch.
> 
> Note that modern git allows repository owners to forbid such a forced
> non fast forward push at the receiving end.  In such a case, you cannot
> even force a push.
> 
> Instead, you would need to fetch the current branch tip from the remote
> and merge it into the branch you were tring to push, possibly using the
> "ours" merge strategy, before pushing it again.  Use of "ours" merge in
> such a case:
> 
>  - makes the next fetch by other people properly fast-forwarding;
> 
>  - records your admission of guilt: "I screwed up the last push and
>    this is a replacement --- this is what I really should have pushed
>    the last time".
> 
>  - makes the resulting tree exactly the same as what you tried to push
>    unsuccessfully.  This is a valid substitute to a forced push in that
>    it reverts the mistakes _you_ made with the previous push.

OK, that's interesting.  In a similar vein, I've been experimenting with
"merge -s ours" lately as a way to keep track of the "meta-history" of
an unsubmitted patch series in progress.  It seems a little hairy right
now, but maybe it'll turn out to be The Right Thing to do.

I don't want to deal with this in the manual yet.  For the sake of
keeping things simple, I'd rather first stick to the case of a public
repository set up by the user which the user controls.  And I think that
kind of use of "-s ours" is worth documenting but I'm not sure how to
deal with it yet.

--b.

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

[Nicolas Pitre]

On Sun, 25 Nov 2007, J. Bruce Fields wrote:

> There's a very brief mention of this:
> 
> 	"As with git-fetch, git-push will complain if this does not
> 	result in a <<fast-forwards,fast forward>>.  Normally this is a
> 	sign of something wrong.  However, if you are sure you know what
> 	you're doing, you may force git-push to perform the update
> 	anyway by preceding the branch name by a plus sign:

... or use "git push -f" (is it mentioned in the manual?)

> But it'd probably be better to have a separate section.  That makes it
> possible to say a little more, and also gets a section called "what to
> do when a push fails" into the table of contents.
> 
> (Though that's a little vague--push can also fail just because you
> mispell the url or something.  A more precise reference to the
> particular error might be better, but we'll have to agree on the error
> message first....)
> 
> Anyway, here's a first draft.

I think we should devote a section of the manual to the "rebase" 
workflow compared to the "merge" workflow.  One of the public Git repo 
I currently maintain is constantly rebased, and I've provided a quick 
Git update cheat sheet along with its announcement for that case:

  http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-November/043147.html

I also wrote an introductory document for $job internal use.  I have a 
section where I briefly cover the main differences and implications for 
merge vs rebase.  Here it is -- please feel free to add it to the manual 
if you think it can be valuable.

----- >8

Rebase vs Merge
---------------

Merge and rebase may look like they are doing the same thing, but they act 
very differently on the repository. Merging basically takes all the 
changes in the remote branch and mix them with your local branch. 
For example, if you create a branch "mywork" from the orion/core branch, 
you will end up with something that looks like this:

	a--b--c <-- orion/master
	       \
	        A--B--C <-- mywork 

After a fetch, the remote branch might have advanced in parallel to
local changes as follows:

	a--b--c--d--e--f <-- orion/master
	       \
	        A--B--C <-- mywork 

If you later do a 'git merge orion/master', your history will look like
this, where 'M' is a merge commit:

	a--b--c--d--e--f <-- orion/master
	       \        \
	        A--B--C--M <-- mywork

A rebase, on the other hand, takes all your changes and reapplies them to 
the current state of the specified branch, and assign the result to the 
currently checked out branch. With the same example, if you were to do a 
'git rebase orion/master', you would get something like this:

	a--b--c--d--e--f <-- orion/master
	                \
	                 A'--B'--C' <-- mywork

Rebase does what the name implies and creates a new baseline for your 
branch. The benefit of this is that you end up with a cleaner history log,
especially if you have to update with the remote branch often, in both
your repository and in upstream repositories that gets updated from you.  


Tracking a rebased remote branch
--------------------------------

Let's suppose that the remote branch you're tracking is itself subject
to be rebased.  Before performing a fetch to update that remote branch,
your history might look like the previous example:

	a--b--c--d--e--f <-- orion/master
	                \
	                 A'--B'--C' <-- mywork

If the remote branch had some commit replaced, or was rebased on a
different commit (or both), then things could look like this after a
fetch:

	a---b---c'--d'--e'--f'--g <-- orion/master
	     \
	      c---d---e---f <-- orion/master@{1}
	                   \
	                    A---B---C <-- mywork

In this example, commits c, d, e and f are not present anymore in the
remote repository.  They are still reachable from your "mywork" local
branch though.  The "orion/master@{1}" is the notation used to refer to the
previous value (before the fetch) of "orion/master".

If you were to use 'git merge' to bring the new commits (c', d', e', f'
and g) into your local branch, that wouldn't get rid of the commits that
they are meant to replace, and is likely to cause a major merge conflict.

The only option in that case is to rebase your work.  Yet there is a twist
because 'rebase' moves every commit reachable from the current branch on
top of the specified branch by default, including those c-d-e-f commits.
So the --onto argument to 'git rebase' must be used to skip over those
unwanted commits as follows:

	git rebase --onto orion/master orion/master@{1} mywork

This means to rebase commits between orion/master@{1} and mywork on top of
orion/master and assing mywork to the result.  The git-rebase man page
provides more examples and a detailed explanation of how 'rebase' works
which is worth a read.

NOte: the orion Git repository is indeed rebased often.  So you'll have
to use this rebase invokation when fetching updates from it.

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

[J. Bruce Fields]

On Sun, Nov 25, 2007 at 11:02:05PM -0500, Nicolas Pitre wrote:
> On Sun, 25 Nov 2007, J. Bruce Fields wrote:
> 
> > There's a very brief mention of this:
> > 
> > 	"As with git-fetch, git-push will complain if this does not
> > 	result in a <<fast-forwards,fast forward>>.  Normally this is a
> > 	sign of something wrong.  However, if you are sure you know what
> > 	you're doing, you may force git-push to perform the update
> > 	anyway by preceding the branch name by a plus sign:
> 
> ... or use "git push -f" (is it mentioned in the manual?)
> 
> > But it'd probably be better to have a separate section.  That makes it
> > possible to say a little more, and also gets a section called "what to
> > do when a push fails" into the table of contents.
> > 
> > (Though that's a little vague--push can also fail just because you
> > mispell the url or something.  A more precise reference to the
> > particular error might be better, but we'll have to agree on the error
> > message first....)
> > 
> > Anyway, here's a first draft.
> 
> I think we should devote a section of the manual to the "rebase" 
> workflow compared to the "merge" workflow.

There's this:

	http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-git-rebase

It doesn't explicitly compare the two, but I think between that and the
containing chapter, it hits on the main issues.

> One of the public Git repo 
> I currently maintain is constantly rebased, and I've provided a quick 
> Git update cheat sheet along with its announcement for that case:
> 
>   http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-November/043147.html

The trick of

	tag -d old_base remote/master
	git fetch remote
	git rebase --onto remote/master old_base my_work

is something we don't document anywhere.

(We might not have to quite so much if we came up with a command that
did the job of git-rebase and/or cherry-pick with more intuitive
syntax....)

> I also wrote an introductory document for $job internal use.  I have a 
> section where I briefly cover the main differences and implications for 
> merge vs rebase.  Here it is -- please feel free to add it to the manual 
> if you think it can be valuable.

Thanks.  I think the manual covers most of what's in the "rebase vs
merge" section already.  (Though it'd be worth reconsidering how we do
it.)

The "tracking a rebased remote branch" stuff would be new and, I think,
helpful.

I'll take a closer look at it eventually--but if someone wants to speed
the process by working out exactly where to fit this in, which parts are
duplicated, etc., and turn the result into a patch, I'd be happy.

I do find that trying to work on top of a constantly rebased branch is
annoying no matter how I do it.  So I sometimes wonder if we shouldn't
instead be finding ways to avoid the practice.

--b.

> 
> ----- >8
> 
> Rebase vs Merge
> ---------------
> 
> Merge and rebase may look like they are doing the same thing, but they act 
> very differently on the repository. Merging basically takes all the 
> changes in the remote branch and mix them with your local branch. 
> For example, if you create a branch "mywork" from the orion/core branch, 
> you will end up with something that looks like this:
> 
> 	a--b--c <-- orion/master
> 	       \
> 	        A--B--C <-- mywork 
> 
> After a fetch, the remote branch might have advanced in parallel to
> local changes as follows:
> 
> 	a--b--c--d--e--f <-- orion/master
> 	       \
> 	        A--B--C <-- mywork 
> 
> If you later do a 'git merge orion/master', your history will look like
> this, where 'M' is a merge commit:
> 
> 	a--b--c--d--e--f <-- orion/master
> 	       \        \
> 	        A--B--C--M <-- mywork
> 
> A rebase, on the other hand, takes all your changes and reapplies them to 
> the current state of the specified branch, and assign the result to the 
> currently checked out branch. With the same example, if you were to do a 
> 'git rebase orion/master', you would get something like this:
> 
> 	a--b--c--d--e--f <-- orion/master
> 	                \
> 	                 A'--B'--C' <-- mywork
> 
> Rebase does what the name implies and creates a new baseline for your 
> branch. The benefit of this is that you end up with a cleaner history log,
> especially if you have to update with the remote branch often, in both
> your repository and in upstream repositories that gets updated from you.  
> 
> 
> Tracking a rebased remote branch
> --------------------------------
> 
> Let's suppose that the remote branch you're tracking is itself subject
> to be rebased.  Before performing a fetch to update that remote branch,
> your history might look like the previous example:
> 
> 	a--b--c--d--e--f <-- orion/master
> 	                \
> 	                 A'--B'--C' <-- mywork
> 
> If the remote branch had some commit replaced, or was rebased on a
> different commit (or both), then things could look like this after a
> fetch:
> 
> 	a---b---c'--d'--e'--f'--g <-- orion/master
> 	     \
> 	      c---d---e---f <-- orion/master@{1}
> 	                   \
> 	                    A---B---C <-- mywork
> 
> In this example, commits c, d, e and f are not present anymore in the
> remote repository.  They are still reachable from your "mywork" local
> branch though.  The "orion/master@{1}" is the notation used to refer to the
> previous value (before the fetch) of "orion/master".
> 
> If you were to use 'git merge' to bring the new commits (c', d', e', f'
> and g) into your local branch, that wouldn't get rid of the commits that
> they are meant to replace, and is likely to cause a major merge conflict.
> 
> The only option in that case is to rebase your work.  Yet there is a twist
> because 'rebase' moves every commit reachable from the current branch on
> top of the specified branch by default, including those c-d-e-f commits.
> So the --onto argument to 'git rebase' must be used to skip over those
> unwanted commits as follows:
> 
> 	git rebase --onto orion/master orion/master@{1} mywork
> 
> This means to rebase commits between orion/master@{1} and mywork on top of
> orion/master and assing mywork to the result.  The git-rebase man page
> provides more examples and a detailed explanation of how 'rebase' works
> which is worth a read.
> 
> NOte: the orion Git repository is indeed rebased often.  So you'll have
> to use this rebase invokation when fetching updates from it.

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

[Nicolas Pitre]

On Mon, 26 Nov 2007, J. Bruce Fields wrote:

> I do find that trying to work on top of a constantly rebased branch is
> annoying no matter how I do it.  So I sometimes wonder if we shouldn't
> instead be finding ways to avoid the practice.

I don't think it can't be avoided in many cases.  Some stuff gets 
rebased because it has to be refined before it is merged in a more 
stable and more "official" repository.  Working on top of a rebased 
branch could be much easier if there was a dedicated command to perform 
the local rebase of one's work after a fetch, just like the pull command 
does a merge after a fetch, at which point both work flows would be 
almost equivalent wrt ease of use.


Nicolas

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

[J. Bruce Fields]

On Sun, Nov 25, 2007 at 11:29:56PM -0500, Nicolas Pitre wrote:
> On Mon, 26 Nov 2007, J. Bruce Fields wrote:
> 
> > I do find that trying to work on top of a constantly rebased branch is
> > annoying no matter how I do it.  So I sometimes wonder if we shouldn't
> > instead be finding ways to avoid the practice.
> 
> I don't think it can't be avoided in many cases.  Some stuff gets 
> rebased because it has to be refined before it is merged in a more 
> stable and more "official" repository.

Well, there is for example the option of doing things like:

	git checkout -b new-mywork mywork
	git fetch origin
	git rebase new-mywork origin
	# further reordering of commits, etc., as needed
	git merge -s ours mywork
	git branch -d mywork
	git push mypubrepo new-mywork:mywork

and if you do this each time, then the public branch named "mywork"
always fast-forwards.  Its first parent, mywork^, is always a clean
patch series against upstream, and is what you'll eventually submit.
The second parent leads to historical versions of the patch series.

> Working on top of a rebased 
> branch could be much easier if there was a dedicated command to perform 
> the local rebase of one's work after a fetch, just like the pull command 
> does a merge after a fetch, at which point both work flows would be 
> almost equivalent wrt ease of use.

I don't think that works if you have more than one branch built on top
of the branch you're fetching.

The problem is that you have to do the rebase at the same time as the
fetch, because it's only the fetch that knows what the old head of the
branch was.

You don't need to know what the old head of the branch was before if
you're fetching a branch that always fast-forwards.  But you do in the
case where it doesn't fast-forward, because in that case the old head
will be forgotten as soon as you're done.

--b.

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

[Jan Hudec]

On Mon, Nov 26, 2007 at 04:15:21 +0000, J. Bruce Fields wrote:
> The trick of
> 
> 	tag -d old_base remote/master
> 	git fetch remote
> 	git rebase --onto remote/master old_base my_work
> 
> is something we don't document anywhere.

Do we really need the tag/branch?

git fetch remote
git rebase --onto remote/master remote/master@{1} my_work

And of course the thing is only needed if master has been rewound. Otherwise
just:

git rebase remote/master my_work

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

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

[Jakub Narebski]

Nicolas Pitre wrote:

> On Mon, 26 Nov 2007, J. Bruce Fields wrote:
> 
>> I do find that trying to work on top of a constantly rebased branch is
>> annoying no matter how I do it.  So I sometimes wonder if we shouldn't
>> instead be finding ways to avoid the practice.
> 
> I don't think it can't be avoided in many cases.  Some stuff gets 
> rebased because it has to be refined before it is merged in a more 
> stable and more "official" repository.  Working on top of a rebased 
> branch could be much easier if there was a dedicated command to perform 
> the local rebase of one's work after a fetch, just like the pull command 
> does a merge after a fetch, at which point both work flows would be 
> almost equivalent wrt ease of use.

There was idea of 'rebase' merge strategy (which was in some form
implemented once under another name: check archives if you want).
And there is an idea of --rebase switch git git-pull.

What is left is the implementation ;-)

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Andreas Ericsson]

Jakub Narebski wrote:
> Nicolas Pitre wrote:
> 
>> On Mon, 26 Nov 2007, J. Bruce Fields wrote:
>>
>>> I do find that trying to work on top of a constantly rebased branch is
>>> annoying no matter how I do it.  So I sometimes wonder if we shouldn't
>>> instead be finding ways to avoid the practice.
>> I don't think it can't be avoided in many cases.  Some stuff gets 
>> rebased because it has to be refined before it is merged in a more 
>> stable and more "official" repository.  Working on top of a rebased 
>> branch could be much easier if there was a dedicated command to perform 
>> the local rebase of one's work after a fetch, just like the pull command 
>> does a merge after a fetch, at which point both work flows would be 
>> almost equivalent wrt ease of use.
> 
> There was idea of 'rebase' merge strategy (which was in some form
> implemented once under another name: check archives if you want).
> And there is an idea of --rebase switch git git-pull.
> 
> What is left is the implementation ;-)
> 

"git pull --rebase" already has an implementation. Dscho cooked one up
which I've been using since then. It works nicely.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Nicolas Pitre]

[ I get really really annoyed when your replies to me aren't directly 
  addressed to me, Jakub.  Told you so repeatedly in the past as well.
  Why are you the only one on this list apparently not able to use a 
  proper email setup? ]

On Mon, 26 Nov 2007, Jakub Narebski wrote:

> Nicolas Pitre wrote:
> 
> > Some stuff gets rebased because it has to be refined before it is 
> > merged in a more stable and more "official" repository.  Working on 
> > top of a rebased branch could be much easier if there was a 
> > dedicated command to perform the local rebase of one's work after a 
> > fetch, just like the pull command does a merge after a fetch, at 
> > which point both work flows would be almost equivalent wrt ease of 
> > use.
> 
> There was idea of 'rebase' merge strategy (which was in some form
> implemented once under another name: check archives if you want).
> And there is an idea of --rebase switch git git-pull.
> 
> What is left is the implementation ;-)

I thought that had been implemented already.  But in fact I had forgot 
about it altogether.

It shouldn't be much complicated than:

	git fetch ${remote} && \
	git rebase --onto ${remote} ${remote}"@{1}" ${local}

given that ${remote} did actually change during the fetch.


Nicolas

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

[David Kastrup]

Nicolas Pitre <nico@cam.org> writes:

> [ I get really really annoyed when your replies to me aren't directly 
>   addressed to me, Jakub.  Told you so repeatedly in the past as well.
>   Why are you the only one on this list apparently not able to use a 
>   proper email setup? ]

X-Injected-Via-Gmane: http://gmane.org/

And Jakub by far is not the only one using gmane for reading and writing
to the list.

I am reading and writing on a number of mailing lists with either
explicit or implicit gateways to news servers.  But the git mailing list
is the only one where I ever encountered a semi-permanent stream of
(sometimes quite rude) complaints because people insist on getting
replies at least twice: once by the mailing list, and once by personal
Email.  In contrast to claims made here, it is _not_ common netiquette
to create extra personal copies.  In fact, for articles sent through
Usenet servers, it is generally considered an _annoyance_ to include
unannounced "courtesy copies" since replies to them will not usually
reach the list and will require redoing.

And I have received complaints about accumulating Cc lists from mailing
list moderators as well, since list servers tend to queue stuff for
moderation once the Cc header reaches a certain size.

I really don't get the point of those demands for personal extra copies:
do people or don't they read the mailing list?

On the current computer setup, I am answering to the list.  On a
different computer, all mail to the mailing list disappears into a black
hole without any indication why.  So I _have_ to use gmane there.  And I
don't see why I should get heat for that when apparently the
automoderation of the list is set up as rabidly as to quietly censor
everything I send via Email (everybody else is able to receive mail
through that account from me).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Nicolas Pitre]

On Mon, 26 Nov 2007, David Kastrup wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > [ I get really really annoyed when your replies to me aren't directly 
> >   addressed to me, Jakub.  Told you so repeatedly in the past as well.
> >   Why are you the only one on this list apparently not able to use a 
> >   proper email setup? ]
> 
> X-Injected-Via-Gmane: http://gmane.org/
> 
> And Jakub by far is not the only one using gmane for reading and writing
> to the list.

It is strange, though, that Jakub is the only one I've noticed who isn't 
able to do me the courtesy of addressing me directly when replying to 
me.

> I am reading and writing on a number of mailing lists with either
> explicit or implicit gateways to news servers.  But the git mailing list
> is the only one where I ever encountered a semi-permanent stream of
> (sometimes quite rude) complaints because people insist on getting
> replies at least twice: once by the mailing list, and once by personal
> Email.  In contrast to claims made here, it is _not_ common netiquette
> to create extra personal copies.

We must not live in the same virtual world then.  This _is_ common 
netiquette in the Linux world.

I get over 500 emails a day.  I can thread them just like a news 
reader would do.  But I do sort them in different folders as well.  My 
most important folder contains emails directly sent to me, or on which 
I'm CC'd.  The other folders might get completely ignored when I'm too 
busy, or threads quickly purged out.

>  In fact, for articles sent through
> Usenet servers, it is generally considered an _annoyance_ to include
> unannounced "courtesy copies" since replies to them will not usually
> reach the list and will require redoing.

This is a mailing list and not a news group.  I don't care if you use a 
newsgroup gateway if it isn't broken.  As it is, gmane is broken as far 
as I'm concerned.

So please complain to gmane or change your setup.


Nicolas

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

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

>> Nicolas Pitre <nico@cam.org> writes:
>> 
> This is a mailing list and not a news group.  I don't care if you use a 
> newsgroup gateway if it isn't broken.  As it is, gmane is broken as far 
> as I'm concerned.
>
> So please complain to gmane or change your setup.

Don't blame gmane, please.  I picked this message up in gmane and I am
responding to you in my newsreader.

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

[David Kastrup]

Nicolas Pitre <nico@cam.org> writes:

> On Mon, 26 Nov 2007, David Kastrup wrote:
>
>>  In fact, for articles sent through Usenet servers, it is generally
>> considered an _annoyance_ to include unannounced "courtesy copies"
>> since replies to them will not usually reach the list and will
>> require redoing.
>
> This is a mailing list and not a news group.  I don't care if you use
> a newsgroup gateway if it isn't broken.  As it is, gmane is broken as
> far as I'm concerned.

A gateway should not be sending to anything but the mailing list
address.  It is not a mail multiplicator.

> So please complain to gmane or change your setup.

I already explained: the git mailing list is set up in a manner that
will block mail from some accounts of mine without notice or error
report.

If there is general consensus on the list that news gateways are not
compatible with the mailing list policies, please report this to gmane,
and gmane will switch the list off-line.

I have no idea why anybody would think this an improvement, but given
the amount of flak I already got for daring to use gmane, it will
probably improve the atmosphere on the list if people like me are locked
out completely from participation rather than their usage of gmane be
lambasted time and again.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Nicolas Pitre]

On Mon, 26 Nov 2007, David Kastrup wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > This is a mailing list and not a news group.  I don't care if you use
> > a newsgroup gateway if it isn't broken.  As it is, gmane is broken as
> > far as I'm concerned.
> 
> A gateway should not be sending to anything but the mailing list
> address.  It is not a mail multiplicator.

Then don't use it.

Yet Junio just replied to my mail, apparently using his news reader, and 
I was directly addressed.

> > So please complain to gmane or change your setup.
> 
> I already explained: the git mailing list is set up in a manner that
> will block mail from some accounts of mine without notice or error
> report.

And why should _I_ care?  This is _your_ problem for you to investigate.

> If there is general consensus on the list that news gateways are not
> compatible with the mailing list policies, please report this to gmane,
> and gmane will switch the list off-line.

Look, it is you the offender here with your broken setup to interact 
with this mailing list.  So I'm complaining to _you_.  Please cope with 
it.

> I have no idea why anybody would think this an improvement, but given
> the amount of flak I already got for daring to use gmane, it will
> probably improve the atmosphere on the list if people like me are locked
> out completely from participation rather than their usage of gmane be
> lambasted time and again.

Please figure out an alternative to gmane on your own, or ask those who 
apparently get it to work properly.  I'm sure you're bright enough to 
find a way.


Nicolas

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

[Jakub Narebski]

Nicolas Pitre wrote:
> On Mon, 26 Nov 2007, David Kastrup wrote:
> 
>> Nicolas Pitre <nico@cam.org> writes:
>> 
>>> [ I get really really annoyed when your replies to me aren't directly 
>>>   addressed to me, Jakub.  Told you so repeatedly in the past as well.
>>>   Why are you the only one on this list apparently not able to use a 
>>>   proper email setup? ]

It is about proper _newsreader_ setup, in fact...

>> X-Injected-Via-Gmane: http://gmane.org/
>> 
>> And Jakub by far is not the only one using gmane for reading and writing
>> to the list.
> 
> It is strange, though, that Jakub is the only one I've noticed who isn't 
> able to do me the courtesy of addressing me directly when replying to 
> me.

My responding [sometimes] only to list is combination of several
issues.

First, newsreader I use, namely KNode 0.10.2 in Kontact 1.2.3 from
KDE 3.5.3 does not make it easy. By default it replies only to list
unless Mail-Reply-To header is used (which shouldn't IIRC). I have
to click reply by e-mail button to send reply via email... and it
adds only last author, from  From header. The rest I have to add by
hand.

Second, something is rotten^W broken between GMane and VGER; if I add
git email address to the list of addresses to send to, VGER rejects and
refuses to send to git mailing list. I have to send also to newsgroup
(gmane.comp.version-control.git) to send to all git mailing list. Now
it looks like two mails are actually send: one to CC'ed addresses, one
to git mailing list, and sometimes people when replying me forget to
reply also to git mailing list.

So third, when I don't think I have something significant to contribute,
and I don't necessary expect answer, I send email only to git mailing
list (news message only to GMane newsgroup coupled with git mailing
list, actually).


Sure, one of solutions would be for me to change newsreader, for example
to Gnus (as people using Gnus doesn't seem to have the same problem
I have), but I think you do know that it is not easy to change habits.

[cut]

Nevertheless, mails are sent to git mailing list, so they should go
to you too.

-- 
Jakub Narebski
Poland

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

[David Kastrup]

Nicolas Pitre <nico@cam.org> writes:

> Please figure out an alternative to gmane on your own, or ask those
> who apparently get it to work properly.  I'm sure you're bright enough
> to find a way.

Without so much as a bounce message or delivery report, there is nothing
to apply one's brightness to.

Since the git mailing list is the only mailing list that censors my work
account in that manner, it is obviously set up in a way different from
most other mailing lists.

Not being a list moderator and not getting any bounce notification,
there is nothing I can use for figuring out what makes the git mailing
list different from others.

And the gratuitous hostility easily evoked towards anybody experiencing
problems with either the list or other aspects concerning git is really
something I have not experienced in any other developer circle.

And I am quite an oldtimer concerning both mailing lists and Usenet.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Johannes Schindelin]

Hi,

On Mon, 26 Nov 2007, Jakub Narebski wrote:

> Nicolas Pitre wrote:
> > On Mon, 26 Nov 2007, David Kastrup wrote:
> > 
> >> Nicolas Pitre <nico@cam.org> writes:
> >> 
> >>> [ I get really really annoyed when your replies to me aren't directly 
> >>>   addressed to me, Jakub.  Told you so repeatedly in the past as well.
> >>>   Why are you the only one on this list apparently not able to use a 
> >>>   proper email setup? ]
> 
> Nevertheless, mails are sent to git mailing list, so they should go to 
> you too.

It was already explained (not often enough?) that some people are 
extremely busy, such as Nicolas.

Therefore, they have to prioritise.

If you choose to be ignored, that's fine by me ;-)

Ciao,
Dscho

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

[Nicolas Pitre]

On Mon, 26 Nov 2007, Johannes Schindelin wrote:

> On Mon, 26 Nov 2007, Jakub Narebski wrote:
> 
> > Nevertheless, mails are sent to git mailing list, so they should go to 
> > you too.
> 
> It was already explained (not often enough?) that some people are 
> extremely busy, such as Nicolas.
> 
> Therefore, they have to prioritise.
> 
> If you choose to be ignored, that's fine by me ;-)

I hate when I miss on followups to my own posts though.  
That is the real issue.


Nicolas

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

[Nicolas Pitre]

On Mon, 26 Nov 2007, David Kastrup wrote:

> Without so much as a bounce message or delivery report, there is nothing
> to apply one's brightness to.

Maybe you could try firing up your web browser and directing it at 
http://vger.kernel.org, just in case there might be a web page set up 
there with some clues.  Hey, there is actually a web page there.

In particular, there is a link there that reads as "Email delivery 
testing tool: mxverify".  Did you try it?

There is another link with "TABOO in the lists".  Maybe you might find 
something there?


Nicolas

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

[David Kastrup]

Nicolas Pitre <nico@cam.org> writes:

> On Mon, 26 Nov 2007, David Kastrup wrote:
>
>> Without so much as a bounce message or delivery report, there is nothing
>> to apply one's brightness to.
>
> Maybe you could try firing up your web browser and directing it at 
> http://vger.kernel.org, just in case there might be a web page set up 
> there with some clues.  Hey, there is actually a web page there.

I really _love_ how the default response on this list for any problem is
to treat one as an idiot and openly show one's contempt.  The
information about subscribing to the mailing list can be found at the
Git home page at <URL:http://git.or.cz/#community>.  It does not mention
anything like a mailing list home page.  Only the archives are
mentioned, and those contain no pointer whatsoever.  It does remind me
of the late Douglas Adams' Hitchhiker's guide to the galaxy:

    `...You hadn't exactly gone out of your way to call attention to
    them had you? I mean like actually telling anyone or anything.'
    `But the plans were on display...'
    `On display? I eventually had to go down to the cellar to find
     them.'
    `That's the display department.'
    `With a torch.'
    `Ah, well the lights had probably gone.'
    `So had the stairs.'
    `But look you found the notice didn't you?'
    `Yes,' said Arthur, `yes I did. It was on display in the bottom of a
     locked filing cabinet stuck in a disused lavatory with a sign on the
     door saying "Beware of The Leopard".'

Anyway, with your pointer I might be able to work through the stuff and
figure out what makes vger so unique here as a mailing list host.

On the other hand: why bother participating in a community that turns
openly hostile whenever one experiences problems?  Where is the fun in
that?  That one will at one point of time be in the situation to lambast
others for their shortcomings, and feel that one is entirely in-style
doing so here?

Is it really impossible to proffer any information without a denigrating
sneer?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Nicolas Pitre]

On Tue, 27 Nov 2007, David Kastrup wrote:

> On the other hand: why bother participating in a community that turns
> openly hostile whenever one experiences problems?  Where is the fun in
> that?  That one will at one point of time be in the situation to lambast
> others for their shortcomings, and feel that one is entirely in-style
> doing so here?

David, honestly, my problem with you is that you seem to be the only one 
having such relational problems around here, and instead of doing some 
homework and obvious guessing on your own to save everyone's nerves, you 
instead write dissertations about the list hostility, etc.  Which in 
turns will obviously earn you more hostilities.

Please get a grip.


Nicolas

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

[David Kastrup]

Nicolas Pitre <nico@cam.org> writes:

> On Tue, 27 Nov 2007, David Kastrup wrote:
>
>> On the other hand: why bother participating in a community that turns
>> openly hostile whenever one experiences problems?  Where is the fun in
>> that?  That one will at one point of time be in the situation to lambast
>> others for their shortcomings, and feel that one is entirely in-style
>> doing so here?
>
> David, honestly, my problem with you is that you seem to be the only one 
> having such relational problems around here,

I am the only one?  I quote from your reply to my original contribution
in this thread:

>On Mon, 26 Nov 2007, David Kastrup wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>> 
>> > [ I get really really annoyed when your replies to me aren't directly 
>> >   addressed to me, Jakub.  Told you so repeatedly in the past as well.
>> >   Why are you the only one on this list apparently not able to use a 
>> >   proper email setup? ]
>> 
>> X-Injected-Via-Gmane: http://gmane.org/
>> 
>> And Jakub by far is not the only one using gmane for reading and writing
>> to the list.
>
>It is strange, though, that Jakub is the only one I've noticed who isn't 
>able to do me the courtesy of addressing me directly when replying to 
>me.

So here you are telling Jakub off as discourteous and the "only one on
this list apparently not able to use a proper email setup".  And when I
explain that I have been in the same situation with a different account
of mine and that this has nothing to do with discourtesy, the heat turns
over to me.

And, again, this is declared an absolutely isolated phenomenon
restricted to a single person.

I am afraid that I am too stupid to understand what goal is supposed to
be achieved by this sort of behavior.  I don't see anything except
annoyance for everybody involved.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Nicolas Pitre]

On Tue, 27 Nov 2007, David Kastrup wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > David, honestly, my problem with you is that you seem to be the only one 
> > having such relational problems around here,
> 
> I am the only one?  I quote from your reply to my original contribution
> in this thread:
> 
> >On Mon, 26 Nov 2007, David Kastrup wrote:
> >
> >> Nicolas Pitre <nico@cam.org> writes:
> >> 
> >> > [ I get really really annoyed when your replies to me aren't directly 
> >> >   addressed to me, Jakub.  Told you so repeatedly in the past as well.
> >> >   Why are you the only one on this list apparently not able to use a 
> >> >   proper email setup? ]
> >> 
> >> X-Injected-Via-Gmane: http://gmane.org/
> >> 
> >> And Jakub by far is not the only one using gmane for reading and writing
> >> to the list.
> >
> >It is strange, though, that Jakub is the only one I've noticed who isn't 
> >able to do me the courtesy of addressing me directly when replying to 
> >me.
> 
> So here you are telling Jakub off as discourteous and the "only one on
> this list apparently not able to use a proper email setup".

Exact.

> And when I explain that I have been in the same situation with a 
> different account of mine and that this has nothing to do with 
> discourtesy, the heat turns over to me.

Then it must be laziness.  And while Jakub admits there is a problem, 
you insist otherwise, building hostility towards you in the process.

> And, again, this is declared an absolutely isolated phenomenon
> restricted to a single person.

OK now you are two.  So what?  This still looks like a tiny minority to 
me.

> I am afraid that I am too stupid to understand what goal is supposed to
> be achieved by this sort of behavior.  I don't see anything except
> annoyance for everybody involved.

You are really annoying indeed.


Nicolas

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

[しらいしななこ]

Quoting Andreas Ericsson <ae@op5.se>:

> "git pull --rebase" already has an implementation. Dscho cooked one up
> which I've been using since then. It works nicely.

What is the reason that the option was not added to the official git?  Was it coded poorly, buggy or were there some other issues?

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

----------------------------------------------------------------------
Find out how you can get spam free email.
http://www.bluebottle.com/tag/3

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

[Jakub Narebski]

On Tue, 27 Nov 2007, しらいしななこ (Nanako Shiraishi) napisał:
> Quoting Andreas Ericsson <ae@op5.se>:
> 
>> "git pull --rebase" already has an implementation. Dscho cooked one up
>> which I've been using since then. It works nicely.
> 
> What is the reason that the option was not added to the official git?
> Was it coded poorly, buggy or were there some other issues? 

There was no main (feature) git release since?

-- 
Jakub Narebski
Poland

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

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 775 bytes --]

Hi,

On Tue, 27 Nov 2007, しらいしななこ wrote:

> Quoting Andreas Ericsson <ae@op5.se>:
> 
> > "git pull --rebase" already has an implementation. Dscho cooked one up
> > which I've been using since then. It works nicely.
> 
> What is the reason that the option was not added to the official git?  
> Was it coded poorly, buggy or were there some other issues?

It is very well possible that it was coded poorly ;-)

The main reason, I believe, was that some old-timers who know the 
implications said that it would encourage a wrong workflow.  One thing 
that could go possibly wrong, for example, is to rebase commits that you 
already published.

So AFAICT it was deemed not only giving people rope, but making that rope 
look like a necklace to them.

Ciao,
Dscho

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

[Andreas Ericsson]

Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 27 Nov 2007, しらいしななこ wrote:
> 
>> Quoting Andreas Ericsson <ae@op5.se>:
>>
>>> "git pull --rebase" already has an implementation. Dscho cooked one up
>>> which I've been using since then. It works nicely.
>> What is the reason that the option was not added to the official git?  
>> Was it coded poorly, buggy or were there some other issues?
> 
> It is very well possible that it was coded poorly ;-)
> 
> The main reason, I believe, was that some old-timers who know the 
> implications said that it would encourage a wrong workflow.


If by "wrong", those old-timers meant "a workflow not commonly used
in a published one-pushes-many-pulls repository", I certainly agree.


>  One thing 
> that could go possibly wrong, for example, is to rebase commits that you 
> already published.
> 

For the vast majority of git users, that's a non-issue as "published" is
usually defined as "pushed to the publicly advertised watering hole".

Yes, I'm aware that git is distributed. That doesn't mean that it's not
convenient to have one single place where all code meant to be released
eventually ends up.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Johannes Schindelin]

Hi,

On Tue, 27 Nov 2007, Andreas Ericsson wrote:

> Johannes Schindelin wrote:
> 
> >  One thing that could go possibly wrong, for example, is to rebase 
> > commits that you already published.
> 
> For the vast majority of git users, that's a non-issue as "published" is 
> usually defined as "pushed to the publicly advertised watering hole".

No.  This is only the "vast majority of git users told by their peers to 
use a central repository".

Just because you use git like cvs does not mean that you "use git".

> Yes, I'm aware that git is distributed. That doesn't mean that it's not 
> convenient to have one single place where all code meant to be released 
> eventually ends up.

It may be convenient for you.  I do not like it.  Yes, I even made the 
mistake with msysGit.  In the end, it would have been much more 
intelligent to set up a repository which others would have had to fork 
from.

Ciao,
Dscho

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

[Nicolas Pitre]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1280 bytes --]

On Tue, 27 Nov 2007, Johannes Schindelin wrote:

> Hi,
> 
> On Tue, 27 Nov 2007, しらいしななこ wrote:
> 
> > Was it coded poorly, buggy or were there some other issues?
> 
> It is very well possible that it was coded poorly ;-)
> 
> The main reason, I believe, was that some old-timers who know the 
> implications said that it would encourage a wrong workflow.  One thing 
> that could go possibly wrong, for example, is to rebase commits that you 
> already published.

Being much more involved in the maintenance of a published Git tree 
lately, I must disagree with the "wrong workflow" statement.  Until the 
stuff I maintain is finally merged upstream, I have to constantly 
amend/replace/fold/split random commits in my repo to follow the review 
cycles involved.  yet I have to publish the result to let others base 
their work on top of my latest tree.  A fetch+rebase is the only option 
for those following my tree, and I made it clear that they have to 
rebase after a fetch because I constantly rebase commits that I have 
already published myself.

And in this case, constant rebasing is a perfectly fine work flow to me. 
Otherwise I might just use Git as a glorified tarball downloader and use 
quilt on top, but this is somehow not as appealing.


Nicolas

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

[J. Bruce Fields]

On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote:
> On Tue, 27 Nov 2007, Johannes Schindelin wrote:
> 
> > Hi,
> > 
> > On Tue, 27 Nov 2007, しらいしななこ wrote:
> > 
> > > Was it coded poorly, buggy or were there some other issues?
> > 
> > It is very well possible that it was coded poorly ;-)
> > 
> > The main reason, I believe, was that some old-timers who know the 
> > implications said that it would encourage a wrong workflow.  One thing 
> > that could go possibly wrong, for example, is to rebase commits that you 
> > already published.
> 
> Being much more involved in the maintenance of a published Git tree 
> lately, I must disagree with the "wrong workflow" statement.  Until the 
> stuff I maintain is finally merged upstream, I have to constantly 
> amend/replace/fold/split random commits in my repo to follow the review 
> cycles involved.  yet I have to publish the result to let others base 
> their work on top of my latest tree.  A fetch+rebase is the only option 
> for those following my tree, and I made it clear that they have to 
> rebase after a fetch because I constantly rebase commits that I have 
> already published myself.

Right.  But a rebase "merge strategy" doesn't work for those people,
because it's not possible in general for their git to know exactly which
part is their work (which needs to be rebased) and which is your old
work (which should be discarded).  Manual inspection is required.

> And in this case, constant rebasing is a perfectly fine work flow to me. 

Again, if you have people basing work on top of yours, I think the best
option may really be to add a merge commit on top of each new version of
the series with first parent the new series and second parent the
previous history.

That way the history does have the information necessary to rebase their
work automatically.

--b.

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

[Andreas Ericsson]

Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 27 Nov 2007, Andreas Ericsson wrote:
> 
>> Johannes Schindelin wrote:
>>
>>>  One thing that could go possibly wrong, for example, is to rebase 
>>> commits that you already published.
>> For the vast majority of git users, that's a non-issue as "published" is 
>> usually defined as "pushed to the publicly advertised watering hole".
> 
> No.  This is only the "vast majority of git users told by their peers to 
> use a central repository".
> 


Let me rephrase.
For any project large enough to want to attract random hackers, there
will always be a single repository considered the public "master repo".
For such projects code is most likely considered "published" when the
code hits that repository (or some middle-stage on its way to it).

It has to do with communication and convenience. When the code reaches
that master repo it's no longer easy to communicate the fact that it
has been rebased to everyone it's been published to.


> Just because you use git like cvs does not mean that you "use git".
> 

I suppose Junio and Linus don't "use git" either then, as they're both
in control of at least one such "master repo" each. Ah well. At least
I'm in good company.


>> Yes, I'm aware that git is distributed. That doesn't mean that it's not 
>> convenient to have one single place where all code meant to be released 
>> eventually ends up.
> 
> It may be convenient for you.  I do not like it.


It's not only convenient for me. It's convenient for the tens of thousands
of people working on the Linux kernel to have a single place to go to for
that one repository that somehow fathers all the tarballs.

So long as it's a small group of developers working on something, it's
obviously not necessary to provide such a place, but when you want to
attract the huge anonymous coders that you've never spoken to, you need
a single place to post the latest and greatest.


>  Yes, I even made the 
> mistake with msysGit.  In the end, it would have been much more 
> intelligent to set up a repository which others would have had to fork 
> from.
> 

So? Any new developer wanting to work on it will still try to locate
the public copy of the "master repo" to start their fork from.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Nicolas Pitre]

On Tue, 27 Nov 2007, J. Bruce Fields wrote:

> On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote:
> > Being much more involved in the maintenance of a published Git tree 
> > lately, I must disagree with the "wrong workflow" statement.  Until the 
> > stuff I maintain is finally merged upstream, I have to constantly 
> > amend/replace/fold/split random commits in my repo to follow the review 
> > cycles involved.  yet I have to publish the result to let others base 
> > their work on top of my latest tree.  A fetch+rebase is the only option 
> > for those following my tree, and I made it clear that they have to 
> > rebase after a fetch because I constantly rebase commits that I have 
> > already published myself.
> 
> Right.  But a rebase "merge strategy" doesn't work for those people,
> because it's not possible in general for their git to know exactly which
> part is their work (which needs to be rebased) and which is your old
> work (which should be discarded).  Manual inspection is required.

I don't follow.

Their work is always origin/master@{1}..HEAD after origin/master has 
been updated through a fetch, and it needs to be rebased on 
origin/master.

> > And in this case, constant rebasing is a perfectly fine work flow to me. 
> 
> Again, if you have people basing work on top of yours, I think the best
> option may really be to add a merge commit on top of each new version of
> the series with first parent the new series and second parent the
> previous history.
> 
> That way the history does have the information necessary to rebase their
> work automatically.

And my repo will then be full of clutter which no one upstream will ever 
accept to merge.  Can't do that.


Nicolas

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

[J. Bruce Fields]

On Tue, Nov 27, 2007 at 10:19:53AM -0500, Nicolas Pitre wrote:
> On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> 
> > On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote:
> > > Being much more involved in the maintenance of a published Git tree 
> > > lately, I must disagree with the "wrong workflow" statement.  Until the 
> > > stuff I maintain is finally merged upstream, I have to constantly 
> > > amend/replace/fold/split random commits in my repo to follow the review 
> > > cycles involved.  yet I have to publish the result to let others base 
> > > their work on top of my latest tree.  A fetch+rebase is the only option 
> > > for those following my tree, and I made it clear that they have to 
> > > rebase after a fetch because I constantly rebase commits that I have 
> > > already published myself.
> > 
> > Right.  But a rebase "merge strategy" doesn't work for those people,
> > because it's not possible in general for their git to know exactly which
> > part is their work (which needs to be rebased) and which is your old
> > work (which should be discarded).  Manual inspection is required.
> 
> I don't follow.
> 
> Their work is always origin/master@{1}..HEAD after origin/master has 
> been updated through a fetch, and it needs to be rebased on 
> origin/master.

No, their work isn't always based on origin/master@{1}.  Often they've
got more than one project going.  If they try

	git checkout project-1
	git pull -s rebase
	git checkout project-2
	git pull -s rebase

what's going to happen?  What if project-2 has been on the back burner
for a few months and they're just getting around to rebasing it now?
What if their various projects are based on different upstream branches,
but the fetch done by git-pull updates them all at once?  What if they
did a git fetch earlier just to peek at current development and are only
now getting around to updating their own branches?

And I don't think any of those are crazy corner cases; I know at least
that I do all of those things.

> > Again, if you have people basing work on top of yours, I think the best
> > option may really be to add a merge commit on top of each new version of
> > the series with first parent the new series and second parent the
> > previous history.
> > 
> > That way the history does have the information necessary to rebase their
> > work automatically.
> 
> And my repo will then be full of clutter which no one upstream will ever 
> accept to merge.  Can't do that.

No, it's no problem--you just submit branch^.  You probably want to give
it a throw-away name for the purpose of the request-pull message, e.g.:

	git branch for-linus HEAD^
	git push my-pub-repo for-linus

then delete for-linus after you see it merged.

But use for-linus only for that, and advertise "branch" as the base
people should be using for ongoing development.

I don't know, maybe it's too complicated.  But I think it's the only way
to get a really robust automated process for the people basing work on
your branch.

--b.

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

[Nicolas Pitre]

On Tue, 27 Nov 2007, J. Bruce Fields wrote:

> On Tue, Nov 27, 2007 at 10:19:53AM -0500, Nicolas Pitre wrote:
> > On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> > 
> > > On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote:
> > > > Being much more involved in the maintenance of a published Git tree 
> > > > lately, I must disagree with the "wrong workflow" statement.  Until the 
> > > > stuff I maintain is finally merged upstream, I have to constantly 
> > > > amend/replace/fold/split random commits in my repo to follow the review 
> > > > cycles involved.  yet I have to publish the result to let others base 
> > > > their work on top of my latest tree.  A fetch+rebase is the only option 
> > > > for those following my tree, and I made it clear that they have to 
> > > > rebase after a fetch because I constantly rebase commits that I have 
> > > > already published myself.
> > > 
> > > Right.  But a rebase "merge strategy" doesn't work for those people,
> > > because it's not possible in general for their git to know exactly which
> > > part is their work (which needs to be rebased) and which is your old
> > > work (which should be discarded).  Manual inspection is required.
> > 
> > I don't follow.
> > 
> > Their work is always origin/master@{1}..HEAD after origin/master has 
> > been updated through a fetch, and it needs to be rebased on 
> > origin/master.
> 
> No, their work isn't always based on origin/master@{1}.  Often they've
> got more than one project going.  If they try
> 
> 	git checkout project-1
> 	git pull -s rebase
> 	git checkout project-2
> 	git pull -s rebase
> 
> what's going to happen?  What if project-2 has been on the back burner
> for a few months and they're just getting around to rebasing it now?

I don't see the problem.  They'll just have a possibly harder rebase due 
to increased chances for conflicts than if they rebased more often, but 
that's to be expected even with a merge.

> What if their various projects are based on different upstream branches,
> but the fetch done by git-pull updates them all at once?
>  What if they
> did a git fetch earlier just to peek at current development and are only
> now getting around to updating their own branches?

You are not _forced_ to use origin/master@{1} in that case -- I used 
that notation only to illustrate the concept in Git terms.  What I tell 
people to do is to tag their new base after the rebase is done, and to 
use that tag after the next fetch to rebase again.

I honnestly don't use such a tag myself because I think I know what I'm 
doing when using Git, and therefore I know when origin/master@{1} refers 
to what I really want.  But the point is that either that usage of 
origin/master@{1}, or a dedicated tag, or whatever other means to 
retrieve the previous base, could be handled implicitly by the porcelain 
and the user wouldn't have to care as much.

Thinking about it, there should be a way to find the proper base even 
without explicitly recording it with a tag.  If it isn't 
origin/master@{1}, it has to be the first of origin/master@{n} for
n = [1, ...] reachable from the local work branch before rebasing.

> And I don't think any of those are crazy corner cases; I know at least
> that I do all of those things.

Sure.  In which case you certainly fall into the "know what you're 
doing" category too and certainly can find your way towards the proper 
base ref to use.  But again I think that can be automated.

> > > Again, if you have people basing work on top of yours, I think the best
> > > option may really be to add a merge commit on top of each new version of
> > > the series with first parent the new series and second parent the
> > > previous history.
> > > 
> > > That way the history does have the information necessary to rebase their
> > > work automatically.
> > 
> > And my repo will then be full of clutter which no one upstream will ever 
> > accept to merge.  Can't do that.
> 
> No, it's no problem--you just submit branch^.  You probably want to give
> it a throw-away name for the purpose of the request-pull message, e.g.:
> 
> 	git branch for-linus HEAD^
> 	git push my-pub-repo for-linus
> 
> then delete for-linus after you see it merged.
> 
> But use for-linus only for that, and advertise "branch" as the base
> people should be using for ongoing development.
> 
> I don't know, maybe it's too complicated.  But I think it's the only way
> to get a really robust automated process for the people basing work on
> your branch.

It just looks too twisted for my taste when proper automatic rebase 
without extra artifacts should be possible.


Nicolas

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

[J. Bruce Fields]

On Tue, Nov 27, 2007 at 11:14:47AM -0500, Nicolas Pitre wrote:
> On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> > No, their work isn't always based on origin/master@{1}.  Often they've
> > got more than one project going.  If they try
> > 
> > 	git checkout project-1
> > 	git pull -s rebase
> > 	git checkout project-2
> > 	git pull -s rebase
> > 
> > what's going to happen?  What if project-2 has been on the back burner
> > for a few months and they're just getting around to rebasing it now?
> 
> I don't see the problem.  They'll just have a possibly harder rebase due 
> to increased chances for conflicts than if they rebased more often, but 
> that's to be expected even with a merge.

Well, fair enough.  It can be much worse than a merge, though--consider
what happens when upstream drops a commit, or replaces a patch by
another patch (or patches) that solves the problem in a different way.

> > What if their various projects are based on different upstream branches,
> > but the fetch done by git-pull updates them all at once?
> >  What if they
> > did a git fetch earlier just to peek at current development and are only
> > now getting around to updating their own branches?
> 
> You are not _forced_ to use origin/master@{1} in that case -- I used 
> that notation only to illustrate the concept in Git terms.  What I tell 
> people to do is to tag their new base after the rebase is done, and to 
> use that tag after the next fetch to rebase again.

That's fine, but it's not an automated process any more.

> I honnestly don't use such a tag myself because I think I know what I'm 
> doing when using Git, and therefore I know when origin/master@{1} refers 
> to what I really want.  But the point is that either that usage of 
> origin/master@{1}, or a dedicated tag, or whatever other means to 
> retrieve the previous base, could be handled implicitly by the porcelain 
> and the user wouldn't have to care as much.

OK, so you're imagining a version of "git pull -s rebase" that also
allows specifying the previous base of your series?  What would the
syntax be?  You could do something like stg does and keep extra
information under .git that records the base of each "patch series".
Then you have to figure out how to manage that information and how it
should interact with the varoius branch management commands.

> Thinking about it, there should be a way to find the proper base even 
> without explicitly recording it with a tag.  If it isn't 
> origin/master@{1}, it has to be the first of origin/master@{n} for
> n = [1, ...] reachable from the local work branch before rebasing.

That'll work in some cases.  You're almost using the reflog as another
piece of history to find the "real" merge-base.

That's a little fragile, since reflogs aren't quite "real" history.  It
doesn't work reliably in the "project that was put on the back burner"
case (because the reflog entries may have expired).  It doesn't work if
work is done in multiple repositories.

> > And I don't think any of those are crazy corner cases; I know at least
> > that I do all of those things.
> 
> Sure.  In which case you certainly fall into the "know what you're 
> doing" category too and certainly can find your way towards the proper 
> base ref to use.

Beginners are will try those things too, so we'd have to explain the
limitations up front.

> But again I think that can be automated.

I'd want to see the algorithm spelled out, and a very convincing
description of exactly which cases it handles.

My other objection is that "rebase" just isn't a merge strategy.  I
think of a merge strategy takes some HEADs in a produces a single merge
commit that connects them.

If we really want a fetch+rebase script, OK, but call it something other
than pull.

--b.

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

[Johannes Schindelin]

Hi,

On Tue, 27 Nov 2007, J. Bruce Fields wrote:

> If we really want a fetch+rebase script, OK, but call it something other 
> than pull.

Why?  pull = fetch + merge only because that was the originally envisioned 
way to pull remote changes into your local working tree.  However, I do 
not see why we should be married to pull being a fetch and a merge for 
eternity.

Ciao,
Dscho

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

[J. Bruce Fields]

On Tue, Nov 27, 2007 at 04:54:18PM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> 
> > If we really want a fetch+rebase script, OK, but call it something other 
> > than pull.
> 
> Why?  pull = fetch + merge only because that was the originally envisioned 
> way to pull remote changes into your local working tree.  However, I do 
> not see why we should be married to pull being a fetch and a merge for 
> eternity.

Two responses:

First, OK, if you want to say "pull" means "fetch something and then
incorporate it somehow into your current branch", that doesn't bother me
quite as much as saying that "pull" always means "fetch + merge", and
that "rebase" is really just a special kind of merge.  It's clearly not
a merge.

Second: "fetch+rebase" will really have very different properties from
"fetch+pull".  It may be possible to make the former behave a little
like the latter in some common cases, but it's going to complicated.
And a lot of git-pull documentation is going to end up with clauses like
"...except if you're running pull in 'rebase' mode, in which case...".
Better to keep the two cases as separate operations with separate syntax
and man pages.  (But share where it makes sense--e.g. any syntax and
documentation of fetch part should be shared.)

--b.

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

[Junio C Hamano]

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

> On Tue, 27 Nov 2007, しらいしななこ wrote:
>
>> Quoting Andreas Ericsson <ae@op5.se>:
>> 
>> > "git pull --rebase" already has an implementation. Dscho cooked one up
>> > which I've been using since then. It works nicely.
>> 
>> What is the reason that the option was not added to the official git?  
>> Was it coded poorly, buggy or were there some other issues?
>
> It is very well possible that it was coded poorly ;-)
>
> The main reason, I believe, was that some old-timers who know the 
> implications said that it would encourage a wrong workflow.  One thing 
> that could go possibly wrong, for example, is to rebase commits that you 
> already published.
>
> So AFAICT it was deemed not only giving people rope, but making that rope 
> look like a necklace to them.

Hmph, that is different from how I remember, and the "workflow" argument
would not be something I would make if we were having that discussion
today.

I think what happened was that we took a misguided detour to make this
an option to "git merge" (which was _my_ mistake IIRC, sorry), which did
not pan out well (because rebase is not "a different form of merge").
After that for some reason we failed to follow-up on the topic.  We
could have gone back to the original "a pull is integrating following a
fetch, and the integration does not have to be merge" approach to see if
it was workable, but we didn't.

If people find it useful, I do not think of a huge reason to object to
the inclusion.  "Give them rope" is good ;-)

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

[Nicolas Pitre]

On Tue, 27 Nov 2007, J. Bruce Fields wrote:

> On Tue, Nov 27, 2007 at 11:14:47AM -0500, Nicolas Pitre wrote:
> > On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> > > No, their work isn't always based on origin/master@{1}.  Often they've
> > > got more than one project going.  If they try
> > > 
> > > 	git checkout project-1
> > > 	git pull -s rebase
> > > 	git checkout project-2
> > > 	git pull -s rebase
> > > 
> > > what's going to happen?  What if project-2 has been on the back burner
> > > for a few months and they're just getting around to rebasing it now?
> > 
> > I don't see the problem.  They'll just have a possibly harder rebase due 
> > to increased chances for conflicts than if they rebased more often, but 
> > that's to be expected even with a merge.
> 
> Well, fair enough.  It can be much worse than a merge, though--consider
> what happens when upstream drops a commit, or replaces a patch by
> another patch (or patches) that solves the problem in a different way.

That's the whole point for the need to rebase.  To others I'm currently 
upstream and I do the above all the time. So I don't see the issue.

> > > What if their various projects are based on different upstream branches,
> > > but the fetch done by git-pull updates them all at once?
> > >  What if they
> > > did a git fetch earlier just to peek at current development and are only
> > > now getting around to updating their own branches?
> > 
> > You are not _forced_ to use origin/master@{1} in that case -- I used 
> > that notation only to illustrate the concept in Git terms.  What I tell 
> > people to do is to tag their new base after the rebase is done, and to 
> > use that tag after the next fetch to rebase again.
> 
> That's fine, but it's not an automated process any more.

Indeed.  I never claimed it was automated, but I'm rather deploring it.

> > I honnestly don't use such a tag myself because I think I know what I'm 
> > doing when using Git, and therefore I know when origin/master@{1} refers 
> > to what I really want.  But the point is that either that usage of 
> > origin/master@{1}, or a dedicated tag, or whatever other means to 
> > retrieve the previous base, could be handled implicitly by the porcelain 
> > and the user wouldn't have to care as much.
> 
> OK, so you're imagining a version of "git pull -s rebase" that also
> allows specifying the previous base of your series?  What would the
> syntax be?  You could do something like stg does and keep extra
> information under .git that records the base of each "patch series".
> Then you have to figure out how to manage that information and how it
> should interact with the varoius branch management commands.

... which is IMHO the best reason to find a solution that doesn't need 
extra information to be kept.

> > Thinking about it, there should be a way to find the proper base even 
> > without explicitly recording it with a tag.  If it isn't 
> > origin/master@{1}, it has to be the first of origin/master@{n} for
> > n = [1, ...] reachable from the local work branch before rebasing.
> 
> That'll work in some cases.  You're almost using the reflog as another
> piece of history to find the "real" merge-base.

Sure.  Since it is there, why not use it?

> That's a little fragile, since reflogs aren't quite "real" history.  It
> doesn't work reliably in the "project that was put on the back burner"
> case (because the reflog entries may have expired).

Tough.

Maybe reflogs should always preserve a minimum of x entries by default 
even if they are older than the expiration threshold.

But practically speaking, if you've been sitting on your work for so 
long and you've pruned your reflog then you should always be able to 
look up your branch history and find the first commit which isn't yours, 
then use its ID explicitly. And if you forgot enough about that work of 
yours so not to be able to determine that base commit then I probably 
don't want to trust you anyway.  :-)

> It doesn't work if
> work is done in multiple repositories.

Hmmm... would have to think a bit more about that, but it never was a 
real issue to me so far.

> > > And I don't think any of those are crazy corner cases; I know at least
> > > that I do all of those things.
> > 
> > Sure.  In which case you certainly fall into the "know what you're 
> > doing" category too and certainly can find your way towards the proper 
> > base ref to use.
> 
> Beginners are will try those things too, so we'd have to explain the
> limitations up front.

Sure.  Yet a bunch of Git beginners are doing just well so far with the 
rather terse instructions I provided for manually rebasing their work 
when using my repo.  So that must not be that bad.

> > But again I think that can be automated.
> 
> I'd want to see the algorithm spelled out, and a very convincing
> description of exactly which cases it handles.
> 
> My other objection is that "rebase" just isn't a merge strategy.  I
> think of a merge strategy takes some HEADs in a produces a single merge
> commit that connects them.
> 
> If we really want a fetch+rebase script, OK, but call it something other
> than pull.

I absolutely agree. Anyway, the Git "pull" is my own most hated command. 
I always considered it has strange semantics hiding too much of what is 
actually going on, using an artificial concept probably borrowed from BK 
to justify its existence.  In all the tutorials for $job I've done so 
far, I simply never talk about pull nor clone, but rather about init, 
"git remote", fetch and merge, with explicit and meaningful branch 
names.  I think that basic commands, even if there is a bit more of 
them, make Git easier to learn and understand than talking about those 
magic meta commands hiding the truth away. But hey, this is only my own 
opinion, and after all I'm the one having to deal with those $job people 
in the end.


Nicolas

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

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1821 bytes --]

Hi,

On Tue, 27 Nov 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Tue, 27 Nov 2007, しらいしななこ wrote:
> >
> >> Quoting Andreas Ericsson <ae@op5.se>:
> >> 
> >> > "git pull --rebase" already has an implementation. Dscho cooked one up
> >> > which I've been using since then. It works nicely.
> >> 
> >> What is the reason that the option was not added to the official git?  
> >> Was it coded poorly, buggy or were there some other issues?
> >
> > It is very well possible that it was coded poorly ;-)
> >
> > The main reason, I believe, was that some old-timers who know the 
> > implications said that it would encourage a wrong workflow.  One thing 
> > that could go possibly wrong, for example, is to rebase commits that you 
> > already published.
> >
> > So AFAICT it was deemed not only giving people rope, but making that rope 
> > look like a necklace to them.
> 
> Hmph, that is different from how I remember, and the "workflow" argument
> would not be something I would make if we were having that discussion
> today.
> 
> I think what happened was that we took a misguided detour to make this
> an option to "git merge" (which was _my_ mistake IIRC, sorry), which did
> not pan out well (because rebase is not "a different form of merge").
> After that for some reason we failed to follow-up on the topic.  We
> could have gone back to the original "a pull is integrating following a
> fetch, and the integration does not have to be merge" approach to see if
> it was workable, but we didn't.
> 
> If people find it useful, I do not think of a huge reason to object to
> the inclusion.  "Give them rope" is good ;-)

FWIW the my last reply in that thread was 
http://thread.gmane.org/gmane.comp.version-control.git/62382/focus=62405

Ciao,
Dscho

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

[Andreas Ericsson]

J. Bruce Fields wrote:
> On Tue, Nov 27, 2007 at 04:54:18PM +0000, Johannes Schindelin wrote:
>> Hi,
>>
>> On Tue, 27 Nov 2007, J. Bruce Fields wrote:
>>
>>> If we really want a fetch+rebase script, OK, but call it something other 
>>> than pull.
>> Why?  pull = fetch + merge only because that was the originally envisioned 
>> way to pull remote changes into your local working tree.  However, I do 
>> not see why we should be married to pull being a fetch and a merge for 
>> eternity.
> 
> Two responses:
> 
> First, OK, if you want to say "pull" means "fetch something and then
> incorporate it somehow into your current branch", that doesn't bother me
> quite as much as saying that "pull" always means "fetch + merge", and
> that "rebase" is really just a special kind of merge.  It's clearly not
> a merge.
> 

I beg to differ. The end result is identical to a merge (assuming one
never does "git rebase skip", which otoh could be thought of as one way
of resolving a merge conflict). It's just history that doesn't turn out
the same. git has always been about content, so from that pov, a rebase
is exactly the same as a merge.


> Second: "fetch+rebase" will really have very different properties from
> "fetch+pull".

"fetch+merge", no?

>  It may be possible to make the former behave a little
> like the latter in some common cases, but it's going to complicated.


True. I don't think octopus rebase needs to be supported, for example.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> ...  In all the tutorials for $job I've done so 
> far, I simply never talk about pull nor clone, but rather about init, 
> "git remote", fetch and merge, with explicit and meaningful branch 
> names.  I think that basic commands, even if there is a bit more of 
> them, make Git easier to learn and understand than talking about those 
> magic meta commands hiding the truth away.

That's actually a quite interesting approach for teaching.

The original "tutorial" (now core-tutorial) was similar in spirit; it
built the user experience by starting at sequence of low level commands,
and then finally said "since this is so often used combination, there is
a short-hand for it that does all".  I think the approach would work
quite well for people who want to use the tool with deep understanding.

However, I am not so sure about people who just want canned set of
instructions and follow them blindly to get their work done.  And I do
not think the latter classes of users are necessarily wrong.

Such a canned set of instructions would (if the project that supplies
the cheat-sheet encourages merges instead of rebases) talk about "clone
then commit then push then pull and repeat", without mentioning what
pull does is fetch+merge nor what fetch means and what merge means, and
that would let people get started without deeper understanding.

But the lack of deeper understanding would hurt them in the longer run
(e.g. "my push was rejected with something called non-fast-forward ---
what does that mean and what would I do now?").  

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

[J. Bruce Fields]

On Wed, Nov 28, 2007 at 05:00:15PM -0800, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
> 
> > ...  In all the tutorials for $job I've done so 
> > far, I simply never talk about pull nor clone, but rather about init, 
> > "git remote", fetch and merge, with explicit and meaningful branch 
> > names.  I think that basic commands, even if there is a bit more of 
> > them, make Git easier to learn and understand than talking about those 
> > magic meta commands hiding the truth away.
> 
> That's actually a quite interesting approach for teaching.
> 
> The original "tutorial" (now core-tutorial) was similar in spirit; it
> built the user experience by starting at sequence of low level commands,
> and then finally said "since this is so often used combination, there is
> a short-hand for it that does all".  I think the approach would work
> quite well for people who want to use the tool with deep understanding.

Yeah.  I considered doing the above some time ago and ran into some
differences between git-clone and "git init && git remote add && git
fetch"--I think it may have just been that the latter didn't guess the
HEAD in the same way.  That's fixed now, right?  Is there any other
difference people would run into?  If not, I'll work on that.  I
wouldn't want to break things down quite as far as the core-tutorial,
but this particular thing is so simple....

--b.

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

[Junio C Hamano]

"J. Bruce Fields" <bfields@fieldses.org> writes:

> Yeah.  I considered doing the above some time ago and ran into some
> differences between git-clone and "git init && git remote add && git
> fetch"--I think it may have just been that the latter didn't guess the
> HEAD in the same way.  That's fixed now, right?

"git remote add" by itself does not talk with remote, so unless you let
it do the initial fetch it is not fixable (and no, "git remote add -f"
currently does not do the guesswork either).

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

[Johan Herland]

On Thursday 29 November 2007, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
> > ...  In all the tutorials for $job I've done so 
> > far, I simply never talk about pull nor clone, but rather about init, 
> > "git remote", fetch and merge, with explicit and meaningful branch 
> > names.  I think that basic commands, even if there is a bit more of 
> > them, make Git easier to learn and understand than talking about those 
> > magic meta commands hiding the truth away.
> 
> That's actually a quite interesting approach for teaching.
> 
> The original "tutorial" (now core-tutorial) was similar in spirit; it
> built the user experience by starting at sequence of low level commands,
> and then finally said "since this is so often used combination, there is
> a short-hand for it that does all".  I think the approach would work
> quite well for people who want to use the tool with deep understanding.
> 
> However, I am not so sure about people who just want canned set of
> instructions and follow them blindly to get their work done.  And I do
> not think the latter classes of users are necessarily wrong.
> 
> Such a canned set of instructions would (if the project that supplies
> the cheat-sheet encourages merges instead of rebases) talk about "clone
> then commit then push then pull and repeat", without mentioning what
> pull does is fetch+merge nor what fetch means and what merge means, and
> that would let people get started without deeper understanding.
> 
> But the lack of deeper understanding would hurt them in the longer run
> (e.g. "my push was rejected with something called non-fast-forward ---
> what does that mean and what would I do now?").  

What about ending the cheat-sheet with a big fat link to a FAQ? The FAQ 
answers common questions like the above (resulting from the cheat-sheet 
glossing over the details) with links to appropriate sections in the more 
thorough introduction (core-tutorial), explaining what's _really_ going on.

Just a thought.


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

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

[Nicolas Pitre]

On Wed, 28 Nov 2007, Junio C Hamano wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > ...  In all the tutorials for $job I've done so 
> > far, I simply never talk about pull nor clone, but rather about init, 
> > "git remote", fetch and merge, with explicit and meaningful branch 
> > names.  I think that basic commands, even if there is a bit more of 
> > them, make Git easier to learn and understand than talking about those 
> > magic meta commands hiding the truth away.
> 
> That's actually a quite interesting approach for teaching.
> 
> The original "tutorial" (now core-tutorial) was similar in spirit; it
> built the user experience by starting at sequence of low level commands,
> and then finally said "since this is so often used combination, there is
> a short-hand for it that does all".  I think the approach would work
> quite well for people who want to use the tool with deep understanding.
> 
> However, I am not so sure about people who just want canned set of
> instructions and follow them blindly to get their work done.  And I do
> not think the latter classes of users are necessarily wrong.
> 
> Such a canned set of instructions would (if the project that supplies
> the cheat-sheet encourages merges instead of rebases) talk about "clone
> then commit then push then pull and repeat", without mentioning what
> pull does is fetch+merge nor what fetch means and what merge means, and
> that would let people get started without deeper understanding.

Sure.  However the people for whom I produced the cheat-sheet have to 
deal with the repo I maintain, which has multiple branches already, and 
using an explicit "git remote add" allows for better names than the 
default "origin".  Right there they become aware of the easy branching 
possibilities of Git.

And with a constantly rewritten history in that repo, they have to 
rebase after every fetch and there is no released Git version with a 
short-hand for fetch+rebase.


Nicolas

What's cooking in git.git (topics)

[Junio C Hamano]

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

----------------------------------------------------------------
[Graduated to 'master']

* jk/maint-cvsimport-fix (Wed Nov 28 13:56:28 2007 -0500)

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

* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit
 - Start preparing the API documents.

The primary reason of this series is because I think we made the system
a lot less approachable by losing hackability.  Although we still have
sample scripts in contrib/example for use of plumbing in scripts, they
will not help aspiring git-hacker-wannabees when our primary attention
has already shifted to moving things to C.

This currently consists of mostly stubs, although I wrote about a few
topics as examples.

* js/fast-export (Sun Nov 25 22:37:20 2007 +0100) 1 commit
 - Add 'git fast-export', the sister of 'git fast-import'

This needs something like 9e42d6a1c53dadd409fab11cc76e0eba9ec15365
(sha1_file.c: Fix size_t related printf format warnings) to compile, I
think, but I haven't tried to fix it (parked in pu)

* js/pull-rebase (Wed Nov 28 13:11:07 2007 +0000) 1 commit
 + Teach 'git pull' about --rebase

Resurrected from an old thread (thanks, Dscho and Nana for reminding).

* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
 + Support builtin aliases

Cute hack.  I'd like to have "git less" here.

* wc/rebase-insn (Sat Nov 24 00:38:50 2007 +1100) 2 commits
 + Mention that git-rm can be an appropriate resolution as well as
   git-add.
 + revert/cherry-pick: Allow overriding the help text by the calling
   Porcelain

Patches from Wincent and David Symonds.  They both improve the help
message upon conflicts.

* js/prune-expire (Thu Nov 29 20:59:55 2007 +0000) 1 commit
 + Add "--expire <time>" option to 'git prune'

This would help making unmonitored pruning jobs safer.  The expiration
does not kick in unless you explicitly ask, which is a suitable default
for interactive session where the users who run "git prune" knows what
they are doing.

* ew/svn (Thu Nov 22 13:44:42 2007 +0000) 4 commits
 - git-svn: add support for pulling author from From: and Signed-off-
   by:
 - git-svn: add a show-externals command.
 - git-svn now reads settings even if called in subdirectory
 - git-svn: Remove unnecessary Git::SVN::Util package

Picked up from the list with Eric's Acks, but haven't merged, as my next
pull from Eric would hopefully bring them in anyway.

* mw/cvsserver (Fri Nov 23 04:12:54 2007 -0500) 1 commit
 - git-cvsserver runs hooks/post-receive

Queue in 'pu', but lacks a corresponding support for hooks/post-update,
which we haven't declared deprecation.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

I think this is a sane thing to do in the longer term.  Will be in
'next' after v1.5.4.  I think "leave porcelain on PATH" might be also a
good thing as a transition measure, but not strictly necessary.  If we
were to do so, I'd like to see a patch that consolidates the knowledge
of what's Porcelain and what's common in one place before that.
Currently:

 (1) generate-cmdlist.sh has its own built-in list for common command
     names to be used in "git help";

 (2) Documentation/cmd-list.perl has more comprehensive classification to
     generate git(7) manpage and git.html.  It needs to also know what's
     deprecated.

 (3) contrib/completion/git-completion.bash has a list of "uncommon
     commands", commands not to be shown to the user.

which is a mess.  I think a good approach would be to separate the
command list part from Documentation/cmd-list.perl script and move it to
the toplevel, and have these three read from it.  Maybe git-help command
can learn "--classify" option to show that command list with
classification, so that git-completion.bash and other scripts can use it
without hardcoding the command list in.

Incidentally, if we do not install dashed form of built-ins anywhere
(which is not this series is about --- this is just moving them out of
user's PATH), "git help -a" will stop showing them.  I am not enthused
about removing the hardlinks to built-ins to begin with, but people who
want such a change need to first modify help.c:list_commands() to pick
up builtins without having git-foo hardlinks in gitexecdir.  This may
need to happen anyway as mingw fallouts, though ;-).

* jc/color (Tue Nov 27 22:41:05 2007 -0800) 2 commits
 + git-config --get-color: get configured color
 + "color.diff = true" is not "always" anymore.

Hopefully Dan's colored "git add -i" can rebuild on top of these.

* js/dashless (Fri Nov 30 12:08:20 2007 +0000) 1 commit
 - transport.c: call dash-less form of receive-pack and upload-pack
   on remote

Not field tested by anybody nor came with any tests, but this is an
important component to move git-foo commands out of user's PATH.

* dc/gitweb (Mon Nov 26 20:42:06 2007 +0800) 1 commit
 - gitweb: the commitdiff is very commonly used, it's needed on
   search page, too

Queue in 'pu', waiting for Acks from gitweb guys.

* jc/docmake-perl (Fri Nov 30 15:48:17 2007 -0800) 1 commit
 - Run the specified perl in Documentation/

Queue in 'pu', waiting for Ack from Merlyn.

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

* cr/tag-options (Sun Nov 25 23:50:58 2007 -0500) 4 commits
 + git-tag: test that -s implies an annotated tag
 + "git-tag -s" should create a signed annotated tag
 + builtin-tag: accept and process multiple -m just like git-commit
 + Make builtin-tag.c use parse_options.

Will merge to 'master' over the weekend.

* jc/branch-contains (Sun Nov 18 22:22:00 2007 -0800) 3 commits
 + git-branch --contains: doc and test
 + git-branch --contains=commit
 + parse-options: Allow to hide options from the default usage.

Contains Pierre's "hidable options with --help-all" patch.
Will merge to 'master' over the weekend.

* jc/move-gitk (Sat Nov 17 10:51:16 2007 -0800) 1 commit
 + Move gitk to its own subdirectory

I have a phoney Makefile under the subdirectory for gitk, but
hopefully with the next pull from Paulus I can replace it with
the real thing, along with the i18n stuff.
Will merge to 'master' over the weekend.

* js/rebase-i-rerere (Thu Nov 22 11:18:10 2007 +0000) 1 commit
 + rebase -i: give rerere a chance

I haven't seen rerere kick in since I merged this to 'next' (which I
almost always run).  Success stories?

* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits
 + Remove hint to use "git help -a"
 + Make the list of common commands more exclusive

Some people on the list may find the exact list of commands
somewhat debatable.

* kh/commit (Wed Nov 28 22:13:08 2007 +0100) 27 commits
 + Do not generate full commit log message if it is not going to be
   used
 + Remove git-status from list of scripts as it is builtin
 + Fix off-by-one error when truncating the diff out of the commit
   message.
 + builtin-commit.c: export GIT_INDEX_FILE for launch_editor as well.
 + Add a few more tests for git-commit
 + builtin-commit: Include the diff in the commit message when
   verbose.
 + builtin-commit: fix partial-commit support
 + Fix add_files_to_cache() to take pathspec, not user specified list
   of files
 + Export three helper functions from ls-files
 + builtin-commit: run commit-msg hook with correct message file
 + builtin-commit: do not color status output shown in the message
   template
 + file_exists(): dangling symlinks do exist
 + Replace "runstatus" with "status" in the tests
 + t7501-commit: Add test for git commit <file> with dirty index.
 + builtin-commit: Clean up an unused variable and a debug fprintf().
 + Call refresh_cache() when updating the user index for --only
   commits.
 + builtin-commit: Add newline when showing which commit was created
 + builtin-commit: resurrect behavior for multiple -m options
 + builtin-commit --s: add a newline if the last line was not a S-o-b
 + builtin-commit: fix --signoff
 + git status: show relative paths when run in a subdirectory
 + builtin-commit: Refresh cache after adding files.
 + builtin-commit: fix reflog message generation
 + launch_editor(): read the file, even when EDITOR=:
 + Port git commit to C.
 + Export launch_editor() and make it accept ':' as a no-op editor.
 + Add testcase for amending and fixing author in git commit.

Now comes with a few more fixes since the last issue of "What's in".
This should be production ready, but commit is so central, so let's wait
a bit longer until the bugfixes completely stop flowing in.  The
earliest will be next Wednesday.

* js/export-with-assignment (Wed Nov 28 15:56:11 2007 +0000) 1 commit
 + Replace instances of export VAR=VAL with VAR=VAL; export VAR

This will make scripts easier to read for traditionalists (that's me), at
the same time working around a bug in BSD ash where VAL is word split if
you write "export VAR=VAL".

----------------------------------------------------------------
[Actively cooking]

* jc/spht (Sat Nov 24 11:57:41 2007 -0800) 6 commits
 + core.whitespace: documentation updates.
 + builtin-apply: teach whitespace_rules
 + builtin-apply: rename "whitespace" variables and fix styles
 + core.whitespace: add test for diff whitespace error highlighting
 + git-diff: complain about >=8 consecutive spaces in initial indent
 + War on whitespace: first, a bit of retreat.

Now apply also knows about the customizable definition of what
whitespace breakages are, and I was reasonably happy. But Bruce kicked
it back from "scheduled to merge" to "still cooking" status, reminding
that we would want to have this not a tree-wide configuration but
per-path attribute.  And I agree with him.

* wc/add-i (Thu Nov 29 13:00:38 2007 +0100) 32 commits
 + Highlight keyboard shortcuts in git-add--interactive
 + Document all help keys in "git add -i" patch mode.
 + Add "--patch" option to git-add--interactive
 + add -i: Fix running from a subdirectory
 + builtin-add: fix command line building to call interactive
 + Merge branch 'kh/commit' into wc/add-i
 + Add a few more tests for git-commit
 + git-add -i: allow multiple selection in patch subcommand
 + builtin-commit: Include the diff in the commit message when
   verbose.
 + builtin-commit: fix partial-commit support
 + Fix add_files_to_cache() to take pathspec, not user specified list
   of files
 + Export three helper functions from ls-files
 + builtin-commit: run commit-msg hook with correct message file
 + builtin-commit: do not color status output shown in the message
   template
 + file_exists(): dangling symlinks do exist
 + Replace "runstatus" with "status" in the tests
 + t7501-commit: Add test for git commit <file> with dirty index.
 + builtin-commit: Clean up an unused variable and a debug fprintf().
 + Call refresh_cache() when updating the user index for --only
   commits.
 + builtin-commit: Add newline when showing which commit was created
 + builtin-commit: resurrect behavior for multiple -m options
 + builtin-commit --s: add a newline if the last line was not a S-o-b
 + builtin-commit: fix --signoff
 + git status: show relative paths when run in a subdirectory
 + builtin-commit: Refresh cache after adding files.
 + builtin-commit: fix reflog message generation
 + launch_editor(): read the file, even when EDITOR=:
 + Port git commit to C.
 + Export launch_editor() and make it accept ':' as a no-op editor.
 + Add testcase for amending and fixing author in git commit.
 + Add path-limiting to git-add--interactive
 + Teach builtin-add to pass multiple paths to git-add--interactive

This looks larger than it really is, as I merged in the builtin commit
series near the tip (they interact with each other somewhat, and it is
very likely that builtin commit series will graduate to 'master' before
this series).

* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
 + refactor fetch's ref matching to use refname_match()
 + push: use same rules as git-rev-parse to resolve refspecs
 + add refname_match()
 + push: support pushing HEAD to real branch name

I think the "git push HEAD" is a good change, and also using the same
short refname resolving as rev-parse does for matching the destination
of push.  I am having second thoughts on the last one.  The changed
semantics is somewhat less safe:

    * We did not allow fetching outside refs/ (except HEAD), but now we
      allow any random string.

    * We used to restrict fetching names that do not begin with refs/ to
      heads, tags and remotes, but now the code grabs anything underneath
      refs/.

which could invite mistakes by letting typos slip through.

Having said that, I probably "fetch" much less often than other people
do and these may be non issues in the real-world usecases.  It could be
that I am worried too much needlessly.  If anybody who is following
'next' has been bitten by the change, please speak up.

* nd/maint-work-tree-fix (Thu Nov 29 19:21:39 2007 +0700) 2 commits
 + Do check_repository_format() early
 + Add missing inside_work_tree setting in setup_git_directory_gently

The tip one needs test script.

----------------------------------------------------------------
[Stalled]

I've dropped a few topics that did not see actions recently.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
 - Added diff hunk coloring to git-add--interactive
 - Let git-add--interactive read colors from .gitconfig
 - Added basic color support to git add --interactive

There were many good suggestions by Jeff to the updated series;
hopefully we can have replacements of these three that incorporate
Jeff's suggestions, and build on the "git-config --get-color" series.

* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
 - Making ce_path_match() more useful by accepting globs

This was to allow "git diff-files -- '*.h'" (currently diff family
knows only the leading directory match and not fileglobs), but was shot
down by Alex.  I tend to agree with him.

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

[Eric Wong]

Junio C Hamano <gitster@pobox.com> wrote:
> * ew/svn (Thu Nov 22 13:44:42 2007 +0000) 4 commits
>  - git-svn: add support for pulling author from From: and Signed-off-
>    by:
>  - git-svn: add a show-externals command.
>  - git-svn now reads settings even if called in subdirectory
>  - git-svn: Remove unnecessary Git::SVN::Util package
> 
> Picked up from the list with Eric's Acks, but haven't merged, as my next
> pull from Eric would hopefully bring them in anyway.

Hi,

I've pushed the following out to git://git.bogomips.org/git-svn.git ,
along with Steven's patch:

Andy Whitcroft (1):
      git-svn: add support for pulling author from From: and Signed-off-by:

David D. Kilzer (1):
      git-svn: Remove unnecessary Git::SVN::Util package

Gustaf Hendeby (1):
      git-svn now reads settings even if called in subdirectory

Steven Grimm (1):
      git-svn: Don't create a "master" branch every time rebase is run

Vineet Kumar (1):
      git-svn: add a show-externals command.


-- 
Eric Wong

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

[Johannes Schindelin]

Hi,

On Fri, 30 Nov 2007, Junio C Hamano wrote:

> * js/dashless (Fri Nov 30 12:08:20 2007 +0000) 1 commit
>  - transport.c: call dash-less form of receive-pack and upload-pack
>    on remote
> 
> Not field tested by anybody nor came with any tests, but this is an
> important component to move git-foo commands out of user's PATH.

Please scratch that.  It does not work, and what it should fix is better 
done by your 3/3.

Ciao,
Dscho

What's cooking in git.git (topics)

[Junio C Hamano]

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

----------------------------------------------------------------
[Graduated to 'master']

* cr/tag-options (Sun Nov 25 23:50:58 2007 -0500) 4 commits
* jc/branch-contains (Sun Nov 18 22:22:00 2007 -0800) 3 commits
* jc/move-gitk (Sat Nov 17 10:51:16 2007 -0800) 1 commit
* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits
* jc/color (Tue Nov 27 22:41:05 2007 -0800) 2 commits

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

* cc/help (Tue Dec 4 06:44:29 2007 +0100) 2 commits
 + Documentation: describe -i/--info option to "git-help"
 + git-help: add -i|--info option to display info page.

There are two additional patches I didn't queue for -w (web) in this
series.

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

* jc/docmake-perl (Fri Nov 30 18:36:34 2007 -0800) 1 commit
 + Run the specified perl in Documentation/

Tired of waiting for Ack from Merlyn, I merged this to 'next'.

* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
 + refactor fetch's ref matching to use refname_match()
 + push: use same rules as git-rev-parse to resolve refspecs
 + add refname_match()
 + push: support pushing HEAD to real branch name

The last one changes the semantics to somewhat less safe:

    * We did not allow fetching outside refs/ (except HEAD), but now we
      allow any random string.

    * We used to restrict fetching names that do not begin with refs/ to
      heads, tags and remotes, but now the code grabs anything underneath
      refs/.

which could invite mistakes by letting typos slip through, but I won't
be a good judge, as I probably "fetch" much less often than other people
do and these may be non issues in the real-world usecases.  It could be
that I am worried too much needlessly.  If anybody who is following
'next' has been bitten by the change, please speak up.  Otherwise this
will go in soon.

* kh/commit (Mon Dec 3 00:03:10 2007 -0800) 33 commits
 + git-commit --allow-empty
 + git-commit: Allow to amend a merge commit that does not change the
   tree
 + quote_path: fix collapsing of relative paths
 + Make git status usage say git status instead of git commit
 + Fix --signoff in builtin-commit differently.
 + git-commit: clean up die messages
 + Do not generate full commit log message if it is not going to be
   used
 + Remove git-status from list of scripts as it is builtin
 + Fix off-by-one error when truncating the diff out of the commit
   message.
 + builtin-commit.c: export GIT_INDEX_FILE for launch_editor as well.
 + Add a few more tests for git-commit
 + builtin-commit: Include the diff in the commit message when
   verbose.
 + builtin-commit: fix partial-commit support
 + Fix add_files_to_cache() to take pathspec, not user specified list
   of files
 + Export three helper functions from ls-files
 + builtin-commit: run commit-msg hook with correct message file
 + builtin-commit: do not color status output shown in the message
   template
 + file_exists(): dangling symlinks do exist
 + Replace "runstatus" with "status" in the tests
 + t7501-commit: Add test for git commit <file> with dirty index.
 + builtin-commit: Clean up an unused variable and a debug fprintf().
 + Call refresh_cache() when updating the user index for --only
   commits.
 + builtin-commit: Add newline when showing which commit was created
 + builtin-commit: resurrect behavior for multiple -m options
 + builtin-commit --s: add a newline if the last line was not a S-o-b
 + builtin-commit: fix --signoff
 + git status: show relative paths when run in a subdirectory
 + builtin-commit: Refresh cache after adding files.
 + builtin-commit: fix reflog message generation
 + launch_editor(): read the file, even when EDITOR=:
 + Port git commit to C.
 + Export launch_editor() and make it accept ':' as a no-op editor.
 + Add testcase for amending and fixing author in git commit.

This should be production ready, but commit is so central, so let's wait
a bit longer until the bugfixes completely stop flowing in.  The
earliest will be next Wednesday.

* wc/add-i (Mon Dec 3 09:09:43 2007 +0100) 34 commits
 + git-add -i: add help text for list-and-choose UI
 + add -i: allow prefix highlighting for "Add untracked" as well.
 + Highlight keyboard shortcuts in git-add--interactive
 + Document all help keys in "git add -i" patch mode.
 + Add "--patch" option to git-add--interactive
 + add -i: Fix running from a subdirectory
 + builtin-add: fix command line building to call interactive
 + Merge branch 'kh/commit' into wc/add-i
 + Add a few more tests for git-commit
 + git-add -i: allow multiple selection in patch subcommand
 + builtin-commit: Include the diff in the commit message when
   verbose.
 + builtin-commit: fix partial-commit support
 + Fix add_files_to_cache() to take pathspec, not user specified list
   of files
 + Export three helper functions from ls-files
 + builtin-commit: run commit-msg hook with correct message file
 + builtin-commit: do not color status output shown in the message
   template
 + file_exists(): dangling symlinks do exist
 + Replace "runstatus" with "status" in the tests
 + t7501-commit: Add test for git commit <file> with dirty index.
 + builtin-commit: Clean up an unused variable and a debug fprintf().
 + Call refresh_cache() when updating the user index for --only
   commits.
 + builtin-commit: Add newline when showing which commit was created
 + builtin-commit: resurrect behavior for multiple -m options
 + builtin-commit --s: add a newline if the last line was not a S-o-b
 + builtin-commit: fix --signoff
 + git status: show relative paths when run in a subdirectory
 + builtin-commit: Refresh cache after adding files.
 + builtin-commit: fix reflog message generation
 + launch_editor(): read the file, even when EDITOR=:
 + Port git commit to C.
 + Export launch_editor() and make it accept ':' as a no-op editor.
 + Add testcase for amending and fixing author in git commit.
 + Add path-limiting to git-add--interactive
 + Teach builtin-add to pass multiple paths to git-add--interactive

This looks larger than it really is, as I merged in the builtin commit
series near the tip (they interact with each other somewhat).  Will
merge to 'master' along with the "commit in C" series above.

----------------------------------------------------------------
[Actively cooking]

* jc/spht (Sat Nov 24 11:57:41 2007 -0800) 6 commits
 + core.whitespace: documentation updates.
 + builtin-apply: teach whitespace_rules
 + builtin-apply: rename "whitespace" variables and fix styles
 + core.whitespace: add test for diff whitespace error highlighting
 + git-diff: complain about >=8 consecutive spaces in initial indent
 + War on whitespace: first, a bit of retreat.

Now apply also knows about the customizable definition of what
whitespace breakages are, and I was reasonably happy. But Bruce kicked
it back from "scheduled to merge" to "still cooking" status, reminding
that we would want to have this not a tree-wide configuration but
per-path attribute.  And I agree with him.

* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit
 - Start preparing the API documents.

The primary reason of this series is because I think we made the system
a lot less approachable by losing hackability.  Although we still have
sample scripts in contrib/example for use of plumbing in scripts, they
will not help aspiring git-hacker-wannabees when our primary attention
has already shifted to moving things to C.

This currently consists of mostly stubs, although I wrote about a few
topics as examples.

* nd/maint-work-tree-fix (Thu Nov 29 19:21:39 2007 +0700) 2 commits
 + Do check_repository_format() early
 + Add missing inside_work_tree setting in setup_git_directory_gently

The tip one needs test script.

* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
 + Support builtin aliases

Cute hack.  I'd like to have "git less" here.

----------------------------------------------------------------
[Stalled]

* 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, so these are not strictly necessary.

* mw/cvsserver (Fri Nov 23 04:12:54 2007 -0500) 1 commit
 - git-cvsserver runs hooks/post-receive

Queue in 'pu', but lacks a corresponding support for hooks/post-update,
which we haven't declared deprecation.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

I think this is a sane thing to do in the longer term.  Will be in
'next' after v1.5.4.  I think "leave porcelain on PATH" might be also a
good thing as a transition measure.

Incidentally, if we do not install dashed form of built-ins anywhere
(which is not this series is about --- this is just moving them out of
user's PATH), "git help -a" will stop showing them.  I am not enthused
about removing the hardlinks to built-ins to begin with, but people who
want such a change need to first modify help.c:list_commands() to pick
up builtins without having git-foo hardlinks in gitexecdir.  This may
need to happen anyway as mingw fallouts, though ;-).

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
 . Added diff hunk coloring to git-add--interactive
 . Let git-add--interactive read colors from .gitconfig
 . Added basic color support to git add --interactive

There were many good suggestions by Jeff to the updated series;
hopefully we can have replacements of these three that incorporate
Jeff's suggestions, and build on the "git-config --get-color" series.

* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
 - Making ce_path_match() more useful by accepting globs

This was to allow "git diff-files -- '*.h'" (currently diff family
knows only the leading directory match and not fileglobs), but was shot
down by Alex.  I tend to agree with him.

* 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.

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 . merge-nu: a new merge backend without using unpack_trees()
 . read_tree: take an explicit index structure
 . gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
 . revert/cherry-pick: start refactoring call to merge_recursive

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

[Johannes Sixt]

Junio C Hamano schrieb:
> * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
>  + refactor fetch's ref matching to use refname_match()
>  + push: use same rules as git-rev-parse to resolve refspecs
>  + add refname_match()
>  + push: support pushing HEAD to real branch name
> 
> The last one changes the semantics to somewhat less safe:
> 
>     * We did not allow fetching outside refs/ (except HEAD), but now we
>       allow any random string.
> 
>     * We used to restrict fetching names that do not begin with refs/ to
>       heads, tags and remotes, but now the code grabs anything underneath
>       refs/.
> 
> which could invite mistakes by letting typos slip through, but I won't
> be a good judge, as I probably "fetch" much less often than other people
> do and these may be non issues in the real-world usecases.  It could be
> that I am worried too much needlessly.  If anybody who is following
> 'next' has been bitten by the change, please speak up.  Otherwise this
> will go in soon.

Forks on repo.or.cz use the namespace refs/forkee that lists everything that 
the forkee has below refs/. So this change might indeed be annoying. (But 
I'm not using next, so I can't tell, yet.)

> Incidentally, if we do not install dashed form of built-ins anywhere
> (which is not this series is about --- this is just moving them out of
> user's PATH), "git help -a" will stop showing them.  I am not enthused
> about removing the hardlinks to built-ins to begin with, but people who
> want such a change need to first modify help.c:list_commands() to pick
> up builtins without having git-foo hardlinks in gitexecdir.  This may
> need to happen anyway as mingw fallouts, though ;-).

Heh. 'git help -a' currently shows nothing. But it has nothing to do with 
hardlinks. It's because the test for the executable bit fails :-(

BTW, we do use hardlinks on Windows; even the MsysGit installer creates them 
(as long as the filesystem is NTFS). So, the fallout you are 
expecting/hoping for will not be in the first round of MinGW port patches. ;)

-- Hannes

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

[Brian Downing]

On Fri, Nov 30, 2007 at 06:37:52PM -0800, Junio C Hamano wrote:
> * jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit
>  - Start preparing the API documents.
> 
> The primary reason of this series is because I think we made the system
> a lot less approachable by losing hackability.  Although we still have
> sample scripts in contrib/example for use of plumbing in scripts, they
> will not help aspiring git-hacker-wannabees when our primary attention
> has already shifted to moving things to C.
> 
> This currently consists of mostly stubs, although I wrote about a few
> topics as examples.

One comment on this:

+sometype *ary;
+int nr;
+int alloc
+
+for (i = 0; i < nr; i++)
+	if (you like ary[i])
+		return;
+/* you did not like any existing one, so add one */
+ALLOC_GROW(ary, nr+1, alloc);
+ary[nr++] = value you like;

Shouldn't we be encouraging the use of size_t here?  I don't know of a
64-bit platform off hand that has an 'int' that's actually 64 bits, so
encouraging this just seems like asking for 64-bit platform limitations
when arrays get over 2GB.

(Looking through the code it looks like there's a fair bit of using
'int' for array indices already, but I think it's probably best not to
perpetuate that.)

-bcd

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

[Steffen Prohaska]

On Dec 4, 2007, at 10:40 AM, Johannes Sixt wrote:

> Junio C Hamano schrieb:
>> * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
>>  + refactor fetch's ref matching to use refname_match()
>>  + push: use same rules as git-rev-parse to resolve refspecs
>>  + add refname_match()
>>  + push: support pushing HEAD to real branch name
>> The last one changes the semantics to somewhat less safe:
>>     * We did not allow fetching outside refs/ (except HEAD), but  
>> now we
>>       allow any random string.
>>     * We used to restrict fetching names that do not begin with  
>> refs/ to
>>       heads, tags and remotes, but now the code grabs anything  
>> underneath
>>       refs/.
>> which could invite mistakes by letting typos slip through, but I  
>> won't
>> be a good judge, as I probably "fetch" much less often than other  
>> people
>> do and these may be non issues in the real-world usecases.  It  
>> could be
>> that I am worried too much needlessly.  If anybody who is following
>> 'next' has been bitten by the change, please speak up.  Otherwise  
>> this
>> will go in soon.
>
> Forks on repo.or.cz use the namespace refs/forkee that lists  
> everything that the forkee has below refs/. So this change might  
> indeed be annoying. (But I'm not using next, so I can't tell, yet.)

But only if you accidentally wrote

    git fetch forkee/heads/something

instead of

    git fetch heads/something

which I don't think is a very likely typo.

With the last change, fetch still requires a match of the full
refspec created by prefixing a short refspec with "refs/".
Different from the old behaviour, it does no longer verify
that the short refspec from the command line starts with
heads, tags, or remotes.  However, it does _not_ recurse
into "sub-directories" to find a matching ref.  It won't
recurse into forkee, unless you explicitly tell fetch to look
in forkee.  With the old implementation you'd have to say
"refs/forkee/heads/something", while the new implementation
would also accept "forkee/heads/something".

	Steffen

What's cooking in git.git (topics)

[Junio C Hamano]

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

----------------------------------------------------------------
[Graduated to 'master']

* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
* kh/commit (Mon Dec 3 00:03:10 2007 -0800) 33 commits
* wc/add-i (Mon Dec 3 09:09:43 2007 +0100) 34 commits

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

* jc/addi-color (Wed Dec 5 00:50:23 2007 -0800) 1 commit
 - Color support for "git-add -i"

This is Dan Zwell's colorized interactive add.  I'll wait for an ack
from Dan and will merge this to 'next', will merge by v1.5.4-rc0.

* ns/checkout-push-pop (Wed Dec 5 07:04:06 2007 +0900) 1 commit
 - git-checkout --push/--pop

A reasonably cleanly written cute hack, and I do not see this breaking
the normal codepath, so I do not mind merging this as long as people
find it useful.

* jc/clean-fix (Tue Dec 4 23:55:41 2007 -0800) 1 commit
 - git-clean: Honor pathspec.

This does fix limited test cases I tried, but I didn't check the
directory related options at all.  Sanity checking appreciated.  We need
a regression fix before v1.5.4

* jc/git-log-doc (Thu Nov 1 15:57:40 2007 +0100) 1 commit
 - Include diff options in the git-log manpage

Rewrote Miklos's patch rather extensively.  Need to be in v1.5.4.

* jc/am-fix (Tue Dec 4 23:01:30 2007 -0800) 1 commit
 - git-am -i: report rewritten title

Microfix for a UI glitch noticed by Jeff Garzik.
Will merge before v1.5.4-rc0.

* pr/mergetool (Wed Dec 5 09:19:13 2007 +0200) 1 commit
 - Open external merge tool with original file extensions for all
   three files

Waiting for Ted's Ack but I think this is safe.  Will merge before v1.5.4-rc0.

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

* jc/docmake-perl (Fri Nov 30 18:36:34 2007 -0800) 1 commit
 + Run the specified perl in Documentation/

Still waiting for Ack from Merlyn, but will merge before v1.5.4-rc0 anyway.

* kh/fetch-optparse (Tue Dec 4 02:25:47 2007 -0500) 1 commit
 + Rewrite builtin-fetch option parsing to use parse_options().

I need to re-read the patch just to make sure, but will merge before
v1.5.4-rc0.

----------------------------------------------------------------
[Actively cooking]

* cc/help (Sun Dec 2 06:08:00 2007 +0100) 4 commits
 - Use {web,instaweb,help}.browser config options.
 - git-help: add -w|--web option to display html man page in a
   browser.
 + Documentation: describe -i/--info option to "git-help"
 + git-help: add -i|--info option to display info page.

I haven't really read the two commits near the tip.  Comments and
nitpics are appreciated.  Nice to have in v1.5.4.

* mw/cvsserver (Wed Dec 5 01:15:01 2007 -0800) 2 commits
 - git-cvsserver runs hooks/post-update
 - git-cvsserver runs hooks/post-receive

I added the missing support for hooks/post-update; will wait for an Ack
from Michael and merge to 'next'.  Nice to have in v1.5.4.

* jc/spht (Sat Nov 24 11:57:41 2007 -0800) 6 commits
 + core.whitespace: documentation updates.
 + builtin-apply: teach whitespace_rules
 + builtin-apply: rename "whitespace" variables and fix styles
 + core.whitespace: add test for diff whitespace error highlighting
 + git-diff: complain about >=8 consecutive spaces in initial indent
 + War on whitespace: first, a bit of retreat.

Now apply also knows about the customizable definition of what
whitespace breakages are, and I was reasonably happy. But Bruce kicked
it back from "scheduled to merge" to "still cooking" status, reminding
that we would want to have this not a tree-wide configuration but
per-path attribute.  And I agree with him.

Bruce volunteered to tackle the gitattributes side.  Nice to have in
v1.5.4.

* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit
 - Start preparing the API documents.

The primary reason of this series is because I think we made the system
a lot less approachable by losing hackability.  Although we still have
sample scripts in contrib/example for use of plumbing in scripts, they
will not help aspiring git-hacker-wannabees when our primary attention
has already shifted to moving things to C.

This currently consists of mostly stubs, although I wrote about a few
topics as examples.  Nice to have in v1.5.4.

* nd/maint-work-tree-fix (Thu Nov 29 19:21:39 2007 +0700) 2 commits
 + Do check_repository_format() early
 + Add missing inside_work_tree setting in setup_git_directory_gently

The tip one needs test script.

* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
 + Support builtin aliases

Cute hack.  I'd like to have "git less" here.

----------------------------------------------------------------
[Stalled]

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

I think this is a sane thing to do in the longer term.  Will be in
'next' after v1.5.4.  I think "leave porcelain on PATH" might be also a
good thing as a transition measure.

Incidentally, if we do not install dashed form of built-ins anywhere
(which is not this series is about --- this is just moving them out of
user's PATH), "git help -a" will stop showing them.  I am not enthused
about removing the hardlinks to built-ins to begin with, but people who
want such a change need to first modify help.c:list_commands() to pick
up builtins without having git-foo hardlinks in gitexecdir.  This may
need to happen anyway as mingw fallouts, though ;-).

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* 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, so these are not strictly necessary.

* 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.

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 - merge-nu: a new merge backend without using unpack_trees()
 - read_tree: take an explicit index structure
 - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
 - revert/cherry-pick: start refactoring call to merge_recursive

* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
 - Making ce_path_match() more useful by accepting globs

This was to allow "git diff-files -- '*.h'" (currently diff family
knows only the leading directory match and not fileglobs), but was shot
down by Alex.  I tend to agree with him.

* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
 . Added diff hunk coloring to git-add--interactive
 . Let git-add--interactive read colors from .gitconfig
 . Added basic color support to git add --interactive

I'd drop this series (still parked in 'offcuts' that is 'even outside
than pu') once I hear back from Dan.

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

[Jakub Narebski]

Junio C Hamano wrote:

> * ns/checkout-push-pop (Wed Dec 5 07:04:06 2007 +0900) 1 commit
>  - git-checkout --push/--pop
> 
> A reasonably cleanly written cute hack, and I do not see this breaking
> the normal codepath, so I do not mind merging this as long as people
> find it useful.

I like it, although I probably would create and use 'pushb' and 'popb'
aliases, with analogy to 'pushd' and 'popd'.

I don't remember if there is a way to list this "branch stack"...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Jakub Narebski]

Junio C Hamano wrote:

> * jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
>  + Support builtin aliases
> 
> Cute hack.  I'd like to have "git less" here.

I guess that "git whatchanged" can be implemented also as builtin alias.

BTW. now that "git show" can be used on blobs, is "git less" really
that needed?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Miles Bader]

Nicolas Pitre <nico@cam.org> writes:
> Yet Junio just replied to my mail, apparently using his news reader, and 
> I was directly addressed.

If you're using Gnus as a MUA, and reading via gmane, you can bypass
gmane for followups by setting the group "To List" parameter to the list
address ("git@vger.kernel.org"); be careful _not_ to set the adjacent
"To Address" parameter, which does something else.

After doing that, followups are sent via email with To and CCs correctly
set up, exactly as if you were reading an ordinary mailing list.

I presume other newsreaders having something similar.

-Miles

[You can hit C-M-a in the group summary buffer to modify group parameters]

-- 
`Life is a boundless sea of bitterness'

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

[Jeff King]

On Wed, Dec 05, 2007 at 02:59:16AM -0800, Junio C Hamano wrote:

> * jc/clean-fix (Tue Dec 4 23:55:41 2007 -0800) 1 commit
>  - git-clean: Honor pathspec.
> 
> This does fix limited test cases I tried, but I didn't check the
> directory related options at all.  Sanity checking appreciated.  We need
> a regression fix before v1.5.4

Hrm, I took a look at this and I'm a bit stumped.

I think the logic in builtin-clean is a bit suspect, and I have a patch
below that fixes it.

However, I still can't get something as simple as:

  mkdir dir.clean &&
  touch dir.clean/file &&
  git clean -d "*.clean/"

to work, and I think the pathspec matching is to blame. If I use
"*.clean/", then read_directory assumes that "*.clean" is a directory to
be opened, without considering that it might be a wildcard, which is
just wrong. If I use "*.clean", then I get the correct directory
listing, but match_pathspec fails because read_directory returns
"dir.clean/". We could fix this by passing match_pathspec ent->len - 1,
but that actually ends up getting ignored! It ends up handing the string
to fnmatch, which treats it like a C string.

Am I crazy, or do we need to fix the wildcard semantics for directories
with both read_directory and with match_pathspec?

Below is my partial patch for reference.

-Peff

---
diff --git a/builtin-clean.c b/builtin-clean.c
index 61ae851..f4cf39f 100644
--- a/builtin-clean.c
+++ b/builtin-clean.c
@@ -117,7 +117,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
 		}
 
 		if (!lstat(ent->name, &st) && (S_ISDIR(st.st_mode))) {
-			int matched_path = 0;
+			int matched_path = !pathspec;
 			strbuf_addstr(&directory, ent->name);
 			if (pathspec) {
 				/*
@@ -128,11 +128,11 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
 						   baselen, seen))
 					matched_path = 1;
 			}
-			if (show_only && (remove_directories || matched_path)) {
+			if (show_only && (remove_directories && matched_path)) {
 				printf("Would remove %s\n", directory.buf);
-			} else if (quiet && (remove_directories || matched_path)) {
+			} else if (quiet && (remove_directories && matched_path)) {
 				remove_dir_recursively(&directory, 0);
-			} else if (remove_directories || matched_path) {
+			} else if (remove_directories && matched_path) {
 				printf("Removing %s\n", directory.buf);
 				remove_dir_recursively(&directory, 0);
 			} else if (show_only) {
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index dfd1188..f204a50 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -192,6 +192,34 @@ test_expect_success 'git-clean -d src/ examples/' '
 
 '
 
+test_expect_success 'git-clean with directory wildcards' '
+
+	mkdir -p dir.clean dir.stay &&
+	touch dir.clean/file dir.stay/file &&
+	git clean "*.clean" &&
+	test -f Makefile &&
+	test -f README &&
+	test -f src/part1.c &&
+	test -f src/part2.c &&
+	test -f dir.stay/file &&
+	test -f dir.clean/file
+
+'
+
+test_expect_success 'git-clean -d with directory wildcards' '
+
+	mkdir -p dir.clean dir.stay &&
+	touch dir.clean/file dir.stay/file &&
+	git clean -d "*.clean" &&
+	test -f Makefile &&
+	test -f README &&
+	test -f src/part1.c &&
+	test -f src/part2.c &&
+	test -f dir.stay/file &&
+	test ! -f dir.clean/file
+
+'
+
 test_expect_success 'git-clean -x' '
 
 	mkdir -p build docs &&

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

[Jeff King]

On Wed, Dec 05, 2007 at 12:10:04PM +0100, Jakub Narebski wrote:

> Junio C Hamano wrote:
> 
> > * jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
> >  + Support builtin aliases
> > 
> > Cute hack.  I'd like to have "git less" here.
> 
> I guess that "git whatchanged" can be implemented also as builtin alias.

If you are thinking of

  [alias]
    whatchanged = log --raw --full-history

it does not quite work. git-log unconditionally sets --always, and there
is no command line option to turn it off. In most cases you could get an
approximation by using --no-merges, but it would still show commits that
actually have no tree change (there are 2 in git.git).

-Peff

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  Others commits may be stashed in 'offcuts'.

The topics list the commits in reverse chronological order.

----------------------------------------------------------------
[Graduated to 'master']

* jc/clean-fix (Wed Dec 5 22:28:06 2007 -0500) 2 commits

This does fix limited test cases I tried, but the original breakage
around the directory related options are probably still there.

* jc/docmake-perl (Fri Nov 30 18:36:34 2007 -0800) 1 commit

Let's see if I can get a straight answer from Merlyn if this fixes the
issue for him.

* jc/addi-color (Wed Dec 5 22:12:07 2007 -0800) 3 commits

This is Dan Zwell's colorized interactive add.

* jc/git-log-doc (Thu Nov 1 15:57:40 2007 +0100) 1 commit

Rewrote Miklos's patch rather extensively.  Need to be in v1.5.4.

* kh/fetch-optparse (Tue Dec 4 02:25:47 2007 -0500) 1 commit

Makes fetch parameter parser to use optparse.

* mw/cvsserver (Wed Dec 5 01:15:01 2007 -0800) 2 commits

Make cvsserver to call post-update and receive hooks to act more like
receive-pack.

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

* pr/mergetool (Wed Dec 5 09:19:13 2007 +0200) 1 commit
 + Open external merge tool with original file extensions for all
   three files

Waiting for Ted's Ack but I think this is safe.  Hoping to merge before
v1.5.4-rc0.

* jc/spht (Thu Dec 6 00:14:14 2007 -0800) 7 commits
 + Use gitattributes to define per-path whitespace rule
 + core.whitespace: documentation updates.
 + builtin-apply: teach whitespace_rules
 + builtin-apply: rename "whitespace" variables and fix styles
 + core.whitespace: add test for diff whitespace error highlighting
 + git-diff: complain about >=8 consecutive spaces in initial indent
 + War on whitespace: first, a bit of retreat.

This teaches apply and diff about the customizable definition of what
whitespace breakages are, and the customization can be refined per-path
using the attributes mechanism.  It would be to nice to have this in
v1.5.4.

----------------------------------------------------------------
[Actively cooking]

* cc/help (Sun Dec 2 06:08:00 2007 +0100) 4 commits
 - Use {web,instaweb,help}.browser config options.
 - git-help: add -w|--web option to display html man page in a
   browser.
 + Documentation: describe -i/--info option to "git-help"
 + git-help: add -i|--info option to display info page.

Not a must, but would be very nice to have in v1.5.4.

* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit
 - Start preparing the API documents.

The primary reason of this series is because I think we made the system
a lot less approachable by losing hackability.  Although we still have
sample scripts in contrib/example for use of plumbing in scripts, they
will not help aspiring git-hacker-wannabees when our primary attention
has already shifted to moving things to C.

This currently consists of mostly stubs, although I wrote about a few
topics as examples.  Nice to have in v1.5.4.

* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
 + Support builtin aliases

Cute hack.

----------------------------------------------------------------
[On hold]

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

I think this is a sane thing to do in the longer term.  Will be in
'next' after v1.5.4.  I think "leave porcelain on PATH" might be also a
good thing as a transition measure.

Incidentally, if we do not install dashed form of built-ins anywhere
(which is not this series is about --- this is just moving them out of
user's PATH), "git help -a" will stop showing them.  I am not enthused
about removing the hardlinks to built-ins to begin with, but people who
want such a change need to first modify help.c:list_commands() to pick
up builtins without having git-foo hardlinks in gitexecdir.  This may
need to happen anyway as mingw fallouts.

----------------------------------------------------------------
[Stalled]

* ns/checkout-push-pop (Wed Dec 5 07:04:06 2007 +0900) 1 commit
 - git-checkout --push/--pop

A reasonably cleanly written cute hack, and I do not see this breaking
the normal codepath, so I do not mind merging this as long as people
find it useful.

* js/remote (Wed Dec 5 19:02:15 2007 +0000) 4 commits
 - 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

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* 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, so these are not strictly necessary.

* 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.

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 . merge-nu: a new merge backend without using unpack_trees()
 . read_tree: take an explicit index structure
 . gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
 . revert/cherry-pick: start refactoring call to merge_recursive

* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
 - Making ce_path_match() more useful by accepting globs

This was to allow "git diff-files -- '*.h'" (currently diff family
knows only the leading directory match and not fileglobs), but was shot
down by Alex.  I tend to agree with him.

* jc/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
 . Make "diff" Porcelain output paths as relative to subdirectory.

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

[Jakub Narebski]

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

> * pr/mergetool (Wed Dec 5 09:19:13 2007 +0200) 1 commit
>  + Open external merge tool with original file extensions for all
>    three files
> 
> Waiting for Ted's Ack but I think this is safe.  Hoping to merge before
> v1.5.4-rc0.

Nice. I don't think this would break anything. By the way, this would
I think also make Emacs (emerge) choose correct major mode for syntax
highlighting etc., so it is not only for Meld...
 
> * jc/spht (Thu Dec 6 00:14:14 2007 -0800) 7 commits
>  + Use gitattributes to define per-path whitespace rule
>  + core.whitespace: documentation updates.
>  + builtin-apply: teach whitespace_rules
>  + builtin-apply: rename "whitespace" variables and fix styles
>  + core.whitespace: add test for diff whitespace error highlighting
>  + git-diff: complain about >=8 consecutive spaces in initial indent
>  + War on whitespace: first, a bit of retreat.
> 
> This teaches apply and diff about the customizable definition of what
> whitespace breakages are, and the customization can be refined per-path
> using the attributes mechanism.  It would be to nice to have this in
> v1.5.4.

By the way, is there some helper plumbing scripts can use to check
attributes for given file (given pathname), either in working area, or
in repository (I am thinking there to use gitattributes for
configuring syntax highlighting (extension to syntax) in gitweb);
perhaps even in the index.

> * jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
>  + Support builtin aliases
> 
> Cute hack.

By the way, beside "git view" alias (with configurable backend, be it
gitk, qgit, giggle or gitview) it would be nice to have "git unstash"
as an alias to "git stash apply" (it would not matter here that
command think of itself as 'git stash' here).
 
> ----------------------------------------------------------------
> [On hold]
> 
> * nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
>  - Move all dashed-form commands to libexecdir
> 
> I think this is a sane thing to do in the longer term.  Will be in
> 'next' after v1.5.4.  I think "leave porcelain on PATH" might be also a
> good thing as a transition measure.

We would have to change the paragraph in INSTALL about git wrapper
(which would be no longer optional, or at least no longer optional in
the sense that you can just delete/not install this file), and its
conflict with (old) GNU Interactive Tools (the other 'git').
 
> [Stalled]
> 
> * ns/checkout-push-pop (Wed Dec 5 07:04:06 2007 +0900) 1 commit
>  - git-checkout --push/--pop
> 
> A reasonably cleanly written cute hack, and I do not see this breaking
> the normal codepath, so I do not mind merging this as long as people
> find it useful.

That would be nice to have, although as somebody[*1*] said, you usualy
know that you should have pushed branch into stack when you want to
'pop'. So it would be nice to have (if possible and easy to implement)
also "git checkout --previous" or "git checkout -".

Robin Rosenberg wrote about nice hack to implement "cd -" like
behavior:

Robin Rosenberg wrote:
> I abuse git bisect for this temporary switcing. It only gives me a one
> level memory, but otoh the git prompt tells me I'm on a discourse.
>
> [me@lathund GIT (rr/abspath|BISECTING)]$ git checkout master
> Switched to branch "master"
>
> [me@lathund GIT (master|BISECTING)]$ git checkout HEAD~2
> Note: moving to "HEAD~2" which isn't a local branch
> If you want to create a new branch from this checkout, you may do so
> (now or later) by using -b with the checkout command again. Example:
>   git checkout -b <new_branch_name>
> HEAD is now at afcc4f7... Merge branch 'js/prune-expire'
>
> [me@lathund GIT (afcc4f7...|BISECTING)]$ git bisect reset
> Previous HEAD position was afcc4f7... Merge branch 'js/prune-expire'
> Switched to branch "rr/abspath"
> [me@lathund GIT (rr/abspath)]$

[*1*] I'm sorry for no attribution
 
> * 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

What is the status of this thingy, by the way?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> [On hold]
>> 
>> * nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
>>  - Move all dashed-form commands to libexecdir
>> 
>> I think this is a sane thing to do in the longer term.  Will be in
>> 'next' after v1.5.4.  I think "leave porcelain on PATH" might be also a
>> good thing as a transition measure.
>
> We would have to change the paragraph in INSTALL about git wrapper
> (which would be no longer optional, or at least no longer optional in
> the sense that you can just delete/not install this file), and its
> conflict with (old) GNU Interactive Tools (the other 'git').

Thanks for noticing.  Please send in a proposed patch to do so; then
we can park it near the tip of this topic, and nobody will forget.

>> [Stalled]
>> 
>> * ns/checkout-push-pop (Wed Dec 5 07:04:06 2007 +0900) 1 commit
>>  - git-checkout --push/--pop
>> 
>> A reasonably cleanly written cute hack, and I do not see this breaking
>> the normal codepath, so I do not mind merging this as long as people
>> find it useful.
>
> That would be nice to have, although as somebody[*1*] said, you usualy
> know that you should have pushed branch into stack when you want to
> 'pop'. So it would be nice to have (if possible and easy to implement)
> also "git checkout --previous" or "git checkout -".
> ...

Perhaps.  There are a few issues, though.

 * When you were on 'master' and say "co -", you would want to come back
   to the 'master' branch, whose tip may have advanced since you
   switched away from (e.g. "git push . experiment:master"), and that is
   a desired behaviour.  When you switch away from a detached HEAD, what
   would we record?  The fact the head was detached and its commit, so
   next "co -" would come back to that exact commit in a detached state?
   Or "co -" is meant to say "I was distracted and was away but now
   let's go back to my normal working state" and should refrain from
   touching the previous branch information?  I tend to think it would
   be the latter.

 * There are a few commands that are not "git checkout" but still
   switches branches ("rebase that branch on this one" form of rebase
   and "bisect").  Personally, I think bisect should stop using the
   branch 'bisect' but instead work on detached HEAD in the longer run,
   but what would we do about "rebase"?

> [*1*] I'm sorry for no attribution

I think this was Matthieu Moy, <vpqir3de8t6.fsf@bauges.imag.fr>,
http://article.gmane.org/gmane.comp.version-control.git/67133

>> * 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
>
> What is the status of this thingy, by the way?

As the topic group header says, it is [Stalled].

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

[Miklos Vajna]

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

On Fri, Dec 07, 2007 at 01:51:03AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> * jc/git-log-doc (Thu Nov 1 15:57:40 2007 +0100) 1 commit
> 
> Rewrote Miklos's patch rather extensively.  Need to be in v1.5.4.

sorry, i totally forgot about this patch while you asked me to test it.
it looks ok, to me

thanks,
- VMiklos

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

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  Others commits may be stashed in 'offcuts'.

The topics list the commits in reverse chronological order.

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

* jc/shortlog-e (Fri Dec 7 17:19:31 2007 -0800) 1 commit
 + git-shortlog -e: show e-mail address as well

I wanted to have a tool to help sanity checking our .mailmap, so I did
this.

----------------------------------------------------------------
[Graduated to 'master']

* pr/mergetool (Wed Dec 5 09:19:13 2007 +0200) 1 commit
* jc/spht (Thu Dec 6 00:14:14 2007 -0800) 7 commits

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

* cc/help (Wed Dec 5 06:09:40 2007 +0100) 5 commits
 + Documentation: describe -w/--web option to "git-help".
 + Use {web,instaweb,help}.browser config options.
 + git-help: add -w|--web option to display html man page in a
   browser.
 + Documentation: describe -i/--info option to "git-help"
 + git-help: add -i|--info option to display info page.

Would be nice to have in v1.5.4.  It may make sense to give a custom
info path when "help -i" is run, just like we futz with manpath while
running "help".

----------------------------------------------------------------
[Actively cooking]

* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit
 - Start preparing the API documents.

The primary reason of this series is because I think we made the system
a lot less approachable by losing hackability.  Although we still have
sample scripts in contrib/example for use of plumbing in scripts, they
will not help aspiring git-hacker-wannabees when our primary attention
has already shifted to moving things to C.

This currently consists of mostly stubs, although I wrote about a few
topics as examples.  Nice to have in v1.5.4.

----------------------------------------------------------------
[On hold]

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

I think this is a sane thing to do in the longer term.  Will be in
'next' after v1.5.4.  I think "leave porcelain on PATH" might be also a
good thing as a transition measure.

Incidentally, if we do not install dashed form of built-ins anywhere
(which is not this series is about --- this is just moving them out of
user's PATH), "git help -a" will stop showing them.  I am not enthused
about removing the hardlinks to built-ins to begin with, but people who
want such a change need to first modify help.c:list_commands() to pick
up builtins without having git-foo hardlinks in gitexecdir.  This may
need to happen anyway as mingw fallouts.

----------------------------------------------------------------
[Stalled]

* ns/checkout-push-pop (Wed Dec 5 07:04:06 2007 +0900) 1 commit
 - git-checkout --push/--pop

A reasonably cleanly written cute hack, and I do not see this breaking
the normal codepath.  But I tend to agree with people that 'push' is
too late for forgetful mortals, and just a single "previous" would be
easier to use.

* js/remote (Wed Dec 5 19:02:15 2007 +0000) 4 commits
 - 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

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
 + Support builtin aliases

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 - merge-nu: a new merge backend without using unpack_trees()
 - read_tree: take an explicit index structure
 - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
 - Making ce_path_match() more useful by accepting globs

This was to allow "git diff-files -- '*.h'" (currently diff family
knows only the leading directory match and not fileglobs), but was shot
down by Alex.  I tend to agree with him.

* jc/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
 - Make "diff" Porcelain output paths as relative to subdirectory.

* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
 . revert/cherry-pick: start refactoring call to merge_recursive

* 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.

* 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, so these are not strictly necessary.

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  Others commits may be stashed in 'offcuts'.

The topics list the commits in reverse chronological order.

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

* jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
 . PARK: show-symref protocol extension.

This is a demonstration of a possible component in the future direction
for HEAD discovery done by git-clone.

----------------------------------------------------------------
[Graduated to 'master']

* jc/merge-recursive-gitlink (Mon Dec 10 11:22:05 2007 -0800) 1 commit
* ew/svn-rev-db (Sat Dec 8 23:27:42 2007 -0800) 2 commits
* jk/svn-color (Tue Dec 11 01:28:42 2007 -0500) 2 commits

These got success stories and Acks.  Thanks for testing.

* cc/help (Wed Dec 12 14:00:24 2007 -0800) 13 commits

I've updated RPM git.spec.in minimally to adjust to the locations things
are installed, and also made "browse-help" usable outside git repository.

* jc/shortlog-e (Tue Dec 11 10:09:04 2007 -0800) 4 commits

Ingo's wish resulted in reversal of numbers and names in short-summary
output, which I think is much saner than the original one, and more
importantly, a saner default behaviour when the user does not give
sufficient parameters to it.

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

We are at 1.5.4-rc0.  There is not much to see here ;-)

----------------------------------------------------------------
[Actively cooking]

* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit
 - Start preparing the API documents.

The primary reason of this series is because I think we made the system
a lot less approachable by losing hackability.  Although we still have
sample scripts in contrib/example for use of plumbing in scripts, they
will not help aspiring git-hacker-wannabees when our primary attention
has already shifted to moving things to C.

This currently consists of mostly stubs, although I wrote about a few
topics as examples.  Nice to have in v1.5.4, but we need more writers.

----------------------------------------------------------------
[On hold]

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

I think this is a sane thing to do in the longer term.  Will be in
'next' after v1.5.4.  I think "leave porcelain on PATH" might be also a
good thing as a transition measure.

Incidentally, if we do not install dashed form of built-ins anywhere
(which is not this series is about --- this is just moving them out of
user's PATH), "git help -a" will stop showing them.  I am not enthused
about removing the hardlinks to built-ins to begin with, but people who
want such a change need to first modify help.c:list_commands() to pick
up builtins without having git-foo hardlinks in gitexecdir.  This may
need to happen anyway as mingw fallouts.

* js/remote (Wed Dec 5 19:02:15 2007 +0000) 4 commits
 - 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

This and Kristian's "git-clone in C" are on hold and post 1.5.4.

----------------------------------------------------------------
[Stalled]

* ns/checkout-push-pop (Wed Dec 5 07:04:06 2007 +0900) 1 commit
 - git-checkout --push/--pop

A reasonably cleanly written cute hack, and I do not see this breaking
the normal codepath.  But I tend to agree with people that 'push' is
too late for forgetful mortals, and just a single "previous" would be
easier to use.

* mh/http (Tue Dec 11 00:08:25 2007 +0100) 6 commits
 - Move fetch_ref from http-push.c and http-walker.c to http.c
 - Fix various memory leaks in http-push.c and http-walker.c
 - Use strbuf in http code
 + Avoid redundant declaration of missing_target()
 + Remove a CURLOPT_HTTPHEADER (un)setting
 + Remove the default_headers variable from http-push.c

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
 + Support builtin aliases

Even the original author has slight NAK on this and I tend to agree.
May want to eventurally revert from 'next' but we are not in a hurry
even to do that.

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 - merge-nu: a new merge backend without using unpack_trees()
 - read_tree: take an explicit index structure
 - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
 - Making ce_path_match() more useful by accepting globs

This was to allow "git diff-files -- '*.h'" (currently diff family
knows only the leading directory match and not fileglobs), but was shot
down by Alex.  I tend to agree with him.

* jc/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
 - Make "diff" Porcelain output paths as relative to subdirectory.

* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
 . revert/cherry-pick: start refactoring call to merge_recursive

* 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.

* 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, so these are not strictly necessary.

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

[Nicolas Pitre]

On Wed, 12 Dec 2007, Junio C Hamano wrote:

> Here are the topics that have been cooking.

What about the blame speedup patch from Linus (Message-ID: 
<alpine.LFD.0.9999.0712111548200.25032@woody.linux-foundation.org>)


Nicolas

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  Others commits may be stashed in 'offcuts'.

The topics list the commits in reverse chronological order.

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

* ph/parseopt (Sun Dec 16 22:45:00 2007 -0800) 4 commits
 - builtin-tag: fix fallouts from recent parsopt restriction.
 - (squashme) gitcli documentation fixups
 - parseopt: Add a gitcli(5) man page.
 - parseopt: Enforce the use of the sticked form for optional
   arguments.

This series is needed by 1.5.4-rc1 for fixing regression relative to
1.5.3 series in the option parser: "git describe --abbrev HEAD" does not
work.  The current approach is taken by this series (discussed on the
list) to work it around by forbidding "git describe --abbrev 10 HEAD"
and requiring it be written as "git describe --abbrev=10 HEAD", but
taking that limitation literally will introduce serious usability
regressions.  We need careful auditing of all the commands that adopted
parse_options() API.

* ab/pserver (Fri Dec 14 04:08:51 2007 +0000) 1 commit
 - Authentication support for pserver

This came somewhat late; I think cvsserver is in its own little corner
and the change seems to be quite isolated, so with enough user requests
and Ack from primary people who have been involved with cvsserver I do
not think we mind to make an exception and make it a part of 1.5.4-rc1.


----------------------------------------------------------------
[Graduated to 'master']

* mh/http (Tue Dec 11 00:08:25 2007 +0100)

Big thanks to Daniel who helped reviewing this series which is about
clean-ups and fixes in http transport.

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

Again, we are post -rc0 and there is nothing interesting to see here.

----------------------------------------------------------------
[Actively cooking]

Again, we are post -rc0 and there is nothing interesting to see here.

----------------------------------------------------------------
[On hold]

* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit

The primary reason of this series is because I think we made the system
a lot less approachable by losing hackability.  Although we still have
sample scripts in contrib/example for use of plumbing in scripts, they
will not help aspiring git-hacker-wannabees when our primary attention
has already shifted to moving things to C.

This currently consists of mostly stubs, although I wrote about a few
topics as examples.  Nice to have in v1.5.4, but we need more writers.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

I think this is a sane thing to do in the longer term.  Will be in
'next' after v1.5.4.  I think "leave porcelain on PATH" might be also a
good thing as a transition measure.

Incidentally, if we do not install dashed form of built-ins anywhere
(which is not this series is about --- this is just moving them out of
user's PATH), "git help -a" will stop showing them.  I am not enthused
about removing the hardlinks to built-ins to begin with, but people who
want such a change need to first modify help.c:list_commands() to pick
up builtins without having git-foo hardlinks in gitexecdir.  This may
need to happen anyway as mingw fallouts.

* js/remote (Wed Dec 5 19:02:15 2007 +0000) 4 commits
 - 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

This and Kristian's "git-clone in C" are on hold and post 1.5.4.

----------------------------------------------------------------
[Stalled]

* ns/checkout-push-pop (Wed Dec 5 07:04:06 2007 +0900) 1 commit
 - git-checkout --push/--pop

A reasonably cleanly written cute hack, and I do not see this breaking
the normal codepath.  But I tend to agree with people that 'push' is
too late for forgetful mortals, and just a single "previous" would be
easier to use.

* jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
 - PARK: show-symref protocol extension.

This is a demonstration of a possible component in the future direction
for HEAD discovery done by git-clone.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
 + Support builtin aliases

Even the original author has slight NAK on this and I tend to agree.
May want to eventurally revert from 'next' but we are not in a hurry
even to do that.

* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
 - Making ce_path_match() more useful by accepting globs

This was to allow "git diff-files -- '*.h'" (currently diff family
knows only the leading directory match and not fileglobs), but was shot
down by Alex.  I tend to agree with him.

* 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, so these are not strictly necessary.

* jc/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
 . Make "diff" Porcelain output paths as relative to subdirectory.

* 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.

* jc/cherry-pick (Sun Dec 16 21:00:03 2007 -0800) 2 commits
 . beginning of use of replay merge in revert
 . revert/cherry-pick: start refactoring call to merge_recursive

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 . merge-nu: a new merge backend without using unpack_trees()
 . read_tree: take an explicit index structure
 . gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  Others commits may be stashed in 'offcuts'.

The topics list the commits in reverse chronological order.

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

* ab/pserver (Fri Dec 14 04:08:51 2007 +0000) 1 commit
 - Authentication support for pserver

This needs careful security audit and a fix to its password
database format.  Plaintext in .git/config is not acceptable.

* rs/pretty-safety (Thu Dec 20 13:20:15 2007 +0100) 1 commit
 - Serious bug with pretty format strings & empty bodies?

I do not think what this addresses is any "serious" problem in
real life.  But on the other hand I do not think it hurts.  Will
take a look at it again and will merge.

* ar/commit-cleanup (Sat Dec 22 19:46:24 2007 +0100) 4 commits
 + Allow selection of different cleanup modes for commit messages
 + builtin-commit: avoid double-negation in the code.
 + builtin-commit: fix amending of the initial commit
 + t7005: do not exit inside test.

This is cleaned up since the last version Alex posted, and the
first three are fixes and clean-ups, so they will be merged.
The primary purpose of this series by Alex is to allow commits
to be made verbatim without stripping lines that begin with '#'
in the commit log messages, which would be a worthy goal, so I
do not mind merging it in 1.5.4.

* ph/describe-match (Fri Dec 21 22:49:54 2007 +0100) 1 commit
 + git-describe: Add a --match option to limit considered tags.

Even though this is a new feature, the impact to the main
codepath is minimum and I think it is Ok to merge it in 1.5.4,
but still seems to have a funny interaction with --contains.  So
it will be on hold.

* jc/sys-select (Tue Dec 18 01:52:07 2007 -0800) 1 commit
 - Do not include <sys/select.h> on pre- POSIX.1-2001 systems

This was done to help HP-UX port, but it appears that HP-UX
headers do not like to cooperate with usual _POSIX_VERSION rule,
so we probably need to scrap it and instead use manual
configuration instead.

----------------------------------------------------------------
[Graduated to 'master']

* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit

The primary reason of this series is because I think we made the system
a lot less approachable by losing hackability.  Although we still have
sample scripts in contrib/example for use of plumbing in scripts, they
will not help aspiring git-hacker-wannabees when our primary attention
has already shifted to moving things to C.

This currently consists of mostly stubs, although I wrote about a few
topics as examples.  Nice to have in v1.5.4, but we need more writers.

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

Nothing to see.  We are in -rc.  Please test 'master'.

----------------------------------------------------------------
[Actively cooking]

Nothing to see.  We are in -rc.  Please test 'master'.

----------------------------------------------------------------
[On hold]

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

I think this is a sane thing to do in the longer term.  Will be in
'next' after v1.5.4.  I think "leave porcelain on PATH" might be also a
good thing as a transition measure.

Incidentally, if we do not install dashed form of built-ins anywhere
(which is not this series is about --- this is just moving them out of
user's PATH), "git help -a" will stop showing them.  I am not enthused
about removing the hardlinks to built-ins to begin with, but people who
want such a change need to first modify help.c:list_commands() to pick
up builtins without having git-foo hardlinks in gitexecdir.  This may
need to happen anyway as mingw fallouts.

* js/remote (Wed Dec 5 19:02:15 2007 +0000) 4 commits
 . 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

This and Kristian's "git-clone in C" are on hold and will need
to be rebased, post 1.5.4.

----------------------------------------------------------------
[Stalled]

* ns/checkout-push-pop (Wed Dec 5 07:04:06 2007 +0900) 1 commit
 - git-checkout --push/--pop

A reasonably cleanly written cute hack, and I do not see this breaking
the normal codepath.  But I tend to agree with people that 'push' is
too late for forgetful mortals, and just a single "previous" would be
easier to use.

* jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
 - PARK: show-symref protocol extension.

This is a demonstration of a possible component in the future direction
for HEAD discovery done by git-clone.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
 + Support builtin aliases

Even the original author has slight NAK on this and I tend to agree.
May want to eventurally revert from 'next' but we are not in a hurry
even to do that.

* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
 - Making ce_path_match() more useful by accepting globs

This was to allow "git diff-files -- '*.h'" (currently diff family
knows only the leading directory match and not fileglobs), but was shot
down by Alex.  I tend to agree with him.

* 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, so these are not strictly necessary.

* jc/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
 . Make "diff" Porcelain output paths as relative to subdirectory.

* 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.

* jc/cherry-pick (Sun Dec 16 21:00:03 2007 -0800) 2 commits
 . beginning of use of replay merge in revert
 . revert/cherry-pick: start refactoring call to merge_recursive

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 . merge-nu: a new merge backend without using unpack_trees()
 . read_tree: take an explicit index structure
 . gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  Others commits may be stashed in 'offcuts'.

The topics list the commits in reverse chronological order.

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

* db/send-email-omit-cc (Tue Dec 25 19:56:29 2007 -0800) 1 commit
 - git-send-email: Generalize auto-cc recipient mechanism.

New feature which seems to be nice, but will be postponed.

* bf/remote-head (Sun Dec 23 20:52:32 2007 -0500) 1 commit
 . git-remote: make add -f guess HEAD, as clone does

New feature which could be used in rewriting git-clone as a thin
wrapper around other commands, but there are conflicting
proposals from Kristian and Dscho, which are post 1.5.4 item.
We'll see how they pan out.

* 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.
Definitely post 1.5.4.

* jc/diff-hunk-header (Wed Jan 2 01:50:11 2008 -0800) 2 commits
 - diff: do not chomp hunk-header in the middle of a character
 - utf8_width(): allow non NUL-terminated input

This is rewritten version of Shibata's patch.  We may need this
in 1.5.4 to help the real world issue the kernel documentaiton
i18n folks are already having.

----------------------------------------------------------------
[Graduated to 'master']

Nothing to see, as we are in -rc freeze.

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

Nothing to see, as we are in -rc freeze.

----------------------------------------------------------------
[Actively cooking]

Nothing to see, as we are in -rc freeze.

----------------------------------------------------------------
[On hold]

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

I think this is a sane thing to do in the longer term.  Will be in
'next' after v1.5.4.  I think "leave porcelain on PATH" might be also a
good thing as a transition measure.

Incidentally, if we do not install dashed form of built-ins anywhere
(which is not this series is about --- this is just moving them out of
user's PATH), "git help -a" will stop showing them.  I am not enthused
about removing the hardlinks to built-ins to begin with, but people who
want such a change need to first modify help.c:list_commands() to pick
up builtins without having git-foo hardlinks in gitexecdir.  This may
need to happen anyway as mingw fallouts.

* js/remote (Wed Dec 5 19:02:15 2007 +0000) 4 commits
 . 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

This and Kristian's "git-clone in C" are on hold and will need
to be rebased, post 1.5.4.

* ph/describe-match (Mon Dec 24 12:18:22 2007 +0100) 2 commits
 + git-name-rev: add a --(no-)undefined option.
 + git-describe: Add a --match option to limit considered tags.

* 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

I haven't queued Brandon's "git stash drop", as the command name
and the UI is undecided yet, but this series will serve as the
basis of such a feature.

----------------------------------------------------------------
[Stalled]

* ab/pserver (Fri Dec 14 04:08:51 2007 +0000) 1 commit
 . Authentication support for pserver

This needs careful security audit and a fix to its password
database format.  Plaintext in .git/config is not acceptable.

* jc/sys-select (Tue Dec 18 01:52:07 2007 -0800) 1 commit
 - Do not include <sys/select.h> on pre- POSIX.1-2001 systems

This was done to help HP-UX port, but it appears that HP-UX
headers do not like to cooperate with usual _POSIX_VERSION rule,
so we probably need to scrap it and instead use manual
configuration instead.

* jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
 - PARK: show-symref protocol extension.

This is a demonstration of a possible component in the future direction
for HEAD discovery done by git-clone.

* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
 + Support builtin aliases

Even the original author has slight NAK on this and I tend to agree.
May want to eventurally revert from 'next' but we are not in a hurry
even to do that.

* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
 - Making ce_path_match() more useful by accepting globs

This was to allow "git diff-files -- '*.h'" (currently diff family
knows only the leading directory match and not fileglobs), but was shot
down by Alex.  I tend to agree with him.

* 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, so these are not strictly necessary.

* jc/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
 . Make "diff" Porcelain output paths as relative to subdirectory.

* 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.

* jc/cherry-pick (Mon Dec 24 00:51:01 2007 -0800) 4 commits
 - PARK: 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.

I shouldn't be wasting time arguing and spending a bit more time
on 'master' and also on this.

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

[Johannes Schindelin]

Hi,

On Sat, 5 Jan 2008, Junio C Hamano wrote:

> * bf/remote-head (Sun Dec 23 20:52:32 2007 -0500) 1 commit
>  . git-remote: make add -f guess HEAD, as clone does
> 
> New feature which could be used in rewriting git-clone as a thin wrapper 
> around other commands, but there are conflicting proposals from Kristian 
> and Dscho, which are post 1.5.4 item. We'll see how they pan out.

I do not have any objection against using bf/remote-head to introduce this 
feature, and will port it to C when it is deemed good enough.  After all, 
we _use_ shell scripting for prototyping things.

> * 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.
> Definitely post 1.5.4.

I did not follow this closely... Would this help the "notes" feature as 
implemented with refs/notes?

> * jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
>  - Making ce_path_match() more useful by accepting globs
> 
> This was to allow "git diff-files -- '*.h'" (currently diff family
> knows only the leading directory match and not fileglobs), but was shot
> down by Alex.  I tend to agree with him.

I recently needed something like this, and had to script around the lack 
of support for this.

Ciao,
Dscho

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been kept out of 'master'.
Commits prefixed with '-' are only in 'pu' while commits
prefixed with '+' are in 'next'.

The topics list the commits in reverse chronological order.

I'd like to get post-release fixes to 'maint' first, tag 1.5.4.1
and merge that to 'master', and then start merging things from
'next' to 'master'.

My wish is to have small but short release cycle for 1.5.5 and
leave bigger ones cooking for 1.6.0.

----------------------------------------------------------------
[Requests for Comments]

* db/send-email-omit-cc (Tue Dec 25 19:56:29 2007 -0800) 1 commit
 - git-send-email: Generalize auto-cc recipient mechanism.

This came after 1.5.4-rc cycle started and was placed on hold.
I do not recall if there was any objection to it.

* jc/gitignore-ends-with-slash (Thu Jan 31 20:23:25 2008 -0800) 2 commits
 - gitignore: lazily find dtype
 - gitignore(5): Allow "foo/" in ignore list to match directory "foo"

This is redone after we had discussion on the list to properly
make "foo/" match only with directories and "foo" with both
files and directories without unnecessary lstat(2) calls.

* jc/apply-whitespace (Tue Jan 15 00:59:05 2008 -0800) 13 commits
 - core.whitespace: cr-at-eol
 - git-apply --whitespace=fix: fix whitespace fuzz introduced by
   previous run
 - builtin-apply.c: pass ws_rule down to match_fragment()
 - builtin-apply.c: move copy_wsfix() function a bit higher.
 - builtin-apply.c: do not feed copy_wsfix() leading '+'
 - builtin-apply.c: simplify calling site to apply_line()
 - builtin-apply.c: clean-up apply_one_fragment()
 - builtin-apply.c: mark common context lines in lineinfo structure.
 - builtin-apply.c: optimize match_beginning/end processing a bit.
 - builtin-apply.c: make it more line oriented
 - builtin-apply.c: push match-beginning/end logic down
 - builtin-apply.c: restructure "offset" matching
 - builtin-apply.c: refactor small part that matches context

* 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/rename (Tue Jan 29 20:54:56 2008 -0800) 1 commit
 - Optimize rename detection for a huge diff

Micro-optimization whose real world benefit is not proven.

----------------------------------------------------------------
[Will merge to 'master' after 1.5.4.1]

* ph/describe-match (Mon Dec 24 12:18:22 2007 +0100) 2 commits
 + git-name-rev: add a --(no-)undefined option.
 + git-describe: Add a --match option to limit considered tags.

* lt/in-core-index (Tue Jan 22 23:01:13 2008 -0800) 9 commits
 + lazy index hashing
 + Create pathname-based hash-table lookup into index
 + read-cache.c: introduce is_racy_timestamp() helper
 + read-cache.c: fix a couple more CE_REMOVE conversion
 + Also use unpack_trees() in do_diff_cache()
 + Make run_diff_index() use unpack_trees(), not read_tree()
 + Avoid running lstat(2) on the same cache entry.
 + index: be careful when handling long names
 + Make on-disk index representation separate from in-core one

This is about reducing number of lstat(2) calls during complex
operations, and optimizing "do we have this in the index"
queries.  Most likely this will be the first series to be merged
to 'master'.

----------------------------------------------------------------
[Actively cooking]

* jk/builtin-alias (Sun Feb 3 01:48:29 2008 -0800) 2 commits
 - Revert "Support builtin aliases"
 + Support builtin aliases

Will revert from 'next', as mentioned in the previous issue of this
message.

----------------------------------------------------------------
[Questionable]

* jc/setup (Fri Feb 1 03:13:10 2008 -0800) 3 commits
 - git-add: adjust to the get_pathspec() changes.
 - Make blame accept absolute paths
 - setup: sanitize absolute and funny paths in get_pathspec()

I suspect this would need to be rethought so that it will return
the same number of paths and make the caller choose what to do
with paths outside the repository.  This is very unfortunate.

Ideally, all of git commands that use get_pathspec() should work
on paths inside work tree and barf on paths outside work tree,
and in that sense the series as I did was fine.  But we have
bolted-on-hack commands that want to see and act on paths that
are outside of the work tree; filtering the paths outside the
work tree in get_pathspec() would break them.

If we redo this series that way, git-ls-files (especially with
its --error-unmatch), git-clean, and git-add should detect the
paths outside the work tree themselves and complain, without
relying on get_pathspec() to do the barfing for them.

* ab/pserver (Fri Dec 14 04:08:51 2007 +0000) 1 commit
 - Authentication support for pserver

This needs careful security audit and a fix to its password
database format.  Plaintext in .git/config is not acceptable.

----------------------------------------------------------------
[On hold]

* js/remote (Wed Dec 5 19:02:15 2007 +0000) 4 commits
 - 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

I might have carefully looked at this in the past but I do not
recall if there were issues.  Need re-reviewing and help from
the list is appreciated.

* bf/remote-head (Sun Dec 23 20:52:32 2007 -0500) 1 commit
 - git-remote: make add -f guess HEAD, as clone does

Likewise.

* 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.  Please resubmit for discussion and application.
Whatever the name and UI is, selective removal of stash is a
nice thing to have for 1.5.5.

* 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/cherry-pick (Mon Dec 24 00:51:01 2007 -0800) 4 commits
 - PARK: 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.

Meant to avoid merge_recursive() during cherry-pick and revert,
so that D/F conflicts can be redone right, but I got busy and
this has unfortunately stalled.

* 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/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
 - Make "diff" Porcelain output paths as relative to subdirectory.

* jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
 - PARK: show-symref protocol extension.


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

Issues that I have looked at, but unprocessed, unconcluded
and/or lack enough discussions to proceed.

* "git-apply --whitespace=fix" context adjustment
  $gmane/72248

* pretty.c optimization (Marco)
  $gmane/72260

* zlib abstraction (Marco)
  $gmane/72262

* revision.c::limit_list() breakage (Jeff King)
  $gmane/72324
  t/t6009

* synopsys: use {} instead of () for grouping alternatives (Jari Aalto)
  $gmane/72243

* A symref file for ".git/" (Lars Hjemli)
  $gmane/72244

* safecrlf (Steffen Prohaska)
  $gmane/72285

* git-send-email unechoed interactive password (Michael Witten)
  $gmane/72220

* compat/qsort (Brian Downing)
  $gmane/72311

* unified "user's choice brower" (Christian Couder)
  $gmane/72226

* "[alias] st = status" and "cd .git && git st" (Jeff King)
  $gmane/72327

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

[Johannes Schindelin]

Hi,

On Sun, 3 Feb 2008, Junio C Hamano wrote:

> [On hold]
> 
> * js/remote (Wed Dec 5 19:02:15 2007 +0000) 4 commits
>  - 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
> 
> I might have carefully looked at this in the past but I do not
> recall if there were issues.  Need re-reviewing and help from
> the list is appreciated.

You said that the test suit fails on one of your machines, and I looked at 
it with valgrind.  There was an odd problem accessing free()d memory, and 
I decided to come back to it after 1.5.4.

So please let me rework it first, before you re-review it.

> * synopsys: use {} instead of () for grouping alternatives (Jari Aalto)
>   $gmane/72243

Personally, I do not think the current form merits any change.

Ciao,
Dscho

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been kept out of 'master'.
Commits prefixed with '-' are only in 'pu' while commits
prefixed with '+' are in 'next'.

The topics list the commits in reverse chronological order.

I'd like to get post-release fixes to 'maint' first, tag 1.5.4.1
and merge that to 'master', and then start merging things from
'next' to 'master'.

My wish is to have small but short release cycle for 1.5.5 and
leave bigger ones cooking for 1.6.0.

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

* jc/error-message-in-cherry-pick (Thu Jan 10 22:49:35 2008 -0800) 1 commit
 + Make error messages from cherry-pick/revert more sensible

Björn Steinbrink reported and then tested this.  Is queued in
'next' but will push it out to 'master' after 1.5.4.1.

* jc/submittingpatches (Sun Feb 3 17:02:28 2008 -0800) 3 commits
 + Documentation/SubmittingPatches: What's Acked-by and Tested-by?
 + Documentation/SubmittingPatches: discuss first then submit
 + Documentation/SubmittingPatches: Instruct how to use [PATCH]
   Subject header

These I think are sensible but they did not see much discussion,
so they are parked here for now.

* cc/browser (Sat Feb 2 07:32:56 2008 +0100) 4 commits
 - instaweb: use 'git-web--browse' to launch browser.
 - Rename 'git-help--browse.sh' to 'git-web--browse.sh'.
 - help--browse: add '--config' option to check a config option for a
   browser.
 - help: make 'git-help--browse' usable outside 'git-help'.

Christian Couder consolidated the logic to pick user's favorite
browser between instaweb and help.

* mw/send-email (Sun Feb 3 19:53:58 2008 -0500) 3 commits
 + git-send-email: Better handling of EOF
 + git-send-email: SIG{TERM,INT} handlers
 + git-send-email: ssh/login style password requests

For 'master' post 1.5.4.1.

* db/no-separate-ls-remote-connection (Mon Feb 4 13:26:23 2008 -0500) 1 commit
 + Reduce the number of connects when fetching

Looked reasonably clean and correct.  Will park in 'next' just
in case, but I think this is ready for 'master' post 1.5.4.1.

* bd/qsort (Sat Feb 2 19:11:30 2008 -0600) 1 commit
 - compat: Add simplified merge sort implementation from glibc

More reasonable qsort(3) than Microsoft by Brian Downing; I
already did the "de-gcc-ism" pointed out on the list but Brian
said he would reroll the patch, so I've parked it in 'pu' for
now.  If Brian is Ok with the version here, we could move it to
'next'.

----------------------------------------------------------------
[Requests for Comments]

* db/send-email-omit-cc (Tue Dec 25 19:56:29 2007 -0800) 1 commit
 + git-send-email: Generalize auto-cc recipient mechanism.

This came after 1.5.4-rc cycle started and was placed on hold.
I do not recall if there was any objection to it.

* jc/gitignore-ends-with-slash (Thu Jan 31 20:23:25 2008 -0800) 2 commits
 + gitignore: lazily find dtype
 + gitignore(5): Allow "foo/" in ignore list to match directory "foo"

This is redone after we had discussion on the list to properly
make "foo/" match only with directories and "foo" with both
files and directories without unnecessary lstat(2) calls.

* jc/apply-whitespace (Tue Jan 15 00:59:05 2008 -0800) 13 commits
 + core.whitespace: cr-at-eol
 + git-apply --whitespace=fix: fix whitespace fuzz introduced by
   previous run
 + builtin-apply.c: pass ws_rule down to match_fragment()
 + builtin-apply.c: move copy_wsfix() function a bit higher.
 + builtin-apply.c: do not feed copy_wsfix() leading '+'
 + builtin-apply.c: simplify calling site to apply_line()
 + builtin-apply.c: clean-up apply_one_fragment()
 + builtin-apply.c: mark common context lines in lineinfo structure.
 + builtin-apply.c: optimize match_beginning/end processing a bit.
 + builtin-apply.c: make it more line oriented
 + builtin-apply.c: push match-beginning/end logic down
 + builtin-apply.c: restructure "offset" matching
 + builtin-apply.c: refactor small part that matches context

* 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/rename (Tue Jan 29 20:54:56 2008 -0800) 1 commit
 - Optimize rename detection for a huge diff

Micro-optimization whose real world benefit is not proven.

----------------------------------------------------------------
[Will merge to 'master' after 1.5.4.1]

* ph/describe-match (Mon Dec 24 12:18:22 2007 +0100) 2 commits
 + git-name-rev: add a --(no-)undefined option.
 + git-describe: Add a --match option to limit considered tags.

* lt/in-core-index (Tue Jan 22 23:01:13 2008 -0800) 9 commits
 + lazy index hashing
 + Create pathname-based hash-table lookup into index
 + read-cache.c: introduce is_racy_timestamp() helper
 + read-cache.c: fix a couple more CE_REMOVE conversion
 + Also use unpack_trees() in do_diff_cache()
 + Make run_diff_index() use unpack_trees(), not read_tree()
 + Avoid running lstat(2) on the same cache entry.
 + index: be careful when handling long names
 + Make on-disk index representation separate from in-core one

This is about reducing number of lstat(2) calls during complex
operations, and optimizing "do we have this in the index"
queries.  Most likely this will be the first series to be merged
to 'master'.

----------------------------------------------------------------
[Dropped]

* jk/builtin-alias (Sun Feb 3 01:48:29 2008 -0800) 2 commits
 + Revert "Support builtin aliases"
 + Support builtin aliases

Reverted from 'next'.

* js/remote (Wed Dec 5 19:02:15 2007 +0000) 4 commits

Dropped per author's request, waiting for a respin.

----------------------------------------------------------------
[Actively Cooking]

* jc/setup (Sun Feb 3 23:59:17 2008 -0800) 4 commits
 + builtin-mv: minimum fix to avoid losing files
 + git-add: adjust to the get_pathspec() changes.
 + Make blame accept absolute paths
 + setup: sanitize absolute and funny paths in get_pathspec()

----------------------------------------------------------------
[Questionable]

* ab/pserver (Fri Dec 14 04:08:51 2007 +0000) 1 commit
 - Authentication support for pserver

This needs careful security audit and a fix to its password
database format.  Plaintext in .git/config is not acceptable.

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

* bf/remote-head (Sun Dec 23 20:52:32 2007 -0500) 1 commit
 - git-remote: make add -f guess HEAD, as clone does

I might have carefully looked at this in the past but I do not
recall if there were issues.  Need re-reviewing and help from
the list is appreciated.

* 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.  Please resubmit for discussion and application.
Whatever the name and UI is, selective removal of stash is a
nice thing to have for 1.5.5.

* 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/cherry-pick (Mon Dec 24 00:51:01 2007 -0800) 4 commits
 - PARK: 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.

Meant to avoid merge_recursive() during cherry-pick and revert,
so that D/F conflicts can be redone right, but I got busy and
this has unfortunately stalled.

* 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/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
 . Make "diff" Porcelain output paths as relative to subdirectory.

* jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
 . PARK: show-symref protocol extension.

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

[Jakub Narebski]

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

> * jc/submittingpatches (Sun Feb 3 17:02:28 2008 -0800) 3 commits
>  + Documentation/SubmittingPatches: What's Acked-by and Tested-by?
>  + Documentation/SubmittingPatches: discuss first then submit
>  + Documentation/SubmittingPatches: Instruct how to use [PATCH]
>    Subject header
> 
> These I think are sensible but they did not see much discussion,
> so they are parked here for now.

In those series I think the middle patch could be improved. I guess
that need for brevity overcame need for being explicit. I don't know
if patches meant for discussion are to be send to mailing list only,
or if the patches meant for submissions are to be sent to git mailing
list _and_ maintainer (and is it an error to send them only to the
list) from this description.

The rest patches are IMHO very good improvement.
 
> ----------------------------------------------------------------
> [Will merge to 'master' after 1.5.4.1]
> 
> * ph/describe-match (Mon Dec 24 12:18:22 2007 +0100) 2 commits
>  + git-name-rev: add a --(no-)undefined option.
>  + git-describe: Add a --match option to limit considered tags.

I'd really like that.
 

IIRC there was also patch which did '~' expansion in paths provided
via options to git, but 1.) is was buggy, 2.) it dealt only with
excludefile, and not for example with --git-dir and --work-dir
arguments, 3.) it was not resend for furrther discussion.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> * jc/submittingpatches (Sun Feb 3 17:02:28 2008 -0800) 3 commits
>>  + Documentation/SubmittingPatches: What's Acked-by and Tested-by?
>>  + Documentation/SubmittingPatches: discuss first then submit
>>  + Documentation/SubmittingPatches: Instruct how to use [PATCH]
>>    Subject header
>> 
>> These I think are sensible but they did not see much discussion,
>> so they are parked here for now.
>
> In those series I think the middle patch could be improved. I guess
> that need for brevity overcame need for being explicit. I don't know
> if patches meant for discussion are to be send to mailing list only,
> or if the patches meant for submissions are to be sent to git mailing
> list _and_ maintainer (and is it an error to send them only to the
> list) from this description.

Yeah, I was very unsure about the wording.  What I think is the
ideal patch flow is:

 (0) You come up with an itch.  You code it up.

 (1) Send it to the list and cc people who may need to know about
     the change.

     The people who may need to know are the ones whose code you
     are butchering.  These people happen to be the ones who are
     most likely to be knowledgeable enough to help you, but
     they have no obligation to help you (i.e. you ask for help,
     don't demand).

     The people could include me, but that is not because I am
     currently the maintainer, but because I may happen to have
     been involved in the code you are touching.

 (2) You get comments and suggestions for improvements.  You may
     even get them in a "on top of" patch form.

 (3) Polish, refine, and re-send to the list and the people who
     spend their time to improve your patch.  Go back to step (2).

 (4) The list forms consensus that the last round of your patch is
     good.  Send it to the list and cc me.

 (5) It is merged to 'next', and cooked further and eventually
     graduates to 'master'.

In any time between the (2)-(3) cycle, I should pick it up from
the list and queue it to 'pu', in order to make it easier for
people play with it without having to pick up and apply the
patch to their trees themselves.

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been kept out of 'master'.
Commits prefixed with '-' are only in 'pu' while commits
prefixed with '+' are in 'next'.

The topics list the commits in reverse chronological order.

I'd like to get post-release fixes to 'maint' first, tag 1.5.4.1
and merge that to 'master', and then start merging things from
'next' to 'master'.

My wish is to have small but short release cycle for 1.5.5 and
leave bigger ones cooking for 1.6.0.

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

* sp/safecrlf (Wed Feb 6 12:25:58 2008 +0100) 1 commit
 + safecrlf: Add mechanism to warn about irreversible crlf
   conversions

* jk/noetcconfig (Wed Feb 6 05:11:53 2008 -0500) 2 commits
 + fix config reading in tests
 + allow suppressing of global and system config

* lh/gitdir (Mon Feb 4 21:59:21 2008 +0100) 4 commits
 - git-submodule: prepare for the .git-file
 - Add tests for .git file
 - Document the .git-file
 - Add platform-independent .git "symlink"

Seems to have funny interaction with Jeff King's test script
updates.

* pb/prepare-commit-msg (Tue Feb 5 08:04:18 2008 +0100) 4 commits
 + git-commit: add a prepare-commit-msg hook
 + git-commit: Refactor creation of log message.
 + git-commit: set GIT_EDITOR=: if editor will not be launched
 + git-commit: support variable number of hook arguments

----------------------------------------------------------------
[Requests for Comments]

* db/send-email-omit-cc (Tue Dec 25 19:56:29 2007 -0800) 1 commit
 + git-send-email: Generalize auto-cc recipient mechanism.

This came after 1.5.4-rc cycle started and was placed on hold.
I do not recall if there was any objection to it.

* jc/gitignore-ends-with-slash (Thu Jan 31 20:23:25 2008 -0800) 2 commits
 + gitignore: lazily find dtype
 + gitignore(5): Allow "foo/" in ignore list to match directory "foo"

This is redone after we had discussion on the list to properly
make "foo/" match only with directories and "foo" with both
files and directories without unnecessary lstat(2) calls.

* jc/apply-whitespace (Tue Jan 15 00:59:05 2008 -0800) 13 commits
 + core.whitespace: cr-at-eol
 + git-apply --whitespace=fix: fix whitespace fuzz introduced by
   previous run
 + builtin-apply.c: pass ws_rule down to match_fragment()
 + builtin-apply.c: move copy_wsfix() function a bit higher.
 + builtin-apply.c: do not feed copy_wsfix() leading '+'
 + builtin-apply.c: simplify calling site to apply_line()
 + builtin-apply.c: clean-up apply_one_fragment()
 + builtin-apply.c: mark common context lines in lineinfo structure.
 + builtin-apply.c: optimize match_beginning/end processing a bit.
 + builtin-apply.c: make it more line oriented
 + builtin-apply.c: push match-beginning/end logic down
 + builtin-apply.c: restructure "offset" matching
 + builtin-apply.c: refactor small part that matches context

* 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/rename (Tue Jan 29 20:54:56 2008 -0800) 1 commit
 - Optimize rename detection for a huge diff

Micro-optimization whose real world benefit is not proven.

----------------------------------------------------------------
[Will merge to 'master' after 1.5.4.1]

* ph/describe-match (Mon Dec 24 12:18:22 2007 +0100) 2 commits
 + git-name-rev: add a --(no-)undefined option.
 + git-describe: Add a --match option to limit considered tags.

* lt/in-core-index (Tue Jan 22 23:01:13 2008 -0800) 9 commits
 + lazy index hashing
 + Create pathname-based hash-table lookup into index
 + read-cache.c: introduce is_racy_timestamp() helper
 + read-cache.c: fix a couple more CE_REMOVE conversion
 + Also use unpack_trees() in do_diff_cache()
 + Make run_diff_index() use unpack_trees(), not read_tree()
 + Avoid running lstat(2) on the same cache entry.
 + index: be careful when handling long names
 + Make on-disk index representation separate from in-core one

This is about reducing number of lstat(2) calls during complex
operations, and optimizing "do we have this in the index"
queries.  Most likely this will be the first series to be merged
to 'master'.

----------------------------------------------------------------
[Actively Cooking]

* jc/setup (Sun Feb 3 23:59:17 2008 -0800) 4 commits
 + builtin-mv: minimum fix to avoid losing files
 + git-add: adjust to the get_pathspec() changes.
 + Make blame accept absolute paths
 + setup: sanitize absolute and funny paths in get_pathspec()

* jc/error-message-in-cherry-pick (Thu Jan 10 22:49:35 2008 -0800) 1 commit
 + Make error messages from cherry-pick/revert more sensible

Björn Steinbrink reported and then tested this.  Is queued in
'next' but will push it out to 'master' after 1.5.4.1.

* jc/submittingpatches (Sun Feb 3 17:02:28 2008 -0800) 3 commits
 + Documentation/SubmittingPatches: What's Acked-by and Tested-by?
 + Documentation/SubmittingPatches: discuss first then submit
 + Documentation/SubmittingPatches: Instruct how to use [PATCH]
   Subject header

These I think are sensible but they did not see much discussion,
so they are parked here for now.

* cc/browser (Sat Feb 2 07:32:56 2008 +0100) 4 commits
 + instaweb: use 'git-web--browse' to launch browser.
 + Rename 'git-help--browse.sh' to 'git-web--browse.sh'.
 + help--browse: add '--config' option to check a config option for a
   browser.
 + help: make 'git-help--browse' usable outside 'git-help'.

Christian Couder consolidated the logic to pick user's favorite
browser between instaweb and help.

* mw/send-email (Sun Feb 3 19:53:58 2008 -0500) 3 commits
 + git-send-email: Better handling of EOF
 + git-send-email: SIG{TERM,INT} handlers
 + git-send-email: ssh/login style password requests

For 'master' post 1.5.4.1.

* db/no-separate-ls-remote-connection (Mon Feb 4 13:26:23 2008 -0500) 1 commit
 + Reduce the number of connects when fetching

Looked reasonably clean and correct.  Will park in 'next' just
in case, but I think this is ready for 'master' post 1.5.4.1.

* bd/qsort (Tue Feb 5 15:10:44 2008 -0600) 1 commit
 + compat: Add simplified merge sort implementation from glibc

More reasonable qsort(3) than Microsoft by Brian Downing; I
already did the "de-gcc-ism" pointed out on the list but Brian
said he would reroll the patch, so I've parked it in 'pu' for
now.  If Brian is Ok with the version here, we could move it to
'next'.

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

* 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.

* 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.

----------------------------------------------------------------
[temporarily excluded]

* bf/remote-head (Sun Dec 23 20:52:32 2007 -0500) 1 commit
 . git-remote: make add -f guess HEAD, as clone does

I might have carefully looked at this in the past but I do not
recall if there were issues.  Need re-reviewing and help from
the list is appreciated.

* ab/pserver (Fri Dec 14 04:08:51 2007 +0000) 1 commit
 . Authentication support for pserver

This needs careful security audit and a fix to its password
database format.  Plaintext in .git/config is not acceptable.

* jc/cherry-pick (Mon Dec 24 00:51:01 2007 -0800) 4 commits
 . PARK: 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.

Meant to avoid merge_recursive() during cherry-pick and revert,
so that D/F conflicts can be redone right, but I got busy and
this has unfortunately stalled.

* 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/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
 . Make "diff" Porcelain output paths as relative to subdirectory.

* jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
 . PARK: show-symref protocol extension.

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

[Jeff King]

On Wed, Feb 06, 2008 at 06:03:51PM -0800, Junio C Hamano wrote:

> * lh/gitdir (Mon Feb 4 21:59:21 2008 +0100) 4 commits
>  - git-submodule: prepare for the .git-file
>  - Add tests for .git file
>  - Document the .git-file
>  - Add platform-independent .git "symlink"
> 
> Seems to have funny interaction with Jeff King's test script
> updates.

I think this is a bug in Lars' code. The problem is that even though we
set GIT_DIR to the contents of the '.git' file, we may already have run
setup_git_env, which creates and remembers paths like '.git/objects'.

It worked with the old tests because we set GIT_CONFIG, which meant that
looking at the config didn't require actually finding the .git
directory. But now that we don't set GIT_CONFIG, setup_git_env gets
called much earlier (to find the right config file). And I think this is
a vindication of my change, since it reflects real world usage much more
-- I can't even get the hash-object test to pass if I do it by hand,
even though the test script passed.

The solution is probably to intercept the lookup of the .git directory
in setup_git_env, and read the .git file there (this should probably get
pulled out as a git_dir() function or similar).

-Peff

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

[Lars Hjemli]

On Feb 7, 2008 6:05 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Feb 06, 2008 at 06:03:51PM -0800, Junio C Hamano wrote:
>
> > * lh/gitdir (Mon Feb 4 21:59:21 2008 +0100) 4 commits
> >  - git-submodule: prepare for the .git-file
> >  - Add tests for .git file
> >  - Document the .git-file
> >  - Add platform-independent .git "symlink"
> >
> > Seems to have funny interaction with Jeff King's test script
> > updates.
>
> I think this is a bug in Lars' code. The problem is that even though we
> set GIT_DIR to the contents of the '.git' file, we may already have run
> setup_git_env, which creates and remembers paths like '.git/objects'.

Yeah, we need to run set_git_dir() to get all the paths set correctly:

diff --git a/setup.c b/setup.c
index 2cbda91..64b069f 100644
--- a/setup.c
+++ b/setup.c
@@ -339,7 +339,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
        for (;;) {
                gitfile_dir = read_gitfile_gently(DEFAULT_GIT_DIR_ENVIRONMENT);
                if (gitfile_dir) {
-                       setenv(GIT_DIR_ENVIRONMENT, gitfile_dir, 1);
+                       if (set_git_dir(gitfile_dir))
+                               return NULL;
                        break;
                }
                if (is_git_directory(DEFAULT_GIT_DIR_ENVIRONMENT))

But this isn't enough either, git-sh-setup.sh needs a patch when
setting GIT_DIR and I just noticed merge-recursive failing (it needs
to call setup_git_directory() in it's main()).

I'll work on this tonight.

-- 
larsh

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

[Jakub Narebski]

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

> * jk/noetcconfig (Wed Feb 6 05:11:53 2008 -0500) 2 commits
>  + fix config reading in tests
>  + allow suppressing of global and system config
> 
> * lh/gitdir (Mon Feb 4 21:59:21 2008 +0100) 4 commits
>  - git-submodule: prepare for the .git-file
>  - Add tests for .git file
>  - Document the .git-file
>  - Add platform-independent .git "symlink"
> 
> Seems to have funny interaction with Jeff King's test script
> updates.

I think that gitdir is a very good idea, but needs further testing.
 
> * ph/describe-match (Mon Dec 24 12:18:22 2007 +0100) 2 commits
>  + git-name-rev: add a --(no-)undefined option.
>  + git-describe: Add a --match option to limit considered tags.

This looks nice. I'd like also to have some kind of --pretty=<format>
(or --format=<format>) for git-describe, and a way to limit both
git-name-rev and git-describe to only *signed* commits.

With this it would be fairly easy in generating git.spec file
from git.spec.in to check if we are on tagged release and use
pre-compiled manpages if it is the case. Although perhaps option
(default?) to use pre-compiled manpages (even if they are outdated
a bit) instead of requiring asciidoc toolchain would be better;
this would make SRPM size larger, as it would contain manpages.
 

> * 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.

Perhaps we should first generate libexecdir separate from bindir,
and put helper scripts there (the *--* scripts), to not pollute
PATH with commands which are never meant to be called directly
by user.
 
> * bf/remote-head (Sun Dec 23 20:52:32 2007 -0500) 1 commit
>  . git-remote: make add -f guess HEAD, as clone does
> 
> I might have carefully looked at this in the past but I do not
> recall if there were issues.  Need re-reviewing and help from
> the list is appreciated.

I'd rather below get implemented, so there isn't any guessing
involved.
 
> * jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
>  . PARK: show-symref protocol extension.

What are the plans on git-clone builtinification (and cleaning up
clone progress and error messages[*1*])?

[*1*] http://texagon.blogspot.com/2008/02/let-play-git.html
-- 
Jakub Narebski
Poland
ShadeHawk on #git

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been kept out of 'master'.
Commits prefixed with '-' are only in 'pu' while commits
prefixed with '+' are in 'next'.  Now I am pushing 1.5.4.1 out,
mature topics will start moving to 'master'.

The topics list the commits in reverse chronological order.

My wish is to have small but short release cycle for 1.5.5 and
leave bigger ones cooking for 1.6.0.

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

* 00/config-null (Fri Feb 8 15:26:18 2008 +0100) 2 commits
 - builtin-gc.c: guard config parser from value=NULL
 - archive-tar.c: guard config parser from value=NULL

The "RFH from Janitors" topic.

* br/gitweb (Fri Feb 8 14:38:04 2008 -0200) 1 commit
 - gitweb: Use the config file to set repository owner's name.

Looked Ok.

* lt/revision-walker (Sat Feb 9 14:02:07 2008 -0800) 1 commit
 - Add "--show-all" revision walker flag for debugging

* mc/prefix (Sat Feb 9 15:40:19 2008 +0100) 1 commit
 - Avoid a useless prefix lookup in strbuf_expand()

* db/checkout (Sun Feb 10 01:27:00 2008 -0800) 21 commits
 - (PARK)
 - 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

This is building on top of Linus's change to in-core index
structure, which will be in 'master' soon.

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

* ph/describe-match (Mon Dec 24 12:18:22 2007 +0100) 2 commits
 + git-name-rev: add a --(no-)undefined option.
 + git-describe: Add a --match option to limit considered tags.

* lt/in-core-index (Tue Jan 22 23:01:13 2008 -0800) 9 commits
 + lazy index hashing
 + Create pathname-based hash-table lookup into index
 + read-cache.c: introduce is_racy_timestamp() helper
 + read-cache.c: fix a couple more CE_REMOVE conversion
 + Also use unpack_trees() in do_diff_cache()
 + Make run_diff_index() use unpack_trees(), not read_tree()
 + Avoid running lstat(2) on the same cache entry.
 + index: be careful when handling long names
 + Make on-disk index representation separate from in-core one

This is about reducing number of lstat(2) calls during complex
operations, and optimizing "do we have this in the index"
queries.  Most likely this will be the first series to be merged
to 'master'.

* jc/error-message-in-cherry-pick (Thu Jan 10 22:49:35 2008 -0800) 1 commit
 + Make error messages from cherry-pick/revert more sensible

Björn Steinbrink reported and then tested this.

* db/send-email-omit-cc (Tue Dec 25 19:56:29 2007 -0800) 1 commit
 + git-send-email: Generalize auto-cc recipient mechanism.

This came after 1.5.4-rc cycle started and was placed on hold.
I do not recall if there was any objection to it.

* mw/send-email (Sun Feb 3 19:53:58 2008 -0500) 3 commits
 + git-send-email: Better handling of EOF
 + git-send-email: SIG{TERM,INT} handlers
 + git-send-email: ssh/login style password requests

* db/no-separate-ls-remote-connection (Sun Feb 10 03:06:57 2008 +0000) 2 commits
 + Fix "git clone" for git:// protocol
 + Reduce the number of connects when fetching

----------------------------------------------------------------
[Actively Cooking]

* jc/setup (Sun Feb 3 23:59:17 2008 -0800) 4 commits
 + builtin-mv: minimum fix to avoid losing files
 + git-add: adjust to the get_pathspec() changes.
 + Make blame accept absolute paths
 + setup: sanitize absolute and funny paths in get_pathspec()

* jc/submittingpatches (Sun Feb 3 17:02:28 2008 -0800) 3 commits
 + Documentation/SubmittingPatches: What's Acked-by and Tested-by?
 + Documentation/SubmittingPatches: discuss first then submit
 + Documentation/SubmittingPatches: Instruct how to use [PATCH]
   Subject header

These I think are sensible but they did not see much discussion,
so they are parked here for now.

* sp/safecrlf (Wed Feb 6 12:25:58 2008 +0100) 1 commit
 + safecrlf: Add mechanism to warn about irreversible crlf
   conversions

* jk/noetcconfig (Wed Feb 6 05:11:53 2008 -0500) 2 commits
 + fix config reading in tests
 + allow suppressing of global and system config

* pb/prepare-commit-msg (Tue Feb 5 08:04:18 2008 +0100) 4 commits
 + git-commit: add a prepare-commit-msg hook
 + git-commit: Refactor creation of log message.
 + git-commit: set GIT_EDITOR=: if editor will not be launched
 + git-commit: support variable number of hook arguments

* jc/gitignore-ends-with-slash (Thu Jan 31 20:23:25 2008 -0800) 2 commits
 + gitignore: lazily find dtype
 + gitignore(5): Allow "foo/" in ignore list to match directory "foo"

This is redone after we had discussion on the list to properly
make "foo/" match only with directories and "foo" with both
files and directories without unnecessary lstat(2) calls.

* jc/apply-whitespace (Tue Jan 15 00:59:05 2008 -0800) 13 commits
 + core.whitespace: cr-at-eol
 + git-apply --whitespace=fix: fix whitespace fuzz introduced by
   previous run
 + builtin-apply.c: pass ws_rule down to match_fragment()
 + builtin-apply.c: move copy_wsfix() function a bit higher.
 + builtin-apply.c: do not feed copy_wsfix() leading '+'
 + builtin-apply.c: simplify calling site to apply_line()
 + builtin-apply.c: clean-up apply_one_fragment()
 + builtin-apply.c: mark common context lines in lineinfo structure.
 + builtin-apply.c: optimize match_beginning/end processing a bit.
 + builtin-apply.c: make it more line oriented
 + builtin-apply.c: push match-beginning/end logic down
 + builtin-apply.c: restructure "offset" matching
 + builtin-apply.c: refactor small part that matches context

* cc/browser (Sat Feb 9 07:11:01 2008 +0100) 8 commits
 + web--browse: Add a few quotes in 'init_browser_path'.
 + Documentation: instaweb: add 'git-web--browse' information.
 + Adjust .gitignore for 5884f1(Rename 'git-help--browse.sh'...)
 + git-web--browse: do not start the browser with nohup
 + instaweb: use 'git-web--browse' to launch browser.
 + Rename 'git-help--browse.sh' to 'git-web--browse.sh'.
 + help--browse: add '--config' option to check a config option for a
   browser.
 + help: make 'git-help--browse' usable outside 'git-help'.

Christian Couder consolidated the logic to pick user's favorite
browser between instaweb and help.

* bd/qsort (Tue Feb 5 15:10:44 2008 -0600) 1 commit
 + compat: Add simplified merge sort implementation from glibc

More reasonable qsort(3) than Microsoft by Brian Downing.

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

* 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.

* 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.

* bf/remote-head (Sun Dec 23 20:52:32 2007 -0500) 1 commit
 - git-remote: make add -f guess HEAD, as clone does

I might have carefully looked at this in the past but I do not
recall if there were issues.  Need re-reviewing and help from
the list is appreciated.

* ab/pserver (Fri Dec 14 04:08:51 2007 +0000) 1 commit
 - Authentication support for pserver

This needs careful security audit and a fix to its password
database format.  Plaintext in .git/config is not acceptable.

* jc/cherry-pick (Mon Dec 24 00:51:01 2007 -0800) 4 commits
 - PARK: 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.

Meant to avoid merge_recursive() during cherry-pick and revert,
so that D/F conflicts can be redone right, but I got busy and
this has unfortunately stalled.

* 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/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
 - Make "diff" Porcelain output paths as relative to subdirectory.

* jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
 - PARK: show-symref protocol extension.

* 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/rename (Tue Jan 29 20:54:56 2008 -0800) 1 commit
 - Optimize rename detection for a huge diff

Micro-optimization whose real world benefit is not proven.

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

[Jakub Narebski]

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

> * br/gitweb (Fri Feb 8 14:38:04 2008 -0200) 1 commit
>  - gitweb: Use the config file to set repository owner's name.
> 
> Looked Ok.

I assume that you have squashed commits: chaning gitweb.perl and
adding to gitweb/README?

I'd rather hear from Pasky first, but well...
 
> * jc/submittingpatches (Sun Feb 3 17:02:28 2008 -0800) 3 commits
>  + Documentation/SubmittingPatches: What's Acked-by and Tested-by?
>  + Documentation/SubmittingPatches: discuss first then submit
>  + Documentation/SubmittingPatches: Instruct how to use [PATCH]
>    Subject header
> 
> These I think are sensible but they did not see much discussion,
> so they are parked here for now.

I thing first and last are good to go, while second could get
improved. This means I guess either resending second patch for further
discussion, or adding it as is, and wait for further improvements; it
is better than nothing.
 
> * jc/gitignore-ends-with-slash (Thu Jan 31 20:23:25 2008 -0800) 2 commits
>  + gitignore: lazily find dtype
>  + gitignore(5): Allow "foo/" in ignore list to match directory "foo"
> 
> This is redone after we had discussion on the list to properly
> make "foo/" match only with directories and "foo" with both
> files and directories without unnecessary lstat(2) calls.

Nice. I like it.
 
> * 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.

Perhaps git should build with separate libexecdir, and at first move
only helper scripts (*--*) there? We can then check what would break,
a little safer. Helper scripts are not meant to be called by user
anyway...

> * ab/pserver (Fri Dec 14 04:08:51 2007 +0000) 1 commit
>  - Authentication support for pserver
> 
> This needs careful security audit and a fix to its password
> database format.  Plaintext in .git/config is not acceptable.

Does git-cvsserver understand .netrc?

> * bf/remote-head (Sun Dec 23 20:52:32 2007 -0500) 1 commit
>  - git-remote: make add -f guess HEAD, as clone does
> 
> I might have carefully looked at this in the past but I do not
> recall if there were issues.  Need re-reviewing and help from
> the list is appreciated.

> * jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
>  - PARK: show-symref protocol extension.

Do not the second cancels a bit of first?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Johannes Schindelin]

Hi,

On Sun, 10 Feb 2008, Jakub Narebski wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > * ab/pserver (Fri Dec 14 04:08:51 2007 +0000) 1 commit
> >  - Authentication support for pserver
> > 
> > This needs careful security audit and a fix to its password database 
> > format.  Plaintext in .git/config is not acceptable.
> 
> Does git-cvsserver understand .netrc?

It is not about the client side of authentication, but the server side.  
So no, git-cvsserver does not, and should not, understand .netrc.

Ciao,
Dscho

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> * br/gitweb (Fri Feb 8 14:38:04 2008 -0200) 1 commit
>>  - gitweb: Use the config file to set repository owner's name.
>> 
>> Looked Ok.
>
> I assume that you have squashed commits: chaning gitweb.perl and
> adding to gitweb/README?
>
> I'd rather hear from Pasky first, but well...

Thanks; will keep it on 'pu' for now.

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> * jc/submittingpatches (Sun Feb 3 17:02:28 2008 -0800) 3 commits
>>  + Documentation/SubmittingPatches: What's Acked-by and Tested-by?
>>  + Documentation/SubmittingPatches: discuss first then submit
>>  + Documentation/SubmittingPatches: Instruct how to use [PATCH]
>>    Subject header
>> 
>> These I think are sensible but they did not see much discussion,
>> so they are parked here for now.
>
> I thing first and last are good to go, while second could get
> improved. This means I guess either resending second patch for further
> discussion, or adding it as is, and wait for further improvements; it
> is better than nothing.

Ok.  As you can see above it's already merged to 'next', so here
is an update with pieces taken from my earlier response to your
question.

-- >8 --
[PATCH] Documentation/SubmittingPatches - a suggested patch flow

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

 Documentation/SubmittingPatches |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 0661293..0e155c9 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -230,6 +230,41 @@ to modify.  "Tested-by:" says the patch was tested by the person
 and found to have the desired effect.
 
 ------------------------------------------------
+An ideal patch flow
+
+Here is an ideal patch flow for this project the current maintainer
+suggests to the contributors:
+
+ (0) You come up with an itch.  You code it up.
+
+ (1) Send it to the list and cc people who may need to know about
+     the change.
+
+     The people who may need to know are the ones whose code you
+     are butchering.  These people happen to be the ones who are
+     most likely to be knowledgeable enough to help you, but
+     they have no obligation to help you (i.e. you ask for help,
+     don't demand).  "git log -p -- $area_you_are_modifying" would
+     help you find out who they are.
+
+ (2) You get comments and suggestions for improvements.  You may
+     even get them in a "on top of your change" patch form.
+
+ (3) Polish, refine, and re-send to the list and the people who
+     spend their time to improve your patch.  Go back to step (2).
+
+ (4) The list forms consensus that the last round of your patch is
+     good.  Send it to the list and cc the maintainer.
+
+ (5) A topic branch is created with the patch and is merged to 'next',
+     and cooked further and eventually graduates to 'master'.
+
+In any time between the (2)-(3) cycle, the maintainer may pick it up
+from the list and queue it to 'pu', in order to make it easier for
+people play with it without having to pick up and apply the patch to
+their trees themselves.
+
+------------------------------------------------
 MUA specific hints
 
 Some of patches I receive or pick up from the list share common

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been kept out of 'master'.
Commits prefixed with '-' are only in 'pu' while commits
prefixed with '+' are in 'next'.  Now I am pushing 1.5.4.1 out,
mature topics will start moving to 'master'.

The topics list the commits in reverse chronological order.

My wish is to have small but short release cycle for 1.5.5 and
leave bigger ones cooking for 1.6.0.

Many topics graduated to "master".  As announced, I'll rewind
and rebuild "next" with the surviving topics on top of "master"
shortly.

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

* ph/describe-match (Mon Dec 24 12:18:22 2007 +0100) 2 commits

* lt/in-core-index (Tue Jan 22 23:01:13 2008 -0800) 9 commits

This is about reducing number of lstat(2) calls during complex
operations, and optimizing "do we have this in the index"
queries.

* jc/error-message-in-cherry-pick (Thu Jan 10 22:49:35 2008 -0800) 1 commit

Björn Steinbrink reported and then tested this.

* db/send-email-omit-cc (Tue Dec 25 19:56:29 2007 -0800) 1 commit

This came after 1.5.4-rc cycle started and was placed on hold.
I do not recall if there was any objection to it.

* mw/send-email (Sun Feb 3 19:53:58 2008 -0500) 3 commits

* db/no-separate-ls-remote-connection (Sun Feb 10 13:45:08 2008 +0000) 1 commit

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

* br/gitweb (Fri Feb 8 14:38:04 2008 -0200) 1 commit
 - gitweb: Use the config file to set repository owner's name.

Looked Ok.

* lt/revision-walker (Sat Feb 9 14:02:07 2008 -0800) 1 commit
 - Add "--show-all" revision walker flag for debugging

* mc/prefix (Sat Feb 9 15:40:19 2008 +0100) 1 commit
 - Avoid a useless prefix lookup in strbuf_expand()

* db/checkout (Sun Feb 10 01:27:00 2008 -0800) 11 commits
 - 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

This is building on top of Linus's change to in-core index
structure, which will be in 'master' soon.

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

* jc/submittingpatches (Sun Feb 3 17:02:28 2008 -0800) 3 commits
 + Documentation/SubmittingPatches: What's Acked-by and Tested-by?
 + Documentation/SubmittingPatches: discuss first then submit
 + Documentation/SubmittingPatches: Instruct how to use [PATCH]
   Subject header

* jk/noetcconfig (Wed Feb 6 05:11:53 2008 -0500) 2 commits
 + fix config reading in tests
 + allow suppressing of global and system config

* pb/prepare-commit-msg (Tue Feb 5 08:04:18 2008 +0100) 4 commits
 + git-commit: add a prepare-commit-msg hook
 + git-commit: Refactor creation of log message.
 + git-commit: set GIT_EDITOR=: if editor will not be launched
 + git-commit: support variable number of hook arguments

* jc/gitignore-ends-with-slash (Thu Jan 31 20:23:25 2008 -0800) 2 commits
 + gitignore: lazily find dtype
 + gitignore(5): Allow "foo/" in ignore list to match directory "foo"

This is redone after we had discussion on the list to properly
make "foo/" match only with directories and "foo" with both
files and directories without unnecessary lstat(2) calls.

* bd/qsort (Tue Feb 5 15:10:44 2008 -0600) 1 commit
 + compat: Add simplified merge sort implementation from glibc

More reasonable qsort(3) than Microsoft by Brian Downing.

----------------------------------------------------------------
[Actively Cooking]

* cc/browser (Mon Feb 11 10:57:34 2008 -0500) 9 commits
 + git-web--browse: fix misplaced quote in init_browser_path()
 + web--browse: Add a few quotes in 'init_browser_path'.
 + Documentation: instaweb: add 'git-web--browse' information.
 + Adjust .gitignore for 5884f1(Rename 'git-help--browse.sh'...)
 + git-web--browse: do not start the browser with nohup
 + instaweb: use 'git-web--browse' to launch browser.
 + Rename 'git-help--browse.sh' to 'git-web--browse.sh'.
 + help--browse: add '--config' option to check a config option for a
   browser.
 + help: make 'git-help--browse' usable outside 'git-help'.

Christian Couder consolidated the logic to pick user's favorite
browser between instaweb and help.

* jc/setup (Sun Feb 3 23:59:17 2008 -0800) 4 commits
 + builtin-mv: minimum fix to avoid losing files
 + git-add: adjust to the get_pathspec() changes.
 + Make blame accept absolute paths
 + setup: sanitize absolute and funny paths in get_pathspec()

* sp/safecrlf (Wed Feb 6 12:25:58 2008 +0100) 1 commit
 + safecrlf: Add mechanism to warn about irreversible crlf
   conversions

* jc/apply-whitespace (Mon Feb 11 15:32:29 2008 -0800) 14 commits
 + apply: do not barf on patch with too large an offset
 + core.whitespace: cr-at-eol
 + git-apply --whitespace=fix: fix whitespace fuzz introduced by
   previous run
 + builtin-apply.c: pass ws_rule down to match_fragment()
 + builtin-apply.c: move copy_wsfix() function a bit higher.
 + builtin-apply.c: do not feed copy_wsfix() leading '+'
 + builtin-apply.c: simplify calling site to apply_line()
 + builtin-apply.c: clean-up apply_one_fragment()
 + builtin-apply.c: mark common context lines in lineinfo structure.
 + builtin-apply.c: optimize match_beginning/end processing a bit.
 + builtin-apply.c: make it more line oriented
 + builtin-apply.c: push match-beginning/end logic down
 + builtin-apply.c: restructure "offset" matching
 + builtin-apply.c: refactor small part that matches context

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

* 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".

* 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.

* bf/remote-head (Sun Dec 23 20:52:32 2007 -0500) 1 commit
 - git-remote: make add -f guess HEAD, as clone does

* ab/pserver (Fri Dec 14 04:08:51 2007 +0000) 1 commit
 - Authentication support for pserver

This needs careful security audit and a fix to its password
database format.  Plaintext in .git/config is not acceptable.

* jc/cherry-pick (Mon Dec 24 00:51:01 2007 -0800) 4 commits
 - PARK: 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.

Meant to avoid merge_recursive() during cherry-pick and revert,
so that D/F conflicts can be redone right, but I got busy and
this has unfortunately stalled.

* 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/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
 - diff --relative: output paths as relative to the current
   subdirectory

* jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
 - PARK: show-symref protocol extension.

* 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/rename (Tue Jan 29 20:54:56 2008 -0800) 1 commit
 - Optimize rename detection for a huge diff

Micro-optimization whose real world benefit is not proven.

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been kept out of 'master'.
Commits prefixed with '-' are only in 'pu' while commits
prefixed with '+' are in 'next'.

The topics list the commits in reverse chronological order.

Many topics graduated to 'master'.  As announced, I'll rewind
and rebuild "next" with the surviving topics on top of "master",
sometime tomorrow.

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

* lt/dirstat (Tue Feb 12 17:06:58 2008 -0800) 2 commits
 - diff: make --dirstat binary-file safe
 + Add "--dirstat" for some directory statistics

The first one already in 'next' is the latest toy Linus showed
off in his 2.6.25-rc2 announcement.  The other one on top is a
rework to make it work more sensibly with a tree with binary
contents.

* gp/hash-stdin (Thu Feb 14 20:13:55 2008 +0000) 1 commit
 - hash-object: cleanup handling of command line options

I've touched Gerrit's original up somewhat and am waiting for a
feedback.

* bc/fopen (Fri Feb 8 20:32:47 2008 -0600) 1 commit
 + Add compat/fopen.c which returns NULL on attempt to open directory

We would want fread(3) from fopen(3)'ed directory to fail but
some systems don't.  This adds a compatibility wrapper for
fopen(3) that fails on directories.

* js/maint-http-push (Thu Feb 14 23:26:12 2008 +0000) 3 commits
 + http-push: avoid a needless goto
 + http-push: do not get confused by submodules
 + http-push: avoid invalid memory accesses

This forks off of 'maint' in the hope of having a fixed
http-push in future 1.5.4.X.  Will wait for success stories.

* js/run-command (Sat Feb 16 18:36:39 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

* jc/bulk-allocate (Wed Feb 13 18:37:27 2008 -0800) 2 commits
 - Bulk allocate diff_filepair
 - patch freeable-bulk-alloc

* jk/empty-tree (Wed Feb 13 05:50:51 2008 -0500) 2 commits
 + add--interactive: handle initial commit better
 + hard-code the empty tree object

Jeff added code to deal with the initial commit case better in
"git-add -i".  Personally I wonder why we bother (if it is an
initial commit, the user _knows_ there is nothing to diff in the
HEAD as there is no HEAD yet, heavens), but the code is already
there so why not.

----------------------------------------------------------------
[Merged to 'master']

* jc/submittingpatches (Sun Feb 3 17:02:28 2008 -0800)

* jk/noetcconfig (Wed Feb 6 05:11:53 2008 -0500)

* pb/prepare-commit-msg (Tue Feb 5 08:04:18 2008 +0100)

* jc/gitignore-ends-with-slash (Thu Jan 31 20:23:25 2008 -0800)

* bd/qsort (Tue Feb 5 15:10:44 2008 -0600)

* cc/browser (Mon Feb 11 10:57:34 2008 -0500)

* sp/safecrlf (Wed Feb 6 12:25:58 2008 +0100)

----------------------------------------------------------------
[Actively Cooking]

* jc/setup (Sun Feb 3 23:59:17 2008 -0800) 4 commits
 + builtin-mv: minimum fix to avoid losing files
 + git-add: adjust to the get_pathspec() changes.
 + Make blame accept absolute paths
 + setup: sanitize absolute and funny paths in get_pathspec()

* lt/revision-walker (Sat Feb 9 14:02:07 2008 -0800) 1 commit
 + Add "--show-all" revision walker flag for debugging

* mc/prefix (Sat Feb 9 15:40:19 2008 +0100) 1 commit
 + Avoid a useless prefix lookup in strbuf_expand()

* db/checkout (Sat Feb 16 17:17:09 2008 -0800) 12 commits
 + 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.

* jc/apply-whitespace (Mon Feb 11 15:32:29 2008 -0800) 14 commits
 + apply: do not barf on patch with too large an offset
 + core.whitespace: cr-at-eol
 + git-apply --whitespace=fix: fix whitespace fuzz introduced by
   previous run
 + builtin-apply.c: pass ws_rule down to match_fragment()
 + builtin-apply.c: move copy_wsfix() function a bit higher.
 + builtin-apply.c: do not feed copy_wsfix() leading '+'
 + builtin-apply.c: simplify calling site to apply_line()
 + builtin-apply.c: clean-up apply_one_fragment()
 + builtin-apply.c: mark common context lines in lineinfo structure.
 + builtin-apply.c: optimize match_beginning/end processing a bit.
 + builtin-apply.c: make it more line oriented
 + builtin-apply.c: push match-beginning/end logic down
 + builtin-apply.c: restructure "offset" matching
 + builtin-apply.c: refactor small part that matches context

Further work on "apply --whitespace=fix".

* 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

* jc/rename (Tue Jan 29 20:54:56 2008 -0800) 1 commit
 + Optimize rename detection for a huge diff

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

* br/gitweb (Fri Feb 8 14:38:04 2008 -0200) 1 commit
 + gitweb: Use the config file to set repository owner's name.

On hold per Jakub's reluctance.

* 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".

* 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.

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

[Jeff King]

On Sat, Feb 16, 2008 at 07:59:57PM -0800, Junio C Hamano wrote: 
> * jk/empty-tree (Wed Feb 13 05:50:51 2008 -0500) 2 commits
>  + add--interactive: handle initial commit better
>  + hard-code the empty tree object
> 
> Jeff added code to deal with the initial commit case better in
> "git-add -i".  Personally I wonder why we bother (if it is an
> initial commit, the user _knows_ there is nothing to diff in the
> HEAD as there is no HEAD yet, heavens), but the code is already
> there so why not.

I was also tempted to just have it output "you can't do this, it's an
initial commit." But the change was fairly easy, and I think Kate's
point is valid: even though it's an unlikely corner case, new users are
likely to start exploring at that corner case, so it helps with new user
perception that we handle it gracefully.

-Peff

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

[Jakub Narebski]

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

> ----------------------------------------------------------------
> [New Topics]
> 
> * lt/dirstat (Tue Feb 12 17:06:58 2008 -0800) 2 commits
>  - diff: make --dirstat binary-file safe
>  + Add "--dirstat" for some directory statistics
> 
> The first one already in 'next' is the latest toy Linus showed
> off in his 2.6.25-rc2 announcement.  The other one on top is a
> rework to make it work more sensibly with a tree with binary
> contents.

Is this new one bytecount based rather than lines-changed based also
for text files?
 
> * js/run-command (Sat Feb 16 18:36:39 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

...and request for API documentation...
 
> * db/checkout (Sat Feb 16 17:17:09 2008 -0800) 12 commits
 
> Checkout rewritten in C.

Nice.
 
> ----------------------------------------------------------------
> [On Hold]
> 
> * br/gitweb (Fri Feb 8 14:38:04 2008 -0200) 1 commit
>  + gitweb: Use the config file to set repository owner's name.
> 
> On hold per Jakub's reluctance.

It was tested by the author (Bruno Ribas) that it doesn't affect
performance, although IMHO for a bit superficial test (1000 identical
repositories, gitweb run as a script, dd or git-for-each-ref as an
additional load).  I'd like to heard from larger gitweb deployments
how it works with a webserver (ApacheBench or similar), with a real
set of repositories, and perhaps in real load conditions... of course
on test gitweb, not on live one.

I also wonder if it would make sense to make it a feature,
i.e. instead of

+       if (!defined $owner){
+               $owner = git_get_project_config('owner');
+       }
        if (!defined $owner) {

have

+       if (!defined $owner){
+               $owner = gitweb_check_feature('owner');
+       }
        if (!defined $owner) {

with the 'owner' feature set as below:

+	'owner' => {
+		'sub' => \&feature_repo_owner,
+		'override' => 1,
+		'default' => [undef]},

and some implementation of feature_repo_owner.  This way it would be
possible to turn off checking for gitweb.owner in repo config from
withing gitweb config.  But this migh be an overingeneering...


I'd like to wait for a bit for comments, and if there wouldn't be any
negative ones, merge it in... and wait who screams ;-)
 
> * 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.

What about making separate libexecdir and moving _helper_ scripts
(*--*) there first?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Matthias Kestenholz]

On Sat, 2008-02-16 at 19:59 -0800, Junio C Hamano wrote:
> [...]

What about color.ui? I am still interested in a single central
configuration variable to enable colored output from git. I know that I
sent a proposal patch at a bad time.

Here is the last patch I sent to the list:

http://permalink.gmane.org/gmane.comp.version-control.git/70055

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

[Junio C Hamano]

Matthias Kestenholz <mk@spinlock.ch> writes:

> On Sat, 2008-02-16 at 19:59 -0800, Junio C Hamano wrote:
>> [...]
>
> What about color.ui? I am still interested in a single central
> configuration variable to enable colored output from git. I know that I
> sent a proposal patch at a bad time.

Yeah, I liked the general idea, and was about to forget.  I
vaguely recall there was a design disagreement between you and
Jeff King (perhaps others as well)?

I appreciate a reminder like your message, but I do not want to
be in the business of fishing for old patches that may or may
not { apply to | work well with } the updated base anymore for
everybody.  I wish I had the mental bandwidth to do so, but it
simply becomes infeasible in the longer run.

Could you (and anybody who has "sent but about to be or
suspected to be forgotten" changes) respin, retest and resend
please?

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

[Jeff King]

On Sun, Feb 17, 2008 at 10:10:50AM -0800, Junio C Hamano wrote:

> > What about color.ui? I am still interested in a single central
> > configuration variable to enable colored output from git. I know that I
> > sent a proposal patch at a bad time.
> 
> Yeah, I liked the general idea, and was about to forget.  I
> vaguely recall there was a design disagreement between you and
> Jeff King (perhaps others as well)?

IIRC, my objection was that the original implementation didn't correctly
preserve the existing split color types, but that the latest version of
the patch dealt with it.

> I appreciate a reminder like your message, but I do not want to
> be in the business of fishing for old patches that may or may
> not { apply to | work well with } the updated base anymore for
> everybody.  I wish I had the mental bandwidth to do so, but it
> simply becomes infeasible in the longer run.
> 
> Could you (and anybody who has "sent but about to be or
> suspected to be forgotten" changes) respin, retest and resend
> please?

Speaking as a reviewer, I second this. It is much easier to review
patches if they are up to date, and doubly so if the new cover letter
material gives a hint as to what happened the last time (e.g., "this
looked good, but we were in rc freeze", "somebody objected to X, and I
have fixed it", or even just "nobody said anything and it got
overlooked").

-Peff

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> * lt/dirstat (Tue Feb 12 17:06:58 2008 -0800) 2 commits
>>  - diff: make --dirstat binary-file safe
>>  + Add "--dirstat" for some directory statistics
>> 
>> The first one already in 'next' is the latest toy Linus showed
>> off in his 2.6.25-rc2 announcement.  The other one on top is a
>> rework to make it work more sensibly with a tree with binary
>> contents.
>
> Is this new one bytecount based rather than lines-changed based also
> for text files?

Short answer: Yes.

The issue in Linus's version is that the amount of change is
defined to be "number of lines added and deleted" for text files
while it is "number of bytes in preimage and postimage" for
binary files.  Summing them up and computing proportions among
them is comparing apples and oranges.

If you used line-based amount-of-change for text and byte-based
one for binary, you would be still comparing apples and oranges,
and you are not solving anything.  The scale used for all files
has to be consistent.

>> * br/gitweb (Fri Feb 8 14:38:04 2008 -0200) 1 commit
>>  + gitweb: Use the config file to set repository owner's name.
>> 
>> On hold per Jakub's reluctance.
> 
> It was tested by the author (Bruno Ribas) that it doesn't affect
> performance, although IMHO for a bit superficial test (1000 identical
> repositories, gitweb run as a script, dd or git-for-each-ref as an
> additional load).  I'd like to heard from larger gitweb deployments
> how it works with a webserver (ApacheBench or similar), with a real
> set of repositories, and perhaps in real load conditions... of course
> on test gitweb, not on live one.

I personally think the patch is Ok.  It would not affect really
large and loaded sites, because the top-level project list is
unusable for them without caching like John 'Warthog9' Hawley
does for k.org, due to other performance bottleneck (namely,
"the last changed timestamp") anyway.

By the way, I think "real load conditions" and "test gitweb not
live" are unfortunately mutually exclusive.  If it is known to
be "test", it will not attract the same set of "real" people as
the real one.

> I also wonder if it would make sense to make it a feature,

It might make sense, but it would not probably not help much in
practice.  It is overengineering, and I think it is spending
efforts in wrong place in the first place.

What I personally think the most important thing that should
happen to gitweb is to help cleaning up and updating John's
caching version that powers k.org, and update our version to
that.  John's version has seen a lot more real-life loads than
any other installation of the vanilla version in git.git, and we
should take advantage of his effort by slurping improvements
from his.  People who are both interested and have been involved
in gitweb might want to form a "gitweb-ng strike force" group,
and make a consolidated effort, just like msysgit folks do to
port our mess to Windows ;-).

>> * 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.
>
> What about making separate libexecdir and moving _helper_ scripts
> (*--*) there first?

Why keep suggesting adding _more_ work, without any code nor
discussion of how that would help?

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

[Jakub Narebski]

On Sun, 17 Feb 2008, Junio C Hamano <gitster@pobox.com> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> > Junio C Hamano <gitster@pobox.com> writes:
> 
>>> * br/gitweb (Fri Feb 8 14:38:04 2008 -0200) 1 commit
>>>  + gitweb: Use the config file to set repository owner's name.
>>> 
>>> On hold per Jakub's reluctance.
>> 
>> It was tested by the author (Bruno Ribas) that it doesn't affect
>> performance, although IMHO for a bit superficial test (1000 identical
>> repositories, gitweb run as a script, dd or git-for-each-ref as an
>> additional load).  I'd like to heard from larger gitweb deployments
>> how it works with a webserver (ApacheBench or similar), with a real
>> set of repositories, and perhaps in real load conditions... of course
>> on test gitweb, not on live one.
> 
> I personally think the patch is Ok.  It would not affect really
> large and loaded sites, because the top-level project list is
> unusable for them without caching like John 'Warthog9' Hawley
> does for k.org, due to other performance bottleneck (namely,
> "the last changed timestamp") anyway.

I was worrying that it would affect gitweb performance badly, in spite 
of (slightly superficial) benchmarks[*1*] testing it is not the case.
Benchmarks were as far as I can understand for Linux, and I worry a bit 
about other operating systems (MacOS X, MS Windows,...) with a higher 
fork cost... although I have slight suspicion that finding owner (not 
just an id of an owner) of a file (from Perl) is of similar cost.

BTW. after reading the thread again the load in benchmark was always 
generated by dd, not by running bunch of git-for-each-ref on different 
refs in parallel.

[*1*] Whose benchmarks should be at least mentioned IMHO in commit 
message; also update to gitweb/README should be IMHO in the same commit 
(while $path/$project -> $git_dir could, but not necessarily should, be 
in separate cleanup patch).
 
> By the way, I think "real load conditions" and "test gitweb not
> live" are unfortunately mutually exclusive.  If it is known to
> be "test", it will not attract the same set of "real" people as
> the real one.

You can always stat, and generate test load with the same stats,
perhaps cut to the page / feature you are benchmarking / profiling.

By "read load conditions" I meant here running second gitweb with or 
without the gitweb.owner patch on the same server as live gitweb. But 
that would affect repetability of benchmark, although I'm not sure if 
it matters; it probably depends on how variable load is, on how 
sensitive benchmark is to detailed load, etc.
 
>> I also wonder if it would make sense to make it a feature,
> 
> It might make sense, but it would not probably not help much in
> practice.  It is overengineering, and I think it is spending
> efforts in wrong place in the first place.

I guess that after waiting a bit for comments you could either apply 
patches, apply patches squashed, or ask Bruno Ribas for resend.

I would then send patch making it a "feature" (where the important bit 
is 'override' part, and 'defaults' does not matter), you would then 
reject it because it is overengineering ;-) or not; but it would be in 
achives.
 
> What I personally think the most important thing that should
> happen to gitweb is to help cleaning up and updating John's
> caching version that powers k.org, and update our version to
> that.  John's version has seen a lot more real-life loads than
> any other installation of the vanilla version in git.git, and we
> should take advantage of his effort by slurping improvements
> from his.  People who are both interested and have been involved
> in gitweb might want to form a "gitweb-ng strike force" group,
> and make a consolidated effort, just like msysgit folks do to
> port our mess to Windows ;-).

This would be really nice. IIRC John said that he would try to find time 
to update kernel.org gitweb to latest, I guess sending caching patches 
for gitweb to the list (or a please pull request).

It was a bit unfortunate that J.H. split gitweb into many smaller 
modules to better understand code when adding caching support, the move 
which was not accepted for "mainline" gitweb, thus effectively creating 
a fork.


BTW it would be nice to have benchmark of different web interfaces under 
heavly load: gitweb, repo.or.cz gitweb, kernel.org gitweb, cgit, wit 
(the Ruby one), git-php, gitarella (if it is developed),...


>>> * 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.
>>
>> What about making separate libexecdir and moving _helper_ scripts
>> (*--*) there first?
> 
> Why keep suggesting adding _more_ work, without any code nor
> discussion of how that would help?

I'm sorry. 

To start discussion: :-)

1. Currently tests check _built_ version:

   # Test the binaries we have just built.  The tests are kept in
   # t/ subdirectory and are run in trash subdirectory.

   It would be nice if there were a switch which would allow to test
   _installed_ (somewhere) version of git, to check for errors like
   some script not finding some command etc.

2. Where to put gitexecdir? /usr/libexec is not in FHS...

-- 
Jakub Narebski
Poland

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> 1. Currently tests check _built_ version:
>
>    # Test the binaries we have just built.  The tests are kept in
>    # t/ subdirectory and are run in trash subdirectory.
>
>    It would be nice if there were a switch which would allow to test
>    _installed_ (somewhere) version of git, to check for errors like
>    some script not finding some command etc.

If you are saying _in addition_ I would not stop you, but I am
not interested in testing installed version at all.  Testing
after installing is already too late.

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

[Jakub Narebski]

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > 1. Currently tests check _built_ version:
> >
> >    # Test the binaries we have just built.  The tests are kept in
> >    # t/ subdirectory and are run in trash subdirectory.
> >
> >    It would be nice if there were a switch which would allow to test
> >    _installed_ (somewhere) version of git, to check for errors like
> >    some script not finding some command etc.
> 
> If you are saying _in addition_ I would not stop you, but I am
> not interested in testing installed version at all.  Testing
> after installing is already too late.

Of course I'm saying "in addition": I wrote "if there were a switch",
meaning that current running test for built git would be default, and
after setting some environment variable for example it would test
installed (or rather pre-installed) version.

It would be testing halfway during installing: we should install to some 
DESTDIR (like rpm does when building from SRPM), 
e.g. /tmp/git-<version>-root/, or something like that.

-- 
Jakub Narebski
Poland

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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

* 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 (Tue Feb 19 02:40:35 2008 -0500) 8 commits
 + 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.

* 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/host-alias (Mon Feb 18 23:28:38 2008 -0500) 2 commits
 - Add support for host aliases in config files
 - Use ALLOC_GROW in remote.{c,h}

Allows URLs used in pushing and fetching to be rewritten.
This is an older round of the series.

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

* bc/fopen (Fri Feb 8 20:32:47 2008 -0600) 1 commit
 + Add compat/fopen.c which returns NULL on attempt to open directory

We would want fread(3) from fopen(3)'ed directory to fail but
some systems don't.  This adds a compatibility wrapper for
fopen(3) that fails on directories.

* js/maint-http-push (Thu Feb 14 23:26:12 2008 +0000) 3 commits
 + http-push: avoid a needless goto
 + http-push: do not get confused by submodules
 + http-push: avoid invalid memory accesses

This forks off of 'maint' in the hope of having a fixed
http-push in future 1.5.4.X.

* jk/empty-tree (Wed Feb 13 05:50:51 2008 -0500) 2 commits
 + add--interactive: handle initial commit better
 + hard-code the empty tree object

Deals with the initial commit case better in "git-add -i".

* jc/setup (Sun Feb 3 23:59:17 2008 -0800) 4 commits
 + builtin-mv: minimum fix to avoid losing files
 + git-add: adjust to the get_pathspec() changes.
 + Make blame accept absolute paths
 + setup: sanitize absolute and funny paths in get_pathspec()

Works better when an absolute path into work tree is given where
a relative paths is expected.

* lt/revision-walker (Sat Feb 9 14:02:07 2008 -0800) 1 commit
 + Add "--show-all" revision walker flag for debugging

* mc/prefix (Sat Feb 9 15:40:19 2008 +0100) 1 commit
 + Avoid a useless prefix lookup in strbuf_expand()

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

* jc/apply-whitespace (Mon Feb 11 15:32:29 2008 -0800) 14 commits
 + apply: do not barf on patch with too large an offset
 + core.whitespace: cr-at-eol
 + git-apply --whitespace=fix: fix whitespace fuzz introduced by
   previous run
 + builtin-apply.c: pass ws_rule down to match_fragment()
 + builtin-apply.c: move copy_wsfix() function a bit higher.
 + builtin-apply.c: do not feed copy_wsfix() leading '+'
 + builtin-apply.c: simplify calling site to apply_line()
 + builtin-apply.c: clean-up apply_one_fragment()
 + builtin-apply.c: mark common context lines in lineinfo structure.
 + builtin-apply.c: optimize match_beginning/end processing a bit.
 + builtin-apply.c: make it more line oriented
 + builtin-apply.c: push match-beginning/end logic down
 + builtin-apply.c: restructure "offset" matching
 + builtin-apply.c: refactor small part that matches context

Further work on "apply --whitespace=fix".

----------------------------------------------------------------
[Actively Cooking]

* lt/dirstat (Tue Feb 12 17:06:58 2008 -0800) 2 commits
 - diff: make --dirstat binary-file safe
 + Add "--dirstat" for some directory statistics

The first one already in 'next' is the latest toy Linus showed
off in his 2.6.25-rc2 announcement.  The other one on top is a
rework to make it work more sensibly with a tree with binary
contents.

* db/checkout (Wed Feb 20 15:54:54 2008 -0800) 16 commits
 + 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.  With a few recent fixes, I think this
is approaching to be usable on "master".

* 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

* jc/rename (Tue Jan 29 20:54:56 2008 -0800) 1 commit
 + Optimize rename detection for a huge diff

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

* gp/hash-stdin (Thu Feb 14 20:13:55 2008 +0000) 1 commit
 - hash-object: cleanup handling of command line options

I've touched Gerrit's original up somewhat and am still waiting
for a feedback.

* js/run-command (Sat Feb 16 18:36:39 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

* jc/bulk-allocate (Wed Feb 13 18:37:27 2008 -0800) 2 commits
 - Bulk allocate diff_filepair
 - patch freeable-bulk-alloc

* 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".

* 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.

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

[Johannes Schindelin]

Hi,

On Wed, 20 Feb 2008, Junio C Hamano wrote:

> ----------------------------------------------------------------
> [New Topics]
> 
> * js/branch-track (Tue Feb 19 11:24:38 2008 -0500) 2 commits

Heh, now it gets confusing ;-) Three regular contributors with the same 
initials? ;-)

> * 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.

The question is: what to do about ALNUM.  Use it in merge-recursive?  Make 
it a config variable?

> * 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.

The question is now: should we initialise remote.origin.push to HEAD like 
you said?  And if so, shouldn't we have git-remote's "add" do the same?

Speaking of which, I think it would make sense to teach git-remote's "add" 
to detect if you are installing a remote "origin" and set up 
branch.$(git symbolic-ref HEAD).{remote,merge} like clone would.  After 
all, if you are setting up "origin", chances are that you just initialised 
a remote repository with your current one.

Thoughts?

> * 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?

> * 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.

I think this is a good plan.  Better safe 'n sorry.

Ciao,
Dscho

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

[Junio C Hamano]

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

>> * 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.
>
> The question is: what to do about ALNUM.  Use it in merge-recursive?  Make 
> it a config variable?

I'd say we'll leave it as is for now and use it everywhere later
after making sure things work out Ok.

>> * 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.
>
> The question is now: should we initialise remote.origin.push to HEAD like 
> you said?  And if so, shouldn't we have git-remote's "add" do the same?

Perhaps we do not do anything further for now, other than
telling shared repository people to put it in their config and
see how well the behaviour matches their expectation.  Protocol
extensions to let clone notice what the other end is can come
later (and we would need to do that anyway to set up HEAD symref
as well).  The same mechanism would be used in "git remote add",
and at that point clone could be implemented as "init/remote
add/fetch/checkout".

>> * 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?

I've been waiting for somebody to come up with a clean "pop", as
it probably is easy enough and would be an itch people other
than you and me can scratch.

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

[Brandon Casey]

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 error message in
two ways.

  1) If a reflog entry is deleted in the middle of the reflog, then
     read_ref_at() will print an error message "warning: Log %s has
     gap after %s". This is a sanity check which checks that the
     previous reflog entry's "new" sha1 is equal to the current reflog
     entry's "old" sha1.

  2) If the top-most reflog entry does not match what is in refs/<ref>
     then read_ref_at() will print an error message "warning: Log %s
     unexpectedly ended on %s". This is another sanity check.

We can either disable these sanity checks, or change the code to ensure that
they pass, or do nothing in which case 'reflog delete' should probably be
removed.

For the first issue, we could rewrite the "old" sha1 while expiring reflog
entries. We would lose some of the meaning of reflog entries in this case.

For the second issue, the ref needs to be rewritten with the sha1 of the
top-most reflog entry. This makes sense for stash, but not for any other
ref.

I'm thinking that two new options to git-reflog are needed which will
implement the above two ideas. One will rewrite the "old" sha1 for each
reflog entry so that it points to the previous entry. The other will
update the ref so that it points at the top-most reflog entry.

thoughts? suggestion for the names for the options?

-brandon

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

[Junio C Hamano]

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.

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

[Brandon Casey]

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

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

[Junio C Hamano]

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".

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

[Junio C Hamano]

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

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

[Brandon Casey]

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

----------------------------------------------------------------
[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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

----------------------------------------------------------------
[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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

----------------------------------------------------------------
[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.

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

[Shawn O. Pearce]

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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

----------------------------------------------------------------
[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.

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

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

----------------------------------------------------------------
[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.

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

[Johannes Schindelin]

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

----------------------------------------------------------------
[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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

----------------------------------------------------------------
[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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

----------------------------------------------------------------
[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.

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

[Johannes Schindelin]

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

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

[Samuel Tardieu]

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/

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

[Steffen Prohaska]

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

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

[Junio C Hamano]

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)?

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

[Junio C Hamano]

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.

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

[Govind Salinas]

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

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

[Samuel Tardieu]

>>>>> "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/

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

[Junio C Hamano]

"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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

----------------------------------------------------------------
[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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

----------------------------------------------------------------
[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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

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

[Kristian Høgsberg]

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

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

[Junio C Hamano]

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.

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

[Johannes Schindelin]

[-- 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"

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

[Junio C Hamano]

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 ;-)

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

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

[Jeff King]

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

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

[Johannes Schindelin]

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

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

[Lars Hjemli]

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

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

[Junio C Hamano]

"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.

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

[Brandon Casey]

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

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.

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

[Ping Yin]

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

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

[Josef Weidendorfer]

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").

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

[Ping Yin]

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

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

[Johannes Schindelin]

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

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

[Josef Weidendorfer]

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

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

[Michele Ballabio]

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?

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

[Junio C Hamano]

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?

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

[Ping Yin]

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

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

[Ping Yin]

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

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

[Ping Yin]

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

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

[Michele Ballabio]

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.

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

[Fedor Sergeev]

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.

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

[Ping Yin]

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

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

[Robin Rosenberg]

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

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

[Fedor Sergeev]

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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

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

[Ping Yin]

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

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

[Junio C Hamano]

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

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

[Junio C Hamano]

Adam, I am very sorry, but the message was misdirected.

I'm resending it now to ask for comments from Avery.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

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

[Daniel Barkalow]

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)

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

[Junio C Hamano]

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 ;-).
.

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

[Steffen Prohaska]

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

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

[Johannes Schindelin]

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

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

[Junio C Hamano]

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 ;-)?

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

[Daniel Barkalow]

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*

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

[Stephan Beyer]

[-- 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 --]

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

[PATCH] git-diff: allow --no-index semantics a bit more

[Junio C Hamano]

Even when inside a git work tree, if two paths are given and at least one
is clearly outside the work tree, it cannot be a request to diff a tracked
path anyway; allow such an invocation to use --no-index semantics.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 > * 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.

 And this should hopefully be enough.

 diff-no-index.c |   39 ++++++++++++++++++++++++++++++++-------
 1 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/diff-no-index.c b/diff-no-index.c
index 1b57fee..b1ae791 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -144,6 +144,25 @@ static int queue_diff(struct diff_options *o,
 	}
 }
 
+static int path_outside_repo(const char *path)
+{
+	/*
+	 * We have already done setup_git_directory_gently() so we
+	 * know we are inside a git work tree already.
+	 */
+	const char *work_tree;
+	size_t len;
+
+	if (!is_absolute_path(path))
+		return 0;
+	work_tree = get_git_work_tree();
+	len = strlen(work_tree);
+	if (strncmp(path, work_tree, len) ||
+	    (path[len] != '\0' && path[len] != '/'))
+		return 1;
+	return 0;
+}
+
 void diff_no_index(struct rev_info *revs,
 		   int argc, const char **argv,
 		   int nongit, const char *prefix)
@@ -162,13 +181,19 @@ void diff_no_index(struct rev_info *revs,
 			break;
 	}
 
-	/*
-	 * No explicit --no-index, but "git diff --opts A B" outside
-	 * a git repository is a cute hack to support.
-	 */
-	if (!no_index && !nongit)
-		return;
-
+	if (!no_index && !nongit) {
+		/*
+		 * Inside a git repository, without --no-index.  Only
+		 * when a path outside the repository is given,
+		 * e.g. "git diff /var/tmp/[12]", or "git diff
+		 * Makefile /var/tmp/Makefile", allow it to be used as
+		 * a colourful "diff" replacement.
+		 */
+		if ((argc != i + 2) ||
+		    (!path_outside_repo(argv[i]) &&
+		     !path_outside_repo(argv[i+1])))
+			return;
+	}
 	if (argc != i + 2)
 		die("git diff %s takes two paths",
 		    no_index ? "--no-index" : "[--no-index]");
-- 
1.5.6.rc0.13.g2d392

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

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

[Jon Loeliger]

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

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

[Steven Grimm]

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

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

[Stephan Beyer]

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

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

[Jakub Narebski]

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

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

[Sebastian Bober]

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

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

[Johannes Schindelin]

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

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

[Shawn O. Pearce]

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.

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

[Johannes Schindelin]

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

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

[Junio C Hamano]

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.

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

[Johannes Schindelin]

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

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

[Johannes Schindelin]

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

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

[Johan Herland]

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

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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.

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

[Miklos Vajna]

[-- 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 --]

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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

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

[Miklos Vajna]

[-- 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 --]

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

[Junio C Hamano]

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.

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

[Pieter de Bie]

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

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

[Pieter de Bie]

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.

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

[Miklos Vajna]

[-- 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 --]

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

[Johannes Schindelin]

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

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

[Miklos Vajna]

[-- 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 --]

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

[Johannes Schindelin]

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

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

[Jakub Narebski]

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

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

[Johannes Schindelin]

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

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

[Jakub Narebski]

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

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

[Junio C Hamano]

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?

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

[Miklos Vajna]

[-- 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 --]

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

[Junio C Hamano]

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?

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

[Miklos Vajna]

[-- 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 --]

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

[Jakub Narebski]

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

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

[Junio C Hamano]

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

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

[しらいしななこ]

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/

[PATCH] Keep some git-* programs in $(bindir)

[Junio C Hamano]

Otherwise remote executions directly over ssh won't find them as they used
to.  --upload-pack and --receive-pack options _could_ be used on the
client side, but things should keep working out-of-box for older clients.

Later versions of clients (fetch-pack and send-pack) probably could start
asking for these programs with dashless form, but that is a different
topic.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * しらいしななこ <nanako3@lavabit.com> writes:
 > Doesn't "git archive --remote=<repo>" also execute git program on a remote machine?

 Ok, how about this?

 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 929136b..742e7d3 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 git-archive$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
-- 
1.5.6.56.g29b0d

[PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

The daemon expects to see the dashed form and we cannot change older
servers.  But when invoking programs on the remote end over SSH, the
command line the client side build is under client's control.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * This I haven't even compile tested at all, but it feels right.  We
   probably should do this before bindir=>libexecdir move; as long as this
   is in place on the client side the version running on the server end
   should not matter.

 connect.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/connect.c b/connect.c
index e92af29..fd1da26 100644
--- a/connect.c
+++ b/connect.c
@@ -589,6 +589,10 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 	conn = xcalloc(1, sizeof(*conn));
 
 	strbuf_init(&cmd, MAX_CMD_LEN);
+	if (protocol != PROTO_GIT && !strncmp(prog, "git-", 4)) {
+		strbuf_addstr(&cmd, "git ");
+		prog += 4;
+	}
 	strbuf_addstr(&cmd, prog);
 	strbuf_addch(&cmd, ' ');
 	sq_quote_buf(&cmd, path);
-- 
1.5.6.56.g29b0d

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

[Shawn O. Pearce]

 <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.

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

[Shawn O. Pearce]

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.

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> The daemon expects to see the dashed form and we cannot change older
> servers.  But when invoking programs on the remote end over SSH, the
> command line the client side build is under client's control.
...
> diff --git a/connect.c b/connect.c
> index e92af29..fd1da26 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -589,6 +589,10 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
>  	conn = xcalloc(1, sizeof(*conn));
>  
>  	strbuf_init(&cmd, MAX_CMD_LEN);
> +	if (protocol != PROTO_GIT && !strncmp(prog, "git-", 4)) {
> +		strbuf_addstr(&cmd, "git ");
> +		prog += 4;
> +	}

Nack on that implementation.

I think this is a problem for systems based on say gitosis,
or some pattern like it.  Day-job doesn't use gitosis, but
has switched to a Perl based forced ssh tool that smells a
lot like gitosis.  Gitosis is popular.

github probably uses something similar.  But nobody knows (or
probably cares) since they don't release their source.

gitosis is likely looking for "$git-upload-pack '(.*)'$" to be
in the $SSH_ORIGINAL_COMMAND environment variable, if you send
"git upload-pack 'path.git'" I think its going to reject.

What's really bad about your patch is you cannot work around it as a
user by setting --upload-pack on the command line, or in the config,
because down at the very deepest level you are switching the "git-"
to "git " and ignoring what the user has supplied you.

Sorry, but I think this change needs to go higher up, to the default
values that --upload-pack and remote.$name.uploadpack override,
so the user can at least work around it when we break her ability
to use github, gitosis, or anything like it.

-- 
Shawn.

Re: [PATCH] Keep some git-* programs in $(bindir)

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
>  * しらいしななこ <nanako3@lavabit.com> writes:
>  > Doesn't "git archive --remote=<repo>" also execute git program on a remote machine?
> 
> diff --git a/Makefile b/Makefile
> index 929136b..742e7d3 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 git-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'

I think you mean git-upload-archive, given what daemon.c says.
Or line 34 of builtin-archive.c, which calls git-upload-archive
by way of git_connect().

-- 
Shawn.

Re: [PATCH] Keep some git-* programs in $(bindir)

[Daniel Barkalow]

On Tue, 24 Jun 2008, Junio C Hamano wrote:

> Otherwise remote executions directly over ssh won't find them as they used
> to.  --upload-pack and --receive-pack options _could_ be used on the
> client side, but things should keep working out-of-box for older clients.
> 
> Later versions of clients (fetch-pack and send-pack) probably could start
> asking for these programs with dashless form, but that is a different
> topic.

Should they use "git upload-pack" or should they look for their helper 
programs in a libexec dir? I don't think that either of these programs is 
useful to run independantly, but I don't know if finding a program that 
doesn't go in $PATH on a remote machine is going to be any fun.

	-Daniel
*This .sig lefti ntentionally blank*

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Sorry, but I think this change needs to go higher up, to the default
> values that --upload-pack and remote.$name.uploadpack override,
> so the user can at least work around it when we break her ability
> to use github, gitosis, or anything like it.

Well, the thing is, "higher up" would not have enough clue to see if it
needs to give dashed form (for git-daemon) or space form (for ssh), so
that suggestion won't help much.

I do not care too much about closed source service, but gitosis should be
able to update the pattern to allow "git[ -]upload-pack" reasonably
easily.

Any other suggestions that is workable?

Re: [PATCH] Keep some git-* programs in $(bindir)

[Shawn O. Pearce]

Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 24 Jun 2008, Junio C Hamano wrote:
> 
> > Otherwise remote executions directly over ssh won't find them as they used
> > to.  --upload-pack and --receive-pack options _could_ be used on the
> > client side, but things should keep working out-of-box for older clients.
> > 
> > Later versions of clients (fetch-pack and send-pack) probably could start
> > asking for these programs with dashless form, but that is a different
> > topic.
> 
> Should they use "git upload-pack" or should they look for their helper 
> programs in a libexec dir? I don't think that either of these programs is 
> useful to run independantly, but I don't know if finding a program that 
> doesn't go in $PATH on a remote machine is going to be any fun.

IMHO they should in the future use "git upload-pack".

But this may not work with all servers, especially those that
use $SSH_ORIGINAL_COMMAND to dispatch to the correct command,
or abort if the user tries to request something dangerous.
Gitosis comes to mind.

I'm not sure we can get away with doing this in 1.6.0 as it is
effectively a network protocol breakage.  We have thus far never
caused a newer client to fail talking to an older server.  I'm
not sure we should start doing that in 1.6.0.

My vote is we keep the dashed form of these 3 commands in the
$PATH during 1.6 and remove them in 1.7, but when we do it we
must ensure there is a way to still request dashed form found
through $PATH when passing --upload-pack as an argument.

-- 
Shawn.

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Sorry, but I think this change needs to go higher up, to the default
> > values that --upload-pack and remote.$name.uploadpack override,
> > so the user can at least work around it when we break her ability
> > to use github, gitosis, or anything like it.
> 
> Well, the thing is, "higher up" would not have enough clue to see if it
> needs to give dashed form (for git-daemon) or space form (for ssh), so
> that suggestion won't help much.

Actually I'd go the other direction.  Allow the higher up level
to supply "git upload-pack" and convert it to git- for the git://
protocol.  Possible patch below.

> I do not care too much about closed source service, but gitosis should be
> able to update the pattern to allow "git[ -]upload-pack" reasonably
> easily.

Pasky also has to update:

$ git ls-remote --upload-pack='git upload-pack' repo.or.cz:/srv/git/egit.git
fatal: unrecognized command 'git upload-pack '/srv/git/egit.git''
fatal: The remote end hung up unexpectedly

;-)
 
> Any other suggestions that is workable?

diff --git a/builtin-clone.c b/builtin-clone.c
index 5c5acb4..98d0f0f 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare;
 static int option_local, option_no_hardlinks, option_shared;
 static char *option_template, *option_reference, *option_depth;
 static char *option_origin = NULL;
-static char *option_upload_pack = "git-upload-pack";
+static char *option_upload_pack = "git upload-pack";
 
 static struct option builtin_clone_options[] = {
 	OPT__QUIET(&option_quiet),
@@ -58,7 +58,7 @@ static struct option builtin_clone_options[] = {
 	OPT_STRING('o', "origin", &option_origin, "branch",
 		   "use <branch> instead or 'origin' to track upstream"),
 	OPT_STRING('u', "upload-pack", &option_upload_pack, "path",
-		   "path to git-upload-pack on the remote"),
+		   "path to git upload-pack on the remote"),
 	OPT_STRING(0, "depth", &option_depth, "depth",
 		    "create a shallow clone of that depth"),
 
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index f4dbcf0..b0efd01 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -14,7 +14,7 @@ static int transfer_unpack_limit = -1;
 static int fetch_unpack_limit = -1;
 static int unpack_limit = 100;
 static struct fetch_pack_args args = {
-	/* .uploadpack = */ "git-upload-pack",
+	/* .uploadpack = */ "git upload-pack",
 };
 
 static const char fetch_pack_usage[] =
diff --git a/connect.c b/connect.c
index e92af29..dbabd93 100644
--- a/connect.c
+++ b/connect.c
@@ -576,8 +576,8 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 		 * from extended components with a NUL byte.
 		 */
 		packet_write(fd[1],
-			     "%s %s%chost=%s%c",
-			     prog, path, 0,
+			     "git-%s %s%chost=%s%c",
+			     prog + 4, path, 0,
 			     target_host, 0);
 		free(target_host);
 		free(url);
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 695a409..0f82a93 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -255,10 +255,10 @@ get_uploadpack () {
 	case "$data_source" in
 	config)
 		uplp=$(git config --get "remote.$1.uploadpack")
-		echo ${uplp:-git-upload-pack}
+		echo ${uplp:-git upload-pack}
 		;;
 	*)
-		echo "git-upload-pack"
+		echo "git upload-pack"
 		;;
 	esac
 }
diff --git a/transport.c b/transport.c
index 3ff8519..351b7f5 100644
--- a/transport.c
+++ b/transport.c
@@ -762,10 +762,10 @@ struct transport *transport_get(struct remote *remote, const char *url)
 
 		data->thin = 1;
 		data->conn = NULL;
-		data->uploadpack = "git-upload-pack";
+		data->uploadpack = "git upload-pack";
 		if (remote && remote->uploadpack)
 			data->uploadpack = remote->uploadpack;
-		data->receivepack = "git-receive-pack";
+		data->receivepack = "git receive-pack";
 		if (remote && remote->receivepack)
 			data->receivepack = remote->receivepack;
 	}

-- 
Shawn.

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

>> Any other suggestions that is workable?
>
> diff --git a/builtin-clone.c b/builtin-clone.c
> index 5c5acb4..98d0f0f 100644
> --- a/builtin-clone.c
> +++ b/builtin-clone.c
> @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare;

<< a patch to conditionally change "git-program" default to "git program"
snipped >>

How would that help client that talk with git-daemon, unlike what I sent
earlier?

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

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

> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>>> Any other suggestions that is workable?
>>
>> diff --git a/builtin-clone.c b/builtin-clone.c
>> index 5c5acb4..98d0f0f 100644
>> --- a/builtin-clone.c
>> +++ b/builtin-clone.c
>> @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare;
>
> << a patch to conditionally change "git-program" default to "git program"
> snipped >>

Typofix: s/cond/uncond/;

> How would that help client that talk with git-daemon, unlike what I sent
> earlier?

If we force --upload-pack workaround to _everybody_ we are already lost.

Also I think the previous one still lets you work it around by giving a
full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not
match "git-" ;-)

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

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

> If we force --upload-pack workaround to _everybody_ we are already lost.
>
> Also I think the previous one still lets you work it around by giving a
> full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not
> match "git-" ;-)

Ok, let's map this out seriously.

* 1.6.0 will install the server-side programs in $(bindir) so that 
  people coming over ssh will find them on the $PATH

* In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both
  "git-program" and "git program" forms.  When the spaced form is used, it
  will behave as if the dashed form is requested.  This is a prerequisite
  for client side change to start asking for "git program".

* In the near future, there will no client-side change.  "git-program"
  will be asked for.

* 6 months after 1.6.0 ships, hopefully all the deployed server side will
  be running that version or newer.  Client side will start asking for
  "git program" by default, but we can still override with --upload-pack
  and friends.

* 12 months after client side changes, everybody will be running that
  version or newer.  We stop installing the server side programs in
  $(bindir) but people coming over ssh will be asking for "git program"
  and "git" will be on the $PATH so there is no issue.

The above 6 and 12 are yanked out of thin air and I am of course open to
tweaking them, but I think the above order of events would be workable.

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Pasky also has to update:
>
> $ git ls-remote --upload-pack='git upload-pack' repo.or.cz:/srv/git/egit.git
> fatal: unrecognized command 'git upload-pack '/srv/git/egit.git''
> fatal: The remote end hung up unexpectedly

Of course.  I am assuming that he runs git-shell for user account, and
that's what the change in 'next' is about.

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> > "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> >>> Any other suggestions that is workable?
> >>
> >> diff --git a/builtin-clone.c b/builtin-clone.c
> >> index 5c5acb4..98d0f0f 100644
> >> --- a/builtin-clone.c
> >> +++ b/builtin-clone.c
> >> @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare;
> >
> > << a patch to conditionally change "git-program" default to "git program"
> > snipped >>

Shouldn't "git upload-pack" work on the server side as far back as
0.99.9k?  That's back really old.  And my patch fixed "git " to be
"git-" when talking to git-daemon, thus keeping clients compatible
with all current git:// servers.

For SSH servers that can't handle "git upload-pack" the user can
change it to --upload-pack=git-upload-pack and get back to the
old behavior, until the server operator can upgrade.

Your patch doesn't offer that work around on the client side.
 
> Typofix: s/cond/uncond/;
> 
> > How would that help client that talk with git-daemon, unlike what I sent
> > earlier?

Check my change in git_connect again:

diff --git a/connect.c b/connect.c
index e92af29..dbabd93 100644
--- a/connect.c
+++ b/connect.c
@@ -576,8 +576,8 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 		 * from extended components with a NUL byte.
 		 */
 		packet_write(fd[1],
-			     "%s %s%chost=%s%c",
-			     prog, path, 0,
+			     "git-%s %s%chost=%s%c",
+			     prog + 4, path, 0,
 			     target_host, 0);
 		free(target_host);
 		free(url);

Its buggy if the user tried to do "git ls-remote --upload-pack=crp git://"
but if this is the direction we want to go we can obviously work out a
better method of forcing "git " to be "git-" when talking to git-daemon.

> If we force --upload-pack workaround to _everybody_ we are already lost.
> 
> Also I think the previous one still lets you work it around by giving a
> full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not
> match "git-" ;-)

Please tell me, where is git-upload-pack on repo.or.cz?

$ ssh repo.or.cz which git-upload-pack
fatal: unrecognized command 'which git-upload-pack'

I doubt I can pass it '/usr/local/bin/git-upload-pack' and get it
to work too.  So I don't think this is a good work around.

Obviously pasky will fix repo.or.cz to accept both at some point
in the near future, likely before 1.6.0 releases, because he's cool
like that.  Not everyone is.

Please don't make 1.6.0 unavailable to end-users because their
server operator can't currently accept "git upload-pack" without
giving them a workaround to force "git-upload-pack" over SSH.

-- 
Shawn.

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > If we force --upload-pack workaround to _everybody_ we are already lost.
> >
> > Also I think the previous one still lets you work it around by giving a
> > full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not
> > match "git-" ;-)
> 
> Ok, let's map this out seriously.

This plan makes a lot of sense to me.  I'm behind it.  For whatever
that means.  At least I'll shutup and stop making noise about this
issue if you take this approach.  :-)

 
> * 1.6.0 will install the server-side programs in $(bindir) so that 
>   people coming over ssh will find them on the $PATH
> 
> * In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both
>   "git-program" and "git program" forms.  When the spaced form is used, it
>   will behave as if the dashed form is requested.  This is a prerequisite
>   for client side change to start asking for "git program".
> 
> * In the near future, there will no client-side change.  "git-program"
>   will be asked for.
> 
> * 6 months after 1.6.0 ships, hopefully all the deployed server side will
>   be running that version or newer.  Client side will start asking for
>   "git program" by default, but we can still override with --upload-pack
>   and friends.
> 
> * 12 months after client side changes, everybody will be running that
>   version or newer.  We stop installing the server side programs in
>   $(bindir) but people coming over ssh will be asking for "git program"
>   and "git" will be on the $PATH so there is no issue.
> 
> The above 6 and 12 are yanked out of thin air and I am of course open to
> tweaking them, but I think the above order of events would be workable.

Yea, 6 and 12 seem like a good idea.  Its a couple of releases and
gives people time to migrate their server installations.

-- 
Shawn.

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>> > "Shawn O. Pearce" <spearce@spearce.org> writes:
>> >
>> >>> Any other suggestions that is workable?
>> >>
>> >> diff --git a/builtin-clone.c b/builtin-clone.c
>> >> index 5c5acb4..98d0f0f 100644
>> >> --- a/builtin-clone.c
>> >> +++ b/builtin-clone.c
>> >> @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare;
>> >
>> > << a patch to conditionally change "git-program" default to "git program"
>> > snipped >>
>
> Shouldn't "git upload-pack" work on the server side as far back as
> 0.99.9k?

Yeah, I missed the patch to connect.c that was buried among other changes.
Sorry.

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

[Miklos Vajna]

[-- 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 --]

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.

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

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Theodore Tso]

On Tue, Jun 24, 2008 at 10:27:07PM -0700, Junio C Hamano wrote:
> Ok, let's map this out seriously.
> 
> * 1.6.0 will install the server-side programs in $(bindir) so that 
>   people coming over ssh will find them on the $PATH
> 
> * In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both
>   "git-program" and "git program" forms.  When the spaced form is used, it
>   will behave as if the dashed form is requested.  This is a prerequisite
>   for client side change to start asking for "git program".
> 
> * In the near future, there will no client-side change.  "git-program"
>   will be asked for.
> 
> * 6 months after 1.6.0 ships, hopefully all the deployed server side will
>   be running that version or newer.  Client side will start asking for
>   "git program" by default, but we can still override with --upload-pack
>   and friends.
> 
> * 12 months after client side changes, everybody will be running that
>   version or newer.  We stop installing the server side programs in
>   $(bindir) but people coming over ssh will be asking for "git program"
>   and "git" will be on the $PATH so there is no issue.
> 
> The above 6 and 12 are yanked out of thin air and I am of course open to
> tweaking them, but I think the above order of events would be workable.

Is that really 6 and 12 months, or "6/12 months or at the next major
release boundary, whichever is later".  i.e., would make some of these
changes as part of a minor dot release, such as having the client side
change what it starts asking for in 1.6.3 or some such?  Presumably
the earliest that change would happen is 1.7, and the earliest to make
the server side installation changes is 1.8, right?  Or did you really
mean a hard 6/12 months, regardless of release cycle issues?

       	    	 	 	       	       - Ted

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

Theodore Tso <tytso@mit.edu> writes:

> On Tue, Jun 24, 2008 at 10:27:07PM -0700, Junio C Hamano wrote:
> ...
>> The above 6 and 12 are yanked out of thin air and I am of course open to
>> tweaking them, but I think the above order of events would be workable.
>
> Is that really 6 and 12 months, or "6/12 months or at the next major
> release boundary, whichever is later".

Sigh... I thought you by now knew me better than that...

Yes, I didn't say it explicitly because I thought it was too obvious,
which was a mistake.  These except for the ones that are preparation (such
as "prepare daemon so that future clients can ask with non-dash forms")
need to happen at release boundaries, but these 6/12 months figures set
the minimums.  E.g. even if we had 6 week release cycles and 1.7.0 were to
be done 6 weeks after 1.6.0, that is still too early for the client side
to switch asking for "git program".

[PATCH] daemon: accept "git program" as well

[Junio C Hamano]

This is a step to futureproof git-daemon to accept clients that
ask for "git upload-pack" and friends, instead of using the more
traditional dash-form "git-upload-pack".  By allowing both, it
makes the client side easier to handle, as it makes "git" the only
thing necessary to be on $PATH when invoking the remote command
directly via ssh.

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

 "Shawn O. Pearce" <spearce@spearce.org> writes:

 > Junio C Hamano <gitster@pobox.com> wrote:
 >
 >> Ok, let's map this out seriously.
 >
 > This plan makes a lot of sense to me.  I'm behind it.  For whatever
 > that means.  At least I'll shutup and stop making noise about this
 > issue if you take this approach.  :-)
 >  
 >> * 1.6.0 will install the server-side programs in $(bindir) so that 
 >>   people coming over ssh will find them on the $PATH
 >> 
 >> * In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both
 >>   "git-program" and "git program" forms.  When the spaced form is used, it
 >>   will behave as if the dashed form is requested.  This is a prerequisite
 >>   for client side change to start asking for "git program".
 >> 
 >> * In the near future, there will no client-side change.  "git-program"
 >>   will be asked for.
 >> 
 >> * 6 months after 1.6.0 ships, hopefully all the deployed server side will
 >>   be running that version or newer.  Client side will start asking for
 >>   "git program" by default, but we can still override with --upload-pack
 >>   and friends.
 >> 
 >> * 12 months after client side changes, everybody will be running that
 >>   version or newer.  We stop installing the server side programs in
 >>   $(bindir) but people coming over ssh will be asking for "git program"
 >>   and "git" will be on the $PATH so there is no issue.
 >> 
 >> The above 6 and 12 are yanked out of thin air and I am of course open to
 >> tweaking them, but I think the above order of events would be workable.
 >
 > Yea, 6 and 12 seem like a good idea.  Its a couple of releases and
 > gives people time to migrate their server installations.

 So this obviously needs to be queued to 'maint' to be included in 1.5.6.1
 and 1.6.0.

 daemon.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/daemon.c b/daemon.c
index 63cd12c..621c567 100644
--- a/daemon.c
+++ b/daemon.c
@@ -586,7 +586,7 @@ static int execute(struct sockaddr *addr)
 	for (i = 0; i < ARRAY_SIZE(daemon_service); i++) {
 		struct daemon_service *s = &(daemon_service[i]);
 		int namelen = strlen(s->name);
-		if (!prefixcmp(line, "git-") &&
+		if ((!prefixcmp(line, "git-") || !prefixcmp(line, "git ")) &&
 		    !strncmp(s->name, line + 4, namelen) &&
 		    line[namelen + 4] == ' ') {
 			/*

[PATCH] Make clients ask for "git program" over ssh and local transport

[Junio C Hamano]

This will allow server side programs such as upload-pack to be installed
outside $PATH.  Connections to git-daemon still ask for "git-program" to
retain backward compatibility for daemons before 1.5.6.1 and 1.6.0.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * This is essentially your patch.  This can be in 1.6.0 clients and it
   should also be in 1.5.6.1 as people might keep ancient clients to talk
   to new servers that won't have anything but "git" on $PATH.

 builtin-clone.c      |    2 +-
 builtin-fetch-pack.c |    2 +-
 connect.c            |   10 ++++++++--
 git-parse-remote.sh  |    4 ++--
 transport.c          |    4 ++--
 5 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/builtin-clone.c b/builtin-clone.c
index 7190952..2f3e9c9 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -36,7 +36,7 @@ static int option_quiet, option_no_checkout, option_bare;
 static int option_local, option_no_hardlinks, option_shared;
 static char *option_template, *option_reference, *option_depth;
 static char *option_origin = NULL;
-static char *option_upload_pack = "git-upload-pack";
+static char *option_upload_pack = "git upload-pack";
 
 static struct option builtin_clone_options[] = {
 	OPT__QUIET(&option_quiet),
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index de1e8d1..a5f21f9 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -14,7 +14,7 @@ static int transfer_unpack_limit = -1;
 static int fetch_unpack_limit = -1;
 static int unpack_limit = 100;
 static struct fetch_pack_args args = {
-	/* .uploadpack = */ "git-upload-pack",
+	/* .uploadpack = */ "git upload-pack",
 };
 
 static const char fetch_pack_usage[] =
diff --git a/connect.c b/connect.c
index e92af29..4a32ba4 100644
--- a/connect.c
+++ b/connect.c
@@ -567,6 +567,8 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 		 * cannot connect.
 		 */
 		char *target_host = xstrdup(host);
+		const char *program_prefix = "";
+
 		if (git_use_proxy(host))
 			git_proxy_connect(fd, host);
 		else
@@ -575,9 +577,13 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 		 * Separate original protocol components prog and path
 		 * from extended components with a NUL byte.
 		 */
+		if (!prefixcmp(prog, "git ")) {
+			program_prefix = "git-";
+			prog += 4;
+		}
 		packet_write(fd[1],
-			     "%s %s%chost=%s%c",
-			     prog, path, 0,
+			     "%s%s %s%chost=%s%c",
+			     program_prefix, prog, path, 0,
 			     target_host, 0);
 		free(target_host);
 		free(url);
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 695a409..0f82a93 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -255,10 +255,10 @@ get_uploadpack () {
 	case "$data_source" in
 	config)
 		uplp=$(git config --get "remote.$1.uploadpack")
-		echo ${uplp:-git-upload-pack}
+		echo ${uplp:-git upload-pack}
 		;;
 	*)
-		echo "git-upload-pack"
+		echo "git upload-pack"
 		;;
 	esac
 }
diff --git a/transport.c b/transport.c
index 3ff8519..351b7f5 100644
--- a/transport.c
+++ b/transport.c
@@ -762,10 +762,10 @@ struct transport *transport_get(struct remote *remote, const char *url)
 
 		data->thin = 1;
 		data->conn = NULL;
-		data->uploadpack = "git-upload-pack";
+		data->uploadpack = "git upload-pack";
 		if (remote && remote->uploadpack)
 			data->uploadpack = remote->uploadpack;
-		data->receivepack = "git-receive-pack";
+		data->receivepack = "git receive-pack";
 		if (remote && remote->receivepack)
 			data->receivepack = remote->receivepack;
 	}
-- 
1.5.6.86.ge2da6

[PATCH] Ask for "git program" even against git-daemon

[Junio C Hamano]

This drops backward compatibility support to ask for "git-program"
form when talking to git-daemon.  Now all git native requests use
"git program" form over ssh, local and git transports.

This needs to be held back until everybody runs git-daemon from 1.5.6.1 or
1.6.0 or newer.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * According to the roadmap we exchanged earlier, this should happen in a
   major release (that increments the second dewey-decimal digit from the
   left) that ships at least 6 months after 1.5.6.1 and 1.6.0 (which will
   have the "git daemon preparation" patch included) are released.

 connect.c |    9 ++-------
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/connect.c b/connect.c
index 4a32ba4..f2e72c2 100644
--- a/connect.c
+++ b/connect.c
@@ -567,7 +567,6 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 		 * cannot connect.
 		 */
 		char *target_host = xstrdup(host);
-		const char *program_prefix = "";
 
 		if (git_use_proxy(host))
 			git_proxy_connect(fd, host);
@@ -577,13 +576,9 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 		 * Separate original protocol components prog and path
 		 * from extended components with a NUL byte.
 		 */
-		if (!prefixcmp(prog, "git ")) {
-			program_prefix = "git-";
-			prog += 4;
-		}
 		packet_write(fd[1],
-			     "%s%s %s%chost=%s%c",
-			     program_prefix, prog, path, 0,
+			     "%s %s%chost=%s%c",
+			     prog, path, 0,
 			     target_host, 0);
 		free(target_host);
 		free(url);
-- 
1.5.6.86.ge2da6

Re: [PATCH] daemon: accept "git program" as well

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> This is a step to futureproof git-daemon to accept clients that
> ask for "git upload-pack" and friends, instead of using the more
> traditional dash-form "git-upload-pack".  By allowing both, it
> makes the client side easier to handle, as it makes "git" the only
> thing necessary to be on $PATH when invoking the remote command
> directly via ssh.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Obviously correct.  Ack.  Thanks Junio.


>  So this obviously needs to be queued to 'maint' to be included in 1.5.6.1
>  and 1.6.0.
> 
>  daemon.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/daemon.c b/daemon.c
> index 63cd12c..621c567 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -586,7 +586,7 @@ static int execute(struct sockaddr *addr)
>  	for (i = 0; i < ARRAY_SIZE(daemon_service); i++) {
>  		struct daemon_service *s = &(daemon_service[i]);
>  		int namelen = strlen(s->name);
> -		if (!prefixcmp(line, "git-") &&
> +		if ((!prefixcmp(line, "git-") || !prefixcmp(line, "git ")) &&
>  		    !strncmp(s->name, line + 4, namelen) &&
>  		    line[namelen + 4] == ' ') {
>  			/*

-- 
Shawn.

Re: [PATCH] Make clients ask for "git program" over ssh and local transport

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> This will allow server side programs such as upload-pack to be installed
> outside $PATH.  Connections to git-daemon still ask for "git-program" to
> retain backward compatibility for daemons before 1.5.6.1 and 1.6.0.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  * This is essentially your patch.  This can be in 1.6.0 clients and it
>    should also be in 1.5.6.1 as people might keep ancient clients to talk
>    to new servers that won't have anything but "git" on $PATH.

Ack.  Thanks for cleaning up the code in connect.c to not segfault
or send garbage.

I think you want to squash this in as well:

diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index d76260c..f693a6d 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -12,7 +12,7 @@ static const char send_pack_usage[] =
 "  --all and explicit <ref> specification are mutually exclusive.";
 
 static struct send_pack_args args = {
-	/* .receivepack = */ "git-receive-pack",
+	/* .receivepack = */ "git receive-pack",
 };
 
 /*
 

-- 
Shawn.

Re: [PATCH] daemon: accept "git program" as well

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>> This is a step to futureproof git-daemon to accept clients that
>> ask for "git upload-pack" and friends, instead of using the more
>> traditional dash-form "git-upload-pack".  By allowing both, it
>> makes the client side easier to handle, as it makes "git" the only
>> thing necessary to be on $PATH when invoking the remote command
>> directly via ssh.
>> 
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Obviously correct.  Ack.  Thanks Junio.

By the way I looked at gitosis (Tommi CC'ed).

    http://repo.or.cz/w/gitosis.git?a=blob;f=gitosis/serve.py;h=c0b7135bf45305ee1079b0dcab3b4ed1ce988aab;hb=38561aa6a51a2ef6cc04aa119481df62d213ffa4

In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array
that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are
compared with user commands after doing:

	verb, args = command.split(None, 1)

(and "verb" is looked up in the set of valid commands).  It should not be
too involved to notice verb is 'git' and then re-split the args part to
see if they are upload-pack/receive-pack, which would be the equivalent
change to this patch.  It needs to be done before the clients are
updated.

Re: [PATCH] Ask for "git program" even against git-daemon

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> This drops backward compatibility support to ask for "git-program"
> form when talking to git-daemon.  Now all git native requests use
> "git program" form over ssh, local and git transports.
> 
> This needs to be held back until everybody runs git-daemon from 1.5.6.1 or
> 1.6.0 or newer.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  * According to the roadmap we exchanged earlier, this should happen in a
>    major release (that increments the second dewey-decimal digit from the
>    left) that ships at least 6 months after 1.5.6.1 and 1.6.0 (which will
>    have the "git daemon preparation" patch included) are released.

Agreed about holding back.

But I wonder if this patch is even worth it at some later point
in time.  Are we also going to change git-daemon to stop accepting
"git-" form?  Is it a worthwhile change?

-- 
Shawn.

Re: [PATCH] Ask for "git program" even against git-daemon

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
> ...
>>  * According to the roadmap we exchanged earlier, this should happen in a
>>    major release (that increments the second dewey-decimal digit from the
>>    left) that ships at least 6 months after 1.5.6.1 and 1.6.0 (which will
>>    have the "git daemon preparation" patch included) are released.
>
> Agreed about holding back.
>
> But I wonder if this patch is even worth it at some later point
> in time.  Are we also going to change git-daemon to stop accepting
> "git-" form?  Is it a worthwhile change?

This was merely responding to...

    From: "Shawn O. Pearce" <spearce@spearce.org>
    Subject: Re: [PATCH] Keep some git-* programs in $(bindir)
    Date: Wed, 25 Jun 2008 00:37:41 -0400
    Message-ID: <20080625043741.GD11793@spearce.org>

    Daniel Barkalow <barkalow@iabervon.org> wrote:
    > ...
    > Should they use "git upload-pack" or should they look for their helper 
    > programs in a libexec dir? I don't think that either of these programs is 
    > useful to run independantly, but I don't know if finding a program that 
    > doesn't go in $PATH on a remote machine is going to be any fun.

    IMHO they should in the future use "git upload-pack".


I do not mind not doing this at all.  Remember, I am the one with more
inertia than anybody else here (holding back backward incompatible
innovations is what maintainers do).

Oh, that inertia does not have much to do with actual body weight, if
anybody is wondering ;-)

Re: [PATCH] Ask for "git program" even against git-daemon

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> > But I wonder if this patch is even worth it at some later point
> > in time.  Are we also going to change git-daemon to stop accepting
> > "git-" form?  Is it a worthwhile change?
> 
> This was merely responding to...
> 
>     From: "Shawn O. Pearce" <spearce@spearce.org>
>     Subject: Re: [PATCH] Keep some git-* programs in $(bindir)
>     Date: Wed, 25 Jun 2008 00:37:41 -0400
>     Message-ID: <20080625043741.GD11793@spearce.org>
> 
>     Daniel Barkalow <barkalow@iabervon.org> wrote:
>     > ...
>     > Should they use "git upload-pack" [...]
> 
>     IMHO they should in the future use "git upload-pack".

Sorry I wasn't clear. I was talking about the SSH transport only.
For git:// we could just always send git-upload-pack, like your
transitional patch does.  Then we stay compatible with even very
old git:// servers.

-- 
Shawn.

Re: [PATCH] Ask for "git program" even against git-daemon

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> >
>> > But I wonder if this patch is even worth it at some later point
>> > in time.  Are we also going to change git-daemon to stop accepting
>> > "git-" form?  Is it a worthwhile change?
>> 
>> This was merely responding to...
>> 
>>     From: "Shawn O. Pearce" <spearce@spearce.org>
>>     Subject: Re: [PATCH] Keep some git-* programs in $(bindir)
>>     Date: Wed, 25 Jun 2008 00:37:41 -0400
>>     Message-ID: <20080625043741.GD11793@spearce.org>
>> 
>>     Daniel Barkalow <barkalow@iabervon.org> wrote:
>>     > ...
>>     > Should they use "git upload-pack" [...]
>> 
>>     IMHO they should in the future use "git upload-pack".
>
> Sorry I wasn't clear. I was talking about the SSH transport only.
> For git:// we could just always send git-upload-pack, like your
> transitional patch does.  Then we stay compatible with even very
> old git:// servers.

Ok, if that is the plan, then we wouldn't even need to futureproof
git-daemon at all.

Not having to change anything is good ;-).

Re: [PATCH] daemon: accept "git program" as well

[Tommi Virtanen]

On Wed, Jun 25, 2008 at 04:26:46PM -0700, Junio C Hamano wrote:
> By the way I looked at gitosis (Tommi CC'ed).
> 
>     http://repo.or.cz/w/gitosis.git?a=blob;f=gitosis/serve.py;h=c0b7135bf45305ee1079b0dcab3b4ed1ce988aab;hb=38561aa6a51a2ef6cc04aa119481df62d213ffa4
> 
> In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array
> that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are
> compared with user commands after doing:

Yeah, that's pretty much a trivial change, doing it now to future-proof
gitosis.

-- 
:(){ :|:&};:

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

[Jakub Narebski]

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

Re: [PATCH] daemon: accept "git program" as well

[Olivier Marin]

Hi,

Tommi Virtanen a écrit :
> On Wed, Jun 25, 2008 at 04:26:46PM -0700, Junio C Hamano wrote:
>>
>> In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array
>> that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are
>> compared with user commands after doing:
> 
> Yeah, that's pretty much a trivial change, doing it now to future-proof
> gitosis.
> 

This just happened to me with a dashless client, so I tried your patch but it
does not work. The problem comes from git-shell that do not support dashless
argument, yet (IOW: git shell -c 'git upload-pack ...' give an error).

The following patch on top of yours fix the problem. The s/git-shell/git shell/
part is not really necessary, but why not?

diff --git a/gitosis/serve.py b/gitosis/serve.py
index 9a91fcb..5aac355 100644
--- a/gitosis/serve.py
+++ b/gitosis/serve.py
@@ -21,12 +21,10 @@ ALLOW_RE = re.compile("^'/*(?P<path>[a-zA-Z0-9][a-zA-Z0-9@._-]*(/[a-zA-Z0-9][a-z
 
 COMMANDS_READONLY = [
     'git-upload-pack',
-    'git upload-pack',
     ]
 
 COMMANDS_WRITE = [
     'git-receive-pack',
-    'git receive-pack',
     ]
 
 class ServingError(Exception):
@@ -75,7 +73,7 @@ def serve(
             # all known "git foo" commands take one argument; improve
             # if/when needed
             raise UnknownCommandError()
-        verb = '%s %s' % (verb, subverb)
+        verb = '%s-%s' % (verb, subverb)
 
     if (verb not in COMMANDS_WRITE
         and verb not in COMMANDS_READONLY):
@@ -201,6 +199,6 @@ class Main(app.App):
             sys.exit(1)
 
         main_log.debug('Serving %s', newcmd)
-        os.execvp('git-shell', ['git-shell', '-c', newcmd])
-        main_log.error('Cannot execute git-shell.')
+        os.execvp('git', ['git', 'shell', '-c', newcmd])
+        main_log.error('Cannot execute git.')
         sys.exit(1)


Olivier.

Re: [PATCH] daemon: accept "git program" as well

[Junio C Hamano]

Olivier Marin <dkr+ml.git@free.fr> writes:

> Hi,
>
> Tommi Virtanen a écrit :
>> On Wed, Jun 25, 2008 at 04:26:46PM -0700, Junio C Hamano wrote:
>>>
>>> In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array
>>> that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are
>>> compared with user commands after doing:
>> 
>> Yeah, that's pretty much a trivial change, doing it now to future-proof
>> gitosis.
>> 
>
> This just happened to me with a dashless client, so I tried your patch but it
> does not work. The problem comes from git-shell that do not support dashless
> argument, yet (IOW: git shell -c 'git upload-pack ...' give an error).
>
> The following patch on top of yours fix the problem. The s/git-shell/git shell/
> part is not really necessary, but why not?
>
> diff --git a/gitosis/serve.py b/gitosis/serve.py
> index 9a91fcb..5aac355 100644
> --- a/gitosis/serve.py
> +++ b/gitosis/serve.py
> @@ -21,12 +21,10 @@ ALLOW_RE = re.compile("^'/*(?P<path>[a-zA-Z0-9][a-zA-Z0-9@._-]*(/[a-zA-Z0-9][a-z
>  
>  COMMANDS_READONLY = [
>      'git-upload-pack',
> -    'git upload-pack',
>      ]
>  
>  COMMANDS_WRITE = [
>      'git-receive-pack',
> -    'git receive-pack',
>      ]
>  
>  class ServingError(Exception):
> @@ -75,7 +73,7 @@ def serve(
>              # all known "git foo" commands take one argument; improve
>              # if/when needed
>              raise UnknownCommandError()
> -        verb = '%s %s' % (verb, subverb)
> +        verb = '%s-%s' % (verb, subverb)
>  
>      if (verb not in COMMANDS_WRITE
>          and verb not in COMMANDS_READONLY):
> @@ -201,6 +199,6 @@ class Main(app.App):
>              sys.exit(1)
>  
>          main_log.debug('Serving %s', newcmd)
> -        os.execvp('git-shell', ['git-shell', '-c', newcmd])
> -        main_log.error('Cannot execute git-shell.')
> +        os.execvp('git', ['git', 'shell', '-c', newcmd])
> +        main_log.error('Cannot execute git.')
>          sys.exit(1)

Hmm, Tommi, if you are doing command sanitizing yourself, is there a
reason to still invoke the command via git-shell?

[PATCH] Make default expiration period of reflog used for stash infinite

[Junio C Hamano]

This makes the default expiration period for the reflog that implements
stash infinite.

The original behaviour to autoexpire old stashes can be restored by using
the gc.refs/stash.{reflogexpire,reflogexpireunreachable} configration
variables introduced by the previous commit.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 > [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.

 builtin-reflog.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/builtin-reflog.c b/builtin-reflog.c
index 0711728..125d455 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -441,6 +441,17 @@ static void set_reflog_expiry_param(struct cmd_reflog_expire_cb *cb, int slot, c
 		}
 	}
 
+	/*
+	 * If unconfigured, make stash never expire
+	 */
+	if (!strcmp(ref, "refs/stash")) {
+		if (!(slot & EXPIRE_TOTAL))
+			cb->expire_total = 0;
+		if (!(slot & EXPIRE_UNREACH))
+			cb->expire_unreachable = 0;
+		return;
+	}
+
 	/* Nothing matched -- use the default value */
 	if (!(slot & EXPIRE_TOTAL))
 		cb->expire_total = default_reflog_expire;
-- 
1.5.6.1.102.g8e69d

[PATCH] Teach git-merge to pass -X<option> to the backend strategy module

[Junio C Hamano]

Distinguishing slight variation of modes of operation between the vanilla
merge-recursive and merge-recursive-ours by the command name may have been
an easy way to experiment, but we should bite the bullet and allow backend
specific options to be given by the end user.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 > [Stalled/Needs more work]
 >
 > * 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.

 Makefile                     |    3 ---
 builtin-merge-recursive.c    |   23 +++++++++++++++--------
 git-merge.sh                 |   11 ++++++++---
 t/t6034-merge-ours-theirs.sh |    4 ++--
 4 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/Makefile b/Makefile
index 82d2892..b003e3e 100644
--- a/Makefile
+++ b/Makefile
@@ -304,8 +304,6 @@ BUILT_INS += git-format-patch$X
 BUILT_INS += git-fsck-objects$X
 BUILT_INS += git-get-tar-commit-id$X
 BUILT_INS += git-init$X
-BUILT_INS += git-merge-recursive-ours$X
-BUILT_INS += git-merge-recursive-theirs$X
 BUILT_INS += git-merge-subtree$X
 BUILT_INS += git-peek-remote$X
 BUILT_INS += git-repo-config$X
@@ -1383,7 +1381,6 @@ check-docs::
 	do \
 		case "$$v" in \
 		git-merge-octopus | git-merge-ours | git-merge-recursive | \
-		git-merge-recursive-ours | git-merge-recursive-theirs | \
 		git-merge-resolve | git-merge-stupid | git-merge-subtree | \
 		git-fsck-objects | git-init-db | \
 		git-?*--?* ) continue ;; \
diff --git a/builtin-merge-recursive.c b/builtin-merge-recursive.c
index a355e7a..6541e16 100644
--- a/builtin-merge-recursive.c
+++ b/builtin-merge-recursive.c
@@ -1407,12 +1407,6 @@ int cmd_merge_recursive(int argc, const char **argv, const char *prefix)
 		if (8 < namelen &&
 		    !strcmp(argv[0] + namelen - 8, "-subtree"))
 			merge_recursive_variants = MERGE_RECURSIVE_SUBTREE;
-		else if (5 < namelen &&
-			 !strcmp(argv[0] + namelen - 5, "-ours"))
-			merge_recursive_variants = MERGE_RECURSIVE_OURS;
-		else if (7 < namelen &&
-			 !strcmp(argv[0] + namelen - 7, "-theirs"))
-			merge_recursive_variants = MERGE_RECURSIVE_THEIRS;
 	}
 
 	git_config(merge_config, NULL);
@@ -1423,8 +1417,21 @@ int cmd_merge_recursive(int argc, const char **argv, const char *prefix)
 		die("Usage: %s <base>... -- <head> <remote> ...\n", argv[0]);
 
 	for (i = 1; i < argc; ++i) {
-		if (!strcmp(argv[i], "--"))
-			break;
+		const char *arg = argv[i];
+
+		if (!prefixcmp(arg, "--")) {
+			if (!arg[2])
+				break;
+			if (!strcmp(arg+2, "ours"))
+				merge_recursive_variants = MERGE_RECURSIVE_OURS;
+			else if (!strcmp(arg+2, "theirs"))
+				merge_recursive_variants = MERGE_RECURSIVE_THEIRS;
+			else if (!strcmp(arg+2, "subtree"))
+				merge_recursive_variants = MERGE_RECURSIVE_SUBTREE;
+			else
+				die("Unknown option %s", arg);
+			continue;
+		}
 		if (bases_count < sizeof(bases)/sizeof(*bases))
 			bases[bases_count++] = argv[i];
 	}
diff --git a/git-merge.sh b/git-merge.sh
index 39b5cd9..d475852 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -17,6 +17,7 @@ commit               perform a commit if the merge succeeds (default)
 ff                   allow fast forward (default)
 s,strategy=          merge strategy to use
 m,message=           message to be used for the merge commit (if any)
+X=                   pass merge strategy specific options
 "
 
 SUBDIRECTORY_OK=Yes
@@ -31,12 +32,12 @@ LF='
 '
 
 all_strategies='recur recursive octopus resolve stupid ours subtree'
-all_strategies="$all_strategies recursive-ours recursive-theirs"
 default_twohead_strategies='recursive'
 default_octopus_strategies='octopus'
 no_fast_forward_strategies='subtree ours'
-no_trivial_strategies='recursive recur subtree ours recursive-ours recursive-theirs'
+no_trivial_strategies='recursive recur subtree ours'
 use_strategies=
+backend_option=
 
 allow_fast_forward=t
 allow_trivial_merge=t
@@ -187,6 +188,10 @@ parse_config () {
 			merge_msg="$1"
 			have_message=t
 			;;
+		-X)
+			shift
+			backend_option="$backend_option --$1"
+			;;
 		--)
 			shift
 			break ;;
@@ -451,7 +456,7 @@ do
     # Remember which strategy left the state in the working tree
     wt_strategy=$strategy
 
-    git-merge-$strategy $common -- "$head_arg" "$@"
+    git-merge-$strategy $backend_option $common -- "$head_arg" "$@"
     exit=$?
     if test "$no_commit" = t && test "$exit" = 0
     then
diff --git a/t/t6034-merge-ours-theirs.sh b/t/t6034-merge-ours-theirs.sh
index 56a9247..91f0f63 100755
--- a/t/t6034-merge-ours-theirs.sh
+++ b/t/t6034-merge-ours-theirs.sh
@@ -35,7 +35,7 @@ test_expect_success 'plain recursive - should conflict' '
 
 test_expect_success 'recursive favouring theirs' '
 	git reset --hard master &&
-	git merge -s recursive-theirs side &&
+	git merge -s recursive -Xtheirs side &&
 	! grep nine file &&
 	grep nueve file &&
 	! grep 9 file &&
@@ -45,7 +45,7 @@ test_expect_success 'recursive favouring theirs' '
 
 test_expect_success 'recursive favouring ours' '
 	git reset --hard master &&
-	git merge -s recursive-ours side &&
+	git merge -s recursive -Xours side &&
 	grep nine file &&
 	! grep nueve file &&
 	! grep 9 file &&
-- 
1.5.6.1.102.g8e69d

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

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.  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

Re: [PATCH] Teach git-merge to pass -X<option> to the backend strategy module

[Jakub Narebski]

Junio C Hamano wrote:

> diff --git a/git-merge.sh b/git-merge.sh
> index 39b5cd9..d475852 100755
> --- a/git-merge.sh
> +++ b/git-merge.sh
> @@ -17,6 +17,7 @@ commit               perform a commit if the merge succeeds (default)
>  ff                   allow fast forward (default)
>  s,strategy=          merge strategy to use
>  m,message=           message to be used for the merge commit (if any)
> +X=                   pass merge strategy specific options
>  "

You have updated usage for git-merge, but didn't update manpages
(Documentation).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Linus Torvalds]

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

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

[Junio C Hamano]

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.

Re: [PATCH] Teach git-merge to pass -X<option> to the backend strategy module

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
>
>> diff --git a/git-merge.sh b/git-merge.sh
>> index 39b5cd9..d475852 100755
>> --- a/git-merge.sh
>> +++ b/git-merge.sh
>> @@ -17,6 +17,7 @@ commit               perform a commit if the merge succeeds (default)
>>  ff                   allow fast forward (default)
>>  s,strategy=          merge strategy to use
>>  m,message=           message to be used for the merge commit (if any)
>> +X=                   pass merge strategy specific options
>>  "
>
> You have updated usage for git-merge, but didn't update manpages
> (Documentation).

Patches welcome ;-)

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

[Junio C Hamano]

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.

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

[Pieter de Bie]

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

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

[Johannes Schindelin]

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

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

[Steffen Prohaska]

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

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

[Jeff King]

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

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

[Junio C Hamano]

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'".

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

[Jeff King]

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

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

[Junio C Hamano]

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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.  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

How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))

[Steffen Prohaska]

On Jun 30, 2008, at 11:08 AM, Junio C Hamano wrote:

> * MinGW will be in.


If this is done, we should be able to create the msysgit release  
directly
from Junio's master.  Hannes changes alone, however, are not sufficient,
because some commits have been parked in 4msysgit.  Now that MinGW is
on Junio's next and Junio's next is also on 4msysgit's next, it it easy
to see how much is left to do by running:

    git diff --stat junio/next..4msysgit/next

junio is a remote pointing to git://git.kernel.org/pub/scm/git/git.git.
4msysgit is a remote pointing to git://repo.or.cz/git/mingw/ 
4msysgit.git.
I attached the output below.

How should we proceed to get rid of the differences?

Should we prepare and send patches directly to the official git list  
now?
Should we wait until the first MinGW branch is on master?
Should we prepare a whole patch series?  Maybe Hannes would maintain  
this
patch series.

I have not yet looked at the remaining differences in detail.  I expect
most of them to be trivial.  But some might require discussion on the
list, so at some point we should send the patches to the official list.

	Steffen


$ git diff --stat junio/next..4msysgit/next
  Makefile                               |   23 ++-
  README.MinGW                           |   77 ++++++++
  RelNotes                               |    1 -
  builtin-fetch-pack.c                   |    3 +-
  builtin-tag.c                          |   14 ++
  builtin-verify-tag.c                   |    2 +
  cache.h                                |    2 +
  check-builtins.sh                      |    2 +-
  compat/mingw.c                         |    4 +-
  compat/winansi.c                       |  309 +++++++++++++++++++++++ 
+++++++++
  connect.c                              |    5 +-
  convert.c                              |    4 +
  fast-import.c                          |    2 +
  git-add--interactive.perl              |    2 +-
  git-compat-util.h                      |    7 +
  git-parse-remote.sh                    |    3 +-
  gitk-git/Makefile                      |    4 +
  gitk-git/gitk                          |    2 +
  help.c                                 |   30 +++-
  path.c                                 |   13 ++
  read-cache.c                           |    5 +
  setup.c                                |    7 +-
  t/t0000-basic.sh                       |   31 +++-
  t/t0001-init.sh                        |    2 +-
  t/t0004-unwritable.sh                  |    7 +
  t/t1002-read-tree-m-u-2way.sh          |    6 +
  t/t1003-read-tree-prefix.sh            |    4 +
  t/t1004-read-tree-m-u-wf.sh            |    2 +
  t/t1300-repo-config.sh                 |    1 +
  t/t1301-shared-repo.sh                 |    4 +
  t/t2001-checkout-cache-clash.sh        |    2 +
  t/t2003-checkout-cache-mkdir.sh        |    4 +
  t/t2004-checkout-cache-temp.sh         |    2 +
  t/t2007-checkout-symlink.sh            |    7 +
  t/t2100-update-cache-badpath.sh        |    2 +
  t/t2201-add-update-typechange.sh       |   11 +-
  t/t3000-ls-files-others.sh             |    1 +
  t/t3010-ls-files-killed-modified.sh    |    7 +
  t/t3100-ls-tree-restrict.sh            |   12 ++
  t/t3200-branch.sh                      |    2 +
  t/t3700-add.sh                         |   10 +
  t/t3901-i18n-patch.sh                  |    4 +
  t/t3903-stash.sh                       |   12 +-
  t/t4004-diff-rename-symlink.sh         |    7 +
  t/t4008-diff-break-rewrite.sh          |    4 +
  t/t4011-diff-symlink.sh                |    7 +
  t/t4023-diff-rename-typechange.sh      |    5 +
  t/t4109-apply-multifrag.sh             |    4 +
  t/t4110-apply-scan.sh                  |    4 +
  t/t4114-apply-typechange.sh            |    5 +
  t/t4115-apply-symlink.sh               |    7 +
  t/t4116-apply-reverse.sh               |    3 +-
  t/t4122-apply-symlink-inside.sh        |    7 +
  t/t4150-am.sh                          |    6 +-
  t/t5000-tar-tree.sh                    |    7 +
  t/t5300-pack-object.sh                 |   62 +++----
  t/t5502-quickfetch.sh                  |    3 +
  t/t5503-tagfollow.sh                   |   25 +++-
  t/t5505-remote.sh                      |    3 +
  t/t5511-refspec.sh                     |   11 +-
  t/t5512-ls-remote.sh                   |    3 +
  t/t5520-pull.sh                        |    1 +
  t/t5530-upload-pack-error.sh           |    1 +
  t/t7004-tag.sh                         |    5 +-
  t/t7005-editor.sh                      |    1 +
  t/t7201-co.sh                          |    6 +-
  t/t7401-submodule-summary.sh           |   30 ++--
  t/t7501-commit.sh                      |    1 +
  t/t7502-status.sh                      |    4 +
  t/t7503-pre-commit-hook.sh             |    6 +
  t/t7504-commit-msg-hook.sh             |    6 +
  t/t9001-send-email.sh                  |    4 +
  t/t9200-git-cvsexportcommit.sh         |    4 +
  t/t9500-gitweb-standalone-no-errors.sh |    3 +
  t/test-lib.sh                          |   17 ++
  templates/Makefile                     |    3 +
  utf8.c                                 |    7 +
  utf8.h                                 |    4 -
  78 files changed, 844 insertions(+), 86 deletions(-)

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

[Kristian Høgsberg]

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

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

[Brandon Casey]

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

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

[Jakub Narebski]

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

Re: [msysGit] How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))

[Johannes Sixt]

On Montag, 30. Juni 2008, Steffen Prohaska wrote:
> On Jun 30, 2008, at 11:08 AM, Junio C Hamano wrote:
> > * MinGW will be in.
>
> If this is done, we should be able to create the msysgit release
> directly
> from Junio's master.  Hannes changes alone, however, are not sufficient,
> because some commits have been parked in 4msysgit.  Now that MinGW is
> on Junio's next and Junio's next is also on 4msysgit's next, it it easy
> to see how much is left to do by running:
>
>     git diff --stat junio/next..4msysgit/next
>
> junio is a remote pointing to git://git.kernel.org/pub/scm/git/git.git.
> 4msysgit is a remote pointing to git://repo.or.cz/git/mingw/
> 4msysgit.git.
> I attached the output below.
>
> How should we proceed to get rid of the differences?
>
> Should we prepare and send patches directly to the official git list
> now?
> Should we wait until the first MinGW branch is on master?
> Should we prepare a whole patch series?  Maybe Hannes would maintain
> this
> patch series.

Until 1.6.0 is released, a number of _required_ patches will have to be 
included. There are two sorts of them:

* Patches that touch generic code, like replacing c == '/' by is_dir_sep(c).

* Patches that are purly Windows specific.

The former I intend to submit to the mailing list directly and as soon as 
possible (but if I can intervene on newly submitted patches early so that a 
fixup is not even necessary, then even better). The latter I intend to 
collect in a branch and submit as a batch. Let's see how this works out.

Then there are the extra patches in 4msysgit. From my POV, they are not 
_required_ because I can appearently work with git on Windows without them. I 
think some of them are not necessary. Can we go through them again?

And then there are the patches to the t/ directory. I do not target them for 
1.6.0, but I do want to prepare another series with them.

-- Hannes

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

[Junio C Hamano]

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.

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

[Junio C Hamano]

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.

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

[Andrew Morton]

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.

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

[Petr Baudis]

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

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

[Johannes Schindelin]

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

Re: [PATCH] Make default expiration period of reflog used for stash infinite

[Olivier Marin]

Junio C Hamano a écrit :
> This makes the default expiration period for the reflog that implements
> stash infinite.

I did not read the whole thread so maybe I missed something but I though you
wanted to apply Nanako's patch before?

The patch: http://article.gmane.org/gmane.comp.version-control.git/85055

Olivier.

Re: How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))

[Clifford Caoile]

Hi:

On Tue, Jul 1, 2008 at 3:47 AM, Johannes Sixt <johannes.sixt@telecom.at> wrote:
>
> On Montag, 30. Juni 2008, Steffen Prohaska wrote:
>> On Jun 30, 2008, at 11:08 AM, Junio C Hamano wrote:
>> > * MinGW will be in.
>>
>> How should we proceed to get rid of the differences?
> ...
> Then there are the extra patches in 4msysgit. From my POV, they are not
> _required_ because I can appearently work with git on Windows without them. I
> think some of them are not necessary. Can we go through them again?

As one of the extra patches in 4msysgit, there is the cca/git.el
branch [1] which I contributed [2] previously for Emacs git.el users
on Windows. However I have not gotten any feedback whatsoever, so
perhaps parking it in 4msysgit is not appropriate. I plan to
separately to host these patch(es). Please ignore it or remove it at
your convenience.

References:
[1] http://repo.or.cz/w/git/mingw/4msysgit.git?a=shortlog;h=refs/heads/cca/git.el
[2] http://thread.gmane.org/gmane.comp.version-control.msysgit/2140

Best regards,
Clifford Caoile

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

[Stephen Rothwell]

[-- 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 --]

Re: [PATCH] Make default expiration period of reflog used for stash infinite

[Junio C Hamano]

Olivier Marin <dkr+ml.git@free.fr> writes:

> Junio C Hamano a écrit :
>> This makes the default expiration period for the reflog that implements
>> stash infinite.
>
> I did not read the whole thread so maybe I missed something but I though you
> wanted to apply Nanako's patch before?
>
> The patch: http://article.gmane.org/gmane.comp.version-control.git/85055

Thanks for reminding, but I am of two minds about the change.

 (1) The change would untie the base tree of the stash from the history
     behind it and allow previously rewound tips of branches that these
     stashes were built on top of.  Without the patch, these otherwise
     unreachable commits will never be reclaimed.

 (2) Today, you can say "git log stash" (note the lack of "-g" option) to
     view the history behind the stash through two artificial commits that
     stash creates.  This will become impossible with the patch.

Probably I am worrying too much; I do not personally think the second
point matters in the real life.  If "git log stash" _were_ any useful,
it means the history behind the stash entries are not useless at all, but
in that case the user would be using regular branches to store them
anyway.

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

[Jeff King]

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

[PATCH] git-add--interactive: manual hunk editing mode

[Thomas Rast]

Adds a new option 'e' to the 'add -p' command loop that lets you edit
the current hunk in your favourite editor.

If the resulting patch applies cleanly, the edited hunk will
immediately be marked for staging. If it does not apply cleanly, you
will be given an opportunity to edit again. If all lines of the hunk
are removed, then the edit is aborted and the hunk is left unchanged.

Applying the changed hunk(s) relies on Johannes Schindelin's new
--recount option for git-apply.

Note that the "real patch" test intentionally uses
  (echo e; echo n; echo d) | git add -p
even though the 'n' and 'd' are superfluous at first sight.  They
serve to get out of the interaction loop if git add -p wrongly
concludes the patch does not apply.

Many thanks to Jeff King <peff@peff.net> for lots of help and
suggestions.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---

Jeff King wrote:
> 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).

It is independent, so I suppose you're right.  (Dscho mentioned in
passing he might repost "add -e" himself.)

- Thomas

 Documentation/git-add.txt  |    1 +
 git-add--interactive.perl  |  124 +++++++++++++++++++++++++++++++++++++++++++-
 t/t3701-add-interactive.sh |   67 ++++++++++++++++++++++++
 3 files changed, 191 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index c6de028..1d8d209 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -246,6 +246,7 @@ patch::
        k - leave this hunk undecided, see previous undecided hunk
        K - leave this hunk undecided, see previous hunk
        s - split the current hunk into smaller hunks
+       e - manually edit the current hunk
        ? - print help
 +
 After deciding the fate for all hunks, if there is any hunk
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 903953e..6bb117a 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -2,6 +2,7 @@
 
 use strict;
 use Git;
+use File::Temp;
 
 my $repo = Git->repository();
 
@@ -18,6 +19,18 @@ my ($fraginfo_color) =
 	$diff_use_color ? (
 		$repo->get_color('color.diff.frag', 'cyan'),
 	) : ();
+my ($diff_plain_color) =
+	$diff_use_color ? (
+		$repo->get_color('color.diff.plain', ''),
+	) : ();
+my ($diff_old_color) =
+	$diff_use_color ? (
+		$repo->get_color('color.diff.old', 'red'),
+	) : ();
+my ($diff_new_color) =
+	$diff_use_color ? (
+		$repo->get_color('color.diff.new', 'green'),
+	) : ();
 
 my $normal_color = $repo->get_color("", "reset");
 
@@ -770,6 +783,104 @@ sub coalesce_overlapping_hunks {
 	return @out;
 }
 
+sub color_diff {
+	return map {
+		colored((/^@/  ? $fraginfo_color :
+			 /^\+/ ? $diff_new_color :
+			 /^-/  ? $diff_old_color :
+			 $diff_plain_color),
+			$_);
+	} @_;
+}
+
+sub edit_hunk_manually {
+	my ($oldtext) = @_;
+
+	my $t = File::Temp->new(
+		TEMPLATE => $repo->repo_path . "/git-hunk-edit.XXXXXX",
+		SUFFIX => '.diff'
+	);
+	print $t "# Manual hunk edit mode -- see bottom for a quick guide\n";
+	print $t @$oldtext;
+	print $t <<EOF;
+# ---
+# To remove '-' lines, make them ' ' lines (context).
+# To remove '+' lines, delete them.
+# Lines starting with # will be removed.
+#
+# If the patch applies cleanly, the edited hunk will immediately be
+# marked for staging. If it does not apply cleanly, you will be given
+# an opportunity to edit again. If all lines of the hunk are removed,
+# then the edit is aborted and the hunk is left unchanged.
+EOF
+	close $t;
+
+	my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor")
+		|| $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+	system('sh', '-c', $editor.' "$@"', $editor, $t);
+
+	open my $fh, '<', $t
+		or die "failed to open hunk edit file for reading: " . $!;
+	my @newtext = grep { !/^#/ } <$fh>;
+	close $fh;
+
+	# Abort if nothing remains
+	if (!grep { /\S/ } @newtext) {
+		return undef;
+	}
+
+	# Reinsert the first hunk header if the user accidentally deleted it
+	if ($newtext[0] !~ /^@/) {
+		unshift @newtext, $oldtext->[0];
+	}
+	return \@newtext;
+}
+
+sub diff_applies {
+	my $fh;
+	open $fh, '| git apply --recount --cached --check';
+	for my $h (@_) {
+		print $fh @{$h->{TEXT}};
+	}
+	return close $fh;
+}
+
+sub prompt_yesno {
+	my ($prompt) = @_;
+	while (1) {
+		print colored $prompt_color, $prompt;
+		my $line = <STDIN>;
+		return 0 if $line =~ /^n/i;
+		return 1 if $line =~ /^y/i;
+	}
+}
+
+sub edit_hunk_loop {
+	my ($head, $hunk, $ix) = @_;
+	my $text = $hunk->[$ix]->{TEXT};
+
+	while (1) {
+		$text = edit_hunk_manually($text);
+		if (!defined $text) {
+			return undef;
+		}
+		my $newhunk = { TEXT => $text, USE => 1 };
+		if (diff_applies($head,
+				 @{$hunk}[0..$ix-1],
+				 $newhunk,
+				 @{$hunk}[$ix+1..$#{$hunk}])) {
+			$newhunk->{DISPLAY} = [color_diff(@{$text})];
+			return $newhunk;
+		}
+		else {
+			prompt_yesno(
+				'Your edited hunk does not apply. Edit again '
+				. '(saying "no" discards!) [y/n]? '
+				) or return undef;
+		}
+	}
+}
+
 sub help_patch_cmd {
 	print colored $help_color, <<\EOF ;
 y - stage this hunk
@@ -781,6 +892,7 @@ J - leave this hunk undecided, see next hunk
 k - leave this hunk undecided, see previous undecided hunk
 K - leave this hunk undecided, see previous hunk
 s - split the current hunk into smaller hunks
+e - manually edit the current hunk
 ? - print help
 EOF
 }
@@ -846,6 +958,7 @@ sub patch_update_file {
 
 	$num = scalar @hunk;
 	$ix = 0;
+	my $need_recount = 0;
 
 	while (1) {
 		my ($prev, $next, $other, $undecided, $i);
@@ -885,6 +998,7 @@ sub patch_update_file {
 		if (hunk_splittable($hunk[$ix]{TEXT})) {
 			$other .= '/s';
 		}
+		$other .= '/e';
 		for (@{$hunk[$ix]{DISPLAY}}) {
 			print;
 		}
@@ -949,6 +1063,13 @@ sub patch_update_file {
 				$num = scalar @hunk;
 				next;
 			}
+			elsif ($line =~ /^e/) {
+				my $newhunk = edit_hunk_loop($head, \@hunk, $ix);
+				if (defined $newhunk) {
+					splice @hunk, $ix, 1, $newhunk;
+					$need_recount = 1;
+				}
+			}
 			else {
 				help_patch_cmd($other);
 				next;
@@ -1002,7 +1123,8 @@ sub patch_update_file {
 	if (@result) {
 		my $fh;
 
-		open $fh, '| git apply --cached';
+		open $fh, '| git apply --cached'
+			. ($need_recount ? ' --recount' : '');
 		for (@{$head->{TEXT}}, @result) {
 			print $fh $_;
 		}
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index fae64ea..e95663d 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -66,6 +66,73 @@ test_expect_success 'revert works (commit)' '
 	grep "unchanged *+3/-0 file" output
 '
 
+cat >expected <<EOF
+EOF
+cat >fake_editor.sh <<EOF
+EOF
+chmod a+x fake_editor.sh
+test_set_editor "$(pwd)/fake_editor.sh"
+test_expect_success 'dummy edit works' '
+	(echo e; echo a) | git add -p &&
+	git diff > diff &&
+	test_cmp expected diff
+'
+
+cat >patch <<EOF
+@@ -1,1 +1,4 @@
+ this
++patch
+-doesn't
+ apply
+EOF
+echo "#!$SHELL_PATH" >fake_editor.sh
+cat >>fake_editor.sh <<\EOF
+mv -f "$1" oldpatch &&
+mv -f patch "$1"
+EOF
+chmod a+x fake_editor.sh
+test_set_editor "$(pwd)/fake_editor.sh"
+test_expect_success 'bad edit rejected' '
+	git reset &&
+	(echo e; echo n; echo d) | git add -p >output &&
+	grep "hunk does not apply" output
+'
+
+cat >patch <<EOF
+this patch
+is garbage
+EOF
+test_expect_success 'garbage edit rejected' '
+	git reset &&
+	(echo e; echo n; echo d) | git add -p >output &&
+	grep "hunk does not apply" output
+'
+
+cat >patch <<EOF
+@@ -1,0 +1,0 @@
+ baseline
++content
++newcontent
++lines
+EOF
+cat >expected <<EOF
+diff --git a/file b/file
+index b5dd6c9..f910ae9 100644
+--- a/file
++++ b/file
+@@ -1,4 +1,4 @@
+ baseline
+ content
+-newcontent
++more
+ lines
+EOF
+test_expect_success 'real edit works' '
+	(echo e; echo n; echo d) | git add -p &&
+	git diff >output &&
+	test_cmp expected output
+'
+
 if test "$(git config --bool core.filemode)" = false
 then
     say 'skipping filemode tests (filesystem does not properly support modes)'
-- 
1.5.4.5

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

[Kristian Høgsberg]

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

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Johannes Schindelin]

Hi,

On Tue, 1 Jul 2008, Thomas Rast wrote:

> (Dscho mentioned in passing he might repost "add -e" himself.)

He will not :-)

Ciao,
Dscho

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> Jeff King wrote:
>> 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).
>
> It is independent, so I suppose you're right.  (Dscho mentioned in
> passing he might repost "add -e" himself.)

Thanks, both.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.  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

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index 903953e..6bb117a 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -2,6 +2,7 @@
>  
>  use strict;
>  use Git;
> +use File::Temp;

People with minimum Perl installation should still be able to use "add -i"
as long as they do not use 'e' subcommand, shouldn't they?  Shouldn't we
do something like:

	my $can_use_temp = eval {
        	require File::Temp;
                1;
	};

and disable 'e' subcommand unless $can_use_temp?

> +sub edit_hunk_manually {
> +	my ($oldtext) = @_;
> +
> +	my $t = File::Temp->new(
> +		TEMPLATE => $repo->repo_path . "/git-hunk-edit.XXXXXX",
> +		SUFFIX => '.diff'
> +	);
> +	print $t "# Manual hunk edit mode -- see bottom for a quick guide\n";
> +	print $t @$oldtext;
> +	print $t <<EOF;
> +# ---
> +# To remove '-' lines, make them ' ' lines (context).
> +# To remove '+' lines, delete them.
> +# Lines starting with # will be removed.

Don't you want to say "Do not touch lines that begin with ' '"?

> +	# Reinsert the first hunk header if the user accidentally deleted it
> +	if ($newtext[0] !~ /^@/) {
> +		unshift @newtext, $oldtext->[0];
> +	}

Hmm, perhaps not even giving the "@@ ... @@" lines to the editor would be
a more robust solution?

> +sub diff_applies {
> +	my $fh;
> +	open $fh, '| git apply --recount --cached --check';
> +	for my $h (@_) {
> +		print $fh @{$h->{TEXT}};
> +	}
> +	return close $fh;

Have to wonder where the potential error message would go, and if it would
confuse the end users...

> @@ -1002,7 +1123,8 @@ sub patch_update_file {
>  	if (@result) {
>  		my $fh;
>  
> -		open $fh, '| git apply --cached';
> +		open $fh, '| git apply --cached'
> +			. ($need_recount ? ' --recount' : '');
>  		for (@{$head->{TEXT}}, @result) {
>  			print $fh $_;
>  		}

I recall that the original "add--interactive" carefully counted numbers in
hunks it reassembles (as it can let you split and then you can choose to
use both parts, which requires it to merge overlapping hunks back), but if
you are going to use --recount anyway, perhaps we can discard that logic?
It may make the patch application less robust, though.  I dunno.

An alternative, and probably more robust, approach would be to recount
what we have in @{$mode->{TEXT}}, after letting the user edit some of
them, so that "add--interactive" still knows what it is doing after
applying your patch without having to rely on "apply --recount".

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Thomas Rast]

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

Junio C Hamano wrote:
> 
> People with minimum Perl installation should still be able to use "add -i"
> as long as they do not use 'e' subcommand, shouldn't they?  Shouldn't we
> do something like:
[...]
> and disable 'e' subcommand unless $can_use_temp?

I can just call the temporary editing file something constant, like
the commit message already is.  I don't care much about that point,
and honestly assumed File::Temp came with every Perl (it's in
perl-base here).

> > +# To remove '-' lines, make them ' ' lines (context).
> > +# To remove '+' lines, delete them.
> > +# Lines starting with # will be removed.
> 
> Don't you want to say "Do not touch lines that begin with ' '"?

Why?  You can make them '-' instead if you really want to :-)

> > +	# Reinsert the first hunk header if the user accidentally deleted it
> 
> Hmm, perhaps not even giving the "@@ ... @@" lines to the editor would be
> a more robust solution?

I originally left it there because Emacs automatically recounts the
header, and it also reminds the user of the function the hunk applies
to.

> > +	open $fh, '| git apply --recount --cached --check';
> 
> Have to wonder where the potential error message would go, and if it would
> confuse the end users...

To the terminal.  If we eat that error message, the user gets
absolutely no indication as to _what_ might be wrong with the edited
patch, so I kind of deliberately left it there.

Then again the message from git-apply is not exactly transparent
either.

> I recall that the original "add--interactive" carefully counted numbers in
> hunks it reassembles (as it can let you split and then you can choose to
> use both parts, which requires it to merge overlapping hunks back), but if
> you are going to use --recount anyway, perhaps we can discard that logic?

We briefly talked about that[1], but Jeff thought it should be a
separate patch, and I agree.  Can't sneakily rip out two dozen lines
of otherwise unrelated code in my feature patch, can I?

> It may make the patch application less robust, though.  I dunno.

I've become convinced it can't, apart from making it less likely to
trip over bugs in the script itself of course.

> An alternative, and probably more robust, approach would be to recount
> what we have in @{$mode->{TEXT}}, after letting the user edit some of
> them, so that "add--interactive" still knows what it is doing after
> applying your patch without having to rely on "apply --recount".

You lost me here.  Why recount the mode part?

If you mean the _hunk_ headers, that's what the first three versions
of this patch did, at the expense of a lot of code complication (and
now that git-apply implements --recount, actually _duplication_).

- Thomas


[1] http://article.gmane.org/gmane.comp.version-control.git/84698

-- 
Thomas Rast
trast@student.ethz.ch


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Jeff King]

On Tue, Jul 01, 2008 at 10:39:58PM -0700, Junio C Hamano wrote:

> > +use File::Temp;
> 
> People with minimum Perl installation should still be able to use "add -i"
> as long as they do not use 'e' subcommand, shouldn't they?  Shouldn't we
> do something like:
> 
> 	my $can_use_temp = eval {
>         	require File::Temp;
>                 1;
> 	};
> 
> and disable 'e' subcommand unless $can_use_temp?

According to Module::CoreList, File::Temp has shipped as part of core
perl since 5.006001. "add -i" doesn't work with perl < 5.6 already due to
things like 3-argument open.

So if the problem is "old perl", I don't think it is an issue. Are there
modern perl installations in the wild that don't have File::Temp?

-Peff

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> According to Module::CoreList, File::Temp has shipped as part of core
> perl since 5.006001. "add -i" doesn't work with perl < 5.6 already due to
> things like 3-argument open.
>
> So if the problem is "old perl", I don't think it is an issue. Are there
> modern perl installations in the wild that don't have File::Temp?

The thing is, I think I heard quite similar explanation why Test::More is
safe to use when the patch to add t/t9700 was submit.  Then what happened?

Re: How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))

[Steffen Prohaska]

On Jun 30, 2008, at 8:47 PM, Johannes Sixt wrote:

> Then there are the extra patches in 4msysgit. From my POV, they are  
> not
> _required_ because I can appearently work with git on Windows  
> without them. I
> think some of them are not necessary. Can we go through them again?


I'll send a patch series in reply to this mail that contains the
following patches:

  [PATCH 01/12] Fake reencoding success under NO_ICONV instead of  
returning NULL.
  [PATCH 02/12] Do not complain about "no common commits" in an empty  
repo
  [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures
  [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.
  [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in  
default browser
  [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)
  [PATCH 07/12] Fixed text file auto-detection: treat EOF character  
032 at the end of file as printable
  [PATCH 08/12] fast-import: MinGW does not have getppid().  So do not  
print it.
  [PATCH 09/12] We need to check for msys as well as Windows in add-- 
interactive.
  [PATCH 10/12] Add ANSI control code emulation for the Windows console
  [PATCH 11/12] verify_path(): do not allow absolute paths
  [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

This series would bring *.{c,h,sh,perl} on Junio's next to 4msysgit/ 
next,
except for some minor differences (whitespace, comments, a workaround in
git-parse-remote.sh).

	Steffen

[PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL.

[Steffen Prohaska]

From: Johannes Sixt <johannes.sixt@telecom.at>

git-am when invoked from git-rebase seems to rely on successful conversion.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 utf8.c |    7 +++++++
 utf8.h |    4 ----
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/utf8.c b/utf8.c
index dc37353..b07d43e 100644
--- a/utf8.c
+++ b/utf8.c
@@ -388,4 +388,11 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
 	iconv_close(conv);
 	return out;
 }
+#else
+char *reencode_string(const char *in, const char *out_encoding, const char *in_encoding)
+{
+	if (!in_encoding)
+		return NULL;
+	return xstrdup(in);
+}
 #endif
diff --git a/utf8.h b/utf8.h
index 98cce1b..f22ef31 100644
--- a/utf8.h
+++ b/utf8.h
@@ -10,10 +10,6 @@ int is_encoding_utf8(const char *name);
 
 int print_wrapped_text(const char *text, int indent, int indent2, int len);
 
-#ifndef NO_ICONV
 char *reencode_string(const char *in, const char *out_encoding, const char *in_encoding);
-#else
-#define reencode_string(a,b,c) NULL
-#endif
 
 #endif
-- 
1.5.6.1.255.g32571

[PATCH 02/12] Do not complain about "no common commits" in an empty repo

[Steffen Prohaska]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

If the repo is empty, we know that already, thank you very much.
So shut fetch-pack up about that case.

Fixes issue 3, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 builtin-fetch-pack.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index f4dbcf0..2175c6d 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -309,7 +309,8 @@ done:
 		}
 		flushes--;
 	}
-	return retval;
+	/* it is no error to fetch into a completely empty repo */
+	return count ? retval : 0;
 }
 
 static struct commit_list *complete;
-- 
1.5.6.1.255.g32571

[PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures

[Steffen Prohaska]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

On Windows, gpg outputs CR/LF signatures.  But since the tag
messages are already stripped of the CR by stripspace(), it is
arguably nicer to do the same for the tag signature.  Actually,
this patch does not look for CR/LF, but strips all CRs
from the signature.

[ spr: ported code to use strbuf ]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 builtin-tag.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/builtin-tag.c b/builtin-tag.c
index e675206..77977ba 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -241,6 +241,20 @@ static int do_sign(struct strbuf *buffer)
 	if (finish_command(&gpg) || !len || len < 0)
 		return error("gpg failed to sign the tag");
 
+#ifdef __MINGW32__
+	/* strip CR from the line endings */
+	{
+		int i, j;
+		for (i = j = 0; i < buffer->len; i++)
+			if (buffer->buf[i] != '\r') {
+				if (i != j)
+					buffer->buf[j] = buffer->buf[i];
+				j++;
+			}
+		strbuf_setlen(buffer, j);
+	}
+#endif
+
 	return 0;
 }
 
-- 
1.5.6.1.255.g32571

[PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.

[Steffen Prohaska]

From: Marius Storm-Olsen <mstormo_git@storm-olsen.com>

SIGPIPE isn't supported in MinGW.

Signed-off-by: Marius Storm-Olsen <mstormo_git@storm-olsen.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 builtin-verify-tag.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/builtin-verify-tag.c b/builtin-verify-tag.c
index 92eaa89..540e3b9 100644
--- a/builtin-verify-tag.c
+++ b/builtin-verify-tag.c
@@ -100,9 +100,11 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix)
 		i++;
 	}
 
+#ifndef __MINGW32__
 	/* sometimes the program was terminated because this signal
 	 * was received in the process of writing the gpg input: */
 	signal(SIGPIPE, SIG_IGN);
+#endif	
 	while (i < argc)
 		if (verify_tag(argv[i++], verbose))
 			had_error = 1;
-- 
1.5.6.1.255.g32571

[PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser

[Steffen Prohaska]

The implementation directly calls the Win32 API to launch the browser.
Note that the specific directory layout of msysgit is required.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 cache.h |    2 ++
 help.c  |   28 ++++++++++++++++++++++++++++
 path.c  |   13 +++++++++++++
 3 files changed, 43 insertions(+), 0 deletions(-)

diff --git a/cache.h b/cache.h
index 0d8edda..958d257 100644
--- a/cache.h
+++ b/cache.h
@@ -529,6 +529,8 @@ const char *make_nonrelative_path(const char *path);
 const char *make_relative_path(const char *abs, const char *base);
 int normalize_absolute_path(char *buf, const char *path);
 int longest_ancestor_length(const char *path, const char *prefix_list);
+/* Convert slashes to backslashes on Windows. */
+char *make_native_separator(char *path);
 
 /* Read and unpack a sha1 file into memory, write memory to a sha1 file */
 extern int sha1_object_info(const unsigned char *, unsigned long *);
diff --git a/help.c b/help.c
index ca9632b..811f8db 100644
--- a/help.c
+++ b/help.c
@@ -9,6 +9,7 @@
 #include "common-cmds.h"
 #include "parse-options.h"
 #include "run-command.h"
+#include "dir.h"
 
 static struct man_viewer_list {
 	struct man_viewer_list *next;
@@ -28,7 +29,11 @@ enum help_format {
 };
 
 static int show_all = 0;
+#ifdef __MINGW32__
+static enum help_format help_format = HELP_FORMAT_WEB;
+#else
 static enum help_format help_format = HELP_FORMAT_MAN;
+#endif
 static struct option builtin_help_options[] = {
 	OPT_BOOLEAN('a', "all", &show_all, "print all available commands"),
 	OPT_SET_INT('m', "man", &help_format, "show man page", HELP_FORMAT_MAN),
@@ -644,12 +649,35 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
 
 static void show_html_page(const char *git_cmd)
 {
+#ifdef __MINGW32__
+	const char* exec_path = git_exec_path();
+	char *htmlpath = make_native_separator(
+			   mkpath("%s/../doc/git/html/%s.html"
+				  , exec_path
+				  , git_cmd)
+			 );
+	if (!file_exists(htmlpath)) {
+		htmlpath = make_native_separator(
+			      mkpath("%s/../doc/git/html/git-%s.html"
+				     , exec_path
+				     , git_cmd)
+			   );
+		if (!file_exists(htmlpath)) {
+			fprintf(stderr, "Can't find HTML help for '%s'.\n"
+				, git_cmd);
+			exit(1);
+		}
+	}
+	printf("Launching default browser to display HTML help ...\n");
+	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
+#else
 	const char *page = cmd_to_page(git_cmd);
 	struct strbuf page_path; /* it leaks but we exec bellow */
 
 	get_html_page_path(&page_path, page);
 
 	execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL);
+#endif
 }
 
 void help_unknown_cmd(const char *cmd)
diff --git a/path.c b/path.c
index 5983255..2a4a76a 100644
--- a/path.c
+++ b/path.c
@@ -439,3 +439,16 @@ int longest_ancestor_length(const char *path, const char *prefix_list)
 
 	return max_len;
 }
+
+char *make_native_separator(char* path) {
+#ifdef __MINGW32__
+	char* c;
+	for (c = path; *c; c++) {
+		if (*c == '/')
+			*c = '\\';
+	}
+	return path;
+#else
+	return path;
+#endif
+}
-- 
1.5.6.1.255.g32571

[PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Steffen Prohaska]

From: Edward Z. Yang <edwardzyang@thewritingpot.com>

PuTTY requires -P while OpenSSH requires -p; if plink is detected
as GIT_SSH, use the alternate flag.

Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 connect.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/connect.c b/connect.c
index 574f42f..0d007f3 100644
--- a/connect.c
+++ b/connect.c
@@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 	conn->argv = arg = xcalloc(6, sizeof(*arg));
 	if (protocol == PROTO_SSH) {
 		const char *ssh = getenv("GIT_SSH");
+		int putty = ssh && strstr(ssh, "plink");
 		if (!ssh) ssh = "ssh";
 
 		*arg++ = ssh;
 		if (port) {
-			*arg++ = "-p";
+			/* P is for PuTTY, p is for OpenSSH */
+			*arg++ = putty ? "-P" : "-p";
 			*arg++ = port;
 		}
 		*arg++ = host;
-- 
1.5.6.1.255.g32571

[PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

[Steffen Prohaska]

From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>

Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 convert.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/convert.c b/convert.c
index 1c66844..f24ac25 100644
--- a/convert.c
+++ b/convert.c
@@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
 		else
 			stats->printable++;
 	}
+
+	// If file ends with EOF then don't count this EOF as non-printable
+	if ( size >= 1 && buf[size-1] == '\032' )
+		stats->nonprintable--;
 }
 
 /*
-- 
1.5.6.1.255.g32571

[PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.

[Steffen Prohaska]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 fast-import.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/fast-import.c b/fast-import.c
index e72b286..271b93c 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -391,7 +391,9 @@ static void write_crash_report(const char *err)
 
 	fprintf(rpt, "fast-import crash report:\n");
 	fprintf(rpt, "    fast-import process: %d\n", getpid());
+#ifndef __MINGW32__
 	fprintf(rpt, "    parent process     : %d\n", getppid());
+#endif
 	fprintf(rpt, "    at %s\n", show_date(time(NULL), 0, DATE_LOCAL));
 	fputc('\n', rpt);
 
-- 
1.5.6.1.255.g32571

[PATCH 09/12] We need to check for msys as well as Windows in add--interactive.

[Steffen Prohaska]

From: Mike Pape <dotzenlabs@gmail.com>

Signed-off-by: Mike Pape <dotzenlabs@gmail.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 git-add--interactive.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 903953e..78a64e6 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -42,7 +42,7 @@ sub colored {
 my $patch_mode;
 
 sub run_cmd_pipe {
-	if ($^O eq 'MSWin32') {
+	if ($^O eq 'MSWin32' || $^O eq 'msys') {
 		my @invalid = grep {m/[":*]/} @_;
 		die "$^O does not support: @invalid\n" if @invalid;
 		my @args = map { m/ /o ? "\"$_\"": $_ } @_;
-- 
1.5.6.1.255.g32571

[PATCH 10/12] Add ANSI control code emulation for the Windows console

[Steffen Prohaska]

From: Peter <git@peter.is-a-geek.org>

This adds only the minimum necessary to keep git pull/merge's diffstat from
wrapping. Notably absent is support for the K (erase) operation, and support
for POSIX write.

Cygwin does not need the WIN_ANSI define, since it has its own (more complete)
ANSI emulation.

Signed-off-by: Peter Harris <git@peter.is-a-geek.org>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 Makefile          |    6 +
 compat/winansi.c  |  309 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 git-compat-util.h |    7 ++
 3 files changed, 322 insertions(+), 0 deletions(-)
 create mode 100644 compat/winansi.c

diff --git a/Makefile b/Makefile
index 5914e1a..a7f2dcb 100644
--- a/Makefile
+++ b/Makefile
@@ -737,6 +737,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
 	NO_SVN_TESTS = YesPlease
 	NO_PERL_MAKEMAKER = YesPlease
 	NO_POSIX_ONLY_PROGRAMS = YesPlease
+	WIN_ANSI = YesPlease
 	COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat
 	COMPAT_CFLAGS += -DSNPRINTF_SIZE_CORR=1
 	COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
@@ -981,6 +982,11 @@ ifdef NO_EXTERNAL_GREP
 	BASIC_CFLAGS += -DNO_EXTERNAL_GREP
 endif
 
+ifdef WIN_ANSI
+	COMPAT_CFLAGS += -DWIN_ANSI
+	COMPAT_OBJS += compat/winansi.o
+endif
+
 ifeq ($(TCLTK_PATH),)
 NO_TCLTK=NoThanks
 endif
diff --git a/compat/winansi.c b/compat/winansi.c
new file mode 100644
index 0000000..86c3fd2
--- /dev/null
+++ b/compat/winansi.c
@@ -0,0 +1,309 @@
+#include <windows.h>
+#include "../git-compat-util.h"
+
+/*
+ Functions to be wrapped:
+*/
+#undef printf
+#undef fputs
+
+/*
+ ANSI codes to implement: m, K
+*/
+
+static HANDLE console;
+static WORD plain_attr;
+static WORD attr;
+static int negative;
+
+static void init(void)
+{
+    CONSOLE_SCREEN_BUFFER_INFO sbi;
+
+    static int initialized = 0;
+    if (initialized)
+	return;
+
+    console = GetStdHandle(STD_OUTPUT_HANDLE);
+    if (console == INVALID_HANDLE_VALUE)
+	console = NULL;
+
+    if (!console)
+	return;
+
+    GetConsoleScreenBufferInfo(console, &sbi);
+    attr = plain_attr = sbi.wAttributes;
+    negative = 0;
+
+    initialized = 1;
+}
+
+
+#define FOREGROUND_ALL (FOREGROUND_RED | FOREGROUND_GREEN | FOREGROUND_BLUE)
+#define BACKGROUND_ALL (BACKGROUND_RED | BACKGROUND_GREEN | BACKGROUND_BLUE)
+
+static void set_console_attr(void)
+{
+    WORD attributes = attr;
+    if (negative) {
+	attributes &= ~FOREGROUND_ALL;
+	attributes &= ~BACKGROUND_ALL;
+
+	/* This could probably use a bitmask instead of a series of ifs */
+	if (attr & FOREGROUND_RED)
+	    attributes |= BACKGROUND_RED;
+	if (attr & FOREGROUND_GREEN)
+	    attributes |= BACKGROUND_GREEN;
+	if (attr & FOREGROUND_BLUE)
+	    attributes |= BACKGROUND_BLUE;
+
+	if (attr & BACKGROUND_RED)
+	    attributes |= FOREGROUND_RED;
+	if (attr & BACKGROUND_GREEN)
+	    attributes |= FOREGROUND_GREEN;
+	if (attr & BACKGROUND_BLUE)
+	    attributes |= FOREGROUND_BLUE;
+    }
+    SetConsoleTextAttribute(console, attributes);
+}
+
+static const char *set_attr(const char *str)
+{
+    const char *func;
+    size_t len = strspn(str, "0123456789;");
+    func = str + len;
+
+    switch (*func) {
+    case 'm':
+	do {
+	    long val = strtol(str, (char **)&str, 10);
+	    switch (val) {
+	    case 0: /* reset */
+		attr = plain_attr;
+		negative = 0;
+		break;
+	    case 1: /* bold */
+		attr |= FOREGROUND_INTENSITY;
+		break;
+	    case 2:  /* faint */
+	    case 22: /* normal */
+		attr &= ~FOREGROUND_INTENSITY;
+		break;
+	    case 3:  /* italic */
+		/* Unsupported */
+		break;
+	    case 4:  /* underline */
+	    case 21: /* double underline */
+		/* Wikipedia says this flag does nothing */
+		/* Furthermore, mingw doesn't define this flag
+		attr |= COMMON_LVB_UNDERSCORE; */
+		break;
+	    case 24: /* no underline */
+		/* attr &= ~COMMON_LVB_UNDERSCORE; */
+		break;
+	    case 5:  /* slow blink */
+	    case 6:  /* fast blink */
+		/* We don't have blink, but we do have background intensity */
+		attr |= BACKGROUND_INTENSITY;
+		break;
+	    case 25: /* no blink */
+		attr &= ~BACKGROUND_INTENSITY;
+		break;
+	    case 7:  /* negative */
+		negative = 1;
+		break;
+	    case 27: /* positive */
+		negative = 0;
+		break;
+	    case 8:  /* conceal */
+	    case 28: /* reveal */
+		/* Unsupported */
+		break;
+	    case 30: /* Black */
+		attr &= ~FOREGROUND_ALL;
+		break;
+	    case 31: /* Red */
+		attr &= ~FOREGROUND_ALL;
+		attr |= FOREGROUND_RED;
+		break;
+	    case 32: /* Green */
+		attr &= ~FOREGROUND_ALL;
+		attr |= FOREGROUND_GREEN;
+		break;
+	    case 33: /* Yellow */
+		attr &= ~FOREGROUND_ALL;
+		attr |= FOREGROUND_RED | FOREGROUND_GREEN;
+		break;
+	    case 34: /* Blue */
+		attr &= ~FOREGROUND_ALL;
+		attr |= FOREGROUND_BLUE;
+		break;
+	    case 35: /* Magenta */
+		attr &= ~FOREGROUND_ALL;
+		attr |= FOREGROUND_RED | FOREGROUND_BLUE;
+		break;
+	    case 36: /* Cyan */
+		attr &= ~FOREGROUND_ALL;
+		attr |= FOREGROUND_GREEN | FOREGROUND_BLUE;
+		break;
+	    case 37: /* White */
+		attr |= FOREGROUND_RED | FOREGROUND_GREEN | FOREGROUND_BLUE;
+		break;
+	    case 38: /* Unknown */
+		break;
+	    case 39: /* reset */
+		attr &= ~FOREGROUND_ALL;
+		attr |= (plain_attr & FOREGROUND_ALL);
+		break;
+	    case 40: /* Black */
+		attr &= ~BACKGROUND_ALL;
+		break;
+	    case 41: /* Red */
+		attr &= ~BACKGROUND_ALL;
+		attr |= BACKGROUND_RED;
+		break;
+	    case 42: /* Green */
+		attr &= ~BACKGROUND_ALL;
+		attr |= BACKGROUND_GREEN;
+		break;
+	    case 43: /* Yellow */
+		attr &= ~BACKGROUND_ALL;
+		attr |= BACKGROUND_RED | BACKGROUND_GREEN;
+		break;
+	    case 44: /* Blue */
+		attr &= ~BACKGROUND_ALL;
+		attr |= BACKGROUND_BLUE;
+		break;
+	    case 45: /* Magenta */
+		attr &= ~BACKGROUND_ALL;
+		attr |= BACKGROUND_RED | BACKGROUND_BLUE;
+		break;
+	    case 46: /* Cyan */
+		attr &= ~BACKGROUND_ALL;
+		attr |= BACKGROUND_GREEN | BACKGROUND_BLUE;
+		break;
+	    case 47: /* White */
+		attr |= BACKGROUND_RED | BACKGROUND_GREEN | BACKGROUND_BLUE;
+		break;
+	    case 48: /* Unknown */
+		break;
+	    case 49: /* reset */
+		attr &= ~BACKGROUND_ALL;
+		attr |= (plain_attr & BACKGROUND_ALL);
+		break;
+	    default:
+		/* Unsupported code */
+		break;
+	    }
+	    str++;
+	} while (*(str-1) == ';');
+
+	set_console_attr();
+	break;
+    case 'K':
+	/* TODO */
+	break;
+    default:
+	/* Unsupported code */
+	break;
+    }
+
+    return func + 1;
+}
+
+static int ansi_emulate(const char *str, FILE *stream)
+{
+    int rv = 0;
+    const char *pos = str;
+
+    while (*pos) {
+	pos = strstr(str, "\033[");
+	if (pos) {
+	    size_t len = pos - str;
+
+	    if (len) {
+		size_t output_len = fwrite(str, 1, len, stream);
+		rv += output_len;
+		if (output_len < len)
+		    return rv;
+	    }
+
+	    str = pos + 2;
+	    rv += 2;
+
+	    fflush(stream);
+
+	    pos = set_attr(str);
+	    rv += pos - str;
+	    str = pos;
+	} else {
+	    rv += strlen(str);
+	    fputs(str, stream);
+	    return rv;
+	}
+    }
+    return rv;
+}
+
+int git_fputs(const char *str, FILE *stream)
+{
+    int rv;
+
+    init();
+
+    if (!console)
+	return fputs(str, stream);
+
+    if (!isatty(fileno(stream)))
+	return fputs(str, stream);
+
+    rv = ansi_emulate(str, stream);
+
+    if (rv >= 0)
+	return 0;
+    else
+	return EOF;
+}
+
+int git_printf(const char *format, ...)
+{
+    va_list list;
+
+    char small_buf[256];
+    char *buf = small_buf;
+    int len, rv;
+
+    init();
+
+    if (!console)
+	goto abort;
+
+    if (!isatty(fileno(stdout)))
+	goto abort;
+
+    va_start(list, format);
+    len = vsnprintf(small_buf, sizeof(small_buf), format, list);
+    va_end(list);
+
+    if (len > sizeof(small_buf) - 1) {
+	buf = malloc(len + 1);
+	if (!buf)
+	    goto abort;
+
+	va_start(list, format);
+	len = vsnprintf(buf, len + 1, format, list);
+	va_end(list);
+    }
+
+    rv = ansi_emulate(buf, stdout);
+
+    if (buf != small_buf)
+	free(buf);
+    return rv;
+
+abort:
+    va_start(list, format);
+    rv = vprintf(format, list);
+    va_end(list);
+    return rv;
+}
diff --git a/git-compat-util.h b/git-compat-util.h
index 545df59..fc5168e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -357,4 +357,11 @@ void git_qsort(void *base, size_t nmemb, size_t size,
 # define FORCE_DIR_SET_GID 0
 #endif
 
+#ifdef WIN_ANSI
+extern int git_fputs(const char *str, FILE *stream);
+extern int git_printf(const char *format, ...) __attribute__((format (printf, 1, 2)));
+#define fputs git_fputs
+#define printf(...) git_printf(__VA_ARGS__)
+#endif
+
 #endif
-- 
1.5.6.1.255.g32571

[PATCH 11/12] verify_path(): do not allow absolute paths

[Steffen Prohaska]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 read-cache.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index f83de8c..cb130ef 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -650,6 +650,11 @@ int verify_path(const char *path)
 {
 	char c;
 
+#ifdef __MINGW32__
+	if (is_absolute_path(path))
+		return error("Cannot handle absolute path: %s", path);
+#endif
+
 	goto inside;
 	for (;;) {
 		if (!c)
-- 
1.5.6.1.255.g32571

[PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

[Steffen Prohaska]

From: Johannes Sixt <johannes.sixt@telecom.at>

Hannes,
You introduced "minoffset" in 861429a7c37c7.  Here is your original
message:

'''
An earlier patch has implemented getcwd() so that it converts the
drive letter into the POSIX-like path that is used internally by
MinGW (C:\foo => /c/foo), but this style does not work outside
the MinGW shell. It is better to just convert the backslashes
to forward slashes and handle the drive letter explicitly.
'''

Dmitry replaced setenv() with set_git_dir in 855f254b2b5b08.
Here is his original message:

'''
git clone was failing with 'invalid object name HEAD' if ran from
cmd.exe directly

environment.c caches results of many getenv calls.
Under MinGW setenv(X) invalidates all previous values returned by
getenv(X)
so cached values become dangling pointers.

Replaced all setenv(GIT_DIR, ...) with set_git_dir

Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
'''
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 setup.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/setup.c b/setup.c
index 6cf9094..1fd30c4 100644
--- a/setup.c
+++ b/setup.c
@@ -381,6 +381,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
 	const char *gitdirenv;
 	const char *gitfile_dir;
 	int len, offset, ceil_offset;
+	int minoffset = 0;
 
 	/*
 	 * Let's assume that we are in a git repository.
@@ -431,6 +432,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
 
 	if (!getcwd(cwd, sizeof(cwd)-1))
 		die("Unable to read current working directory");
+	if (has_dos_drive_prefix(cwd))
+		minoffset = 2;
 
 	ceil_offset = longest_ancestor_length(cwd, env_ceiling_dirs);
 	if (ceil_offset < 0 && has_dos_drive_prefix(cwd))
@@ -461,11 +464,11 @@ const char *setup_git_directory_gently(int *nongit_ok)
 			inside_git_dir = 1;
 			if (!work_tree_env)
 				inside_work_tree = 0;
-			setenv(GIT_DIR_ENVIRONMENT, ".", 1);
+			set_git_dir(".");
 			check_repository_format_gently(nongit_ok);
 			return NULL;
 		}
-		while (--offset > ceil_offset && cwd[offset] != '/');
+		while (offset > minoffset && --offset > ceil_offset && cwd[offset] != '/');
 		if (offset <= ceil_offset) {
 			if (nongit_ok) {
 				if (chdir(cwd))
-- 
1.5.6.1.255.g32571

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Jeff King]

On Wed, Jul 02, 2008 at 01:08:09AM -0700, Junio C Hamano wrote:

> > So if the problem is "old perl", I don't think it is an issue. Are there
> > modern perl installations in the wild that don't have File::Temp?
> 
> The thing is, I think I heard quite similar explanation why Test::More is
> safe to use when the patch to add t/t9700 was submit.  Then what happened?

ISTR the Test::More problem was reported by Linus, who is a Fedora user?
I tried searching for any reasonable information on which of the core
perl modules are installed by default on Fedora systems, but didn't come
up with anything useful.

I really have no clue as to what is out there, and I suspect we must
either play it totally safe, or push the limits and wait for people to
complain about breakage.

-Peff

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> Junio C Hamano wrote:
> ...
>> > +# To remove '-' lines, make them ' ' lines (context).
>> > +# To remove '+' lines, delete them.
>> > +# Lines starting with # will be removed.
>> 
>> Don't you want to say "Do not touch lines that begin with ' '"?
>
> Why?  You can make them '-' instead if you really want to :-)

If you change '-' to ' ', or remove '+', then you are temporarily
reverting the change you have made since HEAD to your working tree copy.
If you do not change anything, you are taking something that was in your
working tree copy.  Both are simpler and easier to explain operations.

Once you allow changing ' ' to '-' or insert '+' at random places,
however, you are letting the user commit lines that is neither from HEAD
nor from the working tree.

If the goal of "e" action in "add -i" is to support that operation (I am
not saying that it is a bad thing to support), you have to deal with an
issue that your patch so far did not have to deal with, and it would
require a much larger change to the way how "add -i" is structured.

When you give the user a hunk like this to edit:

  @@ -4,9 +4,6 @@ GIT v1.6.0 Release Notes
   User visible changes
   --------------------

  -[[Note that none of these are not merged to 'master' as of this writing
  -but they will be before 1.6.0 happens]]
  -
   With the default Makefile settings, most of the programs are now
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical

the user may want to change the line before the line that has "User
visible changes", or the lines toward the end of the hunk. The user may
want to edit the line that ends with "for technical" for rewording the
sentence, but the rest of the sentence is outside the context, and these
lines somehow needs to be summoned to the editing session for completing
the updated sentence.  In order to support that, you need to be able to
extend the context on demand in either direction, beyond the original "git
diff" output you captured in $hunk[$i]{TEXT} (sorry, I misspelled this as
$mode->{TEXT} in the previous message).

Once you start to do that, you would need to worry about the case where
the hunk extended to include later lines overlaps with the hunk after the
one we are currently looking at, and run coalesce_overlapping_hunks to
concatenate them into a larger single hunk.  But to be able to do that,
you would need to keep track of the number of lines in a hunk yourself
anyway, which would mean that you cannot rely on --recount anymore.  The
extension recently made to "git apply" becomes redundant and unused code.

In short, declaring that you are supporting the use to change ' ' to '-'
means you are opening a whole can of worms, and I asked the question
because I did not know if you are really prepared to deal with it.

Re: [PATCH 02/12] Do not complain about "no common commits" in an empty repo

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> If the repo is empty, we know that already, thank you very much.
> So shut fetch-pack up about that case.

Two complaints.

 * What does this have to do with Windows port?  Please don't hide a
   general interface change in a larger and mostly unrelated topic.

 * Do you think people can tell without reading the code in larger context
   outside the patch and this commit log text if you are talking about the
   case you fetch _into_ an empty repository, or if you are attempting to
   fetch _from_ an empty repository, or what?  Please try to be a bit
   easier for _readers_.  Being more redundant and verbose is better than
   being too concise.

About the first point, "no common commits" is just a friendly reminder and
not even an error.  When you see it, you will learn to expect looooooooong
download session.

I personally happen to agree with the logic of this patch, though --- if
you are fetching into an empty repository, you would already expect that
the download is as big as the other end anyway, so you would not need to
be further reminded about that.

But that is just one-man's opinion.  Maybe somebody knows a reason why I
am (and the logic I am agreeing with is) wrong.  Maybe not.  So make the
"remainder of Windows port" series 11 commits, and send this as a general
interface fix via the normal channel to be discussed, please.

Re: [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> +/* Convert slashes to backslashes on Windows. */
> +char *make_native_separator(char *path);

Makes one onder why it is not inside #ifdef, but presumably it is no-op on
other platforms (which is fine, better than fine)?

>  static int show_all = 0;
> +#ifdef __MINGW32__
> +static enum help_format help_format = HELP_FORMAT_WEB;
> +#else
>  static enum help_format help_format = HELP_FORMAT_MAN;
> +#endif

That's Ugly isn't it?  Can't you do this with Makefile macro without
#ifdef please?

> @@ -644,12 +649,35 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
>  
>  static void show_html_page(const char *git_cmd)
>  {
> +#ifdef __MINGW32__
> +	const char* exec_path = git_exec_path();
> +	char *htmlpath = make_native_separator(
> +			   mkpath("%s/../doc/git/html/%s.html"
> +				  , exec_path
> +				  , git_cmd)
> +			 );
> +	if (!file_exists(htmlpath)) {
> +		htmlpath = make_native_separator(
> +			      mkpath("%s/../doc/git/html/git-%s.html"
> +				     , exec_path
> +				     , git_cmd)
> +			   );
> +		if (!file_exists(htmlpath)) {
> +			fprintf(stderr, "Can't find HTML help for '%s'.\n"
> +				, git_cmd);
> +			exit(1);
> +		}
> +	}
> +	printf("Launching default browser to display HTML help ...\n");
> +	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
> +#else
>  	const char *page = cmd_to_page(git_cmd);
>  	struct strbuf page_path; /* it leaks but we exec bellow */
>  
>  	get_html_page_path(&page_path, page);
>  
>  	execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL);
> +#endif
>  }

Hmm.  The above almost makes me barf and suggest making them two totally
separate functions (i.e. introduce a new "show_html_page_on_windows()"
function and do not bother us Unix folks ;-).

But I suspect your code is not beyond salvaging.  Why is the htmlpath
computed by hand in this function, instead of having the port specific
implementation hidden inside get_html_page_path() function?

About the execution part, isn't it the matter of using "open" (whatever
that is) as one of the supported backend for web--browse to unify these
two independent case arms?

Re: [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
>
> Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
>  convert.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/convert.c b/convert.c
> index 1c66844..f24ac25 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
>  		else
>  			stats->printable++;
>  	}
> +
> +	// If file ends with EOF then don't count this EOF as non-printable
> +	if ( size >= 1 && buf[size-1] == '\032' )
> +		stats->nonprintable--;

Style.

I debated for 5 seconds with myself if this should be inside #ifdef, but
doing this everywhere would give us reproducibility --- otherwise the
resulting project won't be cross platform, so I think the intention of
this change is good.

Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> diff --git a/fast-import.c b/fast-import.c
> index e72b286..271b93c 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -391,7 +391,9 @@ static void write_crash_report(const char *err)
>  
>  	fprintf(rpt, "fast-import crash report:\n");
>  	fprintf(rpt, "    fast-import process: %d\n", getpid());
> +#ifndef __MINGW32__
>  	fprintf(rpt, "    parent process     : %d\n", getppid());
> +#endif
>  	fprintf(rpt, "    at %s\n", show_date(time(NULL), 0, DATE_LOCAL));
>  	fputc('\n', rpt);
>  
> -- 
> 1.5.6.1.255.g32571

It does not matter too much for this part that writes crash report, but
keeping the file format the same across platforms will make it easier for
tools to read output, so as a general principle, I think this is a
suboptimal solution to the issue.  How about throwing something like this
in MinGW specific header files?

        #define getppid() 0

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>

No commit log message?  Justification?

Re: [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> From: Marius Storm-Olsen <mstormo_git@storm-olsen.com>
>
> SIGPIPE isn't supported in MinGW.

Shouldn't #ifdef be on SIGPIPE not on __MINGW32__?

> @@ -100,9 +100,11 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix)
>  		i++;
>  	}
>  
> +#ifndef __MINGW32__
>  	/* sometimes the program was terminated because this signal
>  	 * was received in the process of writing the gpg input: */
>  	signal(SIGPIPE, SIG_IGN);
> +#endif	

Re: [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.

[Marius Storm-Olsen]

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

Junio C Hamano said the following on 02.07.2008 11:22:
> Steffen Prohaska <prohaska@zib.de> writes:
> 
>> From: Marius Storm-Olsen <mstormo_git@storm-olsen.com>
>>
>> SIGPIPE isn't supported in MinGW.
> 
> Shouldn't #ifdef be on SIGPIPE not on __MINGW32__?

That's certainly a good suggestion. :-)

-- 
.marius [@] storm-olsen [.com]
'if you know what you're doing, it's not research'


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

[PATCH] Disconnect stash from its base commit

[Nanako Shiraishi]

A stash records the state of the files in the working tree as a merge
between the HEAD and another commit that records the state of the index,
that in turn is a child commit of the HEAD commit.  In order to later
apply (or pop) the stash, however, only the tree objects of these three
commits are necessary.

This patch changes the structure of a stash to use a parentless new commit
that has the same tree as the HEAD commit, in place of the HEAD commit.
This way, a stash does not keep the history that leads to the HEAD commit
reachable, even if the stash is kept forever.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---

 The patch in the message Olivier quoted alone will be insufficient.  This
 is an update to that patch.

 Documentation/git-stash.txt |   14 +++++++-------
 git-stash.sh                |    3 +++
 t/t3903-stash.sh            |    2 +-
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 23ac331..17c65e9 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -101,18 +101,18 @@ DISCUSSION
 ----------
 
 A stash is represented as a commit whose tree records the state of the
-working directory, and its first parent is the commit at `HEAD` when
-the stash was created.  The tree of the second parent records the
+working directory, and its first parent is the commit that has the same
+tree as the `HEAD`.  The tree of the second parent records the
 state of the index when the stash is made, and it is made a child of
-the `HEAD` commit.  The ancestry graph looks like this:
+the first commit.  The ancestry graph looks like this:
 
             .----W
            /    /
-     -----H----I
+	  H*---I
 
-where `H` is the `HEAD` commit, `I` is a commit that records the state
-of the index, and `W` is a commit that records the state of the working
-tree.
+where `H{asterisk}` is a commit with the same tree as the `HEAD`, `I` is
+a commit that records the state of the index, and `W` is a commit that
+records the state of the working tree.
 
 
 EXAMPLES
diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..8f374b3 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -54,6 +54,9 @@ create_stash () {
 	fi
 	msg=$(printf '%s: %s' "$branch" "$head")
 
+	# create the base commit that is parentless
+	b_commit=$(printf 'base of %s\n' "$msg" | git commit-tree "HEAD:")
+
 	# state of the index
 	i_tree=$(git write-tree) &&
 	i_commit=$(printf 'index on %s\n' "$msg" |
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 54d99ed..b083c04 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -32,7 +32,7 @@ index 0cfbf08..00750ed 100644
 EOF
 
 test_expect_success 'parents of stash' '
-	test $(git rev-parse stash^) = $(git rev-parse HEAD) &&
+	test $(git rev-parse stash^^{tree}) = $(git rev-parse HEAD^{tree}) &&
 	git diff stash^2..stash > output &&
 	test_cmp output expect
 '
-- 
1.5.6

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

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Jeff King wrote:

> On Wed, Jul 02, 2008 at 01:08:09AM -0700, Junio C Hamano wrote:
> 
> > > So if the problem is "old perl", I don't think it is an issue. Are 
> > > there modern perl installations in the wild that don't have 
> > > File::Temp?
> > 
> > The thing is, I think I heard quite similar explanation why Test::More 
> > is safe to use when the patch to add t/t9700 was submit.  Then what 
> > happened?
> 
> ISTR the Test::More problem was reported by Linus, who is a Fedora user? 
> I tried searching for any reasonable information on which of the core 
> perl modules are installed by default on Fedora systems, but didn't come 
> up with anything useful.
> 
> I really have no clue as to what is out there, and I suspect we must 
> either play it totally safe, or push the limits and wait for people to 
> complain about breakage.

I wonder why bother trying to import things when you do not need them to 
begin with!  I mean, it is _obvious_ that in this case, we want .git/ to 
be writable _anyway_, so why not stick with a fixed name in that?

Ciao,
Dscho

Re: [PATCH] Disconnect stash from its base commit

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Nanako Shiraishi wrote:

> A stash records the state of the files in the working tree as a merge 
> between the HEAD and another commit that records the state of the index, 
> that in turn is a child commit of the HEAD commit.  In order to later 
> apply (or pop) the stash, however, only the tree objects of these three 
> commits are necessary.
> 
> This patch changes the structure of a stash to use a parentless new 
> commit that has the same tree as the HEAD commit, in place of the HEAD 
> commit. This way, a stash does not keep the history that leads to the 
> HEAD commit reachable, even if the stash is kept forever.

May I register my suspicion that this is the wrong direction to go?

I actually find it quite nice that I can easily see in gitk where I 
spawned off a certain stash, indeed, how the recent stash history 
(manually specified with "stash@{0} stash@{1} stash@{2}" [*1*]), relates 
to the current branch's history.

Ciao,
Dscho

P.S.: I vaguely remember that I once wrote a patch to turn "stash@{0..2}" 
into exactly the same, but I do not remember why I did not follow up on 
it.  Was it refuted, or unwanted?

Re: [PATCH 02/12] Do not complain about "no common commits" in an empty repo

[Steffen Prohaska]

On Jul 2, 2008, at 10:58 AM, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>>
>> If the repo is empty, we know that already, thank you very much.
>> So shut fetch-pack up about that case.
>
> Two complaints.

You are right, although I didn't intend to "hide" the patch.  I just
went through the differences between the mainline and 4msysgit and
collected a patch series with all changes I found.  I sent this series
to the list, so that the remaining differences do not get lost
unrecognized.

I didn't mean to bother you with incomplete patches.  Maybe I should
have made my intention clearer by prefixing the subject lines with
WIP (or something similar).  Apologies.


> * What does this have to do with Windows port?  Please don't hide a
>   general interface change in a larger and mostly unrelated topic.

I remember that users of msysgit's net installer complaint about this
warning.  The warning appeared as part of the output of a sequence of
automatically executed commands.  Without context, the users did not
understand what the warning means.


> * Do you think people can tell without reading the code in larger  
> context
>   outside the patch and this commit log text if you are talking  
> about the
>   case you fetch _into_ an empty repository, or if you are  
> attempting to
>   fetch _from_ an empty repository, or what?  Please try to be a bit
>   easier for _readers_.  Being more redundant and verbose is better  
> than
>   being too concise.
>
> About the first point, "no common commits" is just a friendly  
> reminder and
> not even an error.  When you see it, you will learn to expect  
> looooooooong
> download session.
>
> I personally happen to agree with the logic of this patch, though  
> --- if
> you are fetching into an empty repository, you would already expect  
> that
> the download is as big as the other end anyway, so you would not  
> need to
> be further reminded about that.
>
> But that is just one-man's opinion.  Maybe somebody knows a reason  
> why I
> am (and the logic I am agreeing with is) wrong.  Maybe not.  So make  
> the
> "remainder of Windows port" series 11 commits, and send this as a  
> general
> interface fix via the normal channel to be discussed, please.


Dscho, will you send it?  You are the original author.
	
	Steffen

Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.

[Steffen Prohaska]

On Jul 2, 2008, at 11:20 AM, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> diff --git a/fast-import.c b/fast-import.c
>> index e72b286..271b93c 100644
>> --- a/fast-import.c
>> +++ b/fast-import.c
>> @@ -391,7 +391,9 @@ static void write_crash_report(const char *err)
>>
>> 	fprintf(rpt, "fast-import crash report:\n");
>> 	fprintf(rpt, "    fast-import process: %d\n", getpid());
>> +#ifndef __MINGW32__
>> 	fprintf(rpt, "    parent process     : %d\n", getppid());
>> +#endif
>> 	fprintf(rpt, "    at %s\n", show_date(time(NULL), 0, DATE_LOCAL));
>> 	fputc('\n', rpt);
>>
>> --  
>> 1.5.6.1.255.g32571
>
> It does not matter too much for this part that writes crash report,  
> but
> keeping the file format the same across platforms will make it  
> easier for
> tools to read output, so as a general principle, I think this is a
> suboptimal solution to the issue.  How about throwing something like  
> this
> in MinGW specific header files?
>
>        #define getppid() 0

Hannes added something similar to the compat layer, so this commit
is no longer needed.  I'll remove it from the series and revert it
in 4msysgit.

	Steffen

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

[Steffen Prohaska]

On Jul 2, 2008, at 11:21 AM, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>
> No commit log message?  Justification?

Hannes,
Do we still need this change in verify_path().  I am not sure.
Maybe it should be reverted in 4msysgit?

	Steffen

Re: [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.

[Steffen Prohaska]

On Jul 2, 2008, at 12:03 PM, Marius Storm-Olsen wrote:

> Junio C Hamano said the following on 02.07.2008 11:22:
>> Steffen Prohaska <prohaska@zib.de> writes:
>>> From: Marius Storm-Olsen <mstormo_git@storm-olsen.com>
>>>
>>> SIGPIPE isn't supported in MinGW.
>> Shouldn't #ifdef be on SIGPIPE not on __MINGW32__?
>
> That's certainly a good suggestion. :-)

I reverted this in 4msysgit and will remove the patch from the
series.

	Steffen

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
> 
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> 
> No commit log message?  Justification?

Justification: adding absolute paths was not caught properly on Windows, 
and this was the easiest patch.

However, IIRC, in the meantime we are nice to the user, and allow absolute 
paths (which we turn into a relative path, or error out if it is not under 
the current working directory).

Steffen, can you revert the patch and verify that my memory does not fail 
me?

Ciao,
Dscho

Re: [msysGit] [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Steffen Prohaska wrote:

> 
> From: Johannes Sixt <johannes.sixt@telecom.at>
> 
> Hannes,
> You introduced "minoffset" in 861429a7c37c7.

AFAICT it was redone differently in 'next', because 'next' has this 
ceiling dir thingie, which allows a different (much smaller) patch.

It might be more sensible to base your patch series on 'next'...

Ciao,
Dscho

Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
> 
> > diff --git a/fast-import.c b/fast-import.c
> > index e72b286..271b93c 100644
> > --- a/fast-import.c
> > +++ b/fast-import.c
> > @@ -391,7 +391,9 @@ static void write_crash_report(const char *err)
> >  
> >  	fprintf(rpt, "fast-import crash report:\n");
> >  	fprintf(rpt, "    fast-import process: %d\n", getpid());
> > +#ifndef __MINGW32__
> >  	fprintf(rpt, "    parent process     : %d\n", getppid());
> > +#endif
> >  	fprintf(rpt, "    at %s\n", show_date(time(NULL), 0, DATE_LOCAL));
> >  	fputc('\n', rpt);
> >  
> > -- 
> > 1.5.6.1.255.g32571
> 
> It does not matter too much for this part that writes crash report, but
> keeping the file format the same across platforms will make it easier for
> tools to read output, so as a general principle, I think this is a
> suboptimal solution to the issue.  How about throwing something like this
> in MinGW specific header files?
> 
>         #define getppid() 0

Of course, we could also implement it, using NtQueryInformationProcess() 
as suggested by Google.

Ciao,
Dscho

		

Re: [PATCH 02/12] Do not complain about "no common commits" in an empty repo

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Steffen Prohaska wrote:

> Dscho, will you send it?  You are the original author.

Done,
Dscho

Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

[Steffen Prohaska]

On Jul 2, 2008, at 6:17 PM, Johannes Schindelin wrote:

> On Wed, 2 Jul 2008, Steffen Prohaska wrote:
>
>>
>> From: Johannes Sixt <johannes.sixt@telecom.at>
>>
>> Hannes,
>> You introduced "minoffset" in 861429a7c37c7.
>
> AFAICT it was redone differently in 'next', because 'next' has this
> ceiling dir thingie, which allows a different (much smaller) patch.
>
> It might be more sensible to base your patch series on 'next'...

Hmm.. it is based on next.  But obviously I needed to merge
mingw's master to 4msysgit's master and resolve conflicts.
Maybe I made the wrong decisions then.

Hannes,
If you believe that your setup.c is good, then I'll copy your version
to 4msysgit's master.

	Steffen

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

[Steffen Prohaska]

On Jul 2, 2008, at 6:15 PM, Johannes Schindelin wrote:

> Hi,
>
> On Wed, 2 Jul 2008, Junio C Hamano wrote:
>
>> Steffen Prohaska <prohaska@zib.de> writes:
>>
>>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>>
>> No commit log message?  Justification?
>
> Justification: adding absolute paths was not caught properly on  
> Windows,
> and this was the easiest patch.
>
> However, IIRC, in the meantime we are nice to the user, and allow  
> absolute
> paths (which we turn into a relative path, or error out if it is not  
> under
> the current working directory).
>
> Steffen, can you revert the patch and verify that my memory does not  
> fail
> me?

Is

    git add /c/msysgit/git/read-cache.c

an appropriate test?

It fails with

    error: 'c:/msysgit/git/read-cache.c' is outside repository

no matter if the commit is reverted or not.

	Steffen

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Steffen Prohaska wrote:

> On Jul 2, 2008, at 6:15 PM, Johannes Schindelin wrote:
> 
> >On Wed, 2 Jul 2008, Junio C Hamano wrote:
> >
> > >Steffen Prohaska <prohaska@zib.de> writes:
> > >
> > > >Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 
> > > >Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> > >
> > >No commit log message?  Justification?
> >
> >Justification: adding absolute paths was not caught properly on 
> >Windows, and this was the easiest patch.
> >
> >However, IIRC, in the meantime we are nice to the user, and allow 
> >absolute paths (which we turn into a relative path, or error out if it 
> >is not under the current working directory).
> >
> >Steffen, can you revert the patch and verify that my memory does not 
> >fail me?
> 
> Is
> 
>   git add /c/msysgit/git/read-cache.c
> 
> an appropriate test?
> 
> It fails with
> 
>   error: 'c:/msysgit/git/read-cache.c' is outside repository
> 
> no matter if the commit is reverted or not.

Yes, that is enough.  It proves that the patch 11/12 is unnecessary and 
should be removed from 4msysgit.git.

Thanks,
Dscho

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Junio C Hamano]

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

> I wonder why bother trying to import things when you do not need them to 
> begin with!  I mean, it is _obvious_ that in this case, we want .git/ to 
> be writable _anyway_, so why not stick with a fixed name in that?

Good suggestion -- I love that simplicity.  Thomas?

Re: [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL.

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> From: Johannes Sixt <johannes.sixt@telecom.at>
>
> git-am when invoked from git-rebase seems to rely on successful conversion.

> diff --git a/utf8.h b/utf8.h
> index 98cce1b..f22ef31 100644
> --- a/utf8.h
> +++ b/utf8.h
> @@ -10,10 +10,6 @@ int is_encoding_utf8(const char *name);
>
>  int print_wrapped_text(const char *text, int indent, int indent2, int
> len);
>
> -#ifndef NO_ICONV
>  char *reencode_string(const char *in, const char *out_encoding, const char
> *in_encoding); -#else
> -#define reencode_string(a,b,c) NULL
> -#endif
>
>  #endif

I don't think that this is still needed. It dates back to the origins of 
mingw.git, at which time I did not have a working libiconv.

-- Hannes

Re: [msysGit] [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> On Windows, gpg outputs CR/LF signatures.  But since the tag
> messages are already stripped of the CR by stripspace(), it is
> arguably nicer to do the same for the tag signature.  Actually,
> this patch does not look for CR/LF, but strips all CRs
> from the signature.
>
> [ spr: ported code to use strbuf ]
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
>  builtin-tag.c |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-tag.c b/builtin-tag.c
> index e675206..77977ba 100644
> --- a/builtin-tag.c
> +++ b/builtin-tag.c
> @@ -241,6 +241,20 @@ static int do_sign(struct strbuf *buffer)
>  	if (finish_command(&gpg) || !len || len < 0)
>  		return error("gpg failed to sign the tag");
>
> +#ifdef __MINGW32__
> +	/* strip CR from the line endings */
> +	{
> +		int i, j;
> +		for (i = j = 0; i < buffer->len; i++)
> +			if (buffer->buf[i] != '\r') {
> +				if (i != j)
> +					buffer->buf[j] = buffer->buf[i];
> +				j++;
> +			}
> +		strbuf_setlen(buffer, j);
> +	}
> +#endif
> +
>  	return 0;
>  }

Do we need the #ifdef __MINGW32__? Can't we just strip CRs unconditionally? It 
shouldn't hurt on Unix anyway.

-- Hannes

Re: [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> The implementation directly calls the Win32 API to launch the browser.
> Note that the specific directory layout of msysgit is required.

> +#ifdef __MINGW32__
> +	const char* exec_path = git_exec_path();
> +	char *htmlpath = make_native_separator(
> +			   mkpath("%s/../doc/git/html/%s.html"
> +				  , exec_path
> +				  , git_cmd)
> +			 );
> +	if (!file_exists(htmlpath)) {
> +		htmlpath = make_native_separator(
> +			      mkpath("%s/../doc/git/html/git-%s.html"
> +				     , exec_path
> +				     , git_cmd)
> +			   );
> +		if (!file_exists(htmlpath)) {
> +			fprintf(stderr, "Can't find HTML help for '%s'.\n"
> +				, git_cmd);
> +			exit(1);
> +		}
> +	}
> +	printf("Launching default browser to display HTML help ...\n");
> +	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
> +#else

Can't we move this part into git-web--browse.sh? It should be a matter of 
calling

	start $htmlpath

(and msys-1.0.dll would convert slashes to backslashes for us).

-- Hannes

Re: [PATCH] Disconnect stash from its base commit

[Junio C Hamano]

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

>> This patch changes the structure of a stash to use a parentless new 
>> commit that has the same tree as the HEAD commit, in place of the HEAD 
>> commit. This way, a stash does not keep the history that leads to the 
>> HEAD commit reachable, even if the stash is kept forever.
>
> May I register my suspicion that this is the wrong direction to go?
>
> I actually find it quite nice that I can easily see in gitk where I 
> spawned off a certain stash, indeed, how the recent stash history 
> (manually specified with "stash@{0} stash@{1} stash@{2}" [*1*]), relates 
> to the current branch's history.

A stash may primarily be for applying the change to random place, but
where it was created is not a useless information.  The very original use
case that was in the discussion "git stash" (actually its original form
"git save") was first posted was "I am in the middle of something, and get
interrupted.  Stash the changes away to switch branches to deal with the
emergency for a while so that I can later come back to where I was, and I
want both saving away and coming back easy operations".  A stash _can_ be
applied to any random other state, but "coming back" is very much part of
what it should have supported, and not recording the base commit means we
would lose that capability.

	Side note.  In addition to the current "stash apply" and "stash
	pop", "stash branch $stash newbranchname" that does

        	git checkout -b newbranchanme $stash^

	(i.e. create a new branch starting from the state you were in)
	might be a good ingredient to support a more git-like workflow to
	resume.  If your original branch gained extra commits, was
	rewound, or was rebased during the emergency/distraction, you may
	not have anywhere to apply/pop the stash without conflicts when
	you want to "come back" with normal

        	git checkout somebranch && git stash pop

	But that imaginary "stash branch" command would always give you
	the exact state you were in and creates a clean fork to finish
	what you were doing, and continue.

So the base commit is an integral part of what a stash is, and I agree
with you that an unexpiring stash that pins the whole history beind it is
a feature.  It is not unncessary cruft that accumulates that we need to
worry about.

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> From: Edward Z. Yang <edwardzyang@thewritingpot.com>
>
> PuTTY requires -P while OpenSSH requires -p; if plink is detected
> as GIT_SSH, use the alternate flag.
>
> Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
>  connect.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/connect.c b/connect.c
> index 574f42f..0d007f3 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2], const
> char *url_orig, conn->argv = arg = xcalloc(6, sizeof(*arg));
>  	if (protocol == PROTO_SSH) {
>  		const char *ssh = getenv("GIT_SSH");
> +		int putty = ssh && strstr(ssh, "plink");
>  		if (!ssh) ssh = "ssh";
>
>  		*arg++ = ssh;
>  		if (port) {
> -			*arg++ = "-p";
> +			/* P is for PuTTY, p is for OpenSSH */
> +			*arg++ = putty ? "-P" : "-p";
>  			*arg++ = port;
>  		}
>  		*arg++ = host;

What about installing a wrapper script, plinkssh, that does this:

#!/bin/bash

if test "$1" = -p; then
	port="-P $2"
	shift; shift
fi

exec plink $port "$@"

and require plink users to set GIT_SSH=plinkssh?

-- Hannes

Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> This adds only the minimum necessary to keep git pull/merge's diffstat from
> wrapping. Notably absent is support for the K (erase) operation, and
> support for POSIX write.

If I understand the patch correctly, it won't affect output that goes to the 
pager; only text that goes directly to the console would be colored. This is 
a start. I think I'll queue this in mingw.git.

-- Hannes

Re: [msysGit] Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> On Jul 2, 2008, at 6:17 PM, Johannes Schindelin wrote:
> > On Wed, 2 Jul 2008, Steffen Prohaska wrote:
> >> From: Johannes Sixt <johannes.sixt@telecom.at>
> >>
> >> Hannes,
> >> You introduced "minoffset" in 861429a7c37c7.
> >
> > AFAICT it was redone differently in 'next', because 'next' has this
> > ceiling dir thingie, which allows a different (much smaller) patch.
> >
> > It might be more sensible to base your patch series on 'next'...
>
> Hmm.. it is based on next.  But obviously I needed to merge
> mingw's master to 4msysgit's master and resolve conflicts.
> Maybe I made the wrong decisions then.
>
> Hannes,
> If you believe that your setup.c is good, then I'll copy your version
> to 4msysgit's master.

The setup.c in mingw.git (and soon Junio's master) and Junio's next are 
_different_, but both are correct. If you reverse-apply the patch you 
presented here, then you get the version from Junio's next, which is a good 
state.

[ Of course, the result will work only as long as you do not set 
GIT_CEILING_DIRECTORIES, because we haven't taken care of the helper 
functions that this feature uses, longest_ancestor_length() and 
normalize_path(). ]

We have debated about set_git_dir(".") in the past. mingw.git doesn't have it, 
and it works (for me). I don't know what it is needed for.

-- Hannes

Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console

[Peter Harris]

On Wed, Jul 2, 2008 at 3:17 PM, Johannes Sixt wrote:
> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
>> This adds only the minimum necessary to keep git pull/merge's diffstat from
>> wrapping. Notably absent is support for the K (erase) operation, and
>> support for POSIX write.
>
> If I understand the patch correctly, it won't affect output that goes to the
> pager; only text that goes directly to the console would be colored.

Yes, that is correct.

Note that an MSYS bash/rxvt is effectively considered a pager by this
patch, since it fails the isatty() test. This is actually a good
thing: MSYS has better ANSI support anyway.

Peter Harris

Re: [PATCH] Disconnect stash from its base commit

[Abhijit Menon-Sen]

At 2008-07-02 12:01:35 -0700, gitster@pobox.com wrote:
>
> 	But that imaginary "stash branch" command would always give you
> 	the exact state you were in and creates a clean fork to finish
> 	what you were doing, and continue.

Nice idea. Something as simple as the appended diff?

I reversed the stash/branch arguments so that one need specify only the
branch name. Playing with it a little, it feels very useful.

-- ams

diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..d5ecd24 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -218,6 +218,21 @@ drop_stash () {
 	git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
 }
 
+apply_to_branch () {
+	have_stash || die 'Nothing to apply'
+
+	test -n "$1" || die 'No branch name specified'
+	branch=$1
+
+	if test -z "$2"
+	then
+		set x "$ref_stash@{0}"
+	fi
+	stash=$2
+
+	git-checkout -b $branch $stash^ && apply_stash $stash
+}
+
 # Main command set
 case "$1" in
 list)
@@ -264,6 +279,10 @@ pop)
 		drop_stash "$@"
 	fi
 	;;
+branch)
+	shift
+	apply_to_branch "$@"
+	;;
 *)
 	if test $# -eq 0
 	then

Re: [PATCH] Disconnect stash from its base commit

[Junio C Hamano]

Abhijit Menon-Sen <ams@toroid.org> writes:

> At 2008-07-02 12:01:35 -0700, gitster@pobox.com wrote:
>>
>> 	But that imaginary "stash branch" command would always give you
>> 	the exact state you were in and creates a clean fork to finish
>> 	what you were doing, and continue.
>
> Nice idea. Something as simple as the appended diff?
>
> I reversed the stash/branch arguments so that one need specify only the
> branch name. Playing with it a little, it feels very useful.

I'd further suggest to delete the stash automatically when you create a
new branch out of it.

[PATCH 0/3] git-add--interactive: use --recount, editing

[Thomas Rast]

Junio C Hamano wrote:
> 
> I recall that the original "add--interactive" carefully counted numbers in
> hunks it reassembles (as it can let you split and then you can choose to
> use both parts, which requires it to merge overlapping hunks back), but if
> you are going to use --recount anyway, perhaps we can discard that logic?
> It may make the patch application less robust, though.  I dunno.

This series takes it a bit further.  I played around with 'apply', and
it seems there is no reason to even merge the hunks.  (It would be
great if someone who knows builtin-apply.c could confirm this.)  So we
can get rid of all recounting except for the correct splitting
boundaries.  These are the first two patches.

Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > I wonder why bother trying to import things when you do not need them to 
> > begin with!  I mean, it is _obvious_ that in this case, we want .git/ to 
> > be writable _anyway_, so why not stick with a fixed name in that?
> 
> Good suggestion -- I love that simplicity.  Thomas?

Well, changed that back.

Apart from that, no real changes to 3/3, but the $needs_recount code
has become unnecessary because 1/3 already forces --recount.

- Thomas



 Documentation/git-add.txt  |    1 +
 git-add--interactive.perl  |  203 ++++++++++++++++++++++---------------------
 t/t3701-add-interactive.sh |   67 +++++++++++++++
 3 files changed, 172 insertions(+), 99 deletions(-)

[PATCH 1/3] git-add--interactive: replace hunk recounting with apply --recount

[Thomas Rast]

We recounted the postimage offsets to compensate for hunks that were
not selected.  Now apply --recount can do the job for us.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 git-add--interactive.perl |   30 +++---------------------------
 1 files changed, 3 insertions(+), 27 deletions(-)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 903953e..e1964a5 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -970,39 +970,15 @@ sub patch_update_file {
 		push @result, @{$mode->{TEXT}};
 	}
 	for (@hunk) {
-		my $text = $_->{TEXT};
-		my ($o_ofs, $o_cnt, $n_ofs, $n_cnt) =
-		    parse_hunk_header($text->[0]);
-
-		if (!$_->{USE}) {
-			# We would have added ($n_cnt - $o_cnt) lines
-			# to the postimage if we were to use this hunk,
-			# but we didn't.  So the line number that the next
-			# hunk starts at would be shifted by that much.
-			$n_lofs -= ($n_cnt - $o_cnt);
-			next;
-		}
-		else {
-			if ($n_lofs) {
-				$n_ofs += $n_lofs;
-				$text->[0] = ("@@ -$o_ofs" .
-					      (($o_cnt != 1)
-					       ? ",$o_cnt" : '') .
-					      " +$n_ofs" .
-					      (($n_cnt != 1)
-					       ? ",$n_cnt" : '') .
-					      " @@\n");
-			}
-			for (@$text) {
-				push @result, $_;
-			}
+		if ($_->{USE}) {
+			push @result, @{$_->{TEXT}};
 		}
 	}
 
 	if (@result) {
 		my $fh;
 
-		open $fh, '| git apply --cached';
+		open $fh, '| git apply --cached --recount';
 		for (@{$head->{TEXT}}, @result) {
 			print $fh $_;
 		}
-- 
1.5.6.1.276.gde9a

[PATCH 2/3] git-add--interactive: remove hunk coalescing

[Thomas Rast]

Current git-apply has no trouble at all applying chunks that have
overlapping context, as produced by the splitting feature. So we can
drop the manual coalescing.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 git-add--interactive.perl |   89 ---------------------------------------------
 1 files changed, 0 insertions(+), 89 deletions(-)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index e1964a5..a4234d3 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -682,93 +682,6 @@ sub split_hunk {
 	return @split;
 }
 
-sub find_last_o_ctx {
-	my ($it) = @_;
-	my $text = $it->{TEXT};
-	my ($o_ofs, $o_cnt) = parse_hunk_header($text->[0]);
-	my $i = @{$text};
-	my $last_o_ctx = $o_ofs + $o_cnt;
-	while (0 < --$i) {
-		my $line = $text->[$i];
-		if ($line =~ /^ /) {
-			$last_o_ctx--;
-			next;
-		}
-		last;
-	}
-	return $last_o_ctx;
-}
-
-sub merge_hunk {
-	my ($prev, $this) = @_;
-	my ($o0_ofs, $o0_cnt, $n0_ofs, $n0_cnt) =
-	    parse_hunk_header($prev->{TEXT}[0]);
-	my ($o1_ofs, $o1_cnt, $n1_ofs, $n1_cnt) =
-	    parse_hunk_header($this->{TEXT}[0]);
-
-	my (@line, $i, $ofs, $o_cnt, $n_cnt);
-	$ofs = $o0_ofs;
-	$o_cnt = $n_cnt = 0;
-	for ($i = 1; $i < @{$prev->{TEXT}}; $i++) {
-		my $line = $prev->{TEXT}[$i];
-		if ($line =~ /^\+/) {
-			$n_cnt++;
-			push @line, $line;
-			next;
-		}
-
-		last if ($o1_ofs <= $ofs);
-
-		$o_cnt++;
-		$ofs++;
-		if ($line =~ /^ /) {
-			$n_cnt++;
-		}
-		push @line, $line;
-	}
-
-	for ($i = 1; $i < @{$this->{TEXT}}; $i++) {
-		my $line = $this->{TEXT}[$i];
-		if ($line =~ /^\+/) {
-			$n_cnt++;
-			push @line, $line;
-			next;
-		}
-		$ofs++;
-		$o_cnt++;
-		if ($line =~ /^ /) {
-			$n_cnt++;
-		}
-		push @line, $line;
-	}
-	my $head = ("@@ -$o0_ofs" .
-		    (($o_cnt != 1) ? ",$o_cnt" : '') .
-		    " +$n0_ofs" .
-		    (($n_cnt != 1) ? ",$n_cnt" : '') .
-		    " @@\n");
-	@{$prev->{TEXT}} = ($head, @line);
-}
-
-sub coalesce_overlapping_hunks {
-	my (@in) = @_;
-	my @out = ();
-
-	my ($last_o_ctx);
-
-	for (grep { $_->{USE} } @in) {
-		my $text = $_->{TEXT};
-		my ($o_ofs) = parse_hunk_header($text->[0]);
-		if (defined $last_o_ctx &&
-		    $o_ofs <= $last_o_ctx) {
-			merge_hunk($out[-1], $_);
-		}
-		else {
-			push @out, $_;
-		}
-		$last_o_ctx = find_last_o_ctx($out[-1]);
-	}
-	return @out;
-}
 
 sub help_patch_cmd {
 	print colored $help_color, <<\EOF ;
@@ -962,8 +875,6 @@ sub patch_update_file {
 		}
 	}
 
-	@hunk = coalesce_overlapping_hunks(@hunk);
-
 	my $n_lofs = 0;
 	my @result = ();
 	if ($mode->{USE}) {
-- 
1.5.6.1.276.gde9a

[PATCH 3/3] git-add--interactive: manual hunk editing mode

[Thomas Rast]

Adds a new option 'e' to the 'add -p' command loop that lets you edit
the current hunk in your favourite editor.

If the resulting patch applies cleanly, the edited hunk will
immediately be marked for staging. If it does not apply cleanly, you
will be given an opportunity to edit again. If all lines of the hunk
are removed, then the edit is aborted and the hunk is left unchanged.

Applying the changed hunk(s) relies on Johannes Schindelin's new
--recount option for git-apply.

Note that the "real patch" test intentionally uses
  (echo e; echo n; echo d) | git add -p
even though the 'n' and 'd' are superfluous at first sight.  They
serve to get out of the interaction loop if git add -p wrongly
concludes the patch does not apply.

Many thanks to Jeff King <peff@peff.net> for lots of help and
suggestions.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 Documentation/git-add.txt  |    1 +
 git-add--interactive.perl  |  119 ++++++++++++++++++++++++++++++++++++++++++++
 t/t3701-add-interactive.sh |   67 +++++++++++++++++++++++++
 3 files changed, 187 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 011a743..46dd56c 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -236,6 +236,7 @@ patch::
        k - leave this hunk undecided, see previous undecided hunk
        K - leave this hunk undecided, see previous hunk
        s - split the current hunk into smaller hunks
+       e - manually edit the current hunk
        ? - print help
 +
 After deciding the fate for all hunks, if there is any hunk
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index a4234d3..801d7c0 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -18,6 +18,18 @@ my ($fraginfo_color) =
 	$diff_use_color ? (
 		$repo->get_color('color.diff.frag', 'cyan'),
 	) : ();
+my ($diff_plain_color) =
+	$diff_use_color ? (
+		$repo->get_color('color.diff.plain', ''),
+	) : ();
+my ($diff_old_color) =
+	$diff_use_color ? (
+		$repo->get_color('color.diff.old', 'red'),
+	) : ();
+my ($diff_new_color) =
+	$diff_use_color ? (
+		$repo->get_color('color.diff.new', 'green'),
+	) : ();
 
 my $normal_color = $repo->get_color("", "reset");
 
@@ -683,6 +695,105 @@ sub split_hunk {
 }
 
 
+sub color_diff {
+	return map {
+		colored((/^@/  ? $fraginfo_color :
+			 /^\+/ ? $diff_new_color :
+			 /^-/  ? $diff_old_color :
+			 $diff_plain_color),
+			$_);
+	} @_;
+}
+
+sub edit_hunk_manually {
+	my ($oldtext) = @_;
+
+	my $hunkfile = $repo->repo_path . "/addp-hunk-edit.diff";
+	my $fh;
+	open $fh, '>', $hunkfile
+		or die "failed to open hunk edit file for writing: " . $!;
+	print $fh "# Manual hunk edit mode -- see bottom for a quick guide\n";
+	print $fh @$oldtext;
+	print $fh <<EOF;
+# ---
+# To remove '-' lines, make them ' ' lines (context).
+# To remove '+' lines, delete them.
+# Lines starting with # will be removed.
+#
+# If the patch applies cleanly, the edited hunk will immediately be
+# marked for staging. If it does not apply cleanly, you will be given
+# an opportunity to edit again. If all lines of the hunk are removed,
+# then the edit is aborted and the hunk is left unchanged.
+EOF
+	close $fh;
+
+	my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor")
+		|| $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+	system('sh', '-c', $editor.' "$@"', $editor, $hunkfile);
+
+	open $fh, '<', $hunkfile
+		or die "failed to open hunk edit file for reading: " . $!;
+	my @newtext = grep { !/^#/ } <$fh>;
+	close $fh;
+	unlink $hunkfile;
+
+	# Abort if nothing remains
+	if (!grep { /\S/ } @newtext) {
+		return undef;
+	}
+
+	# Reinsert the first hunk header if the user accidentally deleted it
+	if ($newtext[0] !~ /^@/) {
+		unshift @newtext, $oldtext->[0];
+	}
+	return \@newtext;
+}
+
+sub diff_applies {
+	my $fh;
+	open $fh, '| git apply --recount --cached --check';
+	for my $h (@_) {
+		print $fh @{$h->{TEXT}};
+	}
+	return close $fh;
+}
+
+sub prompt_yesno {
+	my ($prompt) = @_;
+	while (1) {
+		print colored $prompt_color, $prompt;
+		my $line = <STDIN>;
+		return 0 if $line =~ /^n/i;
+		return 1 if $line =~ /^y/i;
+	}
+}
+
+sub edit_hunk_loop {
+	my ($head, $hunk, $ix) = @_;
+	my $text = $hunk->[$ix]->{TEXT};
+
+	while (1) {
+		$text = edit_hunk_manually($text);
+		if (!defined $text) {
+			return undef;
+		}
+		my $newhunk = { TEXT => $text, USE => 1 };
+		if (diff_applies($head,
+				 @{$hunk}[0..$ix-1],
+				 $newhunk,
+				 @{$hunk}[$ix+1..$#{$hunk}])) {
+			$newhunk->{DISPLAY} = [color_diff(@{$text})];
+			return $newhunk;
+		}
+		else {
+			prompt_yesno(
+				'Your edited hunk does not apply. Edit again '
+				. '(saying "no" discards!) [y/n]? '
+				) or return undef;
+		}
+	}
+}
+
 sub help_patch_cmd {
 	print colored $help_color, <<\EOF ;
 y - stage this hunk
@@ -694,6 +805,7 @@ J - leave this hunk undecided, see next hunk
 k - leave this hunk undecided, see previous undecided hunk
 K - leave this hunk undecided, see previous hunk
 s - split the current hunk into smaller hunks
+e - manually edit the current hunk
 ? - print help
 EOF
 }
@@ -798,6 +910,7 @@ sub patch_update_file {
 		if (hunk_splittable($hunk[$ix]{TEXT})) {
 			$other .= '/s';
 		}
+		$other .= '/e';
 		for (@{$hunk[$ix]{DISPLAY}}) {
 			print;
 		}
@@ -862,6 +975,12 @@ sub patch_update_file {
 				$num = scalar @hunk;
 				next;
 			}
+			elsif ($line =~ /^e/) {
+				my $newhunk = edit_hunk_loop($head, \@hunk, $ix);
+				if (defined $newhunk) {
+					splice @hunk, $ix, 1, $newhunk;
+				}
+			}
 			else {
 				help_patch_cmd($other);
 				next;
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index fae64ea..e95663d 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -66,6 +66,73 @@ test_expect_success 'revert works (commit)' '
 	grep "unchanged *+3/-0 file" output
 '
 
+cat >expected <<EOF
+EOF
+cat >fake_editor.sh <<EOF
+EOF
+chmod a+x fake_editor.sh
+test_set_editor "$(pwd)/fake_editor.sh"
+test_expect_success 'dummy edit works' '
+	(echo e; echo a) | git add -p &&
+	git diff > diff &&
+	test_cmp expected diff
+'
+
+cat >patch <<EOF
+@@ -1,1 +1,4 @@
+ this
++patch
+-doesn't
+ apply
+EOF
+echo "#!$SHELL_PATH" >fake_editor.sh
+cat >>fake_editor.sh <<\EOF
+mv -f "$1" oldpatch &&
+mv -f patch "$1"
+EOF
+chmod a+x fake_editor.sh
+test_set_editor "$(pwd)/fake_editor.sh"
+test_expect_success 'bad edit rejected' '
+	git reset &&
+	(echo e; echo n; echo d) | git add -p >output &&
+	grep "hunk does not apply" output
+'
+
+cat >patch <<EOF
+this patch
+is garbage
+EOF
+test_expect_success 'garbage edit rejected' '
+	git reset &&
+	(echo e; echo n; echo d) | git add -p >output &&
+	grep "hunk does not apply" output
+'
+
+cat >patch <<EOF
+@@ -1,0 +1,0 @@
+ baseline
++content
++newcontent
++lines
+EOF
+cat >expected <<EOF
+diff --git a/file b/file
+index b5dd6c9..f910ae9 100644
+--- a/file
++++ b/file
+@@ -1,4 +1,4 @@
+ baseline
+ content
+-newcontent
++more
+ lines
+EOF
+test_expect_success 'real edit works' '
+	(echo e; echo n; echo d) | git add -p &&
+	git diff >output &&
+	test_cmp expected output
+'
+
 if test "$(git config --bool core.filemode)" = false
 then
     say 'skipping filemode tests (filesystem does not properly support modes)'
-- 
1.5.6.1.276.gde9a

Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> Current git-apply has no trouble at all applying chunks that have
> overlapping context, as produced by the splitting feature. So we can
> drop the manual coalescing.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>  git-add--interactive.perl |   89 ---------------------------------------------
>  1 files changed, 0 insertions(+), 89 deletions(-)
>
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index e1964a5..a4234d3 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -682,93 +682,6 @@ sub split_hunk {
>  	return @split;
>  }
>  
> -sub find_last_o_ctx {
> ...
> -}
> -
> -sub merge_hunk {
> ...
> -}
> -
> -sub coalesce_overlapping_hunks {
> ...
> -}
>  
>  sub help_patch_cmd {
>  	print colored $help_color, <<\EOF ;
> @@ -962,8 +875,6 @@ sub patch_update_file {
>  		}
>  	}
>  
> -	@hunk = coalesce_overlapping_hunks(@hunk);
> -
>  	my $n_lofs = 0;
>  	my @result = ();
>  	if ($mode->{USE}) {
> -- 
> 1.5.6.1.276.gde9a

I think [1/3] makes sense as we trust --recount anyway (and more
importantly if the user did not muck with the patch --recount would be a
no-op), but I am not sure about this one.  I suspect this change reduces
the precision and safety of the patch application, especially when the
user does not edit hunks.

When you "[s]plit" a hunk like this:

	@@ -n,7 +m,6 @@
         con
         text
        -deleted preimage
        +replaced postimage
	 more
	 line of context
        -deleted another
	 context

into two, we prepare these two hunks internally:

	@@ -n,5 +m,5 @@
         con
         text
        -deleted preimage
        +replaced postimage
	 more
         line of context

	@@ -l,4 +k,3 @@  -- l=n+5, k=m+5
	 more
         line of context
        -deleted another
	 context

So that applying only one piece without applying the other would still
have correct context to locate where to apply.  However, if the user says
"I want to apply both after all", we would need to remove the overlap when
merge them back.  If you don't, you would be feeding a nonsense patch to
"git apply" that goes back in context.

Blindly concatenating the above two and feeding them to "git apply" *may*
happen to work by accident, not by design.  This very much feels like a
hack of "This works most of the time for me, your mileage may vary" kind,
which we would want to avoid when we can.

Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing

[Junio C Hamano]

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

> Blindly concatenating the above two and feeding them to "git apply" *may*
> happen to work by accident, not by design.  This very much feels like a
> hack of "This works most of the time for me, your mileage may vary" kind,
> which we would want to avoid when we can.

Well, I changed my mind.  Let's run with this and see what happens.

The patch application is hunk-by-hunk in nature anyway, and if the user
munges the trailing context of the first half of an originally-single hunk
and the leading context of the latter half in an inconsistent way, we
would notice the problem anyway.

[PATCH] Implement "git stash branch <newbranch> <stash>"

[Abhijit Menon-Sen]

Restores the stashed state on a new branch rooted at the commit on which
the stash was originally created, so that conflicts caused by subsequent
changes on the original branch can be dealt with.

(Thanks to Junio for this nice idea.)
---
 Documentation/git-stash.txt |   19 ++++++++++++++++++-
 git-stash.sh                |   21 +++++++++++++++++++++
 2 files changed, 39 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 23ac331..cfc1c28 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -8,8 +8,11 @@ git-stash - Stash the changes in a dirty working directory away
 SYNOPSIS
 --------
 [verse]
-'git stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
+'git stash' list
+'git stash' (show | apply | drop | pop ) [<stash>]
+'git stash' branch <branchname> [<stash>]
 'git stash' [save [<message>]]
+'git stash' clear
 
 DESCRIPTION
 -----------
@@ -81,6 +84,20 @@ tree's changes, but also the index's ones. However, this can fail, when you
 have conflicts (which are stored in the index, where you therefore can no
 longer apply the changes as they were originally).
 
+branch <branchname> [<stash>]::
+
+	Creates and checks out a new branch named `<branchname>` starting from
+	the commit at which the `<stash>` was originally created, applies the
+	changes recorded in `<stash>` to the new working tree, and drops the
+	`<stash>` if that completes successfully. When no `<stash>` is given,
+	applies the latest one.
++
+This is useful if the branch on which you ran `git stash save` has
+changed enough that `git stash apply` fails due to conflicts. Since
+the stash is applied on top of the commit that was HEAD at the time
+`git stash` was run, it restores the originally stashed state with
+no conflicts.
+
 clear::
 	Remove all the stashed states. Note that those states will then
 	be subject to pruning, and may be difficult or impossible to recover.
diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..8e50b03 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -218,6 +218,23 @@ drop_stash () {
 	git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
 }
 
+apply_to_branch () {
+	have_stash || die 'Nothing to apply'
+
+	test -n "$1" || die 'No branch name specified'
+	branch=$1
+
+	if test -z "$2"
+	then
+		set x "$ref_stash@{0}"
+	fi
+	stash=$2
+
+	git-checkout -b $branch $stash^ &&
+	apply_stash $stash &&
+	drop_stash $stash
+}
+
 # Main command set
 case "$1" in
 list)
@@ -264,6 +281,10 @@ pop)
 		drop_stash "$@"
 	fi
 	;;
+branch)
+	shift
+	apply_to_branch "$@"
+	;;
 *)
 	if test $# -eq 0
 	then
-- 
1.5.6

Re: [PATCH] Implement "git stash branch <newbranch> <stash>"

[Junio C Hamano]

Abhijit Menon-Sen <ams@toroid.org> writes:

> +branch <branchname> [<stash>]::
> +
> +	Creates and checks out a new branch named `<branchname>` starting from
> +	the commit at which the `<stash>` was originally created, applies the
> +	changes recorded in `<stash>` to the new working tree, and drops the
> +	`<stash>` if that completes successfully. When no `<stash>` is given,
> +	applies the latest one.
> ++
> +This is useful if the branch on which you ran `git stash save` has
> +changed enough that `git stash apply` fails due to conflicts. Since
> +the stash is applied on top of the commit that was HEAD at the time
> +`git stash` was run, it restores the originally stashed state with
> +no conflicts.

Perhaps we would want to replay the stash always with --index for this
application.  By definition this will be conflict-free both in the index
and in the working tree.

I've also toyed with an idea to make <branchname> optional, and detach the
HEAD if <branchname> is not given.  It would be a useful mode of operation
but one problem is that it is _not_ an operation that should be called
"branch" anymore.

Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

[Steffen Prohaska]

On Jul 2, 2008, at 9:32 PM, Johannes Sixt wrote:

> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
>> On Jul 2, 2008, at 6:17 PM, Johannes Schindelin wrote:
>>> On Wed, 2 Jul 2008, Steffen Prohaska wrote:
>>>> From: Johannes Sixt <johannes.sixt@telecom.at>
>>>>
>>>> Hannes,
>>>> You introduced "minoffset" in 861429a7c37c7.
>>>
>>> AFAICT it was redone differently in 'next', because 'next' has this
>>> ceiling dir thingie, which allows a different (much smaller) patch.
>>>
>>> It might be more sensible to base your patch series on 'next'...
>>
>> Hmm.. it is based on next.  But obviously I needed to merge
>> mingw's master to 4msysgit's master and resolve conflicts.
>> Maybe I made the wrong decisions then.
>>
>> Hannes,
>> If you believe that your setup.c is good, then I'll copy your version
>> to 4msysgit's master.
>
> The setup.c in mingw.git (and soon Junio's master) and Junio's next  
> are
> _different_, but both are correct. If you reverse-apply the patch you
> presented here, then you get the version from Junio's next, which is  
> a good
> state.

Ok, I'll wait until Junio's master has the changes and will remove
the changes to 4msysgit then.

	Steffen

Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> On Jul 2, 2008, at 9:32 PM, Johannes Sixt wrote:
>
>> The setup.c in mingw.git (and soon Junio's master) and Junio's next
>> are
>> _different_, but both are correct. If you reverse-apply the patch you
>> presented here, then you get the version from Junio's next, which is
>> a good
>> state.
>
> Ok, I'll wait until Junio's master has the changes and will remove
> the changes to 4msysgit then.

There will be a slight difference between the setup.c in soon-to-be master
and j6t/mingw (14086b0), due to recent optimization already on 'master'
from Linus, 044bbbc (Make git_dir a path relative to work_tree in
setup_work_tree(), 2008-06-19).

diff --git a/setup.c b/setup.c
index 8bb7b10..cc3fb38 100644
--- a/setup.c
+++ b/setup.c
@@ -308,9 +308,10 @@ void setup_work_tree(void)
 	work_tree = get_git_work_tree();
 	git_dir = get_git_dir();
 	if (!is_absolute_path(git_dir))
-		set_git_dir(make_absolute_path(git_dir));
+		git_dir = make_absolute_path(git_dir);
 	if (!work_tree || chdir(work_tree))
 		die("This operation must be run in a work tree");
+	set_git_dir(make_relative_path(git_dir, work_tree));
 	initialized = 1;
 }
 

[PATCH] Implement "git stash branch <newbranch> <stash>"

[Abhijit Menon-Sen]

Restores the stashed state on a new branch rooted at the commit on which
the stash was originally created, so that conflicts caused by subsequent
changes on the original branch can be dealt with.

(Thanks to Junio for this nice idea.)

Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
 Documentation/git-stash.txt |   19 ++++++++++++++++++-
 git-stash.sh                |   21 +++++++++++++++++++++
 2 files changed, 39 insertions(+), 1 deletions(-)

(Reposting with --index and the missing Signed-off-by added.)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 23ac331..a4cbd0c 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -8,8 +8,11 @@ git-stash - Stash the changes in a dirty working directory away
 SYNOPSIS
 --------
 [verse]
-'git stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
+'git stash' list
+'git stash' (show | apply | drop | pop ) [<stash>]
+'git stash' branch <branchname> [<stash>]
 'git stash' [save [<message>]]
+'git stash' clear
 
 DESCRIPTION
 -----------
@@ -81,6 +84,20 @@ tree's changes, but also the index's ones. However, this can fail, when you
 have conflicts (which are stored in the index, where you therefore can no
 longer apply the changes as they were originally).
 
+branch <branchname> [<stash>]::
+
+	Creates and checks out a new branch named `<branchname>` starting from
+	the commit at which the `<stash>` was originally created, applies the
+	changes recorded in `<stash>` to the new working tree and index, then
+	drops the `<stash>` if that completes successfully. When no `<stash>`
+	is given, applies the latest one.
++
+This is useful if the branch on which you ran `git stash save` has
+changed enough that `git stash apply` fails due to conflicts. Since
+the stash is applied on top of the commit that was HEAD at the time
+`git stash` was run, it restores the originally stashed state with
+no conflicts.
+
 clear::
 	Remove all the stashed states. Note that those states will then
 	be subject to pruning, and may be difficult or impossible to recover.
diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..889445c 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -218,6 +218,23 @@ drop_stash () {
 	git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
 }
 
+apply_to_branch () {
+	have_stash || die 'Nothing to apply'
+
+	test -n "$1" || die 'No branch name specified'
+	branch=$1
+
+	if test -z "$2"
+	then
+		set x "$ref_stash@{0}"
+	fi
+	stash=$2
+
+	git-checkout -b $branch $stash^ &&
+	apply_stash --index $stash &&
+	drop_stash $stash
+}
+
 # Main command set
 case "$1" in
 list)
@@ -264,6 +281,10 @@ pop)
 		drop_stash "$@"
 	fi
 	;;
+branch)
+	shift
+	apply_to_branch "$@"
+	;;
 *)
 	if test $# -eq 0
 	then
-- 
1.5.6

Re: [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Johannes Sixt wrote:

> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > On Windows, gpg outputs CR/LF signatures.  But since the tag
> > messages are already stripped of the CR by stripspace(), it is
> > arguably nicer to do the same for the tag signature.  Actually,
> > this patch does not look for CR/LF, but strips all CRs
> > from the signature.
> >
> > [ spr: ported code to use strbuf ]
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> > ---
> >  builtin-tag.c |   14 ++++++++++++++
> >  1 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/builtin-tag.c b/builtin-tag.c
> > index e675206..77977ba 100644
> > --- a/builtin-tag.c
> > +++ b/builtin-tag.c
> > @@ -241,6 +241,20 @@ static int do_sign(struct strbuf *buffer)
> >  	if (finish_command(&gpg) || !len || len < 0)
> >  		return error("gpg failed to sign the tag");
> >
> > +#ifdef __MINGW32__
> > +	/* strip CR from the line endings */
> > +	{
> > +		int i, j;
> > +		for (i = j = 0; i < buffer->len; i++)
> > +			if (buffer->buf[i] != '\r') {
> > +				if (i != j)
> > +					buffer->buf[j] = buffer->buf[i];
> > +				j++;
> > +			}
> > +		strbuf_setlen(buffer, j);
> > +	}
> > +#endif
> > +
> >  	return 0;
> >  }
> 
> Do we need the #ifdef __MINGW32__? Can't we just strip CRs unconditionally? It 
> shouldn't hurt on Unix anyway.

I agree, and I would even like to refactor this into its own function.  
Probably even move it to strbuf.[ch].

Ciao,
Dscho

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Johannes Sixt wrote:

> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> > From: Edward Z. Yang <edwardzyang@thewritingpot.com>
> >
> > PuTTY requires -P while OpenSSH requires -p; if plink is detected
> > as GIT_SSH, use the alternate flag.
> >
> > Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com>
> > Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> > ---
> >  connect.c |    4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/connect.c b/connect.c
> > index 574f42f..0d007f3 100644
> > --- a/connect.c
> > +++ b/connect.c
> > @@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2], const
> > char *url_orig, conn->argv = arg = xcalloc(6, sizeof(*arg));
> >  	if (protocol == PROTO_SSH) {
> >  		const char *ssh = getenv("GIT_SSH");
> > +		int putty = ssh && strstr(ssh, "plink");
> >  		if (!ssh) ssh = "ssh";
> >
> >  		*arg++ = ssh;
> >  		if (port) {
> > -			*arg++ = "-p";
> > +			/* P is for PuTTY, p is for OpenSSH */
> > +			*arg++ = putty ? "-P" : "-p";
> >  			*arg++ = port;
> >  		}
> >  		*arg++ = host;
> 
> What about installing a wrapper script, plinkssh, that does this:
> 
> #!/bin/bash
> 
> if test "$1" = -p; then
> 	port="-P $2"
> 	shift; shift
> fi
> 
> exec plink $port "$@"
> 
> and require plink users to set GIT_SSH=plinkssh?

I like that better than this special-casing of plink.

Ciao,
Dscho

Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing

[Thomas Rast]

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

Junio C Hamano wrote:
> 
> > Blindly concatenating the above two and feeding them to "git apply" *may*
> > happen to work by accident, not by design.  This very much feels like a
> > hack of "This works most of the time for me, your mileage may vary" kind,
> > which we would want to avoid when we can.
> 
> Well, I changed my mind.  Let's run with this and see what happens.

In support of this being a feature of git-apply, notice that it even
handles the situation correctly where the context of a hunk has been
influenced by previous hunks, as in

@@ -1,2 +1,3 @@
 foo
+quux
 bar
@@ -1,3 +1,4 @@
 foo
 quux
+abc
 bar

With Don Zickus' recent patch, it also handles patches that go over
the same file twice.

- Thomas

-- 
Thomas Rast
trast@student.ethz.ch




[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> Junio C Hamano wrote:
>> 
>> > Blindly concatenating the above two and feeding them to "git apply" *may*
>> > happen to work by accident, not by design.  This very much feels like a
>> > hack of "This works most of the time for me, your mileage may vary" kind,
>> > which we would want to avoid when we can.
>> 
>> Well, I changed my mind.  Let's run with this and see what happens.
>
> In support of this being a feature of git-apply, notice that it even
> handles the situation correctly where the context of a hunk has been
> influenced by previous hunks, as in...

That's what meant by my earlier "application is hunk-by-hunk in nature"
and we are in agreement.  The fact it works that way is not quite by
design and close to being "by accident", but I do not foresee anybody
changing it in the near future, so...

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Steffen Prohaska]

On Jul 3, 2008, at 1:10 PM, Johannes Schindelin wrote:

> On Wed, 2 Jul 2008, Johannes Sixt wrote:
>
>> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
>>> From: Edward Z. Yang <edwardzyang@thewritingpot.com>
>>>
>>> PuTTY requires -P while OpenSSH requires -p; if plink is detected
>>> as GIT_SSH, use the alternate flag.
>>>
>>> Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com>
>>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>>> ---
>>> connect.c |    4 +++-
>>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/connect.c b/connect.c
>>> index 574f42f..0d007f3 100644
>>> --- a/connect.c
>>> +++ b/connect.c
>>> @@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2],  
>>> const
>>> char *url_orig, conn->argv = arg = xcalloc(6, sizeof(*arg));
>>> 	if (protocol == PROTO_SSH) {
>>> 		const char *ssh = getenv("GIT_SSH");
>>> +		int putty = ssh && strstr(ssh, "plink");
>>> 		if (!ssh) ssh = "ssh";
>>>
>>> 		*arg++ = ssh;
>>> 		if (port) {
>>> -			*arg++ = "-p";
>>> +			/* P is for PuTTY, p is for OpenSSH */
>>> +			*arg++ = putty ? "-P" : "-p";
>>> 			*arg++ = port;
>>> 		}
>>> 		*arg++ = host;
>>
>> What about installing a wrapper script, plinkssh, that does this:
>>
>> #!/bin/bash
>>
>> if test "$1" = -p; then
>> 	port="-P $2"
>> 	shift; shift
>> fi
>>
>> exec plink $port "$@"
>>
>> and require plink users to set GIT_SSH=plinkssh?
>
> I like that better than this special-casing of plink.


I'd prefer to change connect.c.  plinkssh would introduce another
dependency on the shell, while our overall goal is to avoid shell as
much as possible on Windows, no?  Edward's solution also looks more
obvious to me than the plinkssh wrapper script.

	Steffen

Re: [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser

[Steffen Prohaska]

On Jul 2, 2008, at 8:57 PM, Johannes Sixt wrote:

> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
>> The implementation directly calls the Win32 API to launch the  
>> browser.
>> Note that the specific directory layout of msysgit is required.
>
>> +#ifdef __MINGW32__
>> +	const char* exec_path = git_exec_path();
>> +	char *htmlpath = make_native_separator(
>> +			   mkpath("%s/../doc/git/html/%s.html"
>> +				  , exec_path
>> +				  , git_cmd)
>> +			 );
>> +	if (!file_exists(htmlpath)) {
>> +		htmlpath = make_native_separator(
>> +			      mkpath("%s/../doc/git/html/git-%s.html"
>> +				     , exec_path
>> +				     , git_cmd)
>> +			   );
>> +		if (!file_exists(htmlpath)) {
>> +			fprintf(stderr, "Can't find HTML help for '%s'.\n"
>> +				, git_cmd);
>> +			exit(1);
>> +		}
>> +	}
>> +	printf("Launching default browser to display HTML help ...\n");
>> +	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
>> +#else
>
> Can't we move this part into git-web--browse.sh? It should be a  
> matter of
> calling
>
> 	start $htmlpath
>
> (and msys-1.0.dll would convert slashes to backslashes for us).

I try to avoid the shell as much as possible on Windows.

How about the two following patches:

  [PATCH 1/2] help.c: Add support for htmldir relative to  
git_exec_path()
  [PATCH 2/2] help (Windows): Display HTML in default browser using  
Win32 API

I'll send them as replies to this mail.

	Steffen

	

[PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

[Steffen Prohaska]

If htmldir (in the Makefile) is a relative path, this path will be
interpreted relative to git_exec_path.  This can be used to create an
installation that can be moved to a different directory without
re-compiling.  The Windows installer (msysgit) is an example for such
a setup.

Note that the Makefile maps htmldir to the define GIT_HTML_PATH.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 help.c |   14 +++++++++++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/help.c b/help.c
index ca9632b..5586e1d 100644
--- a/help.c
+++ b/help.c
@@ -634,12 +634,20 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
 {
 	struct stat st;
 
+	const char* html_path = GIT_HTML_PATH;
+	if (!is_absolute_path(html_path)) {
+		struct strbuf d = STRBUF_INIT;
+		strbuf_addf(&d, "%s/%s", git_exec_path(), html_path);
+		html_path = strbuf_detach(&d, NULL);
+	}
+
 	/* Check that we have a git documentation directory. */
-	if (stat(GIT_HTML_PATH "/git.html", &st) || !S_ISREG(st.st_mode))
-		die("'%s': not a documentation directory.", GIT_HTML_PATH);
+	if (stat(mkpath("%s/git.html", html_path), &st)
+	    || !S_ISREG(st.st_mode))
+		die("'%s': not a documentation directory.", html_path);
 
 	strbuf_init(page_path, 0);
-	strbuf_addf(page_path, GIT_HTML_PATH "/%s.html", page);
+	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
 static void show_html_page(const char *git_cmd)
-- 
1.5.6.1.282.gd8a0d

[PATCH 2/2] help (Windows): Display HTML in default browser using Win32 API

[Steffen Prohaska]

The Win32 API is now called directly to launch the system's default
browser for displaying HTML help pages instead of launching a shell to
execute git-web--browser.  Avoiding the MSYS' bash when possible is good
because it avoids potential path translation issues.  In this case it is
not too hard to avoid launching a shell, so let's avoid it.

This commit also adds make_native_separator() to convert slashes to
backslashes on Windows.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 cache.h |    2 ++
 help.c  |   18 ++++++++++++++++++
 path.c  |   18 ++++++++++++++++++
 3 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/cache.h b/cache.h
index 35a9132..747581f 100644
--- a/cache.h
+++ b/cache.h
@@ -527,6 +527,8 @@ static inline int is_absolute_path(const char *path)
 const char *make_absolute_path(const char *path);
 const char *make_nonrelative_path(const char *path);
 const char *make_relative_path(const char *abs, const char *base);
+/* Convert slashes to backslashes on Windows.  no-op on other platforms. */
+const char *make_native_separator(const char *path);
 
 /* Read and unpack a sha1 file into memory, write memory to a sha1 file */
 extern int sha1_object_info(const unsigned char *, unsigned long *);
diff --git a/help.c b/help.c
index 5586e1d..8fcd644 100644
--- a/help.c
+++ b/help.c
@@ -9,6 +9,7 @@
 #include "common-cmds.h"
 #include "parse-options.h"
 #include "run-command.h"
+#include "dir.h"
 
 static struct man_viewer_list {
 	struct man_viewer_list *next;
@@ -650,6 +651,19 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
 	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
+#ifdef __MINGW32__
+static void open_html_win(const char *unixpath)
+{
+	const char *htmlpath = make_native_separator(mkpath("%s",unixpath));
+	if (!file_exists(htmlpath)) {
+		fprintf(stderr, "HTML file '%s' does not exist.\n", htmlpath);
+		exit(1);
+	}
+	printf("Launching default browser to display HTML help ...\n");
+	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
+}
+#endif
+
 static void show_html_page(const char *git_cmd)
 {
 	const char *page = cmd_to_page(git_cmd);
@@ -657,7 +671,11 @@ static void show_html_page(const char *git_cmd)
 
 	get_html_page_path(&page_path, page);
 
+#ifdef __MINGW32__
+	open_html_win(page_path.buf);
+#else
 	execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL);
+#endif
 }
 
 void help_unknown_cmd(const char *cmd)
diff --git a/path.c b/path.c
index 496123c..9f2bd91 100644
--- a/path.c
+++ b/path.c
@@ -343,3 +343,21 @@ const char *make_relative_path(const char *abs, const char *base)
 	strcpy(buf, abs + baselen);
 	return buf;
 }
+
+const char *make_native_separator(const char* path) {
+#ifdef __MINGW32__
+	static char buf[PATH_MAX + 1];
+	char* c;
+
+	if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+		die ("Too long path: %.*s", 60, path);
+
+	for (c = buf; *c; c++) {
+		if (*c == '/')
+			*c = '\\';
+	}
+	return buf;
+#else
+	return path;
+#endif
+}
-- 
1.5.6.1.282.gd8a0d

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Junio C Hamano]

Johannes Sixt <johannes.sixt@telecom.at> writes:

> What about installing a wrapper script, plinkssh, that does this:
>
> #!/bin/bash
>
> if test "$1" = -p; then
> 	port="-P $2"
> 	shift; shift
> fi
>
> exec plink $port "$@"
>
> and require plink users to set GIT_SSH=plinkssh?

That's quite a nice solution with absolute minimum impact.

Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> If htmldir (in the Makefile) is a relative path, this path will be
> interpreted relative to git_exec_path.  This can be used to create an
> installation that can be moved to a different directory without
> re-compiling.  The Windows installer (msysgit) is an example for such
> a setup.
> ...
> +	const char* html_path = GIT_HTML_PATH;

Style.  Asterisk sticks to the variable, not type.

> +	if (!is_absolute_path(html_path)) {
> +		struct strbuf d = STRBUF_INIT;
> +		strbuf_addf(&d, "%s/%s", git_exec_path(), html_path);
> +		html_path = strbuf_detach(&d, NULL);
> +	}

I've seen similar "if $this (which is usually an absolute) is relative, it
is taken as relative to git_exec_path" solution employed elsewhere in the
MinGW series, and I think it makes sense, even though initially I thought
it was somewhat hacky.

Could you check if there are copy-and-pasted duplicated code you can
factor out before continuing this direction?  I suspect templates and
etc/gitconfig are specified in similar fashion, and it would probably be
easier to maintain if you define once:

	char *system_path(const char *specified)
        {
        	if (is_absolute_path(specified))
	                return specified;
		... strbuf dance ...
                return strbuf_detach(...);
        }

and use it like this:

	const char *html_path = system_path(GIT_HTML_PATH);

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Steffen Prohaska]

On Jul 4, 2008, at 11:18 AM, Junio C Hamano wrote:

> Johannes Sixt <johannes.sixt@telecom.at> writes:
>
>> What about installing a wrapper script, plinkssh, that does this:
>>
>> #!/bin/bash
>>
>> if test "$1" = -p; then
>> 	port="-P $2"
>> 	shift; shift
>> fi
>>
>> exec plink $port "$@"
>>
>> and require plink users to set GIT_SSH=plinkssh?
>
> That's quite a nice solution with absolute minimum impact.

It has minimum impact on the source code of git.  The same is not
true, however, for the git user and the installer on Windows:

  - The proposed plinkssh requires that plink is in the PATH.  This is
    not necessarily the case on Windows.  If plink is not in the PATH,
    then the user needs to modify plinkssh.

  - The msysgit installer supports setting GIT_SSH to the full path
    of plink.  It automatically detects this path based on Putty's
    entries in the Windows registry.  If we choose the plinkssh
    solution the installer has to be modified.

Setting '-P' in connect.c would have some impact on the git source,
but would avoid changes elsewhere.

	Steffen

Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

[Johannes Schindelin]

Hi,

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

> Could you check if there are copy-and-pasted duplicated code you can 
> factor out before continuing this direction?

Note also that Hannes tried very hard to get rid of those ugly "#ifdef 
__MINGW32__"s by declaring/overriding functions in git-compat-util.h.

I think that is such a good practice that we should not stop here.

Ciao,
Dscho

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Clifford Caoile]

Hi:

On Fri, Jul 4, 2008 at 6:29 PM, Steffen Prohaska <prohaska@zib.de> wrote:
>
> On Jul 4, 2008, at 11:18 AM, Junio C Hamano wrote:
>
>> Johannes Sixt <johannes.sixt@telecom.at> writes:
>>
>>> What about installing a wrapper script, plinkssh, that does this:
>>
>> That's quite a nice solution with absolute minimum impact.
>
> It has minimum impact on the source code of git.  The same is not
> true, however, for the git user and the installer on Windows:
>
>  - The proposed plinkssh requires that plink is in the PATH.  This is
>   not necessarily the case on Windows.  If plink is not in the PATH,
>   then the user needs to modify plinkssh.
>
>  - The msysgit installer supports setting GIT_SSH to the full path
>   of plink.  It automatically detects this path based on Putty's
>   entries in the Windows registry.  If we choose the plinkssh
>   solution the installer has to be modified.

How about we create one more global environment variable
MSYSGIT_REAL_PLINK which points to the Windows plink during
installation? Then we set the GIT_SSH to the plinkssh, and the
proposed plinkssh can point to MSYSGIT_REAL_PLINK?

+ # fall back to plink if MSYSGIT_REAL_PLINK is not defined
+ # and hope plink is in the path
+ plink=${MSYSGIT_REAL_PLINK:-plink}

- exec plink $port "$@"
+ exec ${plink} $port "$@"

Perhaps I have traded one problem for another, because the msysgit
user still has to be aware of MSYSGIT_REAL_PLINK (at least she doesn't
have to set it up). And of course, the installer has to be modified to
accommodate plinkssh and my proposal.

Best regards,
Clifford Caoile

Re: [msysGit] Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Edward Z. Yang]

Clifford Caoile wrote:
> Perhaps I have traded one problem for another, because the msysgit
> user still has to be aware of MSYSGIT_REAL_PLINK (at least she doesn't
> have to set it up). And of course, the installer has to be modified to
> accommodate plinkssh and my proposal.

This feels unnecessarily complicated.

What would be cool is if we could just set GIT_SSH to plinkssh 
-path-to-plink "C:\Path\To\plink.exe" (obviously a shorter flag or 
something). Unfortunately, this doesn't seem to work with Git's current 
command argument handling.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.  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".

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

[Johannes Schindelin]

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

[PATCH v3] Implement "git stash branch <newbranch> <stash>"

[Abhijit Menon-Sen]

Restores the stashed state on a new branch rooted at the commit on which
the stash was originally created, so that conflicts caused by subsequent
changes on the original branch can be dealt with.

(Thanks to Junio for this nice idea.)

Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
Reposting as requested with a new test included.

 Documentation/git-stash.txt |   19 ++++++++++++++++++-
 git-stash.sh                |   21 +++++++++++++++++++++
 t/t3903-stash.sh            |   24 ++++++++++++++++++++++++
 3 files changed, 63 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 23ac331..a4cbd0c 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -8,8 +8,11 @@ git-stash - Stash the changes in a dirty working directory away
 SYNOPSIS
 --------
 [verse]
-'git stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
+'git stash' list
+'git stash' (show | apply | drop | pop) [<stash>]
+'git stash' branch <branchname> [<stash>]
 'git stash' [save [<message>]]
+'git stash' clear
 
 DESCRIPTION
 -----------
@@ -81,6 +84,20 @@ tree's changes, but also the index's ones. However, this can fail, when you
 have conflicts (which are stored in the index, where you therefore can no
 longer apply the changes as they were originally).
 
+branch <branchname> [<stash>]::
+
+	Creates and checks out a new branch named `<branchname>` starting from
+	the commit at which the `<stash>` was originally created, applies the
+	changes recorded in `<stash>` to the new working tree and index, then
+	drops the `<stash>` if that completes successfully. When no `<stash>`
+	is given, applies the latest one.
++
+This is useful if the branch on which you ran `git stash save` has
+changed enough that `git stash apply` fails due to conflicts. Since
+the stash is applied on top of the commit that was HEAD at the time
+`git stash` was run, it restores the originally stashed state with
+no conflicts.
+
 clear::
 	Remove all the stashed states. Note that those states will then
 	be subject to pruning, and may be difficult or impossible to recover.
diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..889445c 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -218,6 +218,23 @@ drop_stash () {
 	git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
 }
 
+apply_to_branch () {
+	have_stash || die 'Nothing to apply'
+
+	test -n "$1" || die 'No branch name specified'
+	branch=$1
+
+	if test -z "$2"
+	then
+		set x "$ref_stash@{0}"
+	fi
+	stash=$2
+
+	git-checkout -b $branch $stash^ &&
+	apply_stash --index $stash &&
+	drop_stash $stash
+}
+
 # Main command set
 case "$1" in
 list)
@@ -264,6 +281,10 @@ pop)
 		drop_stash "$@"
 	fi
 	;;
+branch)
+	shift
+	apply_to_branch "$@"
+	;;
 *)
 	if test $# -eq 0
 	then
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 54d99ed..6d89218 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -117,4 +117,28 @@ test_expect_success 'stash pop' '
 	test 0 = $(git stash list | wc -l)
 '
 
+cat > expect << EOF
+diff --git a/file b/file
+index 7601807..5716ca5 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-baz
++bar
+EOF
+
+test_expect_success 'stash apply' '
+	echo foo > file &&
+	git commit file -m first
+	echo bar > file &&
+	git stash &&
+	echo baz > file &&
+	git commit file -m second &&
+	git stash branch stashbranch &&
+	git commit file -m alternate\ second &&
+	git diff master..stashbranch > output &&
+	test_cmp output expect &&
+	test 0 = $(git stash list | wc -l)
+'
+
 test_done
-- 
1.5.6

Re: [PATCH v3] Implement "git stash branch <newbranch> <stash>"

[Johannes Schindelin]

Hi,

On Sun, 6 Jul 2008, Abhijit Menon-Sen wrote:

> Restores the stashed state on a new branch rooted at the commit on which
> the stash was originally created, so that conflicts caused by subsequent
> changes on the original branch can be dealt with.
> 
> (Thanks to Junio for this nice idea.)
> 
> Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
> ---
> Reposting as requested with a new test included.

AFAICS the previous version is in 'next' already: 
656b50345239293929ad8c639c5f1941c6b867ad

Hth,
Dscho

[PATCH] Add a test for "git stash branch"

[Abhijit Menon-Sen]

Make sure that applying the stash to a new branch after a conflicting
change doesn't result in an error when you try to commit.

Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---

At 2008-07-06 14:54:44 +0200, Johannes.Schindelin@gmx.de wrote:
>
> AFAICS the previous version is in 'next' already: 
> 656b50345239293929ad8c639c5f1941c6b867ad

Oh, I see, thanks. I misunderstood the request. Here's a separate patch
to just add the test.

Sorry for the noise.

-- ams

 t/t3903-stash.sh |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 54d99ed..6d89218 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -117,4 +117,28 @@ test_expect_success 'stash pop' '
 	test 0 = $(git stash list | wc -l)
 '
 
+cat > expect << EOF
+diff --git a/file b/file
+index 7601807..5716ca5 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-baz
++bar
+EOF
+
+test_expect_success 'stash apply' '
+	echo foo > file &&
+	git commit file -m first
+	echo bar > file &&
+	git stash &&
+	echo baz > file &&
+	git commit file -m second &&
+	git stash branch stashbranch &&
+	git commit file -m alternate\ second &&
+	git diff master..stashbranch > output &&
+	test_cmp output expect &&
+	test 0 = $(git stash list | wc -l)
+'
+
 test_done
-- 
1.5.6

Re: [PATCH] Add a test for "git stash branch"

[Junio C Hamano]

Abhijit Menon-Sen <ams@toroid.org> writes:

> At 2008-07-06 14:54:44 +0200, Johannes.Schindelin@gmx.de wrote:
>>
>> AFAICS the previous version is in 'next' already: 
>> 656b50345239293929ad8c639c5f1941c6b867ad
>
> Oh, I see, thanks. I misunderstood the request. Here's a separate patch
> to just add the test.

Oh, there is no misunderstanding.  You couldn't have possibly known if the
main body of the patch will go to 'next' or just be dropped when I said
"you might also want to have tests" to you.

> +test_expect_success 'stash apply' '
> +	echo foo > file &&
> +	git commit file -m first
> +	echo bar > file &&
> +	git stash &&
> +	echo baz > file &&
> +	git commit file -m second &&
> +	git stash branch stashbranch &&
> +	git commit file -m alternate\ second &&
> +	git diff master..stashbranch > output &&
> +	test_cmp output expect &&
> +	test 0 = $(git stash list | wc -l)
> +'

The title is probably not 'stash apply' but 'stash branch'.  Don't you
want to also validate that:

 - "stash branch" command switched to the new branch "stashbranch"?

 - before making "alternate second", the index and the working tree have
   expected contents?  and

 - the final shape of the history looks correctly forked (i.e.
   "stashbranch" branches at the commit before "-m second" commit was
   made)?

>  test_done
> -- 
> 1.5.6

[PATCH v2] Add a test for "git stash branch"

[Abhijit Menon-Sen]

Make sure that applying the stash to a new branch after a conflicting
change doesn't result in an error when you try to commit.

Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---

At 2008-07-06 12:53:02 -0700, gitster@pobox.com wrote:
>
> The title is probably not 'stash apply' but 'stash branch'.

Fixed, thanks.

> Don't you want to also validate that: [...]

Done.

-- ams

 t/t3903-stash.sh |   61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 54d99ed..bd1cdab 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -117,4 +117,65 @@ test_expect_success 'stash pop' '
 	test 0 = $(git stash list | wc -l)
 '
 
+cat > expect << EOF
+diff --git a/file2 b/file2
+new file mode 100644
+index 0000000..1fe912c
+--- /dev/null
++++ b/file2
+@@ -0,0 +1 @@
++bar2
+EOF
+
+cat > expect1 << EOF
+diff --git a/file b/file
+index 257cc56..5716ca5 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-foo
++bar
+EOF
+
+cat > expect2 << EOF
+diff --git a/file b/file
+index 7601807..5716ca5 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-baz
++bar
+diff --git a/file2 b/file2
+new file mode 100644
+index 0000000..1fe912c
+--- /dev/null
++++ b/file2
+@@ -0,0 +1 @@
++bar2
+EOF
+
+test_expect_success 'stash branch' '
+	echo foo > file &&
+	git commit file -m first
+	echo bar > file &&
+	echo bar2 > file2 &&
+	git add file2 &&
+	git stash &&
+	echo baz > file &&
+	git commit file -m second &&
+	git stash branch stashbranch &&
+	test refs/heads/stashbranch = $(git symbolic-ref HEAD) &&
+	test $(git rev-parse HEAD) = $(git rev-parse master^) &&
+	git diff --cached > output &&
+	test_cmp output expect &&
+	git diff > output &&
+	test_cmp output expect1 &&
+	git add file &&
+	git commit -m alternate\ second &&
+	git diff master..stashbranch &&
+	git diff master..stashbranch > output &&
+	test_cmp output expect2 &&
+	test 0 = $(git stash list | wc -l)
+'
+
 test_done
-- 
1.5.6

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

[Junio C Hamano]

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)
 

Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> This adds only the minimum necessary to keep git pull/merge's diffstat from
> wrapping. Notably absent is support for the K (erase) operation, and
> support for POSIX write.

I've tested this patch, and it is no longer ready for prime-time in its 
current form. It doesn't do what it advertises (colorize diffstat of merge) 
because the diff machinery since some time now uses fprintf, not printf, so 
the replacements are not called and escape characters are left in the console 
window.

> +#ifdef WIN_ANSI
> +extern int git_fputs(const char *str, FILE *stream);
> +extern int git_printf(const char *format, ...) __attribute__((format
> (printf, 1, 2))); +#define fputs git_fputs
> +#define printf(...) git_printf(__VA_ARGS__)
> +#endif
> +
>  #endif

Put this (without #ifdef WIN_ANSI) in mingw.h and don't change the Makefile.

-- Hannes

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.  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.

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.  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.

Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

[Steffen Prohaska]

On Jul 4, 2008, at 2:35 PM, Johannes Schindelin wrote:

> On Fri, 4 Jul 2008, Junio C Hamano wrote:
>
>> Could you check if there are copy-and-pasted duplicated code you can
>> factor out before continuing this direction?
>
> Note also that Hannes tried very hard to get rid of those ugly "#ifdef
> __MINGW32__"s by declaring/overriding functions in git-compat-util.h.
>
> I think that is such a good practice that we should not stop here.

I'll send three patches that address Junio's and Dscho's comments:

  [PATCH 1/3] Move code interpreting path relative to exec-dir to new  
function system_path()
  [PATCH 2/3] help.c: Add support for htmldir relative to  
git_exec_path()
  [PATCH 3/3] help (Windows): Display HTML in default browser using  
Windows' shell API


Hannes,
the patches I'll send probably conflict with your planned work on
GIT_EXEC_PATH that has been discussed on the msysgit list.  I think
you could built on my series and modify system_path().

	Steffen

[PATCH 1/3] Move code interpreting path relative to exec-dir to new function system_path()

[Steffen Prohaska]

Expanding system paths relative to git_exec_path can be used for
creating an installation that can be moved to a different directory
without re-compiling.  We use this approach for template_dir and the
system wide gitconfig.  The Windows installer (msysgit) is an example
for such a setup.

This commit moves common code to a new function system_path().  System
paths that are to be interpreted relative to git_exec_path are passed to
system_path() and the return value is used instead of the original path.
system_path() prefixes a relative path with git_exec_path and leaves
absolute paths unmodified.  For example, we now write

    template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 builtin-init-db.c |   14 ++------------
 cache.h           |    1 +
 config.c          |   11 ++---------
 path.c            |   11 +++++++++++
 4 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/builtin-init-db.c b/builtin-init-db.c
index e23b843..5ba213a 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -115,18 +115,8 @@ static void copy_templates(const char *template_dir)
 
 	if (!template_dir)
 		template_dir = getenv(TEMPLATE_DIR_ENVIRONMENT);
-	if (!template_dir) {
-		/*
-		 * if the hard-coded template is relative, it is
-		 * interpreted relative to the exec_dir
-		 */
-		template_dir = DEFAULT_GIT_TEMPLATE_DIR;
-		if (!is_absolute_path(template_dir)) {
-			struct strbuf d = STRBUF_INIT;
-			strbuf_addf(&d, "%s/%s", git_exec_path(), template_dir);
-			template_dir = strbuf_detach(&d, NULL);
-		}
-	}
+	if (!template_dir)
+		template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);
 	strcpy(template_path, template_dir);
 	template_len = strlen(template_path);
 	if (template_path[template_len-1] != '/') {
diff --git a/cache.h b/cache.h
index 0d8edda..dafa265 100644
--- a/cache.h
+++ b/cache.h
@@ -529,6 +529,7 @@ const char *make_nonrelative_path(const char *path);
 const char *make_relative_path(const char *abs, const char *base);
 int normalize_absolute_path(char *buf, const char *path);
 int longest_ancestor_length(const char *path, const char *prefix_list);
+extern const char *system_path(const char *path);
 
 /* Read and unpack a sha1 file into memory, write memory to a sha1 file */
 extern int sha1_object_info(const unsigned char *, unsigned long *);
diff --git a/config.c b/config.c
index 2862cc4..1e066c7 100644
--- a/config.c
+++ b/config.c
@@ -581,15 +581,8 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
 const char *git_etc_gitconfig(void)
 {
 	static const char *system_wide;
-	if (!system_wide) {
-		system_wide = ETC_GITCONFIG;
-		if (!is_absolute_path(system_wide)) {
-			/* interpret path relative to exec-dir */
-			struct strbuf d = STRBUF_INIT;
-			strbuf_addf(&d, "%s/%s", git_exec_path(), system_wide);
-			system_wide = strbuf_detach(&d, NULL);
-		}
-	}
+	if (!system_wide)
+		system_wide = system_path(ETC_GITCONFIG);
 	return system_wide;
 }
 
diff --git a/path.c b/path.c
index 5983255..141496e 100644
--- a/path.c
+++ b/path.c
@@ -11,6 +11,7 @@
  * which is what it's designed for.
  */
 #include "cache.h"
+#include "exec_cmd.h"
 
 static char bad_path[] = "/bad-path/";
 
@@ -439,3 +440,13 @@ int longest_ancestor_length(const char *path, const char *prefix_list)
 
 	return max_len;
 }
+
+const char *system_path(const char *path)
+{
+	if (!is_absolute_path(path)) {
+		struct strbuf d = STRBUF_INIT;
+		strbuf_addf(&d, "%s/%s", git_exec_path(), path);
+		path = strbuf_detach(&d, NULL);
+	}
+	return path;
+}
-- 
1.5.6.1.282.gd8a0d

[PATCH 2/3] help.c: Add support for htmldir relative to git_exec_path()

[Steffen Prohaska]

If htmldir (in the Makefile) is a relative path, this path will now be
interpreted relative to git_exec_path.  This can be used to create an
installation that can be moved to a different directory without
re-compiling.  The Windows installer (msysgit) is an example for such
a setup.

Note that the Makefile maps htmldir to the define GIT_HTML_PATH.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 help.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/help.c b/help.c
index ca9632b..0f055bf 100644
--- a/help.c
+++ b/help.c
@@ -633,13 +633,15 @@ static void show_info_page(const char *git_cmd)
 static void get_html_page_path(struct strbuf *page_path, const char *page)
 {
 	struct stat st;
+	const char *html_path = system_path(GIT_HTML_PATH);
 
 	/* Check that we have a git documentation directory. */
-	if (stat(GIT_HTML_PATH "/git.html", &st) || !S_ISREG(st.st_mode))
-		die("'%s': not a documentation directory.", GIT_HTML_PATH);
+	if (stat(mkpath("%s/git.html", html_path), &st)
+	    || !S_ISREG(st.st_mode))
+		die("'%s': not a documentation directory.", html_path);
 
 	strbuf_init(page_path, 0);
-	strbuf_addf(page_path, GIT_HTML_PATH "/%s.html", page);
+	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
 static void show_html_page(const char *git_cmd)
-- 
1.5.6.1.282.gd8a0d

[PATCH 3/3] help (Windows): Display HTML in default browser using Windows' shell API

[Steffen Prohaska]

The system's default browser for displaying HTML help pages is now used
directly on Windows, instead of launching git-web--browser, which
requires a Unix shell.  Avoiding MSYS' bash when possible is good
because it avoids potential path translation issues.  In this case it is
not too hard to avoid launching a shell, so let's avoid it.

The Windows-specific code is implemented in compat/mingw.c to avoid
platform-specific code in the main code base.  On Windows, open_html is
provided as a define.  If open_html is not defined, git-web--browse is
used.  This approach avoids platform-specific ifdefs by using
per-function ifdefs.  The "ifndef open_html" together with the
introductory comment should sufficiently warn developers, so that they
hopefully will not break this mechanism.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 compat/mingw.c |   21 +++++++++++++++++++++
 compat/mingw.h |    3 +++
 help.c         |   14 +++++++++++++-
 3 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index 3a05fe7..f7ef545 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler)
 	timer_fn = handler;
 	return old;
 }
+
+static const char *make_backslash_path(const char* path) {
+	static char buf[PATH_MAX + 1];
+	char* c;
+
+	if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+		die ("Too long path: %.*s", 60, path);
+
+	for (c = buf; *c; c++) {
+		if (*c == '/')
+			*c = '\\';
+	}
+	return buf;
+}
+
+void mingw_open_html(const char *unixpath)
+{
+	const char *htmlpath = make_backslash_path(unixpath);
+	printf("Launching default browser to display HTML ...\n");
+	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
+}
diff --git a/compat/mingw.h b/compat/mingw.h
index 6bc049a..136361e 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -193,6 +193,9 @@ static inline unsigned int git_ntohl(unsigned int x)
 sig_handler_t mingw_signal(int sig, sig_handler_t handler);
 #define signal mingw_signal
 
+void mingw_open_html(const char *path);
+#define open_html mingw_open_html
+
 /*
  * git specific compatibility
  */
diff --git a/help.c b/help.c
index 0f055bf..18116f3 100644
--- a/help.c
+++ b/help.c
@@ -644,6 +644,18 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
 	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
+/*
+ * If open_html is not defined in a platform-specific way (see for
+ * example compat/mingw.h), we use the script web--browse to display
+ * HTML.
+ */
+#ifndef open_html
+void open_html(const char* path)
+{
+	execl_git_cmd("web--browse", "-c", "help.browser", path, NULL);
+}
+#endif
+
 static void show_html_page(const char *git_cmd)
 {
 	const char *page = cmd_to_page(git_cmd);
@@ -651,7 +663,7 @@ static void show_html_page(const char *git_cmd)
 
 	get_html_page_path(&page_path, page);
 
-	execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL);
+	open_html(page_path.buf);
 }
 
 void help_unknown_cmd(const char *cmd)
-- 
1.5.6.1.282.gd8a0d

Re: [PATCH 3/3] help (Windows): Display HTML in default browser using Windows' shell API

[Steffen Prohaska]

On Jul 11, 2008, at 9:28 AM, Steffen Prohaska wrote:

> +
> +static const char *make_backslash_path(const char* path) {
> +	static char buf[PATH_MAX + 1];
> +	char* c;

Style :-(.  I'll send a fixed patch in a minute.


> +#ifndef open_html
> +void open_html(const char* path)
> +{

It'll fix this too.

	Steffen

[PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

[Steffen Prohaska]

The system's default browser for displaying HTML help pages is now used
directly on Windows, instead of launching git-web--browser, which
requires a Unix shell.  Avoiding MSYS' bash when possible is good
because it avoids potential path translation issues.  In this case it is
not too hard to avoid launching a shell, so let's avoid it.

The Windows-specific code is implemented in compat/mingw.c to avoid
platform-specific code in the main code base.  On Windows, open_html is
provided as a define.  If open_html is not defined, git-web--browse is
used.  This approach avoids platform-specific ifdefs by using
per-function ifdefs.  The "ifndef open_html" together with the
introductory comment should sufficiently warn developers, so that they
hopefully will not break this mechanism.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 compat/mingw.c |   21 +++++++++++++++++++++
 compat/mingw.h |    3 +++
 help.c         |   14 +++++++++++++-
 3 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index 3a05fe7..0ca73f7 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler)
 	timer_fn = handler;
 	return old;
 }
+
+static const char *make_backslash_path(const char *path) {
+	static char buf[PATH_MAX + 1];
+	char *c;
+
+	if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+		die ("Too long path: %.*s", 60, path);
+
+	for (c = buf; *c; c++) {
+		if (*c == '/')
+			*c = '\\';
+	}
+	return buf;
+}
+
+void mingw_open_html(const char *unixpath)
+{
+	const char *htmlpath = make_backslash_path(unixpath);
+	printf("Launching default browser to display HTML ...\n");
+	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
+}
diff --git a/compat/mingw.h b/compat/mingw.h
index 6bc049a..136361e 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -193,6 +193,9 @@ static inline unsigned int git_ntohl(unsigned int x)
 sig_handler_t mingw_signal(int sig, sig_handler_t handler);
 #define signal mingw_signal
 
+void mingw_open_html(const char *path);
+#define open_html mingw_open_html
+
 /*
  * git specific compatibility
  */
diff --git a/help.c b/help.c
index 0f055bf..52d39b8 100644
--- a/help.c
+++ b/help.c
@@ -644,6 +644,18 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
 	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
+/*
+ * If open_html is not defined in a platform-specific way (see for
+ * example compat/mingw.h), we use the script web--browse to display
+ * HTML.
+ */
+#ifndef open_html
+void open_html(const char *path)
+{
+	execl_git_cmd("web--browse", "-c", "help.browser", path, NULL);
+}
+#endif
+
 static void show_html_page(const char *git_cmd)
 {
 	const char *page = cmd_to_page(git_cmd);
@@ -651,7 +663,7 @@ static void show_html_page(const char *git_cmd)
 
 	get_html_page_path(&page_path, page);
 
-	execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL);
+	open_html(page_path.buf);
 }
 
 void help_unknown_cmd(const char *cmd)
-- 
1.5.6.1.282.gd8a0d

Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

[Johannes Sixt]

Zitat von Steffen Prohaska <prohaska@zib.de>:
>
> On Jul 4, 2008, at 2:35 PM, Johannes Schindelin wrote:
>
> > On Fri, 4 Jul 2008, Junio C Hamano wrote:
> >
> >> Could you check if there are copy-and-pasted duplicated code you can
> >> factor out before continuing this direction?
> >
> > Note also that Hannes tried very hard to get rid of those ugly "#ifdef
> > __MINGW32__"s by declaring/overriding functions in git-compat-util.h.
> >
> > I think that is such a good practice that we should not stop here.
>
> I'll send three patches that address Junio's and Dscho's comments:
>
>   [PATCH 1/3] Move code interpreting path relative to exec-dir to new
> function system_path()
>   [PATCH 2/3] help.c: Add support for htmldir relative to
> git_exec_path()
>   [PATCH 3/3] help (Windows): Display HTML in default browser using
> Windows' shell API
>
>
> Hannes,
> the patches I'll send probably conflict with your planned work on
> GIT_EXEC_PATH that has been discussed on the msysgit list.  I think
> you could built on my series and modify system_path().

Thanks. I haven't done a lot in that direction, yet, so your patches will be
helpful.

But according to the conclusion of our recent discussion

http://thread.gmane.org/gmane.comp.version-control.msysgit/2633/focus=2669

I shall modify system_path() to construct paths relative to the git executable,
which is essentially Makefile's $(bindir), not git_exec_path().

-- Hannes

[PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

[Steffen Prohaska]

From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>

Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 convert.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/convert.c b/convert.c
index 352b69d..78efed8 100644
--- a/convert.c
+++ b/convert.c
@@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
 		else
 			stats->printable++;
 	}
+
+	/* If file ends with EOF then don't count this EOF as non-printable. */
+	if (size >= 1 && buf[size-1] == '\032')
+		stats->nonprintable--;
 }
 
 /*
-- 
1.5.6.1.282.gd8a0d

[PATCH] Convert CR/LF to LF in tag signatures

[Steffen Prohaska]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

On Windows, gpg outputs CR/LF signatures.  But since the tag messages
are already stripped of the CR by stripspace(), it is arguably nicer
to do the same for the tag signature.  Actually, this patch does not
look for CR/LF, but strips all CRs from the signature.  It does so not
only on Windows but on all platforms to keep the code simpler.

[ spr: ported code to use strbuf ]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 builtin-tag.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/builtin-tag.c b/builtin-tag.c
index 3c97c69..a70922b 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -202,6 +202,7 @@ static int do_sign(struct strbuf *buffer)
 	const char *args[4];
 	char *bracket;
 	int len;
+	int i, j;
 
 	if (!*signingkey) {
 		if (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),
@@ -241,6 +242,15 @@ static int do_sign(struct strbuf *buffer)
 	if (finish_command(&gpg) || !len || len < 0)
 		return error("gpg failed to sign the tag");
 
+	/* Strip CR from the line endings, in case we are on Windows. */
+	for (i = j = 0; i < buffer->len; i++)
+		if (buffer->buf[i] != '\r') {
+			if (i != j)
+				buffer->buf[j] = buffer->buf[i];
+			j++;
+		}
+	strbuf_setlen(buffer, j);
+
 	return 0;
 }
 
-- 
1.5.6.1.282.gd8a0d

Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Steffen Prohaska wrote:

> From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
> 
> Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
>  convert.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/convert.c b/convert.c
> index 352b69d..78efed8 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
>  		else
>  			stats->printable++;
>  	}
> +
> +	/* If file ends with EOF then don't count this EOF as non-printable. */
> +	if (size >= 1 && buf[size-1] == '\032')
> +		stats->nonprintable--;

This is one of the things that are very specific to Windows and should not 
affect other people.

Ciao,
Dscho

P.S.: this is one of the examples why I would like to discuss things that 
are Windows-only on the msysGit list, until we have a consensus there.  We 
have a few Git experts there, you and Hannes in particular, which cover 
that side, but also some Windows experts such as Peter and Marius, and we 
should not need to have that discussion on a list where people are not 
expected to care about Windows _at all_.

Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

[Steffen Prohaska]

On Jul 11, 2008, at 8:42 PM, Johannes Schindelin wrote:

> On Fri, 11 Jul 2008, Steffen Prohaska wrote:
>
>> From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
>>
>> Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>> ---
>> convert.c |    4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/convert.c b/convert.c
>> index 352b69d..78efed8 100644
>> --- a/convert.c
>> +++ b/convert.c
>> @@ -61,6 +61,10 @@ static void gather_stats(const char *buf,  
>> unsigned long size, struct text_stat *
>> 		else
>> 			stats->printable++;
>> 	}
>> +
>> +	/* If file ends with EOF then don't count this EOF as non- 
>> printable. */
>> +	if (size >= 1 && buf[size-1] == '\032')
>> +		stats->nonprintable--;
>
> This is one of the things that are very specific to Windows and  
> should not
> affect other people.

Does this mean you are opposed to this change?

Junio thinks that "the intention of this change is good" [1].  Hence,
I cleaned up the style and re-send the patch.

[1] http://article.gmane.org/gmane.comp.version-control.git/87122

	Steffen

Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Steffen Prohaska wrote:

> On Jul 11, 2008, at 8:42 PM, Johannes Schindelin wrote:
> 
> >On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> >
> > >From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
> > >
> > >Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
> > >Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> > >---
> > >convert.c |    4 ++++
> > >1 files changed, 4 insertions(+), 0 deletions(-)
> > >
> > >diff --git a/convert.c b/convert.c
> > >index 352b69d..78efed8 100644
> > >--- a/convert.c
> > >+++ b/convert.c
> > >@@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long
> > >size, struct text_stat *
> > >  else
> > > 		stats->printable++;
> > >	}
> > >+
> > >+	/* If file ends with EOF then don't count this EOF as non-printable.
> > >*/
> > >+	if (size >= 1 && buf[size-1] == '\032')
> > >+		stats->nonprintable--;
> >
> >This is one of the things that are very specific to Windows and should not
> >affect other people.
> 
> Does this mean you are opposed to this change?

Hrm.  Thinking about it again, this _could_ help Unix people who 
collaborate with DOS people.

OTOH it will just hide the fact that text files were committed that 
contain silly characters.

On the third hand, this code path affects only people who set autocrlf.

Well, I guess they asked for it, kind of.

Ciao,
Dscho

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> diff --git a/compat/mingw.c b/compat/mingw.c
> index 3a05fe7..0ca73f7 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler)
> ...
> +void mingw_open_html(const char *unixpath)
> +{
> +	const char *htmlpath = make_backslash_path(unixpath);
> +	printf("Launching default browser to display HTML ...\n");
> +	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
> +}

Do you mean to have that printf() or is it a leftover debugging statement?

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

[Steffen Prohaska]

On Jul 12, 2008, at 5:26 AM, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> diff --git a/compat/mingw.c b/compat/mingw.c
>> index 3a05fe7..0ca73f7 100644
>> --- a/compat/mingw.c
>> +++ b/compat/mingw.c
>> @@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig,  
>> sig_handler_t handler)
>> ...
>> +void mingw_open_html(const char *unixpath)
>> +{
>> +	const char *htmlpath = make_backslash_path(unixpath);
>> +	printf("Launching default browser to display HTML ...\n");
>> +	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
>> +}
>
> Do you mean to have that printf() or is it a leftover debugging  
> statement?

I mean to have it.  It takes some time until a fresh browser starts up
if no browser has been running before.  Impatient people (like me) could
start believing that nothing would happen.  But this certainly depends
on your machine.  I run Windows inside a virtual machine on a Laptop,
which is probably rather slow compared to a desktop machine running
Windows natively.

	Steffen

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

>> Do you mean to have that printf() or is it a leftover debugging
>> statement?
>
> I mean to have it.

Ok, I was just checking.  Unless other Windows users complain, will apply
as-is.  As you might guess, I am completely neutral on this one.

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

[Johannes Sixt]

Zitat von Junio C Hamano <gitster@pobox.com>:

> Steffen Prohaska <prohaska@zib.de> writes:
>
> >> Do you mean to have that printf() or is it a leftover debugging
> >> statement?
> >
> > I mean to have it.
>
> Ok, I was just checking.  Unless other Windows users complain, will apply
> as-is.  As you might guess, I am completely neutral on this one.

I'm working on followups to this series, and it turns out to be more
convenient to have system_path() in exec_cmd.c instead of path.c.
It'll make sense if I resend the series with an updated version of 1/3
(instead of a patch that merely moves the function around).

-- Hannes

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

[Junio C Hamano]

Johannes Sixt <johannes.sixt@telecom.at> writes:

> Zitat von Junio C Hamano <gitster@pobox.com>:
>
>> Steffen Prohaska <prohaska@zib.de> writes:
>>
>> >> Do you mean to have that printf() or is it a leftover debugging
>> >> statement?
>> >
>> > I mean to have it.
>>
>> Ok, I was just checking.  Unless other Windows users complain, will apply
>> as-is.  As you might guess, I am completely neutral on this one.
>
> I'm working on followups to this series, and it turns out to be more
> convenient to have system_path() in exec_cmd.c instead of path.c.
> It'll make sense if I resend the series with an updated version of 1/3
> (instead of a patch that merely moves the function around).

Ok, will drop these three patches and wait for replacement from yours to
appear, and then we will see which ones to apply.

[PATCH] Move code interpreting path relative to exec-dir to new function system_path()

[Johannes Sixt]

From: Steffen Prohaska <prohaska@zib.de>

Expanding system paths relative to git_exec_path can be used for
creating an installation that can be moved to a different directory
without re-compiling.  We use this approach for template_dir and the
system wide gitconfig.  The Windows installer (msysgit) is an example
for such a setup.

This commit moves common code to a new function system_path().  System
paths that are to be interpreted relative to git_exec_path are passed to
system_path() and the return value is used instead of the original path.
system_path() prefixes a relative path with git_exec_path and leaves
absolute paths unmodified.  For example, we now write

    template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);

[j6t: moved from path.c to exec_cmd.c]

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 builtin-init-db.c |   14 ++------------
 config.c          |   11 ++---------
 exec_cmd.c        |   10 ++++++++++
 exec_cmd.h        |    2 +-
 4 files changed, 15 insertions(+), 22 deletions(-)

diff --git a/builtin-init-db.c b/builtin-init-db.c
index e23b843..5ba213a 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -115,18 +115,8 @@ static void copy_templates(const char *template_dir)
 
 	if (!template_dir)
 		template_dir = getenv(TEMPLATE_DIR_ENVIRONMENT);
-	if (!template_dir) {
-		/*
-		 * if the hard-coded template is relative, it is
-		 * interpreted relative to the exec_dir
-		 */
-		template_dir = DEFAULT_GIT_TEMPLATE_DIR;
-		if (!is_absolute_path(template_dir)) {
-			struct strbuf d = STRBUF_INIT;
-			strbuf_addf(&d, "%s/%s", git_exec_path(), template_dir);
-			template_dir = strbuf_detach(&d, NULL);
-		}
-	}
+	if (!template_dir)
+		template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);
 	strcpy(template_path, template_dir);
 	template_len = strlen(template_path);
 	if (template_path[template_len-1] != '/') {
diff --git a/config.c b/config.c
index 2862cc4..1e066c7 100644
--- a/config.c
+++ b/config.c
@@ -581,15 +581,8 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
 const char *git_etc_gitconfig(void)
 {
 	static const char *system_wide;
-	if (!system_wide) {
-		system_wide = ETC_GITCONFIG;
-		if (!is_absolute_path(system_wide)) {
-			/* interpret path relative to exec-dir */
-			struct strbuf d = STRBUF_INIT;
-			strbuf_addf(&d, "%s/%s", git_exec_path(), system_wide);
-			system_wide = strbuf_detach(&d, NULL);
-		}
-	}
+	if (!system_wide)
+		system_wide = system_path(ETC_GITCONFIG);
 	return system_wide;
 }
 
diff --git a/exec_cmd.c b/exec_cmd.c
index da04efe..8899e31 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -40,6 +40,16 @@ static const char *builtin_exec_path(void)
 #endif
 }
 
+const char *system_path(const char *path)
+{
+	if (!is_absolute_path(path)) {
+		struct strbuf d = STRBUF_INIT;
+		strbuf_addf(&d, "%s/%s", git_exec_path(), path);
+		path = strbuf_detach(&d, NULL);
+	}
+	return path;
+}
+
 void git_set_argv_exec_path(const char *exec_path)
 {
 	argv_exec_path = exec_path;
diff --git a/exec_cmd.h b/exec_cmd.h
index a892355..7eb94e5 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -6,6 +6,6 @@ extern const char* git_exec_path(void);
 extern void setup_path(const char *);
 extern int execv_git_cmd(const char **argv); /* NULL terminated */
 extern int execl_git_cmd(const char *cmd, ...);
-
+extern const char *system_path(const char *path);
 
 #endif /* GIT_EXEC_CMD_H */
-- 
1.5.6.2.300.ga3a9

[PATCH] help.c: Add support for htmldir relative to git_exec_path()

[Johannes Sixt]

From: Steffen Prohaska <prohaska@zib.de>

If htmldir (in the Makefile) is a relative path, this path will now be
interpreted relative to git_exec_path.  This can be used to create an
installation that can be moved to a different directory without
re-compiling.  The Windows installer (msysgit) is an example for such
a setup.

Note that the Makefile maps htmldir to the define GIT_HTML_PATH.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 help.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/help.c b/help.c
index ca9632b..0f055bf 100644
--- a/help.c
+++ b/help.c
@@ -633,13 +633,15 @@ static void show_info_page(const char *git_cmd)
 static void get_html_page_path(struct strbuf *page_path, const char *page)
 {
 	struct stat st;
+	const char *html_path = system_path(GIT_HTML_PATH);
 
 	/* Check that we have a git documentation directory. */
-	if (stat(GIT_HTML_PATH "/git.html", &st) || !S_ISREG(st.st_mode))
-		die("'%s': not a documentation directory.", GIT_HTML_PATH);
+	if (stat(mkpath("%s/git.html", html_path), &st)
+	    || !S_ISREG(st.st_mode))
+		die("'%s': not a documentation directory.", html_path);
 
 	strbuf_init(page_path, 0);
-	strbuf_addf(page_path, GIT_HTML_PATH "/%s.html", page);
+	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
 static void show_html_page(const char *git_cmd)
-- 
1.5.6.2.300.ga3a9

[PATCH] help (Windows): Display HTML in default browser using Windows' shell API

[Johannes Sixt]

From: Steffen Prohaska <prohaska@zib.de>

The system's default browser for displaying HTML help pages is now used
directly on Windows, instead of launching git-web--browser, which
requires a Unix shell.  Avoiding MSYS' bash when possible is good
because it avoids potential path translation issues.  In this case it is
not too hard to avoid launching a shell, so let's avoid it.

The Windows-specific code is implemented in compat/mingw.c to avoid
platform-specific code in the main code base.  On Windows, open_html is
provided as a define.  If open_html is not defined, git-web--browse is
used.  This approach avoids platform-specific ifdefs by using
per-function ifdefs.  The "ifndef open_html" together with the
introductory comment should sufficiently warn developers, so that they
hopefully will not break this mechanism.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 compat/mingw.c |   21 +++++++++++++++++++++
 compat/mingw.h |    3 +++
 help.c         |   14 +++++++++++++-
 3 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index 3a05fe7..0ca73f7 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler)
 	timer_fn = handler;
 	return old;
 }
+
+static const char *make_backslash_path(const char *path) {
+	static char buf[PATH_MAX + 1];
+	char *c;
+
+	if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+		die ("Too long path: %.*s", 60, path);
+
+	for (c = buf; *c; c++) {
+		if (*c == '/')
+			*c = '\\';
+	}
+	return buf;
+}
+
+void mingw_open_html(const char *unixpath)
+{
+	const char *htmlpath = make_backslash_path(unixpath);
+	printf("Launching default browser to display HTML ...\n");
+	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
+}
diff --git a/compat/mingw.h b/compat/mingw.h
index 6bc049a..5a3bcee 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -202,6 +202,9 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler);
 #define PATH_SEP ';'
 #define PRIuMAX "I64u"
 
+void mingw_open_html(const char *path);
+#define open_html mingw_open_html
+
 /*
  * helpers
  */
diff --git a/help.c b/help.c
index 0f055bf..52d39b8 100644
--- a/help.c
+++ b/help.c
@@ -644,6 +644,18 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
 	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
+/*
+ * If open_html is not defined in a platform-specific way (see for
+ * example compat/mingw.h), we use the script web--browse to display
+ * HTML.
+ */
+#ifndef open_html
+void open_html(const char *path)
+{
+	execl_git_cmd("web--browse", "-c", "help.browser", path, NULL);
+}
+#endif
+
 static void show_html_page(const char *git_cmd)
 {
 	const char *page = cmd_to_page(git_cmd);
@@ -651,7 +663,7 @@ static void show_html_page(const char *git_cmd)
 
 	get_html_page_path(&page_path, page);
 
-	execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL);
+	open_html(page_path.buf);
 }
 
 void help_unknown_cmd(const char *cmd)
-- 
1.5.6.2.300.ga3a9

[PATCH] Fix relative built-in paths to be relative to the command invocation

[Johannes Sixt]

$(gitexecdir) (as defined in the Makefile) has gained another path
component, but the relative paths in the MINGW section of the Makefile,
which are interpreted relative to it, do not account for it.

Instead of adding another ../ in front of the path, we change the code that
constructs the absolute paths to do it relative to the command's directory,
which is essentially $(bindir). We do it this way because we will also
allow a relative $(gitexecdir) later.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 Makefile       |    2 +-
 exec_cmd.c     |   14 ++++++++++----
 exec_cmd.h     |    3 ++-
 git.c          |    5 ++---
 receive-pack.c |    2 +-
 shell.c        |    4 ++--
 upload-pack.c  |    2 +-
 7 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/Makefile b/Makefile
index 4796565..2bdb9bf 100644
--- a/Makefile
+++ b/Makefile
@@ -1301,7 +1301,7 @@ remove-dashes:
 ### Installation rules
 
 ifeq ($(firstword $(subst /, ,$(template_dir))),..)
-template_instdir = $(gitexecdir)/$(template_dir)
+template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)
 else
 template_instdir = $(template_dir)
 endif
diff --git a/exec_cmd.c b/exec_cmd.c
index 8899e31..45f92eb 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -5,6 +5,7 @@
 
 extern char **environ;
 static const char *argv_exec_path;
+static const char *argv0_path;
 
 static const char *builtin_exec_path(void)
 {
@@ -42,14 +43,19 @@ static const char *builtin_exec_path(void)
 
 const char *system_path(const char *path)
 {
-	if (!is_absolute_path(path)) {
+	if (!is_absolute_path(path) && argv0_path) {
 		struct strbuf d = STRBUF_INIT;
-		strbuf_addf(&d, "%s/%s", git_exec_path(), path);
+		strbuf_addf(&d, "%s/%s", argv0_path, path);
 		path = strbuf_detach(&d, NULL);
 	}
 	return path;
 }
 
+void git_set_argv0_path(const char *path)
+{
+	argv0_path = path;
+}
+
 void git_set_argv_exec_path(const char *exec_path)
 {
 	argv_exec_path = exec_path;
@@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char *path)
 	}
 }
 
-void setup_path(const char *cmd_path)
+void setup_path(void)
 {
 	const char *old_path = getenv("PATH");
 	struct strbuf new_path;
@@ -94,7 +100,7 @@ void setup_path(const char *cmd_path)
 	add_path(&new_path, argv_exec_path);
 	add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
 	add_path(&new_path, builtin_exec_path());
-	add_path(&new_path, cmd_path);
+	add_path(&new_path, argv0_path);
 
 	if (old_path)
 		strbuf_addstr(&new_path, old_path);
diff --git a/exec_cmd.h b/exec_cmd.h
index 7eb94e5..0c46cd5 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -2,8 +2,9 @@
 #define GIT_EXEC_CMD_H
 
 extern void git_set_argv_exec_path(const char *exec_path);
+extern void git_set_argv0_path(const char *path);
 extern const char* git_exec_path(void);
-extern void setup_path(const char *);
+extern void setup_path(void);
 extern int execv_git_cmd(const char **argv); /* NULL terminated */
 extern int execl_git_cmd(const char *cmd, ...);
 extern const char *system_path(const char *path);
diff --git a/git.c b/git.c
index 7075533..b90c358 100644
--- a/git.c
+++ b/git.c
@@ -470,7 +470,6 @@ int main(int argc, const char **argv)
 {
 	const char *cmd = argv[0] && *argv[0] ? argv[0] : "git-help";
 	char *slash = (char *)cmd + strlen(cmd);
-	const char *cmd_path = NULL;
 	int done_alias = 0;
 
 	/*
@@ -483,7 +482,7 @@ int main(int argc, const char **argv)
 	while (cmd <= slash && !is_dir_sep(*slash));
 	if (cmd <= slash) {
 		*slash++ = 0;
-		cmd_path = cmd;
+		git_set_argv0_path(cmd);
 		cmd = slash;
 	}
 
@@ -527,7 +526,7 @@ int main(int argc, const char **argv)
 	 * environment, and the $(gitexecdir) from the Makefile at build
 	 * time.
 	 */
-	setup_path(cmd_path);
+	setup_path();
 
 	while (1) {
 		/* See if it's an internal command */
diff --git a/receive-pack.c b/receive-pack.c
index fa653b4..d44c19e 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -482,7 +482,7 @@ int main(int argc, char **argv)
 	if (!dir)
 		usage(receive_pack_usage);
 
-	setup_path(NULL);
+	setup_path();
 
 	if (!enter_repo(dir, 0))
 		die("'%s': unable to chdir or not a git archive", dir);
diff --git a/shell.c b/shell.c
index 91ca7de..6a48de0 100644
--- a/shell.c
+++ b/shell.c
@@ -15,7 +15,7 @@ static int do_generic_cmd(const char *me, char *arg)
 {
 	const char *my_argv[4];
 
-	setup_path(NULL);
+	setup_path();
 	if (!arg || !(arg = sq_dequote(arg)))
 		die("bad argument");
 	if (prefixcmp(me, "git-"))
@@ -37,7 +37,7 @@ static int do_cvs_cmd(const char *me, char *arg)
 	if (!arg || strcmp(arg, "server"))
 		die("git-cvsserver only handles server: %s", arg);
 
-	setup_path(NULL);
+	setup_path();
 	return execv_git_cmd(cvsserver_argv);
 }
 
diff --git a/upload-pack.c b/upload-pack.c
index 9f82941..c911e70 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -638,7 +638,7 @@ int main(int argc, char **argv)
 	if (i != argc-1)
 		usage(upload_pack_usage);
 
-	setup_path(NULL);
+	setup_path();
 
 	dir = argv[i];
 
-- 
1.5.6.2.300.ga3a9

[PATCH] Allow the built-in exec path to be relative to the command invocation path

[Johannes Sixt]

If GIT_EXEC_PATH (the macro that is defined in the Makefile) is relative,
it is interpreted relative to the command's invocation path, which usually
is $(bindir).

The Makefile rules were written with the assumption that $(gitexecdir) is
an absolute path. We introduce a separate variable that names the
(absolute) installation directory.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 Makefile   |   23 +++++++++++++++--------
 exec_cmd.c |   38 ++------------------------------------
 2 files changed, 17 insertions(+), 44 deletions(-)

diff --git a/Makefile b/Makefile
index 2bdb9bf..3593e6f 100644
--- a/Makefile
+++ b/Makefile
@@ -1307,10 +1307,17 @@ template_instdir = $(template_dir)
 endif
 export template_instdir
 
+ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
+gitexec_instdir = $(shell cd '$(bindir_SQ)/$(gitexecdir_SQ)' && pwd)
+else
+gitexec_instdir = $(gitexecdir)
+endif
+gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
+
 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) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
 	$(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'
 	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
 	$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
@@ -1318,18 +1325,18 @@ ifndef NO_TCLTK
 	$(MAKE) -C gitk-git install
 	$(MAKE) -C git-gui install
 endif
-	if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
+	if test 'z$(bindir_SQ)' != 'z$(gitexec_instdir_SQ)'; \
 	then \
 		ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
-			'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' || \
+			'$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' || \
 		cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
-			'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
+			'$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X'; \
 	fi
-	$(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
+	$(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' ;)
 ifneq (,$X)
-	$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
+	$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
 endif
-	./check_bindir 'z$(bindir_SQ)' 'z$(gitexecdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X'
+	./check_bindir 'z$(bindir_SQ)' 'z$(gitexec_instdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X'
 
 install-doc:
 	$(MAKE) -C Documentation install
diff --git a/exec_cmd.c b/exec_cmd.c
index 45f92eb..c236034 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -7,40 +7,6 @@ extern char **environ;
 static const char *argv_exec_path;
 static const char *argv0_path;
 
-static const char *builtin_exec_path(void)
-{
-#ifndef __MINGW32__
-	return GIT_EXEC_PATH;
-#else
-	int len;
-	char *p, *q, *sl;
-	static char *ep;
-	if (ep)
-		return ep;
-
-	len = strlen(_pgmptr);
-	if (len < 2)
-		return ep = ".";
-
-	p = ep = xmalloc(len+1);
-	q = _pgmptr;
-	sl = NULL;
-	/* copy program name, turn '\\' into '/', skip last part */
-	while ((*p = *q)) {
-		if (*q == '\\' || *q == '/') {
-			*p = '/';
-			sl = p;
-		}
-		p++, q++;
-	}
-	if (sl)
-		*sl = '\0';
-	else
-		ep[0] = '.', ep[1] = '\0';
-	return ep;
-#endif
-}
-
 const char *system_path(const char *path)
 {
 	if (!is_absolute_path(path) && argv0_path) {
@@ -75,7 +41,7 @@ const char *git_exec_path(void)
 		return env;
 	}
 
-	return builtin_exec_path();
+	return system_path(GIT_EXEC_PATH);
 }
 
 static void add_path(struct strbuf *out, const char *path)
@@ -99,7 +65,7 @@ void setup_path(void)
 
 	add_path(&new_path, argv_exec_path);
 	add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
-	add_path(&new_path, builtin_exec_path());
+	add_path(&new_path, system_path(GIT_EXEC_PATH));
 	add_path(&new_path, argv0_path);
 
 	if (old_path)
-- 
1.5.6.2.300.ga3a9

[PATCH] Allow add_path() to add non-existent directories to the path

[Johannes Sixt]

This function had used make_absolute_path(); but this function dies if
the directory that contains the entry whose relative path was supplied in
the argument does not exist. This is a problem if the argument is, for
example, "../libexec/git-core", and that "../libexec" does not exist.

Since the resolution of symbolic links is not required for elements in
PATH, we can fall back to using make_nonrelative_path(), which simply
prepends $PWD to the path.

We have to move make_nonrelative_path() alongside make_absolute_path() in
abspath.c so that git-shell can be linked. See 5b8e6f85f.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 abspath.c  |   36 ++++++++++++++++++++++++++++++++++++
 exec_cmd.c |    2 +-
 path.c     |   36 ------------------------------------
 3 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/abspath.c b/abspath.c
index 4f95a95..99ee1af 100644
--- a/abspath.c
+++ b/abspath.c
@@ -66,3 +66,39 @@ const char *make_absolute_path(const char *path)
 
 	return buf;
 }
+
+static const char *get_pwd_cwd(void)
+{
+	static char cwd[PATH_MAX + 1];
+	char *pwd;
+	struct stat cwd_stat, pwd_stat;
+	if (getcwd(cwd, PATH_MAX) == NULL)
+		return NULL;
+	pwd = getenv("PWD");
+	if (pwd && strcmp(pwd, cwd)) {
+		stat(cwd, &cwd_stat);
+		if (!stat(pwd, &pwd_stat) &&
+		    pwd_stat.st_dev == cwd_stat.st_dev &&
+		    pwd_stat.st_ino == cwd_stat.st_ino) {
+			strlcpy(cwd, pwd, PATH_MAX);
+		}
+	}
+	return cwd;
+}
+
+const char *make_nonrelative_path(const char *path)
+{
+	static char buf[PATH_MAX + 1];
+
+	if (is_absolute_path(path)) {
+		if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+			die ("Too long path: %.*s", 60, path);
+	} else {
+		const char *cwd = get_pwd_cwd();
+		if (!cwd)
+			die("Cannot determine the current working directory");
+		if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX)
+			die ("Too long path: %.*s", 60, path);
+	}
+	return buf;
+}
diff --git a/exec_cmd.c b/exec_cmd.c
index c236034..0ed768d 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -50,7 +50,7 @@ static void add_path(struct strbuf *out, const char *path)
 		if (is_absolute_path(path))
 			strbuf_addstr(out, path);
 		else
-			strbuf_addstr(out, make_absolute_path(path));
+			strbuf_addstr(out, make_nonrelative_path(path));
 
 		strbuf_addch(out, PATH_SEP);
 	}
diff --git a/path.c b/path.c
index 5983255..16c1d01 100644
--- a/path.c
+++ b/path.c
@@ -291,42 +291,6 @@ int adjust_shared_perm(const char *path)
 	return 0;
 }
 
-static const char *get_pwd_cwd(void)
-{
-	static char cwd[PATH_MAX + 1];
-	char *pwd;
-	struct stat cwd_stat, pwd_stat;
-	if (getcwd(cwd, PATH_MAX) == NULL)
-		return NULL;
-	pwd = getenv("PWD");
-	if (pwd && strcmp(pwd, cwd)) {
-		stat(cwd, &cwd_stat);
-		if (!stat(pwd, &pwd_stat) &&
-		    pwd_stat.st_dev == cwd_stat.st_dev &&
-		    pwd_stat.st_ino == cwd_stat.st_ino) {
-			strlcpy(cwd, pwd, PATH_MAX);
-		}
-	}
-	return cwd;
-}
-
-const char *make_nonrelative_path(const char *path)
-{
-	static char buf[PATH_MAX + 1];
-
-	if (is_absolute_path(path)) {
-		if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
-			die ("Too long path: %.*s", 60, path);
-	} else {
-		const char *cwd = get_pwd_cwd();
-		if (!cwd)
-			die("Cannot determine the current working directory");
-		if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX)
-			die ("Too long path: %.*s", 60, path);
-	}
-	return buf;
-}
-
 const char *make_relative_path(const char *abs, const char *base)
 {
 	static char buf[PATH_MAX + 1];
-- 
1.5.6.2.300.ga3a9

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

[Johannes Schindelin]

Hi,

On Sun, 13 Jul 2008, Johannes Sixt wrote:

> diff --git a/Makefile b/Makefile
> index 4796565..2bdb9bf 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1301,7 +1301,7 @@ remove-dashes:
>  ### Installation rules
>  
>  ifeq ($(firstword $(subst /, ,$(template_dir))),..)
> -template_instdir = $(gitexecdir)/$(template_dir)
> +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)

What is this for?  Did the original line stop working?

> diff --git a/exec_cmd.c b/exec_cmd.c
> index 8899e31..45f92eb 100644
> --- a/exec_cmd.c
> +++ b/exec_cmd.c
> @@ -5,6 +5,7 @@
>  
>  extern char **environ;
>  static const char *argv_exec_path;
> +static const char *argv0_path;
>  
>  static const char *builtin_exec_path(void)
>  {
> @@ -42,14 +43,19 @@ static const char *builtin_exec_path(void)
>  
>  const char *system_path(const char *path)
>  {
> -	if (!is_absolute_path(path)) {
> +	if (!is_absolute_path(path) && argv0_path) {
>  		struct strbuf d = STRBUF_INIT;
> -		strbuf_addf(&d, "%s/%s", git_exec_path(), path);
> +		strbuf_addf(&d, "%s/%s", argv0_path, path);
>  		path = strbuf_detach(&d, NULL);
>  	}
>  	return path;
>  }
>  
> +void git_set_argv0_path(const char *path)
> +{
> +	argv0_path = path;
> +}
> +
>  void git_set_argv_exec_path(const char *exec_path)
>  {
>  	argv_exec_path = exec_path;
> @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char *path)
>  	}
>  }
>  
> -void setup_path(const char *cmd_path)
> +void setup_path(void)

It seems to me that this patch would not do anything different, but with 
less code change, if setup_path() would set argv0_path, and not a new 
function was introduced.

Ciao,
Dscho

Re: [PATCH] Allow the built-in exec path to be relative to the command invocation path

[Johannes Schindelin]

Hi,

On Sun, 13 Jul 2008, Johannes Sixt wrote:

> [a patch series, with 3 patches from Steffen]

Wow.  I like this demonstration how a nice patch series looks like.

Ciao,
Dscho

What's cooking in git.git (topics)

[Junio C Hamano]

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

The topics list the commits in reverse chronological order.  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.

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

[Junio C Hamano]

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
 }
 

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

[Johannes Sixt]

Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:

> Hi,
>
> On Sun, 13 Jul 2008, Johannes Sixt wrote:
>
> > diff --git a/Makefile b/Makefile
> > index 4796565..2bdb9bf 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1301,7 +1301,7 @@ remove-dashes:
> >  ### Installation rules
> >
> >  ifeq ($(firstword $(subst /, ,$(template_dir))),..)
> > -template_instdir = $(gitexecdir)/$(template_dir)
> > +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)
>
> What is this for?  Did the original line stop working?

I could just have changed $(gitexecdir) to $(bindir), but in the
make-execpath-relative patch we will need the normalized gitexec_instdir
because its value is compared to $(bindir). So the extra $(shell...) in
_this_ patch is only that the final result looks consistent.

> > diff --git a/exec_cmd.c b/exec_cmd.c
> > index 8899e31..45f92eb 100644
> > --- a/exec_cmd.c
> > +++ b/exec_cmd.c
> > @@ -5,6 +5,7 @@
> >
> >  extern char **environ;
> >  static const char *argv_exec_path;
> > +static const char *argv0_path;
> >
> >  static const char *builtin_exec_path(void)
> >  {
> > @@ -42,14 +43,19 @@ static const char *builtin_exec_path(void)
> >
> >  const char *system_path(const char *path)
> >  {
> > -	if (!is_absolute_path(path)) {
> > +	if (!is_absolute_path(path) && argv0_path) {
> >  		struct strbuf d = STRBUF_INIT;
> > -		strbuf_addf(&d, "%s/%s", git_exec_path(), path);
> > +		strbuf_addf(&d, "%s/%s", argv0_path, path);
> >  		path = strbuf_detach(&d, NULL);
> >  	}
> >  	return path;
> >  }
> >
> > +void git_set_argv0_path(const char *path)
> > +{
> > +	argv0_path = path;
> > +}
> > +
> >  void git_set_argv_exec_path(const char *exec_path)
> >  {
> >  	argv_exec_path = exec_path;
> > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
> *path)
> >  	}
> >  }
> >
> > -void setup_path(const char *cmd_path)
> > +void setup_path(void)
>
> It seems to me that this patch would not do anything different, but with
> less code change, if setup_path() would set argv0_path, and not a new
> function was introduced.

This is just to play a safe game. I had it that way, but I decided to have
the call to the new git_set_argv0_path() early in git.c because the call
to setup_path() in git.c is very late, and it could happen that we call
system_path() (which needs argv0_path) before that. Although I didn't audit
the code whether this really happens.

-- Hannes

Re: [PATCH] Allow add_path() to add non-existent directories to the path

[Johannes Sixt]

Johannes Sixt schrieb:
> +static const char *get_pwd_cwd(void)
> +{
> +	static char cwd[PATH_MAX + 1];
> +	char *pwd;
> +	struct stat cwd_stat, pwd_stat;
> +	if (getcwd(cwd, PATH_MAX) == NULL)
> +		return NULL;
> +	pwd = getenv("PWD");
> +	if (pwd && strcmp(pwd, cwd)) {
> +		stat(cwd, &cwd_stat);
> +		if (!stat(pwd, &pwd_stat) &&
> +		    pwd_stat.st_dev == cwd_stat.st_dev &&
> +		    pwd_stat.st_ino == cwd_stat.st_ino) {
> +			strlcpy(cwd, pwd, PATH_MAX);

git-bash users on Windows, please test this patch. The problem is that
with our custom stat implementation st_dev and st_ino are not reliable. It
 works in my setup because $PWD is not set and this branch is never
entered, but with bash it makes a difference.

-- Hannes

Closing the merge window for 1.6.0

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> I think most of the important stuff is already in 'next'.  Let's start
> talking about closing the merge window for 1.6.0.

I think by the time we declare -rc0, we will have merged everything we
have in "Actively Cooking" list from tonight, perhaps except for the
"merge -Xtheirs", as there do not seem to be wide support for this
feature.  All the Windows bits and myriad of s/git-foo/git foo/ patches
submitted over the weekend and queued in next/pu, and various smallish
topics in "New Topics" list will hopefully all appear in 1.6.0.

In essence, I am saying that the merge window is more-or-less closed, from
the point of view of "what will be in, and what won't be"; of course some
of the topics may not be merged in their current shape without further
fixes.

The reason I say more-or-less is because I am aware of a handful of
patches that are not even in 'pu' yet:

 * A few patches from Mark Levedahl on git-submodule are still held in my
   inbox; I haven't decided what to do with them.

    Date: Wed,  9 Jul 2008 21:05:40 -0400
    Subject: [PATCH] git-submodule - make "submodule add" more strict, and document it
    Message-Id: <1215651941-3460-1-git-send-email-mlevedahl@gmail.com>

    Date: Wed,  9 Jul 2008 21:05:41 -0400
    Subject: [PATCH] git-submodule - register submodule URL if adding in place
    Message-ID: <1215651941-3460-2-git-send-email-mlevedahl@gmail.com>

   These two appeared at the end of a discussion, and as far as I can see,
   there wasn't any objection to them.  Unless somebody makes a convincing
   argument against them, I am inclined to include them in 1.6.0

 * Starting bisect with a forked good and bad pair, from Christian Couder,
   is not queued yet.  I think it is just the matter of Christian
   resending the two patches squashed (or me applying them while squashing
   them myself) --- I was busy cutting 1.5.6.3 release and tending other
   topics, and haven't got around to do so.

    Date: Thu, 10 Jul 2008 05:41:52 +0200
    Subject: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev
    Message-Id: <20080710054152.b051989c.chriscool@tuxfamily.org>

 * Alice and Bob prompt in tutorial, from Ian Katz, is not queued; they
   should be safe to directly apply to 'master'.  The only reason why I
   haven't is because it takes a lot of time to generate and concentration
   to eyeball the documentation markups to catch mistakes.

    Date: Thu, 10 Jul 2008 14:27:30 -0400
    Subject: Re: [PATCH] tutorial: prefix the prompts with names alice or bob,
	to make it clear who is doing what
    Message-ID: <dc5b80bf0807101127q63e3132fw207baf0d88db3d9d@mail.gmail.com>

    Subject: [PATCH] tutorial: clarify "pull" is "fetch + merge"
    Date: Thu, 10 Jul 2008 14:01:57 -0700
    Message-ID: <7vskuho3lm.fsf_-_@gitster.siamese.dyndns.org>

 * A git-svn patch from João Abecasis; I am waiting for Eric to act on it.

    Subject: [PATCH] git-svn: find-rev and rebase for SVN::Mirror repositories
    Date: Wed, 9 Jul 2008 03:08:27 +0100
    Message-ID: <7bf6f1d20807081908kdf9f615taa532ae579b457d7@mail.gmail.com>


Here is the draft release notes as of tonight.

----------------------------------------------------------------

GIT v1.6.0 Release Notes (draft)
================================

User visible changes
--------------------

With the default Makefile settings, most of the programs are now
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 is still supported in this
release, 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.

Source changes needed for porting to MinGW environment are now all in the
main git.git codebase.

By default, packfiles created with this version uses delta-base-offset
encoding introduced in v1.4.4.  Pack idx files are using version 2 that
allows larger packs and added robustness thanks to its CRC checking,
introduced in v1.5.2.

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.

An ancient merge strategy "stupid" has been removed.


Updates since v1.5.6
--------------------

(subsystems)

* git-p4 in contrib learned "allowSubmit" configuration to control on
  which branch to allow "submit" subcommand.

* git-gui learned to stage changes per-line.

(portability)

* Changes for MinGW port have been merged, thanks to Johannes Sixt and
  gangs.

* Sample hook scripts shipped in templates/ are now suffixed with
  *.sample.  We used to prevent them from triggering by default by
  relying on the fact that we install them as unexecutable, but on
  some filesystems this approach does not work.  Instead of running
  "chmod +x" on them, the users who want to activate these samples
  as-is can now rename them dropping *.sample suffix.

* perl's in-place edit (-i) does not work well without backup files on Windows;
  some tests are rewritten to cope with this.

(documentation)

* Updated howto/update-hook-example

* Got rid of usage of "git-foo" from the tutorial and made typography
  more consistent.

* Disambiguating "--" between revs and paths is finally documented.

(performance, robustness, sanity etc.)

* even more documentation pages are now accessible via "man" and "git help".

* reduced excessive inlining to shrink size of the "git" binary.

* verify-pack checks the object CRC when using version 2 idx files.

* When an object is corrupt in a pack, the object became unusable even
  when the same object is available in a loose form,  We now try harder to
  fall back to these redundant objects when able.  In particular, "git
  repack -a -f" can be used to fix such a corruption as long as necessary
  objects are available.

* git-clone does not create refs in loose form anymore (it behaves as
  if you immediately ran git-pack-refs after cloning).  This will help
  repositories with insanely large number of refs.

* core.fsyncobjectfiles configuration can be used to ensure that the loose
  objects created will be fsync'ed (this is only useful on filesystems
  that does not order data writes properly).

* "git commit-tree" plumbing can make Octopus with more than 16 parents.
  "git commit" has been capable of this for quite some time.

(usability, bells and whistles)

* A new environment variable GIT_CEILING_DIRECTORIES can be used to stop
  the discovery process of the toplevel of working tree; this may be useful
  when you are working in a slow network disk and are outside any working tree,
  as bash-completion and "git help" may still need to run in these places.

* By default, stash entries never expire.  Set reflogexpire in [gc
  "refs/stash"] to a reasonable value to get traditional auto-expiration
  behaviour back

* Longstanding latency issue with bash completion script has been
  addressed.  This will need to be backmerged to 'maint' later.

* pager.<cmd> configuration variable can be used to enable/disable the
  default paging behaviour per command.

* "git-add -i" has a new action 'e/dit' to allow you edit the patch hunk
  manually.

* git-apply can handle a patch that touches the same path more than once
  much better than before.

* git-apply can be told not to trust the line counts recorded in the input
  patch but recount, with the new --recount option.

* git-apply can be told to apply a patch to a path deeper than what the
  patch records with --directory option.

* git-archive can be told to omit certain paths from its output using
  export-ignore attributes.

* With -v option, git-branch describes the remote tracking statistics
  similar to the way git-checkout reports by how many commits your branch
  is ahead/behind.

* git-bundle can read the revision arguments from the standard input.

* git-cherry-pick can replay a root commit now.

* git-clone can clone from a remote whose URL would be rewritten by
  configuration stored in $HOME/.gitconfig now.

* git-diff --check now checks leftover merge conflict markers.

* When remote side used to have branch 'foo' and git-fetch finds that now
  it has branch 'foo/bar', it refuses to lose the existing remote tracking
  branch and its reflog.  The error message has been improved to suggest
  pruning the remote if the user wants to proceed and get the latest set
  of branches from the remote, including such 'foo/bar'.

* fast-export learned to export and import marks file; this can be used to
  interface with fast-import incrementally.

* "git rerere" can be told to update the index with auto-reused resolution
  with rerere.autoupdate configuration variable.

* git-rev-list learned --children option to show child commits it
  encountered during the traversal, instead of shoing parent commits.

* git-send-mail can talk not just over SSL but over TLS now.

* "git-stash save" learned --keep-index option.  This lets you stash away the
  local changes and bring the changes staged in the index to your working
  tree for examination and testing.

* git-stash also learned branch subcommand to create a new branch out of
  stashed changes.

* git-status gives the remote tracking statistics similar to the way
  git-checkout reports by how many commits your branch is ahead/behind.

* You can tell "git status -u" to even more aggressively omit checking
  untracked files with --untracked-files=no.

* Original SHA-1 value for "update-ref -d" is optional now.

* Error codes from gitweb are made more descriptive where possible, rather
  than "403 forbidden" as we used to issue everywhere.

(internal)


Fixes since v1.5.6
------------------

All of the fixes in v1.5.6 maintenance series are included in
this release, unless otherwise noted.

 * "git fetch" into an empty repository used to remind the fetch will
   be huge by saying "no common commits", but it is already known by
   the user anyway (need to backport 8cb560f to 'maint').

---
exec >/var/tmp/1
O=v1.5.6.3-315-g10ce020
echo O=$(git describe refs/heads/master)
git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint

Re: Closing the merge window for 1.6.0

[Johannes Sixt]

Junio C Hamano schrieb:
> * git-gui learned to stage changes per-line.

This has usability issues. In particular, it is impossible to stage only
the change "old1"->"new1" or unstage the change "old2"->"new2" of this hunk:

	@@ -1,4 +1,4 @@
	 ctxt1
	-old1
	-old2
	+new1
	+new2
	 ctxt2

Being able to do that was one of the goals, and I missed it :-( Since
that's my personal itch, I'll come up with a patch rather sooner than later.

-- Hannes

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

[Johannes Sixt]

Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:

> Hi,
>
> On Sun, 13 Jul 2008, Johannes Sixt wrote:
>
> > diff --git a/Makefile b/Makefile
> > index 4796565..2bdb9bf 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1301,7 +1301,7 @@ remove-dashes:
> >  ### Installation rules
> >
> >  ifeq ($(firstword $(subst /, ,$(template_dir))),..)
> > -template_instdir = $(gitexecdir)/$(template_dir)
> > +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)
>
> What is this for?  Did the original line stop working?

Hmpf! This new line doesn't work in the intended way if the installation
destination does not exist. I'll have to find a better solution...

-- Hannes

Re: Closing the merge window for 1.6.0

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:


> GIT v1.6.0 Release Notes (draft)
> ================================

> * By default, stash entries never expire.  Set reflogexpire in [gc
>   "refs/stash"] to a reasonable value to get traditional auto-expiration
>   behaviour back

And, of course, one can set up reflog expiration per ref or per 
ref type (for example never expiring stash, making expiration for
HEAD longer than default, and for remote-tracking branches shorter).
 

> * git-stash also learned branch subcommand to create a new branch out of
>   stashed changes.

Typography: wouldn't it be better to use "learned 'branch' subcommand"?
 
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Closing the merge window for 1.6.0

[Petr Baudis]

On Mon, Jul 14, 2008 at 12:50:48AM -0700, Junio C Hamano wrote:
> By default, packfiles created with this version uses delta-base-offset
> encoding introduced in v1.4.4.  Pack idx files are using version 2 that
> allows larger packs and added robustness thanks to its CRC checking,
> introduced in v1.5.2.

Oh, I thought this was some earlier change when I noticed it few days
ago on repo.or.cz, but seems there is still a chance to turn this over -
please reconsider...? :-)

Can't we by default use the version 2 only in case we actually _need_ to
store the larger packs? The CRC checking may be nice, but not critical,
and we could wait a bit more with it yet.

I'm saying this because I believe the best conservative upper bound for
backwards compatibility is Git version in Debian stable. It gets
probably the most stale from all the widely used software distributions
using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
fails miserably on the new packs:

Getting alternates list for http://repo.or.cz/r/repo.git/
Getting pack list for http://repo.or.cz/r/repo.git/
Getting index for pack 5111285cac0f895cd9367c9939ced68e2c43dcc0
error: non-monotonic index
/usr/bin/git-fetch: line 297: 30402 Segmentation fault git-http-fetch -v -a "$head" "$remote/"

P.S.: AFAIK new Debian stable release is scheduled on Fall.

-- 
				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

Re: What's cooking in git.git (topics)

[Johannes Schindelin]

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

Re: Closing the merge window for 1.6.0

[Johannes Schindelin]

Hi,

On Mon, 14 Jul 2008, Petr Baudis wrote:

> I'm saying this because I believe the best conservative upper bound for 
> backwards compatibility is Git version in Debian stable. It gets 
> probably the most stale from all the widely used software distributions 
> using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> fails miserably on the new packs.

Can't we just hit Debian's Git maintainer with a clue bat or a bus, 
whichever is easier, and force them to upgrade _in_ Etch?  It's not like 
we haven't had _several_ stable releases in-between.

Ciao,
Dscho

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

[Johannes Schindelin]

Hi,

On Mon, 14 Jul 2008, Johannes Sixt wrote:

> Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> 
> > On Sun, 13 Jul 2008, Johannes Sixt wrote:
> >
> > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
> > > *path)
> > >  	}
> > >  }
> > >
> > > -void setup_path(const char *cmd_path)
> > > +void setup_path(void)
> >
> > It seems to me that this patch would not do anything different, but 
> > with less code change, if setup_path() would set argv0_path, and not a 
> > new function was introduced.
> 
> This is just to play a safe game. I had it that way, but I decided to have
> the call to the new git_set_argv0_path() early in git.c because the call
> to setup_path() in git.c is very late, and it could happen that we call
> system_path() (which needs argv0_path) before that. Although I didn't audit
> the code whether this really happens.

Well, okay... I would have rather seen it not change (since there was no 
bug to fix), or as a separate patch, but it's Junio's call.

Ciao,
Dscho

Re: Closing the merge window for 1.6.0

[Gerrit Pape]

On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> On Mon, 14 Jul 2008, Petr Baudis wrote:
> > I'm saying this because I believe the best conservative upper bound for 
> > backwards compatibility is Git version in Debian stable. It gets 
> > probably the most stale from all the widely used software distributions 
> > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> > fails miserably on the new packs.
> 
> Can't we just hit Debian's Git maintainer with a clue bat or a bus, 

Please don't.  It wouldn't help, rather the opposite I think, espacially
the bus.  We don't introduce new upstream versions into a Debian stable
release, there's a great effort done for each stable release to reach
high quality integration of all the software packages available in
Debian.  Once that status is reached, only security fixes and criticial
usability fixes are added.

The freeze of the packages for the next stable release is planned a few
days from now, so it looks like Debian 'lenny' will include git 1.5.6.x.

Regards, Gerrit.

Re: Closing the merge window for 1.6.0

[Petr Baudis]

  Hi,

On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> On Mon, 14 Jul 2008, Petr Baudis wrote:
> 
> > I'm saying this because I believe the best conservative upper bound for 
> > backwards compatibility is Git version in Debian stable. It gets 
> > probably the most stale from all the widely used software distributions 
> > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> > fails miserably on the new packs.
> 
> Can't we just hit Debian's Git maintainer with a clue bat or a bus, 
> whichever is easier, and force them to upgrade _in_ Etch?  It's not like 
> we haven't had _several_ stable releases in-between.

  the whole point of having a stable distribution is that random version
upgrades don't happen under your hands; sure, 1.4.4.4 can have plenty of
bugs, but it's buggy in a well-defined way, which is better than upgrade
to newer stable version, which may be less buggy, but in a different
way; also, by upgrading to newer version you might find various subtle
compatibility issues, etc.

  Upgrading to newer version, *especially* if it's over then 1.4 - 1.5
boundary, is not something you could seriously expect Debian to do.
At least I actually _hope_ so, as a sysadmin of a network of 40 etch
workstations.

-- 
				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

Re: Closing the merge window for 1.6.0

[Johannes Schindelin]

Hi,

On Mon, 14 Jul 2008, Gerrit Pape wrote:

> On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> > On Mon, 14 Jul 2008, Petr Baudis wrote:
> > > I'm saying this because I believe the best conservative upper bound for 
> > > backwards compatibility is Git version in Debian stable. It gets 
> > > probably the most stale from all the widely used software distributions 
> > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> > > fails miserably on the new packs.
> > 
> > Can't we just hit Debian's Git maintainer with a clue bat or a bus, 
> 
> Please don't.  It wouldn't help, rather the opposite I think, espacially
> the bus.

Heh.  It was a feeble attempt at humor production ;-)

> We don't introduce new upstream versions into a Debian stable release, 
> there's a great effort done for each stable release to reach high 
> quality integration of all the software packages available in Debian.  
> Once that status is reached, only security fixes and criticial usability 
> fixes are added.

If that is the case, we might need to think about fixing that segmentation 
fault to 1.4.4.5...  Which would be a minor pain in the donkey, I guess.

> The freeze of the packages for the next stable release is planned a few 
> days from now, so it looks like Debian 'lenny' will include git 1.5.6.x.

>From my memories of IRC, it seems that quite a few people do not even 
consider upgrading.

Ciao,
Dscho

Re: Closing the merge window for 1.6.0

[Nicolas Pitre]

On Mon, 14 Jul 2008, Gerrit Pape wrote:

> On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> > On Mon, 14 Jul 2008, Petr Baudis wrote:
> > > I'm saying this because I believe the best conservative upper bound for 
> > > backwards compatibility is Git version in Debian stable. It gets 
> > > probably the most stale from all the widely used software distributions 
> > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> > > fails miserably on the new packs.
> > 
> > Can't we just hit Debian's Git maintainer with a clue bat or a bus, 
> 
> Please don't.  It wouldn't help, rather the opposite I think, espacially
> the bus.  We don't introduce new upstream versions into a Debian stable
> release, there's a great effort done for each stable release to reach
> high quality integration of all the software packages available in
> Debian.  Once that status is reached, only security fixes and criticial
> usability fixes are added.

Please consider it as a critical usability problem.

Maybe we can release 1.4.5 with the ability to read index v2?  That 
wouldn't be hard to backport the reading part of it.


Nicolas

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

[Johannes Sixt]

On Montag, 14. Juli 2008, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 14 Jul 2008, Johannes Sixt wrote:
> > Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > > On Sun, 13 Jul 2008, Johannes Sixt wrote:
> > > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
> > > > *path)
> > > >  	}
> > > >  }
> > > >
> > > > -void setup_path(const char *cmd_path)
> > > > +void setup_path(void)
> > >
> > > It seems to me that this patch would not do anything different, but
> > > with less code change, if setup_path() would set argv0_path, and not a
> > > new function was introduced.
> >
> > This is just to play a safe game. I had it that way, but I decided to
> > have the call to the new git_set_argv0_path() early in git.c because the
> > call to setup_path() in git.c is very late, and it could happen that we
> > call system_path() (which needs argv0_path) before that. Although I
> > didn't audit the code whether this really happens.
>
> Well, okay... I would have rather seen it not change (since there was no
> bug to fix), or as a separate patch, but it's Junio's call.

I investigated this, and, yes, there indeed are calls to system_path() before 
setup_path(), for example:

 commit_pager_choice
   setup_pager
     git_config
       git_etc_gitconfig
         system_path(ETC_GITCONFIG)

Junio, do you want git_set_argv0_path() in a separate patch?

-- Hannes

Re: Closing the merge window for 1.6.0

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Mon, 14 Jul 2008, Gerrit Pape wrote:
>
>> On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
>> > On Mon, 14 Jul 2008, Petr Baudis wrote:
>> > > I'm saying this because I believe the best conservative upper bound for 
>> > > backwards compatibility is Git version in Debian stable. It gets 
>> > > probably the most stale from all the widely used software distributions 
>> > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
>> > > fails miserably on the new packs.
>> > 
>> > Can't we just hit Debian's Git maintainer with a clue bat or a bus, 
>> 
>> Please don't.  It wouldn't help, rather the opposite I think, espacially
>> the bus.  We don't introduce new upstream versions into a Debian stable
>> release, there's a great effort done for each stable release to reach
>> high quality integration of all the software packages available in
>> Debian.  Once that status is reached, only security fixes and criticial
>> usability fixes are added.
>
> Please consider it as a critical usability problem.
>
> Maybe we can release 1.4.5 with the ability to read index v2?  That 
> wouldn't be hard to backport the reading part of it.

I am of two minds here.

On one hand, I am sympathetic to distros that want to give long time
support for ancient versions to keep working in an ever-changing new
world.  It is a wonderful thing that there are distros that aim for ultra
conservative stability, and I applaud them.

But as the upstream, we have our own deprecation schedule.  We should of
course plan carefully not to harm existing users of our releases, but
frankly speaking, 18 months since 1.4.4.4 was tagged (early January 2007)
is an eternity in git timescale.  Maybe we will slow down someday, and
this 18-month is not a set-in-stone rule in any way, but at this point
even without the packfile format issues, I personally think anything
before 1.5.0 is irrelevant --- maybe they are interesting as historical
curiosities, but not more than that.

We could:

	$ git checkout -b maint-1.4 v1.4.4.4
        $ git merge maint
        $ git tag v1.4.4.5

and push the result out.  While I would imagine that the end-user
experience after such a maintenance release would be very positive, that
is not something distros who really want to stay with a stale version for
a good reason would want to swallow ;-).

If we _were_ to keep v1.4.4.X series alive, serious backporting efforts
will be necessary.  For example, recent 'git-shell' futureproofing was
made not just to 1.5.6.X series but was backported to 1.5.4.X and 1.5.5.X,
and we would probably need to give it to 1.4.4.X as well.  What other
things are there that are missing in 1.4.4.X?  It would take nontrivial
engineering resource to even list them, let alone assessing how much
effort is required for such backporting and actually doing it.

The remotes/ layout, use of "git-add" for new contents (instead of only
new files), reflogs, detached HEAD, --pretty=format:%<blah>, bundles,
mergetool,...  all the things that a modern git workflow revolves around
and are described in the user manuals the users find on the net are not
found in 1.4.4.X series.  If a user of such a conservative distro needs to
work with a repository prepared on another platform with newer git,
perhaps crossmounted, should we backport "git branch -r" so that the user
can confortably work with remote tracking branches?  Should we backport
reflogs?

If a distro chooses to support its users whom they force to pin at 1.4.4.X
series, it's primarily _their_ choice.  I do not mind helping them in such
a backport, but the request has to come from the distro first with a
specific list of items that need to be supported.

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

[Junio C Hamano]

Johannes Sixt <johannes.sixt@telecom.at> writes:

> On Montag, 14. Juli 2008, Johannes Schindelin wrote:
>> Hi,
>>
>> On Mon, 14 Jul 2008, Johannes Sixt wrote:
>> > Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> > > On Sun, 13 Jul 2008, Johannes Sixt wrote:
>> > > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
>> > > > *path)
>> > > >  	}
>> > > >  }
>> > > >
>> > > > -void setup_path(const char *cmd_path)
>> > > > +void setup_path(void)
>> > >
>> > > It seems to me that this patch would not do anything different, but
>> > > with less code change, if setup_path() would set argv0_path, and not a
>> > > new function was introduced.
>> >
>> > This is just to play a safe game. I had it that way, but I decided to
>> > have the call to the new git_set_argv0_path() early in git.c because the
>> > call to setup_path() in git.c is very late, and it could happen that we
>> > call system_path() (which needs argv0_path) before that. Although I
>> > didn't audit the code whether this really happens.
>>
>> Well, okay... I would have rather seen it not change (since there was no
>> bug to fix), or as a separate patch, but it's Junio's call.
>
> I investigated this, and, yes, there indeed are calls to system_path() before 
> setup_path(), for example:
>
>  commit_pager_choice
>    setup_pager
>      git_config
>        git_etc_gitconfig
>          system_path(ETC_GITCONFIG)
>
> Junio, do you want git_set_argv0_path() in a separate patch?

I think that would be easier to explain in the commit log what is going
on, if it is a separate patch.

Re: Closing the merge window for 1.6.0

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Getting alternates list for http://repo.or.cz/r/repo.git/
> Getting pack list for http://repo.or.cz/r/repo.git/
> Getting index for pack 5111285cac0f895cd9367c9939ced68e2c43dcc0
> error: non-monotonic index
> /usr/bin/git-fetch: line 297: 30402 Segmentation fault git-http-fetch -v -a "$head" "$remote/"

Yeah, I think git-repack, git-gc, git-pack-objects and git-index-pack on
the server side need a knob to tell it to stay conservative because the
repository may be served over dumb protocols to avoid this problem.

That knob could even be called

	[repack]
        	usedeltabaseoffset = false
	[pack]
        	indexversion = 1

Re: Closing the merge window for 1.6.0

[Teemu Likonen]

Junio C Hamano wrote (2008-07-14 12:00 -0700):

> Nicolas Pitre <nico@cam.org> writes:
> 
> > On Mon, 14 Jul 2008, Gerrit Pape wrote:

> >> > On Mon, 14 Jul 2008, Petr Baudis wrote:
> >> > > I'm saying this because I believe the best conservative upper
> >> > > bound for backwards compatibility is Git version in Debian
> >> > > stable. It gets 

> > Please consider it as a critical usability problem.
> >
> > Maybe we can release 1.4.5 with the ability to read index v2?  That
> > wouldn't be hard to backport the reading part of it.

> I am of two minds here.
> 
> On one hand, I am sympathetic to distros that want to give long time
> support for ancient versions to keep working in an ever-changing new
> world.  It is a wonderful thing that there are distros that aim for
> ultra conservative stability, and I applaud them.
> 
> But as the upstream, we have our own deprecation schedule.

As Debian stable (4.0 "Etch") and its git 1.4.4.4 was mentioned I'd like
to point out that git 1.5.6 is available for Etch users from
kind-of-semi-official <www.backports.org>. So I guess Debian stable
users aren't left completely behind. Git's web page already advertises
backports.org version for Etch.

[PATCH 0/5] replacement for the part of js/more-win that is in pu

[Johannes Sixt]

The interdiff to js/more-win is below. It is mostly the changes
of 1/5.

Johannes Sixt (5):
      Makefile: Normalize $(bindir) and $(gitexecdir) before comparing
      Record the command invocation path early
      Fix relative built-in paths to be relative to the command
         invocation
      Allow the built-in exec path to be relative to the command
         invocation path
      Allow add_path() to add non-existent directories to the path


 Makefile       |   33 +++++++++++++++++-----------
 abspath.c      |   36 ++++++++++++++++++++++++++++++
 exec_cmd.c     |   54 +++++++++++----------------------------------
 exec_cmd.h     |    3 +-
 git.c          |    5 +--
 path.c         |   36 ------------------------------
 receive-pack.c |    2 +-
 shell.c        |    4 +-
 upload-pack.c  |    2 +-
 9 files changed, 77 insertions(+), 98 deletions(-)


diff --git a/Makefile b/Makefile
index 3593e6f..4df6423 100644
--- a/Makefile
+++ b/Makefile
@@ -1301,14 +1301,14 @@ remove-dashes:
 ### Installation rules
 
 ifeq ($(firstword $(subst /, ,$(template_dir))),..)
-template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)
+template_instdir = $(bindir)/$(template_dir)
 else
 template_instdir = $(template_dir)
 endif
 export template_instdir
 
 ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
-gitexec_instdir = $(shell cd '$(bindir_SQ)/$(gitexecdir_SQ)' && pwd)
+gitexec_instdir = $(bindir)/$(gitexecdir)
 else
 gitexec_instdir = $(gitexecdir)
 endif
@@ -1325,18 +1325,18 @@ ifndef NO_TCLTK
 	$(MAKE) -C gitk-git install
 	$(MAKE) -C git-gui install
 endif
-	if test 'z$(bindir_SQ)' != 'z$(gitexec_instdir_SQ)'; \
-	then \
-		ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
-			'$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' || \
-		cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
-			'$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X'; \
-	fi
-	$(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' ;)
 ifneq (,$X)
 	$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
 endif
-	./check_bindir 'z$(bindir_SQ)' 'z$(gitexec_instdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X'
+	bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
+	execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \
+	if test "z$$bindir" != "z$$execdir"; \
+	then \
+		ln -f "$$bindir/git$X" "$$execdir/git$X" || \
+		cp "$$bindir/git$X" "$$execdir/git$X"; \
+	fi && \
+	{ $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
+	./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-shell$X"
 
 install-doc:
 	$(MAKE) -C Documentation install

[PATCH 1/5] Makefile: Normalize $(bindir) and $(gitexecdir) before comparing

[Johannes Sixt]

The install target needs to check whether the user has opted to make
$(gitexecdir) equal to $(bindir). It did so by a straight string
comparison. Since we are going to allow a relative $(gitexecdir), we have
to normalize paths before comparison, which we do with $(cd there && pwd).

The normalized paths are stored in shell variables. These we can now
reuse in the subsequent install statements, which conveniently shortens
the lines a bit.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 Makefile |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Makefile b/Makefile
index 4796565..4de9271 100644
--- a/Makefile
+++ b/Makefile
@@ -1318,18 +1318,18 @@ ifndef NO_TCLTK
 	$(MAKE) -C gitk-git install
 	$(MAKE) -C git-gui install
 endif
-	if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
-	then \
-		ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
-			'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' || \
-		cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
-			'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
-	fi
-	$(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
 ifneq (,$X)
 	$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
 endif
-	./check_bindir 'z$(bindir_SQ)' 'z$(gitexecdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X'
+	bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
+	execdir=$$(cd '$(DESTDIR_SQ)$(gitexecdir_SQ)' && pwd) && \
+	if test "z$$bindir" != "z$$execdir"; \
+	then \
+		ln -f "$$bindir/git$X" "$$execdir/git$X" || \
+		cp "$$bindir/git$X" "$$execdir/git$X"; \
+	fi && \
+	{ $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
+	./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-shell$X"
 
 install-doc:
 	$(MAKE) -C Documentation install
-- 
1.5.6.3.323.g1e58

[PATCH 2/5] Record the command invocation path early

[Johannes Sixt]

We will need the command invocation path in system_path(). This path was
passed to setup_path(), but  system_path() can be called earlier, for
example via:

    main
      commit_pager_choice
        setup_pager
          git_config
            git_etc_gitconfig
              system_path

Therefore, we introduce git_set_argv0_path() and call it as soon as
possible.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 exec_cmd.c     |   10 ++++++++--
 exec_cmd.h     |    3 ++-
 git.c          |    5 ++---
 receive-pack.c |    2 +-
 shell.c        |    4 ++--
 upload-pack.c  |    2 +-
 6 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/exec_cmd.c b/exec_cmd.c
index 8899e31..dedb01d 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -5,6 +5,7 @@
 
 extern char **environ;
 static const char *argv_exec_path;
+static const char *argv0_path;
 
 static const char *builtin_exec_path(void)
 {
@@ -50,6 +51,11 @@ const char *system_path(const char *path)
 	return path;
 }
 
+void git_set_argv0_path(const char *path)
+{
+	argv0_path = path;
+}
+
 void git_set_argv_exec_path(const char *exec_path)
 {
 	argv_exec_path = exec_path;
@@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char *path)
 	}
 }
 
-void setup_path(const char *cmd_path)
+void setup_path(void)
 {
 	const char *old_path = getenv("PATH");
 	struct strbuf new_path;
@@ -94,7 +100,7 @@ void setup_path(const char *cmd_path)
 	add_path(&new_path, argv_exec_path);
 	add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
 	add_path(&new_path, builtin_exec_path());
-	add_path(&new_path, cmd_path);
+	add_path(&new_path, argv0_path);
 
 	if (old_path)
 		strbuf_addstr(&new_path, old_path);
diff --git a/exec_cmd.h b/exec_cmd.h
index 7eb94e5..0c46cd5 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -2,8 +2,9 @@
 #define GIT_EXEC_CMD_H
 
 extern void git_set_argv_exec_path(const char *exec_path);
+extern void git_set_argv0_path(const char *path);
 extern const char* git_exec_path(void);
-extern void setup_path(const char *);
+extern void setup_path(void);
 extern int execv_git_cmd(const char **argv); /* NULL terminated */
 extern int execl_git_cmd(const char *cmd, ...);
 extern const char *system_path(const char *path);
diff --git a/git.c b/git.c
index 7075533..b90c358 100644
--- a/git.c
+++ b/git.c
@@ -470,7 +470,6 @@ int main(int argc, const char **argv)
 {
 	const char *cmd = argv[0] && *argv[0] ? argv[0] : "git-help";
 	char *slash = (char *)cmd + strlen(cmd);
-	const char *cmd_path = NULL;
 	int done_alias = 0;
 
 	/*
@@ -483,7 +482,7 @@ int main(int argc, const char **argv)
 	while (cmd <= slash && !is_dir_sep(*slash));
 	if (cmd <= slash) {
 		*slash++ = 0;
-		cmd_path = cmd;
+		git_set_argv0_path(cmd);
 		cmd = slash;
 	}
 
@@ -527,7 +526,7 @@ int main(int argc, const char **argv)
 	 * environment, and the $(gitexecdir) from the Makefile at build
 	 * time.
 	 */
-	setup_path(cmd_path);
+	setup_path();
 
 	while (1) {
 		/* See if it's an internal command */
diff --git a/receive-pack.c b/receive-pack.c
index fa653b4..d44c19e 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -482,7 +482,7 @@ int main(int argc, char **argv)
 	if (!dir)
 		usage(receive_pack_usage);
 
-	setup_path(NULL);
+	setup_path();
 
 	if (!enter_repo(dir, 0))
 		die("'%s': unable to chdir or not a git archive", dir);
diff --git a/shell.c b/shell.c
index 91ca7de..6a48de0 100644
--- a/shell.c
+++ b/shell.c
@@ -15,7 +15,7 @@ static int do_generic_cmd(const char *me, char *arg)
 {
 	const char *my_argv[4];
 
-	setup_path(NULL);
+	setup_path();
 	if (!arg || !(arg = sq_dequote(arg)))
 		die("bad argument");
 	if (prefixcmp(me, "git-"))
@@ -37,7 +37,7 @@ static int do_cvs_cmd(const char *me, char *arg)
 	if (!arg || strcmp(arg, "server"))
 		die("git-cvsserver only handles server: %s", arg);
 
-	setup_path(NULL);
+	setup_path();
 	return execv_git_cmd(cvsserver_argv);
 }
 
diff --git a/upload-pack.c b/upload-pack.c
index 9f82941..c911e70 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -638,7 +638,7 @@ int main(int argc, char **argv)
 	if (i != argc-1)
 		usage(upload_pack_usage);
 
-	setup_path(NULL);
+	setup_path();
 
 	dir = argv[i];
 
-- 
1.5.6.3.323.g1e58

[PATCH 3/5] Fix relative built-in paths to be relative to the command invocation

[Johannes Sixt]

$(gitexecdir) (as defined in the Makefile) has gained another path
component, but the relative paths in the MINGW section of the Makefile,
which are interpreted relative to it, do not account for it.

Instead of adding another ../ in front of the path, we change the code that
constructs the absolute paths to do it relative to the command's directory,
which is essentially $(bindir). We do it this way because we will also
allow a relative $(gitexecdir) later.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 Makefile   |    2 +-
 exec_cmd.c |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 4de9271..b9ea0ea 100644
--- a/Makefile
+++ b/Makefile
@@ -1301,7 +1301,7 @@ remove-dashes:
 ### Installation rules
 
 ifeq ($(firstword $(subst /, ,$(template_dir))),..)
-template_instdir = $(gitexecdir)/$(template_dir)
+template_instdir = $(bindir)/$(template_dir)
 else
 template_instdir = $(template_dir)
 endif
diff --git a/exec_cmd.c b/exec_cmd.c
index dedb01d..45f92eb 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -43,9 +43,9 @@ static const char *builtin_exec_path(void)
 
 const char *system_path(const char *path)
 {
-	if (!is_absolute_path(path)) {
+	if (!is_absolute_path(path) && argv0_path) {
 		struct strbuf d = STRBUF_INIT;
-		strbuf_addf(&d, "%s/%s", git_exec_path(), path);
+		strbuf_addf(&d, "%s/%s", argv0_path, path);
 		path = strbuf_detach(&d, NULL);
 	}
 	return path;
-- 
1.5.6.3.323.g1e58

[PATCH 4/5] Allow the built-in exec path to be relative to the command invocation path

[Johannes Sixt]

If GIT_EXEC_PATH (the macro that is defined in the Makefile) is relative,
it is interpreted relative to the command's invocation path, which usually
is $(bindir).

The Makefile rules were written with the assumption that $(gitexecdir) is
an absolute path. We introduce a separate variable that names the
(absolute) installation directory.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 Makefile   |   15 +++++++++++----
 exec_cmd.c |   38 ++------------------------------------
 2 files changed, 13 insertions(+), 40 deletions(-)

diff --git a/Makefile b/Makefile
index b9ea0ea..4df6423 100644
--- a/Makefile
+++ b/Makefile
@@ -1307,10 +1307,17 @@ template_instdir = $(template_dir)
 endif
 export template_instdir
 
+ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
+gitexec_instdir = $(bindir)/$(gitexecdir)
+else
+gitexec_instdir = $(gitexecdir)
+endif
+gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
+
 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) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
 	$(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'
 	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
 	$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
@@ -1319,10 +1326,10 @@ ifndef NO_TCLTK
 	$(MAKE) -C git-gui install
 endif
 ifneq (,$X)
-	$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
+	$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
 endif
 	bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
-	execdir=$$(cd '$(DESTDIR_SQ)$(gitexecdir_SQ)' && pwd) && \
+	execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \
 	if test "z$$bindir" != "z$$execdir"; \
 	then \
 		ln -f "$$bindir/git$X" "$$execdir/git$X" || \
diff --git a/exec_cmd.c b/exec_cmd.c
index 45f92eb..c236034 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -7,40 +7,6 @@ extern char **environ;
 static const char *argv_exec_path;
 static const char *argv0_path;
 
-static const char *builtin_exec_path(void)
-{
-#ifndef __MINGW32__
-	return GIT_EXEC_PATH;
-#else
-	int len;
-	char *p, *q, *sl;
-	static char *ep;
-	if (ep)
-		return ep;
-
-	len = strlen(_pgmptr);
-	if (len < 2)
-		return ep = ".";
-
-	p = ep = xmalloc(len+1);
-	q = _pgmptr;
-	sl = NULL;
-	/* copy program name, turn '\\' into '/', skip last part */
-	while ((*p = *q)) {
-		if (*q == '\\' || *q == '/') {
-			*p = '/';
-			sl = p;
-		}
-		p++, q++;
-	}
-	if (sl)
-		*sl = '\0';
-	else
-		ep[0] = '.', ep[1] = '\0';
-	return ep;
-#endif
-}
-
 const char *system_path(const char *path)
 {
 	if (!is_absolute_path(path) && argv0_path) {
@@ -75,7 +41,7 @@ const char *git_exec_path(void)
 		return env;
 	}
 
-	return builtin_exec_path();
+	return system_path(GIT_EXEC_PATH);
 }
 
 static void add_path(struct strbuf *out, const char *path)
@@ -99,7 +65,7 @@ void setup_path(void)
 
 	add_path(&new_path, argv_exec_path);
 	add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
-	add_path(&new_path, builtin_exec_path());
+	add_path(&new_path, system_path(GIT_EXEC_PATH));
 	add_path(&new_path, argv0_path);
 
 	if (old_path)
-- 
1.5.6.3.323.g1e58

[PATCH 5/5] Allow add_path() to add non-existent directories to the path

[Johannes Sixt]

This function had used make_absolute_path(); but this function dies if
the directory that contains the entry whose relative path was supplied in
the argument does not exist. This is a problem if the argument is, for
example, "../libexec/git-core", and that "../libexec" does not exist.

Since the resolution of symbolic links is not required for elements in
PATH, we can fall back to using make_nonrelative_path(), which simply
prepends $PWD to the path.

We have to move make_nonrelative_path() alongside make_absolute_path() in
abspath.c so that git-shell can be linked. See 5b8e6f85f.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 abspath.c  |   36 ++++++++++++++++++++++++++++++++++++
 exec_cmd.c |    2 +-
 path.c     |   36 ------------------------------------
 3 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/abspath.c b/abspath.c
index 4f95a95..0d56124 100644
--- a/abspath.c
+++ b/abspath.c
@@ -66,3 +66,39 @@ const char *make_absolute_path(const char *path)
 
 	return buf;
 }
+
+static const char *get_pwd_cwd(void)
+{
+	static char cwd[PATH_MAX + 1];
+	char *pwd;
+	struct stat cwd_stat, pwd_stat;
+	if (getcwd(cwd, PATH_MAX) == NULL)
+		return NULL;
+	pwd = getenv("PWD");
+	if (pwd && strcmp(pwd, cwd)) {
+		stat(cwd, &cwd_stat);
+		if (!stat(pwd, &pwd_stat) &&
+		    pwd_stat.st_dev == cwd_stat.st_dev &&
+		    pwd_stat.st_ino == cwd_stat.st_ino) {
+			strlcpy(cwd, pwd, PATH_MAX);
+		}
+	}
+	return cwd;
+}
+
+const char *make_nonrelative_path(const char *path)
+{
+	static char buf[PATH_MAX + 1];
+
+	if (is_absolute_path(path)) {
+		if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+			die("Too long path: %.*s", 60, path);
+	} else {
+		const char *cwd = get_pwd_cwd();
+		if (!cwd)
+			die("Cannot determine the current working directory");
+		if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX)
+			die("Too long path: %.*s", 60, path);
+	}
+	return buf;
+}
diff --git a/exec_cmd.c b/exec_cmd.c
index c236034..0ed768d 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -50,7 +50,7 @@ static void add_path(struct strbuf *out, const char *path)
 		if (is_absolute_path(path))
 			strbuf_addstr(out, path);
 		else
-			strbuf_addstr(out, make_absolute_path(path));
+			strbuf_addstr(out, make_nonrelative_path(path));
 
 		strbuf_addch(out, PATH_SEP);
 	}
diff --git a/path.c b/path.c
index 504eae0..9df447b 100644
--- a/path.c
+++ b/path.c
@@ -291,42 +291,6 @@ int adjust_shared_perm(const char *path)
 	return 0;
 }
 
-static const char *get_pwd_cwd(void)
-{
-	static char cwd[PATH_MAX + 1];
-	char *pwd;
-	struct stat cwd_stat, pwd_stat;
-	if (getcwd(cwd, PATH_MAX) == NULL)
-		return NULL;
-	pwd = getenv("PWD");
-	if (pwd && strcmp(pwd, cwd)) {
-		stat(cwd, &cwd_stat);
-		if (!stat(pwd, &pwd_stat) &&
-		    pwd_stat.st_dev == cwd_stat.st_dev &&
-		    pwd_stat.st_ino == cwd_stat.st_ino) {
-			strlcpy(cwd, pwd, PATH_MAX);
-		}
-	}
-	return cwd;
-}
-
-const char *make_nonrelative_path(const char *path)
-{
-	static char buf[PATH_MAX + 1];
-
-	if (is_absolute_path(path)) {
-		if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
-			die ("Too long path: %.*s", 60, path);
-	} else {
-		const char *cwd = get_pwd_cwd();
-		if (!cwd)
-			die("Cannot determine the current working directory");
-		if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX)
-			die ("Too long path: %.*s", 60, path);
-	}
-	return buf;
-}
-
 const char *make_relative_path(const char *abs, const char *base)
 {
 	static char buf[PATH_MAX + 1];
-- 
1.5.6.3.323.g1e58

Re: What's cooking in git.git (topics)

[Lea Wiemann]

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).

Re: What's cooking in git.git (topics)

[Lea Wiemann]

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?

Re: What's cooking in git.git (topics)

[Junio C Hamano]

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]

Re: Closing the merge window for 1.6.0

[Shawn O. Pearce]

Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 14 Jul 2008, Gerrit Pape wrote:
> 
> > On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> > > On Mon, 14 Jul 2008, Petr Baudis wrote:
> > > > I'm saying this because I believe the best conservative upper bound for 
> > > > backwards compatibility is Git version in Debian stable. It gets 
> > > > probably the most stale from all the widely used software distributions 
> > > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> > > > fails miserably on the new packs.
> 
> Maybe we can release 1.4.5 with the ability to read index v2?  That 
> wouldn't be hard to backport the reading part of it.

If we consider that supporting 1.4.4.4 clients is still a priority,
due to the widespread distribution of that version in a popular
version of Debian, we shouldn't be rushing the index v2 or OFS_DELTA
functionality on by default in 1.6.0.  Instead we would wait until
Debian stable (and most other widely popular distributions) are on
a modern enough version of Git to understand this format.

Really.  As much as I'd love to see the switch to v2 made by default
I don't think we can/should do it unless the majority of the user
base will be able to grok it.  And Debian etch sounds like it won't.

-- 
Shawn.

Re: Closing the merge window for 1.6.0

[Martin Langhoff]

On Tue, Jul 15, 2008 at 7:19 AM, Teemu Likonen <tlikonen@iki.fi> wrote:
>> But as the upstream, we have our own deprecation schedule.
>
> As Debian stable (4.0 "Etch") and its git 1.4.4.4 was mentioned I'd like
> to point out that git 1.5.6 is available for Etch users from
> kind-of-semi-official <www.backports.org>. So I guess Debian stable
> users aren't left completely behind. Git's web page already advertises
> backports.org version for Etch.

I concur. Users of git on Etch are using backports AFAIK.

We still have the case of the "casual" user, who does not know much
about git, but installs it to clone & review a project's code. There,
if v1.4.4 complains with a useful message, the casual user will swear
a bit and grab a backport. If it dies a horrible uninformative death,
then we will get  bogus bug reports, flamage, the works.

cheers,



m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

Re: Closing the merge window for 1.6.0

[Nicolas Pitre]

On Tue, 15 Jul 2008, Shawn O. Pearce wrote:

> Nicolas Pitre <nico@cam.org> wrote:
> > On Mon, 14 Jul 2008, Gerrit Pape wrote:
> > 
> > > On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> > > > On Mon, 14 Jul 2008, Petr Baudis wrote:
> > > > > I'm saying this because I believe the best conservative upper bound for 
> > > > > backwards compatibility is Git version in Debian stable. It gets 
> > > > > probably the most stale from all the widely used software distributions 
> > > > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> > > > > fails miserably on the new packs.
> > 
> > Maybe we can release 1.4.5 with the ability to read index v2?  That 
> > wouldn't be hard to backport the reading part of it.
> 
> If we consider that supporting 1.4.4.4 clients is still a priority,
> due to the widespread distribution of that version in a popular
> version of Debian, we shouldn't be rushing the index v2 or OFS_DELTA
> functionality on by default in 1.6.0.  

OFS_DELTA is supported by 1.4.4.4 so that's a non issue.

> Instead we would wait until Debian stable (and most other widely 
> popular distributions) are on a modern enough version of Git to 
> understand this format.

I don't think we should have git development be dictated by some 
discutable policy from one distribution.

IMHO git prior 1.5.0 is so horrible as general usability goes, and so 
different from what everybody is discussing on the net, that no one sane 
should still be using it. Even ourselves (i.e. the git community) are 
not supporting git 1.4.4 anymore so this hardly can be a priority.

As far as I know, there is no other widely popular distribution other 
than Debian using git prior 1.5.0 in their latest release. If Debian 
people want to support git 1.4.4 although we called thatversion obsolete 
_long_ ago then that's their problem.  We should not be bound by that 
external policy to which we never agreed with.

Now I proposed a compromise which consists of making 1.4.4.4+1 able to 
cope with index v2.  That should fall into Debian's "major usability 
fix" category.  I think that is a far better compromize than delaying 
index v2 even further.

> Really.  As much as I'd love to see the switch to v2 made by default
> I don't think we can/should do it unless the majority of the user
> base will be able to grok it.  And Debian etch sounds like it won't.

I truly hope the majority of the user is _not_ using 1.4.4.4.  Otherwise 
I may only have pity for them.


Nicolas

Re: What's cooking in git.git (topics)

[Geoffrey Irving]

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

Re: [PATCH 0/5] replacement for the part of js/more-win that is in pu

[Johannes Sixt]

Johannes Sixt schrieb:
> The interdiff to js/more-win is below. It is mostly the changes
> of 1/5.
> 
> Johannes Sixt (5):
>       Makefile: Normalize $(bindir) and $(gitexecdir) before comparing
>       Record the command invocation path early
>       Fix relative built-in paths to be relative to the command
>          invocation
>       Allow the built-in exec path to be relative to the command
>          invocation path
>       Allow add_path() to add non-existent directories to the path

I retract this series and also the earlier version (the part that is in pu).

If I had done due diligence, I could have found out earlier that it does
not solve the problem it tried to solve. Appologies for the noise. :-(

The series tries to derive the exec-path from argv[0] (if the built-in
path is relative). But if a command is invoked from CMD on Windows,
argv[0] doesn't have a path, there is only the program name, "git.exe". In
the past, we relied on the global variable _pgmptr (only Windows's C
runtime has this), which does contain the full path, and if we set

   gitexecdir = $(bindir)

in the Makefile, then we get a working git.exe, but we put back all
commands into $PATH.

-- Hannes

Re: Closing the merge window for 1.6.0

[Petr Baudis]

On Mon, Jul 14, 2008 at 12:16:26PM -0700, Junio C Hamano wrote:
> Yeah, I think git-repack, git-gc, git-pack-objects and git-index-pack on
> the server side need a knob to tell it to stay conservative because the
> repository may be served over dumb protocols to avoid this problem.
> 
> That knob could even be called
> 
> 	[repack]
>         	usedeltabaseoffset = false
> 	[pack]
>         	indexversion = 1

Can you please mention this in release notes? Until now, I actually
thought you're speaking about a hypothetical improvement, not a knob we
actually have. :-) (BTW, turning off the usedeltabaseoffset is not
critical at least Debian-wise, and I think that really is the oldest Git
in widespread use.)

Now, there is of course still the issue of default behaviour, but at
least my concern is somewhat eased now. :-)

-- 
				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

Re: Closing the merge window for 1.6.0

[Petr Baudis]

On Mon, Jul 14, 2008 at 12:00:54PM -0700, Junio C Hamano wrote:
> But as the upstream, we have our own deprecation schedule.  We should of
> course plan carefully not to harm existing users of our releases, but
> frankly speaking, 18 months since 1.4.4.4 was tagged (early January 2007)
> is an eternity in git timescale.  Maybe we will slow down someday, and
> this 18-month is not a set-in-stone rule in any way, but at this point
> even without the packfile format issues, I personally think anything
> before 1.5.0 is irrelevant --- maybe they are interesting as historical
> curiosities, but not more than that.

Really, I think this is should be put into certain perspective:

	(i) This change is special since it affects client-server
	compatibility in bare repositories. AFAIK, none of the others
	you mention does this.

	(ii) The CRC checking is perhaps quite an improvement, but I
	don't think it is critical-to-have-just-now.

	(iii) Most importantly, this is not about waiting another few
	years for Debian to catch up, since the next stable release
	should really be upcoming rather soon:

		http://debian-community.org/LennyReleaseSchedule/

	(iv) These problems do not concern people who are currently
	_actively_ _working_ with Git; these people hopefully do not
	use 1.4 willingly and already use Git from backports.org.
	This is about user experience for casual users who are quite
	possibly interested only in read-only tracking of upstream
	using Git - these people will likely use default Debian Git
	version and that is okay, because frankly, for them, the
	1.5 improvements do not really matter much. This is also
	large class of prospective future real Git users and we might
	not want to ruin Git's reputation in their eyes.

-- 
				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

Re: What's cooking in git.git (topics)

[Johannes Schindelin]

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

Re: Closing the merge window for 1.6.0

[Dmitry Potapov]

On Tue, Jul 15, 2008 at 11:20:23AM +0200, Petr Baudis wrote:
> 
> 	(iii) Most importantly, this is not about waiting another few
> 	years for Debian to catch up, since the next stable release
> 	should really be upcoming rather soon:
> 
> 		http://debian-community.org/LennyReleaseSchedule/

Even if Lenny will be released right on the scheduler (which I seriously
doubt), Etch will be around for another year. In fact, the last release
of oldstable (sarge) happened on April 12 this year.  Thus delaying of
indexversion=2 does not help much here. Anyone who is more or less
seriously about using Git grabs it from backports. The downside of
delaying is that any incompatible changes are much less welcome by users
during minor releases than major ones. People tend to read release notes
during major releases more carefully and think whether they prefer new
features or backward compatibility. This choice will not be the same for
anyone, but changing default settings on the major release is much more
appropriate than during minor ones.

> 
> 	(iv) These problems do not concern people who are currently
> 	_actively_ _working_ with Git; these people hopefully do not
> 	use 1.4 willingly and already use Git from backports.org.
> 	This is about user experience for casual users who are quite
> 	possibly interested only in read-only tracking of upstream
> 	using Git - these people will likely use default Debian Git
> 	version and that is okay, because frankly, for them, the
> 	1.5 improvements do not really matter much. This is also
> 	large class of prospective future real Git users and we might
> 	not want to ruin Git's reputation in their eyes.

I disagree. It is not Git does not support the old format, but it
switches on the new one as default on the next major release, which
is a sensible thing to do. Those repos that think that access for
Git 1.4 users is important for them can set indexformat=1. As to
prospective future real Git users, anyone who is trying to use Git
1.4 is going to hit by many usability issues that were resolved in
1.5; and there is no community support for Git 1.4 either -- you can
ask about any problem with Git 1.4 on this list, and the only answer
you'll get is that you should upgrade your Git. So, there is no way
for newcommers to start using Git 1.4 and be satisfied with it.

Finally, 18 months since 1.4.4 may not appear as a long time ago for
other projects that are being developed for many years, but for Git,
which was only 21 months when Git 1.4.4 was released, 18 months is
really very *long* time ago.

Dmitry

Re: Closing the merge window for 1.6.0

[Johannes Schindelin]

Hi,

On Tue, 15 Jul 2008, Dmitry Potapov wrote:

> Those repos that think that access for Git 1.4 users is important for 
> them can set indexformat=1.

Unfortunately, you place quite a high maintenance burden on the repository 
maintainers here.

>From the time balance sheet, it does not look good at all: a few minutes 
for Junio to change and commit, up to a few hours (because they missed it 
in the release notes) for probably more than hundred repository 
maintainers that are not subscribed to the Git mailing list.

And I absolutely agree with Pasky that this does _nothing_ in the vague 
direction of wielding a reputation of being easy to use.

Sure, we can make it easy on ourselves.  And it is just as easy to make it 
hard on others.  If you're okay with that, I am not.

Ciao,
Dscho

Re: Closing the merge window for 1.6.0

[Avery Pennarun]

On 7/15/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>  On Tue, 15 Jul 2008, Dmitry Potapov wrote:
>  > Those repos that think that access for Git 1.4 users is important for
>  > them can set indexformat=1.
>
> Unfortunately, you place quite a high maintenance burden on the repository
>  maintainers here.
>
>  From the time balance sheet, it does not look good at all: a few minutes
>  for Junio to change and commit, up to a few hours (because they missed it
>  in the release notes) for probably more than hundred repository
>  maintainers that are not subscribed to the Git mailing list.

To take this in a slightly different direction, what exactly is the
benefit of the new feature?  Apparently my git doesn't have it enabled
by default, and git works fine for me.  Am I missing out on something
that I should feel inferior about if my non-debian-etch running
friends(*) found out about it? :)

Have fun,

Avery

(*) Actually I compile my own git from source anyway.  I never want to
live without "git rebase -i" and "git add -p" ever again.  Life is too
short! :)

Re: Closing the merge window for 1.6.0

[Nicolas Pitre]

On Tue, 15 Jul 2008, Johannes Schindelin wrote:

> And I absolutely agree with Pasky that this does _nothing_ in the vague 
> direction of wielding a reputation of being easy to use.

Staying with git versions prior 1.5 isn't either.  In fact, git had a 
much harder time with its usability reputation in those days.  In other 
words, if some user of Debian is rebutted by the upgrade path for a later 
git version, then the awkwardness of git 1.4.4 UI will be even worse.

Anyway this is all hand waving until someone can come with some evidence 
that git 1.4.4 is actually used by a significant amount of people, and 
that those people depend on dumb transfer protocols.


Nicolas

Re: Closing the merge window for 1.6.0

[Sverre Rabbelier]

On Tue, Jul 15, 2008 at 6:26 PM, Nicolas Pitre <nico@cam.org> wrote:
> Anyway this is all hand waving until someone can come with some evidence
> that git 1.4.4 is actually used by a significant amount of people, and
> that those people depend on dumb transfer protocols.

Can't we add a msg to 1.4.4.x when it finds pack version 2 to upgrade
to 1.5.x? Gets rid of the problem all together while still giving the
user a reasonable message when it finds a repo version 2.
Hey, here's an idea, can't we have 1.4.4.x just give that msg for everything?

$cat git
#!/bin/sh

echo "Please upgrade to 1.5.x, version 1.4.x is no longer supported
nor should you even want to use it </cluebat>"

-- 
Cheers,

Sverre Rabbelier

Re: What's cooking in git.git (topics)

[Geoffrey Irving]

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

Re: Closing the merge window for 1.6.0

[Dmitry Potapov]

On Tue, Jul 15, 2008 at 04:27:02PM +0100, Johannes Schindelin wrote:
> 
> >From the time balance sheet, it does not look good at all: a few minutes 
> for Junio to change and commit, up to a few hours (because they missed it 
> in the release notes) for probably more than hundred repository 
> maintainers that are not subscribed to the Git mailing list.

If you just grab sources and never read release notes, there is nothing
that can help you. If Git 1.6.0 is not the right moment to do these
changes then Git 1.6.1 is neither, regardless whether Debian will
release Lenny by that time or not. People do not upgrade their distro in
the day of release. Some upgraded to Etch not so long ago. So, should we
wait for another year till 1.7.0?

> 
> And I absolutely agree with Pasky that this does _nothing_ in the vague 
> direction of wielding a reputation of being easy to use.

I don't think Git 1.4 is easy to use. If you want Git that is easy to
use install Git 1.5.x. And, it is *much* easier to install Git from
backports then to deal with usability issues of Git 1.4 and the lack
of community support.  So, I don't see how this change may hurt.

> 
> Sure, we can make it easy on ourselves.  And it is just as easy to make it 
> hard on others.  If you're okay with that, I am not.

It has *nothing* to do with making easy on ourselves and hard on others.
The question here is what is the appropriate time to change these default
settings, and I believe that *major* releases are the appropriate time
while minor ones are not.


Dmitry

Re: Closing the merge window for 1.6.0

[Petr Baudis]

On Tue, Jul 15, 2008 at 12:26:48PM -0400, Nicolas Pitre wrote:
> Anyway this is all hand waving until someone can come with some evidence 
> that git 1.4.4 is actually used by a significant amount of people, and 
> that those people depend on dumb transfer protocols.

That will be hard to produce. :-) _My_ personal story is that I have
Git-1.4.4.4 installed system-wide on repo.or.cz and follow git#next
locally, and quite panicked when I was inspecting some repositories
as root (using the system-wide Git) and these error messages popped up.
This may become a similar experience for others on multi-user systems
where people want to share work but don't realize that one of them has
Git installed locally and the other one doesn't. We can save them the
head-slapping and a bit of wasted life.

Out of interest, I did a simple statistics of HTTP user agents on
repo.or.cz; the dumb access does not seem very widely used overally,
it turns out. The stats begin at 19/May/2008:10:54:32 +0200. Here is the
breakdown, counting unique clients only:

# zgrep '"GET /r/.*/info/packs' /var/log/apache2/repo-access.log* | egrep -v bot\|slurp\|Gecko\|Opera |
	cut -d " " -f 1,12- | sed 's/\.g[a-f0-9]*\(\.dirty\)*"/"/' | sort -u |
	cut -d ' ' -f 2 | sort | uniq -c | sort -rn | head -n 50
   1501 "git/1.5.4.3"	<- Ubuntu Hardy (heh.. is just that it?)
    278 "git/1.5.5.1"	<- RHEL5 (ditto)
    151 "git/1.5.2.5"	<- Ubuntu Gutsy
    133 "git/1.5.5.3"	<- ? (maybe Gentoo ~x86 for some time)
    125 "git/1.5.4.5"	<- OpenSUSE 11.0, FC9, Gentoo x86, Dapper backports
    104 "git/1.5.6"	<- Debian Lenny
     94 "git/1.5.5"
     66 "git/1.5.3.7"
     63 "git/1.5.5.4"
     63 "git/1.5.5.1015"
     55 "git/1.5.2.4"	<- OpenSUSE 10.3
     51 "Mozilla/4.0 (compatible;)"	<- huh?
     42 "git/1.5.3.8"
     37 "git/1.5.5.GIT"
     37 "git/1.5.3.5.2229"
     34 "git/1.5.6.1"
     33 "git/1.5.3.6"	<- Feisty backports
     31 "git/1.5.4.1"
     30 "git/1.5.6.2"
     20 "git/1.5.6.GIT"
     18 "git/1.5.3"
     17 "git/1.5.2.2"
     17 "git/1.4.4.4"
     15 "git/1.5.6.1.1071"
     14 "git/1.5.3.3"
     13 "git/1.5.4.4"
     13 "git/1.5.4"
     11 "git/1.5.6.1062"
     11 "git/1.5.5.2"
     10 "git/1.5.5.1.316"

(I also got two 1.4.4.2 (feisty?) fetches from one client. No older
Git versions.)

So wrt. keeping backwards compatibility, this is not _very_ convincing,
I admit. ;-)

-- 
				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

Re: Closing the merge window for 1.6.0

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Tue, 15 Jul 2008, Dmitry Potapov wrote:
>
>> Those repos that think that access for Git 1.4 users is important for 
>> them can set indexformat=1.
>
> Unfortunately, you place quite a high maintenance burden on the repository 
> maintainers here.
>
> From the time balance sheet, it does not look good at all: a few minutes 
> for Junio to change and commit, up to a few hours (because they missed it 
> in the release notes) for probably more than hundred repository 
> maintainers that are not subscribed to the Git mailing list.
>
> And I absolutely agree with Pasky that this does _nothing_ in the vague 
> direction of wielding a reputation of being easy to use.
>
> Sure, we can make it easy on ourselves.  And it is just as easy to make it 
> hard on others.  If you're okay with that, I am not.

I was not planning to comment on this issue further as the ball is in
Debian's court, but I think you are misguided.

We are not making anything hard on others.  Sticking to 1.4.4.4 codebase
is forced by Debian (for its policy) and choice made by its users (for not
knowing or using backports).  1.5.0 and later are vastly better and we
encourage users to update on every occassion we get.

I do not know the extent of the backporting effort necessary, the size of
potentially impacted population if Debian keeps shipping unpatched
1.4.4.4, nor how much Debian cares about supporting their 1.4.4.4 users
i.e. if they are willing and able to carry distro-only forward
compatibility patches, and knowing all of these is necessary before we
declare this is worth handling _ourselves_.  That is why I did not want to
take a definitive stance on this issue before hearing from the Debian
maintainer about them -- I said "Debian has to ask with list of items",
didn't I?

What troubles me the most is that you seem to be forgetting that we are
using git to manage our codebase.  Even if this turns out to be something
we would want to handle ourselves, it does not have to come from me.  If
you care that much, you could backport whatever change is appropriate to
keep 1.4.4.X codebase alive and arrange it to be published as 1.4.4.5.

In any case, it will _definitely_ *NOT* a few minutes of me nor anybody.
Release engineering takes quite a lot of time.

Re: Closing the merge window for 1.6.0

[Johannes Schindelin]

Hi,

On Tue, 15 Jul 2008, Junio C Hamano wrote:

> What troubles me the most is that you seem to be forgetting that we are 
> using git to manage our codebase.

I don't.  I have vivid memories of updating an ancient git repository of 
Git itself, which had some almost forgotten changes in it.  That was in 
the bad old days, when the version number did not even have a "1" in it.

It could not even fetch the current git.git.

I do _not_ want that to happen to anybody else, _even if_ we leave 1.4.4.4 
Behind as if it was an American Child.

Having said that, I do not have the resources to test and fix everything 
that may arise from Debian being seemingly unable to update to Git 1.5.  
So I agree completely that the ball is in Debian's half, and if they let 
it rot, it is sad, but I cannot help it.

Ciao,
Dscho

Re: Closing the merge window for 1.6.0

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Tue, 15 Jul 2008, Junio C Hamano wrote:
>
>> What troubles me the most is that you seem to be forgetting that we are 
>> using git to manage our codebase.
>
> I don't.  I have vivid memories of updating an ancient git repository of 
> Git itself, which had some almost forgotten changes in it.  That was in 
> the bad old days, when the version number did not even have a "1" in it.
>
> It could not even fetch the current git.git.
>
> I do _not_ want that to happen to anybody else, _even if_ we leave 1.4.4.4 
> Behind as if it was an American Child.

My reference to "git" was about "forking is easy".  We seem to have to
agree that talking is even cheaper, though ;-)

> Having said that, I do not have the resources to test and fix everything 
> that may arise from Debian being seemingly unable to update to Git 1.5.  

Heh, what happent to your earlier "a few minutes for Junio to change and
commit"?

Re: Closing the merge window for 1.6.0

[Johannes Schindelin]

Hi,

On Tue, 15 Jul 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Having said that, I do not have the resources to test and fix 
> > everything that may arise from Debian being seemingly unable to update 
> > to Git 1.5.
> 
> Heh, what happent to your earlier "a few minutes for Junio to change and 
> commit"?

That was meant for the integration of the patch that makes the 
backwards-incompatible patch.

Not for the necessary forward-compatible changes.

Ciao,
Dscho

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.

The topics list the commits in reverse chronological order.  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.

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.

The topics list the commits in reverse chronological order.  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.

Re: What's cooking in git.git (topics)

[Stephan Beyer]

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

Re: What's cooking in git.git (topics)

[Nanako Shiraishi]

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/

Re: What's cooking in git.git (topics)

[Junio C Hamano]

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.

Re: What's cooking in git.git (topics)

[Nanako Shiraishi]

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/

Re: What's cooking in git.git (topics)

[Junio C Hamano]

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

Re: What's cooking in git.git (topics)

[Petr Baudis]

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

Re: What's cooking in git.git (topics)

[Junio C Hamano]

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.

Re: What's cooking in git.git (topics)

[Johannes Schindelin]

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

Re: What's cooking in git.git (topics)

[Johannes Schindelin]

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

Re: What's cooking in git.git (topics)

[Nanako Shiraishi]

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/

Re: What's cooking in git.git (topics)

[Junio C Hamano]

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.

Re: What's cooking in git.git (topics)

[Johannes Schindelin]

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

Re: What's cooking in git.git (topics)

[Junio C Hamano]

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.

Re: What's cooking in git.git (topics)

[Johannes Schindelin]

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

What's cooking in git.git (topics)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.

The topics list the commits in reverse chronological order.  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.

Re: Closing the merge window for 1.6.0

[Nick Andrew]

Petr Baudis <pasky <at> suse.cz> writes:

>   Upgrading to newer version, *especially* if it's over then 1.4 - 1.5
> boundary, is not something you could seriously expect Debian to do.
> At least I actually _hope_ so, as a sysadmin of a network of 40 etch
> workstations.

Perhaps Debian could add a "git1.5" package to the etch repository. That
will guarantee that no current etch users of git 1.4.4.4 will be affected,
and they can choose if they want, to install git1.5.

Nick.

Re: What's cooking in git.git (topics)

[Nanako Shiraishi]

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/

Re: What's cooking in git.git (topics)

[Miklos Vajna]

[-- 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 --]

Re: What's cooking in git.git (topics)

[Johannes Schindelin]

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

Re: What's cooking in git.git (topics)

[Junio C Hamano]

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 ...

Re: What's cooking in git.git (topics)

[Johannes Schindelin]

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

Re: What's cooking in git.git (topics)

[Junio C Hamano]

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?

Re: What's cooking in git.git (topics)

[Sverre Rabbelier]

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

Re: What's cooking in git.git (topics)

[Miklos Vajna]

[-- 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 --]

Re: What's cooking in git.git (topics)

[Junio C Hamano]

"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().

Re: What's cooking in git.git (topics)

[Johannes Schindelin]

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"

Re: What's cooking in git.git (topics)

[Petr Baudis]

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

Re: What's cooking in git.git (topics)

[Sverre Rabbelier]

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

Re: What's cooking in git.git (topics)

[Junio C Hamano]

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.

Re: What's cooking in git.git (topics)

[Jakub Narebski]

"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

Re: What's cooking in git.git (topics)

[Yaroslav Halchenko]

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!

Re: What's cooking in git.git (topics)

[Junio C Hamano]

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 ;-)

Re: What's cooking in git.git (topics)

[Yaroslav Halchenko]

[-- 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 --]

Re: What's cooking in git.git (topics)

[Junio C Hamano]

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?

Re: What's cooking in git.git (topics)

[Yaroslav Halchenko]

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        

Re: What's cooking in git.git (topics)

[Johannes Sixt]

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

Re: What's cooking in git.git (topics)

[Yaroslav Halchenko]

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