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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html