Re: Newbie grief
- From
- Rich Pixley <rich.pixley@palm.com>
- Date
- May 1, 2012, 03:04 UTC
- Message-ID
- <4F9F52B9.9060508@palm.com>
- In-Reply-To
- <201205010137.q411bxaU002449@no.baka.org>
On 4/30/12 18:37 , Seth Robertson wrote:
Show 5 quoted lines
> 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.
Show 13 quoted lines
> > 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".
Show 9 quoted lines
> 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.
Show 11 quoted lines
> 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.
Show 6 quoted lines
> 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