Re: Re: Re: Add "clone" support to lntree
For the record, mostly... (this is how it already is in git-pasky-0.5) Dear diary, on Sun, Apr 17, 2005 at 02:07:36AM CEST, I got a letter where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > > Now, what about git branch and git update for switching between > > branches? I think this is the most controversial part; these are > > basically just shortcuts for not having to do git fork, and I wouldn't > > mind so much removing them, if you people really consider them too ugly > > a wart for the soft clean git skin. I admit that they both come from a > > hidden prejudice that git fork is going to be slow and eat a lot of > > disk. > > I think that this just confuses matters. I killed them both for good. > > The idea for git update for switching between branches is that > > especially when you have two rather similar branches and mostly do stuff > > on one of them, but sometimes you want to do something on the other one, > > you can do just quick git update, do stuff, and git update back, without > > any forking. > > I still think that fork should be quick enough, or you could leave the > extra tree around. I'm not against having such a command, but I think it > should be a separate command rather than a different use of update, since > it would be used by poeople working in different ways. I've removed git branch, removed the possibility for git update to switch branches and renamed git update to git seek. You can do git seek git-pasky-0.1 and examine stuff, but your tree is also blocked at the same time - git won't let you commit, merge and such. By doing git seek or git seek master you return back to your branch (assuming its name is master). I think git fork is after all good enough for branching and it is the clean way. Shall there be a big demand for it, it should be minimal hassle to implement 'git switch', which would do that. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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: Re: Re: Add "clone" support to lntree
On Sun, 17 Apr 2005, Petr Baudis wrote: > Dear diary, on Sat, Apr 16, 2005 at 05:17:00AM CEST, I got a letter > where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > > On Sat, 16 Apr 2005, Petr Baudis wrote: > > > > > Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter > > > where Petr Baudis <[EMAIL PROTECTED]> told me that... > > > > git branch --- creates a branch from a given commit > > > > (when passed empty commit, creates a branch > > > > from the current commit and sets the working > > > > tree to that branch) > > > > Note that there is a bug in current git update - it will allow you to > > > > bring several of your trees to follow the same branch, or even a remote > > > > branch. This is not even supposed to work, and will be fixed when I get > > > > some sleep. You will be able to do git pull even on local branches, and > > > > the proper solution for this will be just tracking the branch you want > > > > to follow. > > > > > > I must admit that I'm not entirely decided yet, so I'd love to hear your > > > opinion. > > > > > > I'm wondering, whether each tree should be fixed to a certain branch. > > > That is, you decide a name when you do git fork, and then the tree > > > always follows that branch. (It always has to follow [be bound to] > > > *some* branch, and each branch can be followed by only a single tree at > > > a time.) > > > > I don't think I'm following the use of branches. Currently, what I do is > > have a git-pasky and a git-linus, and fork off a working directory from > > one of these for each thing I want to work on. I do some work, commit as I > > make progress, and then do a diff against the remote head to get a patch > > to send off. If I want to do a series of patches which depend on each > > other, I fork my next directory off of my previous one rather than off of > > a remote base. I haven't done much rebasing, so I haven't worked out how I > > would do that most effectively. > > Yes. And that's exactly what the branches allow you to do. You just do > > git fork myhttpclient ~/myhttpclientdir > > then you do some hacking, and when you have something usable, you can > go back to your main working directory and do > > git merge -b when_you_started myhttpclient > > Since you consider the code perfect, you can now just rm -rf > ~/myhttpclient. > > Suddenly, you get a mail from mj pointing out some bugs, and it looks > like there are more to come. What to do? > > git fork myhttpclient ~/myhttpclientdir > > (Ok, this does not work, but that's a bug, will fix tomorrow.) This will > let you take off when you left in your work on the branch. Ah, I think that's what made me think I wasn't understanding branches; the first thing I tried hit this big. > git update for seeking between commits is probably extremely important > for any kind of binary search when you are wondering when did this bug > appeared first, or when you are exploring how certain branch evolved > over time. Doing git fork for each successive iteration sounds horrible. Even if there isn't a performance hit, it's semantically wrong, because you're looking at different versions that were in the same place at different times. > Now, what about git branch and git update for switching between > branches? I think this is the most controversial part; these are > basically just shortcuts for not having to do git fork, and I wouldn't > mind so much removing them, if you people really consider them too ugly > a wart for the soft clean git skin. I admit that they both come from a > hidden prejudice that git fork is going to be slow and eat a lot of > disk. I think that this just confuses matters. > The idea for git update for switching between branches is that > especially when you have two rather similar branches and mostly do stuff > on one of them, but sometimes you want to do something on the other one, > you can do just quick git update, do stuff, and git update back, without > any forking. I still think that fork should be quick enough, or you could leave the extra tree around. I'm not against having such a command, but I think it should be a separate command rather than a different use of update, since it would be used by poeople working in different ways. > > I think I can make this space efficient by hardlinking unmodified blobs to > > a directory of cached expanded blobs. > > I don't know but I really feel *very* unsafe when doing that. What if > something screws up and corrupts my base... way too easy. And it gets > pretty inconvenient and even more dangerous when you get the idea to do > some modifications on your tree by something else than your favorite > editor (which you've already checked does the right thing). It should only be an option, not required and maybe not even default. I think it should be possible to prevent stuff from screwing up, since we really don't want a
Re: Re: Re: Add "clone" support to lntree
Dear diary, on Sun, Apr 17, 2005 at 01:07:35AM CEST, I got a letter where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > > Actually, what about if git pull outside of repository did what git > > clone does now? I'd kinda like clone instead of fork too. > > This seems like the best solution to me, too. Although that would make > pull take a URL when making a new repository and not otherwise, which > might be confusing. "init-remote" perhaps, or maybe just have "init" do it > if given a URL? Yes, init taking URL optionally sounds ideal. Thanks. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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: Re: Re: Add "clone" support to lntree
Dear diary, on Sat, Apr 16, 2005 at 05:17:00AM CEST, I got a letter where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > On Sat, 16 Apr 2005, Petr Baudis wrote: > > > Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter > > where Petr Baudis <[EMAIL PROTECTED]> told me that... > > > git branch --- creates a branch from a given commit > > > (when passed empty commit, creates a branch > > > from the current commit and sets the working > > > tree to that branch) > > > Note that there is a bug in current git update - it will allow you to > > > bring several of your trees to follow the same branch, or even a remote > > > branch. This is not even supposed to work, and will be fixed when I get > > > some sleep. You will be able to do git pull even on local branches, and > > > the proper solution for this will be just tracking the branch you want > > > to follow. > > > > I must admit that I'm not entirely decided yet, so I'd love to hear your > > opinion. > > > > I'm wondering, whether each tree should be fixed to a certain branch. > > That is, you decide a name when you do git fork, and then the tree > > always follows that branch. (It always has to follow [be bound to] > > *some* branch, and each branch can be followed by only a single tree at > > a time.) > > I don't think I'm following the use of branches. Currently, what I do is > have a git-pasky and a git-linus, and fork off a working directory from > one of these for each thing I want to work on. I do some work, commit as I > make progress, and then do a diff against the remote head to get a patch > to send off. If I want to do a series of patches which depend on each > other, I fork my next directory off of my previous one rather than off of > a remote base. I haven't done much rebasing, so I haven't worked out how I > would do that most effectively. Yes. And that's exactly what the branches allow you to do. You just do git fork myhttpclient ~/myhttpclientdir then you do some hacking, and when you have something usable, you can go back to your main working directory and do git merge -b when_you_started myhttpclient Since you consider the code perfect, you can now just rm -rf ~/myhttpclient. Suddenly, you get a mail from mj pointing out some bugs, and it looks like there are more to come. What to do? git fork myhttpclient ~/myhttpclientdir (Ok, this does not work, but that's a bug, will fix tomorrow.) This will let you take off when you left in your work on the branch. git update for seeking between commits is probably extremely important for any kind of binary search when you are wondering when did this bug appeared first, or when you are exploring how certain branch evolved over time. Doing git fork for each successive iteration sounds horrible. Now, what about git branch and git update for switching between branches? I think this is the most controversial part; these are basically just shortcuts for not having to do git fork, and I wouldn't mind so much removing them, if you people really consider them too ugly a wart for the soft clean git skin. I admit that they both come from a hidden prejudice that git fork is going to be slow and eat a lot of disk. The idea for git branch is to mark a commit as "this is a branch but I don't want to git fork" (because I'm lazy or short on disk space or whatever). Let's say you are tracking a branch, do some local commits and then want to untrack. This will get you back to HEAD.local, but you want to keep a reference for your local commits, and possibly work on them more later - so you mark them as a branch. But thinking about it, I couldn't come up with another usage case than this, and I think that now that we have git fork, I will modify git track behaviour heavily so that tracking/untracking won't really switch you to the other branch completely, but really only tell git pull that you want the pulled updates applied. So git branch command will likely go. The idea for git update for switching between branches is that especially when you have two rather similar branches and mostly do stuff on one of them, but sometimes you want to do something on the other one, you can do just quick git update, do stuff, and git update back, without any forking. Note that this all is *absolutely* subject to change, provided you can convince me about some better way. ;-) My mindset on this is pretty open. This is just what seems to me as a pretty flexible and elegant to do stuff, while giving you enough freedom to pick your own style. > I think I can make this space efficient by hardlinking unmodified blobs to > a directory of cached expanded blobs. I don't know but I really feel *very* unsafe when doing that. What if something screws up and corrupts my base... way too easy. And it gets pretty inconvenient and even more dangerous when you get the idea to do some modifications on your tree by something else than
Re: Re: Add "clone" support to lntree
On Sun, 17 Apr 2005, Petr Baudis wrote: > Dear diary, on Sat, Apr 16, 2005 at 05:06:54AM CEST, I got a letter > where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > > > I think "fork" is as good as anything for describing the operation. I had > > thought about "clone" because it seemed to fill the role that "bk > > clone" had (although I never used BK, so I'm not sure). It doesn't seem > > useful to me to try cloning multiple remote repositories, since you'd get > > a copy of anything common from each; you just want to suck everything into > > the same .git/objects and split off working directories. > > Actually, what about if git pull outside of repository did what git > clone does now? I'd kinda like clone instead of fork too. This seems like the best solution to me, too. Although that would make pull take a URL when making a new repository and not otherwise, which might be confusing. "init-remote" perhaps, or maybe just have "init" do it if given a URL? -Daniel *This .sig left intentionally blank* - 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: Re: Add "clone" support to lntree
Dear diary, on Sat, Apr 16, 2005 at 05:06:54AM CEST, I got a letter where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > On Sat, 16 Apr 2005, Petr Baudis wrote: > > I'm sorry but you are late, I added it about a hour and half ago or so. > > :-) Check git fork. (I *want* separate command than git lntree. In fact, > > I think I should make git lntree gitXlntree.sh instead, since it is > > really internal command for git-tools and the user should probably never > > need it for anything. git lntree is too lowlevel.) > > Have you not pushed since? I don't see it. See my last mail. :-) > I think "fork" is as good as anything for describing the operation. I had > thought about "clone" because it seemed to fill the role that "bk > clone" had (although I never used BK, so I'm not sure). It doesn't seem > useful to me to try cloning multiple remote repositories, since you'd get > a copy of anything common from each; you just want to suck everything into > the same .git/objects and split off working directories. Actually, what about if git pull outside of repository did what git clone does now? I'd kinda like clone instead of fork too. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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: Re: Re: Add "clone" support to lntree
Dear diary, on Sat, Apr 16, 2005 at 05:16:12AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > On Sat, 16 Apr 2005, Petr Baudis wrote: > > > > I'm wondering, whether each tree should be fixed to a certain branch. > > I'm wondering why you talk about "branches" at all. > > No such thing should exist. There are no branches. There are just > repositories. You can track somebody elses repository, but you should > track it by location, not by any "branch name". > > And you track it by just merging it. > > Yeah, we don't have really usable merges yet, but.. First, this "level" of branches concerns multiple working directories tied to a single repository. It seems like a sensible thing to do; and you agreed with it too (IIRC). And when you do that, git-pasky just saves some work for you. For git-pasky, branch is really just a symbolic name for a commit ID, which gets updated every time you commit in some repository. Nothing more. So the whole point of this is to have a symbolic name for some other working directory. When you want to merge, you don't need to go over to the other directory, do commit-id, cut'n'paste, and feed that to git merge. You just do git merge myotherbranch Now, about remote repositories. When you pull a remote repository, that does not mean it has to be immediately merged somewhere. It is very useful to have another branch you do *not* want to merge, but you want to do diffs to it, or even check it out / export it later to some separate directory. Again, the "branch" is just a symbolic name for the head commit ID of what you pulled, and the pointer gets updated every time you pull again - that's the whole point of it. The last concept are "tracking" working directories. If you pull the tracked branch to this directory, it also automerges it. This is useful when you have a single canonical branch for this directory, which it should always mirror. That would be the case e.g. for the gazillions of Linux users who would like to just have the latest bleeding kernel of your, and they expect to use git just like a "different CVS". Basically, they will just do git pull instead of cvs update :-). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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: Re: Add "clone" support to lntree
On Sat, 16 Apr 2005, Petr Baudis wrote: > Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter > where Petr Baudis <[EMAIL PROTECTED]> told me that... > > git branch --- creates a branch from a given commit > > (when passed empty commit, creates a branch > > from the current commit and sets the working > > tree to that branch) > > Note that there is a bug in current git update - it will allow you to > > bring several of your trees to follow the same branch, or even a remote > > branch. This is not even supposed to work, and will be fixed when I get > > some sleep. You will be able to do git pull even on local branches, and > > the proper solution for this will be just tracking the branch you want > > to follow. > > I must admit that I'm not entirely decided yet, so I'd love to hear your > opinion. > > I'm wondering, whether each tree should be fixed to a certain branch. > That is, you decide a name when you do git fork, and then the tree > always follows that branch. (It always has to follow [be bound to] > *some* branch, and each branch can be followed by only a single tree at > a time.) I don't think I'm following the use of branches. Currently, what I do is have a git-pasky and a git-linus, and fork off a working directory from one of these for each thing I want to work on. I do some work, commit as I make progress, and then do a diff against the remote head to get a patch to send off. If I want to do a series of patches which depend on each other, I fork my next directory off of my previous one rather than off of a remote base. I haven't done much rebasing, so I haven't worked out how I would do that most effectively. I think I can make this space efficient by hardlinking unmodified blobs to a directory of cached expanded blobs. -Daniel *This .sig left intentionally blank* - 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: Re: Add "clone" support to lntree
On Sat, 16 Apr 2005, Petr Baudis wrote: > > I'm wondering, whether each tree should be fixed to a certain branch. I'm wondering why you talk about "branches" at all. No such thing should exist. There are no branches. There are just repositories. You can track somebody elses repository, but you should track it by location, not by any "branch name". And you track it by just merging it. Yeah, we don't have really usable merges yet, but.. Linus - 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: Add "clone" support to lntree
On Sat, 16 Apr 2005, Petr Baudis wrote: > Dear diary, on Sat, Apr 16, 2005 at 03:56:03AM CEST, I got a letter > where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > > I often want to take a base tree, which I keep tracking some remote head, > > and make a local working tree that starts from it. This makes "git ln -c > > " give you a tree that you can just start working in and then diff > > against the head you'd started from and send off. > > > > Signed-Off-By: Daniel Barkalow <[EMAIL PROTECTED]> > > I'm sorry but you are late, I added it about a hour and half ago or so. > :-) Check git fork. (I *want* separate command than git lntree. In fact, > I think I should make git lntree gitXlntree.sh instead, since it is > really internal command for git-tools and the user should probably never > need it for anything. git lntree is too lowlevel.) Have you not pushed since? I don't see it. I actually first made gitlntree.sh do the forking thing, because it didn't seem useful as is, until I noticed that merge was already using it internally. > Actually, I don't like the name at all, though. Some people may find > pondering about names pointless, but when I'm going to type them in > every day for the rest of my life, they better should not be stupid. ;-) > > So, what are your clever ideas about git fork's proper name? Or should > we leave it as is? I think "fork" is as good as anything for describing the operation. I had thought about "clone" because it seemed to fill the role that "bk clone" had (although I never used BK, so I'm not sure). It doesn't seem useful to me to try cloning multiple remote repositories, since you'd get a copy of anything common from each; you just want to suck everything into the same .git/objects and split off working directories. -Daniel *This .sig left intentionally blank* - 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: Re: Add "clone" support to lntree
Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter where Petr Baudis <[EMAIL PROTECTED]> told me that... > git branch --- creates a branch from a given commit > (when passed empty commit, creates a branch > from the current commit and sets the working > tree to that branch) > Note that there is a bug in current git update - it will allow you to > bring several of your trees to follow the same branch, or even a remote > branch. This is not even supposed to work, and will be fixed when I get > some sleep. You will be able to do git pull even on local branches, and > the proper solution for this will be just tracking the branch you want > to follow. I must admit that I'm not entirely decided yet, so I'd love to hear your opinion. I'm wondering, whether each tree should be fixed to a certain branch. That is, you decide a name when you do git fork, and then the tree always follows that branch. (It always has to follow [be bound to] *some* branch, and each branch can be followed by only a single tree at a time.) Currently, you can at anytime "mark" a new branch (by git branch) and you can freely "rebranch" your tree (by git update). An alternative approach would be to disallow git update to "rebranch" and remove the git branch command (you'd always do git fork). From what I know, the alternative approach is nearer to what BK takes, and it would be _slightly_ simpler (maybe). OTOH the current approach is I believe more powerful, and could require less resources. WWhat do you think, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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: Add "clone" support to lntree
Dear diary, on Sat, Apr 16, 2005 at 03:56:03AM CEST, I got a letter where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > I often want to take a base tree, which I keep tracking some remote head, > and make a local working tree that starts from it. This makes "git ln -c > " give you a tree that you can just start working in and then diff > against the head you'd started from and send off. > > Signed-Off-By: Daniel Barkalow <[EMAIL PROTECTED]> I'm sorry but you are late, I added it about a hour and half ago or so. :-) Check git fork. (I *want* separate command than git lntree. In fact, I think I should make git lntree gitXlntree.sh instead, since it is really internal command for git-tools and the user should probably never need it for anything. git lntree is too lowlevel.) Actually, I don't like the name at all, though. Some people may find pondering about names pointless, but when I'm going to type them in every day for the rest of my life, they better should not be stupid. ;-) So, what are your clever ideas about git fork's proper name? Or should we leave it as is? Summary of current related git commands (yes, they are already around and should be actually all working): git addremote --- registers a remote branch (name - URL pair) git branch --- creates a branch from a given commit (when passed empty commit, creates a branch from the current commit and sets the working tree to that branch) git clone --- creates a local GIT repository from a remote one git export --- checks out given commit to a separate directory (without any GIT information) git fork --- creates a new branch and working tree from the current working tree, sharing the same local GIT repository git lntree --- creates a "treeshell" sharing the same GIT repository with the current tree If you think any other of those should be renamed, this is the time to speak up. Oh well, I think I'll regret asking about this at all... ;-) Note that there is a bug in current git update - it will allow you to bring several of your trees to follow the same branch, or even a remote branch. This is not even supposed to work, and will be fixed when I get some sleep. You will be able to do git pull even on local branches, and the proper solution for this will be just tracking the branch you want to follow. So, I'll fix that tomorrow, enable you to fork to an existing but unused branch, fix git pull of remote branch by several local branches, and write a lot of documentation. Kind regards, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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
