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 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: 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 your favorite editor (which you've already checked does the right
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
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 anything to ever modify those inodes (as opposed to some cases, where you want to modify inodes only in certain ways). For that matter, relatively
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
