A thing that frustrates me is when I fork a CC0 or MIT project, and then I make a bunch of commits, and then I'm ready to push it to github, and I go to add a license, but then I realize it's already got a license and it's CC0 or MIT, and it's in all these non-modifiable commits
Conversation
Like, with git (or Mercurial, which is what I actually use) you can't change the past, only add to the future. So if I've got 20 commits I never pushed with a CC0 license, and then on commit 21 I add a more restrictive license and push... do the junk commits grant a license?
4
5
Replying to
It's not really non-modifiable. You can use `git rebase -i COMMIT_BEFORE_YOUR_FIRST` and reorder / change / add / squash commits as desired.
1
3
Replying to
That's true! But I'm not using git.
Even in git tho this will sometimes create problems if I've got more than one local checkout/fork of the repo. It is a general problem with dvcs.
1
Replying to
In theory you're not meant to rebase once it's published in a branch / tag but GitHub messes that up by handling pull requests via pushing to your public fork of the repository instead of submitting a patch set to be applied. The way it was intended to be used is different.
1
Most projects don't really have much of a use case for the Linux kernel development style with multiple public trees where people submit their patches and merges to incorporate those into upstream ones.
Gerrit is way better at matching the kind of workflow it was designed to do.
1
Git breaks other clones even without any history rewriting simply from changing the URLs of submodules to point elsewhere such as if they have to be forked. Some of the most irritating software ever.