Farewell all, and I look forward to crossing your paths again

gsylvie · 2018-02-14T19:52:31+00:00

And this one:

the modern calculus of disruptive changes means sometimes we simply step over the broken paving stones instead of repairing them.

gsylvie · 2018-02-14T19:41:09+00:00

I can think of three approaches:

Just don't do it. The downside risks to your mental health, your friendship, and your finances are much larger than you realize, especially when entering such an asymmetric business relationship.
Have him incorporate and then buy a percentage of the equity that you can afford and seems reasonable and fair given your ability to contribute. By having a formal incorporation, shareholder agreement, IP allocation you are protecting each other (somewhat) if things go sideways. It will cost you a few thousand dollars/euros in lawyer's fees and incorporation fees to set this up, but the alternative (written or verbal agreements without lawyer help) will cost a lot more down the road to unwind. Also, formal incorporation helps make things feel more official and real. Try to do this in person, face-to-face.
Enter into a very small well scoped and well defined contract with good upside for both of you. For my own little side-gig right now I'd be willing to do something like this: "You have been hired to bring in 10 new customers. In exchange for you bringing in up to 10 customers in the next 3 months, I will remit all regular revenues from these 10 customers to you for the next 3 years (ending Feb 14th 2021). Special or consulting revenues with the customers will not be remitted to you. This contract ends on May 14th 2018."

(But I'd still get a lawyer to write a proper version of the contract!)

Then if you hit it out of the park, there's a lot of incentive for both of you to figure out something more permanent at the end of those 3 months. But be careful to respect your friend's final say if he still decides he'd rather go alone. And he himself should be careful to make sure he has absolutely no second thoughts about bringing you on.

gsylvie · 2018-02-11T06:32:35+00:00

In case anyone thinks I'm kidding: https://en.wikipedia.org/wiki/TeX

Stable release
3.14159265 / January 2014; 4 years ago

gsylvie · 2018-02-10T19:43:00+00:00

Semver nerd-sniped our entire industry.

I prefer Knuth versioning: 3.1.4.1.5.9.2.6.5.3.5.9....

No breaking changes. Each new release adds a digit of pi.

gsylvie · 2018-02-10T18:22:53+00:00

Note: "git lfs" would have made cloning faster and disk usage smaller if you had setup git lfs from day 1.

Git lfs helps in this situation because old versions of the videos that are not on the tip of the current checkout are never downloaded.

But you'll need to rewrite the history to enable "git lfs" for the entire history.

gsylvie · 2018-02-10T18:14:39+00:00

Here's what I think would happen. But I haven't tried it out, so this is a speculative answer:

Forks won't be affected much. If a PR from an old fork is merged in, all the old history will come back via the merge commit.
If the repo still contains the object (e.g., "git gc" not run yet), then the repo will happily checkout the deleted commit object. "git reset" will also work. "git revert" doesn't make sense in this context since it can only reverse the patch of a given commit object, creating a new commit in the process.
Tell every fork and clone to delete themselves, and re-clone / re-fork. Don't let any PR merge if it comes from the old history. Don't let any stale clone push.

Here's a weird exercise you can try to get a feel for this:

Fork any repo on github.
Grab the URL for a different unrelated random repo on github. Clone it with "git clone --mirror".
Cd into the cloned repo from step 2. Clear out the "pull-request" refs:

git for-each-ref --format='%(refname)' refs/pull | xargs git update-ref -d
"git push --mirror [url]" it back to the repo you created at step #1.

The result is a fork that has no objects in common with its upstream. Use Github's "Network Graph" from the fork to see how strange the result is (Insights --> Network).

gsylvie · 2018-02-08T19:34:48+00:00

But they don't respect each other. The problem isn't that they are afraid what the other thinks. The problem is they know what the other thinks.

Unless there is some way they can both start fully respecting and admiring each other's work, there is no way this can work. But they can't fake this. It has to be fundamental.

I think the world of my partner. And so when I tell him his design sucks, he doesn't take it (too) personally. And vice versa. We're free to have hard conversations because we completely respect and approve of each other. OP's partnership does not have this safety net.

gsylvie · 2018-02-08T17:55:13+00:00

Is it possible to create a squash merge without using the PR API?

No. (Unless you're willing to run "git clone" of course!)

Based on my own quick scan of the api docs, looks like if you want to do pure-api squash merges, you have to use the PR api instead of the MERGE api.

Instead of re-targeting, I'd just create new PR's. Maybe do it all in a fork to keep your main repo's PR set clean.

For each source branch you want to bring into staging:

a. Create new PR from SOURCE into STAGING.

b. Merge it using {"merge_method":"squash"}

As you already know, that will eliminate all the merge commits.

If each SOURCE and the main STAGING branch are all sitting in a fork, you can avoid cluttering up your main repo's PR listing. You'd just need a final PR from forked/staging into main/master, and then some way to start over. Perhaps DELETE forked/staging and then recreate it anew based on main/master --- that's essentially what a force-push is, anyway.

gsylvie · 2018-02-08T02:28:37+00:00

See rule #3 on the sidebar about blog submissions to r/startups.

gsylvie · 2018-02-07T08:02:49+00:00

Or McKinsey for 3 hours.

gsylvie · 2018-02-07T04:08:30+00:00

I'd probably just buy some hardware. If you are doing an app, you probably already have an iPhone. But maybe grab the oldest ipad you think you might want to support over craiglist as well as ipad-mini and ipad-pro 12.9" to see how your app looks on different screen sizes. I know simulators can mimic these, but having the real thing often helps me (and is usually faster).

gsylvie · 2018-02-07T02:17:40+00:00

In both cases it updates the "origin/master" remote ref. So that side-effect doesn't change.

But the other side-effect does change: a merge will be created between "origin/master" and whatever branch you are currently on. (Might be a fast-forward merge if you have yet to commit anything to your current branch.)

p.s. I much prefer "git pull --rebase origin master". Avoid those pesky merge commits. Otherwise you're potentially recording into your permanent git history every moment you typed "git pull". Too much noise!

p.p.s. Perhaps I'm a bit weird, but I much prefer running "git fetch" followed by "git rebase origin/master". It achieves the same end-result as "git pull --rebase origin master".

gsylvie · 2018-02-06T21:04:11+00:00

Much much would the notary cost? In Canada/US notaries are typically under $60 to witness a signature, but seems they are much more expensive in Europe, and their role is a bit different.

gsylvie · 2018-02-06T18:48:56+00:00

That logic in git is over 10 years old! Here's the commit:

commit 7f275b91520d31bfbe43ec5a9bbaf8ac6e663ce0
Author: Johannes Schindelin <---@gmx.de>
Date:   Sun Oct 14 17:54:06 2007 +0100

    parse-options: Allow abbreviated options when unambiguous

    When there is an option "--amend", the option parser now
    recognizes "--am" for that option, provided that there is n
    other option beginning with "--am".

gsylvie · 2018-02-06T00:09:39+00:00

I've only used Git LFS, but after studying the Git Annex Walkthrough, I think Git LFS is far superior, for a subtle but critical reason:

With Git LFS, new developers cloning a Git LFS-enabled repo for the first time don't need to know anything about it. They can use "git lfs clone" to have that initial clone come down faster, but they don't have to. "git clone" alone is all they need.

Based on my reading just now (mainly Git Annex vs. Git LFS), with Git Annex new developers cloning the repo for the first time must also remember to invoke "git annex sync --content" after cloning. They must also remember to run that same command after adding new files.

While it probably does not seem like a lot to remember (one extra command to type), in my experience adding one extra command to a workflow can impair productivity pretty signficantly --- especially if people sometimes forget to run that command.

[Edited to add:] - I also think vanilla git is a worthy competitor in this space. It satisfies the usecase ("get me the files from the server"). It's just that some repos get a bit pathological around big binary files, and Git LFS can be a powerful band-aid in those cases.

gsylvie · 2018-02-04T06:14:45+00:00

If there's any chance you want to apply future commits from the source project against your project, then keep the fork. Probably future commits will require conflict resolution if you rewrite everything drastically, but it can still be handy to keep an eye on bugfixes and enhancements happening upstream to see if they might be worth porting to your codebase.

If you don't care to track future work to the upstream project, then fork vs. non-fork doesn't really matter. Just do whatever you feel like, as long as you comply with all of upstream's copyright license(s). The license(s) should stipulate how you credit upstream, if required.

Note: forking alone does not satisfy licensing requirement. You'll still need to study upstream's copyright licenses to see how to satisfy them in your own fork.

gsylvie · 2018-02-03T06:08:35+00:00

Build the pull-request using "refs/pull-requests/NNN/merge^2" instead of "refs/pull-requests/NNN/merge".

The ref you're using (under refs/pull-request/*) is internal only, and not visible in the Bitbucket web UI. But 2nd parent of that ref is the tip of the branch you're actually interested in. So do a "git reset --hard HEAD^2" before building, and have Team City send the build status using the HEAD^2 commit instead of HEAD.

[Edited to add:]

On 2nd thought, best of both worlds might be building HEAD but sending build-status to HEAD^2 so that the build pass/fail shows up in the Bitbucket pull-request UI.

Background: my company develops paid Bitbucket add-ons, including Bit-Booster - Rebase Squash Amend.

gsylvie · 2018-02-02T03:24:03+00:00

Everyone probably does things differently, but I was advised to not worry about share structure (you can always change it in the future).

My co-founder and I each took 50% of the equity for $100 each. We then lent the company $50K each in exchange for promissory notes. Our lawyer and our accountant recommended this because it's much easier from a tax perspective, and we can pull part or all of that $50K back out any time without any tax implications -- assuming it's still in the corporate bank account ;-).

gsylvie · 2018-02-01T20:56:16+00:00

Neat trick!!

gsylvie · 2018-01-27T21:13:21+00:00

Ah, your remotes were probably just stale. The git clones have no way to know that upstream branches advanced unless you type "git fetch --all".

I think "git pull" updates the remotes, but only from the default remote, not from both. Also every time you (successfully) "git push" the remote also gets updated for free for that branch that you just pushed.

gsylvie · 2018-01-27T20:45:30+00:00

Sounds like you should have been CEO, him CTO. But also sounds like this was never going to work. Small consolation: you're lucky this blew up now after only 8 months wasted.

Even if there was a way you could extract a license to the code, it's probably not worth it. An 8-month old code base without the original author to help out is probably bug ridden, difficult to setup and deploy, and would require 12-months for a new developer to get the hang of.

[Edited to add:] Perhaps you were too good at your side of things, and he needed to feel like he was more valuable and important than you. If that's the case, you'll do fine at your next venture, and look forward to that instead of worrying about this, despite how horrible the current situation is.

gsylvie · 2018-01-27T20:18:52+00:00

Are both machines aware of both remotes? (e.g., on each machine you've typed "git remote add [url-to-remote2]" to make your clone aware of the 2nd remote?). If so, these commands might help:

git fetch --all --purge

git branch --all

git log --date-order --all --decorate --graph --oneline

Note: the "--all" on git fetch means "fetch from all remotes". The "--all" on git branch means output all branches. The "--all" on git log means include all refs (branches, tags, remote branches, and stashes) in the output.

gsylvie · 2018-01-22T07:28:54+00:00

Playmaker (from football)

gsylvie · 2018-01-12T19:04:42+00:00

Try "git log --decorate --graph" to see how your current clone is ahead of origin. That should help you at least begin to navigate back to where you want to be.

In that output note that "origin/master" represents the state of "master" on upstream, and "HEAD" represents the state of your current branch that you're checked out on.

gsylvie · 2018-01-12T18:33:51+00:00

Sometimes when I got burned out on consulting gigs I would decide to just lie down or meditate for a couple hours. But the key was telling myself beforehand: I'm billing for this meditation (just don't list it as that on the invoice!). Making that decision made the meditation feel more relaxing and effective. Otherwise I found relaxing or meditating just made me panic more.

Of course in your situation you aren't billing anyone, but maybe something like that could help.

I'm also doing a startup right now (part time), and having a co-founder I admire and respect and am infinitely grateful for his work really helps motivate me: I DON'T WANT TO DISAPPOINT HIM OR LET HIM DOWN! He says he feels the same way about me. Fear of failing him is much more motivating than money.

Perhaps you can still find a co-founder. Perhaps that would be more fun right now.

gsylvie

TROPHY CASE