On Friday, February 16, 2007 at 03:00:04 (+0100) Jakub Narebski writes:
>Bill Lear wrote:
>
>> On Thursday, February 15, 2007 at 15:21:38 (-0600) Bill Lear writes:
>>>On Thursday, February 15, 2007 at 16:00:23 (-0500) Nicolas Pitre writes:
>>>>On Thu, 15 Feb 2007, Bill Lear wrote:
>>>>
>>>>> We are about to switch to git 1.5 from git 1.4.4.1. I cannot remember
>>>>> if someone posted about this, but what is the danger of working on a
>>>>> tracking branch --- there are abundant cautions about doing this, but
>>>>> I can't recall and can't find the reason this is bad.
>>>>
>>>>A tracking branch is supposed to be a local mirror of what is available
>>>>remotely. If you commit local changes to it then you break that model.
>>>
>>>Ok, so I break the model, what is the harm in that? Can I no longer
>>>pull from or push to the remote branch? Do I corrupt something
>>>locally? Does something else break? I'm trying to formulate an
>>>explanation to our users why the 1.5 way is superior and I can't just
>>>say "if you do that you break the model".
>
>You cannot fetch or push to the remote branch if you made some commits
>on the tracking branch ("broke the model") and remote branch has other
>commits. You can force the issue, but then either remote (for push)
>or local (for fetch) commits would be lost.
Ok, I'm trying to come up with an experiment that verifies this, so
I can give a concrete example to our developers.
I don't seem to be able to get it to fail, but I sure remember having
severe problems with this in practice. Here is my attempt, again with
git 1.4.4.1:
# Create my repo and add a file A
% mkdir my_repo
% cd my_repo
% git init-db
defaulting to local storage area
% echo A > A
% git add A && git commit -a -m "Add A"
Committing initial tree f53c91092dbda83f3565e78c285f3e2ab0cfd968
# Create a peer repo and add a file B
% cd ..
% mkdir peer_repo
% cd peer_repo/
% git init-db
defaulting to local storage area
% echo B > B
% git add B && git commit -a -m "Add B"
Committing initial tree bfcfa4ca04d80d4b092e022ad163e82ca0f4a34f
# Create a topic branch in peer repo and add file C
% git checkout -b topic
% echo C > C
% git add C && git commit -a -m "Add C"
# Go back to my repo and fetch peer's topic branch
% cd ../my_repo/
% git fetch ../peer_repo topic:topic
warning: no common commits
remote: Generating pack...
remote: Done counting 6 objects.
remote: Deltifying 6 objects.
remote: /6) done/6) done
Unpacking 6 objects
remote: Total 6, written 6 (delta 0), reused 0 (delta 0)
100% (6/6) done
* refs/heads/topic: storing branch 'topic' of ../peer_repo
commit: af3ab53
# In my repo, checkout topic and change B
% git checkout topic
% echo "Change B" >> B
% git commit -a -m "Change B"
# Go back to peer repo and change C
% cd ../peer_repo/
% echo "Change C" >> C
% git commit -a -m "Change C"
# Go back to my repo and pull peer's topic branch
% cd ../my_repo
% git pull ../peer_repo topic:topic
remote: Generating pack...
remote: Done counting 5 objects.
remote: Result has 3 objects.
remote: Deltifying 3 objects.
remote: 100% (3/3) done
remote: Total 3, written 3 (delta 0), reused 0 (delta 0)
Unpacking 3 objects
100% (3/3) done
* refs/heads/topic: not updating to non-fast forward branch 'topic' of ../peer_repo
old...new: d3cf979...9e36a9a
Trying really trivial in-index merge...
Wonderful.
In-index merge
C | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
So, why does it say "not updating to non-fast forward branch", yet
it does the merge and gets the changes anyway?
# Seem to have gotten the changes into my_repo anyway:
% git branch
master
* topic
% cat B C
B
Change B
C
Change C
I'm trying to come up with a white-board presentation I can give to
the group this afternoon and they are a contumacious bunch.
Bill
-
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