Johannes Schindelin wrote:
Hi,
On Thu, 25 Oct 2007, Andreas Ericsson wrote:
Johannes Schindelin wrote:
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.
As I pointed out, there is no way to sensibly have 500 _local_ branches
lying around.
It is ridiculous to assume that you have to have local branches for all
the stable, maintenance, whatever branches.
When you have to change something, you branch, hack, develop, commit,
push, and then _clean up_ after yourself. No need to clutter your
local branch space with unused branches.
error: The branch 'next' is not a strict subset of your current HEAD.
If you are sure you want to delete it, run 'git branch -D next'.
So you want me to tell all the developers they should use "git branch
-D maint" instead, so they can bypass the built-in security checks? No
thanks.
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>?
If you _insist_ on your workflow, hey, git is a free program, and you can
do what you want to do with an alias easily enough.
With a git alias? No. There aren't even any switches in git to make it do
what I want. With a shell alias? Sure, it's doable, but cumbersome. With a
shell-script I can get it done, but it's ugly, inefficient and has to parse
everything twice. It's also a time-sink, and time is something I don't have
very much of right now.
You can even make
that alias part of the templates, so you can force your desires down the
throat of every of your coworkers.
They're the ones that requested I hack it into git, but the result would
remain the same, ofcourse.
However, that does not mean that you can insist on support for your
workflow in upstream git.
I'm not. We're currently discussing the pros and the cons, and I'm spending
my free 20 minutes every night working on a patch-series to make git-pull
a built-in and then implementing the switch/config-option/whatever that
makes it do what I want it to do. Apart from Junio, that's how everyone
that wants a feature implemented has to do it, so I'd hardly call that
insisting. If Junio decides the patch does something evil, I'll have to
settle for cherry-picking it into whatever branch I want to build from.
On a side note; I'd *love* for it to have a rebase option as well. Perhaps
I'll do that next. In the mean-time, I'd settle for just updating locally
modifiable copies of tracking branches that I've already configured git to
merge with a tracking branch when it happens to be a fast-forward.
--
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
