Dne úterý 27 listopadu 2007 Jakub Narebski napsal(a): > [Cc: git@xxxxxxxxxxxxxxx, gapon <gapon007@xxxxxxxxx>, > Benoit Sigoure <tsuna@xxxxxxxxxxxxx>] > > Could you _please_ do not toppost? sure, no problem ;) > > 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. i agree - i didn't say that it's correct behaviour - i just said that i like it more than git's one > > > 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? 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 enough i would say - but just my opinion/feeling of course > > 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. how can i do it in repo A? i know how to configure repo B but i didn't know that i can do it for repo B (or better for all "B" repos) > > 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? 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 - 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