What's cooking in git/spearce.git (topics)

What's cooking in git/spearce.git (topics)

[Shawn O. Pearce]

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: factorise "bisect_{bad,good,skip}" into "bisect_state".
 - Bisect: factorise some logging into "bisect_write".
 - Bisect: factorise "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

Recently updated to use "skip".  I haven't had a chance to look at
this series so it just parked in pu for now.

* ds/gitweb (Mon Oct 22 10:28:03 2007 +1000) 1 commit
 + gitweb: Provide title attributes for abbreviated author names.

* lt/rename (Sun Oct 21 16:59:03 2007 -0700) 2 commits
 - Linear-time/space rename logic (exact renames only)
 - Split out "exact content match" phase of rename detection

t4001-diff-rename.sh failed while running tests on pu.  I'm pretty
sure its this topic from Linus.  Need to look at it further.

* js/PATH (Sun Oct 21 22:59:01 2007 +0100) 1 commit
 - execv_git_cmd(): also try PATH if everything else fails.

I raised a concern about GIT_EXEC_PATH="" making $PATH search before
the compiled in path, which is certainly new behavior and I don't
think its quite what was intended.  Parked in pu until I hear back.

* sp/help-exit0 (Sun Oct 21 14:47:45 2007 -0700) 1 commit
 . "git help" and "git help -a" shouldn't exit(1) unless they error

Breaks things because "git" (no arguments) no exits successful,
which is less than ideal.  Only "git help" and "git help branch"
should be exiting successful.

* ja/shorthelp (Sun Oct 21 01:41:41 2007 +0300) 1 commit
 + On error, do not list all commands, but point to --help option

This I like.  We'll see what the list thinks while using next.  :)

* 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
 ... and many many more ...

I think this is just about ready to graduate to master.  I haven't
seen any major problems with it since the recent fixes were put in.
I'd like to see it move over soon as a number of other topics
are based upon the tip of this topic rather than master itself.
But obviously code quality is more important than topic organization.

* 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.
 ... db/fetch-pack begins here ...

This looked sane to me and makes it easier for the MinGW port.
Plus its an overal reduction in code, reusing the run-command
framework to avoid lots of ugly pipe() and dup2() calls.  Its
parked in next for a while to get some testing but is probably
fine to move to master in the near future.

* tf/afs (Fri Oct 19 07:38:16 2007 -0500) 1 commit
 - Better support AFS hardlinking across object directories

I'd rather rewrite this by putting the temporary files directly into
their final object directory, then hardlinking within that directory.
This should work on Coda and AFS, leaving only the FAT filesystem
as the odd-duck that needs to use rename().  But maybe I'm just
being really paranoid about not allowing an object to be replaced.

* jk/terse-fetch (Fri Oct 19 03:40:57 2007 -0400) 62 commits
 - park
 - git-fetch: mega-terse fetch output
 ... db/fetch-pack begins here ...

Much discussion on the list about this topic.  I think we may have
come to an agreement about what the output should look like, but
this topic doesn't implement that output format.  Someone needs to
either update this topic or rewrite it.  Starting from Jeff King's
patch makes things a lot easier.

* 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

I really like the new progress display that Nico implemented here,
and also the terser and more user friendly output from git-repack.
Needs more time for testing, but its pretty obvious code changes
and should be able to graduate to master in the near future.

* 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

Probably fine for master as-is.  I personally don't use mergetool so
I'd appreciate an Ack from someone who does that these are working
well for them.

* 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

This probably should graduate to master soon.  It just delays
updating the tracking refs until after we've made sure all refs
were updated.  I'll give it a few more days and then likely kick
it over to master.

* js/rebase (Wed Oct 17 10:31:35 2007 +0100) 1 commit
 + Fixing path quoting in git-rebase

Simple change, but rebase is a key tool.  I'll probably give this
a few more days and then kick it over.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

Waiting to hear if we're doing anything further with this.  it was
originally created to help "git stash" perform a pop, but nobody
has come forth with a patch for git-stash that uses this feature.
I'd like to have a real use for it that actually tests this code
in a more production setting before it merges to master.

* dz/color-addi (Tue Oct 16 21:42:23 2007 -0400) 1 commit
 - Add color support to git-add--interactive

I'm just parking this here in case anyone wants to pick this up and
continue it further.  I described on list to the original author
a number of problems with why this isn't in next yet; the author
said they will need a little bit of time before they can address
that list.

* 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.

There's actually a few other commits (3?) missing from the above
list that are safely parked away in my tree.  I'm most of the way
through reviewing these and have made a few bug fixes and style
nit corrections in the earlier parts of the series.  I'm going to
try and finish working through this series tomorrow and then will
probably merge it to next.

The other 3 commits are hanging off to the side as 2 of them are
for the top of db/fetch-pack (to port builtin-fetch and friends
to the new option parser) and the 3rd is a somewhat questionable
change due to needing to rename a "-h" to a "-H".  I just got
tired of rebasing these 3 other commits onto the respective topics.
I'm waiting for the core option parser (above) to freeze on a commit
SHA-1 before I deal with these again.

* 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

I've briefly looked at this series and there's reasons why its not
in next yet.  Its actually something that I'm interested in seeing
fixed as the current behavior of how git-push matches refs on the
remote side is just plain nuts.  I'll look at it further after I
get ph/parseopt and cc/skip into next.

* 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

I inherited these from Junio.  No change.

* 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.

Waiting on ph/parseopt (above) and other stuff for builtin-commit.

* 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.

Also inherited from Junio.  No change.

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

I actually had the "dirty work tree stash in rebase" thing trip on
me recently and I got a little pissed off about it.  The behavior
was not what I expected, nor what I wanted, at that particular point
in time.  Actually I wanted git-rebase to stop and *not* attempt
the rebase because of the dirty work tree.  So I'm not feeling the
"auto stash" love right now.

-- 
Shawn.

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

[Jeff King]

On Mon, Oct 22, 2007 at 02:32:22AM -0400, Shawn O. Pearce wrote:

> * jk/terse-fetch (Fri Oct 19 03:40:57 2007 -0400) 62 commits
>  - park
>  - git-fetch: mega-terse fetch output
>  ... db/fetch-pack begins here ...
> 
> Much discussion on the list about this topic.  I think we may have
> come to an agreement about what the output should look like, but
> this topic doesn't implement that output format.  Someone needs to
> either update this topic or rewrite it.  Starting from Jeff King's
> patch makes things a lot easier.

I will eventually get around to rewriting this (it seems the list
comments have died down), but it is much more interesting to play with
Linus' rename stuff tonight. :) If somebody else wants to take a stab,
please go ahead.

-Peff

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

[Jeff King]

On Mon, Oct 22, 2007 at 02:32:22AM -0400, Shawn O. Pearce wrote:

> * lt/rename (Sun Oct 21 16:59:03 2007 -0700) 2 commits
>  - Linear-time/space rename logic (exact renames only)
>  - Split out "exact content match" phase of rename detection
> 
> t4001-diff-rename.sh failed while running tests on pu.  I'm pretty
> sure its this topic from Linus.  Need to look at it further.

Hrm, the problem is that it's not favoring basenames anymore. But I
think it is because the loop in find_identical_files is inside out. For
every source file, it picks the best destination file. But I think we
want to do the opposite: for every destination file, pick the best
source file. Otherwise, if a non-basename source file is connected with
a particular destination file, we no longer try that destination file
again.

Patch is below (please just squash with the one from Linus).

diff --git a/diffcore-rename.c b/diffcore-rename.c
index 05d39db..8881818 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -252,17 +252,18 @@ static int find_identical_files(struct file_similarity *src,
 {
 	int renames = 0;
 	do {
-		struct diff_filespec *one = src->filespec;
+		struct diff_filespec *one = dst->filespec;
 		struct file_similarity *p, *best;
 		int i = 100;
 
 		best = NULL;
-		for (p = dst; p; p = p->next) {
+		for (p = src; p; p = p->next) {
 			struct diff_filespec *two = p->filespec;
 
-			/* Already picked as a destination? */
+			/* Already picked as a source? */
 			if (!p->src_dst)
 				continue;
+
 			/* False hash collission? */
 			if (hashcmp(one->sha1, two->sha1))
 				continue;
@@ -276,10 +277,10 @@ static int find_identical_files(struct file_similarity *src,
 		}
 		if (best) {
 			best->src_dst = 0;
-			record_rename_pair(best->index, src->index, MAX_SCORE);
+			record_rename_pair(dst->index, best->index, MAX_SCORE);
 			renames++;
 		}
-	} while ((src = src->next) != NULL);
+	} while ((dst = dst->next) != NULL);
 	return renames;
 }
 

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

[Linus Torvalds]

Sorry, I missed this while being busy hacking and not reading email ;)

On Mon, 22 Oct 2007, Jeff King wrote:
> 
> Patch is below (please just squash with the one from Linus).

Your patch is better than what used to be there, but

> -			/* Already picked as a destination? */
> +			/* Already picked as a source? */
>  			if (!p->src_dst)
>  				continue;

the above is wrong, the whole thing should be dropped (we *want* to be 
able to re-use sources).

Anyway, the set of fixes I sent out earlier included fixing that stupid 
loop as one of the things.

		Linus

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

[Jeff King]

On Mon, Oct 22, 2007 at 07:32:02PM -0700, Linus Torvalds wrote:

> Your patch is better than what used to be there, but
> 
> > -			/* Already picked as a destination? */
> > +			/* Already picked as a source? */
> >  			if (!p->src_dst)
> >  				continue;
> 
> the above is wrong, the whole thing should be dropped (we *want* to be 
> able to re-use sources).

Oops, you're right. I'm not sure what I was thinking.

> Anyway, the set of fixes I sent out earlier included fixing that stupid 
> loop as one of the things.

Looks like you have made some real progress. I'll try to review your
patch tonight, and hopefully make some progress on the inexact case.

-Peff

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

[Pierre Habouzit]

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

On Mon, Oct 22, 2007 at 06:32:22AM +0000, Shawn O. Pearce wrote:
> * 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.
>
> There's actually a few other commits (3?) missing from the above
> list that are safely parked away in my tree.  I'm most of the way
> through reviewing these and have made a few bug fixes and style
> nit corrections in the earlier parts of the series.  I'm going to
> try and finish working through this series tomorrow and then will
> probably merge it to next.


> The other 3 commits are hanging off to the side as 2 of them are
> for the top of db/fetch-pack (to port builtin-fetch and friends
> to the new option parser) and the 3rd is a somewhat questionable
> change due to needing to rename a "-h" to a "-H".  I just got
> tired of rebasing these 3 other commits onto the respective topics.
> I'm waiting for the core option parser (above) to freeze on a commit
> SHA-1 before I deal with these again.

  You also can ask me to resubmit them when the first round of parseopt
is merged. I'm actually waiting for that before I work on it again
(that's not the sole reason, $work ate my time as well, so I'm not
pressuring ;P) and I can send those again when things are more ready for
them.

  Like I said to you on IRC, I intend to hack a way to ask parse-options
to dump its options in a machine parseable way, to help {z,ba}sh
completions authors. And obviously I intend to migrate even more
builtins :)

-- 
·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/spearce.git (topics)

[Steffen Prohaska]

On Oct 22, 2007, at 8:32 AM, Shawn O. Pearce wrote:

> * 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
>
> I've briefly looked at this series and there's reasons why its not
> in next yet.

It's not ready for next. Especially the last patch in the list
changes the existing behaviour in a way that might be unexpected
by longtime git users. And maybe we even need for the 1.6 cycle
before we can change the behaviour of git push.


> Its actually something that I'm interested in seeing
> fixed as the current behavior of how git-push matches refs on the
> remote side is just plain nuts.  I'll look at it further after I
> get ph/parseopt and cc/skip into next.

I planned to draw a conclusion from the discussion in

http://marc.info/?l=git&m=119286893014690&w=2

and send an updated proposal based on what I learnt. But
unfortunately I didn't have time yet.

My impression now is that the details of the behaviour of "git
push" are hard to understand and should be made more explicit.

Related tasks are currently encoded in the refspecs, but the
details are not always obvious right away:
- creation of new branches on the remote side.
- deletion of branches on the remote side.
- pushing of branches matching on local and remote side.
- pushing local branches explicitly to a different ref on the remote.
- save newbies from pushing to 'non-standard' location, that
   is only push to heads and tags.
- but also allow to push to funny refs if you force git to
   do this.

All this is related to the topic above, although its maybe too much
to be solved at once.

	Steffen

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

[Junio C Hamano]

Thanks for keeping the git list running smoothly while I was away.

I've pulled the four integration branches from you, and split
out the topic branches out of next and pu so that I can take a
look at them individually.  I haven't looked at the actual
changes yet (but I do not have to, as long as I can trust
capable others), and only skimmed the list messages (about 2200
of them since I left).

git.git at k.org and alt-git.git at repo.or.cz should be in sync
with you now.  I'll take a look at the recent changes after
grabbing some sleep ;-)

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

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> Thanks for keeping the git list running smoothly while I was away.

Funny thing.  There's this tool called "git" that makes it really
easy to fork a project, apply patches straight from email, and
republish it for others to read and work on top of.  You should
check it out sometime.  :-)
 
> I've pulled the four integration branches from you, and split
> out the topic branches out of next and pu so that I can take a
> look at them individually.  I haven't looked at the actual
> changes yet (but I do not have to, as long as I can trust
> capable others), and only skimmed the list messages (about 2200
> of them since I left).
> 
> git.git at k.org and alt-git.git at repo.or.cz should be in sync
> with you now.  I'll take a look at the recent changes after
> grabbing some sleep ;-)

We're glad to have you back.  Or should I say _I'm_ glad to have
you back.  Never underestimate a man until you've at least walked
a week in his shoes.  :-)

Most of the patches that happened while you were away were merged
or parked into my git/spearce.git work (in large part thanks
to Lars Hjemli's work during the first week you were offline).
So hopefully you can just pickup from "recent history" (e.g. today
forward) and if we missed anything really interesting authors can
repost once you've had a chance to get caught up.

-- 
Shawn.

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)

[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)

[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]

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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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.

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)

[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)

[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: 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)

[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

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

[PATCH] rebase: brown paper bag fix after the detached HEAD patch

[Johannes Schindelin]

The --skip case was handled properly when rebasing without --merge,
but the --continue case was not.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Mon, 12 Nov 2007, Johannes Schindelin wrote:

	> 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,

	Here you are.  Sorry again.

 git-rebase.sh          |    6 +++++-
 t/t3403-rebase-skip.sh |   17 +++++++++++++++++
 2 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index 7a45e27..c9034b8 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -171,7 +171,11 @@ do
 			finish_rb_merge
 			exit
 		fi
-		git am --resolved --3way --resolvemsg="$RESOLVEMSG"
+		head_name=$(cat .dotest/head-name) &&
+		onto=$(cat .dotest/onto) &&
+		orig_head=$(cat .dotest/orig-head) &&
+		git am --resolved --3way --resolvemsg="$RESOLVEMSG" &&
+		move_to_original_branch
 		exit
 		;;
 	--skip)
diff --git a/t/t3403-rebase-skip.sh b/t/t3403-rebase-skip.sh
index becabfc..657f681 100755
--- a/t/t3403-rebase-skip.sh
+++ b/t/t3403-rebase-skip.sh
@@ -38,6 +38,19 @@ test_expect_failure 'rebase with git am -3 (default)' '
 test_expect_success 'rebase --skip with am -3' '
 	git rebase --skip
 	'
+
+test_expect_success 'rebase moves back to skip-reference' '
+	test refs/heads/skip-reference = $(git symbolic-ref HEAD) &&
+	git branch post-rebase &&
+	git reset --hard pre-rebase &&
+	! git rebase master &&
+	echo "hello" > hello &&
+	git add hello &&
+	git rebase --continue &&
+	test refs/heads/skip-reference = $(git symbolic-ref HEAD) &&
+	git reset --hard post-rebase
+'
+
 test_expect_success 'checkout skip-merge' 'git checkout -f skip-merge'
 
 test_expect_failure 'rebase with --merge' 'git rebase --merge master'
@@ -49,6 +62,10 @@ test_expect_success 'rebase --skip with --merge' '
 test_expect_success 'merge and reference trees equal' \
 	'test -z "`git diff-tree skip-merge skip-reference`"'
 
+test_expect_success 'moved back to branch correctly' '
+	test refs/heads/skip-merge = $(git symbolic-ref HEAD)
+'
+
 test_debug 'gitk --all & sleep 1'
 
 test_done
-- 
1.5.3.5.1738.g5c070

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)

[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)

[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

[PATCH 1/2] push: Add '--matching' option and print warning if it should be used

[Steffen Prohaska]

This on the road to
1) "git push --matching" pushes matching branches.
2) "git push --current" pushes only current branch.
3) "git push" reports error if the config does not contain a Push line.
   (after it reported a warning for a while).

Maybe in two years (that's twice an eternity in git time scales):

4) make "git push --current" the default.

This commit adds '--matching', which is a no-op at this point.
If appropriate, a warning is printed to tell the user that the
default will change in the future.

Thanks to Dscho for suggesting this.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 Documentation/git-push.txt |    8 +++++++-
 builtin-push.c             |   13 +++++++++++--
 t/t5516-fetch-push.sh      |   13 +++++++++++++
 3 files changed, 31 insertions(+), 3 deletions(-)

So here is '--matching'. And PATCH 2/2 will bring '--current'.
They apply on top of sp/refspec-match.

    Steffen

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 4a68aab..d2417f3 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
 SYNOPSIS
 --------
 [verse]
-'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
+'git-push' [--all] [--matching] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
            [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
 
 DESCRIPTION
@@ -63,6 +63,12 @@ the remote repository.
 	Instead of naming each ref to push, specifies that all
 	refs under `$GIT_DIR/refs/heads/` be pushed.
 
+\--matching::
+	Instead of naming each ref to push, specifies that matching
+	refs under `$GIT_DIR/refs/heads/` be pushed.  Matching means
+	the branch exists locally and at the remote under the same name.
+	Currently, this is the default.  But this will change in the future.
+
 \--dry-run::
 	Do everything except actually send the updates.
 
diff --git a/builtin-push.c b/builtin-push.c
index 54fba0e..7e9dcf1 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
 #include "parse-options.h"
 
 static const char * const push_usage[] = {
-	"git-push [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
+	"git-push [--all] [--matching] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
 	NULL,
 };
 
@@ -100,6 +100,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 {
 	int flags = 0;
 	int all = 0;
+	int matching = 0;
 	int dry_run = 0;
 	int force = 0;
 	int tags = 0;
@@ -109,6 +110,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 		OPT__VERBOSE(&verbose),
 		OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
 		OPT_BOOLEAN( 0 , "all", &all, "push all refs"),
+		OPT_BOOLEAN( 0 , "matching", &matching, "push matching refs"),
 		OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
 		OPT_BOOLEAN( 0 , "dry-run", &dry_run, "dry run"),
 		OPT_BOOLEAN('f', "force", &force, "force updates"),
@@ -135,8 +137,15 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 		repo = argv[0];
 		set_refspecs(argv + 1, argc - 1);
 	}
-	if ((flags & TRANSPORT_PUSH_ALL) && refspec)
+	if ((all != 0) + (matching != 0) > 1) {
+		fprintf(stderr, "--all and --matching are mutual exclusive.\n");
 		usage_with_options(push_usage, options);
+	}
+	if ((all || matching) && refspec)
+		usage_with_options(push_usage, options);
+	if (!all && !matching && !refspec)
+		fprintf(stderr, "Warning: assuming '--matching'."
+		                " This default will change in the future.\n");
 
 	return do_push(repo, flags);
 }
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index fd5f284..21aa7c3 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -100,6 +100,19 @@ test_expect_success 'fetch with wildcard' '
 	)
 '
 
+test_expect_code 129 'push command line options (1)' '
+	git push --all --matching testrepo
+'
+
+test_expect_code 129 'push command line options (2)' '
+	git push --matching testrepo master
+'
+
+test_expect_success 'push command line options (3)' '
+	git push testrepo 2>stderr.txt &&
+	grep -q "Warning: assuming.*--matching" stderr.txt
+'
+
 test_expect_success 'push without wildcard' '
 	mk_empty &&
 
-- 
1.5.3.5.743.g87c5c

[PATCH 2/2] push: Add '--current', which pushes only the current branch

[Steffen Prohaska]

Often you want to push only the current branch to the default
remote.  This was awkward to do in the past.  You needed to
remember the default remote and type "git push $remote HEAD".

This commit teaches push to do this if you use '--current'.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 Documentation/git-push.txt |    6 +++++-
 builtin-push.c             |   16 +++++++++++-----
 t/t5516-fetch-push.sh      |   29 +++++++++++++++++++++++++++++
 3 files changed, 45 insertions(+), 6 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index d2417f3..2dfaf50 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
 SYNOPSIS
 --------
 [verse]
-'git-push' [--all] [--matching] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
+'git-push' [--all] [--matching] [--current] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
            [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
 
 DESCRIPTION
@@ -69,6 +69,10 @@ the remote repository.
 	the branch exists locally and at the remote under the same name.
 	Currently, this is the default.  But this will change in the future.
 
+\--current::
+	Instead of naming each ref to push, specifies that only the
+	current branch be pushed.
+
 \--dry-run::
 	Do everything except actually send the updates.
 
diff --git a/builtin-push.c b/builtin-push.c
index 7e9dcf1..e5646d4 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
 #include "parse-options.h"
 
 static const char * const push_usage[] = {
-	"git-push [--all] [--matching] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
+	"git-push [--all] [--matching] [--current] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
 	NULL,
 };
 
@@ -101,6 +101,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 	int flags = 0;
 	int all = 0;
 	int matching = 0;
+	int current = 0;
 	int dry_run = 0;
 	int force = 0;
 	int tags = 0;
@@ -111,6 +112,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 		OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
 		OPT_BOOLEAN( 0 , "all", &all, "push all refs"),
 		OPT_BOOLEAN( 0 , "matching", &matching, "push matching refs"),
+		OPT_BOOLEAN( 0 , "current", &current, "push current branch"),
 		OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
 		OPT_BOOLEAN( 0 , "dry-run", &dry_run, "dry run"),
 		OPT_BOOLEAN('f', "force", &force, "force updates"),
@@ -137,15 +139,19 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 		repo = argv[0];
 		set_refspecs(argv + 1, argc - 1);
 	}
-	if ((all != 0) + (matching != 0) > 1) {
-		fprintf(stderr, "--all and --matching are mutual exclusive.\n");
+	if ((all != 0) + (matching != 0) + (current != 0) > 1) {
+		fprintf(stderr, "--all, --matching, and --current are mutual exclusive.\n");
 		usage_with_options(push_usage, options);
 	}
-	if ((all || matching) && refspec)
+	if ((all || matching || current) && refspec)
 		usage_with_options(push_usage, options);
-	if (!all && !matching && !refspec)
+	if (!all && !matching && !current && !refspec)
 		fprintf(stderr, "Warning: assuming '--matching'."
 		                " This default will change in the future.\n");
+	if (current) {
+		const char* head[1] = { "HEAD" };
+		set_refspecs(head, 1);
+	}
 
 	return do_push(repo, flags);
 }
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 21aa7c3..20e0796 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -113,6 +113,18 @@ test_expect_success 'push command line options (3)' '
 	grep -q "Warning: assuming.*--matching" stderr.txt
 '
 
+test_expect_code 129 'push command line options (4)' '
+	git push --all --current testrepo
+'
+
+test_expect_code 129 'push command line options (5)' '
+	git push --matching --current testrepo
+'
+
+test_expect_code 129 'push command line options (6)' '
+	git push --current testrepo master
+'
+
 test_expect_success 'push without wildcard' '
 	mk_empty &&
 
@@ -284,6 +296,23 @@ test_expect_success 'push with HEAD nonexisting at remote' '
 	check_push_result $the_commit heads/local
 '
 
+test_expect_success 'push with --current' '
+
+	mk_test heads/master &&
+	git checkout master &&
+	git push --current testrepo &&
+	check_push_result $the_commit heads/master
+
+'
+
+test_expect_success 'push with --current nonexisting at remote' '
+
+	mk_test heads/master &&
+	git checkout local &&
+	git push --current testrepo &&
+	check_push_result $the_commit heads/local
+'
+
 test_expect_success 'push with dry-run' '
 
 	mk_test heads/master &&
-- 
1.5.3.5.743.g87c5c

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> Often you want to push only the current branch to the default
> remote.  This was awkward to do in the past.

While I think --current is a handy shorthand to have, I do not
think the above description is correct.

Wouldn't your earlier patch have allowed the configuration setting:

	[remote "$there"]
        	push = HEAD
	[branch "$current"]
        	remote = $there

to work very well already?

I do not think it is "Often you want" that makes it awkward.

Instead, the awkward case is if you do the "only the current"
push NOT often enough.  If it is often enough, you set the
configuration once and the awkwardness is behind you.

If however it is not often enough, you cannot afford to have the
configuration above, because that would force you to tell from
the command line which branches, not just the current one, to
push, and that is inconvenient because it is not rare enough.

Together with your [PATCH 1/2], I like the general direction
these patckes are taking us, but it feels a bit too hasty.  I
personally am not convinced that switching to --current for
everybody is a good move.

> ...
> Maybe in two years (that's twice an eternity in git time scales):
>
> 4) make "git push --current" the default.

If these, both the uncertainly expressed by "Maybe" and "twice
an eternity" are true, which they are, the new warning in the
current patch are inappropriate.  Many people's settings depend
on a working "push the matching refs" behaviour, and we need a
very good excuse to annoy the existing happy users with such a
warning.

Remember, how much vocal the dissenters might have been on the
list in the recent discussions, we need to consider the needs of
the silent majority that has been content with the current
behaviour for a long time.

The "warning" to annoy them may be a way to get their attention
and get them involved in a discussion to decide what the default
should be.  But changing the default without giving the people
who do not like the _new_ default a way to avoid inconvenience
of always typing --matching or --current is not nice.  And
honestly, I do not think there is one single default that is
good for everybody.

We should be doing better.

A smoother transition route would be:

 - Keep "matching" the built-in default for now;

 - Take your patches (but drop "warning" bits at this point) to
   introduce 'matching' and 'current' behaviours, and a way to
   override the built-in default from the command line;

 - Introduce a configuration 'push.defaultRefs' ('matching' or
   'current') to override that built-in default, so people who
   prefer 'current' can override the built-in default, without
   having to type --current every time.

After all that happens, we can start discussing what the
built-in default should be.  When it is changed after the
discussion concludes (which may never happen), people who want
to keep 'matching' behaviour would have had the configuration
mechanism to override that built-in default for some time during
the discussion period.  So the beginning of that discussion
period is when we should start talking about "We might change
the default soon; set the configuration to your liking if you do
not want to get affected" in the warning.

Then after that, we may or may not decide to change the default.
Even if we end up not changing the default, 'current' people
will then have a way (push.matching = false) to tailor their git
for their liking, so everybody wins.

>  DESCRIPTION
> @@ -63,6 +63,12 @@ the remote repository.
>  	Instead of naming each ref to push, specifies that all
>  	refs under `$GIT_DIR/refs/heads/` be pushed.
>  
> +\--matching::
> +	Instead of naming each ref to push, specifies that matching
> +	refs under `$GIT_DIR/refs/heads/` be pushed.  Matching means
> +	the branch exists locally and at the remote under the same name.
> +	Currently, this is the default.  But this will change in the future.

For the above reason, "But this will..." is a bit premature.

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Steffen Prohaska]

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


On Nov 19, 2007, at 2:28 AM, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> Often you want to push only the current branch to the default
>> remote.  This was awkward to do in the past.
>
> While I think --current is a handy shorthand to have, I do not
> think the above description is correct.
>
> Wouldn't your earlier patch have allowed the configuration setting:
>
> 	[remote "$there"]
>         	push = HEAD
> 	[branch "$current"]
>         	remote = $there
>
> to work very well already?

No.  This was the case in the verst first version of the patch
series.  Someone, I don't remember who, proposed to put the
resolution of HEAD into builtin-push.c.  This simplified code
a lot.  Now, HEAD is resolved when parsing the command line.
At that time it is replaced with the full local refname.
The refspec parsing code never sees HEAD, and it won't
understand it.  Try the above setup, and you'll see that it
doesn't work.

Anyway it's not needed if we proceed as outlined below.


> I do not think it is "Often you want" that makes it awkward.
>
> Instead, the awkward case is if you do the "only the current"
> push NOT often enough.  If it is often enough, you set the
> configuration once and the awkwardness is behind you.
>
> If however it is not often enough, you cannot afford to have the
> configuration above, because that would force you to tell from
> the command line which branches, not just the current one, to
> push, and that is inconvenient because it is not rare enough.

Will try to rephrase the commit message.


> Together with your [PATCH 1/2], I like the general direction
> these patckes are taking us, but it feels a bit too hasty.  I
> personally am not convinced that switching to --current for
> everybody is a good move.
>
>> ...
>> Maybe in two years (that's twice an eternity in git time scales):
>>
>> 4) make "git push --current" the default.
>
> If these, both the uncertainly expressed by "Maybe" and "twice
> an eternity" are true, which they are, the new warning in the
> current patch are inappropriate.  Many people's settings depend
> on a working "push the matching refs" behaviour, and we need a
> very good excuse to annoy the existing happy users with such a
> warning.

I think 3) is the interesting case.  "git push" should do
nothing by default.  Either you can configure "git push" to do
something by setting a remote.$remote.push line or you need
to provide a command line switch.  But if you do not tell
explicitly what you want, "git push" will not do anything
for you.

I'm not sure if we ever switch to 4).  But already with 3) the
default changed.  So a warning seems to be appropriate.  But if
we go as outlined below, it's probably a different warning.

I attached a patch that illustrates what "do nothing by default"
means.  This patch should _not_ be applied.  It's only an
illustration what I'm working on.


> Remember, how much vocal the dissenters might have been on the
> list in the recent discussions, we need to consider the needs of
> the silent majority that has been content with the current
> behaviour for a long time.
>
> The "warning" to annoy them may be a way to get their attention
> and get them involved in a discussion to decide what the default
> should be.  But changing the default without giving the people
> who do not like the _new_ default a way to avoid inconvenience
> of always typing --matching or --current is not nice.  And
> honestly, I do not think there is one single default that is
> good for everybody.

Personally, I'd switch to the do-nothing default immediately.
But you are right.  More work is needed to have a smooth transition.


> We should be doing better.
>
> A smoother transition route would be:
>
>  - Keep "matching" the built-in default for now;
>
>  - Take your patches (but drop "warning" bits at this point) to
>    introduce 'matching' and 'current' behaviours, and a way to
>    override the built-in default from the command line;
>
>  - Introduce a configuration 'push.defaultRefs' ('matching' or
>    'current') to override that built-in default, so people who
>    prefer 'current' can override the built-in default, without
>    having to type --current every time.

Sounds like a plan.

If we have the configuration variable, maybe we could switch
off the default behaviour immediately.  Setting a single global
config variable once would be sufficient to get it back.  So,
we could change the default and print a recommendation to run
'git config --global push.defaultRefs matching' to get it back.

...

> After all that happens, we can start discussing what the
> built-in default should be.  When it is changed after the
> discussion concludes (which may never happen), people who want
> to keep 'matching' behaviour would have had the configuration
> mechanism to override that built-in default for some time during
> the discussion period.  So the beginning of that discussion
> period is when we should start talking about "We might change
> the default soon; set the configuration to your liking if you do
> not want to get affected" in the warning.

... And we'd not even start the discussion.  Because there's no
need to.  Every user should make a choice, once.  We do not
provide a default (which obviously will trigger another discussion ;)


> Then after that, we may or may not decide to change the default.
> Even if we end up not changing the default, 'current' people
> will then have a way (push.matching = false) to tailor their git
> for their liking, so everybody wins.
>
>>  DESCRIPTION
>> @@ -63,6 +63,12 @@ the remote repository.
>>  	Instead of naming each ref to push, specifies that all
>>  	refs under `$GIT_DIR/refs/heads/` be pushed.
>>
>> +\--matching::
>> +	Instead of naming each ref to push, specifies that matching
>> +	refs under `$GIT_DIR/refs/heads/` be pushed.  Matching means
>> +	the branch exists locally and at the remote under the same name.
>> +	Currently, this is the default.  But this will change in the  
>> future.
>
> For the above reason, "But this will..." is a bit premature.

I'll change the plan and will come back with a full
implementation.

Thanks for the helpful comments.

	Steffen



[-- Attachment #2: 0001-push-do-nothing-by-default.patch --]
[-- Type: application/octet-stream, Size: 3054 bytes --]

From a97c117794c631f556f87419a3dbaa702b858d95 Mon Sep 17 00:00:00 2001
From: Steffen Prohaska <prohaska@zib.de>
Date: Sun, 18 Nov 2007 19:22:30 +0100
Subject: [PATCH] push: do nothing by default

We used to push all matching branches.  This behaviour
was suitable in many situations, but sometimes confusing.

This commit switches off the default.  push now dies instead.

WORK IN PROGRESS.  NOT-SIGNED-OFF.
---
 builtin-push.c        |    9 +++++++--
 t/t5516-fetch-push.sh |   13 ++++---------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/builtin-push.c b/builtin-push.c
index e5646d4..e637540 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -143,8 +143,13 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 		fprintf(stderr, "--all, --matching, and --current are mutual exclusive.\n");
 		usage_with_options(push_usage, options);
 	}
-	if ((all || matching || current) && refspec)
-		usage_with_options(push_usage, options);
+	if (all || matching || current) {
+		if (refspec)
+			usage_with_options(push_usage, options);
+	} else {
+		if (!refspec)
+			die("No default action found.");
+	}
 	if (!all && !matching && !current && !refspec)
 		fprintf(stderr, "Warning: assuming '--matching'."
 		                " This default will change in the future.\n");
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 20e0796..48689b9 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -108,11 +108,6 @@ test_expect_code 129 'push command line options (2)' '
 	git push --matching testrepo master
 '
 
-test_expect_success 'push command line options (3)' '
-	git push testrepo 2>stderr.txt &&
-	grep -q "Warning: assuming.*--matching" stderr.txt
-'
-
 test_expect_code 129 'push command line options (4)' '
 	git push --all --current testrepo
 '
@@ -154,7 +149,7 @@ test_expect_success 'push with wildcard' '
 test_expect_success 'push with matching heads' '
 
 	mk_test heads/master &&
-	git push testrepo &&
+	git push --matching testrepo &&
 	check_push_result $the_commit heads/master
 
 '
@@ -319,7 +314,7 @@ test_expect_success 'push with dry-run' '
 	cd testrepo &&
 	old_commit=$(git show-ref -s --verify refs/heads/master) &&
 	cd .. &&
-	git push --dry-run testrepo &&
+	git push --dry-run --matching testrepo &&
 	check_push_result $old_commit heads/master
 '
 
@@ -331,7 +326,7 @@ test_expect_success 'push updates local refs' '
 	cd .. &&
 	git clone parent child && cd child &&
 		echo two >foo && git commit -a -m two &&
-		git push &&
+		git push --matching &&
 	test $(git rev-parse master) = $(git rev-parse remotes/origin/master)
 
 '
@@ -346,7 +341,7 @@ test_expect_success 'push does not update local refs on failure' '
 	cd .. &&
 	git clone parent child && cd child &&
 		echo two >foo && git commit -a -m two || exit 1
-		git push && exit 1
+		git push --matching && exit 1
 	test $(git rev-parse master) != $(git rev-parse remotes/origin/master)
 
 '
-- 
1.5.3.5.750.gc43b


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

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

>> Together with your [PATCH 1/2], I like the general direction
>> these patckes are taking us, but it feels a bit too hasty.  I
>> personally am not convinced that switching to --current for
>> everybody is a good move.
>>
>>> ...
>>
> I think 3) is the interesting case.  "git push" should do
> nothing by default.

NO WAY.

Making things cumbersome to everybody does not achieve anything
useful except for a false sense of equality, does it?

Drop that step (3).  That is not useful to anybody.

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Junio C Hamano]

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

> Steffen Prohaska <prohaska@zib.de> writes:
> ...
>> I think 3) is the interesting case.  "git push" should do
>> nothing by default.
>
> NO WAY.
>
> Making things cumbersome to everybody does not achieve anything
> useful except for a false sense of equality, does it?
>
> Drop that step (3).  That is not useful to anybody.

Thinking about it a bit more, I think my wording was a bit too
strong and needs clarifying explanations.

In a case like this, a fix of a "misfeature" for somebody is a
regression for somebody else.  Because there is no single right
default that is appropriate for everybody.

At least having _one_ default (and picking arbitrarily the
historical default as that one default) is better than no
default at all.  The former will not inconvenience anybody by
forcing what has been necessary from before.  The latter will
hurt the lucky ones whose preferred way happened to be the
historical default.

Keeping the status quo, however, will inconvinience unfortunate
people whose preferred way was not the historical default.
That's where we start to tackle the problem, by introducing the
configuration variable.

If we can come up with a way to tell projects that use the
workflow better served with --current, perhaps when a remote is
added to the repository (either the initial clone or "git remote
add") and/or when a new branch is created.  If we automatically
set up the configuration "push.defaultRefs = current" in such a
case, I suspect that we do not have to have the built-in default
(at least, the value of the built-in default would not matter
much).

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Andreas Ericsson]

Junio C Hamano wrote:
> 
> If we can come up with a way to tell projects that use the
> workflow better served with --current, perhaps when a remote is
> added to the repository (either the initial clone or "git remote
> add") and/or when a new branch is created.  If we automatically
> set up the configuration "push.defaultRefs = current" in such a
> case, I suspect that we do not have to have the built-in default
> (at least, the value of the built-in default would not matter
> much).

So when someone who's been using git of today adds a new remote
with a newer git, all of a sudden the default push behaviour
changes for that repo?

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

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Steffen Prohaska]

On Nov 19, 2007, at 8:27 AM, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>>> Together with your [PATCH 1/2], I like the general direction
>>> these patckes are taking us, but it feels a bit too hasty.  I
>>> personally am not convinced that switching to --current for
>>> everybody is a good move.
>>>
>>>> ...
>>>
>> I think 3) is the interesting case.  "git push" should do
>> nothing by default.
>
> NO WAY.
>
> Making things cumbersome to everybody does not achieve anything
> useful except for a false sense of equality, does it?

If forces people to make a decision.  And it will hopefully reduce
the amount of questions
"What does '! [rejected] master -> master (non-fast forward)' mean"?
At least I am pretty sure that it will reduce the number of
times I'll be asked this question.  Because I'll ask people to
set a reasonable default.  But if they forget to do so, they'll be
reminded by "git push", before calling me.

And with "push.defaultRefs = matching" it's easy to tell push
once and forever which decision you made.


> Drop that step (3).  That is not useful to anybody.


 From you follow-up mail:

> Thinking about it a bit more, I think my wording was a bit too
> strong and needs clarifying explanations.
>
> In a case like this, a fix of a "misfeature" for somebody is a
> regression for somebody else.  Because there is no single right
> default that is appropriate for everybody.
>
> At least having _one_ default (and picking arbitrarily the
> historical default as that one default) is better than no
> default at all.  The former will not inconvenience anybody by
> forcing what has been necessary from before.  The latter will
> hurt the lucky ones whose preferred way happened to be the
> historical default.

Well, here we disagree.  My point is: if there's no single
right default, then it's better to force the user to make
the decision.


> Keeping the status quo, however, will inconvinience unfortunate
> people whose preferred way was not the historical default.
> That's where we start to tackle the problem, by introducing the
> configuration variable.
>
> If we can come up with a way to tell projects that use the
> workflow better served with --current, perhaps when a remote is
> added to the repository (either the initial clone or "git remote
> add") and/or when a new branch is created.  If we automatically
> set up the configuration "push.defaultRefs = current" in such a
> case, I suspect that we do not have to have the built-in default
> (at least, the value of the built-in default would not matter
> much).

That's beyond what I plan to implement.

Anyway, I'll not change the default behaviour.

But then, if I think a bit more, I don't see a point in
providing the push.defaultRefs configuration.  The default
_is_ and _will forever be_ '--matching'.  That's it.  If a
user wants to have something different, either he needs to
tell on the command line (e.g. '--all', '--current'); or he
can use the a remote.*.push configuration.

That's easier to explain than a configuration variable
"push.defaultRefs", which he can set to "current".  Or he is
allowed to set it to "matching" without triggering an error.  But
this wouldn't change anything, because it's the default anyway.
Then why should someone ever set it to "matching"?

And further, if we have no plans for changing the default, it's
useless to introduce a switch "--matching".  So if the plan is
to stick with the current default forever, then I'll withdraw
my patch that introduces "--matching".

What's left is a new switch "--current".  Less code, easy
to explain.

	Steffen

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> What's left is a new switch "--current".  Less code, easy
> to explain.

But won't that force the "current" people always type that from
the command line, as your previous point was that your earlier
patch to say "remote.$there.push = HEAD" does not work that way?
If that configuration works as expected, then I'd 100% agree
that we would not need push.defaultRefs.  Either you do not have
"push" at all if your preference is --matching, or you do have
"push = HEAD" if your preference is --current.  But if it
doesn't (which was what I gathered from your earlier response),
having a configuration would help them, wouldn't it?

Changing the default, if it will ever happen, is _NOT_ to help
people who are already using git and want "current" NOW.  The
current users cannot be helped _unless_ we switch overnight, but
that is not an option as it introduces a regression to people's
established workflow.

Changing the default is to help new users who will come in the
future, if majority of the existing users find --current easier
to explain to new people _they_ need to train.

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Steffen Prohaska]

On Nov 19, 2007, at 9:35 AM, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> What's left is a new switch "--current".  Less code, easy
>> to explain.
>
> But won't that force the "current" people always type that from
> the command line, as your previous point was that your earlier
> patch to say "remote.$there.push = HEAD" does not work that way?
> If that configuration works as expected, then I'd 100% agree
> that we would not need push.defaultRefs.  Either you do not have
> "push" at all if your preference is --matching, or you do have
> "push = HEAD" if your preference is --current.  But if it
> doesn't (which was what I gathered from your earlier response),
> having a configuration would help them, wouldn't it?

My main point is that I want to have something that _always_
works as expected without manually tweaking the configuration
variables.  In a setting with shared repos, "git push" doesn't.
Sooner or later it will complain about refusing an update
because of non-fast-forward.  The only thing that currently
works it "git push $correct-remote $correct-branch", but this
depends on the local configuration and on the branch you're on.

"git push --current" would always work as expected; without
setting any configuration variable.

I can tell my users that their workflow is

	git checkout foo
	git pull
	work work work ...
	git push --current

That simple.  I'm fine with that.


> Changing the default, if it will ever happen, is _NOT_ to help
> people who are already using git and want "current" NOW.  The
> current users cannot be helped _unless_ we switch overnight, but
> that is not an option as it introduces a regression to people's
> established workflow.
>
> Changing the default is to help new users who will come in the
> future, if majority of the existing users find --current easier
> to explain to new people _they_ need to train.

I'll not change the default.  I'll only add the --current switch.

	Steffen

[PATCH] push: Add "--current", which pushes only the current branch

[Steffen Prohaska]

Pushing only the current branch to the default remote was awkward
in the past.  You needed to remember the default remote and type
"git push $remote $current".  A recent commit added support for
"git push $remote HEAD".  But still you need to remember and type
the remote.

This commit teaches push a short-cut: "git push --current" now
pushes the current branch to the default remote.

Note, this commit doesn't save you much if you want to push the
current branch to a remote that is not the default:  You can now
say either "git push --current foo" or "git push foo HEAD".

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 Documentation/git-push.txt |    6 +++++-
 builtin-push.c             |   14 ++++++++++++--
 t/t5516-fetch-push.sh      |   25 +++++++++++++++++++++++++
 3 files changed, 42 insertions(+), 3 deletions(-)

Eventually, I gave in.  I accepted that the default is to push
matching branches.  I'll not send further patches that try to
change this.  This is the last patch.

The patch applies on top of sp/refspec-match.

    Steffen

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 4a68aab..6ec6078 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
 SYNOPSIS
 --------
 [verse]
-'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
+'git-push' [--all] [--current] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
            [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
 
 DESCRIPTION
@@ -63,6 +63,10 @@ the remote repository.
 	Instead of naming each ref to push, specifies that all
 	refs under `$GIT_DIR/refs/heads/` be pushed.
 
+\--current::
+	Instead of naming each ref to push, specifies that only the
+	current branch is pushed.
+
 \--dry-run::
 	Do everything except actually send the updates.
 
diff --git a/builtin-push.c b/builtin-push.c
index 54fba0e..c5243ca 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
 #include "parse-options.h"
 
 static const char * const push_usage[] = {
-	"git-push [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
+	"git-push [--all] [--current] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
 	NULL,
 };
 
@@ -100,6 +100,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 {
 	int flags = 0;
 	int all = 0;
+	int current = 0;
 	int dry_run = 0;
 	int force = 0;
 	int tags = 0;
@@ -109,6 +110,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 		OPT__VERBOSE(&verbose),
 		OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
 		OPT_BOOLEAN( 0 , "all", &all, "push all refs"),
+		OPT_BOOLEAN( 0 , "current", &current, "push current branch"),
 		OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
 		OPT_BOOLEAN( 0 , "dry-run", &dry_run, "dry run"),
 		OPT_BOOLEAN('f', "force", &force, "force updates"),
@@ -135,8 +137,16 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 		repo = argv[0];
 		set_refspecs(argv + 1, argc - 1);
 	}
-	if ((flags & TRANSPORT_PUSH_ALL) && refspec)
+	if ((all != 0) + (current != 0) > 1) {
+		fprintf(stderr, "--all and --current are mutual exclusive.\n");
 		usage_with_options(push_usage, options);
+	}
+	if ((all || current) && refspec)
+		usage_with_options(push_usage, options);
+	if (current) {
+		const char* head[1] = { "HEAD" };
+		set_refspecs(head, 1);
+	}
 
 	return do_push(repo, flags);
 }
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index fd5f284..11c078a 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -100,6 +100,14 @@ test_expect_success 'fetch with wildcard' '
 	)
 '
 
+test_expect_code 129 'push: --current and --all mutual exclusive' '
+	git push --all --current testrepo
+'
+
+test_expect_code 129 'push: --current and refspec mutual exclusive' '
+	git push --current testrepo master
+'
+
 test_expect_success 'push without wildcard' '
 	mk_empty &&
 
@@ -271,6 +279,23 @@ test_expect_success 'push with HEAD nonexisting at remote' '
 	check_push_result $the_commit heads/local
 '
 
+test_expect_success 'push with --current' '
+
+	mk_test heads/master &&
+	git checkout master &&
+	git push --current testrepo &&
+	check_push_result $the_commit heads/master
+
+'
+
+test_expect_success 'push with --current nonexisting at remote' '
+
+	mk_test heads/master &&
+	git checkout local &&
+	git push --current testrepo &&
+	check_push_result $the_commit heads/local
+'
+
 test_expect_success 'push with dry-run' '
 
 	mk_test heads/master &&
-- 
1.5.3.5.742.gb61a8b

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Jakub Narebski]

Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
> 
>> What's left is a new switch "--current".  Less code, easy
>> to explain.
> 
> But won't that force the "current" people always type that from
> the command line, as your previous point was that your earlier
> patch to say "remote.$there.push = HEAD" does not work that way?
> If that configuration works as expected, then I'd 100% agree
> that we would not need push.defaultRefs.  Either you do not have
> "push" at all if your preference is --matching, or you do have
> "push = HEAD" if your preference is --current.  But if it
> doesn't (which was what I gathered from your earlier response),
> having a configuration would help them, wouldn't it?

Brief recap, to check if I understand things correctly:

1. If you use "matching" more often, then it should be enough to provide
   remote.<remotename>.push with refspec or wildcard refspec. "git push"
   would push matching. If one wants to push only current branch, one
   would use "git push --current" or "git push <remotename> HEAD".

   Question: what to do if there is no remote.<remotename>.push? Assume
   1-1 matching?

2. If you use "current" more often, then it should be anough (after
   correcting git; although it was written that it is quite a bit of work)
   to provide "remote.<remotename>.push = HEAD", or 
   "push.defaultRefs = current" if one wants to set this up for all
   remotes, or perhaps "remote.*.push = HEAD". "git push" would push
   current. If one wants to push matching, one would use "git push
   --matching"... although for matching one needs remote configured...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Brief recap, to check if I understand things correctly:
>
> 1. If you use "matching" more often, then it should be enough to provide
>    remote.<remotename>.push with refspec or wildcard refspec.

Eh, excuse me, what refspec would you write there?  "matching"
is defined to push the intersection of what we have and what
they have when "git-push" is run.  I do not think there is any
way to write that in remote.$there.push and cast in stone.

With "matching", you can arrange a set of semi-permanent
branches to be shown to others and let others build on, in
either "publishing" or "shared repository" model, while keeping
experimental branches in your private repository, and:

	$ git push $there

will only send what are in "the set of semi-permament branches",
like 'master' and 'maint.  Adding a new branch to that set is
just the matter of a one-shot:

	$ git push $there next

(older git may have choked and asked you to be more explicit by
"next:refs/heads/next").  After you do it once, "matching" will
push 'master', 'maint', 'next' without any additional
configuration.  Removing a branch from the set is also just a
matter of one-shot:

	$ git push $there :next

When you replace 'next' in the above with something that is a
lot short lived, the principle is the same.  I can push a topic
branch (say, jn/gitweb), asking "I have queued your patches but
I am having trouble merging this back to 'master' due to heavy
conflicts; could you do the honors instead?".  While waiting for
you to respond to that request, I may add more commits to that
branch and the "matching" push by me will update what is shown
$there.  Hopefully you would eventually pick it up and merge,
and either push the result back to my 'master' directly or
publish the result elsewhere for me to pull to my 'master'.

After all the interaction is done, the topic branch does not
have to stay $there and can be deleted.  Then 'matching' will
not touch the topic branch anymore, even if I still keep it
privately in my repository.

>    ... If one wants to push only current branch, one
>    would use "git push --current" or "git push <remotename> HEAD".

I think that is the proposal by Steffen (added back CC).

I am wondering if an alternative approach could be simpler.  If
we teach "git-push" to notice when only the refspecs are given
without remotename, and default to branch.$current.remote in
such a case, IOW, make these:

	$ git push HEAD
        $ git push next

push the obvious thing to the default remote, I _think_ we can
achieve the same effect as --current and a bit more.

The latter could be run after I made the 'next' integration
branch into a good shape, switched to 'pu' to merge up other
bits but before finishing that merging yet (it would not help me
personally as I do not work that way --- I push things out only
after I am done with all the public branches --- but it may help
the others).

>    Question: what to do if there is no remote.<remotename>.push? Assume
>    1-1 matching?

One-to-one is what 'matching' does, and the way to trigger it is
not to have a remote.$there.push.

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Jakub Narebski]

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> Brief recap, to check if I understand things correctly:
>>
>> 1. If you use "matching" more often, then it should be enough
>>    to provide remote.<remotename>.push with refspec or wildcard
>>    refspec. 
> 
> Eh, excuse me, what refspec would you write there?  "matching"
> is defined to push the intersection of what we have and what
> they have when "git-push" is run.  I do not think there is any
> way to write that in remote.$there.push and cast in stone.
[...]
>>    Question: what to do if there is no remote.<remotename>.push?
>>    Assume 1-1 matching?
> 
> One-to-one is what 'matching' does, and the way to trigger it is
> not to have a remote.$there.push.

I'm sorry, I had to have "stupid" moment. Thanks a lot for complete 
explanation of git-push, anyway.


>>    ... If one wants to push only current branch, one
>>    would use "git push --current" or "git push <remotename> HEAD".
> 
> I think that is the proposal by Steffen (added back CC).
> 
> I am wondering if an alternative approach could be simpler.  If
> we teach "git-push" to notice when only the refspecs are given
> without remotename, and default to branch.$current.remote in
> such a case, 

Including default remote when branch.<branchname>.remote is not set?

> IOW, make these: 
> 
> 	$ git push HEAD
>       $ git push next
> 
> push the obvious thing to the default remote, I _think_ we can
> achieve the same effect as --current and a bit more.

The only problem would be when there is conflict between remote name and 
branch name (for example default "origin" remote, and old git 
no-separate-remotes "origin" branch, or origin = origin/HEAD).
Perhaps we can reuse '--' as separator between remote(s) and refspecs 
(branch names); other command use it to separate refname / commit-ish 
from pathspec (file name).

So for scripts it would be "git push -- HEAD"; still shorter than
"git push --current".


BTW. what would happen for "git push branch1 branch2" if branch1 has 
different remote than branch2?

> The latter could be run after I made the 'next' integration
> branch into a good shape, switched to 'pu' to merge up other
> bits but before finishing that merging yet (it would not help me
> personally as I do not work that way --- I push things out only
> after I am done with all the public branches --- but it may help
> the others). 

-- 
Jakub Narebski
Poland

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>> 
>>> Brief recap, to check if I understand things correctly:
>>>
>>> 1. If you use "matching" more often, then it should be enough
>>>    to provide remote.<remotename>.push with refspec or wildcard
>>>    refspec. 
>> 
>> Eh, excuse me, what refspec would you write there?  "matching"
>> is defined to push the intersection of what we have and what
>> they have when "git-push" is run.  I do not think there is any
>> way to write that in remote.$there.push and cast in stone.
> [...]
>>>    Question: what to do if there is no remote.<remotename>.push?
>>>    Assume 1-1 matching?
>> 
>> One-to-one is what 'matching' does, and the way to trigger it is
>> not to have a remote.$there.push.
>
> I'm sorry, I had to have "stupid" moment. Thanks a lot for complete 
> explanation of git-push, anyway.
>
>
>>>    ... If one wants to push only current branch, one
>>>    would use "git push --current" or "git push <remotename> HEAD".
>> 
>> I think that is the proposal by Steffen (added back CC).
>> 
>> I am wondering if an alternative approach could be simpler.  If
>> we teach "git-push" to notice when only the refspecs are given
>> without remotename, and default to branch.$current.remote in
>> such a case, 
>
> Including default remote when branch.<branchname>.remote is not set?
>
>> IOW, make these: 
>> 
>> 	$ git push HEAD
>>       $ git push next
>> 
>> push the obvious thing to the default remote, I _think_ we can
>> achieve the same effect as --current and a bit more.
>
> The only problem would be when there is conflict between remote name and 
> branch name...

Yes.  *If* we were to do that fallback it has to be something
like this:

 (1) does $0 look like remote and $1..$n look like a refspec?  If
     so do not fallback;

 (2) Do we have branch.$current.remote?  If not, we cannot
     fallback so error out.

 (3) otherwise, does $0 look like a refspec?  If so, try insert
     it before the params, treating $0..$n all refspecs.

> So for scripts it would be "git push -- HEAD"; still shorter than
> "git push --current".

scripts should be as explicit as they need to be.

What matters is the case when the command cannot be explicit,
just like you cannot write --matching with explicit refspecs.

> BTW. what would happen for "git push branch1 branch2" if branch1 has 
> different remote than branch2?

Read my example more carefully.  It says "push HEAD" and "push
next" while on 'pu' and it takes branch.pu.remote.

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Jakub Narebski]

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Junio C Hamano wrote:

>>> IOW, make these: 
>>> 
>>> 	$ git push HEAD
>>>     $ git push next
>>> 
>>> push the obvious thing to the default remote, I _think_ we can
>>> achieve the same effect as --current and a bit more.
>>
>> The only problem would be when there is conflict between remote name and 
>> branch name...

What about idea of using "--" to separate remote from branchname?

> Yes.  *If* we were to do that fallback it has to be something
> like this:
> 
>  (1) does $0 look like remote and $1..$n look like a refspec?  If
>      so do not fallback;

By "look like remote" you mean that there is [remote "$0"] section
in config (I guess that we can not support old .git/remotes/<remote>
configuration for _new_ features, especially that there exist script
converting to new way of configuring remotes, contrib/remotes2config.sh)
 
>  (2) Do we have branch.$current.remote?  If not, we cannot
>      fallback so error out.

Do not fallback to "origin"?

>  (3) otherwise, does $0 look like a refspec?  If so, try insert
>      it before the params, treating $0..$n all refspecs.

You mean $0 is existing branch, or of the form branch:<whatever>?
Or should we forbid remote names containing ':'?

>> BTW. what would happen for "git push branch1 branch2" if branch1 has 
>> different remote than branch2?
> 
> Read my example more carefully.  It says "push HEAD" and "push
> next" while on 'pu' and it takes branch.pu.remote.

Somehow I missed that $current means _current branch_ (branch we are on,
which defines default remote). 

-- 
Jakub Narebski
Poland

Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Andreas Ericsson]

Steffen Prohaska wrote:
> 
> On Nov 19, 2007, at 2:28 AM, Junio C Hamano wrote:
> 
> 
> 
>> I do not think it is "Often you want" that makes it awkward.
>>
>> Instead, the awkward case is if you do the "only the current"
>> push NOT often enough.  If it is often enough, you set the
>> configuration once and the awkwardness is behind you.
>>
>> If however it is not often enough, you cannot afford to have the
>> configuration above, because that would force you to tell from
>> the command line which branches, not just the current one, to
>> push, and that is inconvenient because it is not rare enough.
> 
> Will try to rephrase the commit message.
> 
> 
>> Together with your [PATCH 1/2], I like the general direction
>> these patckes are taking us, but it feels a bit too hasty.  I
>> personally am not convinced that switching to --current for
>> everybody is a good move.
>>
>>> ...
>>> Maybe in two years (that's twice an eternity in git time scales):
>>>
>>> 4) make "git push --current" the default.
>>
>> If these, both the uncertainly expressed by "Maybe" and "twice
>> an eternity" are true, which they are, the new warning in the
>> current patch are inappropriate.  Many people's settings depend
>> on a working "push the matching refs" behaviour, and we need a
>> very good excuse to annoy the existing happy users with such a
>> warning.
> 
> I think 3) is the interesting case.  "git push" should do
> nothing by default.  Either you can configure "git push" to do
> something by setting a remote.$remote.push line or you need
> to provide a command line switch.  But if you do not tell
> explicitly what you want, "git push" will not do anything
> for you.
> 

I'd really, really hate that. I often have changes on several branches
when I push. I like the behaviour as it is today.

> 
>> Remember, how much vocal the dissenters might have been on the
>> list in the recent discussions, we need to consider the needs of
>> the silent majority that has been content with the current
>> behaviour for a long time.
>>
>> The "warning" to annoy them may be a way to get their attention
>> and get them involved in a discussion to decide what the default
>> should be.  But changing the default without giving the people
>> who do not like the _new_ default a way to avoid inconvenience
>> of always typing --matching or --current is not nice.  And
>> honestly, I do not think there is one single default that is
>> good for everybody.
> 
> Personally, I'd switch to the do-nothing default immediately.
> But you are right.  More work is needed to have a smooth transition.
> 
> 
>> We should be doing better.
>>
>> A smoother transition route would be:
>>
>>  - Keep "matching" the built-in default for now;
>>
>>  - Take your patches (but drop "warning" bits at this point) to
>>    introduce 'matching' and 'current' behaviours, and a way to
>>    override the built-in default from the command line;
>>
>>  - Introduce a configuration 'push.defaultRefs' ('matching' or
>>    'current') to override that built-in default, so people who
>>    prefer 'current' can override the built-in default, without
>>    having to type --current every time.
> 
> Sounds like a plan.
> 
> If we have the configuration variable, maybe we could switch
> off the default behaviour immediately.  Setting a single global
> config variable once would be sufficient to get it back.  So,
> we could change the default and print a recommendation to run
> 'git config --global push.defaultRefs matching' to get it back.
> 

Ugh. People who neither know nor care about git development will
wonder why the hell they now have to tell git something in order
for it to do something it's always done anyway. The majority of
git users never read release-notes. They just do "yum update" and
then go about their business the same way they've always done.

Newcomers that obviously have no such configuration will wonder
why they're getting warnings from using the standard command-set.

> ...
> 
>> After all that happens, we can start discussing what the
>> built-in default should be.  When it is changed after the
>> discussion concludes (which may never happen), people who want
>> to keep 'matching' behaviour would have had the configuration
>> mechanism to override that built-in default for some time during
>> the discussion period.  So the beginning of that discussion
>> period is when we should start talking about "We might change
>> the default soon; set the configuration to your liking if you do
>> not want to get affected" in the warning.
> 
> ... And we'd not even start the discussion.  Because there's no
> need to.  Every user should make a choice, once.  We do not
> provide a default (which obviously will trigger another discussion ;)
> 

If the default's to be changed, making it default to no-op is really
the only sensible thing to do. Otherwise I'm guessing a lot of people
that actually count on the current behaviour will get quite vexed, and
--current is definitely not the universally correct default thing to do.

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

[PATCH] git-commit: Add tests for invalid usage of -a/--interactive with paths

[Björn Steinbrink]

git-commit was/is broken in that it accepts paths together with -a or
--interactive, which it shouldn't. There tests check those usage errors.

Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
> [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.

Sorry, didn't take your comment to that patch as a request to provide
tests. Anyway, here they are :-) I hope I got the commit message/comment
formatting right this time.

diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 4dc35bd..9dba104 100644
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -34,6 +34,16 @@ test_expect_failure \
 	"git-commit -C HEAD -m illegal"
 
 test_expect_failure \
+	"using paths with -a" \
+	"echo King of the bongo >file &&
+	git-commit -m foo -a file"
+
+test_expect_failure \
+	"using paths with --interactive" \
+	"echo bong-o-bong >file &&
+	echo 7 | git-commit -m foo --interactive file"
+
+test_expect_failure \
 	"using invalid commit with -C" \
 	"git-commit -C bogus"
 

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

[PATCH] t7501-commit: Add test for git commit <file> with dirty index.

[Kristian Høgsberg]

---
 t/t7501-commit.sh |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 5aed3de..3627d9f 100644
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -259,4 +259,14 @@ test_expect_success 'amend commit to fix author' '
 	diff expected current
 
 '
+
+test_expect_success 'git commit <file> with dirty index' '
+	echo tacocat > elif &&
+	echo tehlulz > chz &&
+	git add chz &&
+	git commit elif -m "tacocat is a palindrome" &&
+	git show --stat | grep elif &&
+	git diff --cached | grep chz
+'
+	
 test_done
-- 
1.5.3.4.206.g58ba4

Re: [PATCH] t7501-commit: Add test for git commit <file> with dirty index.

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 784 bytes --]

Hi,

On Thu, 15 Nov 2007, Kristian Høgsberg wrote:

> ---
>  t/t7501-commit.sh |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
> index 5aed3de..3627d9f 100644
> --- a/t/t7501-commit.sh
> +++ b/t/t7501-commit.sh
> @@ -259,4 +259,14 @@ test_expect_success 'amend commit to fix author' '
>  	diff expected current
>  
>  '
> +
> +test_expect_success 'git commit <file> with dirty index' '
> +	echo tacocat > elif &&
> +	echo tehlulz > chz &&
> +	git add chz &&
> +	git commit elif -m "tacocat is a palindrome" &&
> +	git show --stat | grep elif &&
> +	git diff --cached | grep chz
> +'
> +	

Funny... I have something similar, but with a fix for builtin-commit ;-)  
Will send out in a minute.

Ciao,
Dscho

[PATCH] builtin-commit: fix "git add x y && git commit y" committing x, too

[Johannes Schindelin]

Earlier, builtin commit would implicitly commit also the staged
changes.

This patch fixes that.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	The function reset_index_to_head() could be moved to somewhere
	more central and be reused in builtin-reset.c instead of
	reset_index_file() later...

 builtin-add.c     |    1 +
 builtin-commit.c  |   30 +++++++++++++++++++++++++++++-
 t/t7500-commit.sh |   10 ++++++++++
 3 files changed, 40 insertions(+), 1 deletions(-)

diff --git a/builtin-add.c b/builtin-add.c
index 77dcde6..017c8f2 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -100,6 +100,7 @@ static void update_callback(struct diff_queue_struct *q,
 		case DIFF_STATUS_UNMERGED:
 		case DIFF_STATUS_MODIFIED:
 		case DIFF_STATUS_TYPE_CHANGED:
+		case DIFF_STATUS_ADDED:
 			add_file_to_cache(path, verbose);
 			break;
 		case DIFF_STATUS_DELETED:
diff --git a/builtin-commit.c b/builtin-commit.c
index 535039c..0dc6e1c 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -19,6 +19,7 @@
 #include "strbuf.h"
 #include "utf8.h"
 #include "parse-options.h"
+#include "unpack-trees.h"
 
 static const char * const builtin_commit_usage[] = {
 	"git-commit [options] [--] <filepattern>...",
@@ -77,6 +78,31 @@ static struct option builtin_commit_options[] = {
 	OPT_END()
 };
 
+static int reset_index_to_head(void)
+{
+	struct unpack_trees_options opts;
+	struct tree_desc tree_desc;
+	struct tree *tree;
+	unsigned char sha1[20];
+
+	/* ignore if it is an initial commit */
+	if (get_sha1("HEAD", sha1))
+		return 0;
+	tree = parse_tree_indirect(sha1);
+	if (!tree || parse_tree(tree))
+		return error("Could not get HEAD's tree");
+	init_tree_desc(&tree_desc, tree->buffer, tree->size);
+
+	memset(&opts, 0, sizeof(opts));
+	opts.index_only = 1;
+	opts.merge = 1;
+	opts.head_idx = 1;
+	opts.fn = oneway_merge;
+	if (unpack_trees(1, &tree_desc, &opts))
+		return error("Could not reset temporary index to HEAD");
+	return 0;
+}
+
 static char *prepare_index(const char **files, const char *prefix)
 {
 	int fd;
@@ -120,12 +146,14 @@ static char *prepare_index(const char **files, const char *prefix)
 			die("failed to read HEAD tree object");
 	}
 
+	if (reset_index_to_head())
+		die ("failed to reset temporary index to HEAD");
+
 	/* Use a lock file to garbage collect the temporary index file. */
 	next_index_lock = xmalloc(sizeof(*next_index_lock));
 	fd = hold_lock_file_for_update(next_index_lock,
 				       git_path("next-index-%d", getpid()), 1);
 	add_files_to_cache(verbose, prefix, files);
-	refresh_cache(REFRESH_QUIET);
 	if (write_cache(fd, active_cache, active_nr) || close(fd))
 		die("unable to write new_index file");
 
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index c9d65e5..d4d7ed7 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -139,4 +139,14 @@ test_expect_success '--signoff' '
 	diff expect output
 '
 
+test_expect_success 'implicit --only only commits specified files' '
+	echo "tonight: " > take &&
+	echo "over the" > world &&
+	git add world take &&
+	test_tick &&
+	git commit -m partial world &&
+	git diff-tree HEAD^..HEAD -- take &&
+	! git diff-index --cached --exit-code HEAD -- take
+'
+
 test_done
-- 
1.5.3.5.1786.gdaaa

Re: [PATCH] builtin-commit: fix "git add x y && git commit y" committing x, too

[Johannes Schindelin]

Hi,

On Thu, 15 Nov 2007, Johannes Schindelin wrote:

> 
> Earlier, builtin commit would implicitly commit also the staged
> changes.
> 
> This patch fixes that.

This was only lightly tested.  Alas, there is still a subtle bug... the 
generated "Untracked/Staged/ToBeCommitted" list seems off.  I guess we'd 
have to reread the index after resetting it to HEAD and adding the files, 
but before generating that commit message.

Ciao,
Dscho

Re: [PATCH] builtin-commit: fix "git add x y && git commit y" committing x, too

[Kristian Høgsberg]

On Thu, 2007-11-15 at 16:11 +0000, Johannes Schindelin wrote:
> Earlier, builtin commit would implicitly commit also the staged
> changes.
> 
> This patch fixes that.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> 
> 	The function reset_index_to_head() could be moved to somewhere
> 	more central and be reused in builtin-reset.c instead of
> 	reset_index_file() later...
> 
>  builtin-add.c     |    1 +
>  builtin-commit.c  |   30 +++++++++++++++++++++++++++++-
>  t/t7500-commit.sh |   10 ++++++++++
>  3 files changed, 40 insertions(+), 1 deletions(-)
> 
> diff --git a/builtin-add.c b/builtin-add.c
> index 77dcde6..017c8f2 100644
> --- a/builtin-add.c
> +++ b/builtin-add.c
> @@ -100,6 +100,7 @@ static void update_callback(struct diff_queue_struct *q,
>  		case DIFF_STATUS_UNMERGED:
>  		case DIFF_STATUS_MODIFIED:
>  		case DIFF_STATUS_TYPE_CHANGED:
> +		case DIFF_STATUS_ADDED:
>  			add_file_to_cache(path, verbose);
>  			break;
>  		case DIFF_STATUS_DELETED:
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 535039c..0dc6e1c 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -19,6 +19,7 @@
>  #include "strbuf.h"
>  #include "utf8.h"
>  #include "parse-options.h"
> +#include "unpack-trees.h"
>  
>  static const char * const builtin_commit_usage[] = {
>  	"git-commit [options] [--] <filepattern>...",
> @@ -77,6 +78,31 @@ static struct option builtin_commit_options[] = {
>  	OPT_END()
>  };
>  
> +static int reset_index_to_head(void)
> +{
> +	struct unpack_trees_options opts;
> +	struct tree_desc tree_desc;
> +	struct tree *tree;
> +	unsigned char sha1[20];
> +
> +	/* ignore if it is an initial commit */
> +	if (get_sha1("HEAD", sha1))
> +		return 0;
> +	tree = parse_tree_indirect(sha1);
> +	if (!tree || parse_tree(tree))
> +		return error("Could not get HEAD's tree");
> +	init_tree_desc(&tree_desc, tree->buffer, tree->size);
> +
> +	memset(&opts, 0, sizeof(opts));
> +	opts.index_only = 1;
> +	opts.merge = 1;
> +	opts.head_idx = 1;
> +	opts.fn = oneway_merge;
> +	if (unpack_trees(1, &tree_desc, &opts))
> +		return error("Could not reset temporary index to HEAD");
> +	return 0;
> +}
> +
>  static char *prepare_index(const char **files, const char *prefix)
>  {
>  	int fd;
> @@ -120,12 +146,14 @@ static char *prepare_index(const char **files, const char *prefix)
>  			die("failed to read HEAD tree object");
>  	}
>  
> +	if (reset_index_to_head())
> +		die ("failed to reset temporary index to HEAD");
> +

If you look just above where you added these lines, there is code to
deal with this case, except it doesn't work.  I was trying to fix this
too by adding a discard_cache() call before building the temp index, but
then I couldn't add the files in question because the index was now
newer than those files.  Anyway, I don't know if your code is better
that just doing read_tree(), but we should only have one or the other in
there.

Kristian

Re: [PATCH] builtin-commit: fix "git add x y && git commit y" committing x, too

[Johannes Schindelin]

Hi,

On Thu, 15 Nov 2007, Kristian H?gsberg wrote:

> On Thu, 2007-11-15 at 16:11 +0000, Johannes Schindelin wrote:
> > Earlier, builtin commit would implicitly commit also the staged
> > changes.
> > 
> > This patch fixes that.
> > 
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > 
> > 	The function reset_index_to_head() could be moved to somewhere
> > 	more central and be reused in builtin-reset.c instead of
> > 	reset_index_file() later...
> > 
> >  builtin-add.c     |    1 +
> >  builtin-commit.c  |   30 +++++++++++++++++++++++++++++-
> >  t/t7500-commit.sh |   10 ++++++++++
> >  3 files changed, 40 insertions(+), 1 deletions(-)
> > 
> > diff --git a/builtin-add.c b/builtin-add.c
> > index 77dcde6..017c8f2 100644
> > --- a/builtin-add.c
> > +++ b/builtin-add.c
> > @@ -100,6 +100,7 @@ static void update_callback(struct diff_queue_struct *q,
> >  		case DIFF_STATUS_UNMERGED:
> >  		case DIFF_STATUS_MODIFIED:
> >  		case DIFF_STATUS_TYPE_CHANGED:
> > +		case DIFF_STATUS_ADDED:
> >  			add_file_to_cache(path, verbose);
> >  			break;
> >  		case DIFF_STATUS_DELETED:
> > diff --git a/builtin-commit.c b/builtin-commit.c
> > index 535039c..0dc6e1c 100644
> > --- a/builtin-commit.c
> > +++ b/builtin-commit.c
> > @@ -19,6 +19,7 @@
> >  #include "strbuf.h"
> >  #include "utf8.h"
> >  #include "parse-options.h"
> > +#include "unpack-trees.h"
> >  
> >  static const char * const builtin_commit_usage[] = {
> >  	"git-commit [options] [--] <filepattern>...",
> > @@ -77,6 +78,31 @@ static struct option builtin_commit_options[] = {
> >  	OPT_END()
> >  };
> >  
> > +static int reset_index_to_head(void)
> > +{
> > +	struct unpack_trees_options opts;
> > +	struct tree_desc tree_desc;
> > +	struct tree *tree;
> > +	unsigned char sha1[20];
> > +
> > +	/* ignore if it is an initial commit */
> > +	if (get_sha1("HEAD", sha1))
> > +		return 0;
> > +	tree = parse_tree_indirect(sha1);
> > +	if (!tree || parse_tree(tree))
> > +		return error("Could not get HEAD's tree");
> > +	init_tree_desc(&tree_desc, tree->buffer, tree->size);
> > +
> > +	memset(&opts, 0, sizeof(opts));
> > +	opts.index_only = 1;
> > +	opts.merge = 1;
> > +	opts.head_idx = 1;
> > +	opts.fn = oneway_merge;
> > +	if (unpack_trees(1, &tree_desc, &opts))
> > +		return error("Could not reset temporary index to HEAD");
> > +	return 0;
> > +}
> > +
> >  static char *prepare_index(const char **files, const char *prefix)
> >  {
> >  	int fd;
> > @@ -120,12 +146,14 @@ static char *prepare_index(const char **files, const char *prefix)
> >  			die("failed to read HEAD tree object");
> >  	}
> >  
> > +	if (reset_index_to_head())
> > +		die ("failed to reset temporary index to HEAD");
> > +
> 
> If you look just above where you added these lines, there is code to
> deal with this case, except it doesn't work.  I was trying to fix this
> too by adding a discard_cache() call before building the temp index, but
> then I couldn't add the files in question because the index was now
> newer than those files.  Anyway, I don't know if your code is better
> that just doing read_tree(), but we should only have one or the other in
> there.

It's not only about discarding the cache.  It's also about avoiding do 
regenerate the index completely; this would waste time, especially for big 
trees.

But the code you are referencing is only updating the index.  The code I 
added is to build the temporary index in a correct manner.

Unfortunately, I guess that the index as calculated by the code you are 
referencing would be needed to show the correct status.

Therefore I propose to use a different struct index_state, copied from the 
current one, for reset_index_to_head(), add_files_to_index() and 
write_index() instead of working on the_index.

But that has to be done by somebody else than me, or wait for Tuesday, as 
I will be travelling.

Ciao,
Dscho

Re: [PATCH] builtin-commit: fix "git add x y && git commit y" committing x, too

[Junio C Hamano]

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

> It's not only about discarding the cache.  It's also about avoiding do 
> regenerate the index completely; this would waste time, especially for big 
> trees.

I was looking at this code earlier tonight but I am too tired so
here are a few comments before I stop.

> But the code you are referencing is only updating the index.  The code I 
> added is to build the temporary index in a correct manner.

Yes, except that it is only in the partial commit codepath and
there is not much point optimizing it, as there are more to it.

If a path that was not in the HEAD was added to the index
earlier, and the path was named on the command line, the
add_files_to_index() function you are borrowing from the
implementation of "add -u" would not notice it.  Look at the
script version of git-commit.sh and look for places near
"ls-files --error-unmatch --with-tree=HEAD".

I _think_ we need to do the equivalent of this, keep the
affected paths in a path-list and use add_file_to_cache()
instead.  We need to feed the same set of paths to update the
index twice (once for the fake one for partial commit, and
another for the real index to be used after the commit is made),
and (1) using add_files_to_index() is more expensive than
walking a path-list, and (2) add_files_to_index() is a wrong
thing to use anyway (by definition you cannot notice addition
when you are comparing the index and the work tree, so I think
your patch to update_callback() is a no-op).


I noticed that the implementation left next-index crufts almost
every time it was run, and started to clean it up.  Here is
still a WIP and it does not optimize the read_tree(HEAD) part,
but you should be able to replace that part with your one-way
merge easily.  As I haven't done that ls-files --error-unmatch
equivalent, this does not pass tests that involve partial
commits with added or removed paths.

---

 builtin-commit.c |  174 +++++++++++++++++++++++++++++++++++++++++++-----------
 1 files changed, 139 insertions(+), 35 deletions(-)

diff --git a/builtin-commit.c b/builtin-commit.c
index 3e7d281..187d613 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -7,6 +7,7 @@
 
 #include "cache.h"
 #include "cache-tree.h"
+#include "dir.h"
 #include "builtin.h"
 #include "diff.h"
 #include "diffcore.h"
@@ -28,7 +29,13 @@ static const char * const builtin_commit_usage[] = {
 static unsigned char head_sha1[20], merge_head_sha1[20];
 static char *use_message_buffer;
 static const char commit_editmsg[] = "COMMIT_EDITMSG";
-static struct lock_file lock_file;
+static struct lock_file index_lock; /* real index */
+static struct lock_file false_lock; /* used only for partial commits */
+static enum {
+	COMMIT_AS_IS = 1,
+	COMMIT_NORMAL,
+	COMMIT_PARTIAL,
+} commit_style;
 
 static char *logfile, *force_author, *template_file;
 static char *edit_message, *use_message;
@@ -78,41 +85,122 @@ static struct option builtin_commit_options[] = {
 	OPT_END()
 };
 
+static void rollback_index_files(void)
+{
+	switch (commit_style) {
+	case COMMIT_AS_IS:
+		break; /* nothing to do */
+	case COMMIT_NORMAL:
+		rollback_lock_file(&index_lock);
+		break;
+	case COMMIT_PARTIAL:
+		rollback_lock_file(&index_lock);
+		rollback_lock_file(&false_lock);
+		break;
+	}
+}
+
+static void commit_index_files(void)
+{
+	switch (commit_style) {
+	case COMMIT_AS_IS:
+		break; /* nothing to do */
+	case COMMIT_NORMAL:
+		commit_lock_file(&index_lock);
+		break;
+	case COMMIT_PARTIAL:
+		commit_lock_file(&index_lock);
+		rollback_lock_file(&false_lock);
+		break;
+	}
+}
+
 static char *prepare_index(const char **files, const char *prefix)
 {
 	int fd;
 	struct tree *tree;
-	struct lock_file *next_index_lock;
 
 	if (interactive) {
 		interactive_add();
 		return get_index_file();
 	}
 
-	fd = hold_locked_index(&lock_file, 1);
 	if (read_cache() < 0)
 		die("index file corrupt");
 
+	/*
+	 * Non partial, non as-is commit.
+	 *
+	 * (1) get the real index;
+	 * (2) update the_index as necessary;
+	 * (3) write the_index out to the real index (still locked);
+	 * (4) return the name of the locked index file.
+	 *
+	 * The caller should run hooks on the locked real index, and
+	 * (A) if all goes well, commit the real index;
+	 * (B) on failure, rollback the real index.
+	 */
 	if (all || also) {
+		fd = hold_locked_index(&index_lock, 1);
 		add_files_to_cache(verbose, also ? prefix : NULL, files);
 		refresh_cache(REFRESH_QUIET);
 		if (write_cache(fd, active_cache, active_nr) || close(fd))
 			die("unable to write new_index file");
-		return lock_file.filename;
+		commit_style = COMMIT_NORMAL;
+		return index_lock.filename;
 	}
 
+	/*
+	 * As-is commit.
+	 *
+	 * (1) return the name of the real index file.
+	 *
+	 * The caller should run hooks on the real index, and run
+	 * hooks on the real index, and create commit from the_index.
+	 * No lockfile is needed.
+	 */
 	if (*files == NULL) {
-		/* Commit index as-is. */
-		rollback_lock_file(&lock_file);
+		fd = hold_locked_index(&index_lock, 1);
+		refresh_cache(REFRESH_QUIET);
+		if (write_cache(fd, active_cache, active_nr) ||
+		    close(fd) || commit_locked_index(&index_lock))
+			die("unable to write new_index file");
+		commit_style = COMMIT_AS_IS;
 		return get_index_file();
 	}
 
-	/* update the user index file */
+	/*
+	 * A partial commit.
+	 *
+	 * (0) find the set of affected paths [NEEDSWORK: NOT DONE YET]
+	 * (1) get lock on the real index file;
+	 * (2) update the_index with the given paths;
+	 * (3) write the_index out to the real index (still locked);
+	 * (4) get lock on the false index file;
+	 * (5) reset the_index from HEAD, but keep the addition;
+	 * (6) update the_index the same way as (2);
+	 * (7) write the_index out to the false index file;
+	 * (8) return the name of the false index file (still locked);
+	 *
+	 * The caller should run hooks on the locked false index, and
+	 * (A) if all goes well, commit the real index;
+	 * (B) on failure, rollback the real index;
+	 * In either case, rollback the false index.
+	 */
+	commit_style = COMMIT_PARTIAL;
+
+	if (file_exists(git_path("MERGE_HEAD")))
+		die("cannot do a partial commit during a merge.");
+
+	fd = hold_locked_index(&index_lock, 1);
 	add_files_to_cache(verbose, prefix, files);
 	refresh_cache(REFRESH_QUIET);
 	if (write_cache(fd, active_cache, active_nr) || close(fd))
 		die("unable to write new_index file");
 
+	fd = hold_lock_file_for_update(&false_lock,
+				       git_path("next-index-%d", getpid()), 1);
+	discard_cache();
 	if (!initial_commit) {
 		tree = parse_tree_indirect(head_sha1);
 		if (!tree)
@@ -120,17 +208,12 @@ static char *prepare_index(const char **files, const char *prefix)
 		if (read_tree(tree, 0, NULL))
 			die("failed to read HEAD tree object");
 	}
-
-	/* Use a lock file to garbage collect the temporary index file. */
-	next_index_lock = xmalloc(sizeof(*next_index_lock));
-	fd = hold_lock_file_for_update(next_index_lock,
-				       git_path("next-index-%d", getpid()), 1);
 	add_files_to_cache(verbose, prefix, files);
 	refresh_cache(REFRESH_QUIET);
-	if (write_cache(fd, active_cache, active_nr) || close(fd))
-		die("unable to write new_index file");
 
-	return next_index_lock->filename;
+	if (write_cache(fd, active_cache, active_nr) || close(fd))
+		die("unable to write temporary index file");
+	return false_lock.filename;
 }
 
 static int run_status(FILE *fp, const char *index_file, const char *prefix)
@@ -437,7 +520,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 
 	commitable = run_status(stdout, index_file, prefix);
 
-	rollback_lock_file(&lock_file);
+	rollback_index_files();
 
 	return commitable ? 0 : 1;
 }
@@ -527,23 +610,36 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 
 	index_file = prepare_index(argv, prefix);
 
-	if (!no_verify && run_hook(index_file, "pre-commit", NULL))
-		exit(1);
+	if (!no_verify && run_hook(index_file, "pre-commit", NULL)) {
+		rollback_index_files();
+		return 1;
+	}
 
 	if (!prepare_log_message(index_file, prefix) && !in_merge) {
 		run_status(stdout, index_file, prefix);
+		rollback_index_files();
 		unlink(commit_editmsg);
 		return 1;
 	}
 
-	strbuf_init(&sb, 0);
-
-	/* Start building up the commit header */
+	/*
+	 * Re-read the index as pre-commit hook could have updated it,
+	 * and write it out as a tree.
+	 */
+	discard_cache();
 	read_cache_from(index_file);
-	active_cache_tree = cache_tree();
+	if (!active_cache_tree)
+		active_cache_tree = cache_tree();
 	if (cache_tree_update(active_cache_tree,
-			      active_cache, active_nr, 0, 0) < 0)
+			      active_cache, active_nr, 0, 0) < 0) {
+		rollback_index_files();
 		die("Error building trees");
+	}
+
+	/*
+	 * The commit object
+	 */
+	strbuf_init(&sb, 0);
 	strbuf_addf(&sb, "tree %s\n",
 		    sha1_to_hex(active_cache_tree->sha1));
 
@@ -592,20 +688,27 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 	header_len = sb.len;
 	if (!no_edit)
 		launch_editor(git_path(commit_editmsg), &sb);
-	else if (strbuf_read_file(&sb, git_path(commit_editmsg), 0) < 0)
+	else if (strbuf_read_file(&sb, git_path(commit_editmsg), 0) < 0) {
+		rollback_index_files();
 		die("could not read commit message\n");
-	if (run_hook(index_file, "commit-msg", commit_editmsg))
+	}
+	if (run_hook(index_file, "commit-msg", commit_editmsg)) {
+		rollback_index_files();
 		exit(1);
+	}
 	stripspace(&sb, 1);
-	if (sb.len < header_len ||
-	    message_is_empty(&sb, header_len))
+	if (sb.len < header_len || message_is_empty(&sb, header_len)) {
+		rollback_index_files();
 		die("* no commit message?  aborting commit.");
+	}
 	strbuf_addch(&sb, '\0');
 	if (is_encoding_utf8(git_commit_encoding) && !is_utf8(sb.buf))
 		fprintf(stderr, commit_utf8_warn);
 
-	if (write_sha1_file(sb.buf, sb.len - 1, commit_type, commit_sha1))
+	if (write_sha1_file(sb.buf, sb.len - 1, commit_type, commit_sha1)) {
+		rollback_index_files();
 		die("failed to write commit object");
+	}
 
 	ref_lock = lock_any_ref_for_update("HEAD",
 					   initial_commit ? NULL : head_sha1,
@@ -620,21 +723,22 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 	strbuf_insert(&sb, 0, reflog_msg, strlen(reflog_msg));
 	strbuf_insert(&sb, strlen(reflog_msg), ": ", 2);
 
-	if (!ref_lock)
+	if (!ref_lock) {
+		rollback_index_files();
 		die("cannot lock HEAD ref");
-	if (write_ref_sha1(ref_lock, commit_sha1, sb.buf) < 0)
+	}
+	if (write_ref_sha1(ref_lock, commit_sha1, sb.buf) < 0) {
+		rollback_index_files();
 		die("cannot update HEAD ref");
+	}
 
 	unlink(git_path("MERGE_HEAD"));
 	unlink(git_path("MERGE_MSG"));
 
-	if (lock_file.filename[0] && commit_locked_index(&lock_file))
-		die("failed to write new index");
+	commit_index_files();
 
 	rerere();
-
-	run_hook(index_file, "post-commit", NULL);
-
+	run_hook(get_index_file(), "post-commit", NULL);
 	if (!quiet)
 		print_summary(prefix, commit_sha1);
 

Re: [PATCH] builtin-commit: fix "git add x y && git commit y" committing x, too

[Junio C Hamano]

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

> I noticed that the implementation left next-index crufts almost
> every time it was run, and started to clean it up.  Here is
> still a WIP and it does not optimize the read_tree(HEAD) part,
> but you should be able to replace that part with your one-way
> merge easily.  As I haven't done that ls-files --error-unmatch
> equivalent, this does not pass tests that involve partial
> commits with added or removed paths.

I was working on this tonight.  Will send out a proposed fix
based on this WIP shortly.  The result seems to pass all the
tests.

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.

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)

[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)

[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)

[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)

[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)

[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)

[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)

[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>

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

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

[PATCH, next version] Add 'git fast-export', the sister of 'git fast-import'

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 19337 bytes --]


This program dumps (parts of) a git repository in the format that
fast-import understands.

For clarity's sake, it does not use the 'inline' method of specifying
blobs in the commits, but builds the blobs before building the commits.

Since signed tags' signatures will not necessarily be valid (think
transformations after the export, or excluding revisions, changing
the history), there are 4 modes to handle them: abort (default),
ignore, warn and strip.  The latter just turns the tags into
unsigned ones.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Fri, 30 Nov 2007, Junio C Hamano wrote:

	> * 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)

	How about this instead?

	(It uses ((uint32_t *)NULL) + number, which should be quite 
	portable.)

 .gitignore                        |    1 +
 Documentation/git-fast-export.txt |   83 ++++++++
 Makefile                          |    1 +
 builtin-fast-export.c             |  410 +++++++++++++++++++++++++++++++++++++
 builtin.h                         |    1 +
 t/t9301-fast-export.sh            |  124 +++++++++++
 6 files changed, 620 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/git-fast-export.txt
 create mode 100755 builtin-fast-export.c
 create mode 100755 t/t9301-fast-export.sh

diff --git a/.gitignore b/.gitignore
index 6564618..8694d02 100644
--- a/.gitignore
+++ b/.gitignore
@@ -35,6 +35,7 @@ git-diff-files
 git-diff-index
 git-diff-tree
 git-describe
+git-fast-export
 git-fast-import
 git-fetch
 git-fetch--tool
diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
new file mode 100644
index 0000000..073ff7f
--- /dev/null
+++ b/Documentation/git-fast-export.txt
@@ -0,0 +1,83 @@
+git-fast-export(1)
+==================
+
+NAME
+----
+git-fast-export - Git data exporter
+
+
+SYNOPSIS
+--------
+'git-fast-export [options]' | 'git-fast-import'
+
+DESCRIPTION
+-----------
+This program dumps the given revisions in a form suitable to be piped
+into gitlink:git-fast-import[1].
+
+You can use it as a human readable bundle replacement (see
+gitlink:git-bundle[1]), or as a kind of an interactive
+gitlink:git-filter-branch[1].
+
+
+OPTIONS
+-------
+--progress=<n>::
+	Insert 'progress' statements every <n> objects, to be shown by
+	gitlink:git-fast-import[1] during import.
+
+--signed-tags=(ignore|warn|strip|abort)::
+	Specify how to handle signed tags.  Since any transformation
+	after the export can change the tag names (which can also happen
+	when excluding revisions) the signatures will not match.
++
+When asking to 'abort' (which is the default), this program will die
+when encountering a signed tag.  With 'strip', the tags will be made
+unsigned, with 'ignore', they will be silently ignored (i.e. not exported)
+and with 'warn', they will be exported, but you will see a warning.
+
+
+EXAMPLES
+--------
+
+-------------------------------------------------------------------
+$ git fast-export --all | (cd /empty/repository && git fast-import)
+-------------------------------------------------------------------
+
+This will export the whole repository and import it into the existing
+empty repository.  Except for reencoding commits that are not in
+UTF-8, it would be a one-to-one mirror.
+
+-----------------------------------------------------
+$ git fast-export master~5..master |
+	sed "s|refs/heads/master|refs/heads/other|" |
+	git fast-import
+-----------------------------------------------------
+
+This makes a new branch called 'other' from 'master~5..master'
+(i.e. if 'master' has linear history, it will take the last 5 commits).
+
+Note that this assumes that none of the blobs and commit messages
+referenced by that revision range contains the string
+'refs/heads/master'.
+
+
+Limitations
+-----------
+
+Since gitlink:git-fast-import[1] cannot tag trees, you will not be
+able to export the linux-2.6.git repository completely, as it contains
+a tag referencing a tree instead of a commit.
+
+
+Author
+------
+Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
+
+Documentation
+--------------
+Documentation by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Makefile b/Makefile
index 6b9131b..f9a62eb 100644
--- a/Makefile
+++ b/Makefile
@@ -338,6 +338,7 @@ BUILTIN_OBJS = \
 	builtin-diff-files.o \
 	builtin-diff-index.o \
 	builtin-diff-tree.o \
+	builtin-fast-export.o \
 	builtin-fetch.o \
 	builtin-fetch-pack.o \
 	builtin-fetch--tool.o \
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
new file mode 100755
index 0000000..570bce6
--- /dev/null
+++ b/builtin-fast-export.c
@@ -0,0 +1,410 @@
+/*
+ * "git fast-export" builtin command
+ *
+ * Copyright (C) 2007 Johannes E. Schindelin
+ */
+#include "builtin.h"
+#include "cache.h"
+#include "commit.h"
+#include "object.h"
+#include "tag.h"
+#include "diff.h"
+#include "diffcore.h"
+#include "log-tree.h"
+#include "revision.h"
+#include "decorate.h"
+#include "path-list.h"
+#include "utf8.h"
+#include "parse-options.h"
+
+/*
+ * TODO:
+ * - tags (--signed-tags=(ignore|warn|strip|abort)
+ */
+
+static const char *fast_export_usage[] = {
+	"git-fast-export [rev-list-opts]",
+	NULL
+};
+
+static int progress;
+static enum { IGNORE, WARN, STRIP, ABORT } signed_tag_mode = ABORT;
+
+static int parse_opt_signed_tag_mode(const struct option *opt,
+		 const char *arg, int unset)
+{
+	if (unset || !strcmp(arg, "abort"))
+		signed_tag_mode = ABORT;
+	else if (!strcmp(arg, "ignore"))
+		signed_tag_mode = IGNORE;
+	else if (!strcmp(arg, "warn"))
+		signed_tag_mode = WARN;
+	else if (!strcmp(arg, "strip"))
+		signed_tag_mode = STRIP;
+	else
+		return error("Unknown signed-tag mode: %s", arg);
+	return 0;
+}
+
+static struct decoration idnums;
+static uint32_t last_idnum;
+
+static int has_unshown_parent(struct commit *commit)
+{
+	struct commit_list *parent;
+
+	for (parent = commit->parents; parent; parent = parent->next)
+		if (!(parent->item->object.flags & SHOWN) &&
+				!(parent->item->object.flags & UNINTERESTING))
+			return 1;
+	return 0;
+}
+
+/* Since intptr_t is C99, we do not use it here */
+static void mark_object(struct object *object)
+{
+	last_idnum++;
+	add_decoration(&idnums, object, ((uint32_t *)NULL) + last_idnum);
+}
+
+static int get_object_mark(struct object *object)
+{
+	void *decoration = lookup_decoration(&idnums, object);
+	if (!decoration)
+		return 0;
+	return (uint32_t *)decoration - (uint32_t *)NULL;
+}
+
+static void show_progress(void)
+{
+	static int counter = 0;
+	if (!progress)
+		return;
+	if ((++counter % progress) == 0)
+		printf("progress %d objects\n", counter);
+}
+
+static void handle_object(const unsigned char *sha1)
+{
+	unsigned long size;
+	enum object_type type;
+	char *buf;
+	struct object *object;
+
+	if (is_null_sha1(sha1))
+		return;
+
+	object = parse_object(sha1);
+	if (!object)
+		die ("Could not read blob %s", sha1_to_hex(sha1));
+
+	if (object->flags & SHOWN)
+		return;
+
+	buf = read_sha1_file(sha1, &type, &size);
+	if (!buf)
+		die ("Could not read blob %s", sha1_to_hex(sha1));
+
+	mark_object(object);
+
+	printf("blob\nmark :%d\ndata %lu\n", last_idnum, size);
+	if (fwrite(buf, size, 1, stdout) != 1)
+		die ("Could not write blob %s", sha1_to_hex(sha1));
+	printf("\n");
+
+	show_progress();
+
+	object->flags |= SHOWN;
+	free(buf);
+}
+
+static void show_filemodify(struct diff_queue_struct *q,
+		struct diff_options *options, void *data)
+{
+	int i;
+	for (i = 0; i < q->nr; i++) {
+		struct diff_filespec *spec = q->queue[i]->two;
+		if (is_null_sha1(spec->sha1))
+			printf("D %s\n", spec->path);
+		else {
+			struct object *object = lookup_object(spec->sha1);
+			printf("M 0%06o :%d %s\n", spec->mode,
+					get_object_mark(object), spec->path);
+		}
+	}
+}
+
+static const char *find_encoding(const char *begin, const char *end)
+{
+	const char *needle = "\nencoding ";
+	char *bol, *eol;
+
+	bol = memmem(begin, end ? end - begin : strlen(begin),
+		needle, strlen(needle));
+	if (!bol)
+		return git_commit_encoding;
+	bol += strlen(needle);
+	eol = strchrnul(bol, '\n');
+	*eol = '\0';
+	return bol;
+}
+
+static void handle_commit(struct commit *commit, struct rev_info *rev)
+{
+	int saved_output_format = rev->diffopt.output_format;
+	const char *author, *author_end, *committer, *committer_end;
+	const char *encoding, *message;
+	char *reencoded = NULL;
+	struct commit_list *p;
+	int i;
+
+	rev->diffopt.output_format = DIFF_FORMAT_CALLBACK;
+
+	parse_commit(commit);
+	author = strstr(commit->buffer, "\nauthor ");
+	if (!author)
+		die ("Could not find author in commit %s",
+				sha1_to_hex(commit->object.sha1));
+	author++;
+	author_end = strchrnul(author, '\n');
+	committer = strstr(author_end, "\ncommitter ");
+	if (!committer)
+		die ("Could not find committer in commit %s",
+				sha1_to_hex(commit->object.sha1));
+	committer++;
+	committer_end = strchrnul(committer, '\n');
+	message = strstr(committer_end, "\n\n");
+	encoding = find_encoding(committer_end, message);
+	if (message)
+		message += 2;
+
+	if (commit->parents) {
+		parse_commit(commit->parents->item);
+		diff_tree_sha1(commit->parents->item->tree->object.sha1,
+				commit->tree->object.sha1, "", &rev->diffopt);
+	}
+	else
+		diff_root_tree_sha1(commit->tree->object.sha1,
+				"", &rev->diffopt);
+
+	for (i = 0; i < diff_queued_diff.nr; i++)
+		handle_object(diff_queued_diff.queue[i]->two->sha1);
+
+	mark_object(&commit->object);
+	if (!is_encoding_utf8(encoding))
+		reencoded = reencode_string(message, "UTF-8", encoding);
+	printf("commit %s\nmark :%d\n%.*s\n%.*s\ndata %u\n%s",
+		(const char *)commit->util, last_idnum,
+		(int)(author_end - author), author,
+		(int)(committer_end - committer), committer,
+		reencoded ? strlen(reencoded) : message ? strlen(message) : 0,
+		reencoded ? reencoded : message ? message : "");
+	if (reencoded)
+		free(reencoded);
+
+	for (i = 0, p = commit->parents; p; p = p->next) {
+		int mark = get_object_mark(&p->item->object);
+		if (!mark)
+			continue;
+		if (i == 0)
+			printf("from :%d\n", mark);
+		else if (i == 1)
+			printf("merge :%d", mark);
+		else
+			printf(" :%d", mark);
+		i++;
+	}
+	if (i > 1)
+		printf("\n");
+
+	log_tree_diff_flush(rev);
+	rev->diffopt.output_format = saved_output_format;
+
+	printf("\n");
+
+	show_progress();
+}
+
+static void handle_tail(struct object_array *commits, struct rev_info *revs)
+{
+	struct commit *commit;
+	while (commits->nr) {
+		commit = (struct commit *)commits->objects[commits->nr - 1].item;
+		if (has_unshown_parent(commit))
+			return;
+		handle_commit(commit, revs);
+		commits->nr--;
+	}
+}
+
+static void handle_tag(const char *name, struct tag *tag)
+{
+        unsigned long size;
+        enum object_type type;
+	char *buf;
+	const char *tagger, *tagger_end, *message;
+	size_t message_size = 0;
+
+	buf = read_sha1_file(tag->object.sha1, &type, &size);
+	if (!buf)
+		die ("Could not read tag %s", sha1_to_hex(tag->object.sha1));
+	message = memmem(buf, size, "\n\n", 2);
+	if (message) {
+		message += 2;
+		message_size = strlen(message);
+	}
+	tagger = memmem(buf, message ? message - buf : size, "\ntagger ", 8);
+	if (!tagger)
+		die ("No tagger for tag %s", sha1_to_hex(tag->object.sha1));
+	tagger++;
+	tagger_end = strchrnul(tagger, '\n');
+
+	/* handle signed tags */
+	if (message) {
+		const char *signature = strstr(message,
+			"\n-----BEGIN PGP SIGNATURE-----\n");
+		if (signature)
+			switch(signed_tag_mode) {
+			case ABORT:
+				die ("Encountered signed tag %s; use "
+					"--signed-tag=<mode> to handle it.",
+					sha1_to_hex(tag->object.sha1));
+			case WARN:
+				warning ("Exporting signed tag %s",
+					sha1_to_hex(tag->object.sha1));
+				/* fallthru */
+			case IGNORE:
+				break;
+			case STRIP:
+				message_size = signature + 1 - message;
+				break;
+			}
+	}
+
+	if (!prefixcmp(name, "refs/tags/"))
+		name += 10;
+	printf("tag %s\nfrom :%d\n%.*s\ndata %d\n%.*s\n",
+		name, get_object_mark(tag->tagged),
+		(int)(tagger_end - tagger), tagger,
+		(int)message_size, message_size, message ? message : "");
+}
+
+static void get_tags_and_duplicates(struct object_array *pending,
+		struct path_list *extra_refs)
+{
+	struct commit *commit;
+	struct tag *tag;
+	int i;
+
+	for (i = 0; i < pending->nr; i++) {
+		struct object_array_entry *e = pending->objects + i;
+		unsigned char sha1[20];
+		char *full_name;
+
+		if (dwim_ref(e->name, strlen(e->name), sha1, &full_name) != 1)
+			continue;
+
+		switch (e->item->type) {
+		case OBJ_COMMIT:
+			commit = (struct commit *)e->item;
+			break;
+		case OBJ_TAG:
+			tag = (struct tag *)e->item;
+			while (tag && tag->object.type == OBJ_TAG) {
+				path_list_insert(full_name, extra_refs)->util
+					= tag;
+				tag = (struct tag *)tag->tagged;
+			}
+			if (!tag)
+				die ("Tag %s points nowhere?", e->name);
+			switch(tag->object.type) {
+			case OBJ_COMMIT:
+				commit = (struct commit *)tag;
+				break;
+			case OBJ_BLOB:
+				handle_object(tag->object.sha1);
+				continue;
+			}
+			break;
+		default:
+			die ("Unexpected object of type %s",
+					typename(e->item->type));
+		}
+		if (commit->util)
+			/* more than one name for the same object */
+			path_list_insert(full_name, extra_refs)->util = commit;
+		else
+			commit->util = full_name;
+	}
+}
+
+static void handle_tags_and_duplicates(struct path_list *extra_refs)
+{
+	struct commit *commit;
+	int i;
+
+	for (i = extra_refs->nr - 1; i >= 0; i--) {
+		const char *name = extra_refs->items[i].path;
+		struct object *object = extra_refs->items[i].util;
+		switch (object->type) {
+		case OBJ_TAG:
+			handle_tag(name, (struct tag *)object);
+			break;
+		case OBJ_COMMIT:
+			/* create refs pointing to already seen commits */
+			commit = (struct commit *)object;
+			printf("reset %s\nfrom :%d\n\n", name,
+					get_object_mark(&commit->object));
+			show_progress();
+			break;
+		}
+	}
+}
+
+int cmd_fast_export(int argc, const char **argv, const char *prefix)
+{
+	struct rev_info revs;
+	struct object_array commits = { 0, 0, NULL };
+	struct path_list extra_refs = { NULL, 0, 0, 0 };
+	struct commit *commit;
+	struct option options[] = {
+		OPT_INTEGER(0, "progress", &progress,
+				"show progress after <n> objects"),
+		OPT_CALLBACK(0, "signed-tags", &signed_tag_mode, "mode",
+				"select handling of signed tags",
+				parse_opt_signed_tag_mode),
+		OPT_END()
+	};
+
+	/* we handle encodings */
+	git_config(git_default_config);
+
+	init_revisions(&revs, prefix);
+	argc = setup_revisions(argc, argv, &revs, NULL);
+	argc = parse_options(argc, argv, options, fast_export_usage, 0);
+	if (argc > 1)
+		usage_with_options (fast_export_usage, options);
+
+	get_tags_and_duplicates(&revs.pending, &extra_refs);
+
+	prepare_revision_walk(&revs);
+	revs.diffopt.format_callback = show_filemodify;
+	DIFF_OPT_SET(&revs.diffopt, RECURSIVE);
+	while ((commit = get_revision(&revs))) {
+		if (has_unshown_parent(commit)) {
+			struct commit_list *parent = commit->parents;
+			add_object_array(&commit->object, NULL, &commits);
+			for (; parent; parent = parent->next)
+				if (!parent->item->util)
+					parent->item->util = commit->util;
+		}
+		else {
+			handle_commit(commit, &revs);
+			handle_tail(&commits, &revs);
+		}
+	}
+
+	handle_tags_and_duplicates(&extra_refs);
+
+	return 0;
+}
diff --git a/builtin.h b/builtin.h
index 3055bcc..142ab63 100644
--- a/builtin.h
+++ b/builtin.h
@@ -33,6 +33,7 @@ extern int cmd_diff_files(int argc, const char **argv, const char *prefix);
 extern int cmd_diff_index(int argc, const char **argv, const char *prefix);
 extern int cmd_diff(int argc, const char **argv, const char *prefix);
 extern int cmd_diff_tree(int argc, const char **argv, const char *prefix);
+extern int cmd_fast_export(int argc, const char **argv, const char *prefix);
 extern int cmd_fetch(int argc, const char **argv, const char *prefix);
 extern int cmd_fetch_pack(int argc, const char **argv, const char *prefix);
 extern int cmd_fetch__tool(int argc, const char **argv, const char *prefix);
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
new file mode 100755
index 0000000..59f6996
--- /dev/null
+++ b/t/t9301-fast-export.sh
@@ -0,0 +1,124 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E. Schindelin
+#
+
+test_description='git-fast-export'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+	echo Wohlauf > file &&
+	git add file &&
+	test_tick &&
+	git commit -m initial &&
+	echo die Luft > file &&
+	echo geht frisch > file2 &&
+	git add file file2 &&
+	test_tick &&
+	git commit -m second &&
+	echo und > file2 &&
+	test_tick &&
+	git commit -m third file2 &&
+	test_tick &&
+	git tag rein &&
+	git checkout -b wer HEAD^ &&
+	echo lange > file2
+	test_tick &&
+	git commit -m sitzt file2 &&
+	test_tick &&
+	git tag -a -m valentin muss &&
+	git merge -s ours master
+
+'
+
+test_expect_success 'fast-export | fast-import' '
+
+	MASTER=$(git rev-parse --verify master) &&
+	REIN=$(git rev-parse --verify rein) &&
+	WER=$(git rev-parse --verify wer) &&
+	MUSS=$(git rev-parse --verify muss) &&
+	mkdir new &&
+	git --git-dir=new/.git init &&
+	git fast-export --all |
+	(cd new &&
+	 git fast-import &&
+	 test $MASTER = $(git rev-parse --verify refs/heads/master) &&
+	 test $REIN = $(git rev-parse --verify refs/tags/rein) &&
+	 test $WER = $(git rev-parse --verify refs/heads/wer) &&
+	 test $MUSS = $(git rev-parse --verify refs/tags/muss))
+
+'
+
+test_expect_success 'fast-export master~2..master' '
+
+	git fast-export master~2..master |
+		sed "s/master/partial/" |
+		(cd new &&
+		 git fast-import &&
+		 test $MASTER != $(git rev-parse --verify refs/heads/partial) &&
+		 git diff master..partial &&
+		 git diff master^..partial^ &&
+		 ! git rev-parse partial~2)
+
+'
+
+test_expect_success 'iso-8859-1' '
+
+        git config i18n.commitencoding ISO-8859-1 &&
+        # use author and committer name in ISO-8859-1 to match it.
+        . ../t3901-8859-1.txt &&
+        test_tick &&
+        echo rosten >file &&
+        git commit -s -m den file &&
+	git fast-export wer^..wer |
+		sed "s/wer/i18n/" |
+		(cd new &&
+		 git fast-import &&
+		 git cat-file commit i18n | grep "Áéí óú")
+
+'
+
+cat > signed-tag-import << EOF
+tag sign-your-name
+from $(git rev-parse HEAD)
+tagger C O Mitter <committer@example.com> 1112911993 -0700
+data 210
+A message for a sign
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.5 (GNU/Linux)
+
+fakedsignaturefakedsignaturefakedsignaturefakedsignaturfakedsign
+aturefakedsignaturefake=
+=/59v
+-----END PGP SIGNATURE-----
+EOF
+
+test_expect_success 'set up faked signed tag' '
+
+	cat signed-tag-import | git fast-import
+
+'
+
+test_expect_success 'signed-tags=abort' '
+
+	! git fast-export --signed-tags=abort sign-your-name
+
+'
+
+test_expect_success 'signed-tags=ignore' '
+
+	git fast-export --signed-tags=ignore sign-your-name > output &&
+	grep PGP output
+
+'
+
+test_expect_success 'signed-tags=strip' '
+
+	git fast-export --signed-tags=strip sign-your-name > output &&
+	! grep PGP output
+
+'
+
+test_done
+
-- 
1.5.3.6.2112.ge2263

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

msysGit on FAT32 (was: What's cooking in git.git (topics))

[Jakub Narebski]

Johannes Sixt <j.sixt@viscovery.net> writes:

> 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. ;)

Would it be possible to add option to an installer to _not_ install
git-cmd form for builtins when installing on FAT28^W FAT32?

-- 
Jakub Narebski
ShadeHawk on #git
Poland

Re: msysGit on FAT32 (was: What's cooking in git.git (topics))

[Johannes Schindelin]

Hi,

On Tue, 4 Dec 2007, Jakub Narebski wrote:

> Johannes Sixt <j.sixt@viscovery.net> writes:
> 
> > 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. ;)
> 
> Would it be possible to add option to an installer to _not_ install 
> git-cmd form for builtins when installing on FAT28^W FAT32?

It is the InnoSetup based installer that does that.  MSys has no way (yet) 
to create hard links (at least that's the state of my knowledge).

Ciao,
Dscho

Re: msysGit on FAT32

[Johannes Sixt]

Johannes Schindelin schrieb:
> On Tue, 4 Dec 2007, Jakub Narebski wrote:
> 
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>
>>> 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. ;)
>> Would it be possible to add option to an installer to _not_ install 
>> git-cmd form for builtins when installing on FAT28^W FAT32?
> 
> It is the InnoSetup based installer that does that.  MSys has no way (yet) 
> to create hard links (at least that's the state of my knowledge).

I don't know about MSys, the runtime, but MSys's 'ln' and 'cp -l' both 
create hardlinks on NTFS. And for this reason, 'git clone -l' does, too.

-- Hannes

Re: msysGit on FAT32

[Johannes Schindelin]

Hi,

On Tue, 4 Dec 2007, Johannes Sixt wrote:

> Johannes Schindelin schrieb:
> > On Tue, 4 Dec 2007, Jakub Narebski wrote:
> > 
> > > Johannes Sixt <j.sixt@viscovery.net> writes:
> > > 
> > > > 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. ;)
> > > Would it be possible to add option to an installer to _not_ install
> > > git-cmd form for builtins when installing on FAT28^W FAT32?
> > 
> > It is the InnoSetup based installer that does that.  MSys has no way (yet)
> > to create hard links (at least that's the state of my knowledge).
> 
> I don't know about MSys, the runtime, but MSys's 'ln' and 'cp -l' both create
> hardlinks on NTFS. And for this reason, 'git clone -l' does, too.

Does it?  *goestocheck* Indeed it works!  (The hardest part was to verify 
it; seems like you have to use MSys' stat.exe, as regular Windows seems to 
have _no_ tool to find that out.)

Thanks,
Dscho

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)

[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

[PATCH] Soft aliases: add "less" and minimal documentation

[Johannes Schindelin]

Now you can use "git less HEAD" to view the raw HEAD commit object.  It
is really a soft alias (i.e. it can be overridden by any user-specified
alias) to "-p cat-file -p".

This commit refactors the code a bit, to make adding new soft aliases
much easier.

It also adds a few lines in git.txt, so that users actually have a chance
to find out about soft aliases.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Wed, 5 Dec 2007, 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.

	How about this?

	BTW now it should be easy to add soft aliases for "update", "up",
	"checkin" and "ci".

 Documentation/git.txt |    9 +++++++++
 git.c                 |   13 +++++++++++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Documentation/git.txt b/Documentation/git.txt
index c4e4d24..d29dfdc 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -248,6 +248,15 @@ users typically do not use them directly.
 include::cmds-purehelpers.txt[]
 
 
+Soft aliases
+~~~~~~~~~~~~
+
+There are a few hard-coded aliases which can be overridden by explicit
+aliases (see gitlink:git-config[1]).  These include "view" for viewing
+the repository graphically, and "less" to show an object from the
+database using the pager.
+
+
 Configuration Mechanism
 -----------------------
 
diff --git a/git.c b/git.c
index 92cc49b..3c82f80 100644
--- a/git.c
+++ b/git.c
@@ -148,10 +148,19 @@ static int split_cmdline(char *cmdline, const char ***argv)
 	return count;
 }
 
+static struct {
+	const char *alias, *command;
+} builtin_aliases[] = {
+	{ "view", "!gitk" },
+	{ "less", "-p cat-file -p" },
+};
+
 static char *builtin_alias(const char *cmd)
 {
-	if (!strcmp(cmd, "view"))
-		return xstrdup("!gitk");
+	int i;
+	for (i = 0; i < ARRAY_SIZE(builtin_aliases); i++)
+		if (!strcmp(cmd, builtin_aliases[i].alias))
+			return xstrdup(builtin_aliases[i].command);
 	return NULL;
 }
 
-- 
1.5.3.7.2139.g2a5a3

Re: [PATCH] Soft aliases: add "less" and minimal documentation

[Junio C Hamano]

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

> Now you can use "git less HEAD" to view the raw HEAD commit object.  It
> is really a soft alias (i.e. it can be overridden by any user-specified
> alias) to "-p cat-file -p".

I actually regret to have suggested "git less".  Not only because you
can always say "git show" instead, but because the error message you
would get with usage string will _not_ say "git-less", but some other
command's name if you say "git less nonsense".

I on the other hand find the "view" alias moderately less problematic.
As long as the future direction for the "view" alias is to allow it to
notice user preference and launch something other than the default
"gitk", iow, it is crystal clear that "git view" is just a short-hand
for launching a history browser and the users are free to choose
whichever viewer available, it won't feel inconsistent if underlying
"gitk" barfed on malformed input using its own name.

But then the users can do all that themselves.  People who like qgit do
not have to configure "git view" to launch qgit but instead run their
favorite program directly.  One thing the built-in alias is possibly
bringing to the table is to give smaller number of commands people need
to learn, without having to know "gitk", "qgit", "tig", "gitview",
"instaweb", and possibly others, while at the same time enforcing a
policy that the history viewer of choice is aliased to "git view" (not
"git viewer" or "git visualize") to maintain a bit of consistency across
users.

By extension to this reasoning, I am not too keen on adding "update",
"up", "checkin", "ci", nor "co".  I do not think of any alternative
backend implementations to these aliases, which means that there isn't
even the advantage of giving a single front-end that lets the user do
the same thing using a choice from multiple backends and keeps the
interface simple for these names.

Re: [PATCH] Soft aliases: add "less" and minimal documentation

[Jeff King]

On Wed, Dec 05, 2007 at 11:45:23AM -0800, Junio C Hamano wrote:

> I actually regret to have suggested "git less".  Not only because you
> can always say "git show" instead, but because the error message you
> would get with usage string will _not_ say "git-less", but some other
> command's name if you say "git less nonsense".
> 
> I on the other hand find the "view" alias moderately less problematic.
> As long as the future direction for the "view" alias is to allow it to
> notice user preference and launch something other than the default
> "gitk", iow, it is crystal clear that "git view" is just a short-hand
> for launching a history browser and the users are free to choose
> whichever viewer available, it won't feel inconsistent if underlying
> "gitk" barfed on malformed input using its own name.

The pattern I see here is that we get into trouble when we _pretend_
that builtin aliases are real commands, and not just handy shortcuts for
the real commands.

IOW, if a user is told that "git less" is the command to look at
objects, then they will:

  1. get confused when "git less" claims to be "git cat-file" or "git
     show" in error messages
  2. get confused when there is no "git less" manpage
  3. get confused when their coworker's "git less" behaves completely
     differently

OTOH, if a user is told that "git less" is an alias for the user's
preferred method for viewing objects, that the default is "git show",
and that they can customize it themselves using alias.less, then I don't
think any of the above will be surprising.

So I think it is a bad idea to use such aliases to satisfy user requests
for simple commands, even when they can obviously be implemented as such
an alias.

That being said...

> By extension to this reasoning, I am not too keen on adding "update",
> "up", "checkin", "ci", nor "co".  I do not think of any alternative

I think "checkin", "ci", and "co" are well-understood as aliases (and
will be doubly so if they are presented in the documentation as such).

After all, they come from CVS, which treats them this way:

$ cvs co
cvs checkout: No CVSROOT specified!  Please use the `-d' option
    ^^^^^^^^

-Peff

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 &&

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

[PATCH 1/2] xdl_diff: identify call sites.

[Junio C Hamano]

This inserts a new function xdi_diff() that currently does not
do anything other than calling the underlying xdl_diff() to the
callchain of current callers of xdl_diff() function.

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

 Nicolas Pitre <nico@cam.org> writes:

 > 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>)

 I would prefer to do a bit more generic solution, not a special hack for
 speeding up blame on prepend-only files, with a proper log message.

 Here is the first installment of such.

 builtin-blame.c   |    2 +-
 builtin-rerere.c  |    2 +-
 combine-diff.c    |    2 +-
 diff.c            |   10 +++++-----
 merge-file.c      |    2 +-
 merge-tree.c      |    2 +-
 xdiff-interface.c |    5 +++++
 xdiff-interface.h |    1 +
 8 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/builtin-blame.c b/builtin-blame.c
index 5466d01..99ea0a0 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -542,7 +542,7 @@ static struct patch *compare_buffer(mmfile_t *file_p, mmfile_t *file_o,
 	state.ret->chunks = NULL;
 	state.ret->num = 0;
 
-	xdl_diff(file_p, file_o, &xpp, &xecfg, &ecb);
+	xdi_diff(file_p, file_o, &xpp, &xecfg, &ecb);
 
 	if (state.ret->num) {
 		struct chunk *chunk;
diff --git a/builtin-rerere.c b/builtin-rerere.c
index 7449323..37e6248 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -260,7 +260,7 @@ static int diff_two(const char *file1, const char *label1,
 	memset(&xecfg, 0, sizeof(xecfg));
 	xecfg.ctxlen = 3;
 	ecb.outf = outf;
-	xdl_diff(&minus, &plus, &xpp, &xecfg, &ecb);
+	xdi_diff(&minus, &plus, &xpp, &xecfg, &ecb);
 
 	free(minus.ptr);
 	free(plus.ptr);
diff --git a/combine-diff.c b/combine-diff.c
index 5a658dc..e22db89 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -226,7 +226,7 @@ static void combine_diff(const unsigned char *parent, mmfile_t *result_file,
 	state.num_parent = num_parent;
 	state.n = n;
 
-	xdl_diff(&parent_file, result_file, &xpp, &xecfg, &ecb);
+	xdi_diff(&parent_file, result_file, &xpp, &xecfg, &ecb);
 	free(parent_file.ptr);
 
 	/* Assign line numbers for this parent.
diff --git a/diff.c b/diff.c
index 9c79ee2..3dd2f35 100644
--- a/diff.c
+++ b/diff.c
@@ -439,7 +439,7 @@ static void diff_words_show(struct diff_words_data *diff_words)
 	ecb.outf = xdiff_outf;
 	ecb.priv = diff_words;
 	diff_words->xm.consume = fn_out_diff_words_aux;
-	xdl_diff(&minus, &plus, &xpp, &xecfg, &ecb);
+	xdi_diff(&minus, &plus, &xpp, &xecfg, &ecb);
 
 	free(minus.ptr);
 	free(plus.ptr);
@@ -1393,7 +1393,7 @@ static void builtin_diff(const char *name_a,
 		if (DIFF_OPT_TST(o, COLOR_DIFF_WORDS))
 			ecbdata.diff_words =
 				xcalloc(1, sizeof(struct diff_words_data));
-		xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
+		xdi_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
 		if (DIFF_OPT_TST(o, COLOR_DIFF_WORDS))
 			free_diff_words_data(&ecbdata);
 	}
@@ -1446,7 +1446,7 @@ static void builtin_diffstat(const char *name_a, const char *name_b,
 		xpp.flags = XDF_NEED_MINIMAL | o->xdl_opts;
 		ecb.outf = xdiff_outf;
 		ecb.priv = diffstat;
-		xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
+		xdi_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
 	}
 
  free_and_return:
@@ -1486,7 +1486,7 @@ static void builtin_checkdiff(const char *name_a, const char *name_b,
 		xpp.flags = XDF_NEED_MINIMAL;
 		ecb.outf = xdiff_outf;
 		ecb.priv = &data;
-		xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
+		xdi_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
 	}
  free_and_return:
 	diff_free_filespec_data(one);
@@ -2898,7 +2898,7 @@ static int diff_get_patch_id(struct diff_options *options, unsigned char *sha1)
 		xecfg.flags = XDL_EMIT_FUNCNAMES;
 		ecb.outf = xdiff_outf;
 		ecb.priv = &data;
-		xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
+		xdi_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
 	}
 
 	SHA1_Final(sha1, &ctx);
diff --git a/merge-file.c b/merge-file.c
index 1e031ea..2a939c9 100644
--- a/merge-file.c
+++ b/merge-file.c
@@ -71,7 +71,7 @@ static int generate_common_file(mmfile_t *res, mmfile_t *f1, mmfile_t *f2)
 	res->size = 0;
 
 	ecb.priv = res;
-	return xdl_diff(f1, f2, &xpp, &xecfg, &ecb);
+	return xdi_diff(f1, f2, &xpp, &xecfg, &ecb);
 }
 
 void *merge_file(struct blob *base, struct blob *our, struct blob *their, unsigned long *size)
diff --git a/merge-tree.c b/merge-tree.c
index 7d4f628..e083246 100644
--- a/merge-tree.c
+++ b/merge-tree.c
@@ -119,7 +119,7 @@ static void show_diff(struct merge_list *entry)
 	if (!dst.ptr)
 		size = 0;
 	dst.size = size;
-	xdl_diff(&src, &dst, &xpp, &xecfg, &ecb);
+	xdi_diff(&src, &dst, &xpp, &xecfg, &ecb);
 	free(src.ptr);
 	free(dst.ptr);
 }
diff --git a/xdiff-interface.c b/xdiff-interface.c
index be866d1..69a022c 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -103,6 +103,11 @@ int xdiff_outf(void *priv_, mmbuffer_t *mb, int nbuf)
 	return 0;
 }
 
+int xdi_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp, xdemitconf_t const *xecfg, xdemitcb_t *xecb)
+{
+	return xdl_diff(mf1, mf2, xpp, xecfg, xecb);
+}
+
 int read_mmfile(mmfile_t *ptr, const char *filename)
 {
 	struct stat st;
diff --git a/xdiff-interface.h b/xdiff-interface.h
index fb742db..f7f791d 100644
--- a/xdiff-interface.h
+++ b/xdiff-interface.h
@@ -13,6 +13,7 @@ struct xdiff_emit_state {
 	unsigned long remainder_size;
 };
 
+int xdi_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp, xdemitconf_t const *xecfg, xdemitcb_t *ecb);
 int xdiff_outf(void *priv_, mmbuffer_t *mb, int nbuf);
 int parse_hunk_header(char *line, int len,
 		      int *ob, int *on,
-- 
1.5.4.rc0.1.g37d0

Re: [PATCH 1/2] xdl_diff: identify call sites.

[Junio C Hamano]

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

> This inserts a new function xdi_diff() that currently does not
> do anything other than calling the underlying xdl_diff() to the
> callchain of current callers of xdl_diff() function.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
>  Nicolas Pitre <nico@cam.org> writes:
>
>  > 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>)
>
>  I would prefer to do a bit more generic solution, not a special hack for
>  speeding up blame on prepend-only files, with a proper log message.

FWIW, I re-ran the gcc/ChangeLog annotation Linus cited and got similar
improvements (about 4x speed-up) with his version and this version and
their results seem to match.  I'll apply these to 'master' and push the
results out.

[PATCH 2/2] xdi_diff: trim common trailing lines

[Junio C Hamano]

This implements earlier Linus's optimization to trim common lines at the
end before passing them down to low level xdiff interface for all of our
xdiff users.

We could later enhance this to also trim common leading lines, but that
would need tweaking of the output function to add the number of lines
trimmed at the beginning to line numbers that appear in the hunk
headers.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 xdiff-interface.c |   34 +++++++++++++++++++++++++++++++++-
 1 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/xdiff-interface.c b/xdiff-interface.c
index 69a022c..f2cd488 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -103,9 +103,41 @@ int xdiff_outf(void *priv_, mmbuffer_t *mb, int nbuf)
 	return 0;
 }
 
+/*
+ * Trim down common substring at the end of the buffers,
+ * but leave at least ctx lines at the end.
+ */
+static void trim_common_tail(mmfile_t *a, mmfile_t *b, int ctx)
+{
+	const int blk = 1024;
+	long trimmed = 0, recovered = 0;
+	int i;
+	char *ap = a->ptr + a->size;
+	char *bp = b->ptr + b->size;
+	long smaller = (a->size < b->size) ? a->size : b->size;
+
+	while (blk + trimmed <= smaller && !memcmp(ap - blk, bp - blk, blk)) {
+		trimmed += blk;
+		ap -= blk;
+		bp -= blk;
+	}
+
+	for (i = 0, recovered = 0; recovered < trimmed && i <= ctx; i++) {
+		while (recovered < trimmed && ap[recovered] != '\n')
+			recovered++;
+	}
+	a->size -= (trimmed - recovered);
+	b->size -= (trimmed - recovered);
+}
+
 int xdi_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp, xdemitconf_t const *xecfg, xdemitcb_t *xecb)
 {
-	return xdl_diff(mf1, mf2, xpp, xecfg, xecb);
+	mmfile_t a = *mf1;
+	mmfile_t b = *mf2;
+
+	trim_common_tail(&a, &b, xecfg->ctxlen);
+
+	return xdl_diff(&a, &b, xpp, xecfg, xecb);
 }
 
 int read_mmfile(mmfile_t *ptr, const char *filename)
-- 
1.5.4.rc0.1.g37d0

Re: [PATCH 2/2] xdi_diff: trim common trailing lines

[Peter Baumann]

On Thu, Dec 13, 2007 at 02:31:49PM -0800, Junio C Hamano wrote:
> This implements earlier Linus's optimization to trim common lines at the
> end before passing them down to low level xdiff interface for all of our
> xdiff users.
> 
> We could later enhance this to also trim common leading lines, but that
> would need tweaking of the output function to add the number of lines
> trimmed at the beginning to line numbers that appear in the hunk
> headers.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  xdiff-interface.c |   34 +++++++++++++++++++++++++++++++++-
>  1 files changed, 33 insertions(+), 1 deletions(-)
> 
> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index 69a022c..f2cd488 100644
> --- a/xdiff-interface.c
> +++ b/xdiff-interface.c
> @@ -103,9 +103,41 @@ int xdiff_outf(void *priv_, mmbuffer_t *mb, int nbuf)
>  	return 0;
>  }
>  
> +/*
> + * Trim down common substring at the end of the buffers,
> + * but leave at least ctx lines at the end.
> + */
> +static void trim_common_tail(mmfile_t *a, mmfile_t *b, int ctx)

Should ctx be a long? (see comment below)

> +{
> +	const int blk = 1024;
> +	long trimmed = 0, recovered = 0;
> +	int i;
> +	char *ap = a->ptr + a->size;
> +	char *bp = b->ptr + b->size;
> +	long smaller = (a->size < b->size) ? a->size : b->size;
> +
> +	while (blk + trimmed <= smaller && !memcmp(ap - blk, bp - blk, blk)) {
> +		trimmed += blk;
> +		ap -= blk;
> +		bp -= blk;
> +	}
> +
> +	for (i = 0, recovered = 0; recovered < trimmed && i <= ctx; i++) {
> +		while (recovered < trimmed && ap[recovered] != '\n')
> +			recovered++;
> +	}
> +	a->size -= (trimmed - recovered);
> +	b->size -= (trimmed - recovered);
> +}
> +
>  int xdi_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp, xdemitconf_t const *xecfg, xdemitcb_t *xecb)
>  {
> -	return xdl_diff(mf1, mf2, xpp, xecfg, xecb);
> +	mmfile_t a = *mf1;
> +	mmfile_t b = *mf2;
> +
> +	trim_common_tail(&a, &b, xecfg->ctxlen);

xdemitconf_t has the following definition

	typedef struct s_xdemitconf {
		long ctxlen;
	        unsigned long flags;
		find_func_t find_func;
	        void *find_func_priv;
	} xdemitconf_t;

So you are loosing some values in your trim_common_tail function by making ctx
only an int. (Not sure that it matters, but I noticed it while glancing over
your code).

> +
> +	return xdl_diff(&a, &b, xpp, xecfg, xecb);
>  }
>  
>  int read_mmfile(mmfile_t *ptr, const char *filename)

-Peter

Re: [PATCH 2/2] xdi_diff: trim common trailing lines

[Junio C Hamano]

Peter Baumann <waste.manager@gmx.de> writes:

> So you are loosing some values in your trim_common_tail function by
> making ctx only an int. (Not sure that it matters, but I noticed it
> while glancing over your code).

While it is true that this does not matter in practice (because the
context value initially comes from the end user via -U parameter that is
stored in a field of type int in diff_options structure), I agre that it
is the right thing to do to use the same type as underlying xdiff
library uses at the interface level.  From the layering point of view.
xdiff-interface.[ch] are meant to be a thin usability wrapper, it should
not needlessly deviate from how the underlying xdiff operates.

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

checkout --push/--pop idea (Re: What's cooking in git.git (topics))

[Jan Hudec]

On Sun, Dec 23, 2007 at 01:20:53 -0800, 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.  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.

Shouldn't reflog of a symbolic ref contain (or also contain) the name of
pointee ref, instead of the resolved value? Than we could still get the exact
past revisions by looking at the pointee reflog by time, but could also get
the past branch names.

It would require an extension to the commitish syntax for specifying how to
resolve the pointee. Eg. HEAD^{1} would mean the previous sha1, HEAD^{1}{}
would mean the previous branch (but current value of it), and, by extension,
HEAD^{}{1} could mean previous value of currently selected branch.

Hm, the slight problem seems to be, that users would want previously checked
out branch even though commits were already done to the current one, so it is
not the previous reflog entry anymore...

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

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 will be cooking in git.git post 1.5.4 (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'.  Others commits may be stashed
in 'offcuts'.

The topics list the commits in reverse chronological order.

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

* 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.

* lt/in-core-index (Sun Jan 20 15:19:56 2008 +0000) 5 commits
 + 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.  Most likely this will be the first series to be
merged after 1.5.4 final.

----------------------------------------------------------------
[Graduated to 'master']

* jc/diff-hunk-header (Wed Jan 2 01:50:11 2008 -0800) 2 commits

This was to fix a real-world issues.

----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]

Nothing to see here.  We are still in rc freeze.

----------------------------------------------------------------
[Actively cooking]

Nothing to see here.  We are still 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.

* 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.

* 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.

* 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 has been 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/cr-at-eol (Tue Jan 15 00:59:05 2008 -0800) 1 commit
 - core.whitespace: cr-at-eol

People who have CRLF in repository are annoyed that they see ^M
at the end of the line marked as trailing whitespace errors.
This is to configure it away.

----------------------------------------------------------------
[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/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/apply-whitespace (Sat Jan 19 01:58:34 2008 -0800) 3 commits
 . builtin-apply.c: push match-beginning/end logic down
 . builtin-apply.c: restructure "offset" matching
 . builtin-apply.c: refactor small part that matches context

When you apply a series of patches with --whitespace=fix, a line
that is introduced in an earlier patch in the series can be
applied while getting its whitespace error fixed, and then it
can appear as a context line, but with its whitespace still
broken, in a later patch.  This series is meant to match such a
context line and propagate an earlier whitespace fix forward
without getting unnecessary conflicts, but I haven't made enough
real progress to show to the list yet.

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