Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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 <[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-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 > and repository, the following should do the same > thing: > > On repository machine, with GIT_DIR being the repository: > $ git push :... > > On repository machine, with GIT_DIR being the repository: > $ git pull :... > > 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 BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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-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 and repository, the following should do the same thing: On repository machine, with GIT_DIR being the repository: $ git push :... On repository machine, with GIT_DIR being the repository: $ git pull :... 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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 BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 > 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 trail, so the "documentation by merge" argument does not stand. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 | [EMAIL PROTECTED]
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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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... - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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->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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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. 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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,... - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Madness takes its toll. Please have exact change.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 | [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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? > > 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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. 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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]* 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 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 <[EMAIL PROTECTED]> told me that... > 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" 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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" 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
