git bug/feature request

git bug/feature request

[gapon]

hi all,
first of all i don't know if there's a bugzilla or something similar for git - 
i have found just this email (on http://git.or.cz/ webpage).

i have discovered "weird" behaviour of git in this scenario*:
- user A is working in repo A
- user B clones repo A
- user B makes some changes, commits, pushes
- user A makes some changes, git status (no info about new commit in his repo 
from user B but it's probably ok i'd say - but some of my files are marked as 
changed and already added to index  but i haven't changed them - that's 
confusing, isn't it?)
- user A can commit his changes => shouldn't be there any info/message/warning 
displayed? it would be helpful to have here some info about "foreign commit" 
in the repo or something like this

hmm?

thanks for git, it's simply the best one!
gapon

* 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

Re: git bug/feature request

[Benoit Sigoure]

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?

I was also bitten by this "feature" of Git.  Until I decided to put a  
bare repo in between and push my commits there.

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

Re: git bug/feature request

[gapon]

bzr:
while pushing, bzr tries to merge into the current working copy (of A)
-> all changes are applied or conflicts occure

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)

gapon


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?
>
> I was also bitten by this "feature" of Git.  Until I decided to put a
> bare repo in between and push my commits there.

Re: git bug/feature request

[Alex Riesen]

On 27/11/2007, gapon <gapon007@gmail.com> wrote:
> hi all,
> first of all i don't know if there's a bugzilla or something similar for git -
> i have found just this email (on http://git.or.cz/ webpage).
>
> i have discovered "weird" behaviour of git in this scenario*:
> - user A is working in repo A
> - user B clones repo A
> - user B makes some changes, commits, pushes
> - user A makes some changes, git status (no info about new commit in his repo
> from user B but it's probably ok i'd say - but some of my files are marked as
> changed and already added to index  but i haven't changed them - that's
> confusing, isn't it?)
> - user A can commit his changes => shouldn't be there any info/message/warning
> displayed? it would be helpful to have here some info about "foreign commit"
> in the repo or something like this

If you share a repository with someone else, you better use different
branches. What's happened is that user B changed the branch the
user A was working on (strictly speaking, the B-user changed the
reference A-user used as HEAD at the moment).

Just have the B-user push his/hers changes on something else,
not the master of the parent repository. For instance, B-user can
add a "push"-line to his origin remote which redirects its pushes
somewhere else:

  git config remote.origin.push 'refs/heads/*:refs/heads/B-user/*'

Or just use a dedicated shared repo where no one works in.
See also Documentation/config.txt, and the man page of git-push.

Re: git bug/feature request

[Jakub Narebski]

gapon wrote:

> hi all,
> first of all i don't know if there's a bugzilla or something similar
> for git - i have found just this email (on http://git.or.cz/ webpage).

There isn't any bug tracker for git. Use git mailing list for bug
reports and feature requests.

> i have discovered "weird" behaviour of git in this scenario*:
> - user A is working in repo A
> - user B clones repo A
> - user B makes some changes, commits, pushes

Do not push into checked out branch!

> - user A makes some changes, git status (no info about new commit
>   in his repo from user B but it's probably ok i'd say - but some
>   of my files are marked as changed and already added to index
>   but i haven't changed them - that's confusing, isn't it?)
> - user A can commit his changes => shouldn't be there any
>   info/message/warning displayed? it would be helpful to have
>   here some info about "foreign commit" in the repo or something
>   like this 

Perhaps there should. There was some idea and even preliminary
implementation of BASE check, but IIRC it was deemed too complicated,
and encouraging wrong workflow.

Besides, even with the check, pushing into checked out branch can quite
easily lead either to loosing (or at least vanishing) some history,
or problems with pushing.

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

IIRC we strongly discourage in documentation to push into checked out
branch. Either use bare repository for communication (it allows for
example for got for "ideal patch series" by rewriting history _before
publishing (pushing)_ and for communication with more than one
chosen developer), or push into _remotes_, not into heads.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git bug/feature request

[gapon]

as i wrote in my first email - i know that this is not "correct" scenario (i 
don't and won't use it anywhere) - but the git's behaviour is in such case 
confusing, at least for me
just for clarification - my email wasn't about how to push or create shared 
repository - it was just about what i have discovered while playing with 
different scms

gapon


Dne úterý 27 listopadu 2007 Alex Riesen napsal(a):
> On 27/11/2007, gapon <gapon007@gmail.com> wrote:
> > hi all,
> > first of all i don't know if there's a bugzilla or something similar for
> > git - i have found just this email (on http://git.or.cz/ webpage).
> >
> > i have discovered "weird" behaviour of git in this scenario*:
> > - user A is working in repo A
> > - user B clones repo A
> > - user B makes some changes, commits, pushes
> > - user A makes some changes, git status (no info about new commit in his
> > repo from user B but it's probably ok i'd say - but some of my files are
> > marked as changed and already added to index  but i haven't changed them
> > - that's confusing, isn't it?)
> > - user A can commit his changes => shouldn't be there any
> > info/message/warning displayed? it would be helpful to have here some
> > info about "foreign commit" in the repo or something like this
>
> If you share a repository with someone else, you better use different
> branches. What's happened is that user B changed the branch the
> user A was working on (strictly speaking, the B-user changed the
> reference A-user used as HEAD at the moment).
>
> Just have the B-user push his/hers changes on something else,
> not the master of the parent repository. For instance, B-user can
> add a "push"-line to his origin remote which redirects its pushes
> somewhere else:
>
>   git config remote.origin.push 'refs/heads/*:refs/heads/B-user/*'
>
> Or just use a dedicated shared repo where no one works in.
> See also Documentation/config.txt, and the man page of git-push.

Re: git bug/feature request

[Jakub Narebski]

[Cc: git@vger.kernel.org, gapon <gapon007@gmail.com>, 
 Benoit Sigoure <tsuna@lrde.epita.fr>]

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

Re: git bug/feature request

[gapon]

Dne úterý 27 listopadu 2007 Jakub Narebski napsal(a):
> [Cc: git@vger.kernel.org, gapon <gapon007@gmail.com>,
>  Benoit Sigoure <tsuna@lrde.epita.fr>]
>
> 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

Re: git bug/feature request

[Alex Riesen]

On 27/11/2007, gapon <gapon007@gmail.com> wrote:
> as i wrote in my first email - i know that this is not "correct" scenario (i
> don't and won't use it anywhere) - but the git's behaviour is in such case
> confusing, at least for me
> just for clarification - my email wasn't about how to push or create shared
> repository - it was just about what i have discovered while playing with
> different scms

Well... It is known problem, for one. That user B of yours, did he just cloned
user A's repo?

What I suspect is a change in how git-clone setups the cloned repo
could have taken care of it. We could either setup push-configuration
so that it just does not work (and let user change to his preference),
or somehow figure out where the pushed references can safely land
and put that in the cloned repo configuration (that is "SOMEHOW",
I afraid. Absolutely no idea what could that be).

Re: git bug/feature request

[Jakub Narebski]

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?

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

Re: git bug/feature request

[Jakub Narebski]

Jakub Narebski wrote:

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

What I forgot to add that git encourages "with integrator" workflows:
either send requests to pull to project maintainer, or send patches
(which allow peer review of them) to maintainer, perhaps via public
project mailing list.

You can do "centralized repository" or "peer to peer" aka "star
topology" workflows, but it is not optimized for those workflows;
you have to work a bit harder.

-- 
Jakub Narebski
Poland

Re: git bug/feature request

[gapon]

Dne úterý 27 listopadu 2007 Alex Riesen napsal(a):
> On 27/11/2007, gapon <gapon007@gmail.com> wrote:
> > as i wrote in my first email - i know that this is not "correct" scenario
> > (i don't and won't use it anywhere) - but the git's behaviour is in such
> > case confusing, at least for me
> > just for clarification - my email wasn't about how to push or create
> > shared repository - it was just about what i have discovered while
> > playing with different scms
>
> Well... It is known problem, for one. That user B of yours, did he just
> cloned user A's repo?

yes, i can paste here all the scenario step by step if you want
>
> What I suspect is a change in how git-clone setups the cloned repo
> could have taken care of it. We could either setup push-configuration
> so that it just does not work (and let user change to his preference),
> or somehow figure out where the pushed references can safely land
> and put that in the cloned repo configuration (that is "SOMEHOW",
> I afraid. Absolutely no idea what could that be).

hard to say what to do, what is correct - now i would say that i like hg 
behaviour the most - but i can be wrong of course; the only purpose of this 
discussion is that i have found out (by accident ;) "weird" behaviour of git 
in such situation - and because git is definitely my most favorite scm i 
wanted to report bug/feature/whatever

thanks for all your comments guys

Re: git bug/feature request

[gapon]

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

Re: git bug/feature request

[Peter Karlsson]

gapon:

> i have discovered "weird" behaviour of git in this scenario*:

Yeah, I have run into it several times myself, and that is being both
user A and B at the same time. The problem seems to be that git allows
you to push into a repository which has a check-out, causing it to
change states in a subtle way. That's just plain broken.

Git should either handle it somehow (perhaps by forcing the push into a
new branch, which the pushee needs name), or just plainly refuse to
push into a repository with a check-out.

I have learned to work around this problem by always pulling between my
repositories, not pulling. I could probably have worked around it by
having a master repository that is bare, but I have found that
difficult because I am tracking an upstream non-Git repository, so to
push and pull changes from that, I need a repository where I can have a
check-out.

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

Yeah. It's even more irritating that recovering from the error state is
difficult as well.

-- 
\\// Peter - http://www.softwolves.pp.se/

Re: git bug/feature request

[David Kastrup]

Peter Karlsson <peter@softwolves.pp.se> writes:

> I have learned to work around this problem by always pulling between
> my repositories, not pulling.

Uhm...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: git bug/feature request

[Jakub Narebski]

Peter Karlsson wrote:

> gapon:
> 
>> i have discovered "weird" behaviour of git in this scenario*:
> 
> Yeah, I have run into it several times myself, and that is being both
> user A and B at the same time. The problem seems to be that git allows
> you to push into a repository which has a check-out, causing it to
> change states in a subtle way. That's just plain broken.
> 
> Git should either handle it somehow (perhaps by forcing the push into a
> new branch, which the pushee needs name), or just plainly refuse to
> push into a repository with a check-out.

I thought that modern git refuses to push into checked out branch
(in HEAD) in non-bare repositories. In shared repositories default
is to deny non-fastforwards, by the way.

> I have learned to work around this problem by always pulling between my
> repositories, not pushing.

You can simply push to remotes, allowing other person to merge
on other side.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git bug/feature request

[Alex Riesen]

On 27/11/2007, gapon <gapon007@gmail.com> wrote:
> > Well... It is known problem, for one. That user B of yours, did he just
> > cloned user A's repo?
>
> yes, i can paste here all the scenario step by step if you want

No, thanks. It is easy to reproduce

Re: git bug/feature request

[Steven Grimm]

On Nov 27, 2007, at 7:13 AM, Jakub Narebski wrote:
> I thought that modern git refuses to push into checked out branch
> (in HEAD) in non-bare repositories.

It doesn't -- otherwise the "update the working copy when a push to  
the current branch comes in" update hook scripts that some of us use  
wouldn't work, and they do work at the moment. (Before anyone warns me  
of the dangers of that: the hook only runs in a shared repo that no  
human is allowed to modify, so the working copy is always a clean  
version of HEAD and thus is safe to update.)

-Steve

Re: git bug/feature request

[Daniel Barkalow]

On Tue, 27 Nov 2007, Steven Grimm wrote:

> On Nov 27, 2007, at 7:13 AM, Jakub Narebski wrote:
> >I thought that modern git refuses to push into checked out branch
> >(in HEAD) in non-bare repositories.
> 
> It doesn't -- otherwise the "update the working copy when a push to the
> current branch comes in" update hook scripts that some of us use wouldn't
> work, and they do work at the moment. (Before anyone warns me of the dangers
> of that: the hook only runs in a shared repo that no human is allowed to
> modify, so the working copy is always a clean version of HEAD and thus is safe
> to update.)

It could require the working copy to be a clean version of HEAD, and, in 
this case, update it. Then it would always be kept consistent one way or 
the other, without consistency depending on the use of a hook. (This is 
like how a pre-refs/remotes/ pull into a checked-out origin was handled, 
and it seemed reliable there)

	-Daniel
*This .sig left intentionally blank*

Re: git bug/feature request

[Daniel Barkalow]

On Tue, 27 Nov 2007, gapon wrote:

> hi all,
> first of all i don't know if there's a bugzilla or something similar for git - 
> i have found just this email (on http://git.or.cz/ webpage).
> 
> i have discovered "weird" behaviour of git in this scenario*:
> - user A is working in repo A
> - user B clones repo A
> - user B makes some changes, commits, pushes
> - user A makes some changes, git status (no info about new commit in his repo 
> from user B but it's probably ok i'd say - but some of my files are marked as 
> changed and already added to index  but i haven't changed them - that's 
> confusing, isn't it?)
> - user A can commit his changes => shouldn't be there any info/message/warning 
> displayed? it would be helpful to have here some info about "foreign commit" 
> in the repo or something like this

This is kind of a fundamentally crazy thing to do; it's like a CVS user 
committing to somebody else's working directory instead of to the central 
repository. As you might expect, the system is confused because the info 
of what version is checked out is changed without the checked-out files 
getting changed. This should probably be kept from happening in some 
fashion, not reported to the user after the fact.

	-Daniel
*This .sig left intentionally blank*

Re: git bug/feature request

[Peter Karlsson]

David Kastrup:

> > I have learned to work around this problem by always pulling between
> > my repositories, not pulling.
> Uhm...

"...not *pushing*", obviously. Sorry :-)

-- 
\\// Peter - http://www.softwolves.pp.se/

Re: git bug/feature request

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

On Tue, Nov 27, 2007 at 12:30:16 +0100, Jakub Narebski wrote:
> gapon wrote:
> 
> > hi all,
> > first of all i don't know if there's a bugzilla or something similar
> > for git - i have found just this email (on http://git.or.cz/ webpage).
> 
> There isn't any bug tracker for git. Use git mailing list for bug
> reports and feature requests.
> 
> > i have discovered "weird" behaviour of git in this scenario*:
> > - user A is working in repo A
> > - user B clones repo A
> > - user B makes some changes, commits, pushes
> 
> Do not push into checked out branch!

Push is the only non-local operation, that could break the checked out state,
right? Than it should be possible to add a check that a push is trying to
change the checked-out ref and detach the HEAD if so.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]