Bill Lear <rael@xxxxxxxxxx> writes:
> master~3 ^2 ~2
>
> Means the 2nd (first generation) parent of the second parent of the
> 3rd (first generation) parent? Is there a way to simply state this in
> plain words, say in terms of commits/merges?
You had one commit (master~3^2~2). You built one commit on top
of it (master~3^2~1) and another (master~3^2).
That one was merged into something else as the second parent,
and the merge result is master~3 (that "something else" is
master~4 aka master~3^ aka master~3^1).
You built three commits on top of that, and that is where your
master currently is.
> I'm unsure how to
> interpret the above, especially since none of us has been developing
> on a branch (I see no other branch names except master, also).
But you are. Each repository are independent and the branches
your developers have, even though each of them have only one,
are separate branches. You are exercising the distributedness
of git development model.
> I'm not sure if this is sane: is it ok to clone the company repo,
> then push from that clone into a bare repo, then from there to
> the company one?
That's essentially everybody doing distributed development does
in git land -- it is very sane.
> Is git doing some sort of weird, silent pseudo-merge
> that we don't understand, thus generated what appears to be a very
> tangled, albeit brief, history, when we examine it?
I do not think so, but the person creating a commit may first be
pulling from the central location, which needs a merge and
results in one. That's very common in centralized workflow
modelled after how CVS is used.
Let's say you have the central (perhaps bare but it does not
matter if it is bare or not) repository and two workers, Alice
and Bob. They both clone from it and make one commit each in
their repositories. The commit ancestries in the entire world
would look like this:
.---o Alice's 'master'
/
---o---o-------o Bob's 'master'
^
central repo's 'master'
Then Bob pushes to the central repo. Since it is a
fast-forward, his push is accpeted and the picture would become
like this:
.---o Alice's 'master'
/
---o---o-------o Bob's 'master'
^
central repo's 'master'
When Alice wants to push her changes back to the central repo,
it is not a fast-forward and is refused. We currently suggest
Alice to first pull from the central repo (this is how CVS is
used -- you try "cvs commit" and get complaints, then you say
"cvs update" and retry).
What happens is that in Alice's repository, if Bob's change and
Alice's change does not conflict, this "pull" creates a merge
commit.
.---o---o Alice's 'master'
/ /
---o---o-------o Bob's 'master'
^
central repo's 'master'
Then Alice can push out her changes.
.---o---o Alice's 'master' == central repo's 'master'
/ /
---o---o-------o Bob's 'master'
If Bob pulls from the central repo at this point, it will also
fast-forward and these three repositories end up with
.---o---o Alice's 'master' == central repo's 'master'
/ / == Bob's 'master'
---o---o-------o
One thing you _could_ do is to train your users to rebase after
push fails, if you do not want these merges.
After her push fails here...
.---o Alice's 'master'
/
---o---o-------o Bob's 'master'
^
central repo's 'master'
Alice could rebase by:
$ git fetch
$ git rebase origin
The first "git fetch" (if Alice is using the default
configuration created by recent "git clone") fetches from the
central repo and stores the 'master' branch at the central repo
as her tracking branch (.git/refs/remotes/origin/master). This
can be referenced on the command line as 'origin' (again, if
Alice is using the default configuration created by recent "git
clone"). What these commands do is:
(1) git-fetch makes central repo's 'master' locally available to
Alice as 'origin'
.---o Alice's 'master'
/
---o---o-------o Bob's 'master'
^
central repo's 'master' == Alice's 'origin'
(2) git-rebase forward ports the commits on Alice's 'master'
since it forked from the central repo, and creates this
graph:
.---o Alice's 'master', updated
/
---o---o-------o Bob's 'master'
^
central repo's 'master' == Alice's 'origin'
After these, 'master' in Alice's repository is a fast-forward
and she can now push to update the central repository.
It would be usually a good idea to rebase if Alice's work is
trivial since she synchronized with the central repository the
last time. If it is a very involved changes, however, it often
is not worth worrying about keeping merges out of the history.
Your developers _are_ working in parallel and there is not much
point in insisting to lineralize the history too much.
-
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