{"thread":{"id":"43","subject":"[PATCH] Add \"clone\" support to lntree","startedAt":"2005-04-16T01:56:03Z","lastAt":"2005-04-20T23:58:58Z","messageCount":29,"participants":["Daniel Barkalow","Petr Baudis","Linus Torvalds","David A. Wheeler","David Greaves","Martin Schlemmer","Jon Seymour","Ingo Molnar","David Mansfield"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"270","messageId":"Pine.LNX.4.21.0504152142360.30848-100000@iabervon.org","threadId":"43","inReplyTo":null,"subject":"[PATCH] Add \"clone\" support to lntree","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-16T01:56:03Z","receivedAt":"2005-04-16T01:56:03Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"I often want to take a base tree, which I keep tracking some remote head,\nand make a local working tree that starts from it. This makes \"git ln -c\n\" give you a tree that you can just start working in and then diff\nagainst the head you'd started from and send off.\n\nSigned-Off-By: Daniel Barkalow \n\nIndex: gitlntree.sh\n===================================================================\n--- b068d3ec7c00cfe4a1f14a898f61c4807cd5bc8b/gitlntree.sh (mode:100755 sha1:17c4966ea64aeced96ae4f1b00f3775c1904b0f1)\n+++ 0877e1b9b70a4305959b7f65ace4044e4ae0afdb/gitlntree.sh (mode:100755 sha1:84cbf0492996f1139b992147b4f53bc14342e3f2)\n@@ -7,11 +7,14 @@\n # same objects database as the current one. It also shares the\n # branches and tags information.\n #\n-# The new directory is completely pristine - there's not even\n-# a directory cache there yet.\n-#\n # Takes the new directory name.\n \n+if [ \"$1\" = \"-c\" ]\n+then\n+ clone=yes\n+ shift 1\n+fi\n+\n destdir=$1\n \n die () {\n@@ -32,3 +35,12 @@\n ln -s $srcdir/.git/objects $dgitdir/objects\n ln -s $srcdir/.git/remotes $dgitdir/remotes\n ln -s $srcdir/.git/tags $dgitdir/tags\n+\n+if [ \"$clone\" != \"\" ]\n+then\n+ cp $srcdir/.git/HEAD $dgitdir/HEAD\n+ cd $destdir\n+ read-tree $(tree-id)\n+ checkout-cache -a\n+ update-cache --refresh\n+fi\n\n"},{"id":"272","messageId":"20050416024755.GX7417@pasky.ji.cz","threadId":"43","inReplyTo":"Pine.LNX.4.21.0504152142360.30848-100000@iabervon.org","subject":"Re: Add \"clone\" support to lntree","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-16T02:47:55Z","receivedAt":"2005-04-16T02:47:55Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Apr 16, 2005 at 03:56:03AM CEST, I got a letter\nwhere Daniel Barkalow told me that...\n> I often want to take a base tree, which I keep tracking some remote head,\n> and make a local working tree that starts from it. This makes \"git ln -c\n> \" give you a tree that you can just start working in and then diff\n> against the head you'd started from and send off.\n> \n> Signed-Off-By: Daniel Barkalow \n\nI'm sorry but you are late, I added it about a hour and half ago or so.\n:-) Check git fork. (I *want* separate command than git lntree. In fact,\nI think I should make git lntree gitXlntree.sh instead, since it is\nreally internal command for git-tools and the user should probably never\nneed it for anything. git lntree is too lowlevel.)\n\nActually, I don't like the name at all, though. Some people may find\npondering about names pointless, but when I'm going to type them in\nevery day for the rest of my life, they better should not be stupid. ;-)\n\nSo, what are your clever ideas about git fork's proper name? Or should\nwe leave it as is?\n\nSummary of current related git commands (yes, they are already around\nand should be actually all working):\n\n\tgit addremote --- registers a remote branch (name - URL pair)\n\tgit branch --- creates a branch from a given commit\n\t\t\t(when passed empty commit, creates a branch\n\t\t\tfrom the current commit and sets the working\n\t\t\ttree to that branch)\n\tgit clone --- creates a local GIT repository from a remote one\n\tgit export --- checks out given commit to a separate directory\n\t\t\t(without any GIT information)\n\tgit fork --- creates a new branch and working tree from\n\t\t\tthe current working tree, sharing the same\n\t\t\tlocal GIT repository\n\tgit lntree --- creates a \"treeshell\" sharing the same GIT\n\t\t\trepository with the current tree\n\nIf you think any other of those should be renamed, this is the time to\nspeak up. Oh well, I think I'll regret asking about this at all... ;-)\n\nNote that there is a bug in current git update - it will allow you to\nbring several of your trees to follow the same branch, or even a remote\nbranch. This is not even supposed to work, and will be fixed when I get\nsome sleep. You will be able to do git pull even on local branches, and\nthe proper solution for this will be just tracking the branch you want\nto follow.\n\nSo, I'll fix that tomorrow, enable you to fork to an existing but unused\nbranch, fix git pull of remote branch by several local branches, and\nwrite a lot of documentation.\n\nKind regards,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"276","messageId":"20050416025844.GY7417@pasky.ji.cz","threadId":"43","inReplyTo":"20050416024755.GX7417@pasky.ji.cz","subject":"Re: Re: Add \"clone\" support to lntree","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-16T02:58:44Z","receivedAt":"2005-04-16T02:58:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter\nwhere Petr Baudis told me that...\n> \tgit branch --- creates a branch from a given commit\n> \t\t\t(when passed empty commit, creates a branch\n> \t\t\tfrom the current commit and sets the working\n> \t\t\ttree to that branch)\n> Note that there is a bug in current git update - it will allow you to\n> bring several of your trees to follow the same branch, or even a remote\n> branch. This is not even supposed to work, and will be fixed when I get\n> some sleep. You will be able to do git pull even on local branches, and\n> the proper solution for this will be just tracking the branch you want\n> to follow.\n\nI must admit that I'm not entirely decided yet, so I'd love to hear your\nopinion.\n\nI'm wondering, whether each tree should be fixed to a certain branch.\nThat is, you decide a name when you do git fork, and then the tree\nalways follows that branch. (It always has to follow [be bound to]\n*some* branch, and each branch can be followed by only a single tree at\na time.)\n\nCurrently, you can at anytime \"mark\" a new branch (by git branch) and\nyou can freely \"rebranch\" your tree (by git update). An alternative\napproach would be to disallow git update to \"rebranch\" and remove the\ngit branch command (you'd always do git fork).\n\n From what I know, the alternative approach is nearer to what BK takes,\nand it would be _slightly_ simpler (maybe). OTOH the current approach is\nI believe more powerful, and could require less resources.\n\nWWhat do you think,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"277","messageId":"Pine.LNX.4.21.0504152251300.30848-100000@iabervon.org","threadId":"43","inReplyTo":"20050416024755.GX7417@pasky.ji.cz","subject":"Re: Add \"clone\" support to lntree","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-16T03:06:54Z","receivedAt":"2005-04-16T03:06:54Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 16 Apr 2005, Petr Baudis wrote:\n\n> Dear diary, on Sat, Apr 16, 2005 at 03:56:03AM CEST, I got a letter\n> where Daniel Barkalow told me that...\n> > I often want to take a base tree, which I keep tracking some remote head,\n> > and make a local working tree that starts from it. This makes \"git ln -c\n> > \" give you a tree that you can just start working in and then diff\n> > against the head you'd started from and send off.\n> > \n> > Signed-Off-By: Daniel Barkalow \n> \n> I'm sorry but you are late, I added it about a hour and half ago or so.\n> :-) Check git fork. (I *want* separate command than git lntree. In fact,\n> I think I should make git lntree gitXlntree.sh instead, since it is\n> really internal command for git-tools and the user should probably never\n> need it for anything. git lntree is too lowlevel.)\n\nHave you not pushed since? I don't see it.\n\nI actually first made gitlntree.sh do the forking thing, because it didn't\nseem useful as is, until I noticed that merge was already using it\ninternally.\n\n> Actually, I don't like the name at all, though. Some people may find\n> pondering about names pointless, but when I'm going to type them in\n> every day for the rest of my life, they better should not be stupid. ;-)\n> \n> So, what are your clever ideas about git fork's proper name? Or should\n> we leave it as is?\n\nI think \"fork\" is as good as anything for describing the operation. I had\nthought about \"clone\" because it seemed to fill the role that \"bk\nclone\" had (although I never used BK, so I'm not sure). It doesn't seem\nuseful to me to try cloning multiple remote repositories, since you'd get\na copy of anything common from each; you just want to suck everything into\nthe same .git/objects and split off working directories.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"279","messageId":"Pine.LNX.4.58.0504152014330.7211@ppc970.osdl.org","threadId":"43","inReplyTo":"20050416025844.GY7417@pasky.ji.cz","subject":"Re: Re: Add \"clone\" support to lntree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-16T03:16:12Z","receivedAt":"2005-04-16T03:16:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 16 Apr 2005, Petr Baudis wrote:\n> \n> I'm wondering, whether each tree should be fixed to a certain branch.\n\nI'm wondering why you talk about \"branches\" at all.\n\nNo such thing should exist. There are no branches. There are just \nrepositories. You can track somebody elses repository, but you should \ntrack it by location, not by any \"branch name\".\n\nAnd you track it by just merging it.\n\nYeah, we don't have really usable merges yet, but..\n\n\t\tLinus\n"},{"id":"280","messageId":"Pine.LNX.4.21.0504152307050.30848-100000@iabervon.org","threadId":"43","inReplyTo":"20050416025844.GY7417@pasky.ji.cz","subject":"Re: Re: Add \"clone\" support to lntree","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-16T03:17:00Z","receivedAt":"2005-04-16T03:17:00Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 16 Apr 2005, Petr Baudis wrote:\n\n> Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter\n> where Petr Baudis told me that...\n> > \tgit branch --- creates a branch from a given commit\n> > \t\t\t(when passed empty commit, creates a branch\n> > \t\t\tfrom the current commit and sets the working\n> > \t\t\ttree to that branch)\n> > Note that there is a bug in current git update - it will allow you to\n> > bring several of your trees to follow the same branch, or even a remote\n> > branch. This is not even supposed to work, and will be fixed when I get\n> > some sleep. You will be able to do git pull even on local branches, and\n> > the proper solution for this will be just tracking the branch you want\n> > to follow.\n> \n> I must admit that I'm not entirely decided yet, so I'd love to hear your\n> opinion.\n> \n> I'm wondering, whether each tree should be fixed to a certain branch.\n> That is, you decide a name when you do git fork, and then the tree\n> always follows that branch. (It always has to follow [be bound to]\n> *some* branch, and each branch can be followed by only a single tree at\n> a time.)\n\nI don't think I'm following the use of branches. Currently, what I do is\nhave a git-pasky and a git-linus, and fork off a working directory from\none of these for each thing I want to work on. I do some work, commit as I\nmake progress, and then do a diff against the remote head to get a patch\nto send off. If I want to do a series of patches which depend on each\nother, I fork my next directory off of my previous one rather than off of\na remote base. I haven't done much rebasing, so I haven't worked out how I\nwould do that most effectively.\n\nI think I can make this space efficient by hardlinking unmodified blobs to\na directory of cached expanded blobs.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"293","messageId":"20050416113955.GB14326@pasky.ji.cz","threadId":"43","inReplyTo":"Pine.LNX.4.58.0504152014330.7211@ppc970.osdl.org","subject":"Re: Re: Re: Add \"clone\" support to lntree","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-16T11:39:56Z","receivedAt":"2005-04-16T11:39:56Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Apr 16, 2005 at 05:16:12AM CEST, I got a letter\nwhere Linus Torvalds told me that...\n> On Sat, 16 Apr 2005, Petr Baudis wrote:\n> > \n> > I'm wondering, whether each tree should be fixed to a certain branch.\n> \n> I'm wondering why you talk about \"branches\" at all.\n> \n> No such thing should exist. There are no branches. There are just \n> repositories. You can track somebody elses repository, but you should \n> track it by location, not by any \"branch name\".\n> \n> And you track it by just merging it.\n> \n> Yeah, we don't have really usable merges yet, but..\n\nFirst, this \"level\" of branches concerns multiple working directories\ntied to a single repository. It seems like a sensible thing to do; and\nyou agreed with it too (IIRC). And when you do that, git-pasky just\nsaves some work for you. For git-pasky, branch is really just a symbolic\nname for a commit ID, which gets updated every time you commit in some\nrepository. Nothing more.\n\nSo the whole point of this is to have a symbolic name for some other\nworking directory. When you want to merge, you don't need to go over to\nthe other directory, do commit-id, cut'n'paste, and feed that to git\nmerge. You just do\n\n\t\tgit merge myotherbranch\n\n\nNow, about remote repositories. When you pull a remote repository, that\ndoes not mean it has to be immediately merged somewhere. It is very\nuseful to have another branch you do *not* want to merge, but you want\nto do diffs to it, or even check it out / export it later to some\nseparate directory. Again, the \"branch\" is just a symbolic name for the\nhead commit ID of what you pulled, and the pointer gets updated every\ntime you pull again - that's the whole point of it.\n\nThe last concept are \"tracking\" working directories. If you pull the\ntracked branch to this directory, it also automerges it. This is useful\nwhen you have a single canonical branch for this directory, which it\nshould always mirror. That would be the case e.g. for the gazillions of\nLinux users who would like to just have the latest bleeding kernel of\nyour, and they expect to use git just like a \"different CVS\". Basically,\nthey will just do\n\n\t\tgit pull\n\ninstead of\n\n\t\tcvs update\n\n:-).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"374","messageId":"20050416230000.GN19099@pasky.ji.cz","threadId":"43","inReplyTo":"Pine.LNX.4.21.0504152251300.30848-100000@iabervon.org","subject":"Re: Re: Add \"clone\" support to lntree","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-16T23:00:00Z","receivedAt":"2005-04-16T23:00:00Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Apr 16, 2005 at 05:06:54AM CEST, I got a letter\nwhere Daniel Barkalow told me that...\n> On Sat, 16 Apr 2005, Petr Baudis wrote:\n> > I'm sorry but you are late, I added it about a hour and half ago or so.\n> > :-) Check git fork. (I *want* separate command than git lntree. In fact,\n> > I think I should make git lntree gitXlntree.sh instead, since it is\n> > really internal command for git-tools and the user should probably never\n> > need it for anything. git lntree is too lowlevel.)\n> \n> Have you not pushed since? I don't see it.\n\nSee my last mail. :-)\n\n> I think \"fork\" is as good as anything for describing the operation. I had\n> thought about \"clone\" because it seemed to fill the role that \"bk\n> clone\" had (although I never used BK, so I'm not sure). It doesn't seem\n> useful to me to try cloning multiple remote repositories, since you'd get\n> a copy of anything common from each; you just want to suck everything into\n> the same .git/objects and split off working directories.\n\nActually, what about if git pull outside of repository did what git\nclone does now? I'd kinda like clone instead of fork too.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"377","messageId":"Pine.LNX.4.21.0504161902380.30848-100000@iabervon.org","threadId":"43","inReplyTo":"20050416230000.GN19099@pasky.ji.cz","subject":"Re: Re: Add \"clone\" support to lntree","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-16T23:07:35Z","receivedAt":"2005-04-16T23:07:35Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 17 Apr 2005, Petr Baudis wrote:\n\n> Dear diary, on Sat, Apr 16, 2005 at 05:06:54AM CEST, I got a letter\n> where Daniel Barkalow told me that...\n>\n> > I think \"fork\" is as good as anything for describing the operation. I had\n> > thought about \"clone\" because it seemed to fill the role that \"bk\n> > clone\" had (although I never used BK, so I'm not sure). It doesn't seem\n> > useful to me to try cloning multiple remote repositories, since you'd get\n> > a copy of anything common from each; you just want to suck everything into\n> > the same .git/objects and split off working directories.\n> \n> Actually, what about if git pull outside of repository did what git\n> clone does now? I'd kinda like clone instead of fork too.\n\nThis seems like the best solution to me, too. Although that would make\npull take a URL when making a new repository and not otherwise, which\nmight be confusing. \"init-remote\" perhaps, or maybe just have \"init\" do it\nif given a URL?\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"388","messageId":"20050416233305.GO19099@pasky.ji.cz","threadId":"43","inReplyTo":"Pine.LNX.4.21.0504152307050.30848-100000@iabervon.org","subject":"Re: Re: Re: Add \"clone\" support to lntree","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-16T23:33:05Z","receivedAt":"2005-04-16T23:33:05Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Apr 16, 2005 at 05:17:00AM CEST, I got a letter\nwhere Daniel Barkalow told me that...\n> On Sat, 16 Apr 2005, Petr Baudis wrote:\n> \n> > Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter\n> > where Petr Baudis told me that...\n> > > \tgit branch --- creates a branch from a given commit\n> > > \t\t\t(when passed empty commit, creates a branch\n> > > \t\t\tfrom the current commit and sets the working\n> > > \t\t\ttree to that branch)\n> > > Note that there is a bug in current git update - it will allow you to\n> > > bring several of your trees to follow the same branch, or even a remote\n> > > branch. This is not even supposed to work, and will be fixed when I get\n> > > some sleep. You will be able to do git pull even on local branches, and\n> > > the proper solution for this will be just tracking the branch you want\n> > > to follow.\n> > \n> > I must admit that I'm not entirely decided yet, so I'd love to hear your\n> > opinion.\n> > \n> > I'm wondering, whether each tree should be fixed to a certain branch.\n> > That is, you decide a name when you do git fork, and then the tree\n> > always follows that branch. (It always has to follow [be bound to]\n> > *some* branch, and each branch can be followed by only a single tree at\n> > a time.)\n> \n> I don't think I'm following the use of branches. Currently, what I do is\n> have a git-pasky and a git-linus, and fork off a working directory from\n> one of these for each thing I want to work on. I do some work, commit as I\n> make progress, and then do a diff against the remote head to get a patch\n> to send off. If I want to do a series of patches which depend on each\n> other, I fork my next directory off of my previous one rather than off of\n> a remote base. I haven't done much rebasing, so I haven't worked out how I\n> would do that most effectively.\n\nYes. And that's exactly what the branches allow you to do. You just do\n\n\tgit fork myhttpclient ~/myhttpclientdir\n\nthen you do some hacking, and when you have something usable, you can\ngo back to your main working directory and do\n\n\tgit merge -b when_you_started myhttpclient\n\nSince you consider the code perfect, you can now just rm -rf\n~/myhttpclient.\n\nSuddenly, you get a mail from mj pointing out some bugs, and it looks\nlike there are more to come. What to do?\n\n\tgit fork myhttpclient ~/myhttpclientdir\n\n(Ok, this does not work, but that's a bug, will fix tomorrow.) This will\nlet you take off when you left in your work on the branch.\n\ngit update for seeking between commits is probably extremely important\nfor any kind of binary search when you are wondering when did this bug\nappeared first, or when you are exploring how certain branch evolved\nover time. Doing git fork for each successive iteration sounds horrible.\n\n\nNow, what about git branch and git update for switching between\nbranches? I think this is the most controversial part; these are\nbasically just shortcuts for not having to do git fork, and I wouldn't\nmind so much removing them, if you people really consider them too ugly\na wart for the soft clean git skin. I admit that they both come from a\nhidden prejudice that git fork is going to be slow and eat a lot of\ndisk.\n\nThe idea for git branch is to mark a commit as \"this is a branch but I\ndon't want to git fork\" (because I'm lazy or short on disk space or\nwhatever). Let's say you are tracking a branch, do some local commits\nand then want to untrack. This will get you back to HEAD.local, but you\nwant to keep a reference for your local commits, and possibly work on\nthem more later - so you mark them as a branch. But thinking about it, I\ncouldn't come up with another usage case than this, and I think that now\nthat we have git fork, I will modify git track behaviour heavily so that\ntracking/untracking won't really switch you to the other branch\ncompletely, but really only tell git pull that you want the pulled\nupdates applied. So git branch command will likely go.\n\nThe idea for git update for switching between branches is that\nespecially when you have two rather similar branches and mostly do stuff\non one of them, but sometimes you want to do something on the other one,\nyou can do just quick git update, do stuff, and git update back, without\nany forking.\n\n\nNote that this all is *absolutely* subject to change, provided you can\nconvince me about some better way. ;-) My mindset on this is pretty\nopen. This is just what seems to me as a pretty flexible and elegant to\ndo stuff, while giving you enough freedom to pick your own style.\n\n> I think I can make this space efficient by hardlinking unmodified blobs to\n> a directory of cached expanded blobs.\n\nI don't know but I really feel *very* unsafe when doing that. What if\nsomething screws up and corrupts my base... way too easy. And it gets\npretty inconvenient and even more dangerous when you get the idea to do\nsome modifications on your tree by something else than your favorite\neditor (which you've already checked does the right thing).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"393","messageId":"20050416234454.GR19099@pasky.ji.cz","threadId":"43","inReplyTo":"Pine.LNX.4.21.0504161902380.30848-100000@iabervon.org","subject":"Re: Re: Re: Add \"clone\" support to lntree","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-16T23:44:54Z","receivedAt":"2005-04-16T23:44:54Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Apr 17, 2005 at 01:07:35AM CEST, I got a letter\nwhere Daniel Barkalow told me that...\n> > Actually, what about if git pull outside of repository did what git\n> > clone does now? I'd kinda like clone instead of fork too.\n> \n> This seems like the best solution to me, too. Although that would make\n> pull take a URL when making a new repository and not otherwise, which\n> might be confusing. \"init-remote\" perhaps, or maybe just have \"init\" do it\n> if given a URL?\n\nYes, init taking URL optionally sounds ideal. Thanks.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"398","messageId":"Pine.LNX.4.21.0504161951160.30848-100000@iabervon.org","threadId":"43","inReplyTo":"20050416233305.GO19099@pasky.ji.cz","subject":"Re: Re: Re: Add \"clone\" support to lntree","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-17T00:07:36Z","receivedAt":"2005-04-17T00:07:36Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 17 Apr 2005, Petr Baudis wrote:\n\n> Dear diary, on Sat, Apr 16, 2005 at 05:17:00AM CEST, I got a letter\n> where Daniel Barkalow told me that...\n> > On Sat, 16 Apr 2005, Petr Baudis wrote:\n> > \n> > > Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter\n> > > where Petr Baudis told me that...\n> > > > \tgit branch --- creates a branch from a given commit\n> > > > \t\t\t(when passed empty commit, creates a branch\n> > > > \t\t\tfrom the current commit and sets the working\n> > > > \t\t\ttree to that branch)\n> > > > Note that there is a bug in current git update - it will allow you to\n> > > > bring several of your trees to follow the same branch, or even a remote\n> > > > branch. This is not even supposed to work, and will be fixed when I get\n> > > > some sleep. You will be able to do git pull even on local branches, and\n> > > > the proper solution for this will be just tracking the branch you want\n> > > > to follow.\n> > > \n> > > I must admit that I'm not entirely decided yet, so I'd love to hear your\n> > > opinion.\n> > > \n> > > I'm wondering, whether each tree should be fixed to a certain branch.\n> > > That is, you decide a name when you do git fork, and then the tree\n> > > always follows that branch. (It always has to follow [be bound to]\n> > > *some* branch, and each branch can be followed by only a single tree at\n> > > a time.)\n> > \n> > I don't think I'm following the use of branches. Currently, what I do is\n> > have a git-pasky and a git-linus, and fork off a working directory from\n> > one of these for each thing I want to work on. I do some work, commit as I\n> > make progress, and then do a diff against the remote head to get a patch\n> > to send off. If I want to do a series of patches which depend on each\n> > other, I fork my next directory off of my previous one rather than off of\n> > a remote base. I haven't done much rebasing, so I haven't worked out how I\n> > would do that most effectively.\n> \n> Yes. And that's exactly what the branches allow you to do. You just do\n> \n> \tgit fork myhttpclient ~/myhttpclientdir\n> \n> then you do some hacking, and when you have something usable, you can\n> go back to your main working directory and do\n> \n> \tgit merge -b when_you_started myhttpclient\n> \n> Since you consider the code perfect, you can now just rm -rf\n> ~/myhttpclient.\n> \n> Suddenly, you get a mail from mj pointing out some bugs, and it looks\n> like there are more to come. What to do?\n> \n> \tgit fork myhttpclient ~/myhttpclientdir\n> \n> (Ok, this does not work, but that's a bug, will fix tomorrow.) This will\n> let you take off when you left in your work on the branch.\n\nAh, I think that's what made me think I wasn't understanding branches; the\nfirst thing I tried hit this big.\n\n> git update for seeking between commits is probably extremely important\n> for any kind of binary search when you are wondering when did this bug\n> appeared first, or when you are exploring how certain branch evolved\n> over time. Doing git fork for each successive iteration sounds horrible.\n\nEven if there isn't a performance hit, it's semantically wrong, because\nyou're looking at different versions that were in the same place at\ndifferent times.\n\n> Now, what about git branch and git update for switching between\n> branches? I think this is the most controversial part; these are\n> basically just shortcuts for not having to do git fork, and I wouldn't\n> mind so much removing them, if you people really consider them too ugly\n> a wart for the soft clean git skin. I admit that they both come from a\n> hidden prejudice that git fork is going to be slow and eat a lot of\n> disk.\n\nI think that this just confuses matters.\n\n> The idea for git update for switching between branches is that\n> especially when you have two rather similar branches and mostly do stuff\n> on one of them, but sometimes you want to do something on the other one,\n> you can do just quick git update, do stuff, and git update back, without\n> any forking.\n\nI still think that fork should be quick enough, or you could leave the\nextra tree around. I'm not against having such a command, but I think it\nshould be a separate command rather than a different use of update, since\nit would be used by poeople working in different ways.\n\n> > I think I can make this space efficient by hardlinking unmodified blobs to\n> > a directory of cached expanded blobs.\n> \n> I don't know but I really feel *very* unsafe when doing that. What if\n> something screws up and corrupts my base... way too easy. And it gets\n> pretty inconvenient and even more dangerous when you get the idea to do\n> some modifications on your tree by something else than your favorite\n> editor (which you've already checked does the right thing).\n\nIt should only be an option, not required and maybe not even\ndefault. I think it should be possible to prevent stuff from screwing up,\nsince we really don't want anything to ever modify those inodes (as\nopposed to some cases, where you want to modify inodes only in certain\nways). For that matter, relatively few programs actually support\nmodifying inodes rather than unlinking.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"750","messageId":"20050419011206.GT5554@pasky.ji.cz","threadId":"43","inReplyTo":"Pine.LNX.4.21.0504161951160.30848-100000@iabervon.org","subject":"Re: Re: Re: Add \"clone\" support to lntree","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-19T01:12:07Z","receivedAt":"2005-04-19T01:12:07Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"For the record, mostly... (this is how it already is in git-pasky-0.5)\n\nDear diary, on Sun, Apr 17, 2005 at 02:07:36AM CEST, I got a letter\nwhere Daniel Barkalow told me that...\n> > Now, what about git branch and git update for switching between\n> > branches? I think this is the most controversial part; these are\n> > basically just shortcuts for not having to do git fork, and I wouldn't\n> > mind so much removing them, if you people really consider them too ugly\n> > a wart for the soft clean git skin. I admit that they both come from a\n> > hidden prejudice that git fork is going to be slow and eat a lot of\n> > disk.\n> \n> I think that this just confuses matters.\n\nI killed them both for good.\n\n> > The idea for git update for switching between branches is that\n> > especially when you have two rather similar branches and mostly do stuff\n> > on one of them, but sometimes you want to do something on the other one,\n> > you can do just quick git update, do stuff, and git update back, without\n> > any forking.\n> \n> I still think that fork should be quick enough, or you could leave the\n> extra tree around. I'm not against having such a command, but I think it\n> should be a separate command rather than a different use of update, since\n> it would be used by poeople working in different ways.\n\nI've removed git branch, removed the possibility for git update to\nswitch branches and renamed git update to git seek. You can do\n\n\tgit seek git-pasky-0.1\n\nand examine stuff, but your tree is also blocked at the same time - git\nwon't let you commit, merge and such. By doing\n\n\tgit seek\nor\n\tgit seek master\n\nyou return back to your branch (assuming its name is master).\n\nI think git fork is after all good enough for branching and it is the\nclean way. Shall there be a big demand for it, it should be minimal\nhassle to implement 'git switch', which would do that.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"768","messageId":"42646967.9030903@dwheeler.com","threadId":"43","inReplyTo":"20050419011206.GT5554@pasky.ji.cz","subject":"Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-04-19T02:13:59Z","receivedAt":"2005-04-19T02:13:59Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"This is a minor UI thing, but what the heck. I propose\nchanging \"pull\" to ONLY download, and \"update\" to pull AND merge.\nWhenever you want to update, just say \"git update\", end of story.\n\nWhy? It seems oddly inconsistent that \"pull\" sometimes merges\nin changes, but at other times it doesn't. If I normally\ntrack someone, but temporarily don't want to (I'm in the middle\nof lots of changes but I _do_ want to see what's going on),\nI have to \"untrack\", pull, and then \"retrack\" again (remembering who\nI once tracked, which may be more of a trick over time).\nMaybe more important, that is more annoying when you're\ntrying to \"just pull data\" from a script; I need to\ndo the untrack, pull, & retrack shuffle just to download data.\n\nI propose that there be two subcommands, \"pull\" and \"update\"\n(now that \"update\" isn't a reserved word again).\nA \"git pull\" ONLY downloads; a \"git update\" pulls AND merges.\nThat means each command does exactly one thing, very simple &\nclean to explain. Also, some tools (such as subversion) already\nuse \"update\" as meaning this (auto download & merge from the\ngiven repository), so the terminology would make sense for some.\n\nI'd be happy to send in a patch to do that. The coding is trivial,\nbut it means a UI change in one of the most common commands\n(use \"update\" instead of \"pull\" in the typical case).\nI could add a \"reminder\" message after pulling, to let people\nadjust to the new commands for a little while.\n\n--- David A. Wheeler\n"},{"id":"806","messageId":"4264CCFF.30400@dgreaves.com","threadId":"43","inReplyTo":"42646967.9030903@dwheeler.com","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-04-19T09:18:55Z","receivedAt":"2005-04-19T09:18:55Z","isPatch":false,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"David A. Wheeler wrote:\n> I propose changing \"pull\" to ONLY download, and \"update\" to pull AND merge.\n\n> Why? It seems oddly inconsistent that \"pull\" sometimes merges\n> in changes, but at other times it doesn't.\ntrue\n\n> I propose that there be two subcommands, \"pull\" and \"update\"\n> (now that \"update\" isn't a reserved word again).\n> A \"git pull\" ONLY downloads; a \"git update\" pulls AND merges.\n\nWhat's the most common thing to do? pull or update?\nwhich is easier to type?\nwhat are people used to?\n\nI'm not sure but I suggest that pull and get would be better choices.\n\ngit pull\ngit get\n\nis it rare enough to justify:\ngit --download-only pull\n\n\nDavid\n\n-- \n"},{"id":"807","messageId":"20050419092812.GE2393@pasky.ji.cz","threadId":"43","inReplyTo":"4264CCFF.30400@dgreaves.com","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-19T09:28:12Z","receivedAt":"2005-04-19T09:28:12Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got a letter\nwhere David Greaves told me that...\n> What's the most common thing to do? pull or update?\n\nupdate for normal users.\n\n> which is easier to type?\n> what are people used to?\n\nI think 'git up' is easier to type than 'git pull'. It's the CVS/SVN\ntradition, though, probably not the BK tradition.\n\n> I'm not sure but I suggest that pull and get would be better choices.\n> \n> git pull\n> git get\n\nI don't like git get; it is something completely new - not in CVS/SVN\nand means something completely different in BK, apparently.\n\n> is it rare enough to justify:\n> git --download-only pull\n\nDunno. I do it personally all the time, with git at least.\n\nWhat do others think? :-)\n\nI start to like the pull/update distinction, and I think I'll go for it.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"808","messageId":"1113905110.1262.1.camel@nosferatu.lan","threadId":"43","inReplyTo":"20050419092812.GE2393@pasky.ji.cz","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"Martin Schlemmer","fromEmail":"azarah@nosferatu.za.org","sentAt":"2005-04-19T10:05:10Z","receivedAt":"2005-04-19T10:05:10Z","isPatch":false,"sender":{"key":"azarah@nosferatu.za.org","avatar":null},"body":"On Tue, 2005-04-19 at 11:28 +0200, Petr Baudis wrote:\n> Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got a letter\n> where David Greaves told me that...\n>\n> Dunno. I do it personally all the time, with git at least.\n> \n> What do others think? :-)\n> \n\nI think pull is pull. If you are doing lots of local stuff and do not\nwant it overwritten, it should have been in a forked branch.\n\n> I start to like the pull/update distinction, and I think I'll go for it.\n> \n\n-- \nMartin Schlemmer\n\n"},{"id":"810","messageId":"20050419105008.GB12757@pasky.ji.cz","threadId":"43","inReplyTo":"1113905110.1262.1.camel@nosferatu.lan","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-19T10:50:08Z","receivedAt":"2005-04-19T10:50:08Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Apr 19, 2005 at 12:05:10PM CEST, I got a letter\nwhere Martin Schlemmer told me that...\n> On Tue, 2005-04-19 at 11:28 +0200, Petr Baudis wrote:\n> > Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got a letter\n> > where David Greaves told me that...\n> >\n> > Dunno. I do it personally all the time, with git at least.\n> > \n> > What do others think? :-)\n> > \n> \n> I think pull is pull. If you are doing lots of local stuff and do not\n> want it overwritten, it should have been in a forked branch.\n\nI disagree. This already forces you to have two branches (one to pull\nfrom to get the data, mirroring the remote branch, one for your real\nwork) uselessly and needlessly.\n\nI think there is just no good name for what pull is doing now, and\nupdate seems like a great name for what pull-and-merge really is. Pull\nreally is pull - it _pulls_ the data, while update also updates the\ngiven tree. No surprises.\n\n(We should obviously have also update-without-pull but that is probably\nnot going to be so common so a parameter for update (like -n) should be\nfine for that.)\n\nThese naming issues may appear silly but I think they matter big time\nfor usability, intuitiveness, and learning curve (I don't want git-pasky\nbecome another GNU arch).\n\nKind regards,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"822","messageId":"2cfc4032050419065472ef3db0@mail.gmail.com","threadId":"43","inReplyTo":"20050419105008.GB12757@pasky.ji.cz","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-04-19T13:54:43Z","receivedAt":"2005-04-19T13:54:43Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"> I disagree. This already forces you to have two branches (one to pull\n> from to get the data, mirroring the remote branch, one for your real\n> work) uselessly and needlessly.\n> \n> ...\n> These naming issues may appear silly but I think they matter big time\n> for usability, intuitiveness, and learning curve (I don't want git-pasky\n> become another GNU arch).\n> \n\n\nNot that it is worth that much, but my $0.02 is that Petr is right on\nthis one. I want something that allows me to get the objects into my\nlocal repository without funking with my working directory.\n\nAs a long time CVS user, \"git update\" would do what I expect it to. I\ndon't have any pre-conceptions about what \"pull\" does, so it doesn't\nphase me if pull is used for this purpose. However, perhaps pull means\nsomething in some other SCM that would cause confusion for others?\n\nSome alternatives to \"pull\" are offered: hoard, gather, make-local, download.\n\nRegards,\n\njon.\n-- \nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"},{"id":"826","messageId":"1113921659.1262.8.camel@nosferatu.lan","threadId":"43","inReplyTo":"20050419105008.GB12757@pasky.ji.cz","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"Martin Schlemmer","fromEmail":"azarah@nosferatu.za.org","sentAt":"2005-04-19T14:40:59Z","receivedAt":"2005-04-19T14:40:59Z","isPatch":false,"sender":{"key":"azarah@nosferatu.za.org","avatar":null},"body":"On Tue, 2005-04-19 at 12:50 +0200, Petr Baudis wrote:\n> Dear diary, on Tue, Apr 19, 2005 at 12:05:10PM CEST, I got a letter\n> where Martin Schlemmer told me that...\n> > On Tue, 2005-04-19 at 11:28 +0200, Petr Baudis wrote:\n> > > Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got a letter\n> > > where David Greaves told me that...\n> > >\n> > > Dunno. I do it personally all the time, with git at least.\n> > > \n> > > What do others think? :-)\n> > > \n> > \n> > I think pull is pull. If you are doing lots of local stuff and do not\n> > want it overwritten, it should have been in a forked branch.\n> \n> I disagree. This already forces you to have two branches (one to pull\n> from to get the data, mirroring the remote branch, one for your real\n> work) uselessly and needlessly.\n> \n> I think there is just no good name for what pull is doing now, and\n> update seems like a great name for what pull-and-merge really is. Pull\n> really is pull - it _pulls_ the data, while update also updates the\n> given tree. No surprises.\n> \n> (We should obviously have also update-without-pull but that is probably\n> not going to be so common so a parameter for update (like -n) should be\n> fine for that.)\n> \n> These naming issues may appear silly but I think they matter big time\n> for usability, intuitiveness, and learning curve (I don't want git-pasky\n> become another GNU arch).\n> \n\nOk, so 'pull' do the bk thing, and 'update' do the cvs thing. I think\nhowever you should do either do one or the other. Maybe drop the\n'update', and rather add 'checkout' (or 'co' for short) which will\nupdate the tree (or merge with local changes if needed). Then you have\ntwo distinct separate things (ok, so pretty much how bk do things).\n\nThis will also enable you to make 'fork', 'export', etc just do the\nright thing with the database, but leave 'checkout' up to the user if he\nwants to do so.\n\n\n-- \nMartin Schlemmer\n\n"},{"id":"850","messageId":"Pine.LNX.4.21.0504191245160.30848-100000@iabervon.org","threadId":"43","inReplyTo":"20050419105008.GB12757@pasky.ji.cz","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-19T18:28:00Z","receivedAt":"2005-04-19T18:28:00Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 19 Apr 2005, Petr Baudis wrote:\n\n> I disagree. This already forces you to have two branches (one to pull\n> from to get the data, mirroring the remote branch, one for your real\n> work) uselessly and needlessly.\n\nIf you pull in a non-tracked tree, it certainly won't apply the\nchanges, so you can just have your local tree and pull other people's\ntrees as desired.\n\n> I think there is just no good name for what pull is doing now, and\n> update seems like a great name for what pull-and-merge really is. Pull\n> really is pull - it _pulls_ the data, while update also updates the\n> given tree. No surprises.\n\nI'm actually getting suspicious that the right thing is to hide \"pull\" in\nthe id scheme. That is, instead of saying \"linus\" to refer to the\n\"linus\" head that you currently have, you say \"+linus\" to refer to the\nhead Linus has on his server currently, and this will cause you to\ndownload anything necessary to perform the operation with the resulting\nvalue.\n\nSee, I don't think you ever want to just pull. You want to\npull-and-do-something, but the something could be any operation that uses\na commit, not necessarily update. So you could do \"git diff -r +linus\" to\ncompare your head against current linus. You'd want \"git update\" to take a\nworking directory from \"linus\" to \"+linus\" (just because you know Linus's\nmore recent head doesn't mean you're automatically using it). You could\njust \"git merge +linus\" in your working directory to sync with Linus. Even\n\"git log +linus\" to see his recent changes.\n\nI think the only reason not to just make any reference to a head pull it\nis performance on looking up the head; you don't really want to hammer the\nserver getting these 40-byte files constantly or wait for a connection\nevery time (not to mention the possibility of not being able to\nconnect). But there's no reason to want to not have the latest data, since\nthe older data doesn't go away.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"882","messageId":"42658888.60007@dwheeler.com","threadId":"43","inReplyTo":"Pine.LNX.4.21.0504191245160.30848-100000@iabervon.org","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-04-19T22:39:04Z","receivedAt":"2005-04-19T22:39:04Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"Daniel Barkalow wrote:\n >See, I don't think you ever want to just pull. You want to\n >pull-and-do-something, but the something could be any operation...\n\nIn a _logical_ sense that's true; I'd only want to pull data if I intended\nto (possibly) do something with it. But as a _practical_ matter,\nI can see lots of reasons for doing a pull as a separate operation.\nOne is disconnected operation; I may want to pull the data now, to\nprepare for disconnectino, and then work later while disconnected.\nAnother is using lots of data compared to the pipesize; if I have a\ndial-in modem, or I want the history of the linux kernel since 0.0.1,\nI might want to \"pull\" & go away/go to sleep for the night. I might\nuse cron/at to automatically \"pull\" at 3am from some interesting branches.\nThe next day, I could then \"pull\" again to update just what changed,\nand/or do the operation I intended to do if the operation auto-pulls the\nmissing data.\n\n>I'm actually getting suspicious that the right thing is to hide \"pull\" in the id scheme. That is, instead of saying \"linus\" to refer to the\n>\"linus\" head that you currently have, you say \"+linus\" to refer to the\n>head Linus has on his server currently, and this will cause you to\n>download anything necessary to perform the operation with the resulting value.\n> \n>\nThat's an interesting idea. I'll have to think about that.\n\nWhat command would you suggest for the common case\nof \"update with current track?\" I've proposed \"git update [NAME]\".\n\"git merge\" with update-from-current-track as default seems unclear, and\nI worry that I might accidentally press RETURN too soon & merge with\nthe wrong thing. And I like the idea of \"git update\" doing the same thing\n(essentially) as \"cvs update\" and \"svn update\"; LOTS of people \"know\"\nwhat update does, so using the same command name for one of the most\ncommon operations smooths transition (GNU Arch's \"tla update\"\nis almost, though not exactly, the same too.)\n\nI still think it's important to have a very simple command that updates\nyour current branch with a tracked branch (because it's common to stay\nin sync with a master branch), and a way to just download the data without\ndoing things with it YET (because you want to do things in stages).\nThe commands \"update\" and \"pull\" come to mind when thinking that way,\nthough as long as the commands are simple & clear that's a good thing\n(I think it's a GOOD idea to use the same commands as CVS and\nSubversion when the results are essentially the same, just because so many\npeople are already familiar with them, but only where it makes sense.)\n\n--- David A. Wheeler\n\n"},{"id":"907","messageId":"Pine.LNX.4.21.0504191908290.30848-100000@iabervon.org","threadId":"43","inReplyTo":"42658888.60007@dwheeler.com","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-19T23:20:40Z","receivedAt":"2005-04-19T23:20:40Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 19 Apr 2005, David A. Wheeler wrote:\n\n> In a _logical_ sense that's true; I'd only want to pull data if I intended\n> to (possibly) do something with it. But as a _practical_ matter,\n> I can see lots of reasons for doing a pull as a separate operation.\n> One is disconnected operation; (...)\n\nThat's true. I think I actually like \"git pull\" as the operation for \"make\nsure I have everything I need, so I can lose net\".\n\n> What command would you suggest for the common case\n> of \"update with current track?\" I've proposed \"git update [NAME]\".\n> \"git merge\" with update-from-current-track as default seems unclear, and\n> I worry that I might accidentally press RETURN too soon & merge with\n> the wrong thing. And I like the idea of \"git update\" doing the same thing\n> (essentially) as \"cvs update\" and \"svn update\"; LOTS of people \"know\"\n> what update does, so using the same command name for one of the most\n> common operations smooths transition (GNU Arch's \"tla update\"\n> is almost, though not exactly, the same too.)\n\nI think that having \"git update\" update a tracked branch is best, if only as\nan aid to discoverability. And \"git merge\" should require you to say what\nyou want to merge with, because it's too easy to pick a wrong default, and\nthe user had better know.\n\nIt seems to me like this makes \"update\" identical to \"merge \", so\n\"update [NAME]\" and \"merge\" don't make sense, since they'd do the other\ncommand, but less intuitively.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"948","messageId":"20050420070157.GA12584@elte.hu","threadId":"43","inReplyTo":"20050419105008.GB12757@pasky.ji.cz","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2005-04-20T07:01:57Z","receivedAt":"2005-04-20T07:01:57Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Petr Baudis wrote:\n\n> > I think pull is pull. If you are doing lots of local stuff and do not\n> > want it overwritten, it should have been in a forked branch.\n> \n> I disagree. This already forces you to have two branches (one to pull \n> from to get the data, mirroring the remote branch, one for your real \n> work) uselessly and needlessly.\n> \n> I think there is just no good name for what pull is doing now, and \n> update seems like a great name for what pull-and-merge really is. Pull \n> really is pull - it _pulls_ the data, while update also updates the \n> given tree. No surprises.\n\nyeah. In fact most of the times i did 'git pull pasky' in the past, the \n'merge' phase was unsuccessful, and i had to nuke the tree and recreate \nit. All i did with the snapshots was to build them, so there were no \nlocal changes. Waiting a couple of days with doing a 'git pull pasky', \nor installing Linus' tree is a sure way to break the merging.\n\ne.g. to reproduce the last such failure i had today, do:\n\n cd git-pasky-base\n echo 8568e1a88c086d1b72b0e84ab24fa6888b5861b9 > .git/HEAD\n read-tree $(tree-id $(cat .git/HEAD))\n checkout-cache -a -f\n make\n make install # make sure to use the older tools\n rm -rf .git/objects\n git pull pasky\n\nand i get:\n\n [...]\n fatal: unable to execute 'gitmerge-file.sh'\n fatal: merge program failed\n\n Conflicts during merge. Do git commit after resolving them.\n\nnote that with earlier versions of pasky, i had other merge conflicts. \nSometimes there were .rej files, sometimes some sort of script failure. \nSo it seems rather unrobust at the moment. Especially if i happen to \ninstall Linus' tree and try to sync the pasky tree with those tools.\n\nanother thing: it's confusing that during 'git pull', the rsync output \nis not visible. Especially during large rsyncs, it would be nice to see \nsome progress. So i usually use a raw rsync not 'git pull', due to this.\n\nyet another thing: what is the canonical 'pasky way' of simply nuking \nthe current files and checking out the latest tree (according to \n.git/HEAD). Right now i'm using a script to:\n\n read-tree $(tree-id $(cat .git/HEAD))\n checkout-cache -a\n\n(i first do an 'rm -f *' in the working directory)\n\ni guess there's an existing command for this already?\n\n\tIngo\n"},{"id":"1023","messageId":"20050420200504.GB19112@pasky.ji.cz","threadId":"43","inReplyTo":"20050420070157.GA12584@elte.hu","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-20T20:05:04Z","receivedAt":"2005-04-20T20:05:04Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter\nwhere Ingo Molnar told me that...\n> [...]\n> fatal: unable to execute 'gitmerge-file.sh'\n> fatal: merge program failed\n\nPure stupidity of mine, I forgot to add gitmerge-file.sh to the list of\nscripts which get installed.\n\n> another thing: it's confusing that during 'git pull', the rsync output \n> is not visible. Especially during large rsyncs, it would be nice to see \n> some progress. So i usually use a raw rsync not 'git pull', due to this.\n\nFixed. For further reference, you can also set RSYNC_FLAGS and put\nwhatever pleases you there.\n\n> yet another thing: what is the canonical 'pasky way' of simply nuking \n> the current files and checking out the latest tree (according to \n> .git/HEAD). Right now i'm using a script to:\n> \n> read-tree $(tree-id $(cat .git/HEAD))\n> checkout-cache -a\n> \n> (i first do an 'rm -f *' in the working directory)\n> \n> i guess there's an existing command for this already?\n\ngit cancel\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"1025","messageId":"20050420203235.GA13270@elte.hu","threadId":"43","inReplyTo":"20050420200504.GB19112@pasky.ji.cz","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2005-04-20T20:32:35Z","receivedAt":"2005-04-20T20:32:35Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Petr Baudis wrote:\n\n> > yet another thing: what is the canonical 'pasky way' of simply nuking \n> > the current files and checking out the latest tree (according to \n> > .git/HEAD). Right now i'm using a script to:\n> > \n> > read-tree $(tree-id $(cat .git/HEAD))\n> > checkout-cache -a\n> > \n> > (i first do an 'rm -f *' in the working directory)\n> > \n> > i guess there's an existing command for this already?\n> \n> git cancel\n\nhm, that's a pretty unintuitive name though. How about making it 'git \ncheckout' and providing a 'git checkout -f' option to force the \ncheckout? (or something like this)\n\n\tIngo\n"},{"id":"1026","messageId":"20050420204551.GA13944@elte.hu","threadId":"43","inReplyTo":"20050420200504.GB19112@pasky.ji.cz","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2005-04-20T20:45:51Z","receivedAt":"2005-04-20T20:45:51Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Petr Baudis wrote:\n\n> Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter\n> where Ingo Molnar told me that...\n> > [...]\n> > fatal: unable to execute 'gitmerge-file.sh'\n> > fatal: merge program failed\n> \n> Pure stupidity of mine, I forgot to add gitmerge-file.sh to the list of\n> scripts which get installed.\n\nanother thing is this annoying message:\n\n rsync: link_stat \"/linux/kernel/people/torvalds/git.git/tags\" (in pub) \n failed: No such file or directory (2)\n rsync error: some files could not be transferred (code 23) at \n main.c(812)\n client: nothing to do: perhaps you need to specify some filenames or \n the --recursive option?\n\nyou said before that it's \"harmless\", but it's annoying nevertheless as \none doesnt know for sure whether the pull went fine.\n\n\tIngo\n"},{"id":"1029","messageId":"20050420211505.GE19112@pasky.ji.cz","threadId":"43","inReplyTo":"20050420204551.GA13944@elte.hu","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-20T21:15:05Z","receivedAt":"2005-04-20T21:15:05Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Apr 20, 2005 at 10:32:35PM CEST, I got a letter\nwhere Ingo Molnar told me that...\n> \n> * Petr Baudis wrote:\n> \n> > > yet another thing: what is the canonical 'pasky way' of simply nuking \n> > > the current files and checking out the latest tree (according to \n> > > .git/HEAD). Right now i'm using a script to:\n> > > \n> > > read-tree $(tree-id $(cat .git/HEAD))\n> > > checkout-cache -a\n> > > \n> > > (i first do an 'rm -f *' in the working directory)\n> > > \n> > > i guess there's an existing command for this already?\n> > \n> > git cancel\n> \n> hm, that's a pretty unintuitive name though. How about making it 'git \n> checkout' and providing a 'git checkout -f' option to force the \n> checkout? (or something like this)\n\nSince it does not really checkout. Ok, it does, but that's only small\npart of it. It just cancels whatever local changes are you doing in the\ntree and bring it to consistent state. When you have a merge in progress\nand after you see the sheer number of conflicts you decide to get your\nhands off, you type just git cancel. Doing basically anything with your\ntree (not only local changes checkout would fix, but also various git\noperations, including git add/rm and git seek) can be easily fixed by\ngit cancel.\n\nDear diary, on Wed, Apr 20, 2005 at 10:45:51PM CEST, I got a letter\nwhere Ingo Molnar told me that...\n> \n> * Petr Baudis wrote:\n> \n> > Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter\n> > where Ingo Molnar told me that...\n> > > [...]\n> > > fatal: unable to execute 'gitmerge-file.sh'\n> > > fatal: merge program failed\n> > \n> > Pure stupidity of mine, I forgot to add gitmerge-file.sh to the list of\n> > scripts which get installed.\n> \n> another thing is this annoying message:\n> \n> rsync: link_stat \"/linux/kernel/people/torvalds/git.git/tags\" (in pub) \n> failed: No such file or directory (2)\n> rsync error: some files could not be transferred (code 23) at \n> main.c(812)\n> client: nothing to do: perhaps you need to specify some filenames or \n> the --recursive option?\n> \n> you said before that it's \"harmless\", but it's annoying nevertheless as \n> one doesnt know for sure whether the pull went fine.\n\nAlready fixed. (Well, \"fixed\"... sent to /dev/null. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"1063","messageId":"4266ECC2.6060202@cobite.com","threadId":"43","inReplyTo":"20050420211505.GE19112@pasky.ji.cz","subject":"Re: Change \"pull\" to _only_ download, and \"git update\"=pull+merge?","fromName":"David Mansfield","fromEmail":"david@cobite.com","sentAt":"2005-04-20T23:58:58Z","receivedAt":"2005-04-20T23:58:58Z","isPatch":false,"sender":{"key":"david@cobite.com","avatar":null},"body":"Petr Baudis wrote:\n> Dear diary, on Wed, Apr 20, 2005 at 10:32:35PM CEST, I got a letter\n> where Ingo Molnar told me that...\n> \n>>* Petr Baudis wrote:\n>>\n>>\n>>>>yet another thing: what is the canonical 'pasky way' of simply nuking \n>>>>the current files and checking out the latest tree (according to \n>>>>.git/HEAD). Right now i'm using a script to:\n>>>>\n>>>> read-tree $(tree-id $(cat .git/HEAD))\n>>>> checkout-cache -a\n>>>>\n>>>>(i first do an 'rm -f *' in the working directory)\n>>>>\n>>>>i guess there's an existing command for this already?\n>>>\n>>>git cancel\n>>\n>>hm, that's a pretty unintuitive name though. How about making it 'git \n>>checkout' and providing a 'git checkout -f' option to force the \n>>checkout? (or something like this)\n> \n> \n> Since it does not really checkout. Ok, it does, but that's only small\n> part of it. It just cancels whatever local changes are you doing in the\n> tree and bring it to consistent state. When you have a merge in progress\n> and after you see the sheer number of conflicts you decide to get your\n> hands off, you type just git cancel. Doing basically anything with your\n> tree (not only local changes checkout would fix, but also various git\n> operations, including git add/rm and git seek) can be easily fixed by\n> git cancel.\n\n\nHow about 'git revert'?\n\nMost editors and word processors use that idiom for revert to saved \ncopy, with the obvious parallel here.\n\nDavid\n"}]}