Krazy Glew's Blog

Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Thursday, June 21, 2012

how-can-mercurial-or-any-other-dvcs-recognize-partially-overlapped-histories

http://stackoverflow.com/questions/11146096/how-can-mercurial-or-any-other-dvcs-recognize-partially-overlapped-histories

Q: is there any way in Mercurial to usefully merge two repositories
whrrer the lines of history are similar, but not identical?

E.g. where one rep has coarse grain revisions 0,1,2
and the other has fine graun revisions 0, 0.1, 0.2, 1, 1.1, 1.2, 2,
and come up with a single history?

Rather than a mess of branches and heads, which is what I get when I try using what I know of Mercurial?

Or the even fancier
Repo1: 0, 1, 1.1, 1.2, 2
Repo 2: 0, 0.1, 0.2, 1, 2, 3

Merge: 0, 0.1, 0.2, 1, 1.1, 1.2 2, 3

In more detail:

What I want is a merge that can recognize when file contents are the same,
or which can recognize that two lines of history are similar, although not all versions in one line
are in the other,
and give something like:

o=o changesets with same file contents on different historical lines
o | (line1)
| | changeset: 2:2a02e67e7b5d
| | user: Andy Glew
| | date: Thu Jun 21 12:40:15 2012 -0700
| | summary: 2
| o (line2)
| | changeset: 8:089179dde80a
| | user: Andy Glew
| | date: Thu Jun 21 12:40:15 2012 -0700
| | summary: 2
| |
| o changeset: 7:615416921e33
| | user: Andy Glew
| | date: Thu Jun 21 12:40:14 2012 -0700
| | summary: 1.2
| |
| o changeset: 6:a43a88065141
| | user: Andy Glew
| | date: Thu Jun 21 12:40:14 2012 -0700
| | summary: 1.1
| |
| |
o=o changesets with same file contents on different historical lines
o | (line1)
| | changeset: 1:93cbae111269
| | user: Andy Glew
| | date: Thu Jun 21 12:40:13 2012 -0700
| | summary: 1
| o (line2)
| | changeset: 5:fef4050e0162
| | user: Andy Glew
| | date: Thu Jun 21 12:40:12 2012 -0700
| | summary: 1
| |
| o changeset: 4:b51fbedc72e5
| | user: Andy Glew
| | date: Thu Jun 21 12:40:12 2012 -0700
| | summary: 0.2
| |
| o changeset: 3:45b7f64b2a23
| | parent: 0:c80bc10826be
| | user: Andy Glew
| | date: Thu Jun 21 12:40:12 2012 -0700
| | summary: 0.1
| |
| |
|/
|
o changeset: 0:c80bc10826be
user: Andy Glew
date: Thu Jun 21 12:40:11 2012 -0700
summary: 0

I can imagine that possibly a merge changeset would be necessary at the o=o points.

But I would like to have it recognized automatically.

Here's an example of how such a history would be created.
Contrived in this example, but something siomilar is happening to me in real-life,
when a project wants coarse grain commits, but where I want to preserve the fine grain ciommits
(as well as the coarse grain stuff released to the project).

[glew@mipscs587 ~/hack/hg-granularity] 900$ bash 12:39:54>. ./eg

% set verbose

% mkdir hg-repo
% cd hg-repo
% ./hg-repo
% hg init
% echo 0 > a
% hg add a
% hg ci -m0 a

% cd ..
% hg clone hg-repo fine
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
% hg clone hg-repo coarse
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

% cd fine
./fine
% echo 0.1 > a; hg ci -m0.1
% echo 0.2 > a; hg ci -m0.2
% echo 1 > a; hg ci -m1
% cat a
1
% hg push default
pushing to /home/glew/hack/hg-granularity/hg-repo
searching for changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 3 changes to 1 files
% hg glog
@ changeset: 3:fef4050e0162
| tag: tip
| user: Andy Glew
| date: Thu Jun 21 12:40:12 2012 -0700
| summary: 1
|
o changeset: 2:b51fbedc72e5
| user: Andy Glew
| date: Thu Jun 21 12:40:12 2012 -0700
| summary: 0.2
|
o changeset: 1:45b7f64b2a23
| user: Andy Glew
| date: Thu Jun 21 12:40:12 2012 -0700
| summary: 0.1
|
o changeset: 0:c80bc10826be
user: Andy Glew
date: Thu Jun 21 12:40:11 2012 -0700
summary: 0

% cd ../coarse
% cp ../fine/a .
% cat a
1
% hg ci -m1
% hg glog
@ changeset: 1:93cbae111269
| tag: tip
| user: Andy Glew
| date: Thu Jun 21 12:40:13 2012 -0700
| summary: 1
|
o changeset: 0:c80bc10826be
user: Andy Glew
date: Thu Jun 21 12:40:11 2012 -0700
summary: 0

% cd ../fine
% echo 1.1 > a; hg ci -m1.1
% echo 1.2 > a; hg ci -m1.2
% echo 2 > a; hg ci -m2
% cat a
2
% hg push default
pushing to /home/glew/hack/hg-granularity/hg-repo
searching for changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 3 changes to 1 files
% hg glog
@ changeset: 6:089179dde80a
| tag: tip
| user: Andy Glew
| date: Thu Jun 21 12:40:15 2012 -0700
| summary: 2
|
o changeset: 5:615416921e33
| user: Andy Glew
| date: Thu Jun 21 12:40:14 2012 -0700
| summary: 1.2
|
o changeset: 4:a43a88065141
| user: Andy Glew
| date: Thu Jun 21 12:40:14 2012 -0700
| summary: 1.1
|
o changeset: 3:fef4050e0162
| user: Andy Glew
| date: Thu Jun 21 12:40:12 2012 -0700
| summary: 1
|
o changeset: 2:b51fbedc72e5
| user: Andy Glew
| date: Thu Jun 21 12:40:12 2012 -0700
| summary: 0.2
|
o changeset: 1:45b7f64b2a23
| user: Andy Glew
| date: Thu Jun 21 12:40:12 2012 -0700
| summary: 0.1
|
o changeset: 0:c80bc10826be
user: Andy Glew
date: Thu Jun 21 12:40:11 2012 -0700
summary: 0

% cd ../coarse
% cp ../fine/a .
% cat a
2
% hg ci -m2
% hg glog
@ changeset: 2:2a02e67e7b5d
| tag: tip
| user: Andy Glew
| date: Thu Jun 21 12:40:15 2012 -0700
| summary: 2
|
o changeset: 1:93cbae111269
| user: Andy Glew
| date: Thu Jun 21 12:40:13 2012 -0700
| summary: 1
|
o changeset: 0:c80bc10826be
user: Andy Glew
date: Thu Jun 21 12:40:11 2012 -0700
summary: 0

OK, so now I have a fine grain history in the fine repo,
and a coarse grain history in the coarse repo. I wouldf like to merge them.
(Firget that the coarse is a subset of the fine: I can easily contrive exanples where they are not).

Simply pushing the coarse graon history gives a warning.
I will opush it later,
but first I will try merging in a separate clone.

% hg push default
pushing to /home/glew/hack/hg-granularity/hg-repo
searching for changes
abort: push creates new remote head 2a02e67e7b5d!
(you should pull and merge or use push -f to force)

% cd ..

% hg clone coarse merge-fine-and-coarse
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
% cd merge-fine-and-coarse/
./merge-fine-and-coarse/

% hg glog
@ changeset: 2:2a02e67e7b5d
| tag: tip
| user: Andy Glew
| date: Thu Jun 21 12:40:15 2012 -0700
| summary: 2
|
o changeset: 1:93cbae111269
| user: Andy Glew
| date: Thu Jun 21 12:40:13 2012 -0700
| summary: 1
|
o changeset: 0:c80bc10826be
user: Andy Glew
date: Thu Jun 21 12:40:11 2012 -0700
summary: 0

% hg pull ../hg-repo
pulling from ../hg-repo
searching for changes
adding changesets
adding manifests
adding file changes
added 6 changesets with 6 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)

% hg heads
changeset: 8:089179dde80a
tag: tip
user: Andy Glew
date: Thu Jun 21 12:40:15 2012 -0700
summary: 2

changeset: 2:2a02e67e7b5d
user: Andy Glew
date: Thu Jun 21 12:40:15 2012 -0700
summary: 2

Here is the merge.

Notice that the pairs
o changeset: 8:089179dde80a
| @ changeset: 2:2a02e67e7b5d
and
o changeset: 5:fef4050e0162
| o changeset: 1:93cbae111269
have the same file contents,
one from the coartse and the other from the fine repo.
But the Mercurial history graph does not reflect this.

% hg glog
o changeset: 8:089179dde80a
| tag: tip
| user: Andy Glew
| date: Thu Jun 21 12:40:15 2012 -0700
| summary: 2
|
o changeset: 7:615416921e33
| user: Andy Glew
| date: Thu Jun 21 12:40:14 2012 -0700
| summary: 1.2
|
o changeset: 6:a43a88065141
| user: Andy Glew
| date: Thu Jun 21 12:40:14 2012 -0700
| summary: 1.1
|
o changeset: 5:fef4050e0162
| user: Andy Glew
| date: Thu Jun 21 12:40:12 2012 -0700
| summary: 1
|
o changeset: 4:b51fbedc72e5
| user: Andy Glew
| date: Thu Jun 21 12:40:12 2012 -0700
| summary: 0.2
|
o changeset: 3:45b7f64b2a23
| parent: 0:c80bc10826be
| user: Andy Glew
| date: Thu Jun 21 12:40:12 2012 -0700
| summary: 0.1
|
| @ changeset: 2:2a02e67e7b5d
| | user: Andy Glew
| | date: Thu Jun 21 12:40:15 2012 -0700
| | summary: 2
| |
| o changeset: 1:93cbae111269
|/ user: Andy Glew
| date: Thu Jun 21 12:40:13 2012 -0700
| summary: 1
|
o changeset: 0:c80bc10826be
user: Andy Glew
date: Thu Jun 21 12:40:11 2012 -0700
summary: 0

% hg diff -r 2a02e67e7b5d -r 089179dde80a

So I'll try a merge

% hg merge -r 8
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

% hg ci -m'merge of fine and coarse at 2'

Better -
this shows that
o changeset: 8:089179dde80a
| @ changeset: 2:2a02e67e7b5d
are a convergence point,
although an extra dummy changesrt was necessary.

But it does not show the commonality between
o changeset: 5:fef4050e0162
| o changeset: 1:93cbae111269

Here's the merged graph

% hg glog
@ changeset: 9:328db8187d31
|\ tag: tip
| | parent: 2:2a02e67e7b5d
| | parent: 8:089179dde80a
| | user: Andy Glew
| | date: Thu Jun 21 12:43:51 2012 -0700
| | summary: merge of fine and coarse at 2
| |
| o changeset: 8:089179dde80a
| | user: Andy Glew
| | date: Thu Jun 21 12:40:15 2012 -0700
| | summary: 2
| |
| o changeset: 7:615416921e33
| | user: Andy Glew
| | date: Thu Jun 21 12:40:14 2012 -0700
| | summary: 1.2
| |
| o changeset: 6:a43a88065141
| | user: Andy Glew
| | date: Thu Jun 21 12:40:14 2012 -0700
| | summary: 1.1
| |
| o changeset: 5:fef4050e0162
| | user: Andy Glew
| | date: Thu Jun 21 12:40:12 2012 -0700
| | summary: 1
| |
| o changeset: 4:b51fbedc72e5
| | user: Andy Glew
| | date: Thu Jun 21 12:40:12 2012 -0700
| | summary: 0.2
| |
| o changeset: 3:45b7f64b2a23
| | parent: 0:c80bc10826be
| | user: Andy Glew
| | date: Thu Jun 21 12:40:12 2012 -0700
| | summary: 0.1
| |
o | changeset: 2:2a02e67e7b5d
| | user: Andy Glew
| | date: Thu Jun 21 12:40:15 2012 -0700
| | summary: 2
| |
o | changeset: 1:93cbae111269
|/ user: Andy Glew
| date: Thu Jun 21 12:40:13 2012 -0700
| summary: 1
|
o changeset: 0:c80bc10826be
user: Andy Glew
date: Thu Jun 21 12:40:11 2012 -0700
summary: 0

How about another merge?

% hg update -r 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

% hg merge -r 5
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

% hg ci -m'merge of fine and coarse at 1'
created new head

% hg glog
@ changeset: 10:cca7fec90d3f
|\ tag: tip
| | parent: 1:93cbae111269
| | parent: 5:fef4050e0162
| | user: Andy Glew
| | date: Thu Jun 21 12:45:03 2012 -0700
| | summary: merge of fine and coarse at 1
| |
| | o changeset: 9:328db8187d31
| | |\ parent: 2:2a02e67e7b5d
| | | | parent: 8:089179dde80a
| | | | user: Andy Glew
| | | | date: Thu Jun 21 12:43:51 2012 -0700
| | | | summary: merge of fine and coarse at 2
| | | |
| | | o changeset: 8:089179dde80a
| | | | user: Andy Glew
| | | | date: Thu Jun 21 12:40:15 2012 -0700
| | | | summary: 2
| | | |
| | | o changeset: 7:615416921e33
| | | | user: Andy Glew
| | | | date: Thu Jun 21 12:40:14 2012 -0700
| | | | summary: 1.2
| | | |
| +---o changeset: 6:a43a88065141
| | | user: Andy Glew
| | | date: Thu Jun 21 12:40:14 2012 -0700
| | | summary: 1.1
| | |
| o | changeset: 5:fef4050e0162
| | | user: Andy Glew
| | | date: Thu Jun 21 12:40:12 2012 -0700
| | | summary: 1
| | |
| o | changeset: 4:b51fbedc72e5
| | | user: Andy Glew
| | | date: Thu Jun 21 12:40:12 2012 -0700
| | | summary: 0.2
| | |
| o | changeset: 3:45b7f64b2a23
| | | parent: 0:c80bc10826be
| | | user: Andy Glew
| | | date: Thu Jun 21 12:40:12 2012 -0700
| | | summary: 0.1
| | |
+---o changeset: 2:2a02e67e7b5d
| | user: Andy Glew
| | date: Thu Jun 21 12:40:15 2012 -0700
| | summary: 2
| |
o | changeset: 1:93cbae111269
|/ user: Andy Glew
| date: Thu Jun 21 12:40:13 2012 -0700
| summary: 1
|
o changeset: 0:c80bc10826be
user: Andy Glew
date: Thu Jun 21 12:40:11 2012 -0700
summary: 0

This is not right. It has established a new head, whereas
what we wanted was some way of indicating that
o changeset: 5:fef4050e0162
| o changeset: 1:93cbae111269
are the same.

OK, switch back to the original coarse

% cd ../coarse

% hg push default
pushing to /home/glew/hack/hg-granularity/hg-repo
searching for changes
abort: push creates new remote head 2a02e67e7b5d!
(you should pull and merge or use push -f to force)

% hg push -f default
pushing to /home/glew/hack/hg-granularity/hg-repo
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 1 files (+1 heads)

% hg glog
@ changeset: 2:2a02e67e7b5d
| tag: tip
| user: Andy Glew
| date: Thu Jun 21 12:40:15 2012 -0700
| summary: 2
|
o changeset: 1:93cbae111269
| user: Andy Glew
| date: Thu Jun 21 12:40:13 2012 -0700
| summary: 1
|
o changeset: 0:c80bc10826be
user: Andy Glew
date: Thu Jun 21 12:40:11 2012 -0700
summary: 0

% cd ../hg-repo/

% hg glog
o changeset: 8:2a02e67e7b5d
| tag: tip
| user: Andy Glew
| date: Thu Jun 21 12:40:15 2012 -0700
| summary: 2
|
o changeset: 7:93cbae111269
| parent: 0:c80bc10826be
| user: Andy Glew
| date: Thu Jun 21 12:40:13 2012 -0700
| summary: 1
|
| o changeset: 6:089179dde80a
| | user: Andy Glew
| | date: Thu Jun 21 12:40:15 2012 -0700
| | summary: 2
| |
| o changeset: 5:615416921e33
| | user: Andy Glew
| | date: Thu Jun 21 12:40:14 2012 -0700
| | summary: 1.2
| |
| o changeset: 4:a43a88065141
| | user: Andy Glew
| | date: Thu Jun 21 12:40:14 2012 -0700
| | summary: 1.1
| |
| o changeset: 3:fef4050e0162
| | user: Andy Glew
| | date: Thu Jun 21 12:40:12 2012 -0700
| | summary: 1
| |
| o changeset: 2:b51fbedc72e5
| | user: Andy Glew
| | date: Thu Jun 21 12:40:12 2012 -0700
| | summary: 0.2
| |
| o changeset: 1:45b7f64b2a23
|/ user: Andy Glew
| date: Thu Jun 21 12:40:12 2012 -0700
| summary: 0.1
|
@ changeset: 0:c80bc10826be
user: Andy Glew
date: Thu Jun 21 12:40:11 2012 -0700
summary: 0

% echo This is not right
This is not right

What I want is a merge that can recognize when file contents are the same,
or which can recognize that two lines of history are similar, although not all versions in one line
are in the other,
and give something like:

o=o changesets with same file contents on different historical lines
o | (line1)
| | changeset: 2:2a02e67e7b5d
| | user: Andy Glew
| | date: Thu Jun 21 12:40:15 2012 -0700
| | summary: 2
| o (line2)
| | changeset: 8:089179dde80a
| | user: Andy Glew
| | date: Thu Jun 21 12:40:15 2012 -0700
| | summary: 2
| |
| o changeset: 7:615416921e33
| | user: Andy Glew
| | date: Thu Jun 21 12:40:14 2012 -0700
| | summary: 1.2
| |
| o changeset: 6:a43a88065141
| | user: Andy Glew
| | date: Thu Jun 21 12:40:14 2012 -0700
| | summary: 1.1
| |
| |
o=o changesets with same file contents on different historical lines
o | (line1)
| | changeset: 1:93cbae111269
| | user: Andy Glew
| | date: Thu Jun 21 12:40:13 2012 -0700
| | summary: 1
| o (line2)
| | changeset: 5:fef4050e0162
| | user: Andy Glew
| | date: Thu Jun 21 12:40:12 2012 -0700
| | summary: 1
| |
| o changeset: 4:b51fbedc72e5
| | user: Andy Glew
| | date: Thu Jun 21 12:40:12 2012 -0700
| | summary: 0.2
| |
| o changeset: 3:45b7f64b2a23
| | parent: 0:c80bc10826be
| | user: Andy Glew
| | date: Thu Jun 21 12:40:12 2012 -0700
| | summary: 0.1
| |
| |
|/
|
o changeset: 0:c80bc10826be
user: Andy Glew
date: Thu Jun 21 12:40:11 2012 -0700
summary: 0

I can imagine that possibly a merge changeset would be necessary at the o=o points.

But I would like to have it recognized automatically.

Heck, forget "recognized". I would like to have a way that I can recognize it manually, but have it represented in Mercurial.

Wednesday, June 20, 2012

Knobs should be left to right - why (some) getopts are broken

There are two main styles of command line argument or options parsers - which my subculture calls "knobs".

My preference is to parse strictly left to right.

Another common approach is to partse all the knobs, possibly out of order. Often the last value written for a knob overrides all previous values.

This can cause problems - hence my preference for left to right. Here's an example:

Imagine that you have a "big" knob, -big A or -big B, that has a big effect - e.g. swapping in a table of multiple settings.

And imagine that you have a small knob, -small x or -small y, that changesd a subsetting.

E.g.
command -big A => table[0] = A0, table[1] = A1, table[2] = A2...

command -big B => table[0] = B0, table[1] = B1, table[2] = B2...

command -big A -big B
=> the later B overrides the earlier A
=> table[0] = B0, table[1] = B1, table[2]=B2...

so far so good.

But imagine that -small changes only one entry.

command -big A -small x => table[0] = A0, table[1] = x, table[2] = A2...

command -big B -small y => table[0] = B0, table[1] = y, table[2] = B2...

Later -small may override earlier -small

command -big A -small x -small y => table[0] = A0, table[1] = y, table[2] = A2...

But... should a later -big override an earlier -small? I think so:

command -big A -small x -big B
=> My preference
=> table[0] = B0, table[1] = B1, table[2] = B2...

But many getopts parsers instead do:

command -big A -small x -big B
=> if -small is processed after -big
=> table[0] = B0, table[1] = x, table[2] = B2...

or, worse, have -big override even earlier -smalls.

List valued knobs don't help much here. Short-sight. Although I admit that I have occasionally use list valued knobs as a kluge when dealing with a non left to right argumernt parser.

---

Some knobs have side effects. Some even create other knobs. There needs to be a defined order of evaluation. Left to right is as goos as any.

---

The problem with left to right is that it tends to imply that you are building a data structure as you parse the knobs. Which sometimes means that a later knob may cause you to want to destroy a datastructure that was being built.

Tuesday, June 19, 2012

Monolithics and Makefiles

I think that one of the reasons why some people write big monolithic programs with too many classes and functions and just plain stuff in the same headers and .c/.cpp files is that they do not have goopd dynamic Make tools. They get the Makefile working, and then don't touch it, since touching it would require editing by hand.

Multihomed workspaces and repos

I often find myself wanting a "multihiomed" workspace or repo:

E.g. a workspace where I push to one or more places regularly.

E.g. I may push to my personal backup or tracking repo.
But occasionally I need to push to a project master.

This becomes complicated when a meta-project is composed of several subrepos - e.g. the main project source, but also source for libraries and tools. Then I want to push the whiole meta-project to the meta-project-repo, the main project (which is a subrepo of the meta-project) to the main project master repo, and the tools and libraries sometimes to the meta-project-repo, and sometimes to their respective master repos.

I can do this by hand, if I remember the names.

But I want to create nice default behavior. Like "push to my backup or m,eta-repo".
And "release all of my changes to rtheir respective providers".

Of course, the respective providers may themselves have flows.

--

I don't see a standard way in hg.

This is partly why I create the CVS.1 CVS.2 ... dirs, long ago.

For now, I am manually recording the multiple homes in files such as meta-repo/subrepo/hg-paths.

Trouyble is, I may not be allowed to asdd stuff like that to meta-repo/subrepo, since that tree belongs to thwe provider.

So I have had to add the metadata about multihoming elsewhere, e.g.
meta-repo/subrepo/hg-paths--for--subrepo.
(I would call it meta-repo/subrepo/hg-paths:subrepo), except I am warned about Windows not liking colons.

Minor BKM: -comment_knob

I find it convenient to give certain programs a command line option that is just a placeholder, which ignoeres its string argument. Just to hold comments.

Especially useful in a test, so you can say

command -comment_knob 'expect failure' -illegal-option ...

Monday, June 18, 2012

Else: what's the difference?

What's the difference

between cascaded IFs

if( cond1 ) {
...
} elsif( cond2 ) {
...
} else {
...
}

and a nested IF in the ELSE part:

if( cond1 ) {
} else {
if( cond2 ) {
...
} else {
...
}
}

?

Not much - except for intent. The latter calls out the ELSE part, the IF cond2 part, emphasizing its separateness. The latter pivots easily to a nested IF in the THEN part. The cascaded IF probably needs to be transformed to the nested IF on the WELSE part, and then pivoted.

Note that the cascaded IF is often used to express a concurrent IF:

if cond1 => ...
:: cond2 => ...
else ...
fi

where the difference is meaningful: in the concurrent IF all of the condityions, cond1 and cond2, are evaluated. Indeed, some argue that there should be no ELSE clause for a concurrent IF.

--

I wonder if there could be some useful difference made between cascaded IF and nested IF in the ELSE part.

Disabling default-push in Mercurial

(I may have already posted this, but cannot find it at this time.)

On a few occasions I have embarrassed myself by pushing to the project master repository accidentally, when I meant to push to my rep where I keep all of my history. (My project requires me to collapse fine grain commits to a much smaller number of coarse gran commits, losing history but keeping the log small. I keep meaning to try mq for this.)

Some folks on stackoverflow *almost* describe how to do this.

Although the post has a bug, which I have fixed. I would post the fix to stackoverflow, except it is down right now, far enough that I am not sure that the below is the correct URL

http://stackoverflow.com/can-you-prevent-default-push-but-allow-pull

Here is the my current BKM to disable default-push:

I've embellished the idea of setting paths.default-push in ~/.hgrc, making it a little bit more self documenting and less error-prone - since, as I point out below, setting default-push = . does not always disable pushing.

in ~/.hgrc

[paths]

# my main project master repo

project-master = ...

#DISABLING IMPLICIT PUSH

# to prevent embarassment from accidentally pushing to the project master repo

# instead of, in my case, a repo that has fine grain commits

# that the rest of the team does not want to see in the project master repo

#default-push = .

# this works mostly, but NOT if you use hg on your home directory

# since '.' in ~/.hgrc seems to be interpreted as -R ~

#default-push = /NONEXISTENT_default-push_--_must_specify_push_target_explicity

# this works ok, but I can clean up the error message using blanks

# keeping this around because blanks in pathnames cionfuse many tools

default-push = /'NONEXISTENT default-push -- must specify push target explicitly'

# this amounts to disabling implicit push targets.

Krazy Glew's Blog

Disclaimer

Thursday, June 21, 2012

how-can-mercurial-or-any-other-dvcs-recognize-partially-overlapped-histories

Wednesday, June 20, 2012

Knobs should be left to right - why (some) getopts are broken

Tuesday, June 19, 2012

Monolithics and Makefiles

Multihomed workspaces and repos

Minor BKM: -comment_knob

Monday, June 18, 2012

Else: what's the difference?

Disabling default-push in Mercurial

Blog Archive

Labels

Search This Blog

Followers

About Me

Links to Me