* Newbie grief @ 2012-04-30 22:30 Rich Pixley 2012-04-30 23:31 ` Seth Robertson ` (2 more replies) 0 siblings, 3 replies; 100+ messages in thread From: Rich Pixley @ 2012-04-30 22:30 UTC (permalink / raw) To: git Hey. I'm a newbie struggling to understand git. I'm trying to do what seems like a simple thing in darcs, monotone, mecurial, gnu arch, etc, but seems nearly impossible in git. There's a central repository, a long ways away on the other side of the internet. So I want a local repository cache. I'm going to be working on a number of different features and different machines all simultaneously so I really don't want them all to be pulling from the central repository. In other systems, this is a simple star network. Clone a repository, use, push, pull, etc. But with git, I can't push unless the cache repository is bare, but if the cache repository is bare, then a change to the central repository will cause the two to become wedged since neither can push or fetch the other. It seems that git is allergic to the dual head branch solution or something, which is surprising and disappointing. How do other people address these situations in git? --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-04-30 22:30 Newbie grief Rich Pixley @ 2012-04-30 23:31 ` Seth Robertson 2012-05-01 1:15 ` Rich Pixley [not found] ` <4F9F28F5.2020403@palm.com> 2012-04-30 23:35 ` Jan Krüger 2012-05-02 8:25 ` Philippe Vaucher 2 siblings, 2 replies; 100+ messages in thread From: Seth Robertson @ 2012-04-30 23:31 UTC (permalink / raw) To: Rich Pixley; +Cc: git In message <4F9F128C.5020304@palm.com>, Rich Pixley writes: Hey. I'm a newbie struggling to understand git. I'm trying to do what seems like a simple thing in darcs, monotone, mecurial, gnu arch, etc, but seems nearly impossible in git. There's a central repository, a long ways away on the other side of the internet. So I want a local repository cache. I'm going to be working on a number of different features and different machines all simultaneously so I really don't want them all to be pulling from the central repository. Are you working with anyone else locally? If not, then what you are probably really trying to do is save time on fetches, so that the latest changes are more likely to be nearby than far away. What I would do is set up a bare backup/--mirror repository of the upstream locally and have it automatically kept up to date with cron or something like that. Then you can have your pull URL point to this mirror and the push URL point to the real upstream. This will work as long as the real upstream and the local mirror are not out of date (if they are, you will be forbidden to push without either pulling from the real upstream or wait for the next cron fetch and pull from your local mirror). This works, but requires that you separate your fetch and push URLs. Another option is to use git "alternates" to have your local repository also look at the automatically updated repository so that you would only fetch over-the-network-changes since the last automatic fetch (which, unless you had the cache have an alternate for the primary repository, would mean that the changes would be transferred twice). Alternates can be problematic if you start moving repositories around or delete them or whatever since the repository with the dangling alternate will then be bad (until the objects reappear one way or another), so perhaps you just want a cron job to `git fetch` or `git remote update -p` in your local repository every so often. Then you can just `git merge` or `git rebase` to get the latest changes instead of `git pull [--rebase]`. This is really the simplest solution. No extra repositories, no configuration changes, just straightforward git operations. The only trick would be race conditions between you (as a human) reviewing the latest changes and then typing the command to merge/rebase them into your local branch and the cron job updating the remoteâseeing what happened afterwords would of course work. I would probably try this first and only start using the others if this became problematic for some reason. None of these cases specifically handles trying to automate pushes, mostly because it cannot always be automatically resolved (and depending on local standards on running test suites before any change is pushed, perhaps should not ever be automatically resolved even for trivial conflicts) if changes appear on the real upstream between your last pull and your next push. Could it be done? Sure. You can push to your local upstream and then have it push out automatically, but if there are conflicts you will need to deal with them, and I would suggest doing so with a bare repository, essentially by having a static preference for the real-upstream's changes and have the cron job send mail to you telling you to re-pull and re-push if it failed to push out due to the remote having changed (telling you the ref/SHA1 that it failed to push). Of course, this isn't *that* different from just sticking a `git push` into the background which sends mail/notifies if the push failed for some reason, and again doing so would be much easier than an intermediary repository solution. But with git, I can't push unless the cache repository is bare, but if the cache repository is bare, then a change to the central repository will cause the two to become wedged since neither can push or fetch the other. Not strictly speaking true. By default git will forbid pushes to non-bare repositories (see receive.denyCurrentBranch in man git-config) since without special automation the working directory will get out of date. See http://bare-vs-nonbare.gitrecipes.de/ for more information. However, I cannot think that having to perform integration in this second repository would actually work. It seems that git is allergic to the dual head branch solution or something, which is surprising and disappointing. Git tracks your version of master separately from each other remote's master. This is exactly dual/multiple heads. What git *does* forbid (by default) is: 1: Letting you update someone else's checked out (non-bare) repository underneath them 2: Letting you update someone else's repository if they have more recent changes than you do. Both of these defaults are really good ideas, but you can disable them if you think you know better. -Seth Robertson ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-04-30 23:31 ` Seth Robertson @ 2012-05-01 1:15 ` Rich Pixley 2012-05-01 1:32 ` Junio C Hamano 2012-05-01 3:44 ` Sitaram Chamarty [not found] ` <4F9F28F5.2020403@palm.com> 1 sibling, 2 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-01 1:15 UTC (permalink / raw) To: Seth Robertson; +Cc: git Thank you for the info and the help. Just one argument... On 4/30/12 16:31 , Seth Robertson wrote: > It seems that git is allergic to the dual head branch solution or > something, which is surprising and disappointing. > > Git tracks your version of master separately from each other remote's > master. This is exactly dual/multiple heads. No, it isn't at all. Multiple heads are the idea that a single commit can "branch" in the repository and that both commits can be HEADS of the same branch at once in a single repository. This allows a potential collision to exist in the repository and to be pushed and pulled through multiple repositories. It also largely eliminates this entire discussion since each of the intermediate repositories between, say, you and I can carry the collision. Either you or I, at will, can merge these heads just like we'd merge any other two commits, push/fetch, etc. That would seem to be the obvious and intuitive behavior, rather than arbitrarily preventing the transfer. > What git *does* forbid > (by default) is: > > 1: Letting you update someone else's checked out (non-bare) repository > underneath them Yeah. That "underneath them" thing is confusing. I don't see any reason why that should necessarily be so. Git knows what commit is checked out. That's HEAD, yes? So what's wrong with letting it collect other commits from other repositories while your working directory sits? You can always commit your change right on top of what's checked out, creating a second head for that branch. Yes, I've read that git-diff, etc, are all making assumptions that fail in this case, but there's nothing significantly different about collecting commits to other branches and collecting commits to the branch you're currently checked out from. Either way, you're going to need to merge those into your working directory before committing your current changes will make much semantic sense. And if you don't want to do that, you can always commit them directly onto HEAD, and thereby create a new branch, at least temporarily. That's one of the huge advantages of the daggy architecture. > 2: Letting you update someone else's repository if they have more > recent changes than you do. Again, if they have more recent changes, then my line of changes should create a fresh HEAD on that branch. Then the repositories hold all of our changes to be merged at our leisure. From a UI perspective, that request has a valid, and relatively obvious semantic. That git simply refuses to do anything except produce a cryptic error message seems... well, sad. > Both of these defaults are really good ideas, but you can disable them > if you think you know better. I know better for source code control systems that support the multiple HEAD concept. I don't know better for git. So far, it looks to me as though git is just plain failing here. I thank you for your suggestions. It'll take me a few readings before I follow them all. Regardless of how I think git _should_ behave, I'll still need to figure something, so thank you. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 1:15 ` Rich Pixley @ 2012-05-01 1:32 ` Junio C Hamano 2012-05-01 1:55 ` Rich Pixley 2012-05-01 3:44 ` Sitaram Chamarty 1 sibling, 1 reply; 100+ messages in thread From: Junio C Hamano @ 2012-05-01 1:32 UTC (permalink / raw) To: Rich Pixley; +Cc: Seth Robertson, git Rich Pixley <rich.pixley@palm.com> writes: >> Git tracks your version of master separately from each other remote's >> master. This is exactly dual/multiple heads. > > No, it isn't at all. > > Multiple heads are the idea that a single commit can "branch" in the > repository and that both commits can be HEADS of the same branch at > once in a single repository. This allows a potential collision to > exist in the repository and to be pushed and pulled through multiple > repositories. I think your "not at all" thinking is a bit tainted by your knowing very well how Hg does things, but I do not think there is much fundamental difference between what we do. Git just tends to be a bit more explicit and encourages users to be also be more explicit. When you integrate from the other side (say, "origin") by pulling, instead of splitting the 'master' branch into two (i.e. ours and origin's), we store what came from the origin in remotes/origin/master and let the user merge it into his heads/master. Essentially, the same name 'master' is split into two, between remotes/origin/ and heads/ namespace. We are just more explicitly about the split. Similarly, when pushing, you could follow the same model by pushing your change into remotes/pixley/master, instead of pushing directly to the "master" branch, i.e. heads/master, and then merge the former to the latter after push succeeds. Needless to say, you do not have to limit the splitting just to two. Since everything is named, you can tell where each 'master' came from by looking at the namespace (obviously this requires people to establish and follow the naming convention). ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 1:32 ` Junio C Hamano @ 2012-05-01 1:55 ` Rich Pixley 0 siblings, 0 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-01 1:55 UTC (permalink / raw) To: Junio C Hamano; +Cc: Seth Robertson, git On 4/30/12 18:32 , Junio C Hamano wrote: > Rich Pixley<rich.pixley@palm.com> writes: > >>> Git tracks your version of master separately from each other remote's >>> master. This is exactly dual/multiple heads. >> >> No, it isn't at all. >> >> Multiple heads are the idea that a single commit can "branch" in the >> repository and that both commits can be HEADS of the same branch at >> once in a single repository. This allows a potential collision to >> exist in the repository and to be pushed and pulled through multiple >> repositories. > > I think your "not at all" thinking is a bit tainted by your knowing very > well how Hg does things, Actually, I came up with the same design back in the early 90's when I was working on CVS. I think the hg way of doing things is pretty obvious once we think about it. You can't expect users to do manual merges on a remote server. So the only thing you can reasonably do is collect and propagate the collision with enough info that a human being can put it back together later. Refusing the commit doesn't seem reasonable to me. The old approach from clearcase multisite where every repository owns it's own unique branch, which shows up as a read-only branch in the other repositories, is a nuisance because you have to constantly keep merging or your geographic partitions drift. It's difficult enough to keep disparate groups working in concert. Forcing them to do big merges in batch frequently doesn't help. That's essentially what we're reduced to with git. The illusion that we're all working on the same branch, (mercurial, monotone, etc), defaults to more frequent merges, and a much smaller change tree when it comes to visualization. > but I do not think there is much fundamental > difference between what we do. Git just tends to be a bit more explicit > and encourages users to be also be more explicit. > > When you integrate from the other side (say, "origin") by pulling, instead > of splitting the 'master' branch into two (i.e. ours and origin's), we > store what came from the origin in remotes/origin/master and let the user > merge it into his heads/master. Essentially, the same name 'master' is > split into two, between remotes/origin/ and heads/ namespace. We are just > more explicitly about the split. I wouldn't call it explicit. That level of detail provides no features. It's tedious extra work that could have been tracked and managed automatically. The fact that it isn't tracked and managed automatically prevents simple repository chaining of the sort I originally set out to accomplish. > Similarly, when pushing, you could follow the same model by pushing your > change into remotes/pixley/master, instead of pushing directly to the > "master" branch, i.e. heads/master, and then merge the former to the > latter after push succeeds. That presupposes that I own both repositories rather than working in a cooperative environment. > Needless to say, you do not have to limit the splitting just to two. > Since everything is named, you can tell where each 'master' came from by > looking at the namespace (obviously this requires people to establish and > follow the naming convention). Right. This is the sort of thing people write source code control systems to manage. :). --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 1:15 ` Rich Pixley 2012-05-01 1:32 ` Junio C Hamano @ 2012-05-01 3:44 ` Sitaram Chamarty 2012-05-01 11:14 ` Ted Ts'o [not found] ` <4FA01C73.5000909@palm.com> 1 sibling, 2 replies; 100+ messages in thread From: Sitaram Chamarty @ 2012-05-01 3:44 UTC (permalink / raw) To: Rich Pixley; +Cc: Seth Robertson, git I've been reading the thread with interest. People who know far more than I do about git, its innards, and its design have been responding in this thread so consider this a git *user*'s point of view: On Tue, May 1, 2012 at 6:45 AM, Rich Pixley <rich.pixley@palm.com> wrote: > Multiple heads are the idea that a single commit can "branch" in the > repository and that both commits can be HEADS of the same branch at once in > a single repository. This allows a potential collision to exist in the > repository and to be pushed and pulled through multiple repositories. It That is bizarre; I have no other word for it. I teach git (occasionally), and if this feature existed I would totally ignore it in my teaching material because I wouldn't know how to defend or explain the need for "hydra branches". It's like having two people with the same first name *and* last name (a situation that is not impossible in real life, but is rare and almost always requires special handling). Does Hg do this? That would explain why my (admittedly half-hearted) attempts to learn it have failed -- whatever tutorial I used must have been written with the idea that hydra branches are intuitive and logical and sane, but did not express the concept as clearly and succinctly as you did. Thanks for this insight; my next attempt to understand Hg, should I ever be forced into it, might actually succeed! ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 3:44 ` Sitaram Chamarty @ 2012-05-01 11:14 ` Ted Ts'o 2012-05-01 16:13 ` Sitaram Chamarty 2012-05-01 18:03 ` Rich Pixley [not found] ` <4FA01C73.5000909@palm.com> 1 sibling, 2 replies; 100+ messages in thread From: Ted Ts'o @ 2012-05-01 11:14 UTC (permalink / raw) To: Sitaram Chamarty; +Cc: Rich Pixley, Seth Robertson, git On Tue, May 01, 2012 at 09:14:24AM +0530, Sitaram Chamarty wrote: > > > Multiple heads are the idea that a single commit can "branch" in the > > repository and that both commits can be HEADS of the same branch at once in > > a single repository. This allows a potential collision to exist in the > > repository and to be pushed and pulled through multiple repositories. It > > That is bizarre; I have no other word for it. > > I teach git (occasionally), and if this feature existed I would > totally ignore it in my teaching material because I wouldn't know how > to defend or explain the need for "hydra branches". I wouldn't use the verb branch (and certainly not "hydra branch"), because it's confusing to someone who thinks this has something to do with noun "branch". But that's a confusion because of the english, or rather the terminology that was used. I would put it this way. Every non-merge commit has a parent (we'll ignore merge commits for now). When you look at that commit via "git show <commit-id>", what you see is the diff between its parent and the state of the source tree as described by that commit-id. If you put it this way, it becomes obvious that a particular parent commit can have multiple child commits. (This seems to be what you are calling "hydra branches".) A branch is a pointer to a commit. When you add a commit to a branch, you are adding a new commit whose parent is pointing to the current branch head, and afterwards, the branch head pointer is changed to point at the new commit. > Does Hg do this? That would explain why my (admittedly half-hearted) > attempts to learn it have failed -- whatever tutorial I used must have > been written with the idea that hydra branches are intuitive and > logical and sane, but did not express the concept as clearly and > succinctly as you did. What Hg does is it requires that all terminal commits (commits that do not have children) must be named by a branch pointer. So when you pull in some changes from Hg, there may be a non-terminal commit, but before the hg pull finishes, it will create a merge commit which merges the current branch pointer and the newly pulled in commits, so that when you are done, the branch pointer points at the new merge commit, and the requirement that there be no non-named terminal commits is maintained. Git differs in that you can have a child commit which is not pointed to by a branch pointer, and which is referred to only by commit-id. These child commits can disappear on you, when you do a garbage collection; but it allows you to have multiple child commits hanging off of a single parent commit, and you can do diffs, cherry picks, etc. But they *do* have a unique name --- the commit id, which is a SHA1 hash of the contents of the diff. Does this help? - Ted ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 11:14 ` Ted Ts'o @ 2012-05-01 16:13 ` Sitaram Chamarty 2012-05-01 18:15 ` Rich Pixley 2012-05-01 18:03 ` Rich Pixley 1 sibling, 1 reply; 100+ messages in thread From: Sitaram Chamarty @ 2012-05-01 16:13 UTC (permalink / raw) To: Ted Ts'o; +Cc: Rich Pixley, Seth Robertson, git On Tue, May 1, 2012 at 4:44 PM, Ted Ts'o <tytso@mit.edu> wrote: > On Tue, May 01, 2012 at 09:14:24AM +0530, Sitaram Chamarty wrote: >> >> > Multiple heads are the idea that a single commit can "branch" in the >> > repository and that both commits can be HEADS of the same branch at once in >> > a single repository. This allows a potential collision to exist in the >> > repository and to be pushed and pulled through multiple repositories. It >> >> That is bizarre; I have no other word for it. >> >> I teach git (occasionally), and if this feature existed I would >> totally ignore it in my teaching material because I wouldn't know how >> to defend or explain the need for "hydra branches". > > I wouldn't use the verb branch (and certainly not "hydra branch"), I coined that phrase for what was described as "[multiple] HEADS of the same branch at once in a single repository". > it this way, it becomes obvious that a particular parent commit can > have multiple child commits. (This seems to be what you are calling > "hydra branches".) No. In git, the multiple child commits you mention are all either different branches, tags, or they are detached/subject to GC. At no time do you actually have the situation he was talking about: a single branch representing more than one leaf (no children) commit *at the same time*. > Git differs in that you can have a child commit which is not pointed > to by a branch pointer, and which is referred to only by commit-id. > These child commits can disappear on you, when you do a garbage > collection; but it allows you to have multiple child commits hanging > off of a single parent commit, and you can do diffs, cherry picks, > etc. But they *do* have a unique name --- the commit id, which is a > SHA1 hash of the contents of the diff. Sure. What the original poster wants is that all these unnamed commits be magically associated with the branch they were born in, and be propagated via pushes and pulls. As I understand it, he would like a one -> many relationship between branch name and SHA. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 16:13 ` Sitaram Chamarty @ 2012-05-01 18:15 ` Rich Pixley 2012-05-01 18:20 ` Michael Witten 2012-05-01 18:42 ` Randal L. Schwartz 0 siblings, 2 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-01 18:15 UTC (permalink / raw) To: Sitaram Chamarty; +Cc: Ted Ts'o, Seth Robertson, git On 5/1/12 09:13 , Sitaram Chamarty wrote: > On Tue, May 1, 2012 at 4:44 PM, Ted Ts'o<tytso@mit.edu> wrote: >> I wouldn't use the verb branch (and certainly not "hydra branch"), > I coined that phrase for what was described as "[multiple] HEADS of > the same branch at once in a single repository". ...keeping in mind here that HEAD is a misnomer as HEAD points to the currently checked out commit, regardless of where that commit might live in the commit graph. It might be childless, but it might have children. What I'm talking about is the situation where a branch can have multiple, childless commits. I've switched to calling these "tips" for this discussion. > Sure. What the original poster wants is that all these unnamed commits > be magically associated with the branch they were born in, and be > propagated via pushes and pulls. As I understand it, he would like a > one -> many relationship between branch name and SHA. Really, what I want is for the push semantic to have a meaning. I want push to work. I want pull to work even without merging. I want to be able to share a branch between different repositories and different users while the source code control system tracks this for me. And I want to create arbitrary network graphs of repositories who all share code via push/pull without manual intervention. These are facilities that we've had in other source code control systems for at least a decade. It seems as though git is tracking all of the info that is needed - excepting multiple tips. The fact that there are converters, including dynamic, real time converters, between git repositories and the hg user interface suggest that there is, indeed, a near one-to-one mapping between mercurial and git. The only thing that's missing in git is the user interface to provide this semantic. Instead, git simply doesn't do what it is asked to do, which seems like a silly user interface choice. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 18:15 ` Rich Pixley @ 2012-05-01 18:20 ` Michael Witten 2012-05-01 18:52 ` Rich Pixley 2012-05-01 18:42 ` Randal L. Schwartz 1 sibling, 1 reply; 100+ messages in thread From: Michael Witten @ 2012-05-01 18:20 UTC (permalink / raw) To: Rich Pixley; +Cc: Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Tue, May 1, 2012 at 18:15, Rich Pixley <rich.pixley@palm.com> wrote: > I want pull to work even without merging. I want to be able to share a > branch between different repositories and different users while the source > code control system tracks this for me I believe you are missing the point that a `pull' in git is a `fetch' followed by a `merge'. You should read about the `fetch' command by reading (`git help fetch'), and make sure you understand how to use refspecs; you will probably find it very instructive to play around by specifying explicit refspecs to `git fetch' rather than relying on the implicit rules (which can be somewhat confusing). ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 18:20 ` Michael Witten @ 2012-05-01 18:52 ` Rich Pixley 2012-05-02 21:28 ` Jakub Narebski 0 siblings, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-01 18:52 UTC (permalink / raw) To: Michael Witten; +Cc: Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/1/12 11:20 , Michael Witten wrote: > On Tue, May 1, 2012 at 18:15, Rich Pixley<rich.pixley@palm.com> wrote: > >> I want pull to work even without merging. I want to be able to share a >> branch between different repositories and different users while the source >> code control system tracks this for me > > I believe you are missing the point that a `pull' in git is a `fetch' > followed by a `merge'. You should read about the `fetch' command by > reading (`git help fetch'), and make sure you understand how to use > refspecs; you will probably find it very instructive to play around > by specifying explicit refspecs to `git fetch' rather than relying > on the implicit rules (which can be somewhat confusing). Yes, I'm aware of the distinction within git. Confusing is an understatement. It seems that in most cases git has no defaults nor implicit rules and when it does, they are frequently surprising or unfathomable. I suppose it's nice that they can be set explicitly, but sad that they pretty much must be. That git uses the word "pull" to mean something different than previous source code control systems only adds to the confusion. I was using "pull" in the more general sense of pushing and pulling data, not in the very narrow meaning of "git fetch + git merge". I'm still pretty much lost on refspecs and refs. The terms are apparently not used in the manuals I've been reading and they don't seem to be used consistently even within git error messages. Is "refspec" the git word for the branch pointer that points to the childless commit that defines a branch? --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 18:52 ` Rich Pixley @ 2012-05-02 21:28 ` Jakub Narebski 0 siblings, 0 replies; 100+ messages in thread From: Jakub Narebski @ 2012-05-02 21:28 UTC (permalink / raw) To: Rich Pixley Cc: Michael Witten, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git Rich Pixley <rich.pixley@palm.com> writes: > On 5/1/12 11:20 , Michael Witten wrote: >> On Tue, May 1, 2012 at 18:15, Rich Pixley<rich.pixley@palm.com> wrote: >> >>> I want pull to work even without merging. I want to be able to share a >>> branch between different repositories and different users while the source >>> code control system tracks this for me >> >> I believe you are missing the point that a `pull' in git is a `fetch' >> followed by a `merge'. You should read about the `fetch' command by >> reading (`git help fetch'), and make sure you understand how to use >> refspecs; you will probably find it very instructive to play around >> by specifying explicit refspecs to `git fetch' rather than relying >> on the implicit rules (which can be somewhat confusing). [...] > That git uses the word "pull" to mean something different than > previous source code control systems only adds to the confusion. I > was using "pull" in the more general sense of pushing and pulling > data, not in the very narrow meaning of "git fetch + git merge". In using "pull" vs "fetch" Git follows the convention of BitKeeper (proprietary distributed version control system which was used for Linux kernel development 'till "BitKeeper fiasco", and which Git replaced). > I'm still pretty much lost on refspecs and refs. The terms are > apparently not used in the manuals I've been reading and they don't > seem to be used consistently even within git error messages. > > Is "refspec" the git word for the branch pointer that points to the > childless commit that defines a branch? "Ref" in Git is a named reference (pointer) to a commit in DAG of revisions, i.e. either [local] branch, tag, remote-tracking branch, etc. "Refspec" is a specification of mapping between ref name in remote repository and "tracking" ref in local repository, e.g. refs/heads/*:refs/remotes/origin/* refs/tags/*:refs/tags/* See any of git-pull(1), git-fetch(1) and git-push(1) manpages. -- Jakub Narebski ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 18:15 ` Rich Pixley 2012-05-01 18:20 ` Michael Witten @ 2012-05-01 18:42 ` Randal L. Schwartz 2012-05-01 20:52 ` Rich Pixley 1 sibling, 1 reply; 100+ messages in thread From: Randal L. Schwartz @ 2012-05-01 18:42 UTC (permalink / raw) To: Rich Pixley; +Cc: Sitaram Chamarty, Ted Ts'o, Seth Robertson, git >>>>> "Rich" == Rich Pixley <rich.pixley@palm.com> writes: Rich> What I'm talking about is the situation where a branch can have multiple, Rich> childless commits. I've switched to calling these "tips" for this Rich> discussion. But in git, a branch *is* what you're calling a "tip". What do you find lacking about git branches, in terms of sharing? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 18:42 ` Randal L. Schwartz @ 2012-05-01 20:52 ` Rich Pixley 2012-05-01 21:05 ` Randal L. Schwartz 0 siblings, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-01 20:52 UTC (permalink / raw) To: Randal L. Schwartz; +Cc: Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/1/12 11:42 , Randal L. Schwartz wrote: >>>>>> "Rich" == Rich Pixley<rich.pixley@palm.com> writes: > > Rich> What I'm talking about is the situation where a branch can have multiple, > Rich> childless commits. I've switched to calling these "tips" for this > Rich> discussion. > > But in git, a branch *is* what you're calling a "tip". And therein lies the problem. > What do you find lacking about git branches, in terms of sharing? A number of situations. But the short answer is that git completely lacks the ability to cope with potential collisions in the repository - even collisions that can be handled completely automatically, even when the collision can be handled completely in the repository graph, (as distinct from lexical or file content resolutions). I want to be able to fetch changes to the branch I currently have checked out. Git blocks this because it doesn't know how to cope with the working directory in that situation. Merging is straightforward. Even updating, (checkout), is fairly straightforward. But the insistence on a single tip means that if I commit directly to a non-tip commit, git doesn't know what to do with the branch pointer. If it leaves it at my commit, then the other changes are essentially orphaned. If it leaves it at the other changes, then my commit is essentially orphaned. While it's probably possible to force git to do this anyway, including orphaning one set of changes, doing so is of limited value since the git interface makes the assumption that branches have a single tip anyway. Pushing is blocked in git. Git simply refuses some push requests which have obvious and fairly straightforward semantics. There are ways in git to accomplish the more general task of information exchange by reversing the initiation request, (pulling), by partitioning the data into branches, etc. But the straightforward, intuitive request to push is, in git, frequently blocked for no particular reason. (Pushes are analogous to the previous situation of fetching to my current branch.) You and I want to share a branch and we each have local, unattended cache/mirror repositories that we would like to use to pass data between us. This doesn't work in git because the first time you and I make simultaneous changes, whether they collide or not, the unattended repositories become wedged. They each refuse to talk to the other until someone manually unwedges them. I want that if you and say, Sitaram commit conflicting changes to a shared branch, it's easy for me to recognize that the conflict exist and easy for me to resolve that conflict in my own repository. I want the source code control system to keep track of those things, show them to me/us, and to track and show my resolution to you. This stuff should all be automatic. It shouldn't require explicit testing, manual pulling, nor explicit discussion between the three of us. It shouldn't prohibit that either, but it shouldn't require it. These are all fairly common situations today. And it wouldn't be so bad if nothing else solved these problems either. But we've had source code control solutions that solved all of these issues for over a decade now. Going backwards to git seems like a pain in that context. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 20:52 ` Rich Pixley @ 2012-05-01 21:05 ` Randal L. Schwartz 2012-05-01 21:12 ` Junio C Hamano 2012-05-01 21:29 ` Rich Pixley 0 siblings, 2 replies; 100+ messages in thread From: Randal L. Schwartz @ 2012-05-01 21:05 UTC (permalink / raw) To: Rich Pixley; +Cc: Sitaram Chamarty, Ted Ts'o, Seth Robertson, git >>>>> "Rich" == Rich Pixley <rich.pixley@palm.com> writes: Rich> I want to be able to fetch changes to the branch I currently have checked out. Rich> Git blocks this because it doesn't know how to cope with the working directory Rich> in that situation. It does? I can always "git fetch origin" in my repo, and the remote branches are in "origin/master, origin/foo, origin/bar". Totally separate from my working tree. If I want to *examine* them, I can make a WIP commit, or use "git stash", and then check them out headless: git stash save git checkout origin/master ## examine ## now go back git checkout master git stash pop and now I can see what the upstream looks like. Or just diff them: git diff ..origin/master Rich> Merging is straightforward. Even updating, (checkout), is fairly Rich> straightforward. But the insistence on a single tip means that if Rich> I commit directly to a non-tip commit, git doesn't know what to do Rich> with the branch pointer. If it leaves it at my commit, then the Rich> other changes are essentially orphaned. If it leaves it at the Rich> other changes, then my commit is essentially orphaned. While it's Rich> probably possible to force git to do this anyway, including Rich> orphaning one set of changes, doing so is of limited value since Rich> the git interface makes the assumption that branches have a single Rich> tip anyway. So, make a set of related names for your branches. It's better with names anyway. Rich> Pushing is blocked in git. Git simply refuses some push requests Rich> which have obvious and fairly straightforward semantics. git push master:from-merlyn/master And now someone can look at "from-merlyn/master", and know that it's from me, and related to master, and either incorporate it into the real master, or cherry-pick from it, or whatever. Solved. Rich> You and I want to share a branch and we each have local, Rich> unattended cache/mirror repositories that we would like to use to Rich> pass data between us. This doesn't work in git because the first Rich> time you and I make simultaneous changes, whether they collide or Rich> not, the unattended repositories become wedged. They each refuse Rich> to talk to the other until someone manually unwedges them. No, you do it like above. Some *person* has to sign off the merge each time. But we can share the unmerged changeset through other branches. Rich> I want that if you and say, Sitaram commit conflicting changes to Rich> a shared branch, it's easy for me to recognize that the conflict Rich> exist and easy for me to resolve that conflict in my own Rich> repository. I want the source code control system to keep track Rich> of those things, show them to me/us, and to track and show my Rich> resolution to you. This stuff should all be automatic. It Rich> shouldn't require explicit testing, manual pulling, nor explicit Rich> discussion between the three of us. It shouldn't prohibit that Rich> either, but it shouldn't require it. You're asking a lot of an automated system. I think you're trying to get a system to replace the communication you should be doing as a developer. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 21:05 ` Randal L. Schwartz @ 2012-05-01 21:12 ` Junio C Hamano 2012-05-01 21:25 ` Rich Pixley 2012-05-01 21:29 ` Rich Pixley 1 sibling, 1 reply; 100+ messages in thread From: Junio C Hamano @ 2012-05-01 21:12 UTC (permalink / raw) To: Randal L. Schwartz Cc: Rich Pixley, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git merlyn@stonehenge.com (Randal L. Schwartz) writes: > Rich> I want that if you and say, Sitaram commit conflicting changes to > Rich> a shared branch, it's easy for me to recognize that the conflict > Rich> exist and easy for me to resolve that conflict in my own > Rich> repository. I want the source code control system to keep track > Rich> of those things, show them to me/us, and to track and show my > Rich> resolution to you. This stuff should all be automatic. It > Rich> shouldn't require explicit testing, manual pulling, nor explicit > Rich> discussion between the three of us. It shouldn't prohibit that > Rich> either, but it shouldn't require it. > > You're asking a lot of an automated system. I think you're trying to > get a system to replace the communication you should be doing as a > developer. While what Merlyn says is always right ;-), you could automate things by having your post-receive hook to notice that remotes/from-merlyn/master location was updated, attempt an automerge, and then report a failure. Not everybody wants such an automated system, so there is no such complexity in the vanilla setting, but the important thing is that whoever needs such a complexity could easily do so. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 21:12 ` Junio C Hamano @ 2012-05-01 21:25 ` Rich Pixley 2012-05-01 21:28 ` Randal L. Schwartz 0 siblings, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-01 21:25 UTC (permalink / raw) To: Junio C Hamano Cc: Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/1/12 14:12 , Junio C Hamano wrote: > merlyn@stonehenge.com (Randal L. Schwartz) writes: > >> Rich> I want that if you and say, Sitaram commit conflicting changes to >> Rich> a shared branch, it's easy for me to recognize that the conflict >> Rich> exist and easy for me to resolve that conflict in my own >> Rich> repository. I want the source code control system to keep track >> Rich> of those things, show them to me/us, and to track and show my >> Rich> resolution to you. This stuff should all be automatic. It >> Rich> shouldn't require explicit testing, manual pulling, nor explicit >> Rich> discussion between the three of us. It shouldn't prohibit that >> Rich> either, but it shouldn't require it. >> >> You're asking a lot of an automated system. I think you're trying to >> get a system to replace the communication you should be doing as a >> developer. > > While what Merlyn says is always right ;-), you could automate things by > having your post-receive hook to notice that remotes/from-merlyn/master > location was updated, attempt an automerge, and then report a failure. > > Not everybody wants such an automated system, so there is no such > complexity in the vanilla setting, but the important thing is that whoever > needs such a complexity could easily do so. I think we have different definitions of "easily". This is simple, first use sorts of stuff. I've already invested weeks in trying to understand git enough to use it and I still don't have a process I like, much less do I know how to write a post-receive hook. I'm sure I could, given enough time. But frankly, I could switch to a different source code control system in less time. Simple things should be simple. They shouldn't require in-depth knowledge and customization of the tool. In other systems, the automation is optional, but it's available. If you want to vet each and every change as you take it, you can. But you don't have to. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 21:25 ` Rich Pixley @ 2012-05-01 21:28 ` Randal L. Schwartz 2012-05-01 21:57 ` Rich Pixley 0 siblings, 1 reply; 100+ messages in thread From: Randal L. Schwartz @ 2012-05-01 21:28 UTC (permalink / raw) To: Rich Pixley Cc: Junio C Hamano, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git >>>>> "Rich" == Rich Pixley <rich.pixley@palm.com> writes: Rich> I think we have different definitions of "easily". This is Rich> simple, first use sorts of stuff. Have you read the Pro Git book? Have you read the gitcore-tutorial page? Have you read the gitworkflows manpage? The processes for "simple, first use" sorts of stuff never gets into the complexity you are describing. You're definitely into more advanced stuff and then complain when you also need to be more advanced to set it up. Not sure what your goal is, then. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 21:28 ` Randal L. Schwartz @ 2012-05-01 21:57 ` Rich Pixley 2012-05-01 22:56 ` Michael Witten 0 siblings, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-01 21:57 UTC (permalink / raw) To: Randal L. Schwartz Cc: Junio C Hamano, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/1/12 14:28 , Randal L. Schwartz wrote: >>>>>> "Rich" == Rich Pixley<rich.pixley@palm.com> writes: > > Rich> I think we have different definitions of "easily". This is > Rich> simple, first use sorts of stuff. > > Have you read the Pro Git book? Yes. The things it covers, it mostly covers well. But it's lacking a lot. There's nothing in it about repository networks, how to get stuff out of my index, reset, and it's not very good about explaining that things like rebase screw up your repository in ways that make sharing impossible. I know that because of how mercurial works and from reverse engineering what must be required, not from reading git doc. And I've spent close to a week now trying to use git on this project, throwing away repositories, patching by hand, and trying to sort out why git was refusing to push for me. That wasn't explained at all nor do the git error messages explain what's happening. > Have you read the gitcore-tutorial page? Not recently. It was pretty much impenetrable the first few times through. I was looking for how to use git, I wasn't interested in all of the gory details of how it stored everything. Just skimmed again. Will need to read it again more thoroughly, though I don't see anything on the stuff we've been discussing. > Have you read the gitworkflows manpage? Yes, but not in a long time. It seems to be more about the policies of working on git source code than about usage of git. > The processes for "simple, first use" sorts of stuff never gets into > the complexity you are describing. You're definitely into more advanced > stuff and then complain when you also need to be more advanced to set it > up. Not sure what your goal is, then. This stuff isn't advanced anymore. It's kind of standard. My complaint is that doing standard stuff like this shouldn't require advanced work. I have days, weeks into git learning curve so far, I've clearly only begun, and I have a big list of things I still can't do in git, though I can do them in other source code control systems. In contrast, I was up and using mercurial in about a day and a half, including all of the stuff we've discussed, and all of the things I've even read about in git. Learning mq's only took about 20 minutes. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 21:57 ` Rich Pixley @ 2012-05-01 22:56 ` Michael Witten 2012-05-01 23:55 ` Philip Oakley ` (3 more replies) 0 siblings, 4 replies; 100+ messages in thread From: Michael Witten @ 2012-05-01 22:56 UTC (permalink / raw) To: Rich Pixley Cc: Randal L. Schwartz, Junio C Hamano, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Tue, May 1, 2012 at 9:57 PM, Rich Pixley <rich.pixley@palm.com> wrote: > In contrast, I was up and using mercurial in about a day and a half, > including all of the stuff we've discussed, and all of the things I've even > read about in git. Learning mq's only took about 20 minutes. Fortunately, git is based on extremely simple principles. Unfortunately, git grew out of really bright people hacking stuff together in order to get sh!t dun; the result is not approachably or even well documented, the UI is sometimes a bit of a kludge, the API is probably nonexistent, and the terminology is so loosely thrown about that it's easy to forget which way is up in discussions. (Note, though, that Junio has done a laudable job of keeping the whole experiment going strong). Having recognized these deficiencies, I suggest that you provide at least one tiny little use case that doesn't work as you'd like; it should be in the form of a command line example that we can all reproduce and discuss precisely. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 22:56 ` Michael Witten @ 2012-05-01 23:55 ` Philip Oakley 2012-05-03 16:08 ` Hallvard Breien Furuseth 2012-05-03 18:46 ` Rich Pixley ` (2 subsequent siblings) 3 siblings, 1 reply; 100+ messages in thread From: Philip Oakley @ 2012-05-01 23:55 UTC (permalink / raw) To: Michael Witten, Rich Pixley Cc: Randal L. Schwartz, Junio C Hamano, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git From: "Michael Witten" <mfwitten@gmail.com> Sent: Tuesday, May 01, 2012 11:56 PM > On Tue, May 1, 2012 at 9:57 PM, Rich Pixley <rich.pixley@palm.com> wrote: > >> In contrast, I was up and using mercurial in about a day and a half, >> including all of the stuff we've discussed, and all of the things I've >> even >> read about in git. Learning mq's only took about 20 minutes. > > Fortunately, git is based on extremely simple principles. > Unfortunately, git grew out of really bright people hacking stuff > together in order to get sh!t dun; the result is not approachably or > even well documented, the UI is sometimes a bit of a kludge, the API > is probably nonexistent, and the terminology is so loosely thrown > about that it's easy to forget which way is up in discussions. > (Note, though, that Junio has done a laudable job of keeping the > whole experiment going strong). > > Having recognized these deficiencies, I suggest that you provide > at least one tiny little use case that doesn't work as you'd > like; it should be in the form of a command line example that we > can all reproduce and discuss precisely. > -- A bit of browsing found http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ which helped with some of the confusion about the different meanings of "branch". It looks like an Hg branch is a Git clone. Git can be hard work until one 'gets' how and why the new DVCS approach works. Plus learing the UI. It is very hard to change one's mindset about how/why/when the old VCS approach broke (or isn't). The common VCS approach is based on drawing office practices from before the Titanic was built. It is only very recently that the reproduction and verification cost for data duplication have dropped sufficiently that a DVCS is the better approach. The historical approach was to protect the single 'master' item (with lots of admin & process). Now it's about 'status accounting' - do I have the right copy at the right status - i.e. the declared master sha1. Philip ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 23:55 ` Philip Oakley @ 2012-05-03 16:08 ` Hallvard Breien Furuseth 2012-05-03 18:20 ` Rich Pixley 0 siblings, 1 reply; 100+ messages in thread From: Hallvard Breien Furuseth @ 2012-05-03 16:08 UTC (permalink / raw) To: Philip Oakley Cc: Michael Witten, Rich Pixley, Randal L. Schwartz, Junio C Hamano, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git Philip Oakley wrote: > A bit of browsing found > http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ > which helped with some of the confusion about the different meanings > of "branch". It looks like an Hg branch is a Git clone. Git can be > hard work until one 'gets' how and why the new DVCS approach works. > Plus learing the UI. Aha, now this thread finally makes some sense. So when Rich wants a "branch" with several tips, he actually wants several Git clones (repositories) with the same Git branch checked out - and some of them with local commits to it. And these commits can be shared as remote branches between the clones, which in Hg-speak means that in one particular clone, Git will "bookmark" the other clones' tips. -- Hallvard ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 16:08 ` Hallvard Breien Furuseth @ 2012-05-03 18:20 ` Rich Pixley 2012-05-03 23:04 ` Hallvard Breien Furuseth 0 siblings, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-03 18:20 UTC (permalink / raw) To: Hallvard Breien Furuseth Cc: Philip Oakley, Michael Witten, Randal L. Schwartz, Junio C Hamano, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/3/12 09:08 , Hallvard Breien Furuseth wrote: > Philip Oakley wrote: >> A bit of browsing found >> http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ >> which helped with some of the confusion about the different meanings >> of "branch". It looks like an Hg branch is a Git clone. Git can be >> hard work until one 'gets' how and why the new DVCS approach works. >> Plus learing the UI. > Aha, now this thread finally makes some sense. So when Rich > wants a "branch" with several tips, he actually wants several > Git clones (repositories) with the same Git branch checked out - > and some of them with local commits to it. Yes. > And these commits can be shared as remote branches between the > clones, which in Hg-speak means that in one particular clone, > Git will "bookmark" the other clones' tips. Well, no. In hg, these are all managed. So there's no scaling issue. They can all push/pull together, since they are really all just one shared branch. Adding a new repository to the mix is trivial. And either pushes or pulls can be used, or any combo. With git, I must manually make space for each and every repository, manually track which set of changes are where, manually track which need to be merged, and manually track which repositories are looking at which git branches so that they don't collide, or only collide in the current repository and only when I'm prepared to merge them. (The bookmark solution appears to be what hg-git uses. Hg-git is an hg extension to allow push/pull/clone from git repositories using hg. Unfortunately, it doesn't translate git submodules into hg subrepositories - yet.) --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 18:20 ` Rich Pixley @ 2012-05-03 23:04 ` Hallvard Breien Furuseth 2012-05-03 23:06 ` Hallvard Breien Furuseth 0 siblings, 1 reply; 100+ messages in thread From: Hallvard Breien Furuseth @ 2012-05-03 23:04 UTC (permalink / raw) To: Rich Pixley Cc: Philip Oakley, Michael Witten, Randal L. Schwartz, Junio C Hamano, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Thu, 03 May 2012 11:20:56 -0700, Rich Pixley <rich.pixley@palm.com> wrote: > On 5/3/12 09:08 , Hallvard Breien Furuseth wrote: >> Aha, now this thread finally makes some sense. So when Rich >> wants a "branch" with several tips, he actually wants several >> Git clones (repositories) with the same Git branch checked out - >> and some of them with local commits to it. > Yes. >> And these commits can be shared as remote branches between the >> clones, which in Hg-speak means that in one particular clone, >> Git will "bookmark" the other clones' tips. > Well, no. In hg, these are all managed. So there's no scaling > issue. They can all push/pull together, since they are really all > just one shared branch. Adding a new repository to the mix is > trivial. And either pushes or pulls can be used, or any combo. > > With git, I must manually make space for each and every repository, > manually track which set of changes are where, manually track which > need to be merged, and manually track which repositories are looking > at which git branches so that they don't collide, or only collide in > the current repository and only when I'm prepared to merge them. > (...) If you say so. I don't know Hg and I'm not about to try to guess if you're stuck in another misconception about Git or not, nor to re-read this entire thread substituting "clone" for "branch". Anyway, I notice you're now giving practical Hg examples to go with your Hg vocabulary instead talking Git in Hg vocabulary, so hopefully this'll get cleared up. Anyway, if you have not done so already: If you show this too with a practical Hg example instead of talking Git in a Hg vocabulary, maybe someone can help. -- Hallvard ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 23:04 ` Hallvard Breien Furuseth @ 2012-05-03 23:06 ` Hallvard Breien Furuseth 0 siblings, 0 replies; 100+ messages in thread From: Hallvard Breien Furuseth @ 2012-05-03 23:06 UTC (permalink / raw) To: Hallvard Breien Furuseth Cc: Rich Pixley, Philip Oakley, Michael Witten, Randal L. Schwartz, Junio C Hamano, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git I wrote: > Anyway, (...) Anyway, (...) Meh. I hate cut&paste into/out of webmail. -- Hallvard ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 22:56 ` Michael Witten 2012-05-01 23:55 ` Philip Oakley @ 2012-05-03 18:46 ` Rich Pixley 2012-05-03 21:09 ` Junio C Hamano 2012-05-04 19:30 ` Felipe Contreras 3 siblings, 0 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-03 18:46 UTC (permalink / raw) To: Michael Witten Cc: Randal L. Schwartz, Junio C Hamano, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/1/12 15:56 , Michael Witten wrote: > On Tue, May 1, 2012 at 9:57 PM, Rich Pixley<rich.pixley@palm.com> wrote: > >> In contrast, I was up and using mercurial in about a day and a half, >> including all of the stuff we've discussed, and all of the things I've even >> read about in git. Learning mq's only took about 20 minutes. > Fortunately, git is based on extremely simple principles. > Unfortunately, git grew out of really bright people hacking stuff > together in order to get sh!t dun; the result is not approachably or > even well documented, the UI is sometimes a bit of a kludge, the API > is probably nonexistent, and the terminology is so loosely thrown > about that it's easy to forget which way is up in discussions. > (Note, though, that Junio has done a laudable job of keeping the > whole experiment going strong). Thank you for acknowledging that. > Having recognized these deficiencies, I suggest that you provide > at least one tiny little use case that doesn't work as you'd > like; it should be in the form of a command line example that we > can all reproduce and discuss precisely. I think I already have. And you've given me an approach that is largely functional in git. It's not wonderful, but it's mostly functional. I'll post my comparison elsepost. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 22:56 ` Michael Witten 2012-05-01 23:55 ` Philip Oakley 2012-05-03 18:46 ` Rich Pixley @ 2012-05-03 21:09 ` Junio C Hamano 2012-05-03 22:44 ` Rich Pixley 2012-05-04 19:30 ` Felipe Contreras 3 siblings, 1 reply; 100+ messages in thread From: Junio C Hamano @ 2012-05-03 21:09 UTC (permalink / raw) To: Michael Witten Cc: Rich Pixley, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git Michael Witten <mfwitten@gmail.com> writes: > (Note, though, that Junio has done a laudable job of keeping the > whole experiment going strong). You are giving me too much credit, and at the same time insulting the people who polished Git enough to suit their workflow. To them, the tool has past "experiment" stage long time ago. They found what was lacking and what would help the need in their workflow. I just have helped them shape their ideas into a coherent whole. That does not mean there is nothing missing, still appears experimental, or inconsistent in the parts of the system that these people do not use nor care about, and when you bring in people coming from different background, they will notice the behaviour or default that do not match their expectation. They can do the usual "scratching own itches" thing the same way to others who have done before. As nobody forces them to do so, they can instead keep whining. It's mostly their choice. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 21:09 ` Junio C Hamano @ 2012-05-03 22:44 ` Rich Pixley 2012-05-03 22:53 ` Randal L. Schwartz ` (2 more replies) 0 siblings, 3 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-03 22:44 UTC (permalink / raw) To: Junio C Hamano Cc: Michael Witten, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/3/12 14:09 , Junio C Hamano wrote: > Michael Witten<mfwitten@gmail.com> writes: > >> (Note, though, that Junio has done a laudable job of keeping the >> whole experiment going strong). > > You are giving me too much credit, and at the same time insulting the > people who polished Git enough to suit their workflow. To them, the tool > has past "experiment" stage long time ago. They found what was lacking > and what would help the need in their workflow. I just have helped them > shape their ideas into a coherent whole. > > That does not mean there is nothing missing, still appears experimental, > or inconsistent in the parts of the system that these people do not use > nor care about, and when you bring in people coming from different > background, they will notice the behaviour or default that do not match > their expectation. They can do the usual "scratching own itches" thing > the same way to others who have done before. As nobody forces them to do > so, they can instead keep whining. It's mostly their choice. Once you've been bitten, and learned to shy away from the sore spot, you don't really have much motivation to change it. The motivation to change it would be to make it easier for the next person. Git clearly doesn't have much of that value in the community culture. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 22:44 ` Rich Pixley @ 2012-05-03 22:53 ` Randal L. Schwartz 2012-05-03 22:59 ` Junio C Hamano 2012-05-04 19:23 ` Felipe Contreras 2 siblings, 0 replies; 100+ messages in thread From: Randal L. Schwartz @ 2012-05-03 22:53 UTC (permalink / raw) To: Rich Pixley Cc: Junio C Hamano, Michael Witten, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git >>>>> "Rich" == Rich Pixley <rich.pixley@palm.com> writes: Rich> Git clearly doesn't have much of that value in the community Rich> culture. You don't know how wrong you are. Good luck getting help after disrespecting the very people who *are* trying to help you. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 22:44 ` Rich Pixley 2012-05-03 22:53 ` Randal L. Schwartz @ 2012-05-03 22:59 ` Junio C Hamano 2012-05-04 19:23 ` Felipe Contreras 2 siblings, 0 replies; 100+ messages in thread From: Junio C Hamano @ 2012-05-03 22:59 UTC (permalink / raw) To: Rich Pixley Cc: Michael Witten, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git Rich Pixley <rich.pixley@palm.com> writes: > On 5/3/12 14:09 , Junio C Hamano wrote: >> Michael Witten<mfwitten@gmail.com> writes: >> >>> (Note, though, that Junio has done a laudable job of keeping the >>> whole experiment going strong). >> >> You are giving me too much credit, and at the same time insulting the >> people who polished Git enough to suit their workflow. To them, the tool >> has past "experiment" stage long time ago. They found what was lacking >> and what would help the need in their workflow. I just have helped them >> shape their ideas into a coherent whole. >> >> That does not mean there is nothing missing, still appears experimental, >> or inconsistent in the parts of the system that these people do not use >> nor care about, and when you bring in people coming from different >> background, they will notice the behaviour or default that do not match >> their expectation.... > > ... The motivation to > change it would be to make it easier for the next person. That is how the workflow support elements that were originally missing like reflogs, stashes, tracking branches, etc. all came to exist. Making it easier for the next person is why we had a large discussion on the default behaviour of unconfigured push andthe follow-up implementation of the "simple" push behaviour. It is a good example that community members are willing to help new person even at the expense of inconvenience to old timers. What does _not_ happen is to chase down people who whined and left without giving us something concrete enough to base design of new workflow support elements, but the community cannot police the behaviour of those who come, whine and then leave, so... ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 22:44 ` Rich Pixley 2012-05-03 22:53 ` Randal L. Schwartz 2012-05-03 22:59 ` Junio C Hamano @ 2012-05-04 19:23 ` Felipe Contreras 2 siblings, 0 replies; 100+ messages in thread From: Felipe Contreras @ 2012-05-04 19:23 UTC (permalink / raw) To: Rich Pixley Cc: Junio C Hamano, Michael Witten, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Fri, May 4, 2012 at 12:44 AM, Rich Pixley <rich.pixley@palm.com> wrote: > Git clearly doesn't have much of that value in the community culture. And you are clearly delusional. You don't like git, we get it, can you stop listing the ways git sucks on every paragraph you write? Thanks. And here's a lesson about reality; reality doesn't care what you think. When you say git is X, Y, and Z, that doesn't mean it's true; that's what you *think*; but what you need to understand is that what you *think* might be totally wrong. These are called value judgments, and you should stop assuming your value judgments are truths, it would make it less annoying for people to discuss with you (specially on a mailing list about the thing you are constantly bashing), and it would help you save face when it turns out you are totally wrong. tl;dr: value judgments != truths Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 22:56 ` Michael Witten ` (2 preceding siblings ...) 2012-05-03 21:09 ` Junio C Hamano @ 2012-05-04 19:30 ` Felipe Contreras 2012-05-04 19:41 ` Michael Witten 3 siblings, 1 reply; 100+ messages in thread From: Felipe Contreras @ 2012-05-04 19:30 UTC (permalink / raw) To: Michael Witten Cc: Rich Pixley, Randal L. Schwartz, Junio C Hamano, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Wed, May 2, 2012 at 12:56 AM, Michael Witten <mfwitten@gmail.com> wrote: > On Tue, May 1, 2012 at 9:57 PM, Rich Pixley <rich.pixley@palm.com> wrote: > >> In contrast, I was up and using mercurial in about a day and a half, >> including all of the stuff we've discussed, and all of the things I've even >> read about in git. Learning mq's only took about 20 minutes. > > Fortunately, git is based on extremely simple principles. > Unfortunately, git grew out of really bright people hacking stuff > together in order to get sh!t dun; the result is not approachably or > even well documented, the UI is sometimes a bit of a kludge, the API > is probably nonexistent, and the terminology is so loosely thrown > about that it's easy to forget which way is up in discussions. > (Note, though, that Junio has done a laudable job of keeping the > whole experiment going strong). You are a prime example of this experiment called 'life', also based on extremely simple principles, mostly through trial and error. Design is overrated :) -- Felipe Contreras ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 19:30 ` Felipe Contreras @ 2012-05-04 19:41 ` Michael Witten 0 siblings, 0 replies; 100+ messages in thread From: Michael Witten @ 2012-05-04 19:41 UTC (permalink / raw) To: Felipe Contreras Cc: Rich Pixley, Randal L. Schwartz, Junio C Hamano, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Fri, May 4, 2012 at 7:30 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote: > On Wed, May 2, 2012 at 12:56 AM, Michael Witten <mfwitten@gmail.com> wrote: >> On Tue, May 1, 2012 at 9:57 PM, Rich Pixley <rich.pixley@palm.com> wrote: >> >>> In contrast, I was up and using mercurial in about a day and a half, >>> including all of the stuff we've discussed, and all of the things I've even >>> read about in git. Learning mq's only took about 20 minutes. >> >> Fortunately, git is based on extremely simple principles. >> Unfortunately, git grew out of really bright people hacking stuff >> together in order to get sh!t dun; the result is not approachably or >> even well documented, the UI is sometimes a bit of a kludge, the API >> is probably nonexistent, and the terminology is so loosely thrown >> about that it's easy to forget which way is up in discussions. >> (Note, though, that Junio has done a laudable job of keeping the >> whole experiment going strong). > > You are a prime example of this experiment called 'life', also based > on extremely simple principles, mostly through trial and error. Design > is overrated :) There is no process other than trial and error, or more precisely, variation and selection. Note, though, that the levels of sophistication involved with variation and selection differ among manifestations of this process. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 21:05 ` Randal L. Schwartz 2012-05-01 21:12 ` Junio C Hamano @ 2012-05-01 21:29 ` Rich Pixley 2012-05-01 21:39 ` Randal L. Schwartz 2012-05-01 23:30 ` Felipe Contreras 1 sibling, 2 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-01 21:29 UTC (permalink / raw) To: Randal L. Schwartz; +Cc: Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/1/12 14:05 , Randal L. Schwartz wrote: >>>>>> "Rich" == Rich Pixley<rich.pixley@palm.com> writes: > > Rich> I want to be able to fetch changes to the branch I currently have checked out. > Rich> Git blocks this because it doesn't know how to cope with the working directory > Rich> in that situation. > > It does? Yes, it does. > I can always "git fetch origin" in my repo, and the remote > branches are in "origin/master, origin/foo, origin/bar". Totally > separate from my working tree. Sure. You can fetch other branches, (unless you happen to be checked out from them). But you can't fetch to master if you're checked out from master. > So, make a set of related names for your branches. It's better with > names anyway. I disagree. They only even need branches if they're different. And the branches can be extremely lightweight. With names, I have to manually track a geometric explosion of extraneous branches and branch names, just in order to be able to sync changes back and forth. That's all work that could be managed automatically by the source code control system. > Rich> Pushing is blocked in git. Git simply refuses some push requests > Rich> which have obvious and fairly straightforward semantics. > > git push master:from-merlyn/master > > And now someone can look at "from-merlyn/master", and know that it's > from me, and related to master, and either incorporate it into the real > master, or cherry-pick from it, or whatever. Solved. Again, yes, you can push to other branches. You could push to other repositories too. That's not really what I'm talking about. > You're asking a lot of an automated system. I think you're trying to > get a system to replace the communication you should be doing as a > developer. I hear that that's what you think. But really, I'm asking for automation to replace the automation I already have in preexisting source code control systems. There are a number of situations, like the ones I've described, that git just plain doesn't cope well with. Other source code control systems have, and going backwards seems silly and frustrating. My particular situation is that I'm developing a "feature" and to do that, I need to be testing on multiple machines. Tens of them. I really don't want hundreds of named branches that I must manually merge from constantly. With mercurial or monotone or even subversion, it's trivial. Branches can be shared. And pushing between them is similarly trivial. It can be done in seconds. With git, it takes hours to do all the manual moves, track the manual moves manually, verify that they've been done correctly, and then later it takes hours to correct the ones that were done incorrectly because they were all done manually or because one machine happened to be down at the time and so got the changes in the wrong order, or whatever. I'm not asking for anything new. I'm asking for something that's as capable as what we've had for years now. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 21:29 ` Rich Pixley @ 2012-05-01 21:39 ` Randal L. Schwartz 2012-05-01 22:07 ` Rich Pixley 2012-05-01 23:30 ` Felipe Contreras 1 sibling, 1 reply; 100+ messages in thread From: Randal L. Schwartz @ 2012-05-01 21:39 UTC (permalink / raw) To: Rich Pixley; +Cc: Sitaram Chamarty, Ted Ts'o, Seth Robertson, git >>>>> "Rich" == Rich Pixley <rich.pixley@palm.com> writes: >> I can always "git fetch origin" in my repo, and the remote >> branches are in "origin/master, origin/foo, origin/bar". Totally >> separate from my working tree. Rich> Sure. You can fetch other branches, (unless you happen to be Rich> checked out from them). But you can't fetch to master if you're Rich> checked out from master. No, you are still missing it. "git fetch" updates the remote tracking branches, which you commonly reference preceded by "origin". So "git fetch" DOES NOT TOUCH "master". It touches only "origin/master". Only when you merge that remote in to your local master do you need to worry about dirty trees or broken merges. Rich> My particular situation is that I'm developing a "feature" and to Rich> do that, I need to be testing on multiple machines. Tens of them. I think you're now confusing git with a deploy system. That is also something that will lead you to unnecessary grief. Pick a deploy system that's not git, and integrate git with it. Rich> I really don't want hundreds of named branches that I must Rich> manually merge from constantly. I don't see how you would end up with this. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 21:39 ` Randal L. Schwartz @ 2012-05-01 22:07 ` Rich Pixley 2012-05-01 22:17 ` Andreas Ericsson ` (2 more replies) 0 siblings, 3 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-01 22:07 UTC (permalink / raw) To: Randal L. Schwartz; +Cc: Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/1/12 14:39 , Randal L. Schwartz wrote: >>>>>> "Rich" == Rich Pixley<rich.pixley@palm.com> writes: > >>> I can always "git fetch origin" in my repo, and the remote >>> branches are in "origin/master, origin/foo, origin/bar". Totally >>> separate from my working tree. > > Rich> Sure. You can fetch other branches, (unless you happen to be > Rich> checked out from them). But you can't fetch to master if you're > Rich> checked out from master. > > No, you are still missing it. > > "git fetch" updates the remote tracking branches, which you commonly > reference preceded by "origin". So "git fetch" DOES NOT TOUCH "master". > It touches only "origin/master". Yes. I understand that that is how git typically works in a non-bare repository. Do you understand what I'm saying? > Only when you merge that remote in to your local master do you need to > worry about dirty trees or broken merges. > > Rich> My particular situation is that I'm developing a "feature" and to > Rich> do that, I need to be testing on multiple machines. Tens of them. > > I think you're now confusing git with a deploy system. That is also > something that will lead you to unnecessary grief. Pick a deploy system > that's not git, and integrate git with it. No, not a deploy system. You use a deploy system to set up something like multiple server http farms. What I'm doing is more akin to porting the same piece of software to 20 different operating system distributions. I'm not "deploying" the source code. I'm developing it. Thank you for acknowledging that git is a poor match for this scenario, though. > Rich> I really don't want hundreds of named branches that I must > Rich> manually merge from constantly. > > I don't see how you would end up with this. Yup. I'm beginning to see that. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 22:07 ` Rich Pixley @ 2012-05-01 22:17 ` Andreas Ericsson 2012-05-01 23:01 ` PJ Weisberg 2012-05-02 14:21 ` Hallvard Breien Furuseth 2 siblings, 0 replies; 100+ messages in thread From: Andreas Ericsson @ 2012-05-01 22:17 UTC (permalink / raw) To: Rich Pixley Cc: Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 05/02/2012 12:07 AM, Rich Pixley wrote: > On 5/1/12 14:39 , Randal L. Schwartz wrote: >> >> Rich> My particular situation is that I'm developing a "feature" >> and to do that, I need to be testing on multiple machines. >> Tens of them. >> >> I think you're now confusing git with a deploy system. That is >> also something that will lead you to unnecessary grief. Pick a >> deploy system that's not git, and integrate git with it. > > No, not a deploy system. You use a deploy system to set up something > like multiple server http farms. What I'm doing is more akin to > porting the same piece of software to 20 different operating system > distributions. I'm not "deploying" the source code. I'm developing > it. > > Thank you for acknowledging that git is a poor match for this > scenario, though. > Git works well for that if you put hooks in place to trigger builds and test-runs on the testservers though. We do exactly that, and I doubt we're the only ones who do automated testing of every push. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 22:07 ` Rich Pixley 2012-05-01 22:17 ` Andreas Ericsson @ 2012-05-01 23:01 ` PJ Weisberg 2012-05-03 18:43 ` Rich Pixley 2012-05-02 14:21 ` Hallvard Breien Furuseth 2 siblings, 1 reply; 100+ messages in thread From: PJ Weisberg @ 2012-05-01 23:01 UTC (permalink / raw) To: Rich Pixley Cc: Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Tue, May 1, 2012 at 3:07 PM, Rich Pixley <rich.pixley@palm.com> wrote: > No, not a deploy system. You use a deploy system to set up something like > multiple server http farms. What I'm doing is more akin to porting the same > piece of software to 20 different operating system distributions. I'm not > "deploying" the source code. I'm developing it. I fail to see how you would end up with more than one branch per environment, though. Fewer, if you do the merge before pushing your change back to the server. It sounds like you're asking for branches without names (or automatically assigned names like master-0, master-1, etc.). I'm sure it's all very intuitive in Hg (which I know nothing about), but it sounds to me like a recipe for confusion. -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 23:01 ` PJ Weisberg @ 2012-05-03 18:43 ` Rich Pixley 2012-05-03 19:09 ` Nathan Gray 0 siblings, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-03 18:43 UTC (permalink / raw) To: PJ Weisberg Cc: Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/1/12 16:01 , PJ Weisberg wrote: > On Tue, May 1, 2012 at 3:07 PM, Rich Pixley<rich.pixley@palm.com> wrote: > >> No, not a deploy system. You use a deploy system to set up something like >> multiple server http farms. What I'm doing is more akin to porting the same >> piece of software to 20 different operating system distributions. I'm not >> "deploying" the source code. I'm developing it. > I fail to see how you would end up with more than one branch per > environment, though. Fewer, if you do the merge before pushing your > change back to the server. > > It sounds like you're asking for branches without names (or > automatically assigned names like master-0, master-1, etc.). I'm sure > it's all very intuitive in Hg (which I know nothing about), but it > sounds to me like a recipe for confusion. I'm finding the reverse to be true. In hg, I don't have to think about how many other branches or repositories there might be. I don't have to track where the changes are. And I don't have to do anything to add another repository to the mix or to remove one. Trivial merges are trivial. The view from any repository is identical, not just symmetric. The things I want to do are all simple commands. Pull from the cache, merge if necessary, do some work, push to the cache. Repeat as necessary since there will be numerous collisions and merges since I'm working on multiple machines concurrently. And eventually, push to central server. With git, if I use the traditional triangle architecture, I have to manually name every repository and every branch uniquely, create fresh branches in every other repository when I create one new repository. Remove old branches from every other repository whenever I remove one. Track collisions manually, track which repositories have which changes manually, and be extra careful about moving changes around so that they don't collide or force merge commits because that screws up git histories. In order to do a simple source code control task, I have to stop, formulate a plan for making things work in git that still ducks both the limitations and traps of git and still accomplishes my goal, and then execute that plan precisely, because recovery is difficult. If I skip the standard git triangle merging architecture, I can collapse some of that bookkeeping by sharing a branch. But the cost is that pushing, pulling, and merging become even more complex as I have to dodge more limitations, (essentially, pushing doesn't work, star networks don't work, etc.) Trying to keep all of that bookkeeping in my head, or trying to remember all of those arbitrary and unnecessary limitations is more complicated. I'll grant that some of this is unique to my current work flow. But I think that a lot of it carries into other work flows as well. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 18:43 ` Rich Pixley @ 2012-05-03 19:09 ` Nathan Gray 2012-05-03 19:16 ` Rich Pixley 0 siblings, 1 reply; 100+ messages in thread From: Nathan Gray @ 2012-05-03 19:09 UTC (permalink / raw) To: Rich Pixley Cc: PJ Weisberg, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Thu, May 3, 2012 at 11:43 AM, Rich Pixley <rich.pixley@palm.com> wrote: > > In hg, I don't have to think about how many other branches or repositories > there might be. I don't have to track where the changes are. And I don't > have to do anything to add another repository to the mix or to remove one. > Trivial merges are trivial. The view from any repository is identical, not > just symmetric. The things I want to do are all simple commands. Pull from > the cache, merge if necessary, do some work, push to the cache. Repeat as > necessary since there will be numerous collisions and merges since I'm > working on multiple machines concurrently. And eventually, push to central > server. Wow, this hg sounds great! You should use that! All kidding aside, what you're talking about are design decisions based on preferred workflows. The workflow you're describing may seem obvious and fantastic to you, but it sounds absurdly complicated to me. You hate the way git handles remote branches. I think it's incredibly sensible for a *truly* distributed VCS to enforce location-based namespacing. Basically, we have differences of opinion. Since your opinion seems to be that hg has done everything right and git has done everything wrong, why are you using git? Cheers, -n8 -- HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch http://hexalex.com On The App Store: http://bit.ly/8Mj1CU On Facebook: http://bit.ly/9MIJiV On Twitter: http://twitter.com/hexalexgame http://n8gray.org ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 19:09 ` Nathan Gray @ 2012-05-03 19:16 ` Rich Pixley 2012-05-03 20:14 ` Randal L. Schwartz 0 siblings, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-03 19:16 UTC (permalink / raw) To: Nathan Gray Cc: PJ Weisberg, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/3/12 12:09 , Nathan Gray wrote: > On Thu, May 3, 2012 at 11:43 AM, Rich Pixley<rich.pixley@palm.com> wrote: >> In hg, I don't have to think about how many other branches or repositories >> there might be. I don't have to track where the changes are. And I don't >> have to do anything to add another repository to the mix or to remove one. >> Trivial merges are trivial. The view from any repository is identical, not >> just symmetric. The things I want to do are all simple commands. Pull from >> the cache, merge if necessary, do some work, push to the cache. Repeat as >> necessary since there will be numerous collisions and merges since I'm >> working on multiple machines concurrently. And eventually, push to central >> server. > Wow, this hg sounds great! You should use that! > > All kidding aside, what you're talking about are design decisions > based on preferred workflows. The workflow you're describing may seem > obvious and fantastic to you, but it sounds absurdly complicated to > me. You hate the way git handles remote branches. I think it's > incredibly sensible for a *truly* distributed VCS to enforce > location-based namespacing. Basically, we have differences of > opinion. Since your opinion seems to be that hg has done everything > right and git has done everything wrong, why are you using git? Corporate mandate. Political decision made without discussion with the people who would be using it. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 19:16 ` Rich Pixley @ 2012-05-03 20:14 ` Randal L. Schwartz 2012-05-03 20:52 ` Rich Pixley 0 siblings, 1 reply; 100+ messages in thread From: Randal L. Schwartz @ 2012-05-03 20:14 UTC (permalink / raw) To: Rich Pixley Cc: Nathan Gray, PJ Weisberg, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git >>>>> "Rich" == Rich Pixley <rich.pixley@palm.com> writes: Rich> Corporate mandate. Political decision made without discussion Rich> with the people who would be using it. Sounds like you put two strikes against git before you even invoked the first command, with that attitude. If you are *serious* about having *git* work for you, it will. Thousands of projects are using git every day. But if you're looking at git like "it's not hg, and I already hate that", you'll end up sounding like you have in the past few days. Methinks *this* is the actual problem. Not git. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 20:14 ` Randal L. Schwartz @ 2012-05-03 20:52 ` Rich Pixley 2012-05-04 15:56 ` Mark Brown 0 siblings, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-03 20:52 UTC (permalink / raw) To: Randal L. Schwartz Cc: Nathan Gray, PJ Weisberg, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/3/12 13:14 , Randal L. Schwartz wrote: >>>>>> "Rich" == Rich Pixley<rich.pixley@palm.com> writes: > Rich> Corporate mandate. Political decision made without discussion > Rich> with the people who would be using it. > > Sounds like you put two strikes against git before you even invoked the > first command, with that attitude. > > If you are *serious* about having *git* work for you, it will. > Thousands of projects are using git every day. > > But if you're looking at git like "it's not hg, and I already hate > that", you'll end up sounding like you have in the past few days. > > Methinks *this* is the actual problem. Not git. It's not just hg. It's other source code control systems as well. Check out any of the other daggy guys. So sure, I'll admit a bias for current technology over older tech. Another part of the problem is that git is badly designed, poorly documented, and the terminology is inconsistent. That, and the limitations make for a pretty steep learning curve. And a third part of the problem is that coming from a number of other daggy tools, I was expecting a lot more out of git that what git actually provides. Certainly, git can be used to do whatever, but a pile of sand and some plastic can be made into a computer too, if we're willing to put enough effort into it. But hey, I'm using it. (I refuse to work with perforce). I had an even worse bias against mecurial before I started using it. The big learning curve was from the linear tools to the daggy tools which happened for me with monotone. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 20:52 ` Rich Pixley @ 2012-05-04 15:56 ` Mark Brown 2012-05-04 18:23 ` Rich Pixley 0 siblings, 1 reply; 100+ messages in thread From: Mark Brown @ 2012-05-04 15:56 UTC (permalink / raw) To: Rich Pixley Cc: Randal L. Schwartz, Nathan Gray, PJ Weisberg, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Thu, May 03, 2012 at 01:52:35PM -0700, Rich Pixley wrote: > It's not just hg. It's other source code control systems as well. > Check out any of the other daggy guys. So sure, I'll admit a bias > for current technology over older tech. I'm still not sure what's missing here without a central server? The other DVCSs I've used (which don't include hg) do require that the user trigger a merge operation somehow; they don't magically go and merge things without being asked. The only thing I've noticed that git does differently is that it caches the remote branches locally by default when remotes are set up. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 15:56 ` Mark Brown @ 2012-05-04 18:23 ` Rich Pixley 2012-05-04 19:14 ` Jakub Narebski 2012-05-04 20:00 ` Mark Brown 0 siblings, 2 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-04 18:23 UTC (permalink / raw) To: Mark Brown Cc: Randal L. Schwartz, Nathan Gray, PJ Weisberg, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/4/12 08:56 , Mark Brown wrote: > On Thu, May 03, 2012 at 01:52:35PM -0700, Rich Pixley wrote: > >> It's not just hg. It's other source code control systems as well. >> Check out any of the other daggy guys. So sure, I'll admit a bias >> for current technology over older tech. > > I'm still not sure what's missing here without a central server? The > other DVCSs I've used (which don't include hg) do require that the user > trigger a merge operation somehow; they don't magically go and merge > things without being asked. Nor does hg. Rather, it allows the collision to be tracked within the source code control tool so that anyone who wants to see it can do so, and so that anyone who wants to merge it can do so. The data flow paths for collisions and proposed changes can follow precisely the same paths as any other code changes. No meta channel is required. This is a different situation from either the one where I, specifically me, must merge or the one where I intend my changes to stay separated from other development, (a new "branch"). The situation with multiple heads allows the merge, the branch, even the decision about whether to merge or branch, to be delayed indefinitely. The fact that it allows for this also allows for a number of different repository network architectures, all of which are blocked in git because of the push problem. In git, those decisions must be made _before_ the push. There's also a possibility of nonterminating merges. That is, if my team is making changes faster than you can merge them, then you'll never get to push your changes. With dual heads, you still can. And then anyone who wants to can merge them. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 18:23 ` Rich Pixley @ 2012-05-04 19:14 ` Jakub Narebski 2012-05-04 20:00 ` Mark Brown 1 sibling, 0 replies; 100+ messages in thread From: Jakub Narebski @ 2012-05-04 19:14 UTC (permalink / raw) To: Rich Pixley Cc: Mark Brown, Randal L. Schwartz, Nathan Gray, PJ Weisberg, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git Rich Pixley <rich.pixley@palm.com> writes: > On 5/4/12 08:56 , Mark Brown wrote: > > On Thu, May 03, 2012 at 01:52:35PM -0700, Rich Pixley wrote: > > > > > It's not just hg. It's other source code control systems as well. > > > Check out any of the other daggy guys. So sure, I'll admit a bias > > > for current technology over older tech. > > > > I'm still not sure what's missing here without a central server? The > > other DVCSs I've used (which don't include hg) do require that the user > > trigger a merge operation somehow; they don't magically go and merge > > things without being asked. > > Nor does hg. Rather, it allows the collision to be tracked within the > source code control tool so that anyone who wants to see it can do so, > and so that anyone who wants to merge it can do so. The data flow > paths for collisions and proposed changes can follow precisely the > same paths as any other code changes. No meta channel is required. > > This is a different situation from either the one where I, > specifically me, must merge or the one where I intend my changes to > stay separated from other development, (a new "branch"). The > situation with multiple heads allows the merge, the branch, even the > decision about whether to merge or branch, to be delayed indefinitely. > > The fact that it allows for this also allows for a number of different > repository network architectures, all of which are blocked in git > because of the push problem. In git, those decisions must be made > _before_ the push. Well, perhaps Git doesn't support "central repository" workflow, where users push to common repository, as well as Mercurial. The main workflow is based on pairs of private (non-bare) + public (bare) repositories, one pair for each developer. You push to own repository, and pull from other public repositories. Note that there is no problem in Git in "pull" direction (at least for pulling single branch): you either fast-forward (be updated), or be asked to perform a merge. Instead of anonymous heads you get automatically named remote-tracking branches. With respect to "push" direction Git assumes that you don't have shell access to remote repository, so there is nobody to perform a merge; hence assymetry between "git pull" and "git push". BTW. can you get in Mercurial which anonymous head comes from which repository? > There's also a possibility of nonterminating merges. That is, if my > team is making changes faster than you can merge them, then you'll > never get to push your changes. With dual heads, you still can. And > then anyone who wants to can merge them. Well, if you have that much activity, you better switch workflows away from "central repository" one, perhaps to maintainer + lieutenants pull-based workflow. Or you can axplicitely push to side branch $ git push repo master:foo/master and ask in side channel to merge it. For me using multi-tailed (multi-head) branches instead of remote-tracking branches serves to blur important distinction (assymetry) between pull and push directions. Now if I understand correctly what you wanted to have is a set of remote repositories, updated only by you (or at least updated in such way that fast-forward non-merge updates are more common than merges), and a way to fetch from those repositories so that branches gets updated to most recent version from among the set of those repositories, isn't it? That's quite advanced workflow / requirement, isn't it? -- Jakub Narebski ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 18:23 ` Rich Pixley 2012-05-04 19:14 ` Jakub Narebski @ 2012-05-04 20:00 ` Mark Brown 1 sibling, 0 replies; 100+ messages in thread From: Mark Brown @ 2012-05-04 20:00 UTC (permalink / raw) To: Rich Pixley Cc: Randal L. Schwartz, Nathan Gray, PJ Weisberg, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git [-- Attachment #1: Type: text/plain, Size: 1788 bytes --] On Fri, May 04, 2012 at 11:23:10AM -0700, Rich Pixley wrote: > This is a different situation from either the one where I, > specifically me, must merge or the one where I intend my changes to > stay separated from other development, (a new "branch"). The > situation with multiple heads allows the merge, the branch, even the > decision about whether to merge or branch, to be delayed > indefinitely. So, git does actually allow this quite happily - people can publish and merge whatever they feel like. What seems to be missing (as far as I can tell without having used hg) is the ability to associate random scratch branches from various places with each other and then do things with that information. Like I said in another e-mail elsewhere in the thread this does make sense to me, though it's not a current workflow. > The fact that it allows for this also allows for a number of > different repository network architectures, all of which are blocked > in git because of the push problem. In git, those decisions must be > made _before_ the push. They're only blocked if you don't want to create new branches; idiomatic git is much more free and easy with that idea so a lot of the time what people would say is that is to just create topic branches. > There's also a possibility of nonterminating merges. That is, if my > team is making changes faster than you can merge them, then you'll > never get to push your changes. With dual heads, you still can. > And then anyone who wants to can merge them. Again, this only applies if everyone has to merge onto the same branch and do it regularly - in normal git workflows this doesn't really occur as the final merge branch requires some review/approval process and unmerged work branches are cheap to create and publish. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 22:07 ` Rich Pixley 2012-05-01 22:17 ` Andreas Ericsson 2012-05-01 23:01 ` PJ Weisberg @ 2012-05-02 14:21 ` Hallvard Breien Furuseth 2012-05-02 15:21 ` Michael Witten 2 siblings, 1 reply; 100+ messages in thread From: Hallvard Breien Furuseth @ 2012-05-02 14:21 UTC (permalink / raw) To: Rich Pixley Cc: Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Tue, 01 May 2012 15:07:27 -0700, Rich Pixley wrote: > On 5/1/12 14:39 , Randal L. Schwartz wrote: >> "git fetch" updates the remote tracking branches, which you commonly >> reference preceded by "origin". So "git fetch" DOES NOT TOUCH >> "master". >> It touches only "origin/master". > > Yes. I understand that that is how git typically works in a non-bare > repository. And in a bare repository: git init --bare foo.git cd foo.git git remote add bar ../bar.git git fetch bar --> adds bar/master etc. For some reason, 'git clone --bare' does not treat the cloned repository the same way - it just copies it under refs/heads/ instead of refs/remotes/, without even adding it as a remote. -- Hallvard ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-02 14:21 ` Hallvard Breien Furuseth @ 2012-05-02 15:21 ` Michael Witten 2012-05-03 12:23 ` Hallvard Breien Furuseth 0 siblings, 1 reply; 100+ messages in thread From: Michael Witten @ 2012-05-02 15:21 UTC (permalink / raw) To: Hallvard Breien Furuseth Cc: Rich Pixley, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Wed, 02 May 2012 16:21:07 +0200, Hallvard Breien Furuseth wrote: > And in a bare repository: > > git init --bare foo.git > cd foo.git > git remote add bar ../bar.git > git fetch bar > --> adds bar/master etc. > > For some reason, 'git clone --bare' does not treat the cloned > repository the same way - it just copies it under refs/heads/ > instead of refs/remotes/, without even adding it as a remote. What do you mean? $ git init bar.git; cd bar.git $ echo a > a; git add a; git commit -m a; cd .. $ git clone bar.git baz.git $ git clone --bare baz.git foo.git; cd foo.git $ git remote add bar ../bar.git $ git fetch bar $ git branch -a * master remotes/bar/master Also, removing the `baz' intermediate repository doesn't matter: $ git init bar.git; cd bar.git $ echo a > a; git add a; git commit -m a; cd .. $ git clone --bare bar.git foo.git; cd foo.git $ git remote add bar ../bar.git $ git fetch bar $ git branch -a * master remotes/bar/master For completenes, your example again: $ git init bar.git; cd bar.git $ echo a > a; git add a; git commit -m a; cd .. $ git init --bare foo.git $ cd foo.git $ git remote add bar ../bar.git $ git fetch bar $ git branch -a remotes/bar/master ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-02 15:21 ` Michael Witten @ 2012-05-03 12:23 ` Hallvard Breien Furuseth 2012-05-03 12:53 ` Randal L. Schwartz 2012-05-03 16:09 ` Michael Witten 0 siblings, 2 replies; 100+ messages in thread From: Hallvard Breien Furuseth @ 2012-05-03 12:23 UTC (permalink / raw) To: Michael Witten Cc: Rich Pixley, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Wed, 02 May 2012 15:21:29 -0000, Michael Witten <mfwitten@gmail.com> wrote: >On Wed, 02 May 2012 16:21:07 +0200, Hallvard Breien Furuseth wrote: >> And in a bare repository: >> >> git init --bare foo.git >> cd foo.git >> git remote add bar ../bar.git >> git fetch bar >> --> adds bar/master etc. >> >> For some reason, 'git clone --bare' does not treat the cloned >> repository the same way - it just copies it under refs/heads/ >> instead of refs/remotes/, without even adding it as a remote. > > What do you mean? I mean 'git clone --bare bar.git foo.git' does not give foo.git a remote named 'origin' with a branch origin/master. Not sure if there is a _simple_ way to do it well either. init + fetch above does not try to hardlink objects/packs like clone does. > (...) > $ git init bar.git; cd bar.git > $ echo a > a; git add a; git commit -m a; cd .. > $ git clone --bare bar.git foo.git; cd foo.git $ git branch -a * master > $ git remote add bar ../bar.git > $ git fetch bar -- Hallvard ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 12:23 ` Hallvard Breien Furuseth @ 2012-05-03 12:53 ` Randal L. Schwartz 2012-05-03 16:09 ` Michael Witten 1 sibling, 0 replies; 100+ messages in thread From: Randal L. Schwartz @ 2012-05-03 12:53 UTC (permalink / raw) To: Hallvard Breien Furuseth Cc: Michael Witten, Rich Pixley, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git >>>>> "Hallvard" == Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no> writes: Hallvard> I mean 'git clone --bare bar.git foo.git' does not give foo.git Hallvard> a remote named 'origin' with a branch origin/master. Not sure Hallvard> if there is a _simple_ way to do it well either. init + fetch Hallvard> above does not try to hardlink objects/packs like clone does. Interesting. I was surprised by this, but I've confirmed it. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 12:23 ` Hallvard Breien Furuseth 2012-05-03 12:53 ` Randal L. Schwartz @ 2012-05-03 16:09 ` Michael Witten 2012-05-03 16:20 ` Hallvard Breien Furuseth 1 sibling, 1 reply; 100+ messages in thread From: Michael Witten @ 2012-05-03 16:09 UTC (permalink / raw) To: Hallvard Breien Furuseth Cc: Rich Pixley, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Thu, 03 May 2012 14:23:59 +0200, Hallvard Furuseth wrote: > On Wed, 02 May 2012 15:21:29 -0000, Michael Witten wrote: > >>On Wed, 02 May 2012 16:21:07 +0200, Hallvard Breien Furuseth wrote: >>> And in a bare repository: >>> >>> git init --bare foo.git >>> cd foo.git >>> git remote add bar ../bar.git >>> git fetch bar >>> --> adds bar/master etc. >>> >>> For some reason, 'git clone --bare' does not treat the cloned >>> repository the same way - it just copies it under refs/heads/ >>> instead of refs/remotes/, without even adding it as a remote. >> >> What do you mean? > > I mean 'git clone --bare bar.git foo.git' does not give foo.git > a remote named 'origin' with a branch origin/master. Not sure > if there is a _simple_ way to do it well either. init + fetch > above does not try to hardlink objects/packs like clone does. > >> (...) >> $ git init bar.git; cd bar.git >> $ echo a > a; git add a; git commit -m a; cd .. >> $ git clone --bare bar.git foo.git; cd foo.git > > $ git branch -a > * master >From `git help clone': --bare Make a bare GIT repository. That is, instead of creating <directory> and placing the administrative files in <directory>/.git, make the <directory> itself the $GIT_DIR. This obviously implies the -n because there is nowhere to check out the working tree. Also the branch heads at the remote are copied directly to corresponding local branch heads, without mapping them to refs/remotes/origin/. When this option is used, neither remote-tracking branches nor the related configuration variables are created. namely: Also the branch heads at the remote are copied directly to corresponding local branch heads, without mapping them to refs/remotes/origin/. When this option is used, neither remote-tracking branches nor the related configuration variables are created. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 16:09 ` Michael Witten @ 2012-05-03 16:20 ` Hallvard Breien Furuseth 2012-05-03 16:44 ` Michael Witten 2012-05-03 18:26 ` Rich Pixley 0 siblings, 2 replies; 100+ messages in thread From: Hallvard Breien Furuseth @ 2012-05-03 16:20 UTC (permalink / raw) To: Michael Witten Cc: Rich Pixley, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Thu, 03 May 2012 16:09:15 -0000, Michael Witten wrote: > On Thu, 03 May 2012 14:23:59 +0200, Hallvard Furuseth wrote: >> I mean 'git clone --bare bar.git foo.git' does not give foo.git >> a remote named 'origin' with a branch origin/master. Not sure >> if there is a _simple_ way to do it well either. init + fetch >> above does not try to hardlink objects/packs like clone does. >> >>> (...) >>> $ git init bar.git; cd bar.git >>> $ echo a > a; git add a; git commit -m a; cd .. >>> $ git clone --bare bar.git foo.git; cd foo.git >> >> $ git branch -a >> * master > > From `git help clone': > > --bare > Make a bare GIT repository. That is, instead of creating > <directory> and placing the administrative files in > <directory>/.git, make the <directory> itself the $GIT_DIR. > This obviously implies the -n because there is nowhere to > check out the working tree. Also the branch heads at the > remote are copied directly to corresponding local branch > heads, without mapping them to refs/remotes/origin/. When > this option is used, neither remote-tracking branches nor the > related configuration variables are created. Yes, I know. I just don't know why. -- Hallvard ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 16:20 ` Hallvard Breien Furuseth @ 2012-05-03 16:44 ` Michael Witten 2012-05-03 18:26 ` Rich Pixley 1 sibling, 0 replies; 100+ messages in thread From: Michael Witten @ 2012-05-03 16:44 UTC (permalink / raw) To: Hallvard Breien Furuseth Cc: Rich Pixley, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Thu, 03 May 2012 18:20:43 +0200, Hallvard Furuseth wrote: > On Thu, 03 May 2012 16:09:15 -0000, Michael Witten wrote: > >> On Thu, 03 May 2012 14:23:59 +0200, Hallvard Furuseth wrote: >> >>> I mean 'git clone --bare bar.git foo.git' does not give foo.git >>> a remote named 'origin' with a branch origin/master. Not sure >>> if there is a _simple_ way to do it well either. init + fetch >>> above does not try to hardlink objects/packs like clone does. >>> >>>> (...) >>>> $ git init bar.git; cd bar.git >>>> $ echo a > a; git add a; git commit -m a; cd .. >>>> $ git clone --bare bar.git foo.git; cd foo.git >>> >>> $ git branch -a >>> * master >> >> From `git help clone': >> >> --bare >> Make a bare GIT repository. That is, instead of creating >> <directory> and placing the administrative files in >> <directory>/.git, make the <directory> itself the $GIT_DIR. >> This obviously implies the -n because there is nowhere to >> check out the working tree. Also the branch heads at the >> remote are copied directly to corresponding local branch >> heads, without mapping them to refs/remotes/origin/. When >> this option is used, neither remote-tracking branches nor the >> related configuration variables are created. > > Yes, I know. I just don't know why. I imagine that the purpose behind a bare repository is really just to provide a repository into which objects may be pushed and from which objects may be fetched, and that's it; it's sole purpose is to act as a point of communication. Cloning a repository with --bare is meant to simplify the task of setting up a bare repository with some initial content. Fortunately, we're talking about the history of a revision control system. I found this with `git blame -L70,76 71821351^ git-clone.txt': commit 4fb66a62eeb7bfec115cd0058d7a05ab62fc23e7 Author: Junio C Hamano <junkio@cox.net> Date: Sun Jan 22 17:27:52 2006 -0800 clone: do not create remotes/origin nor origin branch in a bare repository. It is simply pointless, since no merges will ever happen in such a repository. Signed-off-by: Junio C Hamano <junkio@cox.net> That certainly corroborates the limited purpose of a bare repository. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 16:20 ` Hallvard Breien Furuseth 2012-05-03 16:44 ` Michael Witten @ 2012-05-03 18:26 ` Rich Pixley 2012-05-03 19:33 ` Ted Ts'o 1 sibling, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-03 18:26 UTC (permalink / raw) To: Hallvard Breien Furuseth Cc: Michael Witten, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/3/12 09:20 , Hallvard Breien Furuseth wrote: > On Thu, 03 May 2012 16:09:15 -0000, Michael Witten wrote: >> On Thu, 03 May 2012 14:23:59 +0200, Hallvard Furuseth wrote: >>> I mean 'git clone --bare bar.git foo.git' does not give foo.git >>> a remote named 'origin' with a branch origin/master. Not sure >>> if there is a _simple_ way to do it well either. init + fetch >>> above does not try to hardlink objects/packs like clone does. >>> >>>> (...) >>>> $ git init bar.git; cd bar.git >>>> $ echo a> a; git add a; git commit -m a; cd .. >>>> $ git clone --bare bar.git foo.git; cd foo.git >>> $ git branch -a >>> * master >> From `git help clone': >> >> --bare >> Make a bare GIT repository. That is, instead of creating >> <directory> and placing the administrative files in >> <directory>/.git, make the<directory> itself the $GIT_DIR. >> This obviously implies the -n because there is nowhere to >> check out the working tree. Also the branch heads at the >> remote are copied directly to corresponding local branch >> heads, without mapping them to refs/remotes/origin/. When >> this option is used, neither remote-tracking branches nor the >> related configuration variables are created. > Yes, I know. I just don't know why. I do. It's because creating a string of repositories is a nuisance in git because of the remote/foo practice. You have to manually fetch and merge at each location. In other systems, the branches are tracked identically. You see master, I see master. The only differences we see are any changes I've created that haven't yet been pushed to you or vice verse. But since git can't handle collisions in the repository the way other systems do, it's forced to use the geographic branch scheme for non-bare repositories. Bare repositories don't have the collision between repository branch and working directory copy in git, so with bare repositories, git can use the identical branch scheme, (although it still refuses colliding pushes). If bare repositories used the triangulation approach of non-bare repositories, then automation would be considerably more complicated. So would repository chaining. What I don't understand is why git chose this less functional architecture over the previously existing practice that doesn't have these limitations, although "because that's what BitKeeper did" might be the sad answer. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 18:26 ` Rich Pixley @ 2012-05-03 19:33 ` Ted Ts'o 0 siblings, 0 replies; 100+ messages in thread From: Ted Ts'o @ 2012-05-03 19:33 UTC (permalink / raw) To: Rich Pixley Cc: Hallvard Breien Furuseth, Michael Witten, Randal L. Schwartz, Sitaram Chamarty, Seth Robertson, git On Thu, May 03, 2012 at 11:26:20AM -0700, Rich Pixley wrote: > > In other systems, the branches are tracked identically. You see > master, I see master. The only differences we see are any changes > I've created that haven't yet been pushed to you or vice verse. But > since git can't handle collisions in the repository the way other > systems do, it's forced to use the geographic branch scheme for > non-bare repositories. Bare repositories don't have the collision > between repository branch and working directory copy in git, so with > bare repositories, git can use the identical branch scheme, > (although it still refuses colliding pushes). I'm still not sure I understand your development workflow. It seems like you are trying to publish multiple branches across to multiple repositories on different machines, so they are visible to different developers? What are all of these branches used for, and why are you doing things this way? (I'm not implying that the reason you have for doing this way is silly or stupid, just that I don't understand it and I don't understand why you feel you need to do things this way.) > What I don't understand is why git chose this less functional > architecture over the previously existing practice that doesn't have > these limitations, although "because that's what BitKeeper did" > might be the sad answer. It's mainly because many git users, including many kernel developers have a set of development workflows which is well suited for how git is set up to work. So git was very much shaped by the development workflows of the early git users --- and it goes the other way, too --- new git features will sometimes cause our development practices and workflow to evolve. So I may have a number of different branches that I'm working on, but in general they stay local to my repository until they are ready to be merged to mainline. If patches need to be reviewed, they either get sent via e-mail to the appropriate mailing list, and the review happens via e-mail, or internally at $WORK, we use Gerrit and we push the change to gerrit where the patches are kept and trackked inside Gerrit, alongside the comments as the patch goes through the review process. (I suspect you are pushing patches out to the repository for review as the patches are getting developed and refined, but I don't know that for sure, since you haven't talked about why you want the particular SCM features that you've been asking for.) Once a patch is fully baked, it goes into a maintainer's repository where it gets pulled into a higher-level maintainer's repository. So in practice a developer's repository has very few branches that he or she needs to export to the outside world, at least as I and other Linux kernel developers typically tend to use git. It's obvious you want to use your DSCM in a different way, and it's not that any particular workflow is right or wrong. But obviously, some tools are a better match for certain workflows as compared to other workflows. Regards, - Ted ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 21:29 ` Rich Pixley 2012-05-01 21:39 ` Randal L. Schwartz @ 2012-05-01 23:30 ` Felipe Contreras 2012-05-03 18:31 ` Rich Pixley 2012-05-03 18:58 ` Rich Pixley 1 sibling, 2 replies; 100+ messages in thread From: Felipe Contreras @ 2012-05-01 23:30 UTC (permalink / raw) To: Rich Pixley Cc: Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Tue, May 1, 2012 at 11:29 PM, Rich Pixley <rich.pixley@palm.com> wrote: > I'm not asking for anything new. I'm asking for something that's as capable > as what we've had for years now. So you are basically saying; "I want to do X *exactly* like I do it in mercurial, and that's not easy in git". Well, duh, that's because git is not mercurial. Why don't you do it the _git way_? That would be easy. Show all the hg commands of what you are trying to do, and we can show you how you can achieve the same in git, but much more easily. -- Felipe Contreras ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 23:30 ` Felipe Contreras @ 2012-05-03 18:31 ` Rich Pixley 2012-05-03 18:58 ` Rich Pixley 1 sibling, 0 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-03 18:31 UTC (permalink / raw) To: Felipe Contreras Cc: Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/1/12 16:30 , Felipe Contreras wrote: > On Tue, May 1, 2012 at 11:29 PM, Rich Pixley<rich.pixley@palm.com> wrote: > >> I'm not asking for anything new. I'm asking for something that's as capable >> as what we've had for years now. > So you are basically saying; "I want to do X *exactly* like I do it in > mercurial, and that's not easy in git". Well, no, I'm saying that I want to do it at all, and that's not easy in git. > Well, duh, that's because git is not mercurial. Why don't you do it > the _git way_? That would be easy. That would be great, except that it's not easy. It's a mess. I do have a partial solution now, thanks to the list. It's just a bit messier and non-intuitive since I have to work around the limitations of git. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 23:30 ` Felipe Contreras 2012-05-03 18:31 ` Rich Pixley @ 2012-05-03 18:58 ` Rich Pixley 2012-05-04 14:09 ` Andreas Ericsson 2012-05-04 19:13 ` Felipe Contreras 1 sibling, 2 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-03 18:58 UTC (permalink / raw) To: Felipe Contreras Cc: Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 5/1/12 16:30 , Felipe Contreras wrote: > Show all the hg commands of what you are trying to do, and we can show > you how you can achieve the same in git, but much more easily. hg init foo for i in `yes | head -4000`; do (set -x ; d=`date +%s.%N` ; hg clone foo foo-$d; (cd foo-$d && date > bar && hg add bar && hg ci -m $d)); done for i in foo-*; do (set -x ; (cd $i && hg push -f)); done --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 18:58 ` Rich Pixley @ 2012-05-04 14:09 ` Andreas Ericsson 2012-05-04 14:59 ` Stephen Bash 2012-05-04 19:13 ` Felipe Contreras 1 sibling, 1 reply; 100+ messages in thread From: Andreas Ericsson @ 2012-05-04 14:09 UTC (permalink / raw) To: Rich Pixley Cc: Felipe Contreras, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On 05/03/2012 08:58 PM, Rich Pixley wrote: > On 5/1/12 16:30 , Felipe Contreras wrote: >> Show all the hg commands of what you are trying to do, and we can show >> you how you can achieve the same in git, but much more easily. > hg init foo > for i in `yes | head -4000`; do (set -x ; d=`date +%s.%N` ; hg clone foo foo-$d; (cd foo-$d && date > bar && hg add bar && hg ci -m $d)); done > for i in foo-*; do (set -x ; (cd $i && hg push -f)); done > Here's how that would look in git (though I got rid of the timestamp stuff and used seq instead): git init foo for i in $(seq 1 4000); do git clone foo foo-$i; (cd foo-$i && date > bar && git add bar && git commit -m "$i"; done) for i in foo-*; do (set -x; (cd $i && git push master:$i/master)); done The hg recipe creates 4000 branches which I for some reason can't find the names of so I have no idea how to interact with them. The git recipe names them explicitly to foo-$i/master in the foo/ repo, since git doesn't allow pushing of commits without a ref. Having read further in the thread, I see you did "hg merge" to merge *all* the branches (which is impressive in itself, doing a 4000-way merge), but I still don't see how you'd go about merging just one of them. Perhaps that's not desirable. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 14:09 ` Andreas Ericsson @ 2012-05-04 14:59 ` Stephen Bash 2012-05-04 16:29 ` Mark Brown 0 siblings, 1 reply; 100+ messages in thread From: Stephen Bash @ 2012-05-04 14:59 UTC (permalink / raw) To: Andreas Ericsson Cc: Felipe Contreras, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git, Rich Pixley ----- Original Message ----- > From: "Andreas Ericsson" <ae@op5.se> > Sent: Friday, May 4, 2012 10:09:30 AM > Subject: Re: Newbie grief > > On 05/03/2012 08:58 PM, Rich Pixley wrote: > > On 5/1/12 16:30 , Felipe Contreras wrote: > > > Show all the hg commands of what you are trying to do, and we can > > > show you how you can achieve the same in git, but much more > > > easily. > > > > hg init foo > > for i in `yes | head -4000`; do (set -x ; d=`date +%s.%N` ; hg > > clone foo foo-$d; (cd foo-$d && date > bar && hg add bar && hg ci > > -m $d)); done > > for i in foo-*; do (set -x ; (cd $i && hg push -f)); done > > ... snip ... > > The hg recipe creates 4000 branches which I for some reason can't > find the names of so I have no idea how to interact with them. The > git recipe names them explicitly to foo-$i/master in the foo/ repo, > since git doesn't allow pushing of commits without a ref. If my hg-foo isn't too out of date... The hg recipe creates 4000 "heads" on a single branch, rather than 4000 branches (see the 'hg heads' command). This is basically the point Rich is arguing I believe. hg allows for multiple tip commits all with the same branch name (IMO this is important because hg branch names are permanently recorded in their version of the commit object). This is a *fundamental* difference in the implementation of the two tools (and causes confusion because now "branch" has two slightly different meanings). However, IMHO, philosophically it all boils down to the same thing: development has forked and has to be merged. Whether that fork has a name or not is up to the tool. In hg it doesn't *have* to have a name (multiple heads per branch), in git it does (single head per branch). I personally find Git's enforcement of naming a good thing: either the change I just made should be incorporated into the original branch, or there is a reason for it to stay separate. In the latter case I should name it in a meaningful way so I (and other team members) remember why it is being kept separate (similar to why we use meaningful variable names). In the former, I fetch and then merge or rebase as appropriate before pushing back upstream. HTH, Stephen ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 14:59 ` Stephen Bash @ 2012-05-04 16:29 ` Mark Brown 0 siblings, 0 replies; 100+ messages in thread From: Mark Brown @ 2012-05-04 16:29 UTC (permalink / raw) To: Stephen Bash Cc: Andreas Ericsson, Felipe Contreras, Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git, Rich Pixley On Fri, May 04, 2012 at 10:59:30AM -0400, Stephen Bash wrote: > If my hg-foo isn't too out of date... The hg recipe creates 4000 > "heads" on a single branch, rather than 4000 branches (see the 'hg > heads' command). This is basically the point Rich is arguing I > believe. hg allows for multiple tip commits all with the same branch > name (IMO this is important because hg branch names are permanently > recorded in their version of the commit object). > This is a *fundamental* difference in the implementation of the two > tools (and causes confusion because now "branch" has two slightly > different meanings). However, IMHO, philosophically it all boils down > to the same thing: development has forked and has to be merged. > Whether that fork has a name or not is up to the tool. In hg it > doesn't *have* to have a name (multiple heads per branch), in git it > does (single head per branch). Ah, this makes some sense - I *think* it's coming down not so much that you have to name the branches (googling around it seems hg does assign names, it's just that they're autogenerated numbers) as to the fact that unless you branch directly from wherever your origin repository is git doesn't keep track of where you're ultimately trying to merge development back to. If the above is right then some UI around remotes and branch --track and --set-upstream which provides an automated way of saying "this is a scratch branch for merge into X" and can then do things like helping with merging and enumerating all the scratch branches for a given destination, or with bundling up all the scratch branches and dropping them elsewhere for merge might do the trick? A "strong" branch kind of thing. This does come up a bit with traditional git workflows - I have it a little when working between my desktop and my laptop - but is IME usually resolved by publishing frequently to some central location frequently and then rebasing if lots of local merges aren't approved of in your workflow. git (at least in kernel usage) has more of a "building a patch series" model oriented around preparing things for review. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 18:58 ` Rich Pixley 2012-05-04 14:09 ` Andreas Ericsson @ 2012-05-04 19:13 ` Felipe Contreras 1 sibling, 0 replies; 100+ messages in thread From: Felipe Contreras @ 2012-05-04 19:13 UTC (permalink / raw) To: Rich Pixley Cc: Randal L. Schwartz, Sitaram Chamarty, Ted Ts'o, Seth Robertson, git On Thu, May 3, 2012 at 8:58 PM, Rich Pixley <rich.pixley@palm.com> wrote: > On 5/1/12 16:30 , Felipe Contreras wrote: >> >> Show all the hg commands of what you are trying to do, and we can show >> you how you can achieve the same in git, but much more easily. > > hg init foo > for i in `yes | head -4000`; do (set -x ; d=`date +%s.%N` ; hg clone foo > foo-$d; (cd foo-$d && date > bar && hg add bar && hg ci -m $d)); done > for i in foo-*; do (set -x ; (cd $i && hg push -f)); done Well, that's your problem right there; you are doing something totally stupid. Even the mercurial documentation tells you so: --- By default, push will not allow creation of new heads at the destination, since multiple heads would make it unclear which head to use. In this situation, it is recommended to pull and merge before pushing. --- The git way (which happens to be the mercurial way too), is to fetch and merge (pull) before pushing: do_commit() { (cd $1 && date +%N > bar && git add bar && git commit -m "$2") ;} git init foo; do_commit foo "Initial commit" for i in $(seq 1 10); do git clone foo foo-$i; do_commit foo-$i $i; done for i in foo-*; do (set -x; (cd $i && git pull -s ours --no-edit; git push)); done Do you seriously think it makes sense to have 4000 people doing independent development on 4000 different lines of development all ignoring each other? Which of the 4000 heads would you pick to test this "branch"? Who is going to do the merge of these 4000 heads? This is a recipe for disaster. You prefer a DVCS that allows you to do stupid stuff, well that's your choice, but don't blame git for making it difficult for you to do stupid stuff. You should stop doing that and follow the git/mercurial way; fetch/pull, merge, and push. Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 11:14 ` Ted Ts'o 2012-05-01 16:13 ` Sitaram Chamarty @ 2012-05-01 18:03 ` Rich Pixley 1 sibling, 0 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-01 18:03 UTC (permalink / raw) To: Ted Ts'o; +Cc: Sitaram Chamarty, Seth Robertson, git On 5/1/12 04:14 , Ted Ts'o wrote: > On Tue, May 01, 2012 at 09:14:24AM +0530, Sitaram Chamarty wrote: >> Does Hg do this? That would explain why my (admittedly half-hearted) >> attempts to learn it have failed -- whatever tutorial I used must have >> been written with the idea that hydra branches are intuitive and >> logical and sane, but did not express the concept as clearly and >> succinctly as you did. > > What Hg does is it requires that all terminal commits (commits that do > not have children) must be named by a branch pointer. No more so than git does. It's entirely possible to have commits that have no branch pointer pointing to them. > So when you > pull in some changes from Hg, there may be a non-terminal commit, but > before the hg pull finishes, it will create a merge commit which > merges the current branch pointer and the newly pulled in commits, so > that when you are done, the branch pointer points at the new merge > commit, and the requirement that there be no non-named terminal > commits is maintained. Not so. What happens is that any commit to a non-terminal commit simply succeeds and creates an additional childless commit. If the new commit had a branch pointer, then it continues to have that branch pointer, even if another commit already has that branch pointer. There are just multiple childless commits with that branch pointer. Any merges are initiated manually. But merging any other childless commits is the default for "hg merge". (And merge commits have two parents). The only merges that are done automatically are the same ones that git does on a pull. These are sort of degenerate merges in the sense that they exist entirely in the source code repository graph, there are no lexical or file content collisions. In hg, I can have revision 1 checked out, you can push, (or I can pull), revisions 2, 3, and 4 into my repository, and my next update will merge 2, 3, and 4 into my current working directory, much like with subversion. In git, your push is refused and I can only fetch if I'm also willing to merge at that very moment. > Git differs in that you can have a child commit which is not pointed > to by a branch pointer, and which is referred to only by commit-id. Hg can do this too. > These child commits can disappear on you, when you do a garbage > collection; but it allows you to have multiple child commits hanging > off of a single parent commit, and you can do diffs, cherry picks, > etc. But they *do* have a unique name --- the commit id, which is a > SHA1 hash of the contents of the diff. Same with hg, except that they are persistent and don't disappear on garbage collection. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
[parent not found: <4FA01C73.5000909@palm.com>]
* Re: Newbie grief [not found] ` <4FA01C73.5000909@palm.com> @ 2012-05-02 0:44 ` Sitaram Chamarty 0 siblings, 0 replies; 100+ messages in thread From: Sitaram Chamarty @ 2012-05-02 0:44 UTC (permalink / raw) To: Rich Pixley [I'm going to assume not copying the list on your reply to me was an oversight, since there's nothing in the text to indicate it was supposed to confidential or personal in any way]. [second, sorry about the multiple emails!] On Tue, May 1, 2012 at 10:55 PM, Rich Pixley <rich.pixley@palm.com> wrote: > > On 4/30/12 20:44 , Sitaram Chamarty wrote: >> >> I've been reading the thread with interest. >> >> People who know far more than I do about git, its innards, and its >> design have been responding in this thread so consider this a git >> *user*'s point of view: >> >> On Tue, May 1, 2012 at 6:45 AM, Rich Pixley<rich.pixley@palm.com> wrote: >> >>> Multiple heads are the idea that a single commit can "branch" in the >>> repository and that both commits can be HEADS of the same branch at once >>> in >>> a single repository. This allows a potential collision to exist in the >>> repository and to be pushed and pulled through multiple repositories. >>> It >> >> That is bizarre; I have no other word for it. >> >> I teach git (occasionally), and if this feature existed I would >> totally ignore it in my teaching material because I wouldn't know how >> to defend or explain the need for "hydra branches". >> >> It's like having two people with the same first name *and* last name >> (a situation that is not impossible in real life, but is rare and >> almost always requires special handling). >> >> Does Hg do this? > > Yes, it does. "Hg merge" by default merges a second head into your > current working directory. > > It's a conceptual leap, I concur. Believe me, I'm going through the It's a conceptual leap I can do without; I'm bowing out of this discussion. There's an ambiguity in the branch name now that, to me, is both confusing and unnecessary. It's like each branch name is now an array variable instead of a scalar. We all know when arrays are better than a bunch of similarly named scalars, but in *this* context I don't see why it is needed. The fact that, (in later emails to others), you called this a basic beginning need, or words to that effect, is just icing on top. > reverse cultural shock now that git doesn't have this facility. But it's a > leap whose idea has been around for over 20 years. It wasn't until the > daggy source code control systems like monotone showed up that it became > practical, but that was a decade ago now. > > The big win, of course, is that we can both push to the same repository, > (and through multiple repositories), and we can decide later whether we want > to merge or branch permanently. > >> That would explain why my (admittedly half-hearted) >> attempts to learn it have failed -- whatever tutorial I used must have >> been written with the idea that hydra branches are intuitive and >> logical and sane, but did not express the concept as clearly and >> succinctly as you did. >> >> Thanks for this insight; my next attempt to understand Hg, should I >> ever be forced into it, might actually succeed! > > It's really pretty simple. Your commit, (or push, or pull), always > succeeds, even if it's not at the tip of a branch. If it's not at the tip > of a branch, then it creates a new tip. > > The word "head" here is problematic since git uses it in a totally > different way. In git, "HEAD" refers to whatever commit is currently > checked out. In hg, "head" refers to a childless commit. It doesn't even > need to be on a named branch. > > --rich -- Sitaram ^ permalink raw reply [flat|nested] 100+ messages in thread
[parent not found: <4F9F28F5.2020403@palm.com>]
* Re: Newbie grief [not found] ` <4F9F28F5.2020403@palm.com> @ 2012-05-01 1:37 ` Seth Robertson 2012-05-01 3:04 ` Rich Pixley 0 siblings, 1 reply; 100+ messages in thread From: Seth Robertson @ 2012-05-01 1:37 UTC (permalink / raw) To: Rich Pixley; +Cc: git In message <4F9F28F5.2020403@palm.com>, Rich Pixley writes: On 4/30/12 16:31 , Seth Robertson wrote: > It seems that git is allergic to the dual head branch solution or > something, which is surprising and disappointing. > > Git tracks your version of master separately from each other remote's > master. This is exactly dual/multiple heads. No, it isn't at all. Multiple heads are the idea that a single commit can "branch" in the repository and that /both /commits can be HEADS of the same branch at once in a single repository. This allows a potential collision to exist in the repository and to be pushed and pulled through multiple repositories. It also largely eliminates this entire discussion since each of the intermediate repositories between, say, you and I can carry the collision. Either you or I, at will, can merge these heads just like we'd merge any other two commits, push, etc. That would seem to be the obvious and intuitive behavior, not arbitrarily preventing the transfer. I still don't see how git isn't providing this to you, with the caveat that in git, a single commit with a specific SHA1 hash is constant. You may modify it (making it a new commit), modify its history (making it a new commit), or add new commits after it. Git doesn't number commits the way other VCS do, which may be the source of confusion. A specific commit with a specific SHA1 can be at the head of multiple branches. Those branch may be local to the repository, local tracking branches, or remote tracking branches. Contrarywise, the head of the "master" (or any) branch (or ref) may point to any SHA1. My master branch may point to one SHA1, yours may point to another. You can look at my version of master and I can look at your version of master (permissions permitting). After appropriate network operations, either you, or I, at will, can merge these heads just like we'd merge any other two commits, push, etc. With appropriate naming conventions, we can even continue parallel updates where I can make updates to your version of master and you can make updates to my version of master, in addition to our own. For example, in the diagram http://mercurial.selenic.com/wiki/Head rev2 might be your version of master and rev3 might be my version. Both might exist in my repository and both might exist in your repository, and both might have the symbolic name "master" associated with it, and git would keep it entirely straight. > What git *does* forbid > (by default) is: > > 1: Letting you update someone else's checked out (non-bare) repository > underneath them Yeah. That "underneath them" thing is confusing. I don't see any reason why that should necessarily be so. Git knows what commit is checked out. That's HEAD, yes? So what's wrong with letting it collect other commits from other repositories while your working directory sits? It does! It can! What is forbidden is for me update what you have checked out. Can you conceive of a revision control system where I commit I would make would change what you have checked out? (Well, I can, ClearCase with dynamic views, and it is more horrible than you can imagineâI've had compile fail because the files changed underneath my feet between the start of the compile and the end of the compile). And what happens if the file I changed is also the file you are in the middle of changing? Is your change going to overwrite mine? Is mine going to overwrite yours? This way leads to insanity. You can always commit your change right on top of what's checked out, creating a second head for that branch. With git, you must always commit your change right on top of what's checked out, though of course you may decide to change what's checked out and "float" the changes you made over to the new head (trivial, as long as there are not conflicts between the two heads and the changes you made). However, only the user of the repository is allowed to do this. A remote user is not allowed to change what's checked out. Yes, I've read that git-diff, etc, are all making assumptions that fail in this case, but there's nothing significantly different about collecting commits to other branches and collecting commits to the branch you're currently checked out from. Yes there is. Consider this use case. You can I both spot DIFFERENT bugs. You and I both start editing filea. I fix my problem one way which involves lines 10, 100, and 500, you fix your problem which involves line 10, 100, and 200. I'm typing faster than you so I commit/push first. If I can update your HEAD, at that point I've changed the file you are editing. You save and my change is lost. Now this is where you say, if git only supported multiple HEADs the problem would go away. I could update my version of master and you could update your version of master and there would be no conflict. And...of course you can with git. I don't update your master, what you have checked out, I update what you know is my master. Then when you are done, you get to say "merge my master with your master" or "instead of committing this change on my branch, let me try this last change I made on top of the changes you made" or whatever you want to say. > 2: Letting you update someone else's repository if they have more > recent changes than you do. Again, if they have more recent changes, then my line of changes should create a fresh HEAD on that branch. Then the repositories hold all of our changes to be merged at our leisure. And...git does this. Your changes are made on your HEAD (your branch). My changes are made on my HEAD (my branch). Never the twain shall meet until someone says "merge" (or "rebase"). The key to all of this is the namespace naming convention. refs/remotes/<remotename>/<branchname> (or more informally <remotename>/<branchname>) is a remote tracking branch, or my idea of what your branches (HEADs) currently are. These are (kinda/sorta) read-only reference which are only updated when you specifically ask them to be updated, or if I decide to update what you believe I have (kinda rude, but allowed). So let us consider a specific example. There is a repository which everyone call's "Rich" (they don't need to use the same name, but it reduces confusion), a repository everyone calls "Seth", and a central repository everyone calls "origin". Location Branchname -------- ---------- origin foo (bare) rodger foo rodger origin/foo rodger seth/foo seth foo seth origin/foo seth rodger/foo I make a change in my foo. I can push the change into origin's foo, rodger's seth/foo (and technically origin/foo but that is more than just rude). You can take my change and store it in seth/foo. At any point, after you have the changes (either because I push them or you fetch them) you can then merge your work with my work. So...what's not possible? -Seth Robertson ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 1:37 ` Seth Robertson @ 2012-05-01 3:04 ` Rich Pixley 2012-05-01 5:32 ` Michael Witten 0 siblings, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-01 3:04 UTC (permalink / raw) To: Seth Robertson; +Cc: git On 4/30/12 18:37 , Seth Robertson wrote: > For example, in the diagram http://mercurial.selenic.com/wiki/Head > rev2 might be your version of master and rev3 might be my version. > Both might exist in my repository and both might exist in your > repository, and both might have the symbolic name "master" associated > with it, and git would keep it entirely straight. But not in the same repository. And therein lies the issue. > > What git *does* forbid > > (by default) is: > > > > 1: Letting you update someone else's checked out (non-bare) repository > > underneath them > Yeah. That "underneath them" thing is confusing. I don't see any > reason why that should necessarily be so. > > Git knows what commit is checked out. That's HEAD, yes? So what's > wrong with letting it collect other commits from other repositories > while your working directory sits? > > It does! It can! To the branch you have checked out? That's what I want! How do I do that? > What is forbidden is for me update what you have > checked out. There's some ambiguity in your sentence here. I don't know whether you're referring to my being forbidden from modifying your working directory or whether you're referring my being forbidden to modify the branch from which your working directory is checked out. I understand and respect the former, but the latter seems arbitrary. (I think clearcase already answered the dynamic update problem. I liked it. And I especially liked clearmake and build avoidance. Shame that IBM killed it. (Oh, and if you had inconsistent builds, then you weren't using clearmake. Clearmake solved that problem.)) I'm less concerned about whether my push changes your working directory. I'm fine with leaving your working directory as is and letting you decide when and how to move forward on your own time. Perhaps part of the problem here is the unfortunate choice of the word "HEAD" to refer to the thing you have checked out when that commit might not be a childless commit at all. When I say "create another head" I mean, "create a childless commit on the same branch". > You can always commit your change right on top of what's checked > out, creating a second head for that branch. > > With git, you must always commit your change right on top of what's > checked out, though of course you may decide to change what's checked > out and "float" the changes you made over to the new head (trivial, as > long as there are not conflicts between the two heads and the changes > you made). However, only the user of the repository is allowed to do > this. A remote user is not allowed to change what's checked out. Ok, how do I ask git to push a commit into the middle of a branch that you have checked out at a tip, (there's always exactly one tip for any branch in git, right?)? I don't care to change your working directory nor your index. I just want my commits to show up in the middle of that branch. > Yes, I've read that git-diff, etc, are all making assumptions that fail > in this case, but there's nothing significantly different about > collecting commits to other branches and collecting commits to the > branch you're currently checked out from. > > Yes there is. Consider this use case. You can I both spot DIFFERENT > bugs. You and I both start editing filea. I fix my problem one way > which involves lines 10, 100, and 500, you fix your problem which > involves line 10, 100, and 200. I'm typing faster than you so I > commit/push first. If I can update your HEAD, at that point I've > changed the file you are editing. You save and my change is lost. "HEAD", being defined as the thing I have checked out, should not be changed, I agree. But the nomenclature here is a bit misleading. Really, "HEAD" could be any commit. It doesn't have to be a childless commit. The fact that my HEAD was childless at the time I checked it out doesn't necessarily mean that it must remain childless forever. Let's back it up a moment. I change file1 and you change file2. These are non-colliding changes. They can be trivially merged and yet git refuses to push between our repositories. The refusal seems arbitrary. It could just as easily accept my change, leave your HEAD pointing where it was, but move the "master" pointer to point to the merged commit. This is exactly what it does if I pull your changes into my repository. I just can't ever push them again after this happens. (I could push them previously.) > Now this is where you say, if git only supported multiple HEADs the > problem would go away. Right. > I could update my version of master and you > could update your version of master and there would be no conflict. There'd be a conflict. But we'd be able to update anyway. I'd be able to see your changes in my repository by default. You'd be able to see mine. And either one of us could merge, commit, and push the merge. Until then, the collision could be carried and propagated by multiple repositories around our repository network. Maybe a third person would integrate them for us. > And...of course you can with git. I don't update your master, what > you have checked out, I update what you know is my master. Then when > you are done, you get to say "merge my master with your master" or > "instead of committing this change on my branch, let me try this last > change I made on top of the changes you made" or whatever you want to > say. Yes. And I have no choice. I must say that at every repository I own, every time I push or pull changes, tracking whether those have been merged or not, even when 99% of my changes could have been trivially merged, owned by me, in repositories I own. And I'm forced to do manual merges and extra pulls in the most common collision situation I run into, which can be handled automatically by other systems like mercurial, even subversion. My problem is that I must necessarily manage 10's of repositories for my own work. These extra steps mean a geometric increase in complexity and in error potential over something like mercurial, which maintains the "common branch" illusion automatically for me or something like subversion which genuinely has a common branch. I don't need separate branches for each repository. What I really want is a common branch whose changes I can push back and forth between the various repositories, or coordinate through a central cache, without worrying about the underlying details that git is forcing me to confront. I think I'm beginning to understand what git does offer now. Thank you for the help with clarifications. I just don't like it. It's a huge let down for me in my context from working with systems like mercurial which make my life easier. Quite frankly, git is a huge amount of work for me by comparison to mercurial for no added benefit, or even by comparison to subversion, with only minor benefits in most situations over subversion. > So...what's not possible? In effect, any interesting activities involving push or any workflows that require pushing. Most of them can probably be worked around by using a pull architecture instead, but that adds an unnecessary explosion of complexity in many cases such as the one I'm facing. In particular, sharing a branch becomes problematic with git. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 3:04 ` Rich Pixley @ 2012-05-01 5:32 ` Michael Witten 2012-05-01 6:21 ` Junio C Hamano ` (2 more replies) 0 siblings, 3 replies; 100+ messages in thread From: Michael Witten @ 2012-05-01 5:32 UTC (permalink / raw) To: Rich Pixley; +Cc: Seth Robertson, git On Mon, 30 Apr 2012 20:04:25 -0700, Rich Pixley wrote: > I don't need separate branches for each repository. What I really want > is a common branch whose changes I can push back and forth between the > various repositories, or coordinate through a central cache, without > worrying about the underlying details that git is forcing me to confront. Here's a start for a more precise discussion. Sincerely, Michael Witten Cache server: $ git clone --mirror "$uri_for_central_repo" Machine A: $ git clone "$uri_for_cache_repo" $ git checkout -b feature_0 origin/feature_0 $ # ... do some work ... $ git push --set-upstream origin HEAD:shared/feature_0 $ git config push.default upstream Machine B: $ git clone "$uri_for_cache_repo" $ git checkout -b feature_0 origin/feature_0 $ # ... do some work that conflicts with work done on Machine A... $ git push --set-upstream origin HEAD:shared/feature_0 To $uri_for_cache_repo ! [rejected] HEAD -> shared/feature_0 (non-fast-forward) error: failed to push some refs to '$uri_for_cache_repo' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. $ git pull origin shared/feature_0 From $uri_for_cache_repo * branch shared/feature_0 -> FETCH_HEAD Auto-merging a CONFLICT (add/add): Merge conflict in a Recorded preimage for 'a' Automatic merge failed; fix conflicts and then commit the result. $ # ... resolve conflict and commit results ... $ git push --set-upstream origin HEAD:shared/feature_0 $ git config push.default upstream Machine A: $ git pull # pulls in origin's shared/feature_0 $ # ... do some work ... $ git push # pushes to origin's shared/feature_0 Machine B: $ git pull # pulls in origin's shared/feature_0 $ # ... do some work ... $ git push # pushes to origin's shared/feature_0 Machine A: $ git pull $ git remote add central "$uri_for_central_repo" $ git push central HEAD:feature_0 # Assume there is a conflict To $uri_for_central_repo ! [rejected] HEAD -> feature_0 (non-fast-forward) error: failed to push some refs to '$uri_for_central_repo' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. $ git pull central feature_0 $ # ... resolve conflict and commit results ... $ git push central HEAD:feature_0 # Assume it succeeds this time $ # Let's update the cache repo from Machine A: $ git fetch central $ git push origin 'refs/remotes/central/*:refs/heads/*' Machine B: $ git pull $ git pull . origin/feature_0 # Get new stuff cached from central server ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 5:32 ` Michael Witten @ 2012-05-01 6:21 ` Junio C Hamano 2012-05-01 6:24 ` Michael Witten 2012-05-01 17:29 ` Rich Pixley 2012-05-01 17:33 ` Rich Pixley 2012-05-03 19:13 ` Rich Pixley 2 siblings, 2 replies; 100+ messages in thread From: Junio C Hamano @ 2012-05-01 6:21 UTC (permalink / raw) To: Michael Witten; +Cc: Rich Pixley, Seth Robertson, git Michael Witten <mfwitten@gmail.com> writes: > Here's a start for a more precise discussion. When does the "Cache server" updated from the "$uri_for_central_repo" in this picture? If it is after push by either from Machine A or B, somebody needs to reconcile that and whatever A/B pushed. And between Hg style "split head" or Git style refs/remotes/* namespaces there is no difference to perform that reconcilation. Somebody needs to run "merge" on the "Cache server" and at some point the result needs to be pushed to the $uri_for_central_repo back. So... ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 6:21 ` Junio C Hamano @ 2012-05-01 6:24 ` Michael Witten 2012-05-01 17:29 ` Rich Pixley 1 sibling, 0 replies; 100+ messages in thread From: Michael Witten @ 2012-05-01 6:24 UTC (permalink / raw) To: Junio C Hamano; +Cc: Rich Pixley, Seth Robertson, git On Tue, May 1, 2012 at 06:21, Junio C Hamano <gitster@pobox.com> wrote: > Michael Witten <mfwitten@gmail.com> writes: > >> Here's a start for a more precise discussion. > > When does the "Cache server" updated from the "$uri_for_central_repo" in > this picture? If it is after push by either from Machine A or B, somebody > needs to reconcile that and whatever A/B pushed. > > And between Hg style "split head" or Git style refs/remotes/* namespaces > there is no difference to perform that reconcilation. Somebody needs to > run "merge" on the "Cache server" and at some point the result needs to be > pushed to the $uri_for_central_repo back. > > So... Examples of pushing to the central repo and updating the cache repo are given at the bottom. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 6:21 ` Junio C Hamano 2012-05-01 6:24 ` Michael Witten @ 2012-05-01 17:29 ` Rich Pixley 1 sibling, 0 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-01 17:29 UTC (permalink / raw) To: Junio C Hamano; +Cc: Michael Witten, Seth Robertson, git On 4/30/12 23:21 , Junio C Hamano wrote: > Michael Witten<mfwitten@gmail.com> writes: > >> Here's a start for a more precise discussion. > When does the "Cache server" updated from the "$uri_for_central_repo" in > this picture? If it is after push by either from Machine A or B, somebody > needs to reconcile that and whatever A/B pushed. > > And between Hg style "split head" or Git style refs/remotes/* namespaces > there is no difference to perform that reconcilation. Somebody needs to > run "merge" on the "Cache server" and at some point the result needs to be > pushed to the $uri_for_central_repo back. Untrue. In the hg style, the reconciliation can happen at any repository. Or never. It's completely legitimate to allow this "split head" to become the beginning of a de facto branch. The only difference between a "split head" and a branch is whether the same branch pointer points to both or whether they have different branch pointers. They can even have both. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 5:32 ` Michael Witten 2012-05-01 6:21 ` Junio C Hamano @ 2012-05-01 17:33 ` Rich Pixley 2012-05-03 19:13 ` Rich Pixley 2 siblings, 0 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-01 17:33 UTC (permalink / raw) To: Michael Witten; +Cc: Seth Robertson, git On 4/30/12 22:32 , Michael Witten wrote: > On Mon, 30 Apr 2012 20:04:25 -0700, Rich Pixley wrote: > >> I don't need separate branches for each repository. What I really want >> is a common branch whose changes I can push back and forth between the >> various repositories, or coordinate through a central cache, without >> worrying about the underlying details that git is forcing me to confront. > Here's a start for a more precise discussion. Thank you. That might be just what I need in git. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-01 5:32 ` Michael Witten 2012-05-01 6:21 ` Junio C Hamano 2012-05-01 17:33 ` Rich Pixley @ 2012-05-03 19:13 ` Rich Pixley 2012-05-03 20:19 ` Ronan Keryell ` (2 more replies) 2 siblings, 3 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-03 19:13 UTC (permalink / raw) To: Michael Witten; +Cc: Seth Robertson, git On 4/30/12 22:32 , Michael Witten wrote: > On Mon, 30 Apr 2012 20:04:25 -0700, Rich Pixley wrote: > >> I don't need separate branches for each repository. What I really want >> is a common branch whose changes I can push back and forth between the >> various repositories, or coordinate through a central cache, without >> worrying about the underlying details that git is forcing me to confront. > > Here's a start for a more precise discussion. > > Sincerely, > Michael Witten > > > Cache server: > > $ git clone --mirror "$uri_for_central_repo" > > Machine A: > > $ git clone "$uri_for_cache_repo" > $ git checkout -b feature_0 origin/feature_0 > $ # ... do some work ... > $ git push --set-upstream origin HEAD:shared/feature_0 > $ git config push.default upstream > > Machine B: > > $ git clone "$uri_for_cache_repo" > $ git checkout -b feature_0 origin/feature_0 > $ # ... do some work that conflicts with work done on Machine A... > $ git push --set-upstream origin HEAD:shared/feature_0 > To $uri_for_cache_repo > ! [rejected] HEAD -> shared/feature_0 (non-fast-forward) > error: failed to push some refs to '$uri_for_cache_repo' > To prevent you from losing history, non-fast-forward updates were rejected > Merge the remote changes (e.g. 'git pull') before pushing again. See the > 'Note about fast-forwards' section of 'git push --help' for details. > $ git pull origin shared/feature_0 > From $uri_for_cache_repo > * branch shared/feature_0 -> FETCH_HEAD > Auto-merging a > CONFLICT (add/add): Merge conflict in a > Recorded preimage for 'a' > Automatic merge failed; fix conflicts and then commit the result. > $ # ... resolve conflict and commit results ... > $ git push --set-upstream origin HEAD:shared/feature_0 > $ git config push.default upstream > > Machine A: > > $ git pull # pulls in origin's shared/feature_0 > $ # ... do some work ... > $ git push # pushes to origin's shared/feature_0 > > Machine B: > > $ git pull # pulls in origin's shared/feature_0 > $ # ... do some work ... > $ git push # pushes to origin's shared/feature_0 > > Machine A: > > $ git pull > $ git remote add central "$uri_for_central_repo" > $ git push central HEAD:feature_0 # Assume there is a conflict > To $uri_for_central_repo > ! [rejected] HEAD -> feature_0 (non-fast-forward) > error: failed to push some refs to '$uri_for_central_repo' > To prevent you from losing history, non-fast-forward updates were rejected > Merge the remote changes (e.g. 'git pull') before pushing again. See the > 'Note about fast-forwards' section of 'git push --help' for details. > $ git pull central feature_0 > $ # ... resolve conflict and commit results ... > $ git push central HEAD:feature_0 # Assume it succeeds this time > $ # Let's update the cache repo from Machine A: > $ git fetch central > $ git push origin 'refs/remotes/central/*:refs/heads/*' > > Machine B: > > $ git pull > $ git pull . origin/feature_0 # Get new stuff cached from central server This is probably what I'm going to end up using. Just for comparison, here's a similar process in hg. Cache server: $ hg clone $uri_for_central_repo Machine A: $ hg clone $uri_for_cache_repo $ # ...do some work... $ hg push Machine B: $ hg clone $uri_for_cache_repo $ # ...do some work... $ hg push # assume this collides pushing to $uri_for_cache_repo searching for changes abort: push creates new remote head 6d2eb0a6a278! (you should pull and merge or use push -f to force) $ hg push -f # the pull and merge case parallels git, so let's use push -f. Any repo: $ hg pull # pulls in all changes including the dual heads $ hg merge # collapses the dual heads $ hg commit # commits the merge $ hg push Machine A: $ hg pull # pulls in all changes so far $ hg up $ #... do some work ... $ hg push Machine B $ hg pull $ hg up $ # ... do some work ... $ hg push Any repo: $ hg pull $uri_to_central_repo $ hg merge $ hg push $uri_to_central_repo $ hg push # default is cache repo Machine B: $ hg pull Some Conclusions: * the work flows are similar. * the hg commands are simpler and have the defaults that we want, primarily because no extra branches are required. * the hg error messages are straightforward, clear, and don't require any deep knowledge of the source code control system or it's limitations. (I still don't understand what the git message on collision is saying.) * hg has more options about how to handle the collisions or the merges. While git can mimic some of those options, doing so requires a priori knowledge that isn't stored in the source code control system and therefor requires a human exchange which is optional with hg. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 19:13 ` Rich Pixley @ 2012-05-03 20:19 ` Ronan Keryell 2012-05-03 21:13 ` Junio C Hamano 2012-05-04 18:57 ` Jérôme Benoit 2012-05-04 20:03 ` Felipe Contreras 2 siblings, 1 reply; 100+ messages in thread From: Ronan Keryell @ 2012-05-03 20:19 UTC (permalink / raw) To: Rich Pixley; +Cc: git >>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich Pixley <rich.pixley@palm.com> said: Rich> * the hg error messages are straightforward, clear, and don't Rich> require any deep knowledge of the source code control system Rich> or it's limitations. (I still don't understand what the git Rich> message on collision is saying.) This is a very good suggestion. This would help people not having time to embrace all the advanced details to understand easily what is happening. At least, print a simpler message with some typical use case causing this and some workflow ideas before the detailed explanation. Or adding a new config message.style = expert | newbie | ... and of course with newbie by default. :-) -- Ronan KERYELL |\/ Phone: +1 408 658 9453 Wild Systems / HPC Project |/) 5201 Great America Parkway, Suite 320 K Ronan.Keryell@wild-systems.com Santa Clara, CA 95054 |\ skype:keryell USA | \ http://wild-systems.com ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 20:19 ` Ronan Keryell @ 2012-05-03 21:13 ` Junio C Hamano 2012-05-03 22:23 ` Ronan Keryell 2012-05-03 22:33 ` Rich Pixley 0 siblings, 2 replies; 100+ messages in thread From: Junio C Hamano @ 2012-05-03 21:13 UTC (permalink / raw) To: Ronan Keryell; +Cc: Rich Pixley, git Ronan Keryell <Ronan.Keryell@hpc-project.com> writes: >>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich Pixley <rich.pixley@palm.com> said: > > Rich> * the hg error messages are straightforward, clear, and don't > Rich> require any deep knowledge of the source code control system > Rich> or it's limitations. (I still don't understand what the git > Rich> message on collision is saying.) > > This is a very good suggestion. > ... > At least, print a simpler message with some typical use case causing > this and some workflow ideas before the detailed explanation. It indeed is a good starting point to make a suggestion, but there is nothing actionable in the above by itself, especially since "typical use case" is quite different for different Git users. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 21:13 ` Junio C Hamano @ 2012-05-03 22:23 ` Ronan Keryell 2012-05-03 22:33 ` Rich Pixley 1 sibling, 0 replies; 100+ messages in thread From: Ronan Keryell @ 2012-05-03 22:23 UTC (permalink / raw) To: Junio C Hamano; +Cc: git >>>>> On Thu, 03 May 2012 14:13:40 -0700, Junio C Hamano <gitster@pobox.com> said: >> This is a very good suggestion. ... At least, print a simpler >> message with some typical use case causing this and some workflow >> ideas before the detailed explanation. Junio> It indeed is a good starting point to make a suggestion, but Junio> there is nothing actionable in the above by itself, Junio> especially since "typical use case" is quite different for Junio> different Git users. Right. Just add a new git config entry defining "typical use case". :-) And we can recurse to define what is the default value of this and so on... :-) Just to be constructive, in the previous case, adding something like "It appears that you are trying to push some modifications on a remote server on a branch that has been updated. It may be due to someone having worked on it in the meantime. To go on, you may first do a git merge .... <automatically generated> and try again after solving this so that we are able to precisely track the real history of your project." The last sentence is to motivate the user to do what may be complicated when coming from, say, SVN, and who do not really care with... real history. ;-) Well I'm not a native English speaker, but I hope you can get the idea. After that, there are some other use cases, but I'm not sure that in this case this kind of message would help, because you may have some deeper knowledge of git anyway. For example for my software testing infrastructure, I push some stuff on some remote git and I force the update of the remote branch anyway with a git push -f. If I forgot the '-f' I would have the same error message above that would not be helpful for me. But anyway, this message is not needed since I use git for my very own specific purpose in this case. -- Ronan KERYELL |\/ Phone: +1 408 658 9453 Wild Systems / HPC Project |/) 5201 Great America Parkway, Suite 320 K Ronan.Keryell@wild-systems.com Santa Clara, CA 95054 |\ skype:keryell USA | \ http://wild-systems.com ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 21:13 ` Junio C Hamano 2012-05-03 22:23 ` Ronan Keryell @ 2012-05-03 22:33 ` Rich Pixley 2012-05-03 22:39 ` Rich Pixley 1 sibling, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-03 22:33 UTC (permalink / raw) To: Junio C Hamano; +Cc: Ronan Keryell, git On 5/3/12 14:13 , Junio C Hamano wrote: > Ronan Keryell<Ronan.Keryell@hpc-project.com> writes: >>>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich Pixley<rich.pixley@palm.com> said: >> Rich> * the hg error messages are straightforward, clear, and don't >> Rich> require any deep knowledge of the source code control system >> Rich> or it's limitations. (I still don't understand what the git >> Rich> message on collision is saying.) >> >> This is a very good suggestion. >> ... >> At least, print a simpler message with some typical use case causing >> this and some workflow ideas before the detailed explanation. > It indeed is a good starting point to make a suggestion, but there is > nothing actionable in the above by itself, especially since "typical use > case" is quite different for different Git users. How about, "Your push can't be made because it would cause an irreconcilable collision. You probably want to pull and merge before attempting to push again." --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 22:33 ` Rich Pixley @ 2012-05-03 22:39 ` Rich Pixley 2012-05-04 1:01 ` Illia Bobyr 0 siblings, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-03 22:39 UTC (permalink / raw) To: Junio C Hamano; +Cc: Ronan Keryell, git On 5/3/12 15:33 , Rich Pixley wrote: > On 5/3/12 14:13 , Junio C Hamano wrote: >> Ronan Keryell<Ronan.Keryell@hpc-project.com> writes: >>>>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich Pixley<rich.pixley@palm.com> said: >>> Rich> * the hg error messages are straightforward, clear, and don't >>> Rich> require any deep knowledge of the source code control system >>> Rich> or it's limitations. (I still don't understand what the git >>> Rich> message on collision is saying.) >>> >>> This is a very good suggestion. >>> ... >>> At least, print a simpler message with some typical use case causing >>> this and some workflow ideas before the detailed explanation. >> It indeed is a good starting point to make a suggestion, but there is >> nothing actionable in the above by itself, especially since "typical use >> case" is quite different for different Git users. > How about, "Your push can't be made because it would cause an > irreconcilable collision. You probably want to pull and merge before > attempting to push again." Er... "Your push can't be made because it would cause an irreconcilable collision. You probably want to fetch and merge before attempting to push again." --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 22:39 ` Rich Pixley @ 2012-05-04 1:01 ` Illia Bobyr 2012-05-04 3:13 ` Nathan Gray 0 siblings, 1 reply; 100+ messages in thread From: Illia Bobyr @ 2012-05-04 1:01 UTC (permalink / raw) To: Rich Pixley; +Cc: Ronan Keryell, git On 5/3/2012 3:39 PM, Rich Pixley wrote: > On 5/3/12 15:33 , Rich Pixley wrote: >> On 5/3/12 14:13 , Junio C Hamano wrote: >>> Ronan Keryell<Ronan.Keryell@hpc-project.com> writes: >>>>>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich >>>>>>>>> Pixley<rich.pixley@palm.com> said: >>>> Rich> * the hg error messages are straightforward, clear, >>>> and don't >>>> Rich> require any deep knowledge of the source code control >>>> system >>>> Rich> or it's limitations. (I still don't understand what >>>> the git >>>> Rich> message on collision is saying.) >>>> >>>> This is a very good suggestion. >>>> ... >>>> At least, print a simpler message with some typical use case causing >>>> this and some workflow ideas before the detailed explanation. >>> It indeed is a good starting point to make a suggestion, but there is >>> nothing actionable in the above by itself, especially since "typical >>> use >>> case" is quite different for different Git users. >> How about, "Your push can't be made because it would cause an >> irreconcilable collision. You probably want to pull and merge before >> attempting to push again." > > Er... "Your push can't be made because it would cause an > irreconcilable collision. You probably want to fetch and merge before > attempting to push again." While this error message makes more sense to you at this point it is not entirely true. The collision is not irreconcilable and may not even be a collision. For example, if you just rebased, it is not a collision from a more abstract point of view. It is just a "non-fast forward" move of a branch tip. This term describes what happens precisely :) It is true, that the term is non obvious to the new comers. One may google and get an explanation of the error pretty quickly. First hit for "git non fast forward error" gives an explanation from a new comer point of view for the simplest case. Another option is to change the way git "talks". AFAIR there were a number of attempts to come up with a new dictionary for git. I am not sure if any of the attempts were complete as it is not that easy. Changing just one error message at a time would make it less consistent as a concept of "fast forward" moves is used in other places. For example, git merge has --ff and --no-ff options that stand for "fast forwrad" and "no fast forward" respectively. Illia Bobyr ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 1:01 ` Illia Bobyr @ 2012-05-04 3:13 ` Nathan Gray 2012-05-04 4:35 ` Michael Witten 2012-05-04 19:18 ` Andrew Sayers 0 siblings, 2 replies; 100+ messages in thread From: Nathan Gray @ 2012-05-04 3:13 UTC (permalink / raw) To: Illia Bobyr; +Cc: Rich Pixley, Ronan Keryell, git On Thu, May 3, 2012 at 6:01 PM, Illia Bobyr <ibobyr@blizzard.com> wrote: > > It is just a "non-fast forward" move of a branch tip. This term > describes what happens precisely :) > > It is true, that the term is non obvious to the new comers. > One may google and get an explanation of the error pretty quickly. > First hit for "git non fast forward error" gives an explanation from a > new comer point of view for the simplest case. I just led a team of reasonably bright people through a transition from SVN to git. Not one of them understood this message. Every one of them thought something was broken. This is a very common occurrence, so a short, simple message without jargon for this error would be a big, big win. Cheers, -n8 -- HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch http://hexalex.com On The App Store: http://bit.ly/8Mj1CU On Facebook: http://bit.ly/9MIJiV On Twitter: http://twitter.com/hexalexgame http://n8gray.org ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 3:13 ` Nathan Gray @ 2012-05-04 4:35 ` Michael Witten 2012-05-04 5:25 ` Junio C Hamano 2012-05-04 17:57 ` Rich Pixley 2012-05-04 19:18 ` Andrew Sayers 1 sibling, 2 replies; 100+ messages in thread From: Michael Witten @ 2012-05-04 4:35 UTC (permalink / raw) To: Nathan Gray; +Cc: Junio C Hamano, Illia Bobyr, Rich Pixley, Ronan Keryell, git On Thu, 3 May 2012 20:13:01 -0700, Nathan Gray wrote: > On Thu, May 3, 2012 at 6:01 PM, Illia Bobyr <ibobyr@blizzard.com> wrote: >> >> It is just a "non-fast forward" move of a branch tip. This term >> describes what happens precisely :) >> >> It is true, that the term is non obvious to the new comers. >> One may google and get an explanation of the error pretty quickly. >> First hit for "git non fast forward error" gives an explanation from a >> new comer point of view for the simplest case. > > I just led a team of reasonably bright people through a transition > from SVN to git. Not one of them understood this message. Every one > of them thought something was broken. This is a very common > occurrence, so a short, simple message without jargon for this error > would be a big, big win. Well, what is your suggestion? Nobody in this thread has yet provided an explicit improvement because the actual complaint is that the vast majority of people (including supposed "professionals") don't RTFM; it never even occurs to them! Let's look at the message in question: To $uri_for_central_repo ! [rejected] HEAD -> feature_0 (non-fast-forward) error: failed to push some refs to '$uri_for_central_repo' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Not only does this already spoonfeed the reader with a suggested command for getting back on track (i.e., 'git pull'), but it also explicitly points out the relevant documentation and HOW to gain immediate access to that information from the command line! As for a seemingly conservative suggestion, how about using a little more structural white space: To $uri_for_central_repo ! [rejected] HEAD -> feature_0 (non-fast-forward) error: failed to push some refs to '$uri_for_central_repo' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Alas! Error output like this is constructed in the code in a way that potentially makes adding such white space non-trivial. Perhaps the error message system needs an overhall; rather than spitting out error messages from anywhere, they ought to be corralled and collated by a dedicated subsystem. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 4:35 ` Michael Witten @ 2012-05-04 5:25 ` Junio C Hamano 2012-05-04 10:09 ` Carlos Martín Nieto 2012-05-04 17:57 ` Rich Pixley 1 sibling, 1 reply; 100+ messages in thread From: Junio C Hamano @ 2012-05-04 5:25 UTC (permalink / raw) To: Michael Witten; +Cc: Nathan Gray, Illia Bobyr, Rich Pixley, Ronan Keryell, git Michael Witten <mfwitten@gmail.com> writes: > As for a seemingly conservative suggestion, how about using a little > more structural white space: > > To $uri_for_central_repo > ! [rejected] HEAD -> feature_0 (non-fast-forward) > > error: failed to push some refs to '$uri_for_central_repo' > > To prevent you from losing history, non-fast-forward updates were rejected > Merge the remote changes (e.g. 'git pull') before pushing again. See the > 'Note about fast-forwards' section of 'git push --help' for details. > > Alas! Error output like this is constructed in the code in a way that > potentially makes adding such white space non-trivial. > > Perhaps the error message system needs an overhall; rather than spitting > out error messages from anywhere, they ought to be corralled and collated > by a dedicated subsystem. Didn't somebody recently rework these messages quite extensively? ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 5:25 ` Junio C Hamano @ 2012-05-04 10:09 ` Carlos Martín Nieto 2012-05-04 14:50 ` Junio C Hamano ` (2 more replies) 0 siblings, 3 replies; 100+ messages in thread From: Carlos Martín Nieto @ 2012-05-04 10:09 UTC (permalink / raw) To: Junio C Hamano Cc: Michael Witten, Nathan Gray, Illia Bobyr, Rich Pixley, Ronan Keryell, git [-- Attachment #1: Type: text/plain, Size: 3025 bytes --] On Thu, 2012-05-03 at 22:25 -0700, Junio C Hamano wrote: > Michael Witten <mfwitten@gmail.com> writes: > > > As for a seemingly conservative suggestion, how about using a little > > more structural white space: > > > > To $uri_for_central_repo > > ! [rejected] HEAD -> feature_0 (non-fast-forward) > > > > error: failed to push some refs to '$uri_for_central_repo' > > > > To prevent you from losing history, non-fast-forward updates were rejected > > Merge the remote changes (e.g. 'git pull') before pushing again. See the > > 'Note about fast-forwards' section of 'git push --help' for details. > > > > Alas! Error output like this is constructed in the code in a way that > > potentially makes adding such white space non-trivial. > > > > Perhaps the error message system needs an overhall; rather than spitting > > out error messages from anywhere, they ought to be corralled and collated > > by a dedicated subsystem. > > Didn't somebody recently rework these messages quite extensively? If you're thinking of me, I only changed the pull/rebase side, which was a ridiculously bad message. As this subthread looks like it might actually have something actionable, let me look at this message with the same critical eyes. Most of the first sentence repeats what we can see above. Restating that non-ff updates were rejected doesn't add information and doesn't help people who don't already know what a non-ff update is, so it's either redundant or not helpful[0]. So lets see if we can come up with a friendlier way of saying it. Maybe something like: To $uri_for_central_repo ! [rejected] HEAD -> feature_0 (non-fast-forward) error: failed to push some refs to '$uri_for_central_repo' Some updates which might rewrite history and lose someone else's changes were rejected. Merge those changes (e.g. 'git pull') to incorporate that history. See the 'Note about fast-forwards' section of 'git push --help' for details. It may be a bit longer, but if you don't know what a non-ff is or why it's a problem, this text should help you a lot more than the previous one did. Not reading the documentation (specially when the error message points you to a specific section for a longer explanation) is still no excuse for not known what's going on, but if you've been working on your own for a while, you might have forgotten what this is all about.[1] If people don't have it, I'll try to find time to create a patch. cmn [0] Or worse, as repeating jargon can leave the user thinking that they don't understand anything and reduces the chanced they'd try to figure out the missing parts. I'd qualify this with friendliness rather than anything else, as the message isn't wrong or misleading, just rather on-your-face. [1] At least this is show I rationalise why doing saying "non-ff updates rejected. Read the ff section of the push manpage for an explanation" isn't the right thing to do. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 10:09 ` Carlos Martín Nieto @ 2012-05-04 14:50 ` Junio C Hamano 2012-05-04 17:39 ` Junio C Hamano 2012-05-04 16:46 ` Nathan Gray 2012-05-04 18:10 ` Rich Pixley 2 siblings, 1 reply; 100+ messages in thread From: Junio C Hamano @ 2012-05-04 14:50 UTC (permalink / raw) To: Carlos Martín Nieto Cc: Michael Witten, Nathan Gray, Illia Bobyr, Rich Pixley, Ronan Keryell, git Carlos Martín Nieto <cmn@elego.de> writes: > On Thu, 2012-05-03 at 22:25 -0700, Junio C Hamano wrote: >> Michael Witten <mfwitten@gmail.com> writes: >> >> > As for a seemingly conservative suggestion, how about using a little >> > more structural white space: >> > >> > To $uri_for_central_repo >> > ! [rejected] HEAD -> feature_0 (non-fast-forward) >> > >> > error: failed to push some refs to '$uri_for_central_repo' >> > >> > To prevent you from losing history, non-fast-forward updates were rejected >> > Merge the remote changes (e.g. 'git pull') before pushing again. See the >> > 'Note about fast-forwards' section of 'git push --help' for details. >> > >> > Alas! Error output like this is constructed in the code in a way that >> > potentially makes adding such white space non-trivial. >> > >> > Perhaps the error message system needs an overhall; rather than spitting >> > out error messages from anywhere, they ought to be corralled and collated >> > by a dedicated subsystem. >> >> Didn't somebody recently rework these messages quite extensively? > > If you're thinking of me,... No, I was referring to f25950f (push: Provide situational hints for non-fast-forward errors, 2012-03-20). ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 14:50 ` Junio C Hamano @ 2012-05-04 17:39 ` Junio C Hamano 0 siblings, 0 replies; 100+ messages in thread From: Junio C Hamano @ 2012-05-04 17:39 UTC (permalink / raw) To: Michael Witten, Nathan Gray, Illia Bobyr Cc: Carlos Martín Nieto, Rich Pixley, Ronan Keryell, git Junio C Hamano <gitster@pobox.com> writes: > Carlos Martín Nieto <cmn@elego.de> writes: > >>> Didn't somebody recently rework these messages quite extensively? >> >> If you're thinking of me,... > > No, I was referring to f25950f (push: Provide situational hints for > non-fast-forward errors, 2012-03-20). If anybody wants to further discuss possible rephrasing of the advice messages, please do not base your discussion without what was discussed already in the previous round and what issues need to be taken into account. A good text to use as the starting point of your discussion is the advice messages in 'master'; use c5da24a (Merge branch 'ct/advise-push-default', 2012-04-20) or anything more recent. Also see http://thread.gmane.org/gmane.comp.version-control.git/193079 for the discussion that led to the current text. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 10:09 ` Carlos Martín Nieto 2012-05-04 14:50 ` Junio C Hamano @ 2012-05-04 16:46 ` Nathan Gray 2012-05-04 17:17 ` Illia Bobyr 2012-05-04 18:10 ` Rich Pixley 2 siblings, 1 reply; 100+ messages in thread From: Nathan Gray @ 2012-05-04 16:46 UTC (permalink / raw) To: Carlos Martín Nieto Cc: Junio C Hamano, Michael Witten, Illia Bobyr, Rich Pixley, Ronan Keryell, git On Fri, May 4, 2012 at 3:09 AM, Carlos Martín Nieto <cmn@elego.de> wrote: > On Thu, 2012-05-03 at 22:25 -0700, Junio C Hamano wrote: >> Michael Witten <mfwitten@gmail.com> writes: >> >> > As for a seemingly conservative suggestion, how about using a little >> > more structural white space: >> > >> > To $uri_for_central_repo >> > ! [rejected] HEAD -> feature_0 (non-fast-forward) >> > >> > error: failed to push some refs to '$uri_for_central_repo' >> > >> > To prevent you from losing history, non-fast-forward updates were rejected >> > Merge the remote changes (e.g. 'git pull') before pushing again. See the >> > 'Note about fast-forwards' section of 'git push --help' for details. >> > > > Most of the first sentence repeats what we can see above. Restating that > non-ff updates were rejected doesn't add information and doesn't help > people who don't already know what a non-ff update is, so it's either > redundant or not helpful[0]. So lets see if we can come up with a > friendlier way of saying it. Maybe something like: > > To $uri_for_central_repo > ! [rejected] HEAD -> feature_0 (non-fast-forward) > > error: failed to push some refs to '$uri_for_central_repo' > > Some updates which might rewrite history and lose someone else's > changes were rejected. Merge those changes (e.g. 'git pull') to > incorporate that history. See the 'Note about fast-forwards' section > of 'git push --help' for details. > > It may be a bit longer, but if you don't know what a non-ff is or why > it's a problem, this text should help you a lot more than the previous > one did. Not reading the documentation (specially when the error message > points you to a specific section for a longer explanation) is still no > excuse for not known what's going on, but if you've been working on your > own for a while, you might have forgotten what this is all about.[1] The whitespace that Michael introduced is a big help, for starters, and this rewording is also a nice step forward. I'm still not thrilled about the "rewriting history" verbiage -- that makes it sound like the user did something super risky and was rescued by the system. Here's my suggestion for replacing the last paragraph: Some of your branches are out of date. Merge the remote changes (e.g. 'git pull') then try again. It's short and easy to scan. It has no git-specific jargon that new users would be unfamiliar with. There's no reference to fast-forward updates so no need to refer the user to that help section. What do you think? Cheers, -n8 -- HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch http://hexalex.com On The App Store: http://bit.ly/8Mj1CU On Facebook: http://bit.ly/9MIJiV On Twitter: http://twitter.com/hexalexgame http://n8gray.org ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 16:46 ` Nathan Gray @ 2012-05-04 17:17 ` Illia Bobyr 0 siblings, 0 replies; 100+ messages in thread From: Illia Bobyr @ 2012-05-04 17:17 UTC (permalink / raw) To: Nathan Gray; +Cc: git On 5/4/2012 9:46 AM, Nathan Gray wrote: > On Fri, May 4, 2012 at 3:09 AM, Carlos Martín Nieto<cmn@elego.de> wrote: >> On Thu, 2012-05-03 at 22:25 -0700, Junio C Hamano wrote: >>> Michael Witten<mfwitten@gmail.com> writes: >>> >>>> As for a seemingly conservative suggestion, how about using a little >>>> more structural white space: >>>> >>>> To $uri_for_central_repo >>>> ! [rejected] HEAD -> feature_0 (non-fast-forward) >>>> >>>> error: failed to push some refs to '$uri_for_central_repo' >>>> >>>> To prevent you from losing history, non-fast-forward updates were rejected >>>> Merge the remote changes (e.g. 'git pull') before pushing again. See the >>>> 'Note about fast-forwards' section of 'git push --help' for details. >>>> >> Most of the first sentence repeats what we can see above. Restating that >> non-ff updates were rejected doesn't add information and doesn't help >> people who don't already know what a non-ff update is, so it's either >> redundant or not helpful[0]. So lets see if we can come up with a >> friendlier way of saying it. Maybe something like: >> >> To $uri_for_central_repo >> ! [rejected] HEAD -> feature_0 (non-fast-forward) >> >> error: failed to push some refs to '$uri_for_central_repo' >> >> Some updates which might rewrite history and lose someone else's >> changes were rejected. Merge those changes (e.g. 'git pull') to >> incorporate that history. See the 'Note about fast-forwards' section >> of 'git push --help' for details. >> >> It may be a bit longer, but if you don't know what a non-ff is or why >> it's a problem, this text should help you a lot more than the previous >> one did. Not reading the documentation (specially when the error message >> points you to a specific section for a longer explanation) is still no >> excuse for not known what's going on, but if you've been working on your >> own for a while, you might have forgotten what this is all about.[1] > The whitespace that Michael introduced is a big help, for starters, > and this rewording is also a nice step forward. I'm still not > thrilled about the "rewriting history" verbiage -- that makes it sound > like the user did something super risky and was rescued by the system. > Here's my suggestion for replacing the last paragraph: > > Some of your branches are out of date. Merge the remote changes > (e.g. 'git pull') then try again. > > It's short and easy to scan. It has no git-specific jargon that new > users would be unfamiliar with. There's no reference to fast-forward > updates so no need to refer the user to that help section. What do > you think? Not everybody is a new user :) Throwing away a precise explanation for the purpose of avoiding a possible confusion for someone who either just started (and will have to learn the terms anyway) or for someone who does not really care to learn is a decision that I would weight very carefully. Just as I side note, I lead a team of an ordinary developers through a transition from CVS to Git and there were pretty much fine with the fact that there are pieces in such a complex system as Git that they do not understand immediately. Over a couple of month everyone who cared or required this knowledge knew what a fast-forward is. And people who did not care just learn to do git pull as the message suggests. I think that a reference to the documentation is very nice. I remember that this kind of references allowed me to learn Git gradually as I was facing different usage scenarios instead of reading the whole documentation for all the tools. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 10:09 ` Carlos Martín Nieto 2012-05-04 14:50 ` Junio C Hamano 2012-05-04 16:46 ` Nathan Gray @ 2012-05-04 18:10 ` Rich Pixley 2 siblings, 0 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-04 18:10 UTC (permalink / raw) To: Carlos Martín Nieto Cc: Junio C Hamano, Michael Witten, Nathan Gray, Illia Bobyr, Ronan Keryell, git On 5/4/12 03:09 , Carlos Martín Nieto wrote: > To $uri_for_central_repo > ! [rejected] HEAD -> feature_0 (non-fast-forward) > > error: failed to push some refs to '$uri_for_central_repo' > > Some updates which might rewrite history and lose someone else's > changes were rejected. Merge those changes (e.g. 'git pull') to > incorporate that history. See the 'Note about fast-forwards' section > of 'git push --help' for details. I'd like to suggest "declined" instead of "failed". "error: failed" suggests an error in the data or in the tool rather than a default or a choice on the part of a UI designer. The first few times I got this error I presumed that it was telling me my destination repository was corrupt. So I salvaged my changes with diff and patch, trashed the repository, and cloned a fresh one, (which didn't show this error when I pushed to it.) --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 4:35 ` Michael Witten 2012-05-04 5:25 ` Junio C Hamano @ 2012-05-04 17:57 ` Rich Pixley 2012-05-04 19:22 ` Michael Witten 1 sibling, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-04 17:57 UTC (permalink / raw) To: Michael Witten Cc: Nathan Gray, Junio C Hamano, Illia Bobyr, Ronan Keryell, git On 5/3/12 21:35 , Michael Witten wrote: > On Thu, 3 May 2012 20:13:01 -0700, Nathan Gray wrote: > >> On Thu, May 3, 2012 at 6:01 PM, Illia Bobyr<ibobyr@blizzard.com> wrote: >>> It is just a "non-fast forward" move of a branch tip. This term >>> describes what happens precisely :) >>> >>> It is true, that the term is non obvious to the new comers. >>> One may google and get an explanation of the error pretty quickly. >>> First hit for "git non fast forward error" gives an explanation from a >>> new comer point of view for the simplest case. >> I just led a team of reasonably bright people through a transition >> from SVN to git. Not one of them understood this message. Every one >> of them thought something was broken. This is a very common >> occurrence, so a short, simple message without jargon for this error >> would be a big, big win. > Well, what is your suggestion? > > Nobody in this thread has yet provided an explicit improvement because > the actual complaint is that the vast majority of people (including > supposed "professionals") don't RTFM; it never even occurs to them! > > Let's look at the message in question: > > To $uri_for_central_repo > ! [rejected] HEAD -> feature_0 (non-fast-forward) > error: failed to push some refs to '$uri_for_central_repo' > To prevent you from losing history, non-fast-forward updates were rejected > Merge the remote changes (e.g. 'git pull') before pushing again. See the > 'Note about fast-forwards' section of 'git push --help' for details. > > Not only does this already spoonfeed the reader with a suggested > command for getting back on track (i.e., 'git pull'), but it also > explicitly points out the relevant documentation and HOW to gain > immediate access to that information from the command line! Let's take it line by line. "Rejected - mumble" - the tool did not do what you asked. "error: failed to mumble" - your data is corrupt. "To prevent you mumble mumble" - you're not allowed to do what you want I stopped reading there. I'm not saying this is a correct interpretation. I'm offering it as a data point from a sophisticated, although new, user. I've already offered a suggestion for rewording. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 17:57 ` Rich Pixley @ 2012-05-04 19:22 ` Michael Witten 0 siblings, 0 replies; 100+ messages in thread From: Michael Witten @ 2012-05-04 19:22 UTC (permalink / raw) To: Rich Pixley; +Cc: Nathan Gray, Junio C Hamano, Illia Bobyr, Ronan Keryell, git On Fri, May 4, 2012 at 5:57 PM, Rich Pixley <rich.pixley@palm.com> wrote: > On 5/3/12 21:35 , Michael Witten wrote: >> >> On Thu, 3 May 2012 20:13:01 -0700, Nathan Gray wrote: >> >>> On Thu, May 3, 2012 at 6:01 PM, Illia Bobyr<ibobyr@blizzard.com> wrote: >>>> >>>> It is just a "non-fast forward" move of a branch tip. This term >>>> describes what happens precisely :) >>>> >>>> It is true, that the term is non obvious to the new comers. >>>> One may google and get an explanation of the error pretty quickly. >>>> First hit for "git non fast forward error" gives an explanation from a >>>> new comer point of view for the simplest case. >>> >>> I just led a team of reasonably bright people through a transition >>> from SVN to git. Not one of them understood this message. Every one >>> of them thought something was broken. This is a very common >>> occurrence, so a short, simple message without jargon for this error >>> would be a big, big win. >> >> Well, what is your suggestion? >> >> Nobody in this thread has yet provided an explicit improvement because >> the actual complaint is that the vast majority of people (including >> supposed "professionals") don't RTFM; it never even occurs to them! >> >> Let's look at the message in question: >> >> To $uri_for_central_repo >> ! [rejected] HEAD -> feature_0 (non-fast-forward) >> error: failed to push some refs to '$uri_for_central_repo' >> To prevent you from losing history, non-fast-forward updates were >> rejected >> Merge the remote changes (e.g. 'git pull') before pushing again. See >> the >> 'Note about fast-forwards' section of 'git push --help' for details. >> >> Not only does this already spoonfeed the reader with a suggested >> command for getting back on track (i.e., 'git pull'), but it also >> explicitly points out the relevant documentation and HOW to gain >> immediate access to that information from the command line! > > Let's take it line by line. > > "Rejected - mumble" - the tool did not do what you asked. > "error: failed to mumble" - your data is corrupt. > "To prevent you mumble mumble" - you're not allowed to do what you want > > I stopped reading there. You are not somebody worth helping. > I'm not saying this is a correct interpretation. I'm offering it as a data > point from a sophisticated, although new, user. LOL ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 3:13 ` Nathan Gray 2012-05-04 4:35 ` Michael Witten @ 2012-05-04 19:18 ` Andrew Sayers 1 sibling, 0 replies; 100+ messages in thread From: Andrew Sayers @ 2012-05-04 19:18 UTC (permalink / raw) To: Nathan Gray; +Cc: Illia Bobyr, Rich Pixley, Ronan Keryell, git On 04/05/12 04:13, Nathan Gray wrote: > I just led a team of reasonably bright people through a transition > from SVN to git. Not one of them understood this message. Every one > of them thought something was broken. This is a very common > occurrence, so a short, simple message without jargon for this error > would be a big, big win. Now you come to mention it, I had the same experience a while back. The message could certainly do with improvement, but I think this particular case is more a side-effect of the push.default issue currently being worked through. Beginners expect `git push` to push a single branch, so they see "error" and assume the single branch they pushed must have failed. - Andrew ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 19:13 ` Rich Pixley 2012-05-03 20:19 ` Ronan Keryell @ 2012-05-04 18:57 ` Jérôme Benoit 2012-05-04 20:03 ` Felipe Contreras 2 siblings, 0 replies; 100+ messages in thread From: Jérôme Benoit @ 2012-05-04 18:57 UTC (permalink / raw) To: Rich Pixley; +Cc: git [-- Attachment #1: Type: text/plain, Size: 826 bytes --] On Thu, 03 May 2012 12:13:46 -0700 Rich Pixley <rich.pixley@palm.com> wrote: > * the hg commands are simpler and have the defaults that we want, > primarily because no extra branches are required. You can mimic them with a brand new porclain. For example, the worklfow described here : http://nvie.com/posts/a-successful-git-branching-model/ have been implemented here : https://github.com/nvie/gitflow Since git do not have by design the multi HEAD hg design, you will still not have it but all the glory command chains to mimic it can be done with some shell scripts and a good knowledge of git internals. Regards, -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-03 19:13 ` Rich Pixley 2012-05-03 20:19 ` Ronan Keryell 2012-05-04 18:57 ` Jérôme Benoit @ 2012-05-04 20:03 ` Felipe Contreras 2012-05-04 20:27 ` Junio C Hamano 2 siblings, 1 reply; 100+ messages in thread From: Felipe Contreras @ 2012-05-04 20:03 UTC (permalink / raw) To: Rich Pixley; +Cc: Michael Witten, Seth Robertson, git On Thu, May 3, 2012 at 9:13 PM, Rich Pixley <rich.pixley@palm.com> wrote: > This is probably what I'm going to end up using. > > Just for comparison, here's a similar process in hg. > > Cache server: > > $ hg clone $uri_for_central_repo % git clone $uri_for_central_repo > Machine A: > > $ hg clone $uri_for_cache_repo % git clone $uri_for_cache_repo > $ # ...do some work... > $ hg push % git push > Machine B: > > $ hg clone $uri_for_cache_repo % git clone $uri_for_cache_repo > $ # ...do some work... > $ hg push # assume this collides % git push > pushing to $uri_for_cache_repo > searching for changes > abort: push creates new remote head 6d2eb0a6a278! > (you should pull and merge or use push -f to force) > $ hg push -f # the pull and merge case parallels git, so let's use push -f. This is stupid, why make everybody else's life difficult? Let's merge here. % git pull % git push > Any repo: > > $ hg pull # pulls in all changes including the dual heads % git pull > $ hg merge # collapses the dual heads > $ hg commit # commits the merge > $ hg push No need for this, the guy that diverged did this (Machine B). Plus, what happens if 3 other machines do this? You you have 3 merges, 2 would conflict, and then you would have useless recursive merges, or some people would have to revert. Why bother N people, when one guy can do it at the origin (Machine B)? > Machine A: > > $ hg pull # pulls in all changes so far > $ hg up % git pull > $ #... do some work ... > $ hg push % git push > Machine B > > $ hg pull > $ hg up % git pull > $ # ... do some work ... > $ hg push % git push > Any repo: > > $ hg pull $uri_to_central_repo > $ hg merge % git pull $uri_to_central_repo > $ hg push $uri_to_central_repo % git push $uri_to_central_repo > $ hg push # default is cache repo % git push > Machine B: > > $ hg pull % git pull > Some Conclusions: > > * the work flows are similar. > > * the hg commands are simpler and have the defaults that we want, primarily > because no extra branches are required. Wrong. > * the hg error messages are straightforward, clear, and don't require any > deep knowledge of the source code control system or it's limitations. (I > still don't understand what the git message on collision is saying.) Whatever. I don't care what the error message for a merge conflict actually says, all I need to know is that there was a conflict. > * hg has more options about how to handle the collisions or the merges. > While git can mimic some of those options, doing so requires a priori > knowledge that isn't stored in the source code control system and therefor > requires a human exchange which is optional with hg. WTF? git handles collisions just fine. Actually the git version has less commands. And if configured properly you don't need to specify URLs. Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 20:03 ` Felipe Contreras @ 2012-05-04 20:27 ` Junio C Hamano 2012-05-04 20:45 ` Felipe Contreras 0 siblings, 1 reply; 100+ messages in thread From: Junio C Hamano @ 2012-05-04 20:27 UTC (permalink / raw) To: Felipe Contreras; +Cc: Rich Pixley, Michael Witten, Seth Robertson, git Felipe Contreras <felipe.contreras@gmail.com> writes: > On Thu, May 3, 2012 at 9:13 PM, Rich Pixley <rich.pixley@palm.com> wrote: > ... >> $ # ...do some work... >> $ hg push # assume this collides > > % git push > >> pushing to $uri_for_cache_repo >> searching for changes >> abort: push creates new remote head 6d2eb0a6a278! >> (you should pull and merge or use push -f to force) >> $ hg push -f # the pull and merge case parallels git, so let's use push -f. > > This is stupid, why make everybody else's life difficult? Let's merge here. Doing "hg push -f" _regularly_ is probably stupid, but you need to step back a bit. There is a valid situation where you may sometimes want to publish unmerged work for others to see. The person who is trying to push here may be quite junior, and may not be yet familiar with the areas of the project outside what he has worked on. In his attempt to "pull and then push", he can end up having to resolve a merge conflict that he is not capable of handling correctly. Regardless of the VCS used, you would want to give a way to this junior developer to ask for help "here is my work; while I was working on it, the baseline has been diverged greatly and I need help either merging it or rebasing it." In that context, I can see that Hg's split head could be _one_ way to implement it. You just push and force split the head at the remote, leaving others to sort out the resulting mess. But that is not necessarily the _only_ way to implement it. A Git user would probably push his work to either his own public repository, or in an environment like Rich illustrated, to refs/remotes/junior/need_help_xyzzy of the central repository of the organization, and ask other people to help him. And when he does so, he needs to tell them where they can find his work, either the url to his own repository (and its branch), or his branch at the shared place, and that is where the naming of branch becomes meaningful. Instead of saying "There is 6d2eb0a6a278 in the repo that I need somebody to help merging", the request-for-help message can say "I placed my WIP on junior/need_help_xyzzy branch; please take a look and help merging it." Such a "push -f" to split heads (or pushing to need_help branch and ask others to do the "pull/push" for him) shouldn't be a norm, and if a project _relies_ on the ability to do so, there probably is a deeper problem with the project (e.g. perhaps the codebase is not modularized enough to allow isolated parallel development by junior people on narrow subparts of it). ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 20:27 ` Junio C Hamano @ 2012-05-04 20:45 ` Felipe Contreras 2012-05-04 21:29 ` Rich Pixley 0 siblings, 1 reply; 100+ messages in thread From: Felipe Contreras @ 2012-05-04 20:45 UTC (permalink / raw) To: Junio C Hamano; +Cc: Rich Pixley, Michael Witten, Seth Robertson, git On Fri, May 4, 2012 at 10:27 PM, Junio C Hamano <gitster@pobox.com> wrote: > Felipe Contreras <felipe.contreras@gmail.com> writes: > >> On Thu, May 3, 2012 at 9:13 PM, Rich Pixley <rich.pixley@palm.com> wrote: >> ... >>> $ # ...do some work... >>> $ hg push # assume this collides >> >> % git push >> >>> pushing to $uri_for_cache_repo >>> searching for changes >>> abort: push creates new remote head 6d2eb0a6a278! >>> (you should pull and merge or use push -f to force) >>> $ hg push -f # the pull and merge case parallels git, so let's use push -f. >> >> This is stupid, why make everybody else's life difficult? Let's merge here. > > Doing "hg push -f" _regularly_ is probably stupid, but you need to step > back a bit. There is a valid situation where you may sometimes want to > publish unmerged work for others to see. > > The person who is trying to push here may be quite junior, and may not be > yet familiar with the areas of the project outside what he has worked on. > In his attempt to "pull and then push", he can end up having to resolve a > merge conflict that he is not capable of handling correctly. Regardless of > the VCS used, you would want to give a way to this junior developer to ask > for help "here is my work; while I was working on it, the baseline has > been diverged greatly and I need help either merging it or rebasing it." Sure, but is 'push -f' the right solution? If a junior really has no idea about what he is doing, I wouldn't want him pushing another 'head' to the master branch. Can mercurial really do a rebase only on a specific head of a branch? Even if mercurial can do that, the result can be quite messy; one guy doing a rebase, another guy doing a merge, another guy doing a different merge, another a different rebase; if they know what they are doing, they will avoid 'push -f' and revert or rebase their changes when they notice somebody else tried to do something similar, but maybe one of them is a slightly more advanced junior and actually does 'push -f', and we go into yet another round of conflict resolving. It doesn't matter how you look at it; 'push -f' is not ideal. In the git world there's many ways to resolve this; push to another branch, push to another repo, allow ssh access to your machine, send the changes by mail, copy the git repo to a shared location, etc. *All* of those alternatives are better than 'push -f'. It seems to me that this *huge* thread basically boils down to Rich wanting 'hg push -f', when clearly that just creates problems, even in mercurial. Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 20:45 ` Felipe Contreras @ 2012-05-04 21:29 ` Rich Pixley 2012-05-04 22:05 ` Felipe Contreras 0 siblings, 1 reply; 100+ messages in thread From: Rich Pixley @ 2012-05-04 21:29 UTC (permalink / raw) To: Felipe Contreras; +Cc: Junio C Hamano, Michael Witten, Seth Robertson, git On 5/4/12 1:45 PM, Felipe Contreras wrote: > It doesn't matter how you look at it; 'push -f' is not ideal. Push -f offers an alternative that is available in other source code control systems, (not just mercurial), but not in git. It's a bit of a culture shock to discover that it's not available in git. > In the git world there's many ways to resolve this; push to another > branch, push to another repo, allow ssh access to your machine, send > the changes by mail, copy the git repo to a shared location, etc. > *All* of those alternatives are better than 'push -f'. In your opinion, and that's fine. I don't need to argue this point any longer. All of those other solutions are also available in the other source code control systems too. > It seems to me that this *huge* thread basically boils down to Rich > wanting 'hg push -f', when clearly that just creates problems, even in > mercurial. Actually, I wanted a work flow that was functional for me and supported a shared branch between multiple repositories. I think I have a process for that now. The key things I've learned so far are: * Git can't cope with repository collisions, (in essence, because it's not willing to ever create multiple heads, but also because it doesn't track the entire pedigree of a branch, and because destructive rewrites on the repository are common in typical git usage). The usual way to deal with this in the git world is to use geographical branches and triangles everywhere, but using "merge before push" can provide a way to use shared branches within git, (provided you can live within a fair number of restrictions, which I probably can.) * That that cryptic message means that git would need to cope with a repository collision, which it can't do. It doesn't actually mean that the repository is corrupt, which is what I took it to mean. Frankly, if the cryptic message had been clearer, I probably would never have posted here. I'd likely have figured out that git had this restriction and found a way to work around it on my own. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-05-04 21:29 ` Rich Pixley @ 2012-05-04 22:05 ` Felipe Contreras 0 siblings, 0 replies; 100+ messages in thread From: Felipe Contreras @ 2012-05-04 22:05 UTC (permalink / raw) To: Rich Pixley; +Cc: Junio C Hamano, Michael Witten, Seth Robertson, git On Fri, May 4, 2012 at 11:29 PM, Rich Pixley <rich.pixley@palm.com> wrote: > On 5/4/12 1:45 PM, Felipe Contreras wrote: >> >> It doesn't matter how you look at it; 'push -f' is not ideal. > > > Push -f offers an alternative A crappy alternative. > that is available in other source code control systems, (not just mercurial), Which other systems? monotone? That doesn't say much. > but not in git. It's a bit of a culture > shock to discover that it's not available in git. If you don't find a crappy problematic feature in git that you rely on--that's your problem. >> In the git world there's many ways to resolve this; push to another >> branch, push to another repo, allow ssh access to your machine, send >> the changes by mail, copy the git repo to a shared location, etc. >> *All* of those alternatives are better than 'push -f'. > > In your opinion, and that's fine. I don't need to argue this point any > longer. All of those other solutions are also available in the other source > code control systems too. And they are preferred, even the mercurial documentation says you should avoid 'push -f'. It seems you are the only one that thinks 'push -f' is ideal. >> It seems to me that this *huge* thread basically boils down to Rich >> wanting 'hg push -f', when clearly that just creates problems, even in >> mercurial. > > > Actually, I wanted a work flow that was functional for me and supported a > shared branch between multiple repositories. I think I have a process for > that now. The key things I've learned so far are: > > * Git can't cope with repository collisions, (in essence, because it's not > willing to ever create multiple heads, but also because it doesn't track the > entire pedigree of a branch, and because destructive rewrites on the > repository are common in typical git usage). Wrong. Git copes with collisions just fine; you don't need multiple heads, multiple heads are bad, even in mercurial, even mercurial documentation says so. You merge before you push; easy. > The usual way to deal with this in the git world is to use geographical > branches and triangles everywhere, Again wrong. The usual way is to have feature branches: % git checkout -b rich-reorganize-foo % git push origin rich-reorganize-foo > but using "mege before push" can provide > a way to use shared branches within git, (provided you can live within a > fair number of restrictions, which I probably can.) That's the preferred way in mercurial too; it's the sane way to do it. > * That that cryptic message means that git would need to cope with a > repository collision, which it can't do. It doesn't actually mean that the > repository is corrupt, which is what I took it to mean. > > Frankly, if the cryptic message had been clearer, I probably would never > have posted here. I'd likely have figured out that git had this restriction > and found a way to work around it on my own. Stop thinking your opinion is truth, and stop playing with words. Mercurial has the "restriction" that you can't push to a repository where you don't have permissions; that might be a restriction to somebody, but using the word restriction to describe that situation would be a cheap rhetorical device to be abrasiveness against mercurial. In mercurial and in git you should merge before you pull, if you don't like to be forced to do the sane thing; go use mercurial and be happy with the pain you create to yourself. And BTW, this is the clear message from mercurial: abort: push creates new remote head 6d2eb0a6a278! Not cryptic at all! Personally I don't care, I know a collision when I see it. If you want to help improve the error message, feel free to participate in the other thread that is meant for that. As for the workflow it's clear that the git workflow is a bit simpler than mercurial one, you just want to make your life difficult with 'hg push -f', and if you want to shoot yourself in the foot, you have mercurial for that (even though it's not recommended there either). -- Felipe Contreras ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-04-30 22:30 Newbie grief Rich Pixley 2012-04-30 23:31 ` Seth Robertson @ 2012-04-30 23:35 ` Jan Krüger 2012-05-01 18:59 ` Rich Pixley 2012-05-02 8:25 ` Philippe Vaucher 2 siblings, 1 reply; 100+ messages in thread From: Jan Krüger @ 2012-04-30 23:35 UTC (permalink / raw) To: Rich Pixley; +Cc: git Hi Rich, On 05/01/2012 12:30 AM, Rich Pixley wrote: > I'm trying to do what seems like a simple thing in darcs, monotone, > mecurial, gnu arch, etc, but seems nearly impossible in git. There's a > central repository, a long ways away on the other side of the internet. > So I want a local repository cache. I'm going to be working on a number > of different features and different machines all simultaneously so I > really don't want them all to be pulling from the central repository. > > In other systems, this is a simple star network. Clone a repository, > use, push, pull, etc. But with git, I can't push unless the cache > repository is bare, but if the cache repository is bare, then a change > to the central repository will cause the two to become wedged since > neither can push or fetch the other. If the 'cache repository' is set up using "git clone --mirror" and you push to the primary repository only, that makes the cache repo a definite slave, so you can always run "git fetch" on it without any trouble. You can even enforce this by denying all pushes to the cache repo, thus eliminating any chance of accidental misuse. Conveniently, git allows you to specify a different URL for fetch and push in your local working repositories. HTH, Jan ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-04-30 23:35 ` Jan Krüger @ 2012-05-01 18:59 ` Rich Pixley 0 siblings, 0 replies; 100+ messages in thread From: Rich Pixley @ 2012-05-01 18:59 UTC (permalink / raw) To: Jan Krüger; +Cc: git On 4/30/12 16:35 , Jan Krüger wrote: > Hi Rich, > > On 05/01/2012 12:30 AM, Rich Pixley wrote: >> I'm trying to do what seems like a simple thing in darcs, monotone, >> mecurial, gnu arch, etc, but seems nearly impossible in git. There's a >> central repository, a long ways away on the other side of the internet. >> So I want a local repository cache. I'm going to be working on a number >> of different features and different machines all simultaneously so I >> really don't want them all to be pulling from the central repository. >> >> In other systems, this is a simple star network. Clone a repository, >> use, push, pull, etc. But with git, I can't push unless the cache >> repository is bare, but if the cache repository is bare, then a change >> to the central repository will cause the two to become wedged since >> neither can push or fetch the other. > If the 'cache repository' is set up using "git clone --mirror" and you > push to the primary repository only, that makes the cache repo a > definite slave, so you can always run "git fetch" on it without any > trouble. You can even enforce this by denying all pushes to the cache > repo, thus eliminating any chance of accidental misuse. > > Conveniently, git allows you to specify a different URL for fetch and > push in your local working repositories. Thank you. For completeness, Michael Witten posted details for a comparable architecture where the data flow is in the other direction. Leaf repositories push/pull to/from the cache, pull from the central repository in order to merge changes, then push to the cache to share locally. Eventually, some leaf repository will push to the central. Michael's approach has the advantage that the cache repository can be unattended and that my changes can be circulated locally before becoming visible to the wider, central repository audience. Both approaches cleverly avoid potential collisions in the cache repository by working around them. And, of course, some combinations of the two will work too. --rich ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Newbie grief 2012-04-30 22:30 Newbie grief Rich Pixley 2012-04-30 23:31 ` Seth Robertson 2012-04-30 23:35 ` Jan Krüger @ 2012-05-02 8:25 ` Philippe Vaucher 2 siblings, 0 replies; 100+ messages in thread From: Philippe Vaucher @ 2012-05-02 8:25 UTC (permalink / raw) To: Rich Pixley; +Cc: git > In other systems, this is a simple star network. Clone a repository, use, push, pull, etc. But with git, I can't push unless the cache repository is bare, but if the cache repository is bare, then a change to the central repository will cause the two to become wedged since neither can push or fetch the other. It seems that git is allergic to the dual head branch solution or something, which is surprising and disappointing. If I understand correctly, you're looking for a system where you have a lot of systems that needs to share the modifications on their repo *without* having a central repo. Basically you want a lot of non-bare repositories pushing/pulling from each others. It sounds to me that your problem could easily be solved if your restrict yourself to "pulling" only. Whenever you want the latest change from repo on machine A, just pull from machine A and benefit from the automagic merging etc. Tell me if there's something I'm missing, or maybe describe a simple scenario we can relate with in terms of ideal commands to type and things happening. Thanks, Philippe ^ permalink raw reply [flat|nested] 100+ messages in thread
end of thread, other threads:[~2012-05-04 22:05 UTC | newest] Thread overview: 100+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-30 22:30 Newbie grief Rich Pixley 2012-04-30 23:31 ` Seth Robertson 2012-05-01 1:15 ` Rich Pixley 2012-05-01 1:32 ` Junio C Hamano 2012-05-01 1:55 ` Rich Pixley 2012-05-01 3:44 ` Sitaram Chamarty 2012-05-01 11:14 ` Ted Ts'o 2012-05-01 16:13 ` Sitaram Chamarty 2012-05-01 18:15 ` Rich Pixley 2012-05-01 18:20 ` Michael Witten 2012-05-01 18:52 ` Rich Pixley 2012-05-02 21:28 ` Jakub Narebski 2012-05-01 18:42 ` Randal L. Schwartz 2012-05-01 20:52 ` Rich Pixley 2012-05-01 21:05 ` Randal L. Schwartz 2012-05-01 21:12 ` Junio C Hamano 2012-05-01 21:25 ` Rich Pixley 2012-05-01 21:28 ` Randal L. Schwartz 2012-05-01 21:57 ` Rich Pixley 2012-05-01 22:56 ` Michael Witten 2012-05-01 23:55 ` Philip Oakley 2012-05-03 16:08 ` Hallvard Breien Furuseth 2012-05-03 18:20 ` Rich Pixley 2012-05-03 23:04 ` Hallvard Breien Furuseth 2012-05-03 23:06 ` Hallvard Breien Furuseth 2012-05-03 18:46 ` Rich Pixley 2012-05-03 21:09 ` Junio C Hamano 2012-05-03 22:44 ` Rich Pixley 2012-05-03 22:53 ` Randal L. Schwartz 2012-05-03 22:59 ` Junio C Hamano 2012-05-04 19:23 ` Felipe Contreras 2012-05-04 19:30 ` Felipe Contreras 2012-05-04 19:41 ` Michael Witten 2012-05-01 21:29 ` Rich Pixley 2012-05-01 21:39 ` Randal L. Schwartz 2012-05-01 22:07 ` Rich Pixley 2012-05-01 22:17 ` Andreas Ericsson 2012-05-01 23:01 ` PJ Weisberg 2012-05-03 18:43 ` Rich Pixley 2012-05-03 19:09 ` Nathan Gray 2012-05-03 19:16 ` Rich Pixley 2012-05-03 20:14 ` Randal L. Schwartz 2012-05-03 20:52 ` Rich Pixley 2012-05-04 15:56 ` Mark Brown 2012-05-04 18:23 ` Rich Pixley 2012-05-04 19:14 ` Jakub Narebski 2012-05-04 20:00 ` Mark Brown 2012-05-02 14:21 ` Hallvard Breien Furuseth 2012-05-02 15:21 ` Michael Witten 2012-05-03 12:23 ` Hallvard Breien Furuseth 2012-05-03 12:53 ` Randal L. Schwartz 2012-05-03 16:09 ` Michael Witten 2012-05-03 16:20 ` Hallvard Breien Furuseth 2012-05-03 16:44 ` Michael Witten 2012-05-03 18:26 ` Rich Pixley 2012-05-03 19:33 ` Ted Ts'o 2012-05-01 23:30 ` Felipe Contreras 2012-05-03 18:31 ` Rich Pixley 2012-05-03 18:58 ` Rich Pixley 2012-05-04 14:09 ` Andreas Ericsson 2012-05-04 14:59 ` Stephen Bash 2012-05-04 16:29 ` Mark Brown 2012-05-04 19:13 ` Felipe Contreras 2012-05-01 18:03 ` Rich Pixley [not found] ` <4FA01C73.5000909@palm.com> 2012-05-02 0:44 ` Sitaram Chamarty [not found] ` <4F9F28F5.2020403@palm.com> 2012-05-01 1:37 ` Seth Robertson 2012-05-01 3:04 ` Rich Pixley 2012-05-01 5:32 ` Michael Witten 2012-05-01 6:21 ` Junio C Hamano 2012-05-01 6:24 ` Michael Witten 2012-05-01 17:29 ` Rich Pixley 2012-05-01 17:33 ` Rich Pixley 2012-05-03 19:13 ` Rich Pixley 2012-05-03 20:19 ` Ronan Keryell 2012-05-03 21:13 ` Junio C Hamano 2012-05-03 22:23 ` Ronan Keryell 2012-05-03 22:33 ` Rich Pixley 2012-05-03 22:39 ` Rich Pixley 2012-05-04 1:01 ` Illia Bobyr 2012-05-04 3:13 ` Nathan Gray 2012-05-04 4:35 ` Michael Witten 2012-05-04 5:25 ` Junio C Hamano 2012-05-04 10:09 ` Carlos Martín Nieto 2012-05-04 14:50 ` Junio C Hamano 2012-05-04 17:39 ` Junio C Hamano 2012-05-04 16:46 ` Nathan Gray 2012-05-04 17:17 ` Illia Bobyr 2012-05-04 18:10 ` Rich Pixley 2012-05-04 17:57 ` Rich Pixley 2012-05-04 19:22 ` Michael Witten 2012-05-04 19:18 ` Andrew Sayers 2012-05-04 18:57 ` Jérôme Benoit 2012-05-04 20:03 ` Felipe Contreras 2012-05-04 20:27 ` Junio C Hamano 2012-05-04 20:45 ` Felipe Contreras 2012-05-04 21:29 ` Rich Pixley 2012-05-04 22:05 ` Felipe Contreras 2012-04-30 23:35 ` Jan Krüger 2012-05-01 18:59 ` Rich Pixley 2012-05-02 8:25 ` Philippe Vaucher
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.