How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Josef Weidendorfer]

Hi,

if I clone a remote head other than master via Cogito with

	cg-clone host:path#remoteHead,

work on this branch, and try to push back my changes with

	cg-push,

I get the error

	"pushing to a different head not supported yet".

As far as I can see, there is no support in core GIT to make this ever work 
(at least with get-send-packs), as "git-send-pack" only updates a set of 
heads with the same name both locally and remote.

I suppose the best would be to always keep the same head names in cloned 
repositories - it seems to be easier to handle for users. Perhaps the only 
exception would be "master", as one probably would like to pull masters of 
different remote repositories into a local one (without really working on 
them).

Thus, what about the following: Each time a remote head other than master is 
cloned, a head with the same name is created locally which is an alias to the 
local master. This way, cg-push almost works out of the box. Following patch 
implements this behavior.

Josef

diff --git a/cg-clone b/cg-clone
--- a/cg-clone
+++ b/cg-clone
@@ -69,5 +69,12 @@ cp $_git/refs/heads/origin $_git/refs/he
 git-read-tree HEAD
 git-checkout-cache -a
 git-update-cache --refresh

 echo "Cloned to $dir/ (origin $location available as branch \"origin\")"
+
+if echo "$location" | grep -q "#" ; then
+       rembranch=$(echo "$location" | sed -e "s/.*#//")
+       (cd $_git/refs/heads; ln -s master "$rembranch")
+       echo "Remote head \"$rbranch\" locally available as alias for \"master\""
+fi
+
diff --git a/cg-push b/cg-push
--- a/cg-push
+++ b/cg-push
@@ -28,17 +28,18 @@ uri=$(cat "$_git/branches/$name" 2>/dev/

 rembranch=master
 if echo "$uri" | grep -q '#'; then
        rembranch=$(echo $uri | cut -d '#' -f 2)
        uri=$(echo $uri | cut -d '#' -f 1)
-       die "pushing to a different head not supported yet"
+        [ -s $_git/refs/heads/$rembranch ] || (cd $_git/refs/heads;ln -s master $rembranch)
+        [ $(readlink $_git/refs/heads/$rembranch) = "master" ] || \
+          die "can not push to remote head \"$rembranch\""
 fi

 if echo "$uri" | grep -q "^http://"; then
        die "pushing over HTTP not supported yet"
 elif echo "$uri" | grep -q "^git+ssh://"; then
        git-send-pack "$(echo "$uri" | sed 's#^git+ssh://\([^/]*\)\(/.*\)$#\1:\2#')" $rembranch
-elif echo "$uri" | grep -q ":"; then
+elif echo "$uri" | grep -q "^rsync://"; then
        die "pushing over rsync not supported"
 else
        git-send-pack "$uri" $rembranch
 fi

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> As far as I can see, there is no support in core GIT to make this ever work 
> (at least with get-send-packs), as "git-send-pack" only updates a set of 
> heads with the same name both locally and remote.

Yes, it is my understanding that "clone" means to literally
clone, not "pull into an empty repository with renamed head
names", to the core GIT.  I do not speak for Pasky, but Cogito's
"clone" seems to have a bit different semantics (which I suspect
is more friendly to the users in many situations).

Similarly, "push" to the core GIT (that is what git-send-pack is
about) means performing a subset of "clone" in reverse.  This is
primarily to synchronise two repositories owned by a single
person.

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Petr Baudis]

Dear diary, on Wed, Jul 27, 2005 at 02:58:42PM CEST, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> told me that...
> Hi,

Hello,

> if I clone a remote head other than master via Cogito with
> 
> 	cg-clone host:path#remoteHead,
> 
> work on this branch, and try to push back my changes with
> 
> 	cg-push,
> 
> I get the error
> 
> 	"pushing to a different head not supported yet".
> 
> As far as I can see, there is no support in core GIT to make this ever work 
> (at least with get-send-packs), as "git-send-pack" only updates a set of 
> heads with the same name both locally and remote.

Yes. It sucks. :-)

> I suppose the best would be to always keep the same head names in cloned 
> repositories - it seems to be easier to handle for users. Perhaps the only 
> exception would be "master", as one probably would like to pull masters of 
> different remote repositories into a local one (without really working on 
> them).

I think that would be quite confusing. I mean, you added a remote "bar"
branch under name "foo" by cg-branch-add, but suddenly, branch "bar"
appears as well. Worse if you already have a different branch "bar".

> Thus, what about the following: Each time a remote head other than master is 
> cloned, a head with the same name is created locally which is an alias to the 
> local master. This way, cg-push almost works out of the box. Following patch 
> implements this behavior.

See above. I would much rather see more flexible git-send-pack. Junio,
what about changing its [heads]* parameter e.g. to
[remotehead[:localhead]]* ?

Dear diary, on Thu, Jul 28, 2005 at 03:32:01AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> 
> > As far as I can see, there is no support in core GIT to make this ever work 
> > (at least with get-send-packs), as "git-send-pack" only updates a set of 
> > heads with the same name both locally and remote.
> 
> Yes, it is my understanding that "clone" means to literally
> clone, not "pull into an empty repository with renamed head
> names", to the core GIT.  I do not speak for Pasky, but Cogito's
> "clone" seems to have a bit different semantics (which I suspect
> is more friendly to the users in many situations).

cg-clone serves only for initializing the repository from a remote
source initially.

> Similarly, "push" to the core GIT (that is what git-send-pack is
> about) means performing a subset of "clone" in reverse.  This is
> primarily to synchronise two repositories owned by a single
> person.

cg-push aims to serve as a general pushing mechanism, which should work
properly even if multiple people push to a single repository.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Johannes Schindelin]

Hi,

On Thu, 28 Jul 2005, Petr Baudis wrote:

> See above. I would much rather see more flexible git-send-pack. Junio,
> what about changing its [heads]* parameter e.g. to
> [remotehead[:localhead]]* ?

IMHO this opens the door for shooting in your own foot. Isn't it much too
easy to make a mistake with that syntax? What is so wrong with git-clone
not allowing you to name the HEAD differently?

Ciao,
Dscho

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Petr Baudis]

Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> Hi,

Hello,

> On Thu, 28 Jul 2005, Petr Baudis wrote:
> 
> > See above. I would much rather see more flexible git-send-pack. Junio,
> > what about changing its [heads]* parameter e.g. to
> > [remotehead[:localhead]]* ?
> 
> IMHO this opens the door for shooting in your own foot. Isn't it much too
> easy to make a mistake with that syntax?

What mistake?

> What is so wrong with git-clone not allowing you to name the HEAD
> differently?

Did you read the preceding discussion? When you are pushing from your
master branch to a remote branch, it may well be called different over
there.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Johannes Schindelin]

Hi,

On Thu, 28 Jul 2005, Petr Baudis wrote:

> Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
>
> > On Thu, 28 Jul 2005, Petr Baudis wrote:
> >
> > > See above. I would much rather see more flexible git-send-pack. Junio,
> > > what about changing its [heads]* parameter e.g. to
> > > [remotehead[:localhead]]* ?
> >
> > IMHO this opens the door for shooting in your own foot. Isn't it much too
> > easy to make a mistake with that syntax?
>
> What mistake?

To mix up different branches. With that syntax you can easily push changes
onto the wrong head.

I might well be wrong here, but I think the most common usage for git-push
is to update a public repository, which is done by one or just a few
maintainer(s), in which case it is no problem to enforce
localhead=remotehead. BTW, this whole multihead mess applies only to Jeffs
anyway :-)

I just do not see a high demand for mappings of remote and local HEAD
names, but rather a high potential of making mistakes (after all, it is
not the machine which makes mistakes, it's the human operator).

> If you want the holes in your knowledge showing up try teaching
> someone.  -- Alan Cox

I like that one.

Ciao,
Dscho

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Petr Baudis]

Dear diary, on Thu, Jul 28, 2005 at 05:56:21PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> Hi,

Hello,

> On Thu, 28 Jul 2005, Petr Baudis wrote:
> 
> > Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
> > where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> >
> > > On Thu, 28 Jul 2005, Petr Baudis wrote:
> > >
> > > > See above. I would much rather see more flexible git-send-pack. Junio,
> > > > what about changing its [heads]* parameter e.g. to
> > > > [remotehead[:localhead]]* ?
> > >
> > > IMHO this opens the door for shooting in your own foot. Isn't it much too
> > > easy to make a mistake with that syntax?
> >
> > What mistake?
> 
> To mix up different branches. With that syntax you can easily push changes
> onto the wrong head.

How? Only when you explicitly specify the remote head. When you're
explicit, you ought to know what are you doing.

> I might well be wrong here, but I think the most common usage for git-push
> is to update a public repository, which is done by one or just a few
> maintainer(s), in which case it is no problem to enforce
> localhead=remotehead. BTW, this whole multihead mess applies only to Jeffs
> anyway :-)

AFAIK the plan is to centralize all the kernel repositories to a single
one. For that, developers would generally push into branches with name
different that "master".

> I just do not see a high demand for mappings of remote and local HEAD
> names, but rather a high potential of making mistakes (after all, it is
> not the machine which makes mistakes, it's the human operator).

If you fear making mistakes, better use something which attempts to do
some babysitting for you, like Cogito. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> AFAIK the plan is to centralize all the kernel repositories to a single
> one. For that, developers would generally push into branches with name
> different that "master".

I did not know about that plan, but that is interesting and now
I understand why you think it is important to be able for more
than one person to push into a single repository.

How will the namespace of N-hundred branches in that repository
be managed?  To avoid collisions, wouldn't there be some
coordination, and there will be branch names there that
everybody agrees that they are owned by you?

At that point, wouldn't it be easier for _you_ (as one kernel
developer who owns such globally unique branch names) to name
your branch you intend to push there the same way in your
working repository as well?

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Johannes Schindelin]

Hi,

On Thu, 28 Jul 2005, Junio C Hamano wrote:

> Petr Baudis <pasky@suse.cz> writes:
>
> > AFAIK the plan is to centralize all the kernel repositories to a single
> > one. For that, developers would generally push into branches with name
> > different that "master".
>
> I did not know about that plan, but that is interesting and now
> I understand why you think it is important to be able for more
> than one person to push into a single repository.

Is it possible that those plans only mean to centralize .git/objects/ and
leave the rest in single repositories? Seems much more sensible to me.

Ciao,
Dscho

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Ryan Anderson]

On Thu, Jul 28, 2005 at 07:32:55PM +0200, Johannes Schindelin wrote:
> Is it possible that those plans only mean to centralize .git/objects/ and
> leave the rest in single repositories? Seems much more sensible to me.

I think that's accurate.  It can be done without the repositories even
really noticing if "git relink" is used aggressively to migrate
hard links into the repository regularly.  (Though, "packs" cause some
confusion in that scheme, I think.)


-- 

Ryan Anderson
  sometimes Pug Majere

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Johannes Schindelin]

Hi,

On Thu, 28 Jul 2005, Ryan Anderson wrote:

> On Thu, Jul 28, 2005 at 07:32:55PM +0200, Johannes Schindelin wrote:
> > Is it possible that those plans only mean to centralize .git/objects/ and
> > leave the rest in single repositories? Seems much more sensible to me.
>
> I think that's accurate.  It can be done without the repositories even
> really noticing if "git relink" is used aggressively to migrate
> hard links into the repository regularly.  (Though, "packs" cause some
> confusion in that scheme, I think.)

I guess that's where git-daemon comes into play.

Ciao,
Dscho

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Petr Baudis]

Dear diary, on Thu, Jul 28, 2005 at 06:52:45PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
> 
> > AFAIK the plan is to centralize all the kernel repositories to a single
> > one. For that, developers would generally push into branches with name
> > different that "master".
> 
> I did not know about that plan, but that is interesting and now
> I understand why you think it is important to be able for more
> than one person to push into a single repository.

For that particular thing, this is only part of the motivation. The much
bigger part of the motivation are projects which don't have a central
maintainer but where group of people needs to be equal in access to a
central repository. That's actually vast majority of larger projects, I
think.

> How will the namespace of N-hundred branches in that repository
> be managed?  To avoid collisions, wouldn't there be some
> coordination, and there will be branch names there that
> everybody agrees that they are owned by you?

You could name your branches e.g. "davej/agpgart", "davej/cpufreq", etc.
But those proposals of central repository were certainly quite
preliminary, and perhaps I overstated saying "the plan is".

> At that point, wouldn't it be easier for _you_ (as one kernel
> developer who owns such globally unique branch names) to name
> your branch you intend to push there the same way in your
> working repository as well?

And if you are cloning locally or whatever, you have to mention the
branch name explicitly.

One of the Cogito design bits is that branch name is something local to
the repository. When you are adding a branch, the local name you assign
it is your private thing repository-wise, and doesn't have to have any
correlation to other repositories you might interact width.

As I already argued, this helps when you are importing someone else's
master as your branch called whatever (obviously not master), and if you
have to deal with two remote branches with the same name (such a
conflict is bound to happen and bound to be vulnerable to be a huge
hassle). That also applies to pushing, you might be pushing to multiple
repositories - say you are working on some cool kernel stuff for SuSE,
so you might want to push to kernel.org _and_ into the deep bowels of
some SuSE kernel infrastructure (whatever - I'm not familiar with those
things yet if you are now drooling to get some insight about how this is
working in SuSE].

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Johannes Schindelin]

Hi,

On Thu, 28 Jul 2005, Petr Baudis wrote:

> For that particular thing, this is only part of the motivation. The much
> bigger part of the motivation are projects which don't have a central
> maintainer but where group of people needs to be equal in access to a
> central repository. That's actually vast majority of larger projects, I
> think.

Are you really sure you want to slave git into being a "better
Subversion"? IMHO, if you need a central repository, you should also have
one central HEAD.

Just my tucence,
Dscho

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Matthias Urlichs]

Hi, Johannes Schindelin wrote:

> Are you really sure you want to slave git into being a "better
> Subversion"?

Since git is better than all of these, we should be able to easily write a
SVN-like porcelain, so ... ;-)

> IMHO, if you need a central repository, you should also have
> one central HEAD.

I disagree. Larger projects have multiple HEADs (stable, oldstable,
development, ...). I don't like putting those in different repositories,
you end up with a heap of housekeeping effort to hardlink duplicate
objects, all of which is going to be wasted when different people run
"git repack".

Not everybody has 100-GB disks and multi-MB Internet pipes to play with...

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
On ability:
	A dwarf is small, even if he stands on a mountain top;
	a colossus keeps his height, even if he stands in a well.
		-- Lucius Annaeus Seneca, 4BC - 65AD

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Johannes Schindelin]

Hi,

On Thu, 28 Jul 2005, Matthias Urlichs wrote:

> Hi, Johannes Schindelin wrote:
>
> Since git is better than all of these, we should be able to easily write a
> SVN-like porcelain, so ... ;-)

Sorry, you're correct.

> > IMHO, if you need a central repository, you should also have
> > one central HEAD.
>
> I disagree. Larger projects have multiple HEADs (stable, oldstable,
> development, ...). I don't like putting those in different repositories,
> you end up with a heap of housekeeping effort to hardlink duplicate
> objects, all of which is going to be wasted when different people run
> "git repack".

Sorry again. I should have been clearer: If you have a larger project
which does have production releases which have to be patched for a while,
and thus need several branches, then there is still a *very good* reason
not to play games with the names of those branches or the tags.

Naming the remote HEAD differently than the local HEAD is just *wrong*
when you want to push back to them. I agree that it is a fine intellectual
challenge to keep juggling a few remote HEADs, and throw in a few local
HEADs, but all that is *complicated*. And complicated things lead to
complications.

BTW I am a Jeff, I use git branches extensively in two projects.

The only sane way if you have to have different local and remote HEADs
that I can think of, would be to allow only the current local active HEAD
to be pushed to a certain remote HEAD (preferably identified by a file in
.git/branches).

Ciao,
Dscho

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Petr Baudis]

Dear diary, on Thu, Jul 28, 2005 at 10:14:35PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> Hi,

Hello,

> Naming the remote HEAD differently than the local HEAD is just *wrong*
> when you want to push back to them.

But you might not know that in advance. That's one of they key points of
the distributed systems, after all - when you are cloning, you needn't
know in advance that you will want to do local commits, and don't need
upstream approval. You also might not know in advance that you will want
to push them back. Sure, distributed systems are more complicated. If
you don't like complicated things, there's always RCS. ;-)

> The only sane way if you have to have different local and remote HEADs
> that I can think of, would be to allow only the current local active HEAD
> to be pushed to a certain remote HEAD (preferably identified by a file in
> .git/branches).

Well, but (if I understand you correctly) that was always the _point_.
It's what I was talking about all the time. :-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> One of the Cogito design bits is that branch name is something local to
> the repository. When you are adding a branch, the local name you assign
> it is your private thing repository-wise, and doesn't have to have any
> correlation to other repositories you might interact width.

I do not disagree with that.  I think branch name is mostly a
local matter.  However, I happen to think that two repositories
you use send-pack (not clone which uses completely different
protocol) to sync one from the other are semantically equivalent
ones, except that the destination may be a strict subset.  I
think of it as "a copy I throw at a public place to show what I
have in my private repository I work in", so,...

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Petr Baudis]

Dear diary, on Fri, Jul 29, 2005 at 04:24:40AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
> 
> > One of the Cogito design bits is that branch name is something local to
> > the repository. When you are adding a branch, the local name you assign
> > it is your private thing repository-wise, and doesn't have to have any
> > correlation to other repositories you might interact width.
> 
> I do not disagree with that.  I think branch name is mostly a
> local matter.  However, I happen to think that two repositories
> you use send-pack (not clone which uses completely different
> protocol) to sync one from the other are semantically equivalent
> ones, except that the destination may be a strict subset.  I
> think of it as "a copy I throw at a public place to show what I
> have in my private repository I work in", so,...

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?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> 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...

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Petr Baudis]

Dear diary, on Fri, Jul 29, 2005 at 09:48:57AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> 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.

> > 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

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> 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.

Now I see where you are coming from; I tend to agree why you
might want to have different names on the remote end.  I however
still suspect that you might be spreading chaos under the name
of more flexibility.  The fact that you can push into it by
definition means you have some control over the other end, and
obviously you are in total control on your end.  I do not see
why you cannot rename branches where needed so that whatever you
are pushing match.  That would also be one less thing to keep
track of for yourself [*1*].

Yes, I am aware that you brought up the example of pushing to
two separate places, but does it happen in practice that you can
push to two places, and at the same time neither of them
cooperates with you to make it easier for you to work on these
three machines by having the same head names?

Having said that, I do not particulary think allowing push to
write into different ref is an unreasonable thing.  As you
pointed out long time ago when send-pack was first done, the
protocol is not so easily extensible, so this may require either
backward incompatible protocol change, or introduction of a new
program pair send-pack-2 / receive-pack-2.  I'll take a look
sometime this weekend.  Bedtime.


[Footnote]

*1* In a hypothetical situation ``I use branch "b00" in this
repository to do XYZ work but I use branch "b24" in the other
repository for the same XYZ work'', Porcelain can keep track of
mapping between b00:b24 for you, but you still need to keep
track of b00:XYZ and b24:XYZ mapping in your head.

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Petr Baudis]

Dear diary, on Fri, Jul 29, 2005 at 10:54:07AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> I however still suspect that you might be spreading chaos under the
> name of more flexibility.

I'm such a villain! ;-))

> The fact that you can push into it by definition means you have some
> control over the other end, and obviously you are in total control on
> your end.  I do not see why you cannot rename branches where needed so
> that whatever you are pushing match.  That would also be one less
> thing to keep track of for yourself [*1*].

You might get the push access rather lately in the process (this "lazy
development privileges granting" is one of the point of distributed
VCSes), at point where other people are used to pull from you and
renaming your branch locally might mean some trouble.

> Yes, I am aware that you brought up the example of pushing to
> two separate places, but does it happen in practice that you can
> push to two places, and at the same time neither of them
> cooperates with you to make it easier for you to work on these
> three machines by having the same head names?

Yes, they may have incompatible but strict head naming conventions. And
wouldn't it be easier to just have different head names rather than
forcing to increase administrative load 'n stuff?

> [Footnote]
> 
> *1* In a hypothetical situation ``I use branch "b00" in this
> repository to do XYZ work but I use branch "b24" in the other
> repository for the same XYZ work'', Porcelain can keep track of
> mapping between b00:b24 for you, but you still need to keep
> track of b00:XYZ and b24:XYZ mapping in your head.

I think 95% of the cases will be "master locally, non-master remotely".
That's not really that difficult at all.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Johannes Schindelin]

Hi,

On Fri, 29 Jul 2005, Petr Baudis wrote:

> You might get the push access rather lately in the process (this "lazy
> development privileges granting" is one of the point of distributed
> VCSes), at point where other people are used to pull from you and
> renaming your branch locally might mean some trouble.

I still do not get it. What is so wrong with

	git-switch-tree remotehead
	git-merge master
	git-push remoteside remotehead

which would have the further advantage of documenting what you really did
in the history.

And if you really want to be able to spread chaos in your own head, you
can do something like

	ln -s master .git/refs/heads/remotehead
	git-push remoteside remotehead

A change in the protocol is not needed IMHO, and the protocol itself
suggests that you rather use a simple setup. After all, Murphy is lurking
behind every bash script!

Ciao,
Dscho

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Petr Baudis]

Dear diary, on Fri, Jul 29, 2005 at 12:57:50PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> Hi,

Hello,

> On Fri, 29 Jul 2005, Petr Baudis wrote:
> 
> > You might get the push access rather lately in the process (this "lazy
> > development privileges granting" is one of the point of distributed
> > VCSes), at point where other people are used to pull from you and
> > renaming your branch locally might mean some trouble.
> 
> I still do not get it. What is so wrong with
> 
> 	git-switch-tree remotehead
> 	git-merge master
> 	git-push remoteside remotehead
> 
> which would have the further advantage of documenting what you really did
> in the history.

How would that document anything normal push wouldn't?

> And if you really want to be able to spread chaos in your own head, you
> can do something like
> 
> 	ln -s master .git/refs/heads/remotehead
> 	git-push remoteside remotehead

I'd argue that's much more messy and evil than pushing to heads with
different names. If you compare what you just proposed with pushing to
heads with different names, what's the advantage?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Johannes Schindelin]

Hi,

On Fri, 29 Jul 2005, Petr Baudis wrote:

> Dear diary, on Fri, Jul 29, 2005 at 12:57:50PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
>
> > 	git-switch-tree remotehead
> > 	git-merge master
> > 	git-push remoteside remotehead
> >
> > which would have the further advantage of documenting what you really did
> > in the history.
>
> How would that document anything normal push wouldn't?

git-merge?

> > And if you really want to be able to spread chaos in your own head, you
> > can do something like
> >
> > 	ln -s master .git/refs/heads/remotehead
> > 	git-push remoteside remotehead
>
> I'd argue that's much more messy and evil than pushing to heads with
> different names. If you compare what you just proposed with pushing to
> heads with different names, what's the advantage?

It makes it hard. It tells you to be real careful here. It tells you that
you are not babysitted from here on.

Ciao,
Dscho

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Petr Baudis]

Dear diary, on Fri, Jul 29, 2005 at 02:26:51PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> Hi,
> 
> On Fri, 29 Jul 2005, Petr Baudis wrote:
> 
> > Dear diary, on Fri, Jul 29, 2005 at 12:57:50PM CEST, I got a letter
> > where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> >
> > > 	git-switch-tree remotehead
> > > 	git-merge master
> > > 	git-push remoteside remotehead
> > >
> > > which would have the further advantage of documenting what you really did
> > > in the history.
> >
> > How would that document anything normal push wouldn't?
> 
> git-merge?

You have to git-merge anyway if remote head is not your ancestor yet,
otherwise the push cannot proceed.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

>> > How would that document anything normal push wouldn't?
>> 
>> git-merge?
>
> You have to git-merge anyway if remote head is not your ancestor yet,
> otherwise the push cannot proceed.

Indeed.  And if git-merge fast forwards, then you would not get
any trail, so the "documentation by merge" argument does not
stand.

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Matthias Urlichs]

Hi, Junio C Hamano wrote:

> Porcelain can keep track of
> mapping between b00:b24 for you,

Exactly.

> but you still need to keep
> track of b00:XYZ and b24:XYZ mapping in your head.

This is why I name my local branch "XYZ". ;-)

XYZ may not be an appropriate name for the remote branch, or maybe the
remote repo is *not* under my direct control, e.g. a shared-master style
setup.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
:munch: vt. [often confused with {mung}, q.v.] To transform information
   in a serial fashion, often requiring large amounts of computation. To
   trace down a data structure. Related to {crunch} and nearly synonymous
   with {grovel}, but connotes less pain.

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Having said that, I do not particulary think allowing push to
> write into different ref is an unreasonable thing.  As you
> pointed out long time ago when send-pack was first done, the
> protocol is not so easily extensible, so this may require either
> backward incompatible protocol change, or introduction of a new
> program pair send-pack-2 / receive-pack-2.  I'll take a look
> sometime this weekend.  Bedtime.

Again, what Linus designed turns out to be perfect.  It does not
appear to need a protocol level change at all.  I'll code up
something over the weekend if I am lucky.

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Carl Baldwin]

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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Junio C Hamano]

Carl Baldwin <cnb@fc.hp.com> writes:

> 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.
>
> Sorry to join the game so late.  I've only read this thread now.

Just in case you have not noticed, the push in 0.99.4 and
onwards does exactly that.  Please see git-push-script.txt in
the Documentation/ directory --- oops, there is no such thing.

Please see git-send-pack.txt instead, and if you feel like it, I
would appreciate a patch to add the missing documentation for
git-push-script ;-).

What's not supported well yet is the opposite --- downloading
multiple refs and dealing with them.

Johannes Schindelin calls this "reverse push", and I think that
is really a good name to describe what it does.  It takes a
remote repository and possibly multiple refs, downloads the
objects to complete the named remote references, and updates the
local refs only if the remote refs are fast forward children of
the local refs being replaced, just like "push" fast forwards
the remote refs using the local refs.  In other words, given
<src> and <dst> repository, the following should do the same
thing:

    On <src> repository machine, with GIT_DIR being the <src> repository:
    $ git push <dst> <ref-local-name>:<ref-remote-name>...

    On <dst> repository machine, with GIT_DIR being the <dst> repository:
    $ git pull <src> <ref-remote-name>:<ref-local-name>...

Johannes posted a script on the list a couple of days ago, which
should work well, except that it was written before the
git-fetch-pack command was updated to natively download from
multiple refs, so it does not know how to fetch multiple refs at
a one go.

-jc

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Carl Baldwin]

Over the week-end, I was thinking about the thread "Re: How is working
on arbitrary remote heads supposed to work in Cogito".  I wanted to
weigh in an opinion that I've developed on it but thought it deserved a
new thread.

Somewhere in the thread something was mentioned about maintaining
<local branch>:<remote branch> pairs in the git repository when pushes
and pulls are performed.  I think the argument was actually against
keeping this information and ultimately against allowing pushes to a
branch of a different name.

I wanted to weigh in with why it would be a good idea to make note of
this information.  The only thing that would be required of the plumbing
is to specify how this information is kept and if a push or pull is
performed directly with git then make note of the push/pull
relationship.  Everything else would be up to the porcelains.

So, I envision a simple directed graph where nodes represent the
branches (wether local or remote) and the edges represent push or pull
relationships between branches.

Git already stores the nodes.

The edges, in theory, would spring into existence when a push or pull is
performed between two branches for the first time.

This graph will be extremely useful for manageing flow in a project.  It
could enable something as simple as a script that would walk the edges
and tell which ones have fallen behind.  It would also be possible to
easily pull up a visual representation of the graph (with graphviz,
maybe).  This sort of thing might prove to be a valuable orientation
tool for the developer or project manager.

It could also enable some very powerful project flow management --- in a
porcelain of course --- that would manage flow from an engineer's own
sand-box through software engineering 'gates' such as integration,
quality assurance, product maintenance and the documentation and
sign-offs required to pass through each of these gates.

It could also be used to aid in documenting and managing the, already
existent, linux tree development flow in whatever way suits.

This is a big return on investment.  Little would be required of the
plumbing to maintain these 'edges', just add to them when it performs a
push/pull on an edge that hasn't already been recorded.  Any changes or
deletions could be handled by the user or by some porcelain.

I think it is important, though, to specify how this information should
be stored to maintain compatibility between porcelains while (hopefully)
allowing for some degree of flexibility.  I don't yet know where this
line should be drawn.

Carl

On Sat, Aug 13, 2005 at 12:48:32AM -0700, Junio C Hamano wrote:
> Carl Baldwin <cnb@fc.hp.com> writes:
> 
> > 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.
> >
> > Sorry to join the game so late.  I've only read this thread now.
> 
> Just in case you have not noticed, the push in 0.99.4 and
> onwards does exactly that.  Please see git-push-script.txt in
> the Documentation/ directory --- oops, there is no such thing.
> 
> Please see git-send-pack.txt instead, and if you feel like it, I
> would appreciate a patch to add the missing documentation for
> git-push-script ;-).
> 
> What's not supported well yet is the opposite --- downloading
> multiple refs and dealing with them.
> 
> Johannes Schindelin calls this "reverse push", and I think that
> is really a good name to describe what it does.  It takes a
> remote repository and possibly multiple refs, downloads the
> objects to complete the named remote references, and updates the
> local refs only if the remote refs are fast forward children of
> the local refs being replaced, just like "push" fast forwards
> the remote refs using the local refs.  In other words, given
> <src> and <dst> repository, the following should do the same
> thing:
> 
>     On <src> repository machine, with GIT_DIR being the <src> repository:
>     $ git push <dst> <ref-local-name>:<ref-remote-name>...
> 
>     On <dst> repository machine, with GIT_DIR being the <dst> repository:
>     $ git pull <src> <ref-remote-name>:<ref-local-name>...
> 
> Johannes posted a script on the list a couple of days ago, which
> should work well, except that it was written before the
> git-fetch-pack command was updated to natively download from
> multiple refs, so it does not know how to fetch multiple refs at
> a one go.
> 
> -jc
> 

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Johannes Schindelin]

Hi,

On Sat, 13 Aug 2005, Junio C Hamano wrote:

> Johannes posted a script on the list a couple of days ago, which
> should work well, except that it was written before the
> git-fetch-pack command was updated to natively download from
> multiple refs, so it does not know how to fetch multiple refs at
> a one go.

Actually, my script usually only calls fetch once. It checks if the commit 
object is already local before trying to fetch it, and it turns out that a 
single fetch is often (always?) sufficient to slurp the other commits, 
too. I did not have time to find out if that is a true bug in git.

Ciao,
Dscho

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Josef Weidendorfer]

Hi,

On Friday 29 July 2005 09:48, you wrote:
> Petr Baudis <pasky@suse.cz> writes:
> > 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

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Matthias Urlichs]

Hi, Petr Baudis wrote:

> If you fear making mistakes, better use something which attempts to do
> some babysitting for you, like Cogito. ;-)

Some babysitting needs to be part of the core push protocol; anything else
would be prone to race conditions in a multiuser setting, esp. when people
use different porcelains.

At minimum, you'd send the old branch head with the new one, and let the
server not overwrite it if it changed in the meantime.

Then, you'd kill porcelain writers who don't verify that the old head is
a(n indirect) parent of the new one. ;-)

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Madness takes its toll. Please have exact change.

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Petr Baudis]

Dear diary, on Thu, Jul 28, 2005 at 11:13:38PM CEST, I got a letter
where Matthias Urlichs <smurf@smurf.noris.de> told me that...
> Then, you'd kill porcelain writers who don't verify that the old head is
> a(n indirect) parent of the new one. ;-)

send-pack.c:

	if (!ref_newer(new_sha1, ref->old_sha1)) {
		error("remote '%s' isn't a strict parent of local", name);
		continue;
	}

"git-core: Making life nice for Porcelains."

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Josef Weidendorfer]

On Thursday 28 July 2005 17:56, Johannes Schindelin wrote:
> localhead=remotehead. BTW, this whole multihead mess applies only to Jeffs
> anyway :-)

GIT/Cogito usage is not about linux kernel only.
I actually try to work with a scenario for a project with a few developers, 
where each one should have its branch(es) in the central repository. I think 
this could be quite common among future GIT uses. I even would allow the few 
developers to merge into the central master.

> I just do not see a high demand for mappings of remote and local HEAD
> names, but rather a high potential of making mistakes (after all, it is
> not the machine which makes mistakes, it's the human operator).

I also think it is quite confusing to have different branch names for the same 
head in cloned repositories.

But I also think that Paskys scenario is real, where you want to pull branches 
in 2 remote repositories with the same name.

So why not put the name of the remote repository into the local branch name?
A remote branch "host1:path#branch1" could be named "host1:path#branch1".
The shorthand specified with "cg-add-branch" would be a local alias, i.e.
	(cd .git/refs/heads; ln -s host1:path#branch1 mylocalalias)

I even would find it handy to be able to say
	cg-pull host1:path#branch1
, and
	cg-push mylocalbranch host2:path#branch2
should create the alias "mylocalbranch"="host2:path#branch2"
and create a entry in .git/branches.

Josef

Unnamed branches

[Petr Baudis]

Dear diary, on Thu, Jul 28, 2005 at 08:53:56PM CEST, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> told me that...
> So why not put the name of the remote repository into the local branch name?
> A remote branch "host1:path#branch1" could be named "host1:path#branch1".
> The shorthand specified with "cg-add-branch" would be a local alias, i.e.
> 	(cd .git/refs/heads; ln -s host1:path#branch1 mylocalalias)
> 
> I even would find it handy to be able to say
> 	cg-pull host1:path#branch1
> , and
> 	cg-push mylocalbranch host2:path#branch2
> should create the alias "mylocalbranch"="host2:path#branch2"
> and create a entry in .git/branches.

  This is a sensible argument, and I initially disallowed this mainly to
save some work. ;-) But I agree that something like this would be nice.
The issues:

  * How to name the unnamed branches? You need some way to normalize
URLs like http://www.kernel.org/pub/s%63m//cogito/ to something which is
unique for a given location (http://www.kernel.org/pub/scm/cogito) and
usable as filename - at least substituting the slashes for something,
like underscores, and encoding underscored by % sequences.

  * Have all named remote branches as symlinks to their URLs (thus
effectively also eliminating the need for .git/branches/), or keep them
as they are? One disadvantage of the symlinks is that the refs/
directory would become quite messy.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
>> IMHO this opens the door for shooting in your own foot. Isn't it much too
>> easy to make a mistake with that syntax?
>
> What mistake?
>
>> What is so wrong with git-clone not allowing you to name the HEAD
>> differently?
>
> Did you read the preceding discussion? When you are pushing from your
> master branch to a remote branch, it may well be called different over
> there.

The real question is why you would even want to do that.

Managing multiple heads and making sure which one is which even
on a single repository is a mental burden, at least to me.  When
you can name local and remote differently, the name mappings
also need to be managed in addition to that.  Yes, the mappings
can be automated by Porcelains, but that means we need to have
another configuration item around (which needs to be compatible
across Porcelains) to achieve that flexibility, but what does
that flexibility really buys you?

My gut feeling is that Johannes is right here, at least about
the send-pack side.  Storing "master" pulled from a remote under
a name different from the remote is a different story.  I do not
have much problem with that.

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Petr Baudis]

Dear diary, on Thu, Jul 28, 2005 at 06:14:17PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> My gut feeling is that Johannes is right here, at least about
> the send-pack side.  Storing "master" pulled from a remote under
> a name different from the remote is a different story.  I do not
> have much problem with that.

But that means you already have to manage the mapping anyway, with all
the burden of configuration items etc. And what if repository A has
branch 'foo' and repository B also has branch 'foo'?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Petr Baudis]

Dear diary, on Thu, Jul 28, 2005 at 02:08:07PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> told me that...
> See above. I would much rather see more flexible git-send-pack. Junio,
> what about changing its [heads]* parameter e.g. to
> [remotehead[:localhead]]* ?

Ok, I was thinking backwards about it. I meant
[localhead[:remotehead]]*, sorry. :-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox