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 ref
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
: pairs i
Carl Baldwin <[EMAIL PROTECTED]> writes:
> On Fri, Jul 29, 2005 at 08:10:51AM +, 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
On Fri, Jul 29, 2005 at 08:10:51AM +, 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 fi
Junio C Hamano <[EMAIL PROTECTED]> 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
Petr Baudis <[EMAIL PROTECTED]> 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
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
Dear diary, on Fri, Jul 29, 2005 at 02:26:51PM CEST, I got a letter
where Johannes Schindelin <[EMAIL PROTECTED]> 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 <[EMAIL PROTE
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 <[EMAIL PROTECTED]> told me that...
>
> > git-switch-tree remotehead
> > git-merge master
> > git-push remoteside remotehead
> >
> > which woul
Dear diary, on Fri, Jul 29, 2005 at 12:57:50PM CEST, I got a letter
where Johannes Schindelin <[EMAIL PROTECTED]> 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 grantin
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
Dear diary, on Fri, Jul 29, 2005 at 10:54:07AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> 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 definitio
Hi,
On Friday 29 July 2005 09:48, you wrote:
> Petr Baudis <[EMAIL PROTECTED]> 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 a
Petr Baudis <[EMAIL PROTECTED]> 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
Dear diary, on Fri, Jul 29, 2005 at 09:48:57AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> Petr Baudis <[EMAIL PROTECTED]> writes:
>
> > Aha, so it seems our problem is hopefully only in terminology, great.
> >
> > So, what do you mean by "clone" here? And what
Petr Baudis <[EMAIL PROTECTED]> 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 equivale
Dear diary, on Thu, Jul 28, 2005 at 11:13:38PM CEST, I got a letter
where Matthias Urlichs <[EMAIL PROTECTED]> 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->o
Dear diary, on Thu, Jul 28, 2005 at 10:14:35PM CEST, I got a letter
where Johannes Schindelin <[EMAIL PROTECTED]> 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. Th
Dear diary, on Fri, Jul 29, 2005 at 04:24:40AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> Petr Baudis <[EMAIL PROTECTED]> writes:
>
> > One of the Cogito design bits is that branch name is something local to
> > the repository. When you are adding a branch, the
Petr Baudis <[EMAIL PROTECTED]> 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 y
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 di
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 centr
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 HE
Dear diary, on Thu, Jul 28, 2005 at 05:56:21PM CEST, I got a letter
where Johannes Schindelin <[EMAIL PROTECTED]> 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 <[EMAIL
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 h
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
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 actua
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 no
Dear diary, on Thu, Jul 28, 2005 at 06:52:45PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> Petr Baudis <[EMAIL PROTECTED]> writes:
>
> > AFAIK the plan is to centralize all the kernel repositories to a single
> > one. For that, developers would generally push in
Hi,
On Thu, 28 Jul 2005, Junio C Hamano wrote:
> Petr Baudis <[EMAIL PROTECTED]> 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 t
Petr Baudis <[EMAIL PROTECTED]> 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 yo
Dear diary, on Thu, Jul 28, 2005 at 06:14:17PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> 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 dif
Petr Baudis <[EMAIL PROTECTED]> writes:
> Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
> where Johannes Schindelin <[EMAIL PROTECTED]> 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?
>
>
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 <[EMAIL PROTECTED]> told me that...
>
> > On Thu, 28 Jul 2005, Petr Baudis wrote:
> >
> > > See above. I would much rather see more flexible git-send-pack.
Dear diary, on Thu, Jul 28, 2005 at 02:08:07PM CEST, I got a letter
where Petr Baudis <[EMAIL PROTECTED]> 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 b
Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
where Johannes Schindelin <[EMAIL PROTECTED]> 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
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
Dear diary, on Wed, Jul 27, 2005 at 02:58:42PM CEST, I got a letter
where Josef Weidendorfer <[EMAIL PROTECTED]> 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 ch
Josef Weidendorfer <[EMAIL PROTECTED]> 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" me
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 i
40 matches
Mail list logo
