Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That sounds great.

What about the situation where A and B don't have conflicts (as defined by the VCS), but still don't work. For example, based on a state of a piece of source code, e.g. A renames a method and all usages (works fine), and B introduces new code (but uses the original method name, also works fine). Merging them will not produce conflicts, but will not work.

In Git I always use "--exec 'mvn clean test'" when using "git rebase", to compile the source code (which would find such rename issues) and run unit tests (which would find other issues, e.g. A introduces a new mandatory column in a database table and B introduces an INSERT statement without that column).

What would be really cool is if one could say to Pijul "for any operations on this repository, execute this command to determine if the software is OK". And then forget about it. That way all operations it does it could check, and the user could never forget. I wish Git had something like that.

Or have I misunderstood something? I mean, simply relying on "no conflicts implies everything's fine" is not sufficient as far as I can see?



I would say that is somewhat outside the jurisdiction of the VCS. Sure you can have post-commit or CI hooks that ensure your code always compiles, but it doesn't need deep support from the VCS to do that.

However, the fact the pijul doesn't really treat the "no conflict" state as "special" is in some ways closer to what you want - the repo is just a collection of patches, and whether the result is "good" or "bad" is not determined by the VCS, but by whatever means you choose to employ.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: