[Cc: git@vger.kernel.org, gapon <gapon007@gmail.com>, 
 Benoit Sigoure <tsuna@lrde.epita.fr>]

Could you _please_ do not toppost?


That's wrong, wrong, WRONG! What to do in the case of conflicts?
Whan you pull, you can resolve them, as they are on your local side,

That is also wrong: how do you decide name of new branch then, and
woundn't this lead to proliferation of branches?

You can do the same with git, but you have to specify new branch name
in repo A, or just configure remote in repo B.

BTW. how do you want for user A (which might be not at terminal, or might
be not logged in, or might use some application using terminal, or might
use multiple [virtual] terminals, or...) to be informed?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


-

[ message continues ]

i agree - i didn't say that it's correct behaviour - i just said that i like 

i don't agree that it's wrong - in the hg log all you see is that the commit 
from repo B has different parent - that's all
if hg status (or similar) printed some info about this situation it would be 

how can i do it in repo A? i know how to configure repo B but i didn't know 

quite easily i would say - while doing git status or git commit or so - it 
doesn't matter if one uses terminal or gui - just let user know that 
something has changed in his repo
as i wrote earlier - it's confusing (at least for me) that git marks any files 
as changed (i haven't changed any file) and more, it adds them to the index
-

[ message continues ]

I think it is just wrong and it is hardly any other be worse.

git-clone sets up repo B (the clone) for one direction of transfer,
from repo A (cloned repo) to repo B (the clone). If you want to push
to repo A, you should configure repo B to do so.


There was an idea, and even preliminary implementation in 'pu' branch
(proposed updates) to have BASE extension in the index (or in refs,
I don't remember exactly: search the archives), and check when committing
if for example push didn't change the repository, didin't advance current
checked out branch under our feet so to say. This allowed for the behavior
you want.

It was abandoned, for the following reasons as far as I know.

First, there are legitimate situations, created by current user, where
branch (HEAD) changes: reset, amend, checkout -m, etc. It would be hard
to avoid annoing false positives (false alarms).

Second, it was complicated to do correctly, as it affected quite a bit
of git codebase.

Third, it encourages a wrong (CVS braindamage inspired) workflow. The last
thing you want when committing changes is to have to resolve some
conflicts, and/or check if [automatic] conflict resolution is correct.

You are welcome to ressurect BASE extension to index file :-)

-- 
Jakub Narebski
Poland
-

[ message continues ]

What I forgot to add that git encourages "with integrator" workflows:
either send requests to pull to project maintainer, or send patches
(which allow peer review of them) to maintainer, perhaps via public
project mailing list.

You can do "centralized repository" or "peer to peer" aka "star
topology" workflows, but it is not optimized for those workflows;
you have to work a bit harder.

-- 
Jakub Narebski
Poland
-

[ message continues ]

jakub, thanks for explanation - now it's clear that it's not easy to handle 
such case... unfortunately
-

[ message continues ]