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.

I know there are a number of other topics that I don't have in my
tree yet (bisect improvements, push refspec matching improvements,
option parser).  I plan on loading those into 'pu' tomorrow.
In the meantime we have this in next.


* db/fetch-pack (Thu Oct 11 01:47:55 2007 +0100) 58 commits
 + 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
 + Remove duplicate ref matches in fetch
 ... and many more ...

 The above commits are all new since Junio's last published next.
 About half of them fix known bugs in the builtin-fetch series.
 If you are running next, you want these fixes.

 I'm actually really happy with this series, but given the set of
 bugs that the above commits had to fix I think it needs to cook
 more in next before the topic can safely can graduate into master.

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

 I'm also really happy with this change.  If nobody objects I may
 move it over to master later this week.


* lt/diff-rename (Tue Oct 2 19:28:19 2007 -0700) 1 commit
 + optimize diffcore-delta by sorting hash entries.

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

* 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 inherited the above three topics from Junio.  I haven't had a
chance to really look at these yet myself to understand what their
status is and how ready they are for master (or not ready as the
case may be).

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

[Johannes Schindelin]

Hi,

first let me thank you for being the interim maintainer.  I know it is 
much work, and I frankly do not have the time, or nerve, to do it.  Out of 
curiousity: did you use the scripts in "todo" to send these emails?

On Tue, 16 Oct 2007, Shawn O. Pearce wrote:

> * lt/diff-rename (Tue Oct 2 19:28:19 2007 -0700) 1 commit
>  + optimize diffcore-delta by sorting hash entries.

AFAIR this was ready to go to master, with a 5-10% speedup or so, just 
needing a bit of testing.  Which it should have gotten by now.

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

This is the beginning of the builtin-commit.  The option parser has to go 
in before that (it was split out from the builtin-commit series), and the 
(minimal) adjustments to builtin-commit.c for the now-changed option 
parser have to be done.

So I think this topic should stay in master until builtin-commit is there, 
too.

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

This needs more work in rebase-i, and Junio indicated that he's not 
completely happy with it.

It would serve to be able to rebase in a dirty tree, by first stashing 
away the changes, and then applying them on top of the rebased branch.

I think that this would avoid many "Huh?" effects, but it should try to 
"git stash apply --index" first, falling back to "git stash apply".

Something like that would be very nice for git-pull, too, I guess.

However, I have not thought through all implications.

Ciao,
Dscho

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

[Theodore Tso]

On Tue, Oct 16, 2007 at 12:16:28PM +0100, Johannes Schindelin wrote:
> 
> first let me thank you for being the interim maintainer.  I know it is 
> much work, and I frankly do not have the time, or nerve, to do it.  Out of 
> curiousity: did you use the scripts in "todo" to send these emails?

I've recently started trying to use some of the scripts in "todo" to
send similar "What's cooking" messages, and started wondering if they
were what Junio actually used in production to send his notes.  For
example, the scripts don't work particularly well if the refs have
been packed.  So I had to make changes such as these so they would
work for me.

I was waiting for Junio to get back from vacation to ask if he was
interested in accepting such changes, and/or changes to make the
scripts more general purpose, and possibly useful for other projects.

		     	      	     	       - Ted

diff --git a/PU b/PU
index 4b4be2b..4643a42 100755
--- a/PU
+++ b/PU
@@ -26,8 +26,8 @@ case "$#" in
 0)
 	# interactive ;-)
 	shift
-	HH=`cd .git/refs/heads && find -type f |
-	sed -e 's/^\.\///' \
+	HH=`git-show-ref --heads | awk '{print $2}' |\
+	sed -e 's;refs/heads/;;' \
 	    -e '/^naster$/d' -e '/^master$/d' -e '/^maint$/d' -e '/^pu$/d'`
 	while test "$HH"
 	do
diff --git a/RB b/RB
index 918a372..a890cfd 100755
--- a/RB
+++ b/RB
@@ -3,9 +3,9 @@
 master_sha1=`git rev-parse --verify refs/heads/master`
 LF='
 '
-(cd .git/refs/heads && find -type f) |
+git-show-ref --heads | awk '{print $2}' |
 sed -n \
-    -e 's/^\.\///' \
+    -e 's;refs/heads/;;' \
     -e '/^[^\/][^\/]\//p' |
 while read topic
 do

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

[Shawn O. Pearce]

Theodore Tso <tytso@mit.edu> wrote:
> I've recently started trying to use some of the scripts in "todo" to
> send similar "What's cooking" messages, and started wondering if they
> were what Junio actually used in production to send his notes.  For
> example, the scripts don't work particularly well if the refs have
> been packed.  So I had to make changes such as these so they would
> work for me.

I think Junio just makes sure he doesn't pack his refs.  :-)
 
> diff --git a/PU b/PU
> index 4b4be2b..4643a42 100755
> --- a/PU
> +++ b/PU
> @@ -26,8 +26,8 @@ case "$#" in
>  0)
>  	# interactive ;-)
>  	shift
> -	HH=`cd .git/refs/heads && find -type f |
> -	sed -e 's/^\.\///' \
> +	HH=`git-show-ref --heads | awk '{print $2}' |\

Perhaps `git for-each-ref --format='%(refname)' refs/heads` is the
better change here as then you can avoid the pipe into awk.  We still
need the sed to strip the refs/heads/ off the results though.

> +	sed -e 's;refs/heads/;;' \
>  	    -e '/^naster$/d' -e '/^master$/d' -e '/^maint$/d' -e '/^pu$/d'`
>  	while test "$HH"
>  	do

I'm actually applying it with the show-ref variant and will wind up
pushing it into my tree later tonight.  Because I do pack my refs.

-- 
Shawn.

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

[Junio C Hamano]

Theodore Tso <tytso@mit.edu> writes:

> On Tue, Oct 16, 2007 at 12:16:28PM +0100, Johannes Schindelin wrote:
>> 
>> first let me thank you for being the interim maintainer.  I know it is 
>> much work, and I frankly do not have the time, or nerve, to do it.  Out of 
>> curiousity: did you use the scripts in "todo" to send these emails?
>
> I've recently started trying to use some of the scripts in "todo" to
> send similar "What's cooking" messages, and started wondering if they
> were what Junio actually used in production to send his notes.  For
> example, the scripts don't work particularly well if the refs have
> been packed.  So I had to make changes such as these so they would
> work for me.

Sorry, WI is for "what's in", WC is for "what's cooking".  I
should remove PU and RB from there.

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

[Theodore Tso]

On Mon, Oct 22, 2007 at 06:15:09PM -0700, Junio C Hamano wrote:
> >
> > I've recently started trying to use some of the scripts in "todo" to
> > send similar "What's cooking" messages, and started wondering if they
> > were what Junio actually used in production to send his notes.  For
> > example, the scripts don't work particularly well if the refs have
> > been packed.  So I had to make changes such as these so they would
> > work for me.
> 
> Sorry, WI is for "what's in", WC is for "what's cooking".  I
> should remove PU and RB from there.
> 

I assume PU is what you used to build your proposed-update branch?
I'm actually trying to use it, and it is useful, although it hasn't
been working for me completely perfectly.  I've still been trying to
figure out if the reason why it hasn't been working quite right is due
to my not understanding how to use it correctly, or whether you don't
use it these days.

One question which I have had about the WC script is that if I
manually add a commit to the next branch, it ends up showing up in all
of the topic branches as a commit that was part of that topic branch
which is in next.  So I can manually edit the output of WC to remove
the spurious commit, or I could make it be a rule that all new commits
either must go against the master branch, or be put in a topic branch
based off of master, and then merged into next.  Or maybe I'm not
understanding how to make the WC and git-topic.perl script work and
sing for me perfectly?

					- Ted

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

[Junio C Hamano]

Theodore Tso <tytso@mit.edu> writes:

> I assume PU is what you used to build your proposed-update branch?
> I'm actually trying to use it, and it is useful, although it hasn't
> been working for me completely perfectly.  I've still been trying to
> figure out if the reason why it hasn't been working quite right is due
> to my not understanding how to use it correctly, or whether you don't
> use it these days.

Ah, these days I almost always do:

	git checkout pu
	git reset --hard next

and then merge the topics that haven't been merged anywhere by
hand, using output from

        Meta/git-topic.perl

as the guide.

> One question which I have had about the WC script is that if I
> manually add a commit to the next branch, it ends up showing up in all
> of the topic branches as a commit that was part of that topic branch
> which is in next...

Well, the policy is never to commit directly on top of next
(iow, only merge other topics and nothing else).  Otherwise it
becomes hard to allow individual topics graduate to 'master'
independently.

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

[Theodore Tso]

On Mon, Oct 22, 2007 at 06:29:59PM -0700, Junio C Hamano wrote:
> Well, the policy is never to commit directly on top of next
> (iow, only merge other topics and nothing else).  Otherwise it
> becomes hard to allow individual topics graduate to 'master'
> independently.

I see.  So if it's non-trivial enough that you want it to "cook" in
next for a cycle, you'll create a topic branch for it (based off of
'master'), and then force a merge into 'next'?

					- Ted

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

[Shawn O. Pearce]

Theodore Tso <tytso@mit.edu> wrote:
> On Mon, Oct 22, 2007 at 06:29:59PM -0700, Junio C Hamano wrote:
> > Well, the policy is never to commit directly on top of next
> > (iow, only merge other topics and nothing else).  Otherwise it
> > becomes hard to allow individual topics graduate to 'master'
> > independently.
> 
> I see.  So if it's non-trivial enough that you want it to "cook" in
> next for a cycle, you'll create a topic branch for it (based off of
> 'master'), and then force a merge into 'next'?

Yes.  Because 'next' always has commits in it that never appear in
'master'.  So any topic forked from master must merge into next.
It can't be a fast-forward.  No forced merging required.

Of course this isn't true for a new project.  That first topic
that forked from master to *create* next will be a fast-forward
as it creates next.  But that's no big deal.  The second topic will
merge into next, and that first topic can still be merged back into
master without merging next (or the second topic).

I was also doing the same thing Junio already explained to manage
next and pu while he was away.  Except I shortcut his:

	git checkout pu
	git reset --hard next

as:

	git branch -f pu next
	git checkout pu

as I'm was usually already sitting on next.  This saved my poor
little laptop from a second of IO chugging as it slewed around
between the two versions.  There were no files to update as it
switched from next to pu, and pu was already setup for merging
the proposed topics.  :-)

-- 
Shawn.

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

[Theodore Tso]

On Tue, Oct 23, 2007 at 12:05:22AM -0400, Shawn O. Pearce wrote:
>
> Yes.  Because 'next' always has commits in it that never appear in
> 'master'.  So any topic forked from master must merge into next.
> It can't be a fast-forward.  No forced merging required.

Why is it the case that 'next' always commits that never appear in
'master'.  So far in how I've been doing things that hasn't been the
case.  When I do a "git checkout master; git merge next", it's always
been a fast-forward merge. 

Oh, I see.  That's because if you put some trivial changes in
'master', and then pull those changes into next, there will be merge
commits in 'next' that will never be in 'master.  Is that it?  

I had been trying to avoid that case by always putting new commits,
even trivial ones, into 'next', and then having them drop into
'master' at the next cycle; so 'master' was always trailing 'next',
but they were always the same commit string (i.e., 'master' was always
a subset of 'next').  

Aside from the WC script not working right, are there other
disadvantages to my doing things that way as opposed to the way the
Junio has been running the git repository?

						- Ted

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

[Shawn O. Pearce]

Theodore Tso <tytso@mit.edu> wrote:
> On Tue, Oct 23, 2007 at 12:05:22AM -0400, Shawn O. Pearce wrote:
> >
> > Yes.  Because 'next' always has commits in it that never appear in
> > 'master'.  So any topic forked from master must merge into next.
> > It can't be a fast-forward.  No forced merging required.
> 
> Why is it the case that 'next' always commits that never appear in
> 'master'.  So far in how I've been doing things that hasn't been the
> case.  When I do a "git checkout master; git merge next", it's always
> been a fast-forward merge. 
> 
> Oh, I see.  That's because if you put some trivial changes in
> 'master', and then pull those changes into next, there will be merge
> commits in 'next' that will never be in 'master.  Is that it?  

Exactly.  This of course means that next has been growing in distance
from master for quite some time.  It has well over 1000 commits now
in git.git that aren't in master.  Most of those will never merge
there either.
 
> I had been trying to avoid that case by always putting new commits,
> even trivial ones, into 'next', and then having them drop into
> 'master' at the next cycle; so 'master' was always trailing 'next',
> but they were always the same commit string (i.e., 'master' was always
> a subset of 'next').  
> 
> Aside from the WC script not working right, are there other
> disadvantages to my doing things that way as opposed to the way the
> Junio has been running the git repository?

The reason Junio does what he does is flexibility.

By merging only individual topics forked from master into next you
can merge those individual topics into master at different points
in time.  For example db/fetch-pack has been in next for many weeks
and hasn't yet merged into master, yet jc/am-quiet was forked after
db/fetch-pack started and has already merged into master.

Your way would make jc/am-quiet wait until db/fetch-pack was ready.
That's a big risk in the sense that your tree is "blocked" and even
simple changes are held up by ones that suddenly became a lot more
complex then you originally thought they were going to be.

-- 
Shawn.

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

[Theodore Tso]

On Tue, Oct 23, 2007 at 12:46:57AM -0400, Shawn O. Pearce wrote:
> By merging only individual topics forked from master into next you
> can merge those individual topics into master at different points
> in time.  For example db/fetch-pack has been in next for many weeks
> and hasn't yet merged into master, yet jc/am-quiet was forked after
> db/fetch-pack started and has already merged into master.
> 
> Your way would make jc/am-quiet wait until db/fetch-pack was ready.
> That's a big risk in the sense that your tree is "blocked" and even
> simple changes are held up by ones that suddenly became a lot more
> complex then you originally thought they were going to be.

Yes, true.  Alternatively, what I've been doing is that if I wasn't
sure that a particular topic was ready to go to 'master' very shortly
after it went into 'next', I would never let it go into 'next', but
rather keep it in 'pu' (which is OK, because pu is constantly getting
rewound).  But I guess the downside of that is you might get fewer
testers for the code, because fewer people are probably tracking and
testing 'pu' as compared to 'next'.

Right?

					- Ted

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

[Shawn O. Pearce]

Theodore Tso <tytso@mit.edu> wrote:
> On Tue, Oct 23, 2007 at 12:46:57AM -0400, Shawn O. Pearce wrote:
> > By merging only individual topics forked from master into next you
> > can merge those individual topics into master at different points
> > in time.  For example db/fetch-pack has been in next for many weeks
> > and hasn't yet merged into master, yet jc/am-quiet was forked after
> > db/fetch-pack started and has already merged into master.
> > 
> > Your way would make jc/am-quiet wait until db/fetch-pack was ready.
> > That's a big risk in the sense that your tree is "blocked" and even
> > simple changes are held up by ones that suddenly became a lot more
> > complex then you originally thought they were going to be.
> 
> Yes, true.  Alternatively, what I've been doing is that if I wasn't
> sure that a particular topic was ready to go to 'master' very shortly
> after it went into 'next', I would never let it go into 'next', but
> rather keep it in 'pu' (which is OK, because pu is constantly getting
> rewound).  But I guess the downside of that is you might get fewer
> testers for the code, because fewer people are probably tracking and
> testing 'pu' as compared to 'next'.
> 
> Right?

Yes, that's a good point.

I think in Git part of the reason less people track pu is because
its very volatile.  Not because of the rewind policy, but becuase
sometimes the code there doesn't work properly so using it for real
"production" work is pretty risky.  On the other hand most of the
code that merges into next has been reasonbly well reviewed and
tested, so following it for "production" work is not as risky.

Junio has in the past proposed rewinding next, especially after a
significant release (e.g. 1.5.3).  A bunch of folks (myself included
if I recall correctly) didn't want to do this, as we create topic
branches locally from things in next and sometimes make commits
over them to improve the topic further.  But I also make topic
branches for things in pu, so I might as well just shut up and
not complain.  :-)

Of course another thought that just came to mind is it is very easy
for me to review next with a

	git log -p --reverse origin/next..build-next

just before merging it into my build branch and compiling it locally.
If next rewound frequently (as pu does) this would be more difficult.

-- 
Shawn.

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

[Theodore Tso]

On Tue, Oct 23, 2007 at 01:07:26AM -0400, Shawn O. Pearce wrote:
> Junio has in the past proposed rewinding next, especially after a
> significant release (e.g. 1.5.3).  

Hmm, yes.  I think I'd want to rewind next after a while; the thought
of next drifting hundreds or thousands of commits away from master
just gives me the heebee-jeebies.  I'm sure it mostly works, but it
just feels wrong.  :-)

> A bunch of folks (myself included if I recall correctly) didn't want
> to do this, as we create topic branches locally from things in next
> and sometimes make commits over them to improve the topic further.

I guess I don't see why this would be a hardship; would a quick rebase
on the topic branches more or less take care of the problem?  

I guess that brings up another question; I've been regularly rebasing
the topics branches as master and next advances... probably more out
of superstition than anything else.  Is that a bad idea for any reason?


Hmm... I guess some of this would be really good to get into the Howto
section of the user guide when talking about git workflows!

	       	    	       	       	     	 - Ted

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

[Shawn O. Pearce]

Theodore Tso <tytso@mit.edu> wrote:
> On Tue, Oct 23, 2007 at 01:07:26AM -0400, Shawn O. Pearce wrote:
> > Junio has in the past proposed rewinding next, especially after a
> > significant release (e.g. 1.5.3).  
> 
> Hmm, yes.  I think I'd want to rewind next after a while; the thought
> of next drifting hundreds or thousands of commits away from master
> just gives me the heebee-jeebies.  I'm sure it mostly works, but it
> just feels wrong.  :-)

There's been a couple of times in git history where Junio has basically
done this to whack next back into line:

	git checkout next
	git diff next master | git apply --index
	git commit -m "Whack next back in line"

Because we've found a change or two lurking in there that shouldn't
have been there after a while.  I think it was related to a merge
conflict that happened in next but didn't in master or something
like that.  But usually this difference exists as there's usually
always something cooking in next.
 
> > A bunch of folks (myself included if I recall correctly) didn't want
> > to do this, as we create topic branches locally from things in next
> > and sometimes make commits over them to improve the topic further.
> 
> I guess I don't see why this would be a hardship; would a quick rebase
> on the topic branches more or less take care of the problem?  

Yes.  But you need the prior value of the branch so you can do
something easy like:

	git checkout yourtopic
	git rebase --onto $newtopic $oldtopic

which means you probably need to look through the logs for not just
pu but also pu@{1}.  A script to break out the topic branches from
pu post fetch and store them as proper tracking branches would make
this easier, but that much.  If you plan ahead you can save that
$oldtopic point so you can do something like this:

	git log pu ; # find $newtopic
	git checkout yourtopic
	git rebase --onto $newtopic base-yourtopic
	git tag -f base-yourtopic $newtopic

> I guess that brings up another question; I've been regularly rebasing
> the topics branches as master and next advances... probably more out
> of superstition than anything else.  Is that a bad idea for any reason?

It keeps the history shorter in gitk.  But otherwise it isn't bad.
Unless you are running into a lot of conflicts every time you rebase
and its wasting your time.  ;-)

I prefer to rebase the topics until they've merged to an integration
branch that doesn't rewind (e.g. master or next in git.git).
That way they have the shortest line possible in gitk between the
final merge and the start point.

There are good reasons why there's an "author" and a "committer"
field in commits.  Rebasing will change the committer field's
timestamp, but not the author field.  And author comes from the
email, to preserve the original date of development.
 
> Hmm... I guess some of this would be really good to get into the Howto
> section of the user guide when talking about git workflows!

Yea, I think so too.  We've adopted this model in git.git because
it works for our community.  A lot of other communities aren't
too far away, as we have a lot of crossover in members.  E.g. we
learned a lot from the kernel community.

-- 
Shawn.

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

[Theodore Tso]

On Tue, Oct 23, 2007 at 01:42:38AM -0400, Shawn O. Pearce wrote:
> Yes.  But you need the prior value of the branch so you can do
> something easy like:
> 
> 	git checkout yourtopic
> 	git rebase --onto $newtopic $oldtopic
> 
> which means you probably need to look through the logs for not just
> pu but also pu@{1}.  A script to break out the topic branches from
> pu post fetch and store them as proper tracking branches would make
> this easier, but that much.  If you plan ahead you can save that
> $oldtopic point so you can do something like this:
> 
> 	git log pu ; # find $newtopic
> 	git checkout yourtopic
> 	git rebase --onto $newtopic base-yourtopic
> 	git tag -f base-yourtopic $newtopic

Yeah, I had thought about writing a little script that would take my
project's topic branches, and then push them out into the public
repository under topics/ad/extents-testcases or
topics/tt/badblocks-cleanup.  That would make it easy to find the head
of your topic, and once you find that, the base of your-topic isn't
that hard to find, since it would just be the result of "git-rev-list
topic ^master | tail -1".

One of the reasons I was thinking the above is because most of the
patches are coming into my end as emailed patch series, and I end up
tweaking them a lot as I carry them around in the topics branch.  So
if other people want to see what I've done to a branch after I've done
a git rebase --interactive, it's easier if they can get access to the
individual topics branch, so they can extract out the patch series
while it's being tweaked by me (and possibly others).

This is probably because my view of git has been colored by kernel
community practices, where patches are normally perfected and get
rebased a lot (normally in a sub-maintainer or maintainer's tree)
before they get pushed to Linus, and in my mental model a topic branch
represents the maintainer's git tree in the central repository.

The extreme end of this would be the classical BitKeeper model, where
Larry McVoy once argued to me that he didn't like history to *ever* be
rewound/rewritten, since not only did this interfere with other people
trees once they had been pushed, but it causes development history to
be lost, which is always valuable.  (Of course, in the end he did
write "bk fold", which squashes the last N commits into 1, mainly due
to customer pressure.)  The kernel viewpoint is to rebase all the
time, because the history is so huge that we don't *want* to see the
development history of the rough drafts of features before they get
merged into mainline.

> It keeps the history shorter in gitk.  But otherwise it isn't bad.
> Unless you are running into a lot of conflicts every time you rebase
> and its wasting your time.  ;-)

It sounds like what you are saying here is that the git.git tree takes
a viewpoint which is slightly between the extremes of the kernel model
(which does involve resolving rebasing a lot and resolving lots of
conflicts, but heh, that's not Linus's problem, that's been pushed out
to the leafs of the developer community, and besides, it strongly
encourages topics to get merged into the mainline fast), and the
classical Bitkeeper model, which says that philosophical goodness
means you should keep *all* development history once it enters the BK SCM.

With git.git, we are essentially throwing away development history
while it is in 'pu', but once a commit graduates to 'next', we do keep
the development history forever.  The downside to this is that
development 'crud' can build up in next; even if all substantive
commits in 'next' end up graduating to 'master', there will still be
lots of merge commits that will only be in 'next'.   

I have an emotional bias which tends to treat that excess history as
toxic waste to be avoided at all costs, but that's probably because
when you have a git tree as huge as the kernel, life is easier if the
history is kept as clean as possible.  

Which I suppose is easy enough to do in the git.git model; if you
throw away the 'next' branch and then rewind it so it is forked off of
'master' all of that history essentially gets flushed.  The downside
is that people maintaining topics branches which were forked against
the old 'next' will need to do some grotty work to rebase their
patches, so any attempt to rewind next would probably require the
central maintainer to give plenty of notice, and then on the flag day,
save 'next' as 'old-next' before rewinding to allow the other
developers to more easily rebase any private branches they might have.

Hmm, interesting.  A lot of this is quite subtle, or at least the
impacts of different choices in the git workflow really didn't become
obvious to me until I started trying I stepped into the central
maintainer role for a project using git!

							- Ted

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

[Daniel Barkalow]

I keep thinking that there should be a better mechanism to use for "pu" 
than a branch. Normally what you see in "pu" is a sequential merge of 
"next" and a number of topic branches, where the series of merges is 
either entirely uninteresting or only interesting in a schematic sense 
(that is, it is interesting what topics appear, and in what order, but the 
snapshot of each topic's head when it got merged isn't interesting).

That is, the work which "pu" consists of, and therefore the history is a 
sequence of steps, each of which is one or more of: "add this topic", 
"update this topic", "remove this topic", "update to a new next". And we 
don't keep a record of this history, but it's not what's discarded by 
rewinding anyway.

I think that, if we actually care about this sort of thing, we'd want to 
make "pu" a series of commits, each with the previous "pu" as the sole 
parent, with a series object given in a new header. The series object 
would start with a "next" commit, and then list the topics merged by name 
and head-as-merged. Of course, the "pu" commits would contain the 
resulting tree as normal, so that people without a git that understands 
this would see "pu" as consisting of a straight line of commits, each of 
which simply shows the net effect of the changes. Or something like that. 
I suppose "pu" could also be represented as a superproject where each 
subproject is "next" or a topic branch, if we really want to avoid 
introducing new objects, but that seems unweildy somehow.

Is this worth doing? It might be; I bet it would make debugging -mm a 
whole lot nicer. (First bisect through -mm to find the action Andrew took 
that accepted the breakage, then bisect the history within that action.) I 
bet the status quo is a real pain when the feature that broke is only in 
-mm and later in Andrew's list than the tree whose change triggered the 
failure (i.e., -mm4 works; -mm5 doesn't work, and everything in -mm5 is 
either broken or untestable).

And, of course, "origin/pu[db/builtin-fetch]" would be an easy thing to 
build into git, and it could even generate extra magic, where it knows 
what the topic was last rebased on, so git could lead people through 
"rebase everything in a pu collection on the new base for the collection"
and "make my local topic branch agree with my topic branch as present in 
origin/pu".

	-Daniel
*This .sig left intentionally blank*

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

[Junio C Hamano]

Theodore Tso <tytso@mit.edu> writes:

> With git.git, we are essentially throwing away development history
> while it is in 'pu', but once a commit graduates to 'next', we do keep
> the development history forever.  The downside to this is that
> development 'crud' can build up in next; even if all substantive
> commits in 'next' end up graduating to 'master', there will still be
> lots of merge commits that will only be in 'next'.   
>
> I have an emotional bias which tends to treat that excess history as
> toxic waste to be avoided at all costs, but that's probably because
> when you have a git tree as huge as the kernel, life is easier if the
> history is kept as clean as possible.  
>
> Which I suppose is easy enough to do in the git.git model; if you
> throw away the 'next' branch and then rewind it so it is forked off of
> 'master' all of that history essentially gets flushed.

You can view 'next' as if it is sort of -mm.  Following 'master'
is like following Linus tree, whose development is without those
numerous 'merge improvements again' merges into 'next'.

> The downside
> is that people maintaining topics branches which were forked against
> the old 'next' will need to do some grotty work to rebase their
> patches, so any attempt to rewind next would probably require the
> central maintainer to give plenty of notice, and then on the flag day,
> save 'next' as 'old-next' before rewinding to allow the other
> developers to more easily rebase any private branches they might have.

An alternative is to give an easier access to the tips of
individual topic branch head, at least to the ones that have
been merged to 'next' as they will never be rewound once they
are in 'next', and encourage people to fork off of them, instead
of 'next' directly.  Then 'next' will be more like 'pu'.

> Hmm, interesting.  A lot of this is quite subtle, or at least the
> impacts of different choices in the git workflow really didn't become
> obvious to me until I started trying I stepped into the central
> maintainer role for a project using git!

Very true.

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

[Theodore Tso]

On Tue, Oct 23, 2007 at 12:00:38PM -0700, Junio C Hamano wrote:
> 
> You can view 'next' as if it is sort of -mm.  Following 'master'
> is like following Linus tree, whose development is without those
> numerous 'merge improvements again' merges into 'next'.

Actually -mm is much closer to 'pu', since it can and is rewound all
the time.  Patches can disappear if they are causing problems, they
can be replaced and reworked, etc.

						- Ted

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

[Shawn O. Pearce]

Theodore Tso <tytso@mit.edu> wrote:
> On Mon, Oct 22, 2007 at 06:15:09PM -0700, Junio C Hamano wrote:
> > 
> > Sorry, WI is for "what's in", WC is for "what's cooking".  I
> > should remove PU and RB from there.
> 
> I assume PU is what you used to build your proposed-update branch?

Actually I found PU of some use:

	git branch -f pu next
	git checkout pu
	./Meta/PU --continue

its a little sluggish to list, but made it pretty easy to pick
topics for merging into pu.  git-rerere really makes it easy to
recover conflicts in pu during future rebuilds of pu.

> based off of master, and then merged into next.  Or maybe I'm not
> understanding how to make the WC and git-topic.perl script work and
> sing for me perfectly?

The other tidbits I managed to learn by trial and error here was
to make sure I did the following:

	- make sure master is fully merged into next
	- make sure next is fully merged into pu
	- Run "Meta/git-topic.perl --base=master | less"

It wasn't uncommon for me to merge master->next, next->pu, run
git-topic, then reset both next and pu *back* to what I had last
published (remote tracking branches updated during push make this
easy) before moving on with my next and pu updating activities.

Of course take my notes above with a grain of salt; I only worked
this way for a week and it took me a couple of days to come up with
the above.  Junio may very well have it streamlined even more.

-- 
Shawn.

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

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> first let me thank you for being the interim maintainer.  I know it is 
> much work, and I frankly do not have the time, or nerve, to do it.

Heh.  In the past 24 hours I've really learned how much I appreciate
the work that Junio does, and how infrequently I make it known that
I'm happy he's doing it for us.  Nothing like understanding what
the guy goes through then to walk a day in his shoes.  :-)

> Out of 
> curiousity: did you use the scripts in "todo" to send these emails?

Yes.  Took me a few minutes to figure out which scripts did
what magic.  Junio likes two character script names, because uh,
they are short to type.  Then I hand modified the output to say
git/spearce.git and appear from me, not Junio.  But otherwise they
are the same scripts available from his Meta repository (aka the
todo branch).
 
> On Tue, 16 Oct 2007, Shawn O. Pearce wrote:
> 
> > * lt/diff-rename (Tue Oct 2 19:28:19 2007 -0700) 1 commit
> 
> AFAIR this was ready to go to master, with a 5-10% speedup or so, just 
> needing a bit of testing.  Which it should have gotten by now.

OK.  I'll look at it tomorrow and consider moving it.  I recall the
context of this discussion now that you mention it, and I've been
running this in production use since Junio committed it to next
so I'm certainly not seeing any downsides to having this patch in
the tree.
 
> > * kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits
> > * js/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits

Thanks for the summary on these two topics.  They are going to stay
parked in next for a while then.  :-)

-- 
Shawn.

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.