Re: git bug/feature request

From: Jakub Narebski <jnareb@gmail.com>
Date: Nov 27, 2007, 13:31 UTC
Message-ID: <200711271431.21516.jnareb@gmail.com>
In-Reply-To: <200711271350.38468.gapon007@gmail.com>

Dnia wtorek 27. listopada 2007, gapon napisał(a):

> Dne úterý 27 listopadu 2007 Jakub Narebski napsal(a):
>> gapon wrote:

Show 10 quoted lines

>>> 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?

>>> 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)

[...]

Show 5 quoted lines

>> 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.

Show 7 quoted lines

>> 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 Narebski
Poland