From: Randal L. Schwartz <hidden> Date: 2016-06-15 22:53:43
quoted
quoted
quoted
quoted
"Rich" == Rich Pixley [off-list ref] 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
[off-list ref] <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
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
From: Mark Brown <hidden> Date: 2016-06-15 22:53:44
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.
On Thu, May 03, 2012 at 01:52:35PM -0700, Rich Pixley wrote:
quoted
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:53:44
Rich Pixley [off-list ref] writes:
On 5/4/12 08:56 , Mark Brown wrote:
quoted
On Thu, May 03, 2012 at 01:52:35PM -0700, Rich Pixley wrote:
quoted
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
From: Mark Brown <hidden> Date: 2016-06-15 22:53:44
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.