Re: Newbie grief

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Fri, May 4, 2012 at 11:29 PM, Rich Pixley <rich.pixley@xxxxxxxx> wrote:
> On 5/4/12 1:45 PM, Felipe Contreras wrote:
>> It doesn't matter how you look at it; 'push -f' is not ideal.
> Push -f offers an alternative

A crappy alternative.

> that is available in other source code control systems, (not just mercurial),

Which other systems? monotone? That doesn't say much.

> but not in git.  It's a bit of a culture
> shock to discover that it's not available in git.

If you don't find a crappy problematic feature in git that you rely
on--that's your problem.

>> In the git world there's many ways to resolve this; push to another
>> branch, push to another repo, allow ssh access to your machine, send
>> the changes by mail, copy the git repo to a shared location, etc.
>> *All* of those alternatives are better than 'push -f'.
> In your opinion, and that's fine.  I don't need to argue this point any
> longer.  All of those other solutions are also available in the other source
> code control systems too.

And they are preferred, even the mercurial documentation says you
should avoid 'push -f'.

It seems you are the only one that thinks 'push -f' is ideal.

>> It seems to me that this *huge* thread basically boils down to Rich
>> wanting 'hg push -f', when clearly that just creates problems, even in
>> mercurial.
> Actually, I wanted a work flow that was functional for me and supported a
> shared branch between multiple repositories.  I think I have a process for
> that now.  The key things I've learned so far are:
> * Git can't cope with repository collisions, (in essence, because it's not
> willing to ever create multiple heads, but also because it doesn't track the
> entire pedigree of a branch, and because destructive rewrites on the
> repository are common in typical git usage).

Wrong. Git copes with collisions just fine; you don't need multiple
heads, multiple heads are bad, even in mercurial, even mercurial
documentation says so. You merge before you push; easy.

> The usual way to deal with this in the git world is to use geographical
> branches and triangles everywhere,

Again wrong. The usual way is to have feature branches:

% git checkout -b rich-reorganize-foo
% git push origin rich-reorganize-foo

> but using "mege before push" can provide
> a way to use shared branches within git, (provided you can live within a
> fair number of restrictions, which I probably can.)

That's the preferred way in mercurial too; it's the sane way to do it.

> * That that cryptic message means that git would need to cope with a
> repository collision, which it can't do.  It doesn't actually mean that the
> repository is corrupt, which is what I took it to mean.
> Frankly, if the cryptic message had been clearer, I probably would never
> have posted here.  I'd likely have figured out that git had this restriction
> and found a way to work around it on my own.

Stop thinking your opinion is truth, and stop playing with words.
Mercurial has the "restriction" that you can't push to a repository
where you don't have permissions; that might be a restriction to
somebody, but using the word restriction to describe that situation
would be a cheap rhetorical device to be abrasiveness against

In mercurial and in git you should merge before you pull, if you don't
like to be forced to do the sane thing; go use mercurial and be happy
with the pain you create to yourself.

And BTW, this is the clear message from mercurial:
abort: push creates new remote head 6d2eb0a6a278!

Not cryptic at all!

Personally I don't care, I know a collision when I see it. If you want
to help improve the error message, feel free to participate in the
other thread that is meant for that. As for the workflow it's clear
that the git workflow is a bit simpler than mercurial one, you just
want to make your life difficult with 'hg push -f', and if you want to
shoot yourself in the foot, you have mercurial for that (even though
it's not recommended there either).

Felipe Contreras
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Newbies FAQ]     [Linux Kernel Development]     [Free Online Dating]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Free Online Dating]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]     [Linux Resources]

Add to Google