Re: git bug/feature request

[gapon <gapon007@gmail.com>]

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