Johannes Schindelin wrote:
Hi,
On Thu, 25 Oct 2007, Andreas Ericsson wrote:
Johannes Schindelin wrote:
On Wed, 24 Oct 2007, Andreas Ericsson wrote:
Conceptually, I don't think it'll be any problem what so ever
telling anyone that the branches that aren't currently checked out
get merged automatically only if they result in a fast-forward.
It would be a matter of seconds until someone asks "why only
fast-forwards? Would it not be _much_ better to merge _always_?
Stupid git."
And all because the concept of "local" vs "remote" was blurred.
It's already blurred, since we have git-pull instead of just git-fetch.
Huh? How is "I ask git pull to fetch the remote branch, and merge it into
my local branch" a blurring of local vs remote branch?
The local branch is still the local branch where it is _my_ responsibility
to update or change anything.
True. So git pull saves you exactly one command. The various fetch-all-git-
repos-and-update-all-fast-forward-branches in circulation at the office
save us ~500 commands each time they're run. Or rather, they *could* do
that, but you can't know until you've run it.
So what should I do to make what I want possible, without having git-pull
muddy the waters of local vs remote? There's clearly a user desire for it,
besides that of my eight co-workers and myself. Introduce git-<cmd-156>?
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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
