{"thread":{"id":"1523","subject":"Making note, in the repository, of push/pull relationships","startedAt":"2005-08-15T16:25:19Z","lastAt":"2005-08-16T23:01:27Z","messageCount":8,"participants":["Carl Baldwin","Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7302","messageId":"20050815162519.GB9719@hpsvcnb.fc.hp.com","threadId":"1523","inReplyTo":null,"subject":"Making note, in the repository, of push/pull relationships","fromName":"Carl Baldwin","fromEmail":"cnb@fc.hp.com","sentAt":"2005-08-15T16:25:19Z","receivedAt":"2005-08-15T16:25:19Z","isPatch":false,"sender":{"key":"cnb@fc.hp.com","avatar":null},"body":"(Sorry for the repost.  The other one was an accident.)\n\nOver the week-end, I was thinking about the thread \"Re: How is working\non arbitrary remote heads supposed to work in Cogito\".  I wanted to\nweigh in an opinion that I've developed on it but thought it deserved a\nnew thread.\n\nSomewhere in the thread something was mentioned about maintaining\n<local branch>:<remote branch> pairs in the git repository when pushes\nand pulls are performed.  I think the argument was actually against\nkeeping this information and ultimately against allowing pushes to a\nbranch of a different name.\n\nI wanted to weigh in with why it would be a good idea to make note of\nthis information.  The only thing that would be required of the plumbing\nis to specify how this information is kept and if a push or pull is\nperformed directly with git then make note of the push/pull\nrelationship.  Everything else would be up to the porcelains.\n\nSo, I envision a simple directed graph where nodes represent the\nbranches (wether local or remote) and the edges represent push or pull\nrelationships between branches.\n\nGit already stores the nodes.\n\nThe edges, in theory, would spring into existence when a push or pull is\nperformed between two branches for the first time.\n\nThis graph will be extremely useful for manageing flow in a project.  It\ncould enable something as simple as a script that would walk the edges\nand tell which ones have fallen behind.  It would also be possible to\neasily pull up a visual representation of the graph (with graphviz,\nmaybe).  This sort of thing might prove to be a valuable orientation\ntool for the developer or project manager.\n\nIt could also enable some very powerful project flow management --- in a\nporcelain of course --- that would manage flow from an engineer's own\nsand-box through software engineering 'gates' such as integration,\nquality assurance, product maintenance and the documentation and\nsign-offs required to pass through each of these gates.\n\nIt could also be used to aid in documenting and managing the, already\nexistent, linux tree development flow in whatever way suits.\n\nThis is a big return on investment.  Little would be required of the\nplumbing to maintain these 'edges', just add to them when it performs a\npush/pull on an edge that hasn't already been recorded.  Any changes or\ndeletions could be handled by the user or by some porcelain.\n\nI think it is important, though, to specify how this information should\nbe stored to maintain compatibility between porcelains while (hopefully)\nallowing for some degree of flexibility.  I don't yet know where this\nline should be drawn.\n\nCarl\n\n-- \n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n Carl Baldwin                        Systems VLSI Laboratory\n Hewlett Packard Company\n MS 88                               work: 970 898-1523\n 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com\n Fort Collins, CO 80525              home: Carl@ecBaldwin.net\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n"},{"id":"7321","messageId":"Pine.LNX.4.63.0508160044490.25894@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1523","inReplyTo":"20050815162519.GB9719@hpsvcnb.fc.hp.com","subject":"Re: Making note, in the repository, of push/pull relationships","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-15T22:49:33Z","receivedAt":"2005-08-15T22:49:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Aug 2005, Carl Baldwin wrote:\n\n> Somewhere in the thread something was mentioned about maintaining\n> <local branch>:<remote branch> pairs in the git repository when pushes\n> and pulls are performed.  I think the argument was actually against\n> keeping this information and ultimately against allowing pushes to a\n> branch of a different name.\n\nI think the loudest voice was mine :-)\n\nActually, I was not against *keeping* the information, but against \n*pulling* in such strange ways. If \"cross-pulling\" is allowed, I am all \nfor keeping track of that.\n\nIn the meantime, I did not think about the issue at all :-) However, as is \noften the case in an open discussion, I think I was wrong after all. There \nmay be cases you want that, and in the end, nobody forces me to use that \nfeature.\n\nAnyway, Junio decided to enhance the fetch mechanism to support the \ncross-pulling (and also multi-pulling).\n\nCiao,\nDscho\n"},{"id":"7330","messageId":"7vzmrispi4.fsf@assigned-by-dhcp.cox.net","threadId":"1523","inReplyTo":"20050815162519.GB9719@hpsvcnb.fc.hp.com","subject":"Re: Making note, in the repository, of push/pull relationships","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-16T00:18:43Z","receivedAt":"2005-08-16T00:18:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Baldwin <cnb@fc.hp.com> writes:\n\n> Somewhere in the thread something was mentioned about maintaining\n> <local branch>:<remote branch> pairs in the git repository when pushes\n> and pulls are performed.  I think the argument was actually against\n> keeping this information and ultimately against allowing pushes to a\n> branch of a different name.\n\nIf you are referring to what I said about the user having some\ncontrol over both ends hence it should be possible to arrange to\nuse the same name on both ends to reduce mental burden, Pasky\nand others convinced me otherwise during later discussions, and\nthe current core knows how to do renaming pushes.\n\nOne proposal which has not been pursued yet, due to lack of time\non my end if anything else, is to have a set of files that is an\nextension of current $GIT_DIR/branches/* file (which can record\nthe URL and optionally one filename under refs/heads/ over there\nto mean \"which branch to pull from by default\").  Instead, the\nproposal introduces $GIT_DIR/remotes/* files, whose contents\nwould look like this:\n\n    $ cat .git/remotes/ko\n    URL: master.kernel.org:/pub/scm/git/git.git/\n    Push: master pu rc\n    Pull: master:ko-master pu:ko-pu rc:ko-rc\n\nThe expected workflow with the above example \"remotes\" file is\nfor me to be able to do this:\n\n (1) fetch from master.kernel.org (that is the source of the\n     mirroring for everybody to see on {www,rsync}.kernel.org)\n     before starting my day.  The current \"git fetch\" does not\n     do this, but make it:\n\n     $ git fetch ko\n\n     to mean \"fetch from those three branches on the 'Pull:'\n     line, fast-forward local ko-master, ko-pu and ko-rc with\n     these heads\".\n\n     Then I can see where my private heads and publicly visibile\n     ones stand to make sure things are in good order.  E.g. I\n     can do \"git show-branches ko ko-master rc rc-master\".\n\n (2) after doing work in my private repository, push to\n     master.kernel.org with:\n\n     $ git push ko\n\n     This does not happen to involve renaming push, because both\n     ends are owned and controlled by me, but you could put\n     renaming refspec on \"Push:\" line in the .git/remotes line\n     to make it rename.\n\nNote that I am _not_ expecting for \"git push/pull/fetch\"\ncommands to dynamically update .git/remotes/ file whenever it\ngets a new set of heads and renaming refspecs on the command\nline.  Explicit refspecs on the command line will just override\nwhat is recorded in .git/remotes/* files instead.  So:\n\n     $ git push ko pu:refs/heads/testing\n\nwould not push usual \"master pu rc\" but create a new \"testing\"\nbranch there, starting at the commit which is the head commit of\nthe local \"pu\" branch.  This is a one-shot override, so next\ntime around, \"git push ko\" will do the usual three heads that is\nrecorded in the .git/remotes/ko file.\n"},{"id":"7366","messageId":"20050816160327.GA20016@hpsvcnb.fc.hp.com","threadId":"1523","inReplyTo":"Pine.LNX.4.63.0508160044490.25894@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: Making note, in the repository, of push/pull relationships","fromName":"Carl Baldwin","fromEmail":"cnb@fc.hp.com","sentAt":"2005-08-16T16:03:27Z","receivedAt":"2005-08-16T16:03:27Z","isPatch":false,"sender":{"key":"cnb@fc.hp.com","avatar":null},"body":"On Tue, Aug 16, 2005 at 12:49:33AM +0200, Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 15 Aug 2005, Carl Baldwin wrote:\n> \n> > Somewhere in the thread something was mentioned about maintaining\n> > <local branch>:<remote branch> pairs in the git repository when pushes\n> > and pulls are performed.  I think the argument was actually against\n> > keeping this information and ultimately against allowing pushes to a\n> > branch of a different name.\n> \n> I think the loudest voice was mine :-)\n> \n> Actually, I was not against *keeping* the information, but against \n> *pulling* in such strange ways. If \"cross-pulling\" is allowed, I am all \n> for keeping track of that.\n\nSo, just a question.  What, exactly, is meant by 'cross-pulling'?\n\n> In the meantime, I did not think about the issue at all :-) However, as is \n> often the case in an open discussion, I think I was wrong after all. There \n> may be cases you want that, and in the end, nobody forces me to use that \n> feature.\n> \n> Anyway, Junio decided to enhance the fetch mechanism to support the \n> cross-pulling (and also multi-pulling).\n> \n> Ciao,\n> Dscho\n> \n\n-- \n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n Carl Baldwin                        Systems VLSI Laboratory\n Hewlett Packard Company\n MS 88                               work: 970 898-1523\n 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com\n Fort Collins, CO 80525              home: Carl@ecBaldwin.net\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n"},{"id":"7368","messageId":"20050816171142.GB20016@hpsvcnb.fc.hp.com","threadId":"1523","inReplyTo":"7vzmrispi4.fsf@assigned-by-dhcp.cox.net","subject":"Re: Making note, in the repository, of push/pull relationships","fromName":"Carl Baldwin","fromEmail":"cnb@fc.hp.com","sentAt":"2005-08-16T17:11:42Z","receivedAt":"2005-08-16T17:11:42Z","isPatch":false,"sender":{"key":"cnb@fc.hp.com","avatar":null},"body":"On Mon, Aug 15, 2005 at 05:18:43PM -0700, Junio C Hamano wrote:\n> If you are referring to what I said about the user having some\n> control over both ends hence it should be possible to arrange to\n> use the same name on both ends to reduce mental burden, Pasky\n> and others convinced me otherwise during later discussions, and\n> the current core knows how to do renaming pushes.\n\nI wasn't referring to any particular post just a general idea that came\nup in the thread. I wanted a starting point to present my thoughts. :-)\n\n>     $ cat .git/remotes/ko\n>     URL: master.kernel.org:/pub/scm/git/git.git/\n>     Push: master pu rc\n>     Pull: master:ko-master pu:ko-pu rc:ko-rc\n\nThis is very close to what I was getting at.  It records each branch\ninvolved and wether the relationship is push or pull (or possibly both).\n\nIf I may, let me give an example of something I think could serve the\npurpose a little more simply and generically.\n\nLet's say I start with the following:\n% ls .git/refs/heads\nmaster\nmylocalbranch\nmyremotebranch\nko-master\n% cat .git/branches/ko-master\nmaster.kernel.org:/pub/scm/git/git.git\n\nI would add something like this:  (I didn't put much thought into the\nactual directory and file names, forgive me.  ;-)\n\n% cat .git/branches/relationships\npull:ko-master:master\npull:master:mylocalbranch # The next two document my flow locally\npull:mylocalbranch:master\npush:master:myremotebranch # I push my master to a remote that I control\n\n_OR_\n\n% ls .git/relationships/*\npull:ko-master:master\npull:master:mylocalbranch\npull:mylocalbranch:master\npush:master:myremotebranch\n\nI think this is flexible and could easily support the workflow that you\npresent below.  You could do the following as a convenience in using\nfetch in addition to what I suggest above.\n\n% cat .git/remotes/ko\npush: master:ko-master pu:ko-pu rc:ko-rc\npull: ko-master:master ko-pu:pu ko-rc:rc\n\nI might argue that this is now a job for a porcelain script or\nsomething.\n\nWith the addition of the simple relationships file a complete graph of\nyour workflow could derived.  There is no assumption on what the\nworkflow is nor if the branches are local or remote.  This work flow can\nbe arbitrarily simple or complex but further complexity can and should\nbe handled in the porcelains.\n\n> The expected workflow with the above example \"remotes\" file is\n> for me to be able to do this:\n> \n>  (1) fetch from master.kernel.org (that is the source of the\n>      mirroring for everybody to see on {www,rsync}.kernel.org)\n>      before starting my day.  The current \"git fetch\" does not\n>      do this, but make it:\n> \n>      $ git fetch ko\n\nThis is still doable.  As is this...\n\n>  (2) after doing work in my private repository, push to\n>      master.kernel.org with:\n> \n>      $ git push ko\n>\n> Note that I am _not_ expecting for \"git push/pull/fetch\"\n> commands to dynamically update .git/remotes/ file whenever it\n\nSo, with the way I suggest splitting up refspecs and 'relationships' I\n_would_ suggest dynamically adding to (but not deleting from) the\nrelationships file.  But, I agree with you about the refspec.  I think\nthis should be 100% supplied by the user or porcelain.\n\nAdding relationships dynamically will be a good way to document whatever\nflow is being used.  Also, the savy user can periodically check the file\n(or a porcelain with a pretty interface could do something intelligent\nwith it) to see how his work flow has evolved.  He can also\ndelete relationships that are no longer needed if he is a clean-freak\nlike me ;-)\n\nI really think there is some good common ground here.  Let's keep going\nwith this.  I actually have an idea brewing up for a porcelain to handle\nwork-flow in a tightly-knit corporate type development environment.\n\nHey, I've enjoyed the discussion.  I hope to make a valuable\ncontribution to git.  I think it has incredible potential.\n\nCheers,\nCarl\n\n> would not push usual \"master pu rc\" but create a new \"testing\"\n> branch there, starting at the commit which is the head commit of\n> the local \"pu\" branch.  This is a one-shot override, so next\n> time around, \"git push ko\" will do the usual three heads that is\n> recorded in the .git/remotes/ko file.\n> \n> \n\n-- \n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n Carl Baldwin                        Systems VLSI Laboratory\n Hewlett Packard Company\n MS 88                               work: 970 898-1523\n 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com\n Fort Collins, CO 80525              home: Carl@ecBaldwin.net\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n"},{"id":"7380","messageId":"Pine.LNX.4.63.0508162241150.19656@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1523","inReplyTo":"20050816160327.GA20016@hpsvcnb.fc.hp.com","subject":"Re: Making note, in the repository, of push/pull relationships","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-16T20:45:35Z","receivedAt":"2005-08-16T20:45:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Aug 2005, Carl Baldwin wrote:\n\n> So, just a question.  What, exactly, is meant by 'cross-pulling'?\n\nWhen I say \"cross-pulling\" I mean that a branch is pulled from a remote \nrepository, where the named head is called \"a\", but that reference is \npulled into the local branch whose head is \"b\".\n\nExample:\n\n--snip--\n> git-ls-remote-script junio\n\nabe0582207c72ec848e78707577c61a98f5c633d        refs/heads/master\nc506e5687b9257c6182950f245d58cf839abfae4        refs/heads/pu\n1f40c7c24d999675df818f9d7824937a964f9f40        refs/heads/rc\n0918385dbd9656cab0d1d81ba7453d49bbc16250        refs/tags/junio-gpg-pub\nd6602ec5194c87b0fc87103ca4d67251c76f233a        refs/tags/v0.99\nf25a265a342aed6041ab0cc484224d9ca54b6f41        refs/tags/v0.99.1\nc5db5456ae3b0873fc659c19fafdde22313cc441        refs/tags/v0.99.2\n7ceca275d047c90c0c7d5afb13ab97efdf51bd6e        refs/tags/v0.99.3\nb3e9704ecdf48869f635f0aa99ddfb513f885aff        refs/tags/v0.99.4\n\n> git-pull-script junio pu:temporary-proposed-updates\n\n[...]\n\n> echo .git/refs/heads/temporary-proposed-updates\n\nc506e5687b9257c6182950f245d58cf839abfae4\n--snap--\n\nSo, the remote branch \"pu\" gets cross-pulled to the local branch \n\"temporary-proposed-updates\", i.e. to a local branch of a different name.\n\nCiao,\nDscho\n"},{"id":"7383","messageId":"7vll318u8b.fsf@assigned-by-dhcp.cox.net","threadId":"1523","inReplyTo":"20050816171142.GB20016@hpsvcnb.fc.hp.com","subject":"Re: Making note, in the repository, of push/pull relationships","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-16T21:09:08Z","receivedAt":"2005-08-16T21:09:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Baldwin <cnb@fc.hp.com> writes:\n\n> If I may, let me give an example of something I think could serve the\n> purpose a little more simply and generically.\n>\n> Let's say I start with the following:\n> % ls .git/refs/heads\n> master\n> mylocalbranch\n> myremotebranch\n> ko-master\n> % cat .git/branches/ko-master\n> master.kernel.org:/pub/scm/git/git.git\n>\n> I would add something like this:  (I didn't put much thought into the\n> actual directory and file names, forgive me.  ;-)\n>\n> % cat .git/branches/relationships\n> pull:ko-master:master\n> pull:master:mylocalbranch # The next two document my flow locally\n> pull:mylocalbranch:master\n> push:master:myremotebranch # I push my master to a remote that I control\n\nAnd presumably you have .git/branches/myremotebranch file that\nsays something like \"master.kernel.org:/pub/scm/git/git.git\".\nOr should the last line of relationships file be spelled just\npush:master:ko-master?\n\n> % cat .git/remotes/ko\n> push: master:ko-master pu:ko-pu rc:ko-rc\n> pull: ko-master:master ko-pu:pu ko-rc:rc\n>\n> I might argue that this is now a job for a porcelain script or\n> something.\n\nProbably.\n\nMy primary interest in discussing this is to see Porcelain folks\nagree on what notation and semantics to use, and probably set an\nexample by having the minimum base in the barebone Porcelain.\n\nPersonally I think there are two kinds of patch-flow: one that\nis pretty much static that can easily be described with\nsomething like your relationships notation, and ad-hoc one that\nI think should not automatically contaminate the established\nstatic flow your relationships notation nicely describes.  The\ncorporate world may put disproportional stress on the importance\nof the former, but my feeling is that ad-hoc patch-flow that is\noutside your usual static patch-flow is just as important; see\nDocumentation/howto/using-topic-branches.txt for why.\n"},{"id":"7396","messageId":"20050816230127.GA23831@hpsvcnb.fc.hp.com","threadId":"1523","inReplyTo":"7vll318u8b.fsf@assigned-by-dhcp.cox.net","subject":"Re: Making note, in the repository, of push/pull relationships","fromName":"Carl Baldwin","fromEmail":"cnb@fc.hp.com","sentAt":"2005-08-16T23:01:27Z","receivedAt":"2005-08-16T23:01:27Z","isPatch":false,"sender":{"key":"cnb@fc.hp.com","avatar":null},"body":"On Tue, Aug 16, 2005 at 02:09:08PM -0700, Junio C Hamano wrote:\n> And presumably you have .git/branches/myremotebranch file that\n> says something like \"master.kernel.org:/pub/scm/git/git.git\".\n> Or should the last line of relationships file be spelled just\n> push:master:ko-master?\n\nOops, I did intend to add just that to .git/branches/myremotebranch.\n\n> > % cat .git/remotes/ko\n> > push: master:ko-master pu:ko-pu rc:ko-rc\n> > pull: ko-master:master ko-pu:pu ko-rc:rc\n> >\n> > I might argue that this is now a job for a porcelain script or\n> > something.\n> \n> Probably.\n> \n> My primary interest in discussing this is to see Porcelain folks\n> agree on what notation and semantics to use, and probably set an\n> example by having the minimum base in the barebone Porcelain.\n\nThis sounds good.\n\n> Personally I think there are two kinds of patch-flow: one that\n> is pretty much static that can easily be described with\n> something like your relationships notation, and ad-hoc one that\n> I think should not automatically contaminate the established\n> static flow your relationships notation nicely describes.  The\n> corporate world may put disproportional stress on the importance\n> of the former, but my feeling is that ad-hoc patch-flow that is\n> outside your usual static patch-flow is just as important; see\n> Documentation/howto/using-topic-branches.txt for why.\n\nI don't doubt the utility of these topic branches.  In fact, I think it\nwhat he's doing with this is great.  This is exactly the kind of thing\nthe 'relationships' could help out with.\n\nAs he creates branches from existing branches, pushes, pulls and merges\nbetween them the relationships files would maintain a record of this.\nLet's say, for example, he made a change on speed-up-spinlocks and\nmerged it to test.  Later, a bug is found and he fixes the bug on the\nspeed-up-spinlocks branch.  Now, a script could run using the\nrelationships files that could immediately tell that the test branch is\nbehind the speed-up-spinlocks branch and that they should be merged.\nFor someone who has a lot of different things to do this will be\nvaluable.\n\nI would leave maintenance of any static work flows up to the porcelains.\nIf a project chose to use some sort of static flow then it can simply\npopulate the relationships files to help drive pushing and pulling if\nsome rogue developer were to use git alone or some other porcelain (thus\nmaintaining compatibility between porcelains).  If a porcelain wanted to\nbe very strict about adherance to a static flow then checking the\nrelationships could tell if something 'bad' has been done outside of\nthat porcelain.\n\nI hope I'm being clear.  Please let me know if something is not clear.\n\nCarl\n\n-- \n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n Carl Baldwin                        Systems VLSI Laboratory\n Hewlett Packard Company\n MS 88                               work: 970 898-1523\n 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com\n Fort Collins, CO 80525              home: Carl@ecBaldwin.net\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n"}]}