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

quoted text
> 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.


quoted text
> 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




-
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