as_someone

12 anni fadiscuss

> every Java program is infringing

No, for a couple reasons:

1. Those programs aren't distributing the material in question. You, the user, will have independently acquired the JRE. This will have most likely been through non-infringing means, given that Sun/Oracle lets you have it for free, and even if it were infringing, you'd be the one at fault, not the program author.

2. Even if that weren't true, there would still be a couple of options to create a non-infringing program. Only programs that are neither non-GPL, nor those from authors who have some other valid commercial license would be infringing. Not "every Java program".

as_someone

12 anni fadiscuss

Sure, if Google were happy to comply with the GPL. But they're not.

as_someone

12 anni fadiscuss

j2kun means the stuff that shows up from TFA when using git diff:

  diff --git a/octocat.txt b/octocat.txt
  index 7d8d808..e725ef6 100644
  --- a/octocat.txt
  +++ b/octocat.txt
  @@ -1 +1 @@
  -A Tale of Two Octocats
  +[mA Tale of Two Octocats and an Octodog

as_someone

12 anni fadiscuss

> http://www.sbf5.com/~cduan/technical/git/>--which

... aaaaand HN is busted, and won't update the post when I try to edit that to fix the link.

That's http://www.sbf5.com/~cduan/technical/git/ for convenience.

as_someone

12 anni fadiscuss

Use Mercurial.

There's http://hginit.com. Given your comment about "I didn't need a tuturial for Subversion", though, maybe you'll find that inadequate, too. As someone who tried using SVN before ever touching hg or git or its forebears, I found SVN baffling. To me, the DVCSes make sense. HgInit's "Subversion Re-education" page says:

> Mercurial separates the act of committing new code from the act of inflicting it on everybody else.

The fact that this isn't the case in SVN is mystifying to me.

I still struggle with git. In fact, I don't use it, largely because I still don't know how to use it. Note how I said that "the DVCSes make sense". I say that, because I can read "Understanding Git Conceptually" <http://www.sbf5.com/~cduan/technical/git/>--which a number of HN commenters have posted before--and I get it. The problem is not that I don't understand the concepts backing git. It's that I don't understand how these concepts map onto git's infuriatingly obtuse UI.

So use Mercurial. Because,

a) it's better (read: nicer to use), and b) when you use Mercurial, it comes with the benefit that you're helping inoculate the dev world against a DVCS monoculture.

If it helps, know this: I write as someone whose use case is largely the one you outline. I mostly find myself working alone, on a side project of mine where I'm the only committer.

  # Crystallize your changes in a revision marked with your
  # commit comment:
  hg commit

That's it, pretty much. Occasionally you'll need to do an hg addremove to make sure Mercurial isn't ignoring any new files you've introduced (hg add and hg remove if you want to do things manually), and an hg mv whenever you need to move things around.

Everything ramps up pretty sensibly and steadily from there, so that you're really only spending the mindspace to pay for the features you're really using.

For example, if you have a public-facing repo:

  hg push # read as "publish", if it helps.

Do this, occasionally preceded by an hg out (when you find that you want to see what you'll be pushing), and you're good to go.

comments