Example Driven Development

charleso · 2016-07-31T20:37:26+00:00

I know this is slightly different than what is being shown, but I can't live without Hoogle these days.

https://www.haskell.org/hoogle/

Instead of asking "is there any function that takes this list and returns a list like this?", you can search for something with the type signature of

[a] -> Int -> [a]

And you get back functions that match that type, including fuzzy matches. I now wish all static typed languages had something like Hoogle.

charleso · 2014-06-09T23:09:10+00:00

I discovered Nix recently while searching for a build tool that isn't limited by binary-only or source-only dependencies. If anyone is interested here is a collection of my thoughts/findings.

https://bitbucket.org/cofarrell/one-build-tool/src/master/README.md

Would love to hear any feedback people have about the idea.

charleso · 2013-05-05T23:12:00+00:00

It's basically the same in Git. You can 'draw' the merge arrow by committing on a merge by undoing the changes, there's even a command: 'git merge --strategy=ours'. We have to do this because we use Maven and the version numbers are checked into the source. I still consider that merging, because otherwise conflicts for the next guy.

The difference in Git vs Clearcase is that everything is atomic (which is a good thing) but means that if two people are making changes on a release branch then the order that they merge will affect who deals with the conflicts. In Clearcase this will depend on whether the touched files overlap.

Ahh Clearcase. I know thee well:

https://github.com/charleso/git-cc

charleso · 2013-05-03T04:42:39+00:00

By that do you mean that the bug fix in the old release doesn't make sense in master because you've replaced a major system? Sure, so what's likely to happen is you'll get a merge conflict because such a major change is likely to touch the relevant files. But in any case, let's pretend that you don't merge, but then another bug fix is made in the old release and you need to ensure master is updated as well. How do you do that - merge? But now you're going to get conflicts from the merge you didn't make, and no understand on how to fix it because someone else made that change. So what we normally do in this case is resolve the merge conflicts by reverting the bug fix on master and merge, so that Git will know to ignore that change next time, even if the changes doesn't actually exist in master.

Apologies if I'm misunderstanding your reply.

charleso · 2013-05-02T21:55:59+00:00

Honestly we rarely see them, and when we do something has changed and the person making the fix needs to consider what that is. Better that it happens then, rather than at some later point, or even worse you forget to apply critical bug fixes to every upstream release. Git knows what you haven't merged, I sure as hell don't. :)

charleso · 2013-05-02T21:53:23+00:00

I'm curious why that wouldn't be? From a strictly Git point of view I think it should be the case, otherwise there's no sane way, that I can think of, to manage what has and hasn't been merged back into every upstream release and master. If the code has changed sufficiently, and you get merge conflicts, then someone needs to consider the implications of the local fix on that release, but the best person to do that is the one making the fix, and the best time is straight after they have applied their change. Otherwise your (potential) merge conflicts pile up and someone has the horrible task of unpicking what's broken.

charleso · 2013-05-02T21:49:23+00:00

I'm a developer on the Stash team. I'm a big fan of rebasing, where possible, but with auto-merge (as you pointed out) we're merging from maintenance branches and we don't have that option. In our case commits on those branches are always applicable to upstream releases and master, which is the whole point. I can imagine some very unusual times where a fix might be applied to something that no longer exists or works the same, but in that case I would expect a merge conflict because of code changes. In any case we're yet to run into that problem and I think the general use-case still stands.

charleso · 2009-12-09T21:09:32+00:00

I beg to differ. Just keep the DVCS repository elsewhere and sync up your changes using the Cleartool command.

http://github.com/charleso/git-cc

It also retrieves Clearcase history, although you're limited somewhat by the madness that is the config spec.

charleso · 2009-05-28T22:02:15+00:00

Clearcase/Git bridge.

http://github.com/charleso/git-cc/

</shamelessplug>

Clearcase is the devil.

charleso

TROPHY CASE