Re: git bug/feature request

[Jakub Narebski <jnareb@gmail.com>]

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

Could you _please_ do not toppost?

gapon wrote:

> Dne úterý 27 listopadu 2007 Benoit Sigoure napsal(a):
>> On Nov 27, 2007, at 11:27 AM, gapon wrote:
>> > * yes, i know that this scenario is "incorrect" but... it's
>> > possible and
>> > therefore i think it should be somehow handled - i tried a similar
>> > one with
>> > hg and bzr and i like their behaviour more
>>
>> Would you mind describing the behavior of hg and bzr in this case?
[...]
>
> bzr:
> while pushing, bzr tries to merge into the current working copy (of A)
> -> all changes are applied or conflicts occure

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,
but when you push you cannot do that.

> hg:
> while pushing, neither merge nor info message, but new head (branch) is 
> created in repo A - so then in A you can commit your changes but it's 
> different head (repo A has more heads, use hg heads to list them)
> btw i filed and enhancement for hg, to let user know that there are more heads 
> in the repo (you have to use hg log or hg heads to discover that someone else 
> has pushed into your repo and hg merge to merge them) 

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