[Cc: git@xxxxxxxxxxxxxxx, gapon <gapon007@xxxxxxxxx>, Benoit Sigoure <tsuna@xxxxxxxxxxxxx>] 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 - 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
