Dne úterý 27 listopadu 2007 Jakub Narebski napsal(a): > Dnia wtorek 27. listopada 2007, gapon napisał(a): > > Dne úterý 27 listopadu 2007 Jakub Narebski napsal(a): > >> gapon wrote: > >>> 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 > > I think it is just wrong and it is hardly any other be worse. > By the way, don't current git _refuse_ to update checked out branch? what do you mean exactly? i will try it > > >>> 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) > > [...] > > >> 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) > > 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. > > See also comments below. > > >> 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 > > 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. > Blind merging is a bad, bad idea. > > > 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 > > You are welcome to ressurect BASE extension to index file :-) jakub, thanks for explanation - now it's clear that it's not easy to handle such case... unfortunately - 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
