On Oct 24, 2007, at 11:28 PM, Peter Baumann wrote:
On Wed, Oct 24, 2007 at 11:06:24PM +0200, Andreas Ericsson wrote:
J. Bruce Fields wrote:
On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote:
On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote:
I want git pull to work like git push.
That strikes me as a less complete solution, since it only
helps in the
case where the other branches all happen to be unmodified
locally (hence
can be fast-forwarded). In other cases the "git push" will
still emit a
spurious error.
Well, but then there's something you should really think
about.
Perhaps, but not necessarily; you may have some branches with local
changes that you're content to leave unpushed (and un-updated).
Sure, but that won't change. The only thing I'm proposing is that
local copies of remote branches are automatically fast-forwarded
on every pull, but only if
* the branch has no modifications what so ever
* the branch is set up to auto-merge with the particular branch
fetched from the particular remote
I really don't see any downsides what so ever with this. Those
of you who do, please enlighten me.
You can't check what got added in your pull, e.g you can't review
the new
code with something like
gitk next..origin/next
You're not forced to pull. Just use "git fetch" if you
want to do this. Or is something missing if you'd be
limited to "git fetch"?
I often do something like this, just to see what got changed. So at
least
in my opinion you have to add a third point:
* the branch has no modifications what so ever
* the branch is set up to auto-merge with the particular branch
fetched from the particular remote
AND
* the user set a config option to always autofastfoward if the above
conditions are true! This could be implemented as a global
option with
a per branch overwrite.
I (and, as I understood, Andreas, too) want to change the
default. Because we believe that git would be easier to use
in workflows based on a shared repository.
But if we fail to convince the list, maybe a global
configuration variable that configures "git pull" to autoforward
branches as propose would be a nearly equally good solution.
However, I think it is dangerous to introduce many of such
configuration options. Explaining the behaviour of git will
become harder. The behaviour will become dependent on the
local configuration and eventually the first question before
answering a question will be "send me the output of 'git config
--list'. I need to see how your git is configured."
Steffen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
