git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: gapon <gapon007@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Benoit Sigoure <tsuna@lrde.epita.fr>, git@vger.kernel.org
Subject: Re: git bug/feature request
Date: Tue, 27 Nov 2007 13:50:38 +0100	[thread overview]
Message-ID: <200711271350.38468.gapon007@gmail.com> (raw)
In-Reply-To: <fih0cd$d31$1@ger.gmane.org>

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

  reply	other threads:[~2007-11-27 12:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-27 10:27 git bug/feature request gapon
2007-11-27 10:57 ` Benoit Sigoure
2007-11-27 11:16   ` gapon
2007-11-27 11:51     ` Jakub Narebski
2007-11-27 12:50       ` gapon [this message]
2007-11-27 13:31         ` Jakub Narebski
2007-11-27 13:38           ` Jakub Narebski
2007-11-27 14:06           ` gapon
2007-11-27 11:21 ` Alex Riesen
2007-11-27 11:31   ` gapon
2007-11-27 13:03     ` Alex Riesen
2007-11-27 13:45       ` gapon
2007-11-27 16:36         ` Alex Riesen
2007-11-27 11:30 ` Jakub Narebski
2007-11-30 18:21   ` Jan Hudec
2007-11-27 14:35 ` Peter Karlsson
2007-11-27 14:38   ` David Kastrup
2007-11-28 13:30     ` Peter Karlsson
2007-11-27 15:13   ` Jakub Narebski
2007-11-27 19:49     ` Steven Grimm
2007-11-27 20:19       ` Daniel Barkalow
2007-11-27 20:34 ` Daniel Barkalow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200711271350.38468.gapon007@gmail.com \
    --to=gapon007@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=tsuna@lrde.epita.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).