7 ms·

I understand that it's not worth the cost to cleanup the history, but it's always frustrating to see such a project come with a 100kloc "initial" commit.

• crazygringo 13y ago
  Interesting. Why? What would be valuable about the commit history for you?
  • kingkilr 13y ago
    The same things that are valuable about any commit history?
    • meowface 13y ago
      I would imagine that if you're a random person only just finding the project now and aren't already involved in it (by working for or with Stack Exchange), then you probably wouldn't get all that much value out of the commit history. Feel free to dispute that, though. There may be some scenarios I'm not considering.
      • tedunangst 13y ago
        if (x < 42 && y > 1776) useConfabulator = false; Why? Who knows? People don't comment their code for many reasons, not least of which is that it's not technically required and you can easily put it off and forget. Every checkin generally requires at least some comment. You can still enter meaningless messages like "fix", but you're not liable to do so by accident.
  • emillon 13y ago
    I think that the commit history says a lot about the development process and the company culture. First, is that it's interesting to see how these companies work internally. Second, it's easier to dive into the code by reading the latest commits. You can see what's going on and what pieces are changed together. Finally, there is a substantial difference between: - a repository that's handled as a first class "source code ledger" (pick one or several of: proper branching/merging, atomic commits, issues referenced in commit messages, etc). - a repository full of "git commit -a -m 'ill fix this bug later, TGIF'" whose history makes no sense. I don't want to open the debate on which one is preferable or not (most people agree that git bisect is handy, but it is open to debate whether it's worth the cost). What I'm wondering is how it looked and why it was rewritten. The most probable reason is that they wanted to make sure that nothing sensitive was exposed (non-redistributable embedded dependencies, information on their infrastructure, ...). But it's also possible that this was started as a type-2 repository and they don't want to expose this image. I tend to think that every code should be written (and developed) as it was open sourced one day, but as always there's a cost trade-off in here. Anyway, thanks for open sourcing this piece of software!
    • Nick-Craver 13y ago
      Guy who wrote it here...the only reason this isn't public is security, at a few points there were various passwords in the repository. Also, the internal repository is Hg (still is, though this may change). I still want to dogfood major changes before breaking others. We could convert this history, sure...but the security reason remains. There were many commits that don't make a lot of sense to anyone but me probably, since they were so massive in scale...especially leading up to this release. For example, moving the configuration from web.config-ish xml style to JSON in preparation for a larger system I wanted to have done before open sourcing it to not hose adopters later. That being said, most commits are decent size features or several every day or two. This was completely a side-project for me, happening while waiting on something or in the evening. Going forward, we're shifting focus to monitoring and will be giving some real dedicated time to it. We will be building our own monitoring system as a whole, polling, push, agents, etc...and Opserver is a large part of that big picture. Those commits will be much more interesting, and you're going to see them all. If there are any questions though, I'm happy to answer them...we're pretty wide open, just short of sharing logins and passwords.
      • emillon 13y ago
        Thanks!
• mjibson 13y ago
  Please consider that this project started internal only, so there may be sensitive information in the full history.