git pull with "no common commits" : danger?

Hello,

I mistakenly pulled a project into another project. I had the
"warning: no common commits" but the pull did proceed.
I am wondering if, from a usability point of view, it would be
best to avoid doing so by default.

Thanks,

  -- aghiles

Aghiles venit, vidit, dixit 08.04.2010 09:56:

Hello,

I mistakenly pulled a project into another project. I had the
"warning: no common commits" but the pull did proceed.
I am wondering if, from a usability point of view, it would be
best to avoid doing so by default.

Puleeezze: No animals were harmed during the process, right? I mean, no
data loss, all you have to do is a git reset. Let's try and not make Git
into "Are you sure"dom.

Michael

Aghiles venit, vidit, dixit 08.04.2010 09:56:

quoted

Hello,

I mistakenly pulled a project into another project. I had the
"warning: no common commits" but the pull did proceed.
I am wondering if, from a usability point of view, it would be
best to avoid doing so by default.

Puleeezze: No animals were harmed during the process, right? I mean, no
data loss, all you have to do is a git reset. Let's try and not make Git
into "Are you sure"dom.

How many times did you see that message? If you saw it, it was probably a
mistake. I think that it is a safe bet to assume that whoever does that won't
complain to type something like: git pull --no-common-commits-ok

I manage many git projects and this happens from time to time, mainly
because of tiredness. I simply consider the proposed behaviour more
natural.

Git is not the bare bone tool set anymore, it aspires into becoming a user
friendly tool, usable by "the masses". And don't worry, following some simple
usability rules won't make git less "cool".

Now, that was just a suggestion,

  -- aghiles

Hi,

Aghiles wrote:

I mistakenly pulled a project into another project. I had the
"warning: no common commits" but the pull did proceed.

First: you are aware that interrupting the pull will have no bad
side-effects, right?  So if the worry is lost time, then git is not
advertising its features well enough.

Because of this, if ‘git fetch’ starts refusing to fetch when there
are no common commits, I will be unhappy, because it imposes hassle on
the user for basically no benefit.

On the other hand, ‘git pull’ is a little different.  The fetch has
very little cost because it’s interruptible, but the merge could
result in two unrelated pieces of history being merged, requiring
the user to use ‘git reset --keep HEAD^’ to get back to the
previous state.  A more likely outcome is a merge conflict, requiring
‘git reset --merge’ to recover.

Can we make this less painful?  Is it worth adding yet another option
to ‘git pull’ to avoid this pain?  I don’t know.

Regards,
Jonathan

Jonathan Nieder [off-list ref] writes:

...

On the other hand, ‘git pull’ is a little different.  The fetch has
very little cost because it’s interruptible, but the merge could
result in two unrelated pieces of history being merged, requiring
the user to use ‘git reset --keep HEAD^’ to get back to the
previous state.  A more likely outcome is a merge conflict, requiring
‘git reset --merge’ to recover.

Can we make this less painful?  Is it worth adding yet another option
to ‘git pull’ to avoid this pain?  I don’t know.

That is exactly the case I was talking about.  I never lost any data
because of this and considering what Junio Hamano is saying I
probably should just continue to do the 'git reset'.

  -- aghiles