Newbie grief

Newbie grief

[Rich Pixley]

Hey.  I'm a newbie struggling to understand git.

I'm trying to do what seems like a simple thing in darcs, monotone, 
mecurial, gnu arch, etc, but seems nearly impossible in git.  There's a 
central repository, a long ways away on the other side of the internet.  
So I want a local repository cache.  I'm going to be working on a number 
of different features and different machines all simultaneously so I 
really don't want them all to be pulling from the central repository.

In other systems, this is a simple star network.  Clone a repository, 
use, push, pull, etc.  But with git, I can't push unless the cache 
repository is bare, but if the cache repository is bare, then a change 
to the central repository will cause the two to become wedged since 
neither can push or fetch the other.  It seems that git is allergic to 
the dual head branch solution or something, which is surprising and 
disappointing.

How do other people address these situations in git?

--rich

Re: Newbie grief

[Seth Robertson]

In message <4F9F128C.5020304@palm.com>, Rich Pixley writes:

    Hey.  I'm a newbie struggling to understand git.

    I'm trying to do what seems like a simple thing in darcs, monotone,
    mecurial, gnu arch, etc, but seems nearly impossible in git.  There's a
    central repository, a long ways away on the other side of the internet.
    So I want a local repository cache.  I'm going to be working on a number
    of different features and different machines all simultaneously so I
    really don't want them all to be pulling from the central repository.

Are you working with anyone else locally?  If not, then what you are
probably really trying to do is save time on fetches, so that the
latest changes are more likely to be nearby than far away.

What I would do is set up a bare backup/--mirror repository of the
upstream locally and have it automatically kept up to date with cron
or something like that.  Then you can have your pull URL point to this
mirror and the push URL point to the real upstream.  This will work as
long as the real upstream and the local mirror are not out of date (if
they are, you will be forbidden to push without either pulling from
the real upstream or wait for the next cron fetch and pull from your
local mirror).

This works, but requires that you separate your fetch and push URLs.
Another option is to use git "alternates" to have your local
repository also look at the automatically updated repository so that
you would only fetch over-the-network-changes since the last automatic
fetch (which, unless you had the cache have an alternate for the
primary repository, would mean that the changes would be transferred
twice).

Alternates can be problematic if you start moving repositories around
or delete them or whatever since the repository with the dangling
alternate will then be bad (until the objects reappear one way or
another), so perhaps you just want a cron job to `git fetch` or `git
remote update -p` in your local repository every so often.  Then you
can just `git merge` or `git rebase` to get the latest changes instead
of `git pull [--rebase]`.  This is really the simplest solution.  No
extra repositories, no configuration changes, just straightforward git
operations.  The only trick would be race conditions between you (as a
human) reviewing the latest changes and then typing the command to
merge/rebase them into your local branch and the cron job updating the
remote—seeing what happened afterwords would of course work.  I would
probably try this first and only start using the others if this became
problematic for some reason.

None of these cases specifically handles trying to automate pushes,
mostly because it cannot always be automatically resolved (and
depending on local standards on running test suites before any change
is pushed, perhaps should not ever be automatically resolved even for
trivial conflicts) if changes appear on the real upstream between your
last pull and your next push.

Could it be done?  Sure.  You can push to your local upstream and then
have it push out automatically, but if there are conflicts you will
need to deal with them, and I would suggest doing so with a bare
repository, essentially by having a static preference for the
real-upstream's changes and have the cron job send mail to you telling
you to re-pull and re-push if it failed to push out due to the remote
having changed (telling you the ref/SHA1 that it failed to push).

Of course, this isn't *that* different from just sticking a `git push`
into the background which sends mail/notifies if the push failed for
some reason, and again doing so would be much easier than an
intermediary repository solution.

    But with git, I can't push unless the cache repository is bare,
    but if the cache repository is bare, then a change to the central
    repository will cause the two to become wedged since neither can
    push or fetch the other.

Not strictly speaking true.  By default git will forbid pushes to
non-bare repositories (see receive.denyCurrentBranch in man
git-config) since without special automation the working directory
will get out of date.  See http://bare-vs-nonbare.gitrecipes.de/ for
more information.  However, I cannot think that having to perform
integration in this second repository would actually work.

    It seems that git is allergic to the dual head branch solution or
    something, which is surprising and disappointing.

Git tracks your version of master separately from each other remote's
master.  This is exactly dual/multiple heads.  What git *does* forbid
(by default) is:

1: Letting you update someone else's checked out (non-bare) repository
underneath them

2: Letting you update someone else's repository if they have more
recent changes than you do.

Both of these defaults are really good ideas, but you can disable them
if you think you know better.

					-Seth Robertson

Re: Newbie grief

[Jan Krüger]

Hi Rich,

On 05/01/2012 12:30 AM, Rich Pixley wrote:
> I'm trying to do what seems like a simple thing in darcs, monotone,
> mecurial, gnu arch, etc, but seems nearly impossible in git.  There's a
> central repository, a long ways away on the other side of the internet. 
> So I want a local repository cache.  I'm going to be working on a number
> of different features and different machines all simultaneously so I
> really don't want them all to be pulling from the central repository.
> 
> In other systems, this is a simple star network.  Clone a repository,
> use, push, pull, etc.  But with git, I can't push unless the cache
> repository is bare, but if the cache repository is bare, then a change
> to the central repository will cause the two to become wedged since
> neither can push or fetch the other.

If the 'cache repository' is set up using "git clone --mirror" and you
push to the primary repository only, that makes the cache repo a
definite slave, so you can always run "git fetch" on it without any
trouble. You can even enforce this by denying all pushes to the cache
repo, thus eliminating any chance of accidental misuse.

Conveniently, git allows you to specify a different URL for fetch and
push in your local working repositories.

HTH,
Jan

Re: Newbie grief

[Rich Pixley]

Thank you for the info and the help.  Just one argument...

On 4/30/12 16:31 , Seth Robertson wrote:
>      It seems that git is allergic to the dual head branch solution or
>      something, which is surprising and disappointing.
>
> Git tracks your version of master separately from each other remote's
> master.  This is exactly dual/multiple heads.

No, it isn't at all.

Multiple heads are the idea that a single commit can "branch" in the 
repository and that both commits can be HEADS of the same branch at once 
in a single repository.  This allows a potential collision to exist in 
the repository and to be pushed and pulled through multiple 
repositories.  It also largely eliminates this entire discussion since 
each of the intermediate repositories between, say, you and I can carry 
the collision.  Either you or I, at will, can merge these heads just 
like we'd merge any other two commits, push/fetch, etc.

That would seem to be the obvious and intuitive behavior, rather than 
arbitrarily preventing the transfer.

 >  What git *does* forbid
> (by default) is:
>
> 1: Letting you update someone else's checked out (non-bare) repository
> underneath them

Yeah.  That "underneath them" thing is confusing.  I don't see any 
reason why that should necessarily be so.

Git knows what commit is checked out.  That's HEAD, yes?  So what's 
wrong with letting it collect other commits from other repositories 
while your working directory sits?  You can always commit your change 
right on top of what's checked out, creating a second head for that branch.

Yes, I've read that git-diff, etc, are all making assumptions that fail 
in this case, but there's nothing significantly different about 
collecting commits to other branches and collecting commits to the 
branch you're currently checked out from.  Either way, you're going to 
need to merge those into your working directory before committing your 
current changes will make much semantic sense.  And if you don't want to 
do that, you can always commit them directly onto HEAD, and thereby 
create a new branch, at least temporarily.  That's one of the huge 
advantages of the daggy architecture.

> 2: Letting you update someone else's repository if they have more
> recent changes than you do.

Again, if they have more recent changes, then my line of changes should 
create a fresh HEAD on that branch.  Then the repositories hold all of 
our changes to be merged at our leisure.

 From a UI perspective, that request has a valid, and relatively obvious 
semantic.  That git simply refuses to do anything except produce a 
cryptic error message seems... well, sad.

> Both of these defaults are really good ideas, but you can disable them
> if you think you know better.

I know better for source code control systems that support the multiple 
HEAD concept.  I don't know better for git.  So far, it looks to me as 
though git is just plain failing here.

I thank you for your suggestions.  It'll take me a few readings before I 
follow them all.  Regardless of how I think git _should_ behave, I'll 
still need to figure something, so thank you.

--rich

Re: Newbie grief

[Junio C Hamano]

Rich Pixley <rich.pixley@palm.com> writes:

>> Git tracks your version of master separately from each other remote's
>> master.  This is exactly dual/multiple heads.
>
> No, it isn't at all.
>
> Multiple heads are the idea that a single commit can "branch" in the
> repository and that both commits can be HEADS of the same branch at
> once in a single repository.  This allows a potential collision to
> exist in the repository and to be pushed and pulled through multiple
> repositories.

I think your "not at all" thinking is a bit tainted by your knowing very
well how Hg does things, but I do not think there is much fundamental
difference between what we do.  Git just tends to be a bit more explicit
and encourages users to be also be more explicit.

When you integrate from the other side (say, "origin") by pulling, instead
of splitting the 'master' branch into two (i.e. ours and origin's), we
store what came from the origin in remotes/origin/master and let the user
merge it into his heads/master.  Essentially, the same name 'master' is
split into two, between remotes/origin/ and heads/ namespace.  We are just
more explicitly about the split.

Similarly, when pushing, you could follow the same model by pushing your
change into remotes/pixley/master, instead of pushing directly to the
"master" branch, i.e. heads/master, and then merge the former to the
latter after push succeeds.

Needless to say, you do not have to limit the splitting just to two.
Since everything is named, you can tell where each 'master' came from by
looking at the namespace (obviously this requires people to establish and
follow the naming convention).

Re: Newbie grief

[Seth Robertson]

In message <4F9F28F5.2020403@palm.com>, Rich Pixley writes:

    On 4/30/12 16:31 , Seth Robertson wrote:
    >      It seems that git is allergic to the dual head branch solution or
    >      something, which is surprising and disappointing.
    >
    > Git tracks your version of master separately from each other remote's
    > master.  This is exactly dual/multiple heads.
    No, it isn't at all.

    Multiple heads are the idea that a single commit can "branch" in the
    repository and that /both /commits can be HEADS of the same branch at
    once in a single repository.  This allows a potential collision to exist
    in the repository and to be pushed and pulled through multiple
    repositories.  It also largely eliminates this entire discussion since
    each of the intermediate repositories between, say, you and I can carry
    the collision.  Either you or I, at will, can merge these heads just
    like we'd merge any other two commits, push, etc.

    That would seem to be the obvious and intuitive behavior, not
    arbitrarily preventing the transfer.

I still don't see how git isn't providing this to you, with the caveat
that in git, a single commit with a specific SHA1 hash is constant.
You may modify it (making it a new commit), modify its history (making
it a new commit), or add new commits after it.  Git doesn't number
commits the way other VCS do, which may be the source of confusion.

A specific commit with a specific SHA1 can be at the head of multiple
branches.  Those branch may be local to the repository, local tracking
branches, or remote tracking branches.

Contrarywise, the head of the "master" (or any) branch (or ref) may
point to any SHA1.  My master branch may point to one SHA1, yours may
point to another.  You can look at my version of master and I can look
at your version of master (permissions permitting).  After appropriate
network operations, either you, or I, at will, can merge these heads
just like we'd merge any other two commits, push, etc.  With
appropriate naming conventions, we can even continue parallel updates
where I can make updates to your version of master and you can make
updates to my version of master, in addition to our own.

For example, in the diagram http://mercurial.selenic.com/wiki/Head
rev2 might be your version of master and rev3 might be my version.
Both might exist in my repository and both might exist in your
repository, and both might have the symbolic name "master" associated
with it, and git would keep it entirely straight.

    >    What git *does* forbid
    > (by default) is:
    >
    > 1: Letting you update someone else's checked out (non-bare) repository
    > underneath them
    Yeah.  That "underneath them" thing is confusing.  I don't see any
    reason why that should necessarily be so.

    Git knows what commit is checked out.  That's HEAD, yes?  So what's
    wrong with letting it collect other commits from other repositories
    while your working directory sits?

It does!  It can! What is forbidden is for me update what you have
checked out.  Can you conceive of a revision control system where I
commit I would make would change what you have checked out?  (Well, I
can, ClearCase with dynamic views, and it is more horrible than you
can imagine—I've had compile fail because the files changed underneath
my feet between the start of the compile and the end of the compile).
And what happens if the file I changed is also the file you are in the
middle of changing?  Is your change going to overwrite mine?  Is mine
going to overwrite yours?  This way leads to insanity.

    You can always commit your change right on top of what's checked
    out, creating a second head for that branch.

With git, you must always commit your change right on top of what's
checked out, though of course you may decide to change what's checked
out and "float" the changes you made over to the new head (trivial, as
long as there are not conflicts between the two heads and the changes
you made).  However, only the user of the repository is allowed to do
this.  A remote user is not allowed to change what's checked out.

    Yes, I've read that git-diff, etc, are all making assumptions that fail
    in this case, but there's nothing significantly different about
    collecting commits to other branches and collecting commits to the
    branch you're currently checked out from.

Yes there is.  Consider this use case.  You can I both spot DIFFERENT
bugs.  You and I both start editing filea.  I fix my problem one way
which involves lines 10, 100, and 500, you fix your problem which
involves line 10, 100, and 200.  I'm typing faster than you so I
commit/push first.  If I can update your HEAD, at that point I've
changed the file you are editing. You save and my change is lost.

Now this is where you say, if git only supported multiple HEADs the
problem would go away.  I could update my version of master and you
could update your version of master and there would be no conflict.
And...of course you can with git.  I don't update your master, what
you have checked out, I update what you know is my master.  Then when
you are done, you get to say "merge my master with your master" or
"instead of committing this change on my branch, let me try this last
change I made on top of the changes you made" or whatever you want to
say.

    > 2: Letting you update someone else's repository if they have more
    > recent changes than you do.
    Again, if they have more recent changes, then my line of changes should
    create a fresh HEAD on that branch.  Then the repositories hold all of
    our changes to be merged at our leisure.

And...git does this.  Your changes are made on your HEAD (your
branch).  My changes are made on my HEAD (my branch).  Never the twain
shall meet until someone says "merge" (or "rebase").

The key to all of this is the namespace naming convention.
refs/remotes/<remotename>/<branchname> (or more informally
<remotename>/<branchname>) is a remote tracking branch, or my idea of
what your branches (HEADs) currently are.  These are (kinda/sorta)
read-only reference which are only updated when you specifically ask
them to be updated, or if I decide to update what you believe I have
(kinda rude, but allowed).

So let us consider a specific example.  There is a repository which
everyone call's "Rich" (they don't need to use the same name, but it
reduces confusion), a repository everyone calls "Seth", and a central
repository everyone calls "origin".

Location   Branchname
--------   ----------
origin     foo		(bare)
rodger	   foo
rodger	   origin/foo
rodger	   seth/foo
seth	   foo
seth	   origin/foo
seth	   rodger/foo

I make a change in my foo.  I can push the change into origin's foo,
rodger's seth/foo (and technically origin/foo but that is more than
just rude).  You can take my change and store it in seth/foo.

At any point, after you have the changes (either because I push them
or you fetch them) you can then merge your work with my work.

So...what's not possible?

					-Seth Robertson

Re: Newbie grief

[Rich Pixley]

On 4/30/12 18:32 , Junio C Hamano wrote:
> Rich Pixley<rich.pixley@palm.com>  writes:
>
>>> Git tracks your version of master separately from each other remote's
>>> master.  This is exactly dual/multiple heads.
>>
>> No, it isn't at all.
>>
>> Multiple heads are the idea that a single commit can "branch" in the
>> repository and that both commits can be HEADS of the same branch at
>> once in a single repository.  This allows a potential collision to
>> exist in the repository and to be pushed and pulled through multiple
>> repositories.
>
> I think your "not at all" thinking is a bit tainted by your knowing very
> well how Hg does things,

Actually, I came up with the same design back in the early 90's when I 
was working on CVS.  I think the hg way of doing things is pretty 
obvious once we think about it.  You can't expect users to do manual 
merges on a remote server.  So the only thing you can reasonably do is 
collect and propagate the collision with enough info that a human being 
can put it back together later.  Refusing the commit doesn't seem 
reasonable to me.

The old approach from clearcase multisite where every repository owns 
it's own unique branch, which shows up as a read-only branch in the 
other repositories, is a nuisance because you have to constantly keep 
merging or your geographic partitions drift.  It's difficult enough to 
keep disparate groups working in concert.  Forcing them to do big merges 
in batch frequently doesn't help.  That's essentially what we're reduced 
to with git.

The illusion that we're all working on the same branch, (mercurial, 
monotone, etc), defaults to more frequent merges, and a much smaller 
change tree when it comes to visualization.

> but I do not think there is much fundamental
> difference between what we do.  Git just tends to be a bit more explicit
> and encourages users to be also be more explicit.
>
> When you integrate from the other side (say, "origin") by pulling, instead
> of splitting the 'master' branch into two (i.e. ours and origin's), we
> store what came from the origin in remotes/origin/master and let the user
> merge it into his heads/master.  Essentially, the same name 'master' is
> split into two, between remotes/origin/ and heads/ namespace.  We are just
> more explicitly about the split.

I wouldn't call it explicit.  That level of detail provides no features. 
  It's tedious extra work that could have been tracked and managed 
automatically.  The fact that it isn't tracked and managed automatically 
prevents simple repository chaining of the sort I originally set out to 
accomplish.

> Similarly, when pushing, you could follow the same model by pushing your
> change into remotes/pixley/master, instead of pushing directly to the
> "master" branch, i.e. heads/master, and then merge the former to the
> latter after push succeeds.

That presupposes that I own both repositories rather than working in a 
cooperative environment.

> Needless to say, you do not have to limit the splitting just to two.
> Since everything is named, you can tell where each 'master' came from by
> looking at the namespace (obviously this requires people to establish and
> follow the naming convention).

Right.  This is the sort of thing people write source code control 
systems to manage.  :).

--rich

Re: Newbie grief

[Rich Pixley]

On 4/30/12 18:37 , Seth Robertson wrote:
> For example, in the diagram http://mercurial.selenic.com/wiki/Head
> rev2 might be your version of master and rev3 might be my version.
> Both might exist in my repository and both might exist in your
> repository, and both might have the symbolic name "master" associated
> with it, and git would keep it entirely straight.

But not in the same repository. And therein lies the issue.

>      >     What git *does* forbid
>      >  (by default) is:
>      >
>      >  1: Letting you update someone else's checked out (non-bare) repository
>      >  underneath them
>      Yeah.  That "underneath them" thing is confusing.  I don't see any
>      reason why that should necessarily be so.
>
>      Git knows what commit is checked out.  That's HEAD, yes?  So what's
>      wrong with letting it collect other commits from other repositories
>      while your working directory sits?
>
> It does!  It can!

To the branch you have checked out?  That's what I want!  How do I do that?

> What is forbidden is for me update what you have
> checked out.

There's some ambiguity in your sentence here.  I don't know whether 
you're referring to my being forbidden from modifying your working 
directory or whether you're referring my being forbidden to modify the 
branch from which your working directory is checked out.  I understand 
and respect the former, but the latter seems arbitrary.

(I think clearcase already answered the dynamic update problem.  I liked 
it.  And I especially liked clearmake and build avoidance.  Shame that 
IBM killed it.  (Oh, and if you had inconsistent builds, then you 
weren't using clearmake.  Clearmake solved that problem.))

I'm less concerned about whether my push changes your working directory. 
  I'm fine with leaving your working directory as is and letting you 
decide when and how to move forward on your own time.

Perhaps part of the problem here is the unfortunate choice of the word 
"HEAD" to refer to the thing you have checked out when that commit might 
not be a childless commit at all.  When I say "create another head" I 
mean, "create a childless commit on the same branch".

>      You can always commit your change right on top of what's checked
>      out, creating a second head for that branch.
>
> With git, you must always commit your change right on top of what's
> checked out, though of course you may decide to change what's checked
> out and "float" the changes you made over to the new head (trivial, as
> long as there are not conflicts between the two heads and the changes
> you made).  However, only the user of the repository is allowed to do
> this.  A remote user is not allowed to change what's checked out.

Ok, how do I ask git to push a commit into the middle of a branch that 
you have checked out at a tip, (there's always exactly one tip for any 
branch in git, right?)?  I don't care to change your working directory 
nor your index.  I just want my commits to show up in the middle of that 
branch.

>      Yes, I've read that git-diff, etc, are all making assumptions that fail
>      in this case, but there's nothing significantly different about
>      collecting commits to other branches and collecting commits to the
>      branch you're currently checked out from.
>
> Yes there is.  Consider this use case.  You can I both spot DIFFERENT
> bugs.  You and I both start editing filea.  I fix my problem one way
> which involves lines 10, 100, and 500, you fix your problem which
> involves line 10, 100, and 200.  I'm typing faster than you so I
> commit/push first.  If I can update your HEAD, at that point I've
> changed the file you are editing. You save and my change is lost.

"HEAD", being defined as the thing I have checked out, should not be 
changed, I agree.

But the nomenclature here is a bit misleading.  Really, "HEAD" could be 
any commit.  It doesn't have to be a childless commit.  The fact that my 
HEAD was childless at the time I checked it out doesn't necessarily mean 
that it must remain childless forever.

Let's back it up a moment.  I change file1 and you change file2.  These 
are non-colliding changes.  They can be trivially merged and yet git 
refuses to push between our repositories.

The refusal seems arbitrary.  It could just as easily accept my change, 
leave your HEAD pointing where it was, but move the "master" pointer to 
point to the merged commit.  This is exactly what it does if I pull your 
changes into my repository.  I just can't ever push them again after 
this happens.  (I could push them previously.)

> Now this is where you say, if git only supported multiple HEADs the
> problem would go away.

Right.

> I could update my version of master and you
> could update your version of master and there would be no conflict.

There'd be a conflict.  But we'd be able to update anyway.  I'd be able 
to see your changes in my repository by default.  You'd be able to see 
mine.  And either one of us could merge, commit, and push the merge. 
Until then, the collision could be carried and propagated by multiple 
repositories around our repository network.  Maybe a third person would 
integrate them for us.

> And...of course you can with git.  I don't update your master, what
> you have checked out, I update what you know is my master.  Then when
> you are done, you get to say "merge my master with your master" or
> "instead of committing this change on my branch, let me try this last
> change I made on top of the changes you made" or whatever you want to
> say.

Yes.  And I have no choice.  I must say that at every repository I own, 
every time I push or pull changes, tracking whether those have been 
merged or not, even when 99% of my changes could have been trivially 
merged, owned by me, in repositories I own.  And I'm forced to do manual 
merges and extra pulls in the most common collision situation I run 
into, which can be handled automatically by other systems like 
mercurial, even subversion.

My problem is that I must necessarily manage 10's of repositories for my 
own work.  These extra steps mean a geometric increase in complexity and 
in error potential over something like mercurial, which maintains the 
"common branch" illusion automatically for me or something like 
subversion which genuinely has a common branch.

I don't need separate branches for each repository.  What I really want 
is a common branch whose changes I can push back and forth between the 
various repositories, or coordinate through a central cache, without 
worrying about the underlying details that git is forcing me to confront.

I think I'm beginning to understand what git does offer now.  Thank you 
for the help with clarifications.  I just don't like it.  It's a huge 
let down for me in my context from working with systems like mercurial 
which make my life easier.  Quite frankly, git is a huge amount of work 
for me by comparison to mercurial for no added benefit, or even by 
comparison to subversion, with only minor benefits in most situations 
over subversion.

> So...what's not possible?

In effect, any interesting activities involving push or any workflows 
that require pushing.  Most of them can probably be worked around by 
using a pull architecture instead, but that adds an unnecessary 
explosion of complexity in many cases such as the one I'm facing.

In particular, sharing a branch becomes problematic with git.

--rich

Re: Newbie grief

[Sitaram Chamarty]

I've been reading the thread with interest.

People who know far more than I do about git, its innards, and its
design have been responding in this thread so consider this a git
*user*'s point of view:

On Tue, May 1, 2012 at 6:45 AM, Rich Pixley <rich.pixley@palm.com> wrote:

> Multiple heads are the idea that a single commit can "branch" in the
> repository and that both commits can be HEADS of the same branch at once in
> a single repository.  This allows a potential collision to exist in the
> repository and to be pushed and pulled through multiple repositories.  It

That is bizarre; I have no other word for it.

I teach git (occasionally), and if this feature existed I would
totally ignore it in my teaching material because I wouldn't know how
to defend or explain the need for "hydra branches".

It's like having two people with the same first name *and* last name
(a situation that is not impossible in real life, but is rare and
almost always requires special handling).

Does Hg do this?  That would explain why my (admittedly half-hearted)
attempts to learn it have failed -- whatever tutorial I used must have
been written with the idea that hydra branches are intuitive and
logical and sane, but did not express the concept as clearly and
succinctly as you did.

Thanks for this insight; my next attempt to understand Hg, should I
ever be forced into it, might actually succeed!

Re: Newbie grief

[Michael Witten]

On Mon, 30 Apr 2012 20:04:25 -0700, Rich Pixley wrote:

> I don't need separate branches for each repository.  What I really want 
> is a common branch whose changes I can push back and forth between the 
> various repositories, or coordinate through a central cache, without 
> worrying about the underlying details that git is forcing me to confront.

Here's a start for a more precise discussion.

Sincerely,
Michael Witten


Cache server:

  $ git clone --mirror "$uri_for_central_repo"

Machine A:

  $ git clone "$uri_for_cache_repo"
  $ git checkout -b feature_0 origin/feature_0
  $ # ... do some work ...
  $ git push --set-upstream origin HEAD:shared/feature_0
  $ git config push.default upstream

Machine B:

  $ git clone "$uri_for_cache_repo"
  $ git checkout -b feature_0 origin/feature_0
  $ # ... do some work that conflicts with work done on Machine A...
  $ git push --set-upstream origin HEAD:shared/feature_0
  To $uri_for_cache_repo
   ! [rejected]        HEAD -> shared/feature_0 (non-fast-forward)
   error: failed to push some refs to '$uri_for_cache_repo'
  To prevent you from losing history, non-fast-forward updates were rejected
  Merge the remote changes (e.g. 'git pull') before pushing again.  See the
  'Note about fast-forwards' section of 'git push --help' for details.
  $ git pull origin shared/feature_0
  From $uri_for_cache_repo
   * branch            shared/feature_0 -> FETCH_HEAD
  Auto-merging a
  CONFLICT (add/add): Merge conflict in a
  Recorded preimage for 'a'
  Automatic merge failed; fix conflicts and then commit the result.
  $ # ... resolve conflict and commit results ...
  $ git push --set-upstream origin HEAD:shared/feature_0
  $ git config push.default upstream

Machine A:

  $ git pull # pulls in origin's shared/feature_0
  $ # ... do some work ...
  $ git push # pushes to origin's shared/feature_0

Machine B:

  $ git pull # pulls in origin's shared/feature_0
  $ # ... do some work ...
  $ git push # pushes to origin's shared/feature_0

Machine A:

  $ git pull
  $ git remote add central "$uri_for_central_repo"
  $ git push central HEAD:feature_0 # Assume there is a conflict
  To $uri_for_central_repo
   ! [rejected]        HEAD -> feature_0 (non-fast-forward)
  error: failed to push some refs to '$uri_for_central_repo'
  To prevent you from losing history, non-fast-forward updates were rejected
  Merge the remote changes (e.g. 'git pull') before pushing again.  See the
  'Note about fast-forwards' section of 'git push --help' for details.
  $ git pull central feature_0
  $ # ... resolve conflict and commit results ...
  $ git push central HEAD:feature_0 # Assume it succeeds this time
  $ # Let's update the cache repo from Machine A:
  $ git fetch central
  $ git push origin 'refs/remotes/central/*:refs/heads/*'

Machine B:

  $ git pull
  $ git pull . origin/feature_0 # Get new stuff cached from central server

Re: Newbie grief

[Junio C Hamano]

Michael Witten <mfwitten@gmail.com> writes:

> Here's a start for a more precise discussion.

When does the "Cache server" updated from the "$uri_for_central_repo" in
this picture?  If it is after push by either from Machine A or B, somebody
needs to reconcile that and whatever A/B pushed.

And between Hg style "split head" or Git style refs/remotes/* namespaces
there is no difference to perform that reconcilation.  Somebody needs to
run "merge" on the "Cache server" and at some point the result needs to be
pushed to the $uri_for_central_repo back.

So...

Re: Newbie grief

[Michael Witten]

On Tue, May 1, 2012 at 06:21, Junio C Hamano <gitster@pobox.com> wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> Here's a start for a more precise discussion.
>
> When does the "Cache server" updated from the "$uri_for_central_repo" in
> this picture?  If it is after push by either from Machine A or B, somebody
> needs to reconcile that and whatever A/B pushed.
>
> And between Hg style "split head" or Git style refs/remotes/* namespaces
> there is no difference to perform that reconcilation.  Somebody needs to
> run "merge" on the "Cache server" and at some point the result needs to be
> pushed to the $uri_for_central_repo back.
>
> So...

Examples of pushing to the central repo and updating the cache repo
are given at the bottom.

Re: Newbie grief

[Ted Ts'o]

On Tue, May 01, 2012 at 09:14:24AM +0530, Sitaram Chamarty wrote:
> 
> > Multiple heads are the idea that a single commit can "branch" in the
> > repository and that both commits can be HEADS of the same branch at once in
> > a single repository.  This allows a potential collision to exist in the
> > repository and to be pushed and pulled through multiple repositories.  It
> 
> That is bizarre; I have no other word for it.
> 
> I teach git (occasionally), and if this feature existed I would
> totally ignore it in my teaching material because I wouldn't know how
> to defend or explain the need for "hydra branches".

I wouldn't use the verb branch (and certainly not "hydra branch"),
because it's confusing to someone who thinks this has something to do
with noun "branch".  But that's a confusion because of the english, or
rather the terminology that was used.

I would put it this way.  Every non-merge commit has a parent (we'll
ignore merge commits for now).  When you look at that commit via "git
show <commit-id>", what you see is the diff between its parent and the
state of the source tree as described by that commit-id.  If you put
it this way, it becomes obvious that a particular parent commit can
have multiple child commits.  (This seems to be what you are calling
"hydra branches".)

A branch is a pointer to a commit.  When you add a commit to a branch,
you are adding a new commit whose parent is pointing to the current
branch head, and afterwards, the branch head pointer is changed to
point at the new commit.

> Does Hg do this?  That would explain why my (admittedly half-hearted)
> attempts to learn it have failed -- whatever tutorial I used must have
> been written with the idea that hydra branches are intuitive and
> logical and sane, but did not express the concept as clearly and
> succinctly as you did.

What Hg does is it requires that all terminal commits (commits that do
not have children) must be named by a branch pointer.  So when you
pull in some changes from Hg, there may be a non-terminal commit, but
before the hg pull finishes, it will create a merge commit which
merges the current branch pointer and the newly pulled in commits, so
that when you are done, the branch pointer points at the new merge
commit, and the requirement that there be no non-named terminal
commits is maintained.

Git differs in that you can have a child commit which is not pointed
to by a branch pointer, and which is referred to only by commit-id.
These child commits can disappear on you, when you do a garbage
collection; but it allows you to have multiple child commits hanging
off of a single parent commit, and you can do diffs, cherry picks,
etc.  But they *do* have a unique name --- the commit id, which is a
SHA1 hash of the contents of the diff.

Does this help?

						- Ted

Re: Newbie grief

[Sitaram Chamarty]

On Tue, May 1, 2012 at 4:44 PM, Ted Ts'o <tytso@mit.edu> wrote:
> On Tue, May 01, 2012 at 09:14:24AM +0530, Sitaram Chamarty wrote:
>>
>> > Multiple heads are the idea that a single commit can "branch" in the
>> > repository and that both commits can be HEADS of the same branch at once in
>> > a single repository.  This allows a potential collision to exist in the
>> > repository and to be pushed and pulled through multiple repositories.  It
>>
>> That is bizarre; I have no other word for it.
>>
>> I teach git (occasionally), and if this feature existed I would
>> totally ignore it in my teaching material because I wouldn't know how
>> to defend or explain the need for "hydra branches".
>
> I wouldn't use the verb branch (and certainly not "hydra branch"),

I coined that phrase for what was described as "[multiple] HEADS of
the same branch at once in a single repository".

> it this way, it becomes obvious that a particular parent commit can
> have multiple child commits.  (This seems to be what you are calling
> "hydra branches".)

No.  In git, the multiple child commits you mention are all either
different branches, tags, or they are detached/subject to GC.  At no
time do you actually have the situation he was talking about: a single
branch representing more than one leaf (no children) commit *at the
same time*.

> Git differs in that you can have a child commit which is not pointed
> to by a branch pointer, and which is referred to only by commit-id.
> These child commits can disappear on you, when you do a garbage
> collection; but it allows you to have multiple child commits hanging
> off of a single parent commit, and you can do diffs, cherry picks,
> etc.  But they *do* have a unique name --- the commit id, which is a
> SHA1 hash of the contents of the diff.

Sure.

What the original poster wants is that all these unnamed commits be
magically associated with the branch they were born in, and be
propagated via pushes and pulls.

As I understand it, he would like a one -> many relationship between
branch name and SHA.

Re: Newbie grief

[Rich Pixley]

On 4/30/12 23:21 , Junio C Hamano wrote:
> Michael Witten<mfwitten@gmail.com>  writes:
>
>> Here's a start for a more precise discussion.
> When does the "Cache server" updated from the "$uri_for_central_repo" in
> this picture?  If it is after push by either from Machine A or B, somebody
> needs to reconcile that and whatever A/B pushed.
>
> And between Hg style "split head" or Git style refs/remotes/* namespaces
> there is no difference to perform that reconcilation.  Somebody needs to
> run "merge" on the "Cache server" and at some point the result needs to be
> pushed to the $uri_for_central_repo back.
Untrue.  In the hg style, the reconciliation can happen at any 
repository.  Or never.  It's completely legitimate to allow this "split 
head" to become the beginning of a de facto branch.  The only difference 
between a "split head" and a branch is whether the same branch pointer 
points to both or whether they have different branch pointers.  They can 
even have both.

--rich

Re: Newbie grief

[Rich Pixley]

On 4/30/12 22:32 , Michael Witten wrote:
> On Mon, 30 Apr 2012 20:04:25 -0700, Rich Pixley wrote:
>
>> I don't need separate branches for each repository.  What I really want
>> is a common branch whose changes I can push back and forth between the
>> various repositories, or coordinate through a central cache, without
>> worrying about the underlying details that git is forcing me to confront.
> Here's a start for a more precise discussion.
Thank you.  That might be just what I need in git.

--rich

Re: Newbie grief

[Rich Pixley]

On 5/1/12 04:14 , Ted Ts'o wrote:
> On Tue, May 01, 2012 at 09:14:24AM +0530, Sitaram Chamarty wrote:
>> Does Hg do this?  That would explain why my (admittedly half-hearted)
>> attempts to learn it have failed -- whatever tutorial I used must have
>> been written with the idea that hydra branches are intuitive and
>> logical and sane, but did not express the concept as clearly and
>> succinctly as you did.
>
> What Hg does is it requires that all terminal commits (commits that do
> not have children) must be named by a branch pointer.

No more so than git does.  It's entirely possible to have commits that 
have no branch pointer pointing to them.

> So when you
> pull in some changes from Hg, there may be a non-terminal commit, but
> before the hg pull finishes, it will create a merge commit which
> merges the current branch pointer and the newly pulled in commits, so
> that when you are done, the branch pointer points at the new merge
> commit, and the requirement that there be no non-named terminal
> commits is maintained.

Not so.  What happens is that any commit to a non-terminal commit simply 
succeeds and creates an additional childless commit.  If the new commit 
had a branch pointer, then it continues to have that branch pointer, 
even if another commit already has that branch pointer.  There are just 
multiple childless commits with that branch pointer.

Any merges are initiated manually.  But merging any other childless 
commits is the default for "hg merge".  (And merge commits have two 
parents).

The only merges that are done automatically are the same ones that git 
does on a pull.  These are sort of degenerate merges in the sense that 
they exist entirely in the source code repository graph, there are no 
lexical or file content collisions.

In hg, I can have revision 1 checked out, you can push, (or I can pull), 
revisions 2, 3, and 4 into my repository, and my next update will merge 
2, 3, and 4 into my current working directory, much like with 
subversion.  In git, your push is refused and I can only fetch if I'm 
also willing to merge at that very moment.

> Git differs in that you can have a child commit which is not pointed
> to by a branch pointer, and which is referred to only by commit-id.

Hg can do this too.

> These child commits can disappear on you, when you do a garbage
> collection; but it allows you to have multiple child commits hanging
> off of a single parent commit, and you can do diffs, cherry picks,
> etc.  But they *do* have a unique name --- the commit id, which is a
> SHA1 hash of the contents of the diff.

Same with hg, except that they are persistent and don't disappear on 
garbage collection.

--rich

Re: Newbie grief

[Rich Pixley]

On 5/1/12 09:13 , Sitaram Chamarty wrote:
> On Tue, May 1, 2012 at 4:44 PM, Ted Ts'o<tytso@mit.edu>  wrote:
>> I wouldn't use the verb branch (and certainly not "hydra branch"),
> I coined that phrase for what was described as "[multiple] HEADS of
> the same branch at once in a single repository".
...keeping in mind here that HEAD is a misnomer as HEAD points to the 
currently checked out commit, regardless of where that commit might live 
in the commit graph.  It might be childless, but it might have children.

What I'm talking about is the situation where a branch can have 
multiple, childless commits.  I've switched to calling these "tips" for 
this discussion.
> Sure. What the original poster wants is that all these unnamed commits 
> be magically associated with the branch they were born in, and be 
> propagated via pushes and pulls. As I understand it, he would like a 
> one -> many relationship between branch name and SHA.
Really, what I want is for the push semantic to have a meaning.  I want 
push to work.  I want pull to work even without merging.  I want to be 
able to share a branch between different repositories and different 
users while the source code control system tracks this for me.  And I 
want to create arbitrary network graphs of repositories who all share 
code via push/pull without manual intervention.

These are facilities that we've had in other source code control systems 
for at least a decade.

It seems as though git is tracking all of the info that is needed - 
excepting multiple tips.  The fact that there are converters, including 
dynamic, real time converters, between git repositories and the hg user 
interface suggest that there is, indeed, a near one-to-one mapping 
between mercurial and git.  The only thing that's missing in git is the 
user interface to provide this semantic.  Instead, git simply doesn't do 
what it is asked to do, which seems like a silly user interface choice.

--rich

Re: Newbie grief

[Michael Witten]

On Tue, May 1, 2012 at 18:15, Rich Pixley <rich.pixley@palm.com> wrote:

> I want pull to work even without merging.  I want to be able to share a
> branch between different repositories and different users while the source
> code control system tracks this for me

I believe you are missing the point that a `pull' in git is a `fetch'
followed by a `merge'. You should read about the `fetch' command by
reading (`git help fetch'), and make sure you understand how to use
refspecs; you will probably find it very instructive to play around
by specifying explicit refspecs to `git fetch' rather than relying
on the implicit rules (which can be somewhat confusing).

Re: Newbie grief

[Randal L. Schwartz]

>>>>> "Rich" == Rich Pixley <rich.pixley@palm.com> writes:

Rich> What I'm talking about is the situation where a branch can have multiple,
Rich> childless commits.  I've switched to calling these "tips" for this
Rich> discussion.

But in git, a branch *is* what you're calling a "tip".

What do you find lacking about git branches, in terms of sharing?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: Newbie grief

[Rich Pixley]

On 5/1/12 11:20 , Michael Witten wrote:
> On Tue, May 1, 2012 at 18:15, Rich Pixley<rich.pixley@palm.com>  wrote:
>
>> I want pull to work even without merging.  I want to be able to share a
>> branch between different repositories and different users while the source
>> code control system tracks this for me
>
> I believe you are missing the point that a `pull' in git is a `fetch'
> followed by a `merge'. You should read about the `fetch' command by
> reading (`git help fetch'), and make sure you understand how to use
> refspecs; you will probably find it very instructive to play around
> by specifying explicit refspecs to `git fetch' rather than relying
> on the implicit rules (which can be somewhat confusing).

Yes, I'm aware of the distinction within git.  Confusing is an 
understatement.  It seems that in most cases git has no defaults nor 
implicit rules and when it does, they are frequently surprising or 
unfathomable.  I suppose it's nice that they can be set explicitly, but 
sad that they pretty much must be.

That git uses the word "pull" to mean something different than previous 
source code control systems only adds to the confusion.  I was using 
"pull" in the more general sense of pushing and pulling data, not in the 
very narrow meaning of "git fetch + git merge".

I'm still pretty much lost on refspecs and refs.  The terms are 
apparently not used in the manuals I've been reading and they don't seem 
to be used consistently even within git error messages.

Is "refspec" the git word for the branch pointer that points to the 
childless commit that defines a branch?

--rich

Re: Newbie grief

[Rich Pixley]

On 4/30/12 16:35 , Jan Krüger wrote:
> Hi Rich,
>
> On 05/01/2012 12:30 AM, Rich Pixley wrote:
>> I'm trying to do what seems like a simple thing in darcs, monotone,
>> mecurial, gnu arch, etc, but seems nearly impossible in git.  There's a
>> central repository, a long ways away on the other side of the internet.
>> So I want a local repository cache.  I'm going to be working on a number
>> of different features and different machines all simultaneously so I
>> really don't want them all to be pulling from the central repository.
>>
>> In other systems, this is a simple star network.  Clone a repository,
>> use, push, pull, etc.  But with git, I can't push unless the cache
>> repository is bare, but if the cache repository is bare, then a change
>> to the central repository will cause the two to become wedged since
>> neither can push or fetch the other.
> If the 'cache repository' is set up using "git clone --mirror" and you
> push to the primary repository only, that makes the cache repo a
> definite slave, so you can always run "git fetch" on it without any
> trouble. You can even enforce this by denying all pushes to the cache
> repo, thus eliminating any chance of accidental misuse.
>
> Conveniently, git allows you to specify a different URL for fetch and
> push in your local working repositories.
Thank you.

For completeness, Michael Witten posted details for a comparable 
architecture where the data flow is in the other direction.  Leaf 
repositories push/pull to/from the cache, pull from the central 
repository in order to merge changes, then push to the cache to share 
locally.  Eventually, some leaf repository will push to the central.

Michael's approach has the advantage that the cache repository can be 
unattended and that my changes can be circulated locally before becoming 
visible to the wider, central repository audience.

Both approaches cleverly avoid potential collisions in the cache 
repository by working around them.  And, of course, some combinations of 
the two will work too.

--rich

Re: Newbie grief

[Rich Pixley]

On 5/1/12 11:42 , Randal L. Schwartz wrote:
>>>>>> "Rich" == Rich Pixley<rich.pixley@palm.com>  writes:
>
> Rich>  What I'm talking about is the situation where a branch can have multiple,
> Rich>  childless commits.  I've switched to calling these "tips" for this
> Rich>  discussion.
>
> But in git, a branch *is* what you're calling a "tip".

And therein lies the problem.

> What do you find lacking about git branches, in terms of sharing?

A number of situations.  But the short answer is that git completely 
lacks the ability to cope with potential collisions in the repository - 
even collisions that can be handled completely automatically, even when 
the collision can be handled completely in the repository graph, (as 
distinct from lexical or file content resolutions).

I want to be able to fetch changes to the branch I currently have 
checked out.  Git blocks this because it doesn't know how to cope with 
the working directory in that situation.  Merging is straightforward. 
Even updating, (checkout), is fairly straightforward.  But the 
insistence on a single tip means that if I commit directly to a non-tip 
commit, git doesn't know what to do with the branch pointer.  If it 
leaves it at my commit, then the other changes are essentially orphaned. 
  If it leaves it at the other changes, then my commit is essentially 
orphaned.  While it's probably possible to force git to do this anyway, 
including orphaning one set of changes, doing so is of limited value 
since the git interface makes the assumption that branches have a single 
tip anyway.

Pushing is blocked in git.  Git simply refuses some push requests which 
have obvious and fairly straightforward semantics.  There are ways in 
git to accomplish the more general task of information exchange by 
reversing the initiation request, (pulling), by partitioning the data 
into branches, etc.  But the straightforward, intuitive request to push 
is, in git, frequently blocked for no particular reason.  (Pushes are 
analogous to the previous situation of fetching to my current branch.)

You and I want to share a branch and we each have local, unattended 
cache/mirror repositories that we would like to use to pass data between 
us.  This doesn't work in git because the first time you and I make 
simultaneous changes, whether they collide or not, the unattended 
repositories become wedged.  They each refuse to talk to the other until 
someone manually unwedges them.

I want that if you and say, Sitaram commit conflicting changes to a 
shared branch, it's easy for me to recognize that the conflict exist and 
easy for me to resolve that conflict in my own repository.  I want the 
source code control system to keep track of those things, show them to 
me/us, and to track and show my resolution to you.  This stuff should 
all be automatic.  It shouldn't require explicit testing, manual 
pulling, nor explicit discussion between the three of us.  It shouldn't 
prohibit that either, but it shouldn't require it.

These are all fairly common situations today.  And it wouldn't be so bad 
if nothing else solved these problems either.  But we've had source code 
control solutions that solved all of these issues for over a decade now. 
  Going backwards to git seems like a pain in that context.

--rich

Re: Newbie grief

[Randal L. Schwartz]

>>>>> "Rich" == Rich Pixley <rich.pixley@palm.com> writes:

Rich> I want to be able to fetch changes to the branch I currently have checked out.
Rich> Git blocks this because it doesn't know how to cope with the working directory
Rich> in that situation.

It does?  I can always "git fetch origin" in my repo, and the remote
branches are in "origin/master, origin/foo, origin/bar".  Totally
separate from my working tree.

If I want to *examine* them, I can make a WIP commit, or use "git
stash", and then check them out headless:

  git stash save
  git checkout origin/master
  ## examine
  ## now go back
  git checkout master
  git stash pop

and now I can see what the upstream looks like.  Or just diff them:

  git diff ..origin/master

Rich>   Merging is straightforward. Even updating, (checkout), is fairly
Rich> straightforward.  But the insistence on a single tip means that if
Rich> I commit directly to a non-tip commit, git doesn't know what to do
Rich> with the branch pointer.  If it leaves it at my commit, then the
Rich> other changes are essentially orphaned. If it leaves it at the
Rich> other changes, then my commit is essentially orphaned.  While it's
Rich> probably possible to force git to do this anyway, including
Rich> orphaning one set of changes, doing so is of limited value since
Rich> the git interface makes the assumption that branches have a single
Rich> tip anyway.

So, make a set of related names for your branches.  It's better with
names anyway.

Rich> Pushing is blocked in git.  Git simply refuses some push requests
Rich> which have obvious and fairly straightforward semantics.

 git push master:from-merlyn/master

And now someone can look at "from-merlyn/master", and know that it's
from me, and related to master, and either incorporate it into the real
master, or cherry-pick from it, or whatever.  Solved.

Rich> You and I want to share a branch and we each have local,
Rich> unattended cache/mirror repositories that we would like to use to
Rich> pass data between us.  This doesn't work in git because the first
Rich> time you and I make simultaneous changes, whether they collide or
Rich> not, the unattended repositories become wedged.  They each refuse
Rich> to talk to the other until someone manually unwedges them.

No, you do it like above.  Some *person* has to sign off the merge each
time.  But we can share the unmerged changeset through other branches.

Rich> I want that if you and say, Sitaram commit conflicting changes to
Rich> a shared branch, it's easy for me to recognize that the conflict
Rich> exist and easy for me to resolve that conflict in my own
Rich> repository.  I want the source code control system to keep track
Rich> of those things, show them to me/us, and to track and show my
Rich> resolution to you.  This stuff should all be automatic.  It
Rich> shouldn't require explicit testing, manual pulling, nor explicit
Rich> discussion between the three of us.  It shouldn't prohibit that
Rich> either, but it shouldn't require it.

You're asking a lot of an automated system.  I think you're trying to
get a system to replace the communication you should be doing as a
developer.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: Newbie grief

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> Rich> I want that if you and say, Sitaram commit conflicting changes to
> Rich> a shared branch, it's easy for me to recognize that the conflict
> Rich> exist and easy for me to resolve that conflict in my own
> Rich> repository.  I want the source code control system to keep track
> Rich> of those things, show them to me/us, and to track and show my
> Rich> resolution to you.  This stuff should all be automatic.  It
> Rich> shouldn't require explicit testing, manual pulling, nor explicit
> Rich> discussion between the three of us.  It shouldn't prohibit that
> Rich> either, but it shouldn't require it.
>
> You're asking a lot of an automated system.  I think you're trying to
> get a system to replace the communication you should be doing as a
> developer.

While what Merlyn says is always right ;-), you could automate things by
having your post-receive hook to notice that remotes/from-merlyn/master
location was updated, attempt an automerge, and then report a failure.

Not everybody wants such an automated system, so there is no such
complexity in the vanilla setting, but the important thing is that whoever
needs such a complexity could easily do so.

Re: Newbie grief

[Rich Pixley]

On 5/1/12 14:12 , Junio C Hamano wrote:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>
>> Rich>  I want that if you and say, Sitaram commit conflicting changes to
>> Rich>  a shared branch, it's easy for me to recognize that the conflict
>> Rich>  exist and easy for me to resolve that conflict in my own
>> Rich>  repository.  I want the source code control system to keep track
>> Rich>  of those things, show them to me/us, and to track and show my
>> Rich>  resolution to you.  This stuff should all be automatic.  It
>> Rich>  shouldn't require explicit testing, manual pulling, nor explicit
>> Rich>  discussion between the three of us.  It shouldn't prohibit that
>> Rich>  either, but it shouldn't require it.
>>
>> You're asking a lot of an automated system.  I think you're trying to
>> get a system to replace the communication you should be doing as a
>> developer.
>
> While what Merlyn says is always right ;-), you could automate things by
> having your post-receive hook to notice that remotes/from-merlyn/master
> location was updated, attempt an automerge, and then report a failure.
>
> Not everybody wants such an automated system, so there is no such
> complexity in the vanilla setting, but the important thing is that whoever
> needs such a complexity could easily do so.

I think we have different definitions of "easily".  This is simple, 
first use sorts of stuff.  I've already invested weeks in trying to 
understand git enough to use it and I still don't have a process I like, 
much less do I know how to write a post-receive hook.  I'm sure I could, 
given enough time.  But frankly, I could switch to a different source 
code control system in less time.

Simple things should be simple.  They shouldn't require in-depth 
knowledge and customization of the tool.

In other systems, the automation is optional, but it's available.  If 
you want to vet each and every change as you take it, you can.  But you 
don't have to.

--rich

Re: Newbie grief

[Randal L. Schwartz]

>>>>> "Rich" == Rich Pixley <rich.pixley@palm.com> writes:

Rich> I think we have different definitions of "easily".  This is
Rich> simple, first use sorts of stuff.

Have you read the Pro Git book?

Have you read the gitcore-tutorial page?

Have you read the gitworkflows manpage?

The processes for "simple, first use" sorts of stuff never gets into
the complexity you are describing.  You're definitely into more advanced
stuff and then complain when you also need to be more advanced to set it
up.  Not sure what your goal is, then.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: Newbie grief

[Rich Pixley]

On 5/1/12 14:05 , Randal L. Schwartz wrote:
>>>>>> "Rich" == Rich Pixley<rich.pixley@palm.com>  writes:
>
> Rich>  I want to be able to fetch changes to the branch I currently have checked out.
> Rich>  Git blocks this because it doesn't know how to cope with the working directory
> Rich>  in that situation.
>
> It does?

Yes, it does.

> I can always "git fetch origin" in my repo, and the remote
> branches are in "origin/master, origin/foo, origin/bar".  Totally
> separate from my working tree.

Sure.  You can fetch other branches, (unless you happen to be checked 
out from them).  But you can't fetch to master if you're checked out 
from master.

> So, make a set of related names for your branches.  It's better with
> names anyway.

I disagree.  They only even need branches if they're different.  And the 
branches can be extremely lightweight.  With names, I have to manually 
track a geometric explosion of extraneous branches and branch names, 
just in order to be able to sync changes back and forth.  That's all 
work that could be managed automatically by the source code control system.

> Rich>  Pushing is blocked in git.  Git simply refuses some push requests
> Rich>  which have obvious and fairly straightforward semantics.
>
>   git push master:from-merlyn/master
>
> And now someone can look at "from-merlyn/master", and know that it's
> from me, and related to master, and either incorporate it into the real
> master, or cherry-pick from it, or whatever.  Solved.

Again, yes, you can push to other branches.  You could push to other 
repositories too.  That's not really what I'm talking about.

> You're asking a lot of an automated system.  I think you're trying to
> get a system to replace the communication you should be doing as a
> developer.

I hear that that's what you think.  But really, I'm asking for 
automation to replace the automation I already have in preexisting 
source code control systems.

There are a number of situations, like the ones I've described, that git 
just plain doesn't cope well with.  Other source code control systems 
have, and going backwards seems silly and frustrating.

My particular situation is that I'm developing a "feature" and to do 
that, I need to be testing on multiple machines.  Tens of them.  I 
really don't want hundreds of named branches that I must manually merge 
from constantly.

With mercurial or monotone or even subversion, it's trivial.  Branches 
can be shared.  And pushing between them is similarly trivial.  It can 
be done in seconds.  With git, it takes hours to do all the manual 
moves, track the manual moves manually, verify that they've been done 
correctly, and then later it takes hours to correct the ones that were 
done incorrectly because they were all done manually or because one 
machine happened to be down at the time and so got the changes in the 
wrong order, or whatever.

I'm not asking for anything new.  I'm asking for something that's as 
capable as what we've had for years now.

--rich

Re: Newbie grief

[Randal L. Schwartz]

>>>>> "Rich" == Rich Pixley <rich.pixley@palm.com> writes:

>> I can always "git fetch origin" in my repo, and the remote
>> branches are in "origin/master, origin/foo, origin/bar".  Totally
>> separate from my working tree.

Rich> Sure.  You can fetch other branches, (unless you happen to be
Rich> checked out from them).  But you can't fetch to master if you're
Rich> checked out from master.

No, you are still missing it.

"git fetch" updates the remote tracking branches, which you commonly
reference preceded by "origin".  So "git fetch" DOES NOT TOUCH "master".
It touches only "origin/master".

Only when you merge that remote in to your local master do you need to
worry about dirty trees or broken merges.

Rich> My particular situation is that I'm developing a "feature" and to
Rich> do that, I need to be testing on multiple machines.  Tens of them.

I think you're now confusing git with a deploy system.  That is also
something that will lead you to unnecessary grief.  Pick a deploy system
that's not git, and integrate git with it.

Rich> I really don't want hundreds of named branches that I must
Rich> manually merge from constantly.

I don't see how you would end up with this.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: Newbie grief

[Rich Pixley]

On 5/1/12 14:28 , Randal L. Schwartz wrote:
>>>>>> "Rich" == Rich Pixley<rich.pixley@palm.com>  writes:
>
> Rich>  I think we have different definitions of "easily".  This is
> Rich>  simple, first use sorts of stuff.
>
> Have you read the Pro Git book?

Yes.  The things it covers, it mostly covers well.  But it's lacking a lot.

There's nothing in it about repository networks, how to get stuff out of 
my index, reset, and it's not very good about explaining that things 
like rebase screw up your repository in ways that make sharing 
impossible.  I know that because of how mercurial works and from reverse 
engineering what must be required, not from reading git doc.

And I've spent close to a week now trying to use git on this project, 
throwing away repositories, patching by hand, and trying to sort out why 
git was refusing to push for me.  That wasn't explained at all nor do 
the git error messages explain what's happening.

> Have you read the gitcore-tutorial page?

Not recently.  It was pretty much impenetrable the first few times 
through.  I was looking for how to use git, I wasn't interested in all 
of the gory details of how it stored everything.

Just skimmed again.  Will need to read it again more thoroughly, though 
I don't see anything on the stuff we've been discussing.

> Have you read the gitworkflows manpage?

Yes, but not in a long time.  It seems to be more about the policies of 
working on git source code than about usage of git.

> The processes for "simple, first use" sorts of stuff never gets into
> the complexity you are describing.  You're definitely into more advanced
> stuff and then complain when you also need to be more advanced to set it
> up.  Not sure what your goal is, then.

This stuff isn't advanced anymore.  It's kind of standard.  My complaint 
is that doing standard stuff like this shouldn't require advanced work.

I have days, weeks into git learning curve so far, I've clearly only 
begun, and I have a big list of things I still can't do in git, though I 
can do them in other source code control systems.  In contrast, I was up 
and using mercurial in about a day and a half, including all of the 
stuff we've discussed, and all of the things I've even read about in 
git.  Learning mq's only took about 20 minutes.

--rich

Re: Newbie grief

[Rich Pixley]

On 5/1/12 14:39 , Randal L. Schwartz wrote:
>>>>>> "Rich" == Rich Pixley<rich.pixley@palm.com>  writes:
>
>>> I can always "git fetch origin" in my repo, and the remote
>>> branches are in "origin/master, origin/foo, origin/bar".  Totally
>>> separate from my working tree.
>
> Rich>  Sure.  You can fetch other branches, (unless you happen to be
> Rich>  checked out from them).  But you can't fetch to master if you're
> Rich>  checked out from master.
>
> No, you are still missing it.
>
> "git fetch" updates the remote tracking branches, which you commonly
> reference preceded by "origin".  So "git fetch" DOES NOT TOUCH "master".
> It touches only "origin/master".

Yes.  I understand that that is how git typically works in a non-bare 
repository.

Do you understand what I'm saying?

> Only when you merge that remote in to your local master do you need to
> worry about dirty trees or broken merges.
>
> Rich>  My particular situation is that I'm developing a "feature" and to
> Rich>  do that, I need to be testing on multiple machines.  Tens of them.
>
> I think you're now confusing git with a deploy system.  That is also
> something that will lead you to unnecessary grief.  Pick a deploy system
> that's not git, and integrate git with it.

No, not a deploy system.  You use a deploy system to set up something 
like multiple server http farms.  What I'm doing is more akin to porting 
the same piece of software to 20 different operating system 
distributions.  I'm not "deploying" the source code.  I'm developing it.

Thank you for acknowledging that git is a poor match for this scenario, 
though.

> Rich>  I really don't want hundreds of named branches that I must
> Rich>  manually merge from constantly.
>
> I don't see how you would end up with this.

Yup.  I'm beginning to see that.

--rich

Re: Newbie grief

[Andreas Ericsson]

On 05/02/2012 12:07 AM, Rich Pixley wrote:
> On 5/1/12 14:39 , Randal L. Schwartz wrote:
>> 
>> Rich> My particular situation is that I'm developing a "feature"
>> and to do that, I need to be testing on multiple machines.
>> Tens of them.
>> 
>> I think you're now confusing git with a deploy system. That is
>> also something that will lead you to unnecessary grief. Pick a
>> deploy system that's not git, and integrate git with it.
> 
> No, not a deploy system. You use a deploy system to set up something
> like multiple server http farms. What I'm doing is more akin to
> porting the same piece of software to 20 different operating system
> distributions. I'm not "deploying" the source code. I'm developing
> it.
> 
> Thank you for acknowledging that git is a poor match for this
> scenario, though.
> 

Git works well for that if you put hooks in place to trigger builds
and test-runs on the testservers though. We do exactly that, and I
doubt we're the only ones who do automated testing of every push.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: Newbie grief

[Michael Witten]

On Tue, May 1, 2012 at 9:57 PM, Rich Pixley <rich.pixley@palm.com> wrote:

> In contrast, I was up and using mercurial in about a day and a half,
> including all of the stuff we've discussed, and all of the things I've even
> read about in git.  Learning mq's only took about 20 minutes.

Fortunately, git is based on extremely simple principles.
Unfortunately, git grew out of really bright people hacking stuff
together in order to get sh!t dun; the result is not approachably or
even well documented, the UI is sometimes a bit of a kludge, the API
is probably nonexistent, and the terminology is so loosely thrown
about that it's easy to forget which way is up in discussions.
(Note, though, that Junio has done a laudable job of keeping the
whole experiment going strong).

Having recognized these deficiencies, I suggest that you provide
at least one tiny little use case that doesn't work as you'd
like; it should be in the form of a command line example that we
can all reproduce and discuss precisely.

Re: Newbie grief

[PJ Weisberg]

On Tue, May 1, 2012 at 3:07 PM, Rich Pixley <rich.pixley@palm.com> wrote:

> No, not a deploy system.  You use a deploy system to set up something like
> multiple server http farms.  What I'm doing is more akin to porting the same
> piece of software to 20 different operating system distributions.  I'm not
> "deploying" the source code.  I'm developing it.

I fail to see how you would end up with more than one branch per
environment, though.  Fewer, if you do the merge before pushing your
change back to the server.

It sounds like you're asking for branches without names (or
automatically assigned names like master-0, master-1, etc.).  I'm sure
it's all very intuitive in Hg (which I know nothing about), but it
sounds to me like a recipe for confusion.

-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from
magic is insufficiently advanced.

Re: Newbie grief

[Felipe Contreras]

On Tue, May 1, 2012 at 11:29 PM, Rich Pixley <rich.pixley@palm.com> wrote:

> I'm not asking for anything new.  I'm asking for something that's as capable
> as what we've had for years now.

So you are basically saying; "I want to do X *exactly* like I do it in
mercurial, and that's not easy in git".

Well, duh, that's because git is not mercurial. Why don't you do it
the _git way_? That would be easy.

Show all the hg commands of what you are trying to do, and we can show
you how you can achieve the same in git, but much more easily.

-- 
Felipe Contreras

Re: Newbie grief

[Philip Oakley]

From: "Michael Witten" <mfwitten@gmail.com> Sent: Tuesday, May 01, 2012 
11:56 PM
> On Tue, May 1, 2012 at 9:57 PM, Rich Pixley <rich.pixley@palm.com> wrote:
>
>> In contrast, I was up and using mercurial in about a day and a half,
>> including all of the stuff we've discussed, and all of the things I've 
>> even
>> read about in git. Learning mq's only took about 20 minutes.
>
> Fortunately, git is based on extremely simple principles.
> Unfortunately, git grew out of really bright people hacking stuff
> together in order to get sh!t dun; the result is not approachably or
> even well documented, the UI is sometimes a bit of a kludge, the API
> is probably nonexistent, and the terminology is so loosely thrown
> about that it's easy to forget which way is up in discussions.
> (Note, though, that Junio has done a laudable job of keeping the
> whole experiment going strong).
>
> Having recognized these deficiencies, I suggest that you provide
> at least one tiny little use case that doesn't work as you'd
> like; it should be in the form of a command line example that we
> can all reproduce and discuss precisely.
> --
A bit of browsing found 
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ which 
helped with some of the confusion about the different meanings of "branch". 
It looks like an Hg branch is a Git clone.  Git can be hard work until one 
'gets' how and why the new DVCS approach works. Plus learing the UI.

It is very hard to change one's mindset about how/why/when the old VCS 
approach broke (or isn't). The common VCS approach is based on drawing 
office practices from before the Titanic was built. It is only very recently 
that the reproduction and verification cost for data duplication have 
dropped sufficiently that a DVCS is the better approach. The historical 
approach was to protect the single 'master' item (with lots of admin & 
process). Now it's about 'status accounting' - do I have the right copy at 
the right status - i.e. the declared master sha1.

Philip 

Re: Newbie grief

[Sitaram Chamarty]

[I'm going to assume not copying the list on your reply to me was an
oversight, since there's nothing in the text to indicate it was
supposed to confidential or personal in any way].

[second, sorry about the multiple emails!]

On Tue, May 1, 2012 at 10:55 PM, Rich Pixley <rich.pixley@palm.com> wrote:
>
> On 4/30/12 20:44 , Sitaram Chamarty wrote:
>>
>> I've been reading the thread with interest.
>>
>> People who know far more than I do about git, its innards, and its
>> design have been responding in this thread so consider this a git
>> *user*'s point of view:
>>
>> On Tue, May 1, 2012 at 6:45 AM, Rich Pixley<rich.pixley@palm.com>  wrote:
>>
>>> Multiple heads are the idea that a single commit can "branch" in the
>>> repository and that both commits can be HEADS of the same branch at once
>>> in
>>> a single repository.  This allows a potential collision to exist in the
>>> repository and to be pushed and pulled through multiple repositories.
>>>  It
>>
>> That is bizarre; I have no other word for it.
>>
>> I teach git (occasionally), and if this feature existed I would
>> totally ignore it in my teaching material because I wouldn't know how
>> to defend or explain the need for "hydra branches".
>>
>> It's like having two people with the same first name *and* last name
>> (a situation that is not impossible in real life, but is rare and
>> almost always requires special handling).
>>
>> Does Hg do this?
>
> Yes, it does.  "Hg merge" by default merges a second head into your
> current working directory.
>
> It's a conceptual leap, I concur.  Believe me, I'm going through the


It's a conceptual leap I can do without; I'm bowing out of this discussion.

There's an ambiguity in the branch name now that, to me, is both
confusing and unnecessary.

It's like each branch name is now an array variable instead of a scalar.

We all know when arrays are better than a bunch of similarly named
scalars, but in *this* context I don't see why it is needed.

The fact that, (in later emails to others), you called this a basic
beginning need, or words to that effect, is just icing on top.

> reverse cultural shock now that git doesn't have this facility.  But it's a
> leap whose idea has been around for over 20 years.  It wasn't until the
> daggy source code control systems like monotone showed up that it became
> practical, but that was a decade ago now.
>
> The big win, of course, is that we can both push to the same repository,
> (and through multiple repositories), and we can decide later whether we want
> to merge or branch permanently.
>
>>   That would explain why my (admittedly half-hearted)
>> attempts to learn it have failed -- whatever tutorial I used must have
>> been written with the idea that hydra branches are intuitive and
>> logical and sane, but did not express the concept as clearly and
>> succinctly as you did.
>>
>> Thanks for this insight; my next attempt to understand Hg, should I
>> ever be forced into it, might actually succeed!
>
> It's really pretty simple.  Your commit, (or push, or pull), always
> succeeds, even if it's not at the tip of a branch.  If it's not at the tip
> of a branch, then it creates a new tip.
>
> The word "head" here is problematic since git uses it in a totally
> different way.  In git, "HEAD" refers to whatever commit is currently
> checked out.  In hg, "head" refers to a childless commit.  It doesn't even
> need to be on a named branch.
>
> --rich




--
Sitaram

Re: Newbie grief

[Philippe Vaucher]

> In other systems, this is a simple star network.  Clone a repository, use, push, pull, etc.  But with git, I can't push unless the cache repository is bare, but if the cache repository is bare, then a change to the central repository will cause the two to become wedged since neither can push or fetch the other.  It seems that git is allergic to the dual head branch solution or something, which is surprising and disappointing.


If I understand correctly, you're looking for a system where you have
a lot of systems that needs to share the modifications on their repo
*without* having a central repo. Basically you want a lot of non-bare
repositories pushing/pulling from each others.

It sounds to me that your problem could easily be solved if your
restrict yourself to "pulling" only. Whenever you want the latest
change from repo on machine A, just pull from machine A and benefit
from the automagic merging etc.

Tell me if there's something I'm missing, or maybe describe a simple
scenario we can relate with in terms of ideal commands to type and
things happening.

Thanks,
Philippe

Re: Newbie grief

[Hallvard Breien Furuseth]

 On Tue, 01 May 2012 15:07:27 -0700, Rich Pixley wrote:
> On 5/1/12 14:39 , Randal L. Schwartz wrote:
>> "git fetch" updates the remote tracking branches, which you commonly
>> reference preceded by "origin".  So "git fetch" DOES NOT TOUCH 
>> "master".
>> It touches only "origin/master".
>
> Yes.  I understand that that is how git typically works in a non-bare
> repository.

 And in a bare repository:

     git init --bare foo.git
     cd              foo.git
     git remote add bar ../bar.git
     git fetch      bar
         --> adds bar/master etc.

 For some reason, 'git clone --bare' does not treat the cloned
 repository the same way - it just copies it under refs/heads/
 instead of refs/remotes/, without even adding it as a remote.

-- 
 Hallvard

Re: Newbie grief

[Michael Witten]

On Wed, 02 May 2012 16:21:07 +0200, Hallvard Breien Furuseth wrote:

> And in a bare repository:
>
>     git init --bare foo.git
>     cd              foo.git
>     git remote add bar ../bar.git
>     git fetch      bar
>         --> adds bar/master etc.
>
> For some reason, 'git clone --bare' does not treat the cloned
> repository the same way - it just copies it under refs/heads/
> instead of refs/remotes/, without even adding it as a remote.

What do you mean?

  $ git init bar.git; cd bar.git
  $ echo a > a; git add a; git commit -m a; cd ..
  $ git clone        bar.git baz.git
  $ git clone --bare baz.git foo.git; cd foo.git
  $ git remote add bar ../bar.git
  $ git fetch bar
  $ git branch -a
  * master
    remotes/bar/master

Also, removing the `baz' intermediate repository doesn't matter:

  $ git init bar.git; cd bar.git
  $ echo a > a; git add a; git commit -m a; cd ..
  $ git clone --bare bar.git foo.git; cd foo.git
  $ git remote add bar ../bar.git
  $ git fetch bar
  $ git branch -a
  * master
    remotes/bar/master

For completenes, your example again:

  $ git init bar.git; cd bar.git
  $ echo a > a; git add a; git commit -m a; cd ..
  $ git init --bare foo.git
  $ cd              foo.git
  $ git remote add bar ../bar.git
  $ git fetch      bar
  $ git branch -a
    remotes/bar/master

Re: Newbie grief

[Jakub Narebski]

Rich Pixley <rich.pixley@palm.com> writes:
> On 5/1/12 11:20 , Michael Witten wrote:
>> On Tue, May 1, 2012 at 18:15, Rich Pixley<rich.pixley@palm.com>  wrote:
>>
>>> I want pull to work even without merging.  I want to be able to share a
>>> branch between different repositories and different users while the source
>>> code control system tracks this for me
>>
>> I believe you are missing the point that a `pull' in git is a `fetch'
>> followed by a `merge'. You should read about the `fetch' command by
>> reading (`git help fetch'), and make sure you understand how to use
>> refspecs; you will probably find it very instructive to play around
>> by specifying explicit refspecs to `git fetch' rather than relying
>> on the implicit rules (which can be somewhat confusing).

[...]
> That git uses the word "pull" to mean something different than
> previous source code control systems only adds to the confusion.  I
> was using "pull" in the more general sense of pushing and pulling
> data, not in the very narrow meaning of "git fetch + git merge".

In using "pull" vs "fetch" Git follows the convention of BitKeeper
(proprietary distributed version control system which was used for
Linux kernel development 'till "BitKeeper fiasco", and which Git
replaced).

> I'm still pretty much lost on refspecs and refs.  The terms are
> apparently not used in the manuals I've been reading and they don't
> seem to be used consistently even within git error messages.
> 
> Is "refspec" the git word for the branch pointer that points to the
> childless commit that defines a branch?

"Ref" in Git is a named reference (pointer) to a commit in DAG of
revisions, i.e. either [local] branch, tag, remote-tracking branch,
etc.

"Refspec" is a specification of mapping between ref name in remote
repository and "tracking" ref in local repository, e.g.

  refs/heads/*:refs/remotes/origin/*
  refs/tags/*:refs/tags/*

See any of git-pull(1), git-fetch(1) and git-push(1) manpages.

-- 
Jakub Narebski

Re: Newbie grief

[Hallvard Breien Furuseth]

 On Wed, 02 May 2012 15:21:29 -0000, Michael Witten <mfwitten@gmail.com> 
 wrote:
>On Wed, 02 May 2012 16:21:07 +0200, Hallvard Breien Furuseth wrote:
>> And in a bare repository:
>>
>>     git init --bare foo.git
>>     cd              foo.git
>>     git remote add bar ../bar.git
>>     git fetch      bar
>>         --> adds bar/master etc.
>>
>> For some reason, 'git clone --bare' does not treat the cloned
>> repository the same way - it just copies it under refs/heads/
>> instead of refs/remotes/, without even adding it as a remote.
>
> What do you mean?

 I mean 'git clone --bare bar.git foo.git' does not give foo.git
 a remote named 'origin' with a branch origin/master.  Not sure
 if there is a _simple_ way to do it well either.  init + fetch
 above does not try to hardlink objects/packs like clone does.

> (...)
>   $ git init bar.git; cd bar.git
>   $ echo a > a; git add a; git commit -m a; cd ..
>   $ git clone --bare bar.git foo.git; cd foo.git

     $ git branch -a
     * master

>   $ git remote add bar ../bar.git
>   $ git fetch bar

-- 
 Hallvard

Re: Newbie grief

[Randal L. Schwartz]

>>>>> "Hallvard" == Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no> writes:

Hallvard> I mean 'git clone --bare bar.git foo.git' does not give foo.git
Hallvard> a remote named 'origin' with a branch origin/master.  Not sure
Hallvard> if there is a _simple_ way to do it well either.  init + fetch
Hallvard> above does not try to hardlink objects/packs like clone does.

Interesting.  I was surprised by this, but I've confirmed it.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: Newbie grief

[Hallvard Breien Furuseth]

 Philip Oakley wrote:
> A bit of browsing found
> http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
> which helped with some of the confusion about the different meanings
> of "branch". It looks like an Hg branch is a Git clone.  Git can be
> hard work until one 'gets' how and why the new DVCS approach works.
> Plus learing the UI.

 Aha, now this thread finally makes some sense.  So when Rich
 wants a "branch" with several tips, he actually wants several
 Git clones (repositories) with the same Git branch checked out -
 and some of them with local commits to it.

 And these commits can be shared as remote branches between the
 clones, which in Hg-speak means that in one particular clone,
 Git will "bookmark" the other clones' tips.

-- 
 Hallvard

Re: Newbie grief

[Michael Witten]

On Thu, 03 May 2012 14:23:59 +0200, Hallvard Furuseth wrote:

> On Wed, 02 May 2012 15:21:29 -0000, Michael Witten wrote:
>
>>On Wed, 02 May 2012 16:21:07 +0200, Hallvard Breien Furuseth wrote:
>>> And in a bare repository:
>>>
>>>     git init --bare foo.git
>>>     cd              foo.git
>>>     git remote add bar ../bar.git
>>>     git fetch      bar
>>>         --> adds bar/master etc.
>>>
>>> For some reason, 'git clone --bare' does not treat the cloned
>>> repository the same way - it just copies it under refs/heads/
>>> instead of refs/remotes/, without even adding it as a remote.
>>
>> What do you mean?
>
> I mean 'git clone --bare bar.git foo.git' does not give foo.git
> a remote named 'origin' with a branch origin/master.  Not sure
> if there is a _simple_ way to do it well either.  init + fetch
> above does not try to hardlink objects/packs like clone does.
>
>> (...)
>>   $ git init bar.git; cd bar.git
>>   $ echo a > a; git add a; git commit -m a; cd ..
>>   $ git clone --bare bar.git foo.git; cd foo.git
>
>    $ git branch -a
>    * master

>From `git help clone':

  --bare
      Make a bare GIT repository. That is, instead of creating
      <directory> and placing the administrative files in
      <directory>/.git, make the <directory> itself the $GIT_DIR.
      This obviously implies the -n because there is nowhere to
      check out the working tree. Also the branch heads at the
      remote are copied directly to corresponding local branch
      heads, without mapping them to refs/remotes/origin/. When
      this option is used, neither remote-tracking branches nor the
      related configuration variables are created.

namely:

                                  Also the branch heads at the
      remote are copied directly to corresponding local branch
      heads, without mapping them to refs/remotes/origin/. When
      this option is used, neither remote-tracking branches nor the
      related configuration variables are created.

Re: Newbie grief

[Hallvard Breien Furuseth]

 On Thu, 03 May 2012 16:09:15 -0000, Michael Witten wrote:
> On Thu, 03 May 2012 14:23:59 +0200, Hallvard Furuseth wrote:
>> I mean 'git clone --bare bar.git foo.git' does not give foo.git
>> a remote named 'origin' with a branch origin/master.  Not sure
>> if there is a _simple_ way to do it well either.  init + fetch
>> above does not try to hardlink objects/packs like clone does.
>>
>>> (...)
>>>   $ git init bar.git; cd bar.git
>>>   $ echo a > a; git add a; git commit -m a; cd ..
>>>   $ git clone --bare bar.git foo.git; cd foo.git
>>
>>    $ git branch -a
>>    * master
>
> From `git help clone':
>
>   --bare
>       Make a bare GIT repository. That is, instead of creating
>       <directory> and placing the administrative files in
>       <directory>/.git, make the <directory> itself the $GIT_DIR.
>       This obviously implies the -n because there is nowhere to
>       check out the working tree. Also the branch heads at the
>       remote are copied directly to corresponding local branch
>       heads, without mapping them to refs/remotes/origin/. When
>       this option is used, neither remote-tracking branches nor the
>       related configuration variables are created.

 Yes, I know.  I just don't know why.

-- 
 Hallvard

Re: Newbie grief

[Michael Witten]

On Thu, 03 May 2012 18:20:43 +0200, Hallvard Furuseth wrote:

> On Thu, 03 May 2012 16:09:15 -0000, Michael Witten wrote:
>
>> On Thu, 03 May 2012 14:23:59 +0200, Hallvard Furuseth wrote:
>>
>>> I mean 'git clone --bare bar.git foo.git' does not give foo.git
>>> a remote named 'origin' with a branch origin/master.  Not sure
>>> if there is a _simple_ way to do it well either.  init + fetch
>>> above does not try to hardlink objects/packs like clone does.
>>>
>>>> (...)
>>>>   $ git init bar.git; cd bar.git
>>>>   $ echo a > a; git add a; git commit -m a; cd ..
>>>>   $ git clone --bare bar.git foo.git; cd foo.git
>>>
>>>    $ git branch -a
>>>    * master
>>
>> From `git help clone':
>>
>>   --bare
>>       Make a bare GIT repository. That is, instead of creating
>>       <directory> and placing the administrative files in
>>       <directory>/.git, make the <directory> itself the $GIT_DIR.
>>       This obviously implies the -n because there is nowhere to
>>       check out the working tree. Also the branch heads at the
>>       remote are copied directly to corresponding local branch
>>       heads, without mapping them to refs/remotes/origin/. When
>>       this option is used, neither remote-tracking branches nor the
>>       related configuration variables are created.
>
> Yes, I know.  I just don't know why.

I imagine that the purpose behind a bare repository is really just to
provide a repository into which objects may be pushed and from which
objects may be fetched, and that's it; it's sole purpose is to act
as a point of communication. Cloning a repository with --bare is
meant to simplify the task of setting up a bare repository with
some initial content.

Fortunately, we're talking about the history of a revision control
system. I found this with `git blame -L70,76 71821351^ git-clone.txt':

  commit 4fb66a62eeb7bfec115cd0058d7a05ab62fc23e7
  Author: Junio C Hamano <junkio@cox.net>
  Date:   Sun Jan 22 17:27:52 2006 -0800
  
      clone: do not create remotes/origin nor origin branch in a bare repository.
      
      It is simply pointless, since no merges will ever happen in such
      a repository.
      
      Signed-off-by: Junio C Hamano <junkio@cox.net>

That certainly corroborates the limited purpose of a bare repository.

Re: Newbie grief

[Rich Pixley]

On 5/3/12 09:08 , Hallvard Breien Furuseth wrote:
>   Philip Oakley wrote:
>> A bit of browsing found
>> http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
>> which helped with some of the confusion about the different meanings
>> of "branch". It looks like an Hg branch is a Git clone.  Git can be
>> hard work until one 'gets' how and why the new DVCS approach works.
>> Plus learing the UI.
>   Aha, now this thread finally makes some sense.  So when Rich
>   wants a "branch" with several tips, he actually wants several
>   Git clones (repositories) with the same Git branch checked out -
>   and some of them with local commits to it.
Yes.
>   And these commits can be shared as remote branches between the
>   clones, which in Hg-speak means that in one particular clone,
>   Git will "bookmark" the other clones' tips.
Well, no.  In hg, these are all managed.  So there's no scaling issue.  
They can all push/pull together, since they are really all just one 
shared branch.  Adding a new repository to the mix is trivial.  And 
either pushes or pulls can be used, or any combo.

With git, I must manually make space for each and every repository, 
manually track which set of changes are where, manually track which need 
to be merged, and manually track which repositories are looking at which 
git branches so that they don't collide, or only collide in the current 
repository and only when I'm prepared to merge them.

(The bookmark solution appears to be what hg-git uses.  Hg-git is an hg 
extension to allow push/pull/clone from git repositories using hg.  
Unfortunately, it doesn't translate git submodules into hg 
subrepositories - yet.)

--rich

Re: Newbie grief

[Rich Pixley]

On 5/3/12 09:20 , Hallvard Breien Furuseth wrote:
>   On Thu, 03 May 2012 16:09:15 -0000, Michael Witten wrote:
>> On Thu, 03 May 2012 14:23:59 +0200, Hallvard Furuseth wrote:
>>> I mean 'git clone --bare bar.git foo.git' does not give foo.git
>>> a remote named 'origin' with a branch origin/master.  Not sure
>>> if there is a _simple_ way to do it well either.  init + fetch
>>> above does not try to hardlink objects/packs like clone does.
>>>
>>>> (...)
>>>>    $ git init bar.git; cd bar.git
>>>>    $ echo a>  a; git add a; git commit -m a; cd ..
>>>>    $ git clone --bare bar.git foo.git; cd foo.git
>>>     $ git branch -a
>>>     * master
>>  From `git help clone':
>>
>>    --bare
>>        Make a bare GIT repository. That is, instead of creating
>>        <directory>  and placing the administrative files in
>>        <directory>/.git, make the<directory>  itself the $GIT_DIR.
>>        This obviously implies the -n because there is nowhere to
>>        check out the working tree. Also the branch heads at the
>>        remote are copied directly to corresponding local branch
>>        heads, without mapping them to refs/remotes/origin/. When
>>        this option is used, neither remote-tracking branches nor the
>>        related configuration variables are created.
>   Yes, I know.  I just don't know why.
I do.

It's because creating a string of repositories is a nuisance in git 
because of the remote/foo practice.  You have to manually fetch and 
merge at each location.

In other systems, the branches are tracked identically.  You see master, 
I see master.  The only differences we see are any changes I've created 
that haven't yet been pushed to you or vice verse.  But since git can't 
handle collisions in the repository the way other systems do, it's 
forced to use the geographic branch scheme for non-bare repositories.  
Bare repositories don't have the collision between repository branch and 
working directory copy in git, so with bare repositories, git can use 
the identical branch scheme, (although it still refuses colliding pushes).

If bare repositories used the triangulation approach of non-bare 
repositories, then automation would be considerably more complicated.  
So would repository chaining.

What I don't understand is why git chose this less functional 
architecture over the previously existing practice that doesn't have 
these limitations, although "because that's what BitKeeper did" might be 
the sad answer.

--rich

Re: Newbie grief

[Rich Pixley]

On 5/1/12 16:30 , Felipe Contreras wrote:
> On Tue, May 1, 2012 at 11:29 PM, Rich Pixley<rich.pixley@palm.com>  wrote:
>
>> I'm not asking for anything new.  I'm asking for something that's as capable
>> as what we've had for years now.
> So you are basically saying; "I want to do X *exactly* like I do it in
> mercurial, and that's not easy in git".
Well, no, I'm saying that I want to do it at all, and that's not easy in 
git.
> Well, duh, that's because git is not mercurial. Why don't you do it
> the _git way_? That would be easy.
That would be great, except that it's not easy.  It's a mess.

I do have a partial solution now, thanks to the list.  It's just a bit 
messier and non-intuitive since I have to work around the limitations of 
git.

--rich

Re: Newbie grief

[Rich Pixley]

On 5/1/12 16:01 , PJ Weisberg wrote:
> On Tue, May 1, 2012 at 3:07 PM, Rich Pixley<rich.pixley@palm.com>  wrote:
>
>> No, not a deploy system.  You use a deploy system to set up something like
>> multiple server http farms.  What I'm doing is more akin to porting the same
>> piece of software to 20 different operating system distributions.  I'm not
>> "deploying" the source code.  I'm developing it.
> I fail to see how you would end up with more than one branch per
> environment, though.  Fewer, if you do the merge before pushing your
> change back to the server.
>
> It sounds like you're asking for branches without names (or
> automatically assigned names like master-0, master-1, etc.).  I'm sure
> it's all very intuitive in Hg (which I know nothing about), but it
> sounds to me like a recipe for confusion.
I'm finding the reverse to be true.

In hg, I don't have to think about how many other branches or 
repositories there might be.  I don't have to track where the changes 
are.  And I don't have to do anything to add another repository to the 
mix or to remove one.  Trivial merges are trivial.  The view from any 
repository is identical, not just symmetric.  The things I want to do 
are all simple commands.  Pull from the cache, merge if necessary, do 
some work, push to the cache.  Repeat as necessary since there will be 
numerous collisions and merges since I'm working on multiple machines 
concurrently.  And eventually, push to central server.

With git, if I use the traditional triangle architecture, I have to 
manually name every repository and every branch uniquely, create fresh 
branches in every other repository when I create one new repository.  
Remove old branches from every other repository whenever I remove one.  
Track collisions manually, track which repositories have which changes 
manually, and be extra careful about moving changes around so that they 
don't collide or force merge commits because that screws up git 
histories.  In order to do a simple source code control task, I have to 
stop, formulate a plan for making things work in git that still ducks 
both the limitations and traps of git and still accomplishes my goal, 
and then execute that plan precisely, because recovery is difficult.

If I skip the standard git triangle merging architecture, I can collapse 
some of that bookkeeping by sharing a branch.  But the cost is that 
pushing, pulling, and merging become even more complex as I have to 
dodge more limitations, (essentially, pushing doesn't work, star 
networks don't work, etc.)

Trying to keep all of that bookkeeping in my head, or trying to remember 
all of those arbitrary and unnecessary limitations is more complicated.

I'll grant that some of this is unique to my current work flow.  But I 
think that a lot of it carries into other work flows as well.

--rich

Re: Newbie grief

[Rich Pixley]

On 5/1/12 15:56 , Michael Witten wrote:
> On Tue, May 1, 2012 at 9:57 PM, Rich Pixley<rich.pixley@palm.com>  wrote:
>
>> In contrast, I was up and using mercurial in about a day and a half,
>> including all of the stuff we've discussed, and all of the things I've even
>> read about in git.  Learning mq's only took about 20 minutes.
> Fortunately, git is based on extremely simple principles.
> Unfortunately, git grew out of really bright people hacking stuff
> together in order to get sh!t dun; the result is not approachably or
> even well documented, the UI is sometimes a bit of a kludge, the API
> is probably nonexistent, and the terminology is so loosely thrown
> about that it's easy to forget which way is up in discussions.
> (Note, though, that Junio has done a laudable job of keeping the
> whole experiment going strong).
Thank you for acknowledging that.
> Having recognized these deficiencies, I suggest that you provide
> at least one tiny little use case that doesn't work as you'd
> like; it should be in the form of a command line example that we
> can all reproduce and discuss precisely.
I think I already have.  And you've given me an approach that is largely 
functional in git.  It's not wonderful, but it's mostly functional.

I'll post my comparison elsepost.

--rich

Re: Newbie grief

[Rich Pixley]

On 5/1/12 16:30 , Felipe Contreras wrote:
> Show all the hg commands of what you are trying to do, and we can show
> you how you can achieve the same in git, but much more easily.
hg init foo
for i in `yes | head -4000`; do (set -x ; d=`date +%s.%N` ; hg clone foo 
foo-$d; (cd foo-$d && date > bar && hg add bar && hg ci -m $d)); done
for i in foo-*; do (set -x ; (cd $i && hg push -f)); done

--rich

Re: Newbie grief

[Nathan Gray]

On Thu, May 3, 2012 at 11:43 AM, Rich Pixley <rich.pixley@palm.com> wrote:
>
> In hg, I don't have to think about how many other branches or repositories
> there might be.  I don't have to track where the changes are.  And I don't
> have to do anything to add another repository to the mix or to remove one.
>  Trivial merges are trivial.  The view from any repository is identical, not
> just symmetric.  The things I want to do are all simple commands.  Pull from
> the cache, merge if necessary, do some work, push to the cache.  Repeat as
> necessary since there will be numerous collisions and merges since I'm
> working on multiple machines concurrently.  And eventually, push to central
> server.

Wow, this hg sounds great!  You should use that!

All kidding aside, what you're talking about are design decisions
based on preferred workflows.  The workflow you're describing may seem
obvious and fantastic to you, but it sounds absurdly complicated to
me.  You hate the way git handles remote branches.  I think it's
incredibly sensible for a *truly* distributed VCS to enforce
location-based namespacing.  Basically, we have differences of
opinion.  Since your opinion seems to be that hg has done everything
right and git has done everything wrong, why are you using git?

Cheers,
-n8

-- 
HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch
http://hexalex.com
On The App Store: http://bit.ly/8Mj1CU
On Facebook: http://bit.ly/9MIJiV
On Twitter: http://twitter.com/hexalexgame
http://n8gray.org

Re: Newbie grief

[Rich Pixley]

On 4/30/12 22:32 , Michael Witten wrote:
> On Mon, 30 Apr 2012 20:04:25 -0700, Rich Pixley wrote:
>
>> I don't need separate branches for each repository.  What I really want
>> is a common branch whose changes I can push back and forth between the
>> various repositories, or coordinate through a central cache, without
>> worrying about the underlying details that git is forcing me to confront.
>
> Here's a start for a more precise discussion.
>
> Sincerely,
> Michael Witten
>
>
> Cache server:
>
>    $ git clone --mirror "$uri_for_central_repo"
>
> Machine A:
>
>    $ git clone "$uri_for_cache_repo"
>    $ git checkout -b feature_0 origin/feature_0
>    $ # ... do some work ...
>    $ git push --set-upstream origin HEAD:shared/feature_0
>    $ git config push.default upstream
>
> Machine B:
>
>    $ git clone "$uri_for_cache_repo"
>    $ git checkout -b feature_0 origin/feature_0
>    $ # ... do some work that conflicts with work done on Machine A...
>    $ git push --set-upstream origin HEAD:shared/feature_0
>    To $uri_for_cache_repo
>     ! [rejected]        HEAD ->  shared/feature_0 (non-fast-forward)
>     error: failed to push some refs to '$uri_for_cache_repo'
>    To prevent you from losing history, non-fast-forward updates were rejected
>    Merge the remote changes (e.g. 'git pull') before pushing again.  See the
>    'Note about fast-forwards' section of 'git push --help' for details.
>    $ git pull origin shared/feature_0
>    From $uri_for_cache_repo
>     * branch            shared/feature_0 ->  FETCH_HEAD
>    Auto-merging a
>    CONFLICT (add/add): Merge conflict in a
>    Recorded preimage for 'a'
>    Automatic merge failed; fix conflicts and then commit the result.
>    $ # ... resolve conflict and commit results ...
>    $ git push --set-upstream origin HEAD:shared/feature_0
>    $ git config push.default upstream
>
> Machine A:
>
>    $ git pull # pulls in origin's shared/feature_0
>    $ # ... do some work ...
>    $ git push # pushes to origin's shared/feature_0
>
> Machine B:
>
>    $ git pull # pulls in origin's shared/feature_0
>    $ # ... do some work ...
>    $ git push # pushes to origin's shared/feature_0
>
> Machine A:
>
>    $ git pull
>    $ git remote add central "$uri_for_central_repo"
>    $ git push central HEAD:feature_0 # Assume there is a conflict
>    To $uri_for_central_repo
>     ! [rejected]        HEAD ->  feature_0 (non-fast-forward)
>    error: failed to push some refs to '$uri_for_central_repo'
>    To prevent you from losing history, non-fast-forward updates were rejected
>    Merge the remote changes (e.g. 'git pull') before pushing again.  See the
>    'Note about fast-forwards' section of 'git push --help' for details.
>    $ git pull central feature_0
>    $ # ... resolve conflict and commit results ...
>    $ git push central HEAD:feature_0 # Assume it succeeds this time
>    $ # Let's update the cache repo from Machine A:
>    $ git fetch central
>    $ git push origin 'refs/remotes/central/*:refs/heads/*'
>
> Machine B:
>
>    $ git pull
>    $ git pull . origin/feature_0 # Get new stuff cached from central server

This is probably what I'm going to end up using.

Just for comparison, here's a similar process in hg.

Cache server:

   $ hg clone $uri_for_central_repo

Machine A:

   $ hg clone $uri_for_cache_repo
   $ # ...do some work...
   $ hg push

Machine B:

   $ hg clone $uri_for_cache_repo
   $ # ...do some work...
   $ hg push # assume this collides
   pushing to $uri_for_cache_repo
   searching for changes
   abort: push creates new remote head 6d2eb0a6a278!
   (you should pull and merge or use push -f to force)
   $ hg push -f # the pull and merge case parallels git, so let's use 
push -f.

Any repo:

   $ hg pull # pulls in all changes including the dual heads
   $ hg merge # collapses the dual heads
   $ hg commit # commits the merge
   $ hg push

Machine A:

   $ hg pull # pulls in all changes so far
   $ hg up
   $ #... do some work ...
   $ hg push

Machine B

   $ hg pull
   $ hg up
   $ # ... do some work ...
   $ hg push

Any repo:

   $ hg pull $uri_to_central_repo
   $ hg merge
   $ hg push $uri_to_central_repo
   $ hg push # default is cache repo

Machine B:

   $ hg pull


Some Conclusions:

* the work flows are similar.

* the hg commands are simpler and have the defaults that we want, 
primarily because no extra branches are required.

* the hg error messages are straightforward, clear, and don't require 
any deep knowledge of the source code control system or it's 
limitations.  (I still don't understand what the git message on 
collision is saying.)

* hg has more options about how to handle the collisions or the merges. 
  While git can mimic some of those options, doing so requires a priori 
knowledge that isn't stored in the source code control system and 
therefor requires a human exchange which is optional with hg.

--rich

Re: Newbie grief

[Rich Pixley]

On 5/3/12 12:09 , Nathan Gray wrote:
> On Thu, May 3, 2012 at 11:43 AM, Rich Pixley<rich.pixley@palm.com>  wrote:
>> In hg, I don't have to think about how many other branches or repositories
>> there might be.  I don't have to track where the changes are.  And I don't
>> have to do anything to add another repository to the mix or to remove one.
>>   Trivial merges are trivial.  The view from any repository is identical, not
>> just symmetric.  The things I want to do are all simple commands.  Pull from
>> the cache, merge if necessary, do some work, push to the cache.  Repeat as
>> necessary since there will be numerous collisions and merges since I'm
>> working on multiple machines concurrently.  And eventually, push to central
>> server.
> Wow, this hg sounds great!  You should use that!
>
> All kidding aside, what you're talking about are design decisions
> based on preferred workflows.  The workflow you're describing may seem
> obvious and fantastic to you, but it sounds absurdly complicated to
> me.  You hate the way git handles remote branches.  I think it's
> incredibly sensible for a *truly* distributed VCS to enforce
> location-based namespacing.  Basically, we have differences of
> opinion.  Since your opinion seems to be that hg has done everything
> right and git has done everything wrong, why are you using git?
Corporate mandate.  Political decision made without discussion with the 
people who would be using it.

--rich

Re: Newbie grief

[Ted Ts'o]

On Thu, May 03, 2012 at 11:26:20AM -0700, Rich Pixley wrote:
> 
> In other systems, the branches are tracked identically.  You see
> master, I see master.  The only differences we see are any changes
> I've created that haven't yet been pushed to you or vice verse.  But
> since git can't handle collisions in the repository the way other
> systems do, it's forced to use the geographic branch scheme for
> non-bare repositories.  Bare repositories don't have the collision
> between repository branch and working directory copy in git, so with
> bare repositories, git can use the identical branch scheme,
> (although it still refuses colliding pushes).

I'm still not sure I understand your development workflow.  It seems
like you are trying to publish multiple branches across to multiple
repositories on different machines, so they are visible to different
developers?  What are all of these branches used for, and why are you
doing things this way?  (I'm not implying that the reason you have for
doing this way is silly or stupid, just that I don't understand it and
I don't understand why you feel you need to do things this way.)

> What I don't understand is why git chose this less functional
> architecture over the previously existing practice that doesn't have
> these limitations, although "because that's what BitKeeper did"
> might be the sad answer.

It's mainly because many git users, including many kernel developers
have a set of development workflows which is well suited for how git
is set up to work.  So git was very much shaped by the development
workflows of the early git users --- and it goes the other way, too
--- new git features will sometimes cause our development practices
and workflow to evolve.

So I may have a number of different branches that I'm working on, but
in general they stay local to my repository until they are ready to be
merged to mainline.  If patches need to be reviewed, they either get
sent via e-mail to the appropriate mailing list, and the review
happens via e-mail, or internally at $WORK, we use Gerrit and we push
the change to gerrit where the patches are kept and trackked inside
Gerrit, alongside the comments as the patch goes through the review
process.  (I suspect you are pushing patches out to the repository for
review as the patches are getting developed and refined, but I don't
know that for sure, since you haven't talked about why you want the
particular SCM features that you've been asking for.)

Once a patch is fully baked, it goes into a maintainer's repository
where it gets pulled into a higher-level maintainer's repository.  So
in practice a developer's repository has very few branches that he or
she needs to export to the outside world, at least as I and other
Linux kernel developers typically tend to use git.

It's obvious you want to use your DSCM in a different way, and it's
not that any particular workflow is right or wrong.  But obviously,
some tools are a better match for certain workflows as compared to
other workflows.

Regards,

					- Ted

Re: Newbie grief

[Randal L. Schwartz]

>>>>> "Rich" == Rich Pixley <rich.pixley@palm.com> writes:

Rich> Corporate mandate.  Political decision made without discussion
Rich> with the people who would be using it.

Sounds like you put two strikes against git before you even invoked the
first command, with that attitude.

If you are *serious* about having *git* work for you, it will.
Thousands of projects are using git every day.

But if you're looking at git like "it's not hg, and I already hate
that", you'll end up sounding like you have in the past few days.

Methinks *this* is the actual problem.  Not git.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: Newbie grief

[Ronan Keryell]

>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich Pixley <rich.pixley@palm.com> said:

    Rich> * the hg error messages are straightforward, clear, and don't
    Rich> require any deep knowledge of the source code control system
    Rich> or it's limitations.  (I still don't understand what the git
    Rich> message on collision is saying.)

This is a very good suggestion.

This would help people not having time to embrace all the advanced
details to understand easily what is happening.

At least, print a simpler message with some typical use case causing
this and some workflow ideas before the detailed explanation.

Or adding a new config message.style = expert | newbie | ...
and of course with newbie by default. :-)
-- 
  Ronan KERYELL                            |\/  Phone:  +1 408 658 9453
  Wild Systems / HPC Project               |/)
  5201 Great America Parkway, Suite 320    K    Ronan.Keryell@wild-systems.com
  Santa Clara, CA 95054                    |\   skype:keryell
  USA                                      | \  http://wild-systems.com

Re: Newbie grief

[Rich Pixley]

On 5/3/12 13:14 , Randal L. Schwartz wrote:
>>>>>> "Rich" == Rich Pixley<rich.pixley@palm.com>  writes:
> Rich>  Corporate mandate.  Political decision made without discussion
> Rich>  with the people who would be using it.
>
> Sounds like you put two strikes against git before you even invoked the
> first command, with that attitude.
>
> If you are *serious* about having *git* work for you, it will.
> Thousands of projects are using git every day.
>
> But if you're looking at git like "it's not hg, and I already hate
> that", you'll end up sounding like you have in the past few days.
>
> Methinks *this* is the actual problem.  Not git.
It's not just hg.  It's other source code control systems as well.  
Check out any of the other daggy guys.  So sure, I'll admit a bias for 
current technology over older tech.

Another part of the problem is that git is badly designed, poorly 
documented, and the terminology is inconsistent.  That, and the 
limitations make for a pretty steep learning curve.

And a third part of the problem is that coming from a number of other 
daggy tools, I was expecting a lot more out of git that what git 
actually provides.  Certainly, git can be used to do whatever, but a 
pile of sand and some plastic can be made into a computer too, if we're 
willing to put enough effort into it.

But hey, I'm using it.  (I refuse to work with perforce).  I had an even 
worse bias against mecurial before I started using it.  The big learning 
curve was from the linear tools to the daggy tools which happened for me 
with monotone.

--rich

Re: Newbie grief

[Junio C Hamano]

Michael Witten <mfwitten@gmail.com> writes:

> (Note, though, that Junio has done a laudable job of keeping the
> whole experiment going strong).

You are giving me too much credit, and at the same time insulting the
people who polished Git enough to suit their workflow.  To them, the tool
has past "experiment" stage long time ago.  They found what was lacking
and what would help the need in their workflow.  I just have helped them
shape their ideas into a coherent whole.

That does not mean there is nothing missing, still appears experimental,
or inconsistent in the parts of the system that these people do not use
nor care about, and when you bring in people coming from different
background, they will notice the behaviour or default that do not match
their expectation.  They can do the usual "scratching own itches" thing
the same way to others who have done before. As nobody forces them to do
so, they can instead keep whining.  It's mostly their choice.

Re: Newbie grief

[Junio C Hamano]

Ronan Keryell <Ronan.Keryell@hpc-project.com> writes:

>>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich Pixley <rich.pixley@palm.com> said:
>
>     Rich> * the hg error messages are straightforward, clear, and don't
>     Rich> require any deep knowledge of the source code control system
>     Rich> or it's limitations.  (I still don't understand what the git
>     Rich> message on collision is saying.)
>
> This is a very good suggestion.
> ...
> At least, print a simpler message with some typical use case causing
> this and some workflow ideas before the detailed explanation.

It indeed is a good starting point to make a suggestion, but there is
nothing actionable in the above by itself, especially since "typical use
case" is quite different for different Git users.

Re: Newbie grief

[Ronan Keryell]

>>>>> On Thu, 03 May 2012 14:13:40 -0700, Junio C Hamano <gitster@pobox.com> said:

    >> This is a very good suggestion.  ...  At least, print a simpler
    >> message with some typical use case causing this and some workflow
    >> ideas before the detailed explanation.

    Junio> It indeed is a good starting point to make a suggestion, but
    Junio> there is nothing actionable in the above by itself,
    Junio> especially since "typical use case" is quite different for
    Junio> different Git users.

Right.

Just add a new git config entry defining "typical use case". :-)
And we can recurse to define what is the default value of this and so
on... :-)

Just to be constructive, in the previous case, adding something like
"It appears that you are trying to push some modifications on a remote
server on a branch that has been updated. It may be due to someone
having worked on it in the meantime. To go on, you may first do a
git merge .... <automatically generated>
and try again after solving this so that we are able to precisely track
the real history of your project."

The last sentence is to motivate the user to do what may be complicated
when coming from, say, SVN, and who do not really care with... real
history. ;-)

Well I'm not a native English speaker, but I hope you can get the idea.

After that, there are some other use cases, but I'm not sure that in
this case this kind of message would help, because you may have some
deeper knowledge of git anyway.

For example for my software testing infrastructure, I push some stuff on
some remote git and I force the update of the remote branch anyway with
a git push -f.  If I forgot the '-f' I would have the same error message
above that would not be helpful for me. But anyway, this message is not
needed since I use git for my very own specific purpose in this case.
-- 
  Ronan KERYELL                            |\/  Phone:  +1 408 658 9453
  Wild Systems / HPC Project               |/)
  5201 Great America Parkway, Suite 320    K    Ronan.Keryell@wild-systems.com
  Santa Clara, CA 95054                    |\   skype:keryell
  USA                                      | \  http://wild-systems.com

Re: Newbie grief

[Rich Pixley]

On 5/3/12 14:13 , Junio C Hamano wrote:
> Ronan Keryell<Ronan.Keryell@hpc-project.com>  writes:
>>>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich Pixley<rich.pixley@palm.com>  said:
>>      Rich>  * the hg error messages are straightforward, clear, and don't
>>      Rich>  require any deep knowledge of the source code control system
>>      Rich>  or it's limitations.  (I still don't understand what the git
>>      Rich>  message on collision is saying.)
>>
>> This is a very good suggestion.
>> ...
>> At least, print a simpler message with some typical use case causing
>> this and some workflow ideas before the detailed explanation.
> It indeed is a good starting point to make a suggestion, but there is
> nothing actionable in the above by itself, especially since "typical use
> case" is quite different for different Git users.
How about, "Your push can't be made because it would cause an 
irreconcilable collision.  You probably want to pull and merge before 
attempting to push again."

--rich

Re: Newbie grief

[Rich Pixley]

On 5/3/12 15:33 , Rich Pixley wrote:
> On 5/3/12 14:13 , Junio C Hamano wrote:
>> Ronan Keryell<Ronan.Keryell@hpc-project.com>   writes:
>>>>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich Pixley<rich.pixley@palm.com>   said:
>>>       Rich>   * the hg error messages are straightforward, clear, and don't
>>>       Rich>   require any deep knowledge of the source code control system
>>>       Rich>   or it's limitations.  (I still don't understand what the git
>>>       Rich>   message on collision is saying.)
>>>
>>> This is a very good suggestion.
>>> ...
>>> At least, print a simpler message with some typical use case causing
>>> this and some workflow ideas before the detailed explanation.
>> It indeed is a good starting point to make a suggestion, but there is
>> nothing actionable in the above by itself, especially since "typical use
>> case" is quite different for different Git users.
> How about, "Your push can't be made because it would cause an
> irreconcilable collision.  You probably want to pull and merge before
> attempting to push again."

Er... "Your push can't be made because it would cause an irreconcilable 
collision.  You probably want to fetch and merge before attempting to 
push again."

--rich

Re: Newbie grief

[Rich Pixley]

On 5/3/12 14:09 , Junio C Hamano wrote:
> Michael Witten<mfwitten@gmail.com>  writes:
>
>> (Note, though, that Junio has done a laudable job of keeping the
>> whole experiment going strong).
>
> You are giving me too much credit, and at the same time insulting the
> people who polished Git enough to suit their workflow.  To them, the tool
> has past "experiment" stage long time ago.  They found what was lacking
> and what would help the need in their workflow.  I just have helped them
> shape their ideas into a coherent whole.
>
> That does not mean there is nothing missing, still appears experimental,
> or inconsistent in the parts of the system that these people do not use
> nor care about, and when you bring in people coming from different
> background, they will notice the behaviour or default that do not match
> their expectation.  They can do the usual "scratching own itches" thing
> the same way to others who have done before. As nobody forces them to do
> so, they can instead keep whining.  It's mostly their choice.

Once you've been bitten, and learned to shy away from the sore spot, you 
don't really have much motivation to change it.  The motivation to 
change it would be to make it easier for the next person.

Git clearly doesn't have much of that value in the community culture.

--rich

Re: Newbie grief

[Randal L. Schwartz]

>>>>> "Rich" == Rich Pixley <rich.pixley@palm.com> writes:

Rich> Git clearly doesn't have much of that value in the community
Rich> culture.

You don't know how wrong you are.  Good luck getting help after
disrespecting the very people who *are* trying to help you.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: Newbie grief

[Junio C Hamano]

Rich Pixley <rich.pixley@palm.com> writes:

> On 5/3/12 14:09 , Junio C Hamano wrote:
>> Michael Witten<mfwitten@gmail.com>  writes:
>>
>>> (Note, though, that Junio has done a laudable job of keeping the
>>> whole experiment going strong).
>>
>> You are giving me too much credit, and at the same time insulting the
>> people who polished Git enough to suit their workflow.  To them, the tool
>> has past "experiment" stage long time ago.  They found what was lacking
>> and what would help the need in their workflow.  I just have helped them
>> shape their ideas into a coherent whole.
>>
>> That does not mean there is nothing missing, still appears experimental,
>> or inconsistent in the parts of the system that these people do not use
>> nor care about, and when you bring in people coming from different
>> background, they will notice the behaviour or default that do not match
>> their expectation....
> 
> ...  The motivation to
> change it would be to make it easier for the next person.

That is how the workflow support elements that were originally missing
like reflogs, stashes, tracking branches, etc. all came to exist.  Making
it easier for the next person is why we had a large discussion on the
default behaviour of unconfigured push andthe follow-up implementation of
the "simple" push behaviour.  It is a good example that community members
are willing to help new person even at the expense of inconvenience to old
timers.

What does _not_ happen is to chase down people who whined and left without
giving us something concrete enough to base design of new workflow support
elements, but the community cannot police the behaviour of those who come,
whine and then leave, so...

Re: Newbie grief

[Hallvard Breien Furuseth]

 On Thu, 03 May 2012 11:20:56 -0700, Rich Pixley <rich.pixley@palm.com> 
 wrote:
> On 5/3/12 09:08 , Hallvard Breien Furuseth wrote:
>>   Aha, now this thread finally makes some sense.  So when Rich
>>   wants a "branch" with several tips, he actually wants several
>>   Git clones (repositories) with the same Git branch checked out -
>>   and some of them with local commits to it.
> Yes.
>>   And these commits can be shared as remote branches between the
>>   clones, which in Hg-speak means that in one particular clone,
>>   Git will "bookmark" the other clones' tips.
> Well, no.  In hg, these are all managed.  So there's no scaling
> issue.  They can all push/pull together, since they are really all
> just one shared branch.  Adding a new repository to the mix is
> trivial.  And either pushes or pulls can be used, or any combo.
>
> With git, I must manually make space for each and every repository,
> manually track which set of changes are where, manually track which
> need to be merged, and manually track which repositories are looking
> at which git branches so that they don't collide, or only collide in
> the current repository and only when I'm prepared to merge them.
> (...)

 If you say so.  I don't know Hg and I'm not about to try to guess
 if you're stuck in another misconception about Git or not, nor
 to re-read this entire thread substituting "clone" for "branch".

 Anyway, I notice you're now giving practical Hg examples to go
 with your Hg vocabulary instead talking Git in Hg vocabulary, so
 hopefully this'll get cleared up.

 Anyway, if you have not done so already: If you show this too with
 a practical Hg example instead of talking Git in a Hg vocabulary,
 maybe someone can help.

-- 
 Hallvard

Re: Newbie grief

[Hallvard Breien Furuseth]

 I wrote:
> Anyway, (...) Anyway, (...)

 Meh.  I hate cut&paste into/out of webmail.

-- 
 Hallvard

Re: Newbie grief

[Illia Bobyr]

On 5/3/2012 3:39 PM, Rich Pixley wrote:
> On 5/3/12 15:33 , Rich Pixley wrote:
>> On 5/3/12 14:13 , Junio C Hamano wrote:
>>> Ronan Keryell<Ronan.Keryell@hpc-project.com>   writes:
>>>>>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich 
>>>>>>>>> Pixley<rich.pixley@palm.com>   said:
>>>>       Rich>   * the hg error messages are straightforward, clear, 
>>>> and don't
>>>>       Rich>   require any deep knowledge of the source code control 
>>>> system
>>>>       Rich>   or it's limitations.  (I still don't understand what 
>>>> the git
>>>>       Rich>   message on collision is saying.)
>>>>
>>>> This is a very good suggestion.
>>>> ...
>>>> At least, print a simpler message with some typical use case causing
>>>> this and some workflow ideas before the detailed explanation.
>>> It indeed is a good starting point to make a suggestion, but there is
>>> nothing actionable in the above by itself, especially since "typical 
>>> use
>>> case" is quite different for different Git users.
>> How about, "Your push can't be made because it would cause an
>> irreconcilable collision.  You probably want to pull and merge before
>> attempting to push again."
>
> Er... "Your push can't be made because it would cause an 
> irreconcilable collision.  You probably want to fetch and merge before 
> attempting to push again."

While this error message makes more sense to you at this point it is not 
entirely true.
The collision is not irreconcilable and may not even be a collision.  
For example, if you just rebased, it is not a collision from a more 
abstract point of view.

It is just a "non-fast forward" move of a branch tip.  This term 
describes what happens precisely :)

It is true, that the term is non obvious to the new comers.
One may google and get an explanation of the error pretty quickly.  
First hit for "git non fast forward error" gives an explanation from a 
new comer point of view for the simplest case.

Another option is to change the way git "talks".  AFAIR there were a 
number of attempts to come up with a new dictionary for git.
I am not sure if any of the attempts were complete as it is not that easy.
Changing just one error message at a time would make it less consistent 
as a concept of "fast forward" moves is used in other places.
For example, git merge has --ff and --no-ff options that stand for "fast 
forwrad" and "no fast forward" respectively.

Illia Bobyr

Re: Newbie grief

[Nathan Gray]

On Thu, May 3, 2012 at 6:01 PM, Illia Bobyr <ibobyr@blizzard.com> wrote:
>
> It is just a "non-fast forward" move of a branch tip.  This term
> describes what happens precisely :)
>
> It is true, that the term is non obvious to the new comers.
> One may google and get an explanation of the error pretty quickly.
> First hit for "git non fast forward error" gives an explanation from a
> new comer point of view for the simplest case.

I just led a team of reasonably bright people through a transition
from SVN to git.  Not one of them understood this message.  Every one
of them thought something was broken.  This is a very common
occurrence, so a short, simple message without jargon for this error
would be a big, big win.

Cheers,
-n8

-- 
HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch
http://hexalex.com
On The App Store: http://bit.ly/8Mj1CU
On Facebook: http://bit.ly/9MIJiV
On Twitter: http://twitter.com/hexalexgame
http://n8gray.org

Re: Newbie grief

[Michael Witten]

On Thu, 3 May 2012 20:13:01 -0700, Nathan Gray wrote:

> On Thu, May 3, 2012 at 6:01 PM, Illia Bobyr <ibobyr@blizzard.com> wrote:
>>
>> It is just a "non-fast forward" move of a branch tip.  This term
>> describes what happens precisely :)
>>
>> It is true, that the term is non obvious to the new comers.
>> One may google and get an explanation of the error pretty quickly.
>> First hit for "git non fast forward error" gives an explanation from a
>> new comer point of view for the simplest case.
>
> I just led a team of reasonably bright people through a transition
> from SVN to git.  Not one of them understood this message.  Every one
> of them thought something was broken.  This is a very common
> occurrence, so a short, simple message without jargon for this error
> would be a big, big win.

Well, what is your suggestion?

Nobody in this thread has yet provided an explicit improvement because
the actual complaint is that the vast majority of people (including
supposed "professionals") don't RTFM; it never even occurs to them!

Let's look at the message in question:

  To $uri_for_central_repo
   ! [rejected]        HEAD -> feature_0 (non-fast-forward)
  error: failed to push some refs to '$uri_for_central_repo'
  To prevent you from losing history, non-fast-forward updates were rejected
  Merge the remote changes (e.g. 'git pull') before pushing again.  See the
  'Note about fast-forwards' section of 'git push --help' for details.

Not only does this already spoonfeed the reader with a suggested
command for getting back on track (i.e., 'git pull'), but it also
explicitly points out the relevant documentation and HOW to gain
immediate access to that information from the command line!

As for a seemingly conservative suggestion, how about using a little
more structural white space:

  To $uri_for_central_repo
   ! [rejected]        HEAD -> feature_0 (non-fast-forward)

  error: failed to push some refs to '$uri_for_central_repo'

  To prevent you from losing history, non-fast-forward updates were rejected
  Merge the remote changes (e.g. 'git pull') before pushing again.  See the
  'Note about fast-forwards' section of 'git push --help' for details.

Alas! Error output like this is constructed in the code in a way that
potentially makes adding such white space non-trivial.

Perhaps the error message system needs an overhall; rather than spitting
out error messages from anywhere, they ought to be corralled and collated
by a dedicated subsystem.

Re: Newbie grief

[Junio C Hamano]

Michael Witten <mfwitten@gmail.com> writes:

> As for a seemingly conservative suggestion, how about using a little
> more structural white space:
>
>   To $uri_for_central_repo
>    ! [rejected]        HEAD -> feature_0 (non-fast-forward)
>
>   error: failed to push some refs to '$uri_for_central_repo'
>
>   To prevent you from losing history, non-fast-forward updates were rejected
>   Merge the remote changes (e.g. 'git pull') before pushing again.  See the
>   'Note about fast-forwards' section of 'git push --help' for details.
>
> Alas! Error output like this is constructed in the code in a way that
> potentially makes adding such white space non-trivial.
>
> Perhaps the error message system needs an overhall; rather than spitting
> out error messages from anywhere, they ought to be corralled and collated
> by a dedicated subsystem.

Didn't somebody recently rework these messages quite extensively?

Re: Newbie grief

[Carlos Martín Nieto]

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

On Thu, 2012-05-03 at 22:25 -0700, Junio C Hamano wrote:
> Michael Witten <mfwitten@gmail.com> writes:
> 
> > As for a seemingly conservative suggestion, how about using a little
> > more structural white space:
> >
> >   To $uri_for_central_repo
> >    ! [rejected]        HEAD -> feature_0 (non-fast-forward)
> >
> >   error: failed to push some refs to '$uri_for_central_repo'
> >
> >   To prevent you from losing history, non-fast-forward updates were rejected
> >   Merge the remote changes (e.g. 'git pull') before pushing again.  See the
> >   'Note about fast-forwards' section of 'git push --help' for details.
> >
> > Alas! Error output like this is constructed in the code in a way that
> > potentially makes adding such white space non-trivial.
> >
> > Perhaps the error message system needs an overhall; rather than spitting
> > out error messages from anywhere, they ought to be corralled and collated
> > by a dedicated subsystem.
> 
> Didn't somebody recently rework these messages quite extensively?

If you're thinking of me, I only changed the pull/rebase side, which was
a ridiculously bad message. As this subthread looks like it might
actually have something actionable, let me look at this message with the
same critical eyes.

Most of the first sentence repeats what we can see above. Restating that
non-ff updates were rejected doesn't add information and doesn't help
people who don't already know what a non-ff update is, so it's either
redundant or not helpful[0]. So lets see if we can come up with a
friendlier way of saying it. Maybe something like:

    To $uri_for_central_repo
    ! [rejected]        HEAD -> feature_0 (non-fast-forward)

    error: failed to push some refs to '$uri_for_central_repo'

    Some updates which might rewrite history and lose someone else's
    changes were rejected. Merge those changes (e.g. 'git pull') to
    incorporate that history. See the 'Note about fast-forwards' section
    of 'git push --help' for details.

It may be a bit longer, but if you don't know what a non-ff is or why
it's a problem, this text should help you a lot more than the previous
one did. Not reading the documentation (specially when the error message
points you to a specific section for a longer explanation) is still no
excuse for not known what's going on, but if you've been working on your
own for a while, you might have forgotten what this is all about.[1]

If people don't have it, I'll try to find time to create a patch.

   cmn

[0] Or worse, as repeating jargon can leave the user thinking that they
don't understand anything and reduces the chanced they'd try to figure
out the missing parts. I'd qualify this with friendliness rather than
anything else, as the message isn't wrong or misleading, just rather
on-your-face.

[1] At least this is show I rationalise why doing saying "non-ff updates
rejected. Read the ff section of the push manpage for an explanation"
isn't the right thing to do.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Newbie grief

[Andreas Ericsson]

On 05/03/2012 08:58 PM, Rich Pixley wrote:
> On 5/1/12 16:30 , Felipe Contreras wrote:
>> Show all the hg commands of what you are trying to do, and we can show
>> you how you can achieve the same in git, but much more easily.
> hg init foo
> for i in `yes | head -4000`; do (set -x ; d=`date +%s.%N` ; hg clone foo foo-$d; (cd foo-$d && date > bar && hg add bar && hg ci -m $d)); done
> for i in foo-*; do (set -x ; (cd $i && hg push -f)); done
> 

Here's how that would look in git (though I got rid of the timestamp
stuff and used seq instead):

git init foo
for i in $(seq 1 4000); do git clone foo foo-$i; (cd foo-$i && date > bar && git add bar && git commit -m "$i"; done)
for i in foo-*; do (set -x; (cd $i && git push master:$i/master)); done

The hg recipe creates 4000 branches which I for some reason can't
find the names of so I have no idea how to interact with them. The
git recipe names them explicitly to foo-$i/master in the foo/ repo,
since git doesn't allow pushing of commits without a ref.


Having read further in the thread, I see you did "hg merge" to merge
*all* the branches (which is impressive in itself, doing a 4000-way
merge), but I still don't see how you'd go about merging just one of
them. Perhaps that's not desirable.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: Newbie grief

[Junio C Hamano]

Carlos Martín Nieto <cmn@elego.de> writes:

> On Thu, 2012-05-03 at 22:25 -0700, Junio C Hamano wrote:
>> Michael Witten <mfwitten@gmail.com> writes:
>> 
>> > As for a seemingly conservative suggestion, how about using a little
>> > more structural white space:
>> >
>> >   To $uri_for_central_repo
>> >    ! [rejected]        HEAD -> feature_0 (non-fast-forward)
>> >
>> >   error: failed to push some refs to '$uri_for_central_repo'
>> >
>> >   To prevent you from losing history, non-fast-forward updates were rejected
>> >   Merge the remote changes (e.g. 'git pull') before pushing again.  See the
>> >   'Note about fast-forwards' section of 'git push --help' for details.
>> >
>> > Alas! Error output like this is constructed in the code in a way that
>> > potentially makes adding such white space non-trivial.
>> >
>> > Perhaps the error message system needs an overhall; rather than spitting
>> > out error messages from anywhere, they ought to be corralled and collated
>> > by a dedicated subsystem.
>> 
>> Didn't somebody recently rework these messages quite extensively?
>
> If you're thinking of me,...

No, I was referring to f25950f (push: Provide situational hints for
non-fast-forward errors, 2012-03-20).

Re: Newbie grief

[Stephen Bash]

----- Original Message -----
> From: "Andreas Ericsson" <ae@op5.se>
> Sent: Friday, May 4, 2012 10:09:30 AM
> Subject: Re: Newbie grief
> 
> On 05/03/2012 08:58 PM, Rich Pixley wrote:
> > On 5/1/12 16:30 , Felipe Contreras wrote:
> > > Show all the hg commands of what you are trying to do, and we can
> > > show you how you can achieve the same in git, but much more
> > > easily.
> >
> > hg init foo
> > for i in `yes | head -4000`; do (set -x ; d=`date +%s.%N` ; hg
> > clone foo foo-$d; (cd foo-$d && date > bar && hg add bar && hg ci
> > -m $d)); done
> > for i in foo-*; do (set -x ; (cd $i && hg push -f)); done
>
> ... snip ... 
> 
> The hg recipe creates 4000 branches which I for some reason can't
> find the names of so I have no idea how to interact with them. The
> git recipe names them explicitly to foo-$i/master in the foo/ repo,
> since git doesn't allow pushing of commits without a ref.

If my hg-foo isn't too out of date...  The hg recipe creates 4000 "heads" on a single branch, rather than 4000 branches (see the 'hg heads' command).  This is basically the point Rich is arguing I believe.  hg allows for multiple tip commits all with the same branch name (IMO this is important because hg branch names are permanently recorded in their version of the commit object).

This is a *fundamental* difference in the implementation of the two tools (and causes confusion because now "branch" has two slightly different meanings).  However, IMHO, philosophically it all boils down to the same thing: development has forked and has to be merged.  Whether that fork has a name or not is up to the tool.  In hg it doesn't *have* to have a name (multiple heads per branch), in git it does (single head per branch).

I personally find Git's enforcement of naming a good thing: either the change I just made should be incorporated into the original branch, or there is a reason for it to stay separate.  In the latter case I should name it in a meaningful way so I (and other team members) remember why it is being kept separate (similar to why we use meaningful variable names).  In the former, I fetch and then merge or rebase as appropriate before pushing back upstream.

HTH,
Stephen

Re: Newbie grief

[Mark Brown]

On Thu, May 03, 2012 at 01:52:35PM -0700, Rich Pixley wrote:

> It's not just hg.  It's other source code control systems as well.
> Check out any of the other daggy guys.  So sure, I'll admit a bias
> for current technology over older tech.

I'm still not sure what's missing here without a central server?   The
other DVCSs I've used (which don't include hg) do require that the user
trigger a merge operation somehow; they don't magically go and merge
things without being asked.  The only thing I've noticed that git does
differently is that it caches the remote branches locally by default
when remotes are set up.

Re: Newbie grief

[Mark Brown]

On Fri, May 04, 2012 at 10:59:30AM -0400, Stephen Bash wrote:

> If my hg-foo isn't too out of date...  The hg recipe creates 4000
> "heads" on a single branch, rather than 4000 branches (see the 'hg
> heads' command).  This is basically the point Rich is arguing I
> believe.  hg allows for multiple tip commits all with the same branch
> name (IMO this is important because hg branch names are permanently
> recorded in their version of the commit object).

> This is a *fundamental* difference in the implementation of the two
> tools (and causes confusion because now "branch" has two slightly
> different meanings).  However, IMHO, philosophically it all boils down
> to the same thing: development has forked and has to be merged.
> Whether that fork has a name or not is up to the tool.  In hg it
> doesn't *have* to have a name (multiple heads per branch), in git it
> does (single head per branch).

Ah, this makes some sense - I *think* it's coming down not so much that
you have to name the branches (googling around it seems hg does assign
names, it's just that they're autogenerated numbers) as to the fact that
unless you branch directly from wherever your origin repository is git
doesn't keep track of where you're ultimately trying to merge development
back to.

If the above is right then some UI around remotes and branch --track and
--set-upstream which provides an automated way of saying "this is a
scratch branch for merge into X" and can then do things like helping
with merging and enumerating all the scratch branches for a given
destination, or with bundling up all the scratch branches and dropping
them elsewhere for merge might do the trick?  A "strong" branch kind of
thing.

This does come up a bit with traditional git workflows - I have it a
little when working between my desktop and my laptop - but is IME
usually resolved by publishing frequently to some central location
frequently and then rebasing if lots of local merges aren't approved of
in your workflow.  git (at least in kernel usage) has more of a
"building a patch series" model oriented around preparing things for
review.

Re: Newbie grief

[Nathan Gray]

On Fri, May 4, 2012 at 3:09 AM, Carlos Martín Nieto <cmn@elego.de> wrote:
> On Thu, 2012-05-03 at 22:25 -0700, Junio C Hamano wrote:
>> Michael Witten <mfwitten@gmail.com> writes:
>>
>> > As for a seemingly conservative suggestion, how about using a little
>> > more structural white space:
>> >
>> >   To $uri_for_central_repo
>> >    ! [rejected]        HEAD -> feature_0 (non-fast-forward)
>> >
>> >   error: failed to push some refs to '$uri_for_central_repo'
>> >
>> >   To prevent you from losing history, non-fast-forward updates were rejected
>> >   Merge the remote changes (e.g. 'git pull') before pushing again.  See the
>> >   'Note about fast-forwards' section of 'git push --help' for details.
>> >
>
> Most of the first sentence repeats what we can see above. Restating that
> non-ff updates were rejected doesn't add information and doesn't help
> people who don't already know what a non-ff update is, so it's either
> redundant or not helpful[0]. So lets see if we can come up with a
> friendlier way of saying it. Maybe something like:
>
>    To $uri_for_central_repo
>    ! [rejected]        HEAD -> feature_0 (non-fast-forward)
>
>    error: failed to push some refs to '$uri_for_central_repo'
>
>    Some updates which might rewrite history and lose someone else's
>    changes were rejected. Merge those changes (e.g. 'git pull') to
>    incorporate that history. See the 'Note about fast-forwards' section
>    of 'git push --help' for details.
>
> It may be a bit longer, but if you don't know what a non-ff is or why
> it's a problem, this text should help you a lot more than the previous
> one did. Not reading the documentation (specially when the error message
> points you to a specific section for a longer explanation) is still no
> excuse for not known what's going on, but if you've been working on your
> own for a while, you might have forgotten what this is all about.[1]

The whitespace that Michael introduced is a big help, for starters,
and this rewording is also a nice step forward.  I'm still not
thrilled about the "rewriting history" verbiage -- that makes it sound
like the user did something super risky and was rescued by the system.
 Here's my suggestion for replacing the last paragraph:

  Some of your branches are out of date.  Merge the remote changes
(e.g. 'git pull') then try again.

It's short and easy to scan.  It has no git-specific jargon that new
users would be unfamiliar with.  There's no reference to fast-forward
updates so no need to refer the user to that help section.  What do
you think?

Cheers,
-n8

-- 
HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch
http://hexalex.com
On The App Store: http://bit.ly/8Mj1CU
On Facebook: http://bit.ly/9MIJiV
On Twitter: http://twitter.com/hexalexgame
http://n8gray.org

Re: Newbie grief

[Illia Bobyr]

On 5/4/2012 9:46 AM, Nathan Gray wrote:
> On Fri, May 4, 2012 at 3:09 AM, Carlos Martín Nieto<cmn@elego.de>  wrote:
>> On Thu, 2012-05-03 at 22:25 -0700, Junio C Hamano wrote:
>>> Michael Witten<mfwitten@gmail.com>  writes:
>>>
>>>> As for a seemingly conservative suggestion, how about using a little
>>>> more structural white space:
>>>>
>>>>    To $uri_for_central_repo
>>>>     ! [rejected]        HEAD ->  feature_0 (non-fast-forward)
>>>>
>>>>    error: failed to push some refs to '$uri_for_central_repo'
>>>>
>>>>    To prevent you from losing history, non-fast-forward updates were rejected
>>>>    Merge the remote changes (e.g. 'git pull') before pushing again.  See the
>>>>    'Note about fast-forwards' section of 'git push --help' for details.
>>>>
>> Most of the first sentence repeats what we can see above. Restating that
>> non-ff updates were rejected doesn't add information and doesn't help
>> people who don't already know what a non-ff update is, so it's either
>> redundant or not helpful[0]. So lets see if we can come up with a
>> friendlier way of saying it. Maybe something like:
>>
>>     To $uri_for_central_repo
>>     ! [rejected]        HEAD ->  feature_0 (non-fast-forward)
>>
>>     error: failed to push some refs to '$uri_for_central_repo'
>>
>>     Some updates which might rewrite history and lose someone else's
>>     changes were rejected. Merge those changes (e.g. 'git pull') to
>>     incorporate that history. See the 'Note about fast-forwards' section
>>     of 'git push --help' for details.
>>
>> It may be a bit longer, but if you don't know what a non-ff is or why
>> it's a problem, this text should help you a lot more than the previous
>> one did. Not reading the documentation (specially when the error message
>> points you to a specific section for a longer explanation) is still no
>> excuse for not known what's going on, but if you've been working on your
>> own for a while, you might have forgotten what this is all about.[1]
> The whitespace that Michael introduced is a big help, for starters,
> and this rewording is also a nice step forward.  I'm still not
> thrilled about the "rewriting history" verbiage -- that makes it sound
> like the user did something super risky and was rescued by the system.
>   Here's my suggestion for replacing the last paragraph:
>
>    Some of your branches are out of date.  Merge the remote changes
> (e.g. 'git pull') then try again.
>
> It's short and easy to scan.  It has no git-specific jargon that new
> users would be unfamiliar with.  There's no reference to fast-forward
> updates so no need to refer the user to that help section.  What do
> you think?

Not everybody is a new user :)
Throwing away a precise explanation for the purpose of avoiding a 
possible confusion for someone who either just started (and will have to 
learn the terms anyway) or for someone who does not really care to learn 
is a decision that I would weight very carefully.

Just as I side note, I lead a team of an ordinary developers through a 
transition from CVS to Git and there were pretty much fine with the fact 
that there are pieces in such a complex system as Git that they do not 
understand immediately.  Over a couple of month everyone who cared or 
required this knowledge knew what a fast-forward is.  And people who did 
not care just learn to do git pull as the message suggests.

I think that a reference to the documentation is very nice.  I remember 
that this kind of references allowed me to learn Git gradually as I was 
facing different usage scenarios instead of reading the whole 
documentation for all the tools.

Re: Newbie grief

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Carlos Martín Nieto <cmn@elego.de> writes:
>
>>> Didn't somebody recently rework these messages quite extensively?
>>
>> If you're thinking of me,...
>
> No, I was referring to f25950f (push: Provide situational hints for
> non-fast-forward errors, 2012-03-20).

If anybody wants to further discuss possible rephrasing of the advice
messages, please do not base your discussion without what was discussed
already in the previous round and what issues need to be taken into
account.

A good text to use as the starting point of your discussion is the advice
messages in 'master'; use c5da24a (Merge branch 'ct/advise-push-default',
2012-04-20) or anything more recent.  Also see

    http://thread.gmane.org/gmane.comp.version-control.git/193079

for the discussion that led to the current text.

Re: Newbie grief

[Rich Pixley]

On 5/3/12 21:35 , Michael Witten wrote:
> On Thu, 3 May 2012 20:13:01 -0700, Nathan Gray wrote:
>
>> On Thu, May 3, 2012 at 6:01 PM, Illia Bobyr<ibobyr@blizzard.com>  wrote:
>>> It is just a "non-fast forward" move of a branch tip.  This term
>>> describes what happens precisely :)
>>>
>>> It is true, that the term is non obvious to the new comers.
>>> One may google and get an explanation of the error pretty quickly.
>>> First hit for "git non fast forward error" gives an explanation from a
>>> new comer point of view for the simplest case.
>> I just led a team of reasonably bright people through a transition
>> from SVN to git.  Not one of them understood this message.  Every one
>> of them thought something was broken.  This is a very common
>> occurrence, so a short, simple message without jargon for this error
>> would be a big, big win.
> Well, what is your suggestion?
>
> Nobody in this thread has yet provided an explicit improvement because
> the actual complaint is that the vast majority of people (including
> supposed "professionals") don't RTFM; it never even occurs to them!
>
> Let's look at the message in question:
>
>    To $uri_for_central_repo
>     ! [rejected]        HEAD ->  feature_0 (non-fast-forward)
>    error: failed to push some refs to '$uri_for_central_repo'
>    To prevent you from losing history, non-fast-forward updates were rejected
>    Merge the remote changes (e.g. 'git pull') before pushing again.  See the
>    'Note about fast-forwards' section of 'git push --help' for details.
>
> Not only does this already spoonfeed the reader with a suggested
> command for getting back on track (i.e., 'git pull'), but it also
> explicitly points out the relevant documentation and HOW to gain
> immediate access to that information from the command line!
Let's take it line by line.

"Rejected - mumble" - the tool did not do what you asked.
"error: failed to mumble"  - your data is corrupt.
"To prevent you mumble mumble" - you're not allowed to do what you want

I stopped reading there.

I'm not saying this is a correct interpretation.  I'm offering it as a 
data point from a sophisticated, although new, user.

I've already offered a suggestion for rewording.

--rich

Re: Newbie grief

[Rich Pixley]

On 5/4/12 03:09 , Carlos Martín Nieto wrote:
>      To $uri_for_central_repo
>      ! [rejected]        HEAD ->  feature_0 (non-fast-forward)
>
>      error: failed to push some refs to '$uri_for_central_repo'
>
>      Some updates which might rewrite history and lose someone else's
>      changes were rejected. Merge those changes (e.g. 'git pull') to
>      incorporate that history. See the 'Note about fast-forwards' section
>      of 'git push --help' for details.

I'd like to suggest "declined" instead of "failed".  "error: failed" 
suggests an error in the data or in the tool rather than a default or a 
choice on the part of a UI designer.

The first few times I got this error I presumed that it was telling me 
my destination repository was corrupt.  So I salvaged my changes with 
diff and patch, trashed the repository, and cloned a fresh one, (which 
didn't show this error when I pushed to it.)

--rich

Re: Newbie grief

[Rich Pixley]

On 5/4/12 08:56 , Mark Brown wrote:
> On Thu, May 03, 2012 at 01:52:35PM -0700, Rich Pixley wrote:
>
>> It's not just hg.  It's other source code control systems as well.
>> Check out any of the other daggy guys.  So sure, I'll admit a bias
>> for current technology over older tech.
>
> I'm still not sure what's missing here without a central server?   The
> other DVCSs I've used (which don't include hg) do require that the user
> trigger a merge operation somehow; they don't magically go and merge
> things without being asked.

Nor does hg.  Rather, it allows the collision to be tracked within the 
source code control tool so that anyone who wants to see it can do so, 
and so that anyone who wants to merge it can do so.  The data flow paths 
for collisions and proposed changes can follow precisely the same paths 
as any other code changes.  No meta channel is required.

This is a different situation from either the one where I, specifically 
me, must merge or the one where I intend my changes to stay separated 
from other development, (a new "branch").  The situation with multiple 
heads allows the merge, the branch, even the decision about whether to 
merge or branch, to be delayed indefinitely.

The fact that it allows for this also allows for a number of different 
repository network architectures, all of which are blocked in git 
because of the push problem.  In git, those decisions must be made 
_before_ the push.

There's also a possibility of nonterminating merges.  That is, if my 
team is making changes faster than you can merge them, then you'll never 
get to push your changes.  With dual heads, you still can.  And then 
anyone who wants to can merge them.

--rich

Re: Newbie grief

[Jérôme Benoit]

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

On Thu, 03 May 2012 12:13:46 -0700
Rich Pixley <rich.pixley@palm.com> wrote:

 
> * the hg commands are simpler and have the defaults that we want, 
> primarily because no extra branches are required.

You can mimic them with a brand new porclain.

For example, the worklfow described here : 

http://nvie.com/posts/a-successful-git-branching-model/

have been implemented here : 

https://github.com/nvie/gitflow

Since git do not have by design the multi HEAD hg design, you will
still not have it but all the glory command chains to mimic it can be
done with some shell scripts and a good knowledge of git internals. 

Regards,  

-- 
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Newbie grief

[Felipe Contreras]

On Thu, May 3, 2012 at 8:58 PM, Rich Pixley <rich.pixley@palm.com> wrote:
> On 5/1/12 16:30 , Felipe Contreras wrote:
>>
>> Show all the hg commands of what you are trying to do, and we can show
>> you how you can achieve the same in git, but much more easily.
>
> hg init foo
> for i in `yes | head -4000`; do (set -x ; d=`date +%s.%N` ; hg clone foo
> foo-$d; (cd foo-$d && date > bar && hg add bar && hg ci -m $d)); done
> for i in foo-*; do (set -x ; (cd $i && hg push -f)); done

Well, that's your problem right there; you are doing something totally stupid.

Even the mercurial documentation tells you so:

---
By default, push will not allow creation of new heads at the
destination, since multiple heads would make it unclear which head to
use. In this situation, it is recommended to pull and merge before
pushing.
---

The git way (which happens to be the mercurial way too), is to fetch
and merge (pull) before pushing:

do_commit() { (cd $1 && date +%N > bar && git add bar && git commit -m "$2") ;}
git init foo; do_commit foo "Initial commit"
for i in $(seq 1 10); do git clone foo foo-$i; do_commit foo-$i $i; done
for i in foo-*; do (set -x; (cd $i && git pull -s ours --no-edit; git
push)); done

Do you seriously think it makes sense to have 4000 people doing
independent development on 4000 different lines of development all
ignoring each other? Which of the 4000 heads would you pick to test
this "branch"? Who is going to do the merge of these 4000 heads?

This is a recipe for disaster.

You prefer a DVCS that allows you to do stupid stuff, well that's your
choice, but don't blame git for making it difficult for you to do
stupid stuff. You should stop doing that and follow the git/mercurial
way; fetch/pull, merge, and push.

Cheers.

-- 
Felipe Contreras

Re: Newbie grief

[Jakub Narebski]

Rich Pixley <rich.pixley@palm.com> writes:
> On 5/4/12 08:56 , Mark Brown wrote:
> > On Thu, May 03, 2012 at 01:52:35PM -0700, Rich Pixley wrote:
> >
> > > It's not just hg.  It's other source code control systems as well.
> > > Check out any of the other daggy guys.  So sure, I'll admit a bias
> > > for current technology over older tech.
> >
> > I'm still not sure what's missing here without a central server?   The
> > other DVCSs I've used (which don't include hg) do require that the user
> > trigger a merge operation somehow; they don't magically go and merge
> > things without being asked.
> 
> Nor does hg.  Rather, it allows the collision to be tracked within the
> source code control tool so that anyone who wants to see it can do so,
> and so that anyone who wants to merge it can do so.  The data flow
> paths for collisions and proposed changes can follow precisely the
> same paths as any other code changes.  No meta channel is required.
> 
> This is a different situation from either the one where I,
> specifically me, must merge or the one where I intend my changes to
> stay separated from other development, (a new "branch").  The
> situation with multiple heads allows the merge, the branch, even the
> decision about whether to merge or branch, to be delayed indefinitely.
> 
> The fact that it allows for this also allows for a number of different
> repository network architectures, all of which are blocked in git
> because of the push problem.  In git, those decisions must be made
> _before_ the push.

Well, perhaps Git doesn't support "central repository" workflow, where
users push to common repository, as well as Mercurial.  The main
workflow is based on pairs of private (non-bare) + public (bare)
repositories, one pair for each developer.  You push to own
repository, and pull from other public repositories.
 
Note that there is no problem in Git in "pull" direction (at least for
pulling single branch): you either fast-forward (be updated), or be
asked to perform a merge.  Instead of anonymous heads you get
automatically named remote-tracking branches.

With respect to "push" direction Git assumes that you don't have shell
access to remote repository, so there is nobody to perform a merge;
hence assymetry between "git pull" and "git push".

BTW. can you get in Mercurial which anonymous head comes from which
repository?

> There's also a possibility of nonterminating merges.  That is, if my
> team is making changes faster than you can merge them, then you'll
> never get to push your changes.  With dual heads, you still can.  And
> then anyone who wants to can merge them.

Well, if you have that much activity, you better switch workflows away
from "central repository" one, perhaps to maintainer + lieutenants
pull-based workflow.

Or you can axplicitely push to side branch 

  $ git push repo master:foo/master

and ask in side channel to merge it.


For me using multi-tailed (multi-head) branches instead of
remote-tracking branches serves to blur important distinction
(assymetry) between pull and push directions.


Now if I understand correctly what you wanted to have is a set of
remote repositories, updated only by you (or at least updated in such
way that fast-forward non-merge updates are more common than merges),
and a way to fetch from those repositories so that branches gets
updated to most recent version from among the set of those
repositories, isn't it?

That's quite advanced workflow / requirement, isn't it?

-- 
Jakub Narebski

Re: Newbie grief

[Andrew Sayers]

On 04/05/12 04:13, Nathan Gray wrote:
> I just led a team of reasonably bright people through a transition
> from SVN to git.  Not one of them understood this message.  Every one
> of them thought something was broken.  This is a very common
> occurrence, so a short, simple message without jargon for this error
> would be a big, big win.

Now you come to mention it, I had the same experience a while back.

The message could certainly do with improvement, but I think this
particular case is more a side-effect of the push.default issue
currently being worked through.  Beginners expect `git push` to push a
single branch, so they see "error" and assume the single branch they
pushed must have failed.

	- Andrew

Re: Newbie grief

[Michael Witten]

On Fri, May 4, 2012 at 5:57 PM, Rich Pixley <rich.pixley@palm.com> wrote:
> On 5/3/12 21:35 , Michael Witten wrote:
>>
>> On Thu, 3 May 2012 20:13:01 -0700, Nathan Gray wrote:
>>
>>> On Thu, May 3, 2012 at 6:01 PM, Illia Bobyr<ibobyr@blizzard.com>  wrote:
>>>>
>>>> It is just a "non-fast forward" move of a branch tip.  This term
>>>> describes what happens precisely :)
>>>>
>>>> It is true, that the term is non obvious to the new comers.
>>>> One may google and get an explanation of the error pretty quickly.
>>>> First hit for "git non fast forward error" gives an explanation from a
>>>> new comer point of view for the simplest case.
>>>
>>> I just led a team of reasonably bright people through a transition
>>> from SVN to git.  Not one of them understood this message.  Every one
>>> of them thought something was broken.  This is a very common
>>> occurrence, so a short, simple message without jargon for this error
>>> would be a big, big win.
>>
>> Well, what is your suggestion?
>>
>> Nobody in this thread has yet provided an explicit improvement because
>> the actual complaint is that the vast majority of people (including
>> supposed "professionals") don't RTFM; it never even occurs to them!
>>
>> Let's look at the message in question:
>>
>>   To $uri_for_central_repo
>>    ! [rejected]        HEAD ->  feature_0 (non-fast-forward)
>>   error: failed to push some refs to '$uri_for_central_repo'
>>   To prevent you from losing history, non-fast-forward updates were
>> rejected
>>   Merge the remote changes (e.g. 'git pull') before pushing again.  See
>> the
>>   'Note about fast-forwards' section of 'git push --help' for details.
>>
>> Not only does this already spoonfeed the reader with a suggested
>> command for getting back on track (i.e., 'git pull'), but it also
>> explicitly points out the relevant documentation and HOW to gain
>> immediate access to that information from the command line!
>
> Let's take it line by line.
>
> "Rejected - mumble" - the tool did not do what you asked.
> "error: failed to mumble"  - your data is corrupt.
> "To prevent you mumble mumble" - you're not allowed to do what you want
>
> I stopped reading there.

You are not somebody worth helping.

> I'm not saying this is a correct interpretation.  I'm offering it as a data
> point from a sophisticated, although new, user.

LOL

Re: Newbie grief

[Felipe Contreras]

On Fri, May 4, 2012 at 12:44 AM, Rich Pixley <rich.pixley@palm.com> wrote:

> Git clearly doesn't have much of that value in the community culture.

And you are clearly delusional.

You don't like git, we get it, can you stop listing the ways git sucks
on every paragraph you write? Thanks.

And here's a lesson about reality; reality doesn't care what you
think. When you say git is X, Y, and Z, that doesn't mean it's true;
that's what you *think*; but what you need to understand is that what
you *think* might be totally wrong.

These are called value judgments, and you should stop assuming your
value judgments are truths, it would make it less annoying for people
to discuss with you (specially on a mailing list about the thing you
are constantly bashing), and it would help you save face when it turns
out you are totally wrong.

tl;dr: value judgments != truths

Cheers.

-- 
Felipe Contreras

Re: Newbie grief

[Felipe Contreras]

On Wed, May 2, 2012 at 12:56 AM, Michael Witten <mfwitten@gmail.com> wrote:
> On Tue, May 1, 2012 at 9:57 PM, Rich Pixley <rich.pixley@palm.com> wrote:
>
>> In contrast, I was up and using mercurial in about a day and a half,
>> including all of the stuff we've discussed, and all of the things I've even
>> read about in git.  Learning mq's only took about 20 minutes.
>
> Fortunately, git is based on extremely simple principles.
> Unfortunately, git grew out of really bright people hacking stuff
> together in order to get sh!t dun; the result is not approachably or
> even well documented, the UI is sometimes a bit of a kludge, the API
> is probably nonexistent, and the terminology is so loosely thrown
> about that it's easy to forget which way is up in discussions.
> (Note, though, that Junio has done a laudable job of keeping the
> whole experiment going strong).

You are a prime example of this experiment called 'life', also based
on extremely simple principles, mostly through trial and error. Design
is overrated :)

-- 
Felipe Contreras

Re: Newbie grief

[Michael Witten]

On Fri, May 4, 2012 at 7:30 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Wed, May 2, 2012 at 12:56 AM, Michael Witten <mfwitten@gmail.com> wrote:
>> On Tue, May 1, 2012 at 9:57 PM, Rich Pixley <rich.pixley@palm.com> wrote:
>>
>>> In contrast, I was up and using mercurial in about a day and a half,
>>> including all of the stuff we've discussed, and all of the things I've even
>>> read about in git.  Learning mq's only took about 20 minutes.
>>
>> Fortunately, git is based on extremely simple principles.
>> Unfortunately, git grew out of really bright people hacking stuff
>> together in order to get sh!t dun; the result is not approachably or
>> even well documented, the UI is sometimes a bit of a kludge, the API
>> is probably nonexistent, and the terminology is so loosely thrown
>> about that it's easy to forget which way is up in discussions.
>> (Note, though, that Junio has done a laudable job of keeping the
>> whole experiment going strong).
>
> You are a prime example of this experiment called 'life', also based
> on extremely simple principles, mostly through trial and error. Design
> is overrated :)

There is no process other than trial and error, or more precisely,
variation and selection.

Note, though, that the levels of sophistication involved with variation
and selection differ among manifestations of this process.

Re: Newbie grief

[Mark Brown]

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

On Fri, May 04, 2012 at 11:23:10AM -0700, Rich Pixley wrote:

> This is a different situation from either the one where I,
> specifically me, must merge or the one where I intend my changes to
> stay separated from other development, (a new "branch").  The
> situation with multiple heads allows the merge, the branch, even the
> decision about whether to merge or branch, to be delayed
> indefinitely.

So, git does actually allow this quite happily - people can publish and
merge whatever they feel like.  What seems to be missing (as far as I
can tell without having used hg) is the ability to associate random
scratch branches from various places with each other and then do things
with that information.  Like I said in another e-mail elsewhere in the
thread this does make sense to me, though it's not a current workflow.

> The fact that it allows for this also allows for a number of
> different repository network architectures, all of which are blocked
> in git because of the push problem.  In git, those decisions must be
> made _before_ the push.

They're only blocked if you don't want to create new branches; idiomatic
git is much more free and easy with that idea so a lot of the time what
people would say is that is to just create topic branches.

> There's also a possibility of nonterminating merges.  That is, if my
> team is making changes faster than you can merge them, then you'll
> never get to push your changes.  With dual heads, you still can.
> And then anyone who wants to can merge them.

Again, this only applies if everyone has to merge onto the same branch
and do it regularly - in normal git workflows this doesn't really occur
as the final merge branch requires some review/approval process and
unmerged work branches are cheap to create and publish.

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

Re: Newbie grief

[Felipe Contreras]

On Thu, May 3, 2012 at 9:13 PM, Rich Pixley <rich.pixley@palm.com> wrote:

> This is probably what I'm going to end up using.
>
> Just for comparison, here's a similar process in hg.
>
> Cache server:
>
>  $ hg clone $uri_for_central_repo

% git clone $uri_for_central_repo

> Machine A:
>
>  $ hg clone $uri_for_cache_repo

% git clone $uri_for_cache_repo

>  $ # ...do some work...
>  $ hg push

% git push

> Machine B:
>
>  $ hg clone $uri_for_cache_repo

% git clone $uri_for_cache_repo

>  $ # ...do some work...
>  $ hg push # assume this collides

% git push

>  pushing to $uri_for_cache_repo
>  searching for changes
>  abort: push creates new remote head 6d2eb0a6a278!
>  (you should pull and merge or use push -f to force)
>  $ hg push -f # the pull and merge case parallels git, so let's use push -f.

This is stupid, why make everybody else's life difficult? Let's merge here.

% git pull
% git push

> Any repo:
>
>  $ hg pull # pulls in all changes including the dual heads

% git pull

>  $ hg merge # collapses the dual heads
>  $ hg commit # commits the merge
>  $ hg push

No need for this, the guy that diverged did this (Machine B).

Plus, what happens if 3 other machines do this? You you have 3 merges,
2 would conflict, and then you would have useless recursive merges, or
some people would have to revert. Why bother N people, when one guy
can do it at the origin (Machine B)?

> Machine A:
>
>  $ hg pull # pulls in all changes so far
>  $ hg up

% git pull

>  $ #... do some work ...
>  $ hg push

% git push

> Machine B
>
>  $ hg pull
>  $ hg up

% git pull

>  $ # ... do some work ...
>  $ hg push

% git push

> Any repo:
>
>  $ hg pull $uri_to_central_repo
>  $ hg merge

% git pull $uri_to_central_repo

>  $ hg push $uri_to_central_repo

% git push $uri_to_central_repo

>  $ hg push # default is cache repo

% git push

> Machine B:
>
>  $ hg pull

% git pull

> Some Conclusions:
>
> * the work flows are similar.
>
> * the hg commands are simpler and have the defaults that we want, primarily
> because no extra branches are required.

Wrong.

> * the hg error messages are straightforward, clear, and don't require any
> deep knowledge of the source code control system or it's limitations.  (I
> still don't understand what the git message on collision is saying.)

Whatever. I don't care what the error message for a merge conflict
actually says, all I need to know is that there was a conflict.

> * hg has more options about how to handle the collisions or the merges.
>  While git can mimic some of those options, doing so requires a priori
> knowledge that isn't stored in the source code control system and therefor
> requires a human exchange which is optional with hg.

WTF? git handles collisions just fine.

Actually the git version has less commands. And if configured properly
you don't need to specify URLs.

Cheers.

-- 
Felipe Contreras

Re: Newbie grief

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Thu, May 3, 2012 at 9:13 PM, Rich Pixley <rich.pixley@palm.com> wrote:
> ...
>>  $ # ...do some work...
>>  $ hg push # assume this collides
>
> % git push
>
>>  pushing to $uri_for_cache_repo
>>  searching for changes
>>  abort: push creates new remote head 6d2eb0a6a278!
>>  (you should pull and merge or use push -f to force)
>>  $ hg push -f # the pull and merge case parallels git, so let's use push -f.
>
> This is stupid, why make everybody else's life difficult? Let's merge here.

Doing "hg push -f" _regularly_ is probably stupid, but you need to step
back a bit.  There is a valid situation where you may sometimes want to
publish unmerged work for others to see.

The person who is trying to push here may be quite junior, and may not be
yet familiar with the areas of the project outside what he has worked on.
In his attempt to "pull and then push", he can end up having to resolve a
merge conflict that he is not capable of handling correctly. Regardless of
the VCS used, you would want to give a way to this junior developer to ask
for help "here is my work; while I was working on it, the baseline has
been diverged greatly and I need help either merging it or rebasing it."

In that context, I can see that Hg's split head could be _one_ way to
implement it.  You just push and force split the head at the remote,
leaving others to sort out the resulting mess.

But that is not necessarily the _only_ way to implement it.  A Git user
would probably push his work to either his own public repository, or in an
environment like Rich illustrated, to refs/remotes/junior/need_help_xyzzy
of the central repository of the organization, and ask other people to
help him.  And when he does so, he needs to tell them where they can find
his work, either the url to his own repository (and its branch), or his
branch at the shared place, and that is where the naming of branch becomes
meaningful.  Instead of saying "There is 6d2eb0a6a278 in the repo that I
need somebody to help merging", the request-for-help message can say "I
placed my WIP on junior/need_help_xyzzy branch; please take a look and
help merging it."

Such a "push -f" to split heads (or pushing to need_help branch and ask
others to do the "pull/push" for him) shouldn't be a norm, and if a
project _relies_ on the ability to do so, there probably is a deeper
problem with the project (e.g. perhaps the codebase is not modularized
enough to allow isolated parallel development by junior people on narrow
subparts of it).

Re: Newbie grief

[Felipe Contreras]

On Fri, May 4, 2012 at 10:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Thu, May 3, 2012 at 9:13 PM, Rich Pixley <rich.pixley@palm.com> wrote:
>> ...
>>>  $ # ...do some work...
>>>  $ hg push # assume this collides
>>
>> % git push
>>
>>>  pushing to $uri_for_cache_repo
>>>  searching for changes
>>>  abort: push creates new remote head 6d2eb0a6a278!
>>>  (you should pull and merge or use push -f to force)
>>>  $ hg push -f # the pull and merge case parallels git, so let's use push -f.
>>
>> This is stupid, why make everybody else's life difficult? Let's merge here.
>
> Doing "hg push -f" _regularly_ is probably stupid, but you need to step
> back a bit.  There is a valid situation where you may sometimes want to
> publish unmerged work for others to see.
>
> The person who is trying to push here may be quite junior, and may not be
> yet familiar with the areas of the project outside what he has worked on.
> In his attempt to "pull and then push", he can end up having to resolve a
> merge conflict that he is not capable of handling correctly. Regardless of
> the VCS used, you would want to give a way to this junior developer to ask
> for help "here is my work; while I was working on it, the baseline has
> been diverged greatly and I need help either merging it or rebasing it."

Sure, but is 'push -f' the right solution? If a junior really has no
idea about what he is doing, I wouldn't want him pushing another
'head' to the master branch. Can mercurial really do a rebase only on
a specific head of a branch? Even if mercurial can do that, the result
can be quite messy; one guy doing a rebase, another guy doing a merge,
another guy doing a different merge, another a different rebase; if
they know what they are doing, they will avoid 'push -f' and revert or
rebase their changes when they notice somebody else tried to do
something similar, but maybe one of them is a slightly more advanced
junior and actually does 'push -f', and we go into yet another round
of conflict resolving.

It doesn't matter how you look at it; 'push -f' is not ideal.

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

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.

Cheers.

-- 
Felipe Contreras

Re: Newbie grief

[Rich Pixley]

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 that is available in other source code 
control systems, (not just mercurial), but not in git.  It's a bit of a 
culture shock to discover that it's not available in git.

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

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

The usual way to deal with this in the git world is to use geographical 
branches and triangles everywhere, but using "merge 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 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.

--rich

Re: Newbie grief

[Felipe Contreras]

On Fri, May 4, 2012 at 11:29 PM, Rich Pixley <rich.pixley@palm.com> 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
mercurial.

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