On Wed, 20 Sep 2006, Petr Baudis wrote: > > This is really a wrong way of describing the problem - I'd say that Git > is being difficult here. I'm sorry, but no. Git has been designed from the ground up for safety and security. Performance was one big issue, but at every turn, _integrity_ of the archive has always been a much more important one. I realize that a lot of people don't think "integrity" matters. I'm sorry, but those people are simply wrong. In an SCM, "integrity" is the _only_ thing that matters. Everything else is just fluff. > The point is, the subsystem maintainers need to maintain stacks of > patches and rebase against the main kernel branch regularily, and they > want to still publish their current state. And git supports that. > So it's not really any of them being strange or difficult, but Git being > so because it has no seamless support for tracking those branches. It _does_ have seamless support for tracking those branches, but git had DAMN WELL BETTER MAKE SURE THAT NO INFORMATION GETS LOST! That's the one and _only_ thing a SCM had better always guarantee. The fact that very few systems guarantee it, and that you can mess around any which way you damn well want in most other systems, without the user being any wiser is a BUG in those systems. The fact that you can edit (and/or move around) the raw CVS files after-the-fact, and nobody will ever know is _bad_. That other systems allow it even today is just a disgrace. We may have some bugs in git, but modulo those, I hope the design is actually very reliable. If you pull from some other repository, you're guaranteed that you won't suddenly have lost your old state just because the other end had a mistake. People had better understand that git does support rebasing, but also understand that THAT DESTROYS HISTORY. If you don't understand that, then you shouldn't be told about it. Which is exactly what git does. The thing is, if you don't understand how rebasing etc destroys history, you may do things like do a "git pull" or a "git merge" of a branch that the other side WILL THROW AWAY! That will later result in major pain, because when you then try to merge it later, you will get all kinds of nasty behaviour, because the history you merged earlier no longer matches the history you're now trying to merge again, and the work you merged earlier is simply not there any more. See? A "git rebase" has _major_ implications for the receiving end. If git just silently rebased on the receiving end too, THAT WOULD BE A BUG! Once you understand this, and you understand what it _means_, you can then add a "+" in your local .git/remotes/xyzzy file. But git should sure as hell not allow it by default. You may think git is being difficult, but the fact is, git is protecting your data integrity, and protecting your sanity. And if you don't understand that, then git _should_ refuse to update a branch that you may have depended on the old contents for, and inform you that something strange has happened. All of git depends on history being append-only. The fact that you -can- rebase does not change that. A rebase is really "create a totally new branch, delete the old one, and call the new one the same name as you did the old one". So it's really no different from you renaming an unrelated branch to a name that you already used earlier. The recipient really _should_ be told that the old branch is gone, and replaced with something totally unrelated. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html