Petr Baudis [off-list ref] writes:
Aha, so it seems our problem is hopefully only in terminology, great.
So, what do you mean by "clone" here? And what command should I use for
pushing then?
Notice I never used the word "clone" in what I said.
What I mean by "a semantically equivalent two repositories,
potentially one being a strict subset of the other" is you can
pull head A from one or head A from the other and can get the
same result (although one may and the other may not have head
B). And naturally you use send-pack for pushing.
If I "clone" from repository A to create a repository B, I would
never "push back" from B to A. Instead I would ask a person who
owns A to "pull from B". My impression is the patch flow in the
kernel circle works like that (although I have never been in
that circle).
Now, A may happen to be on my home machine and B may happen be
on my notebook, meaning the owner of A and B are both myself.
But even in that case I would still work by "pulling from A"
when I am on B, and "pulling from B" when I am on A. In other
words, "pulling" is the only patch flow mechanism I would use.
Pushing is only for publication and I treat it as just a
GIT-aware rsync/mirror, nothing more. I have a feeling that
your workflow is different and you plan to use both push and
pull for normal patch flows. This distinction is probably where
the disagreement comes from.
And I strongly suspect that the primary reason that I "simply do
not get it" after reading your messages is because my mental
model is strongly molded into what Linus taught us. I have to
unlearn things...
Dear diary, on Fri, Jul 29, 2005 at 09:48:57AM CEST, I got a letter
where Junio C Hamano [off-list ref] told me that...
Petr Baudis [off-list ref] writes:
quoted
Aha, so it seems our problem is hopefully only in terminology, great.
So, what do you mean by "clone" here? And what command should I use for
pushing then?
Notice I never used the word "clone" in what I said.
quoted
However, I happen to think that two repositories
you use send-pack (not _CLONE_ which uses completely different
protocol)
(emphasis mine ;-)
Now, A may happen to be on my home machine and B may happen be
on my notebook, meaning the owner of A and B are both myself.
But even in that case I would still work by "pulling from A"
when I am on B, and "pulling from B" when I am on A. In other
words, "pulling" is the only patch flow mechanism I would use.
I use cg-push on my notebook, given that the notebook might not happen
to have public IP address in some cases, or might be behind some
corporate firewall, or that I'm lazy to ssh to my home machine in order
to pull.
Pushing is only for publication and I treat it as just a
GIT-aware rsync/mirror, nothing more. I have a feeling that
your workflow is different and you plan to use both push and
pull for normal patch flows. This distinction is probably where
the disagreement comes from.
Exactly. I want much more freedom in pushing, the only requirement being
that "the to-be-replaced remote head is ancestor of the to-be-pushed
local head". I think (am I wrong?) git-send-pack localhead:remotehead
would work just fine for me, the only thing I need is the support for
different local and remote head names.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
Hi,
On Friday 29 July 2005 09:48, you wrote:
Petr Baudis [off-list ref] writes:
quoted
So, what do you mean by "clone" here? And what command should I use for
pushing then?
...
Now, A may happen to be on my home machine and B may happen be
on my notebook, meaning the owner of A and B are both myself.
But even in that case I would still work by "pulling from A"
when I am on B, and "pulling from B" when I am on A. In other
words, "pulling" is the only patch flow mechanism I would use.
OK, that is your opinion and your work flow. But porcelains perhaps would like
to allow other work flows, even if it seems confusing for you.
And I think the problem here simple is that send-pack *forces* local and
remote head names to be the same. This is forcing policy to porcelains, but
GIT should be only about plumbing.
Perhaps the solution is to allow more flexibility in GIT.
What about introducing an additional environment GIT_REFS_DIR?
When using send-pack, the porcelain would set this variable to a directory
containing a 1:1 name relationship to the remote repository.
Josef
On Fri, Jul 29, 2005 at 08:10:51AM +0000, Petr Baudis wrote:
Exactly. I want much more freedom in pushing, the only requirement being
that "the to-be-replaced remote head is ancestor of the to-be-pushed
local head". I think (am I wrong?) git-send-pack localhead:remotehead
would work just fine for me, the only thing I need is the support for
different local and remote head names.
Greetings,
Sorry to join the game so late. I've only read this thread now.
It seems to me that this is the way to go. Several have mentioned that
head names should be the same on the remote and the local side.
However, I wanted to point out that it may be impossible to keep these
names in sync due to the 'loosely knit' nature of the types of projects
that are likely to use git.
It seems that the requirement that the remote head be a strict ancestor
of the local head is actually quite strong and should avoid mistakes
like pushing to the wrong head.
Anyway, those are my two cents. I couldn't tell wether a resolution had
been achieved so I thought I would pipe up.
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -