On 5/1/12 14:39 , Randal L. Schwartz wrote:
"Rich" == Rich Pixley<rich.pixley@xxxxxxxx> writes:
I can always "git fetch origin" in my repo, and the remote
branches are in "origin/master, origin/foo, origin/bar". Totally
separate from my working tree.
Rich> Sure. You can fetch other branches, (unless you happen to be
Rich> checked out from them). But you can't fetch to master if you're
Rich> checked out from master.
No, you are still missing it.
"git fetch" updates the remote tracking branches, which you commonly
reference preceded by "origin". So "git fetch" DOES NOT TOUCH "master".
It touches only "origin/master".
Yes. I understand that that is how git typically works in a non-bare
repository.
Do you understand what I'm saying?
Only when you merge that remote in to your local master do you need to
worry about dirty trees or broken merges.
Rich> My particular situation is that I'm developing a "feature" and to
Rich> do that, I need to be testing on multiple machines. Tens of them.
I think you're now confusing git with a deploy system. That is also
something that will lead you to unnecessary grief. Pick a deploy system
that's not git, and integrate git with it.
No, not a deploy system. You use a deploy system to set up something
like multiple server http farms. What I'm doing is more akin to porting
the same piece of software to 20 different operating system
distributions. I'm not "deploying" the source code. I'm developing it.
Thank you for acknowledging that git is a poor match for this scenario,
though.
Rich> I really don't want hundreds of named branches that I must
Rich> manually merge from constantly.
I don't see how you would end up with this.
Yup. I'm beginning to see that.
--rich
--
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