On Sat, 15 Aug 2009, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > One more thing. I suspect that adding --delete and nothing else probably > > makes things worse than not doing anything. I don't necessarily agree with that. Having '--delete=<dst>' being long version equivalent of ':<dst>' doesn't in my opinion change parading used by git-push to the "<scm> push <operation> <refs>..." paradigm used by Mercurial. It's just a convenience syntax sugar: have more readable but longer version. Just like equivalent short and long options. BTW. there are few other places where git is TMTOWDI... > > In a mental model where "push there --delete $branch" is natural, there > > are branches on the other side, and when you run 'push' command, you name > > the special operation, 'delete', that you would want to inflict on them. > > > > In such a world, there probably are other (perhaps not so special) > > operations you can inflict on the branches on the other side as well. > > They are probably called something like: > > > > push there --create $branch $commit > > push there --update $branch $commit > > > > If you give them only --delete without completing the vocabulary by giving > > these operations as well, you would force people to mix "git native" world > > model (i.e. there is no "mode" nor "opration"; there is only "list of > > instructions, each of which encodes the equivalent of 'mode'") with this > > Hg-inspired world model. > > One final note on this topic. A more problematic is --rename. > > In the "there are branches on the other side, and a push command can be > told to operate on them in different ways" world model, you naturally > would want to: > > push there --delete $branch > push there --rename $old $new > push there --copy $old $new > > The first one you can implement as a syntax sugar by turning it into the > native way of pushing ":$branch". You however cannot shoehorn rename and > copy, because the way in which git push works does not have direct access > to their "original" values of remote branches. If we do not have the > current object $old points at, you cannot emulate "rename $old $new" nor > "copy $old $new" only with simple syntax sugarcoating. We would likely > need a protocol extension to fit them in, and that is of dubious value. True. I'm against introducing "<scm> push <remote> <operation> <refs>" paradigm. If you think that '--delete=<dst>' for ':<dst>' would cause too much confusion... > > Among the ones Jakub listed in another message: http://nubyonrails.com/articles/five-features-from-mercurial-that-would-make-git-suck-less > 1. "<scm> init <directory>" (done) > 2. "hg commit --close-branch" vs slightly cryptic > "git push origin :refs/heads/feature-tweak", which can be written > simply as "git push origin :feature-tweak" I think. > (that is what this patch series is about) > 3. Numeric local references, e.g. 18:a432bc and "hg checkout 18"... > but more realistic example would be "hg checkout 6324" :-P > 4. sensible defaults: meaning of revert, staging area (i.e. commit -a) > 5. "hg serve" (gitweb and a kind of git-daemon equivalent) Note that I didn't said that I have agree with those points (as you can see with comment to #3 for example), and I did say to read original blog post instead of relying on this bare-bones summary. > > I think only #1 and #5 make sense (and I wonder if it would be enough to > mention "instaweb" and "daemon" to cover #5). I think #5 is also about native transport over HTTP, i.e. the "smart" HTTP protocol idea (which didn't pass protocol design stage, AFAIK no code). > > As we discussed in this thread at length, #2 is on the borderline. It > makes sense if you take only --delete out of possible vocabulary, but when > you think about it as a part of a coherent whole, it becomes somewhat > iffy---it does not fit particularly well with other parts of the system. I can agree that #2 is borderline and a bit problematic (when one is in the mood for bikeshedding at least ;-))). > > I think #3 and #4 comes from fundamental difference of the world views. > > Regarding #3, giving monotonically increasing numbers to local commits > would not be very hard without breaking the underlying data model. You > would automatically tag the original commit whenever a new branch is > created, and count commits relative to that origin-point tag for the > current branch, perhaps following only the first parent chain, or > something like that. > > For such a incrementing number be any useful, the user's history should > rarely rewind, and this also introduces a notion/illusion that a branch > somehow has its own identity, which we deliberately have rejected. I doubt > this is worth it. Most of the time you are interested in the recent past, > and HEAD~14 would be far easier to use than r19354 anyway ;-) Also there is a matter of fast-forward merges that git use, which I think is against 'branch have identity' idea. On the other side there was considered adding 'generation' header generation(this) = max(generation(this.parents)) + 1 which was intended to help speed up traversal, but it was decided it was not worth the hassle to add such commit object header to existing repository which do not use it. There was idea to put it in cache, as it is recalculable, but that idea was never put into code. > > About #4, in general, I do not think it is worth discussing a topic that > begins with the word "sensible" when the person who uses that word does > not realize that what is sensible is in the eyes of beholder. Different > SCMs use "revert" to mean different things, because there are a lot of > combinations of _things_ you would want to revert, _states_ you would want > to revert to, and _ways_ you would want the revert to be expressed. You > may be familiar with the way BK used the word revert, or you may be > familiar with the way SVN used the word revert. There is no single > "right" use of the word. > > It also is not worth repeating the discussion on fear of index, either. IHMO the very minor disadvantage of having to specify "git commit -a" with '-a' option in usual case is well worth it when you need more complicated staging / index manipulation, e.g. during more involved merging. > > This is a good example of why you should _think_ before blindly parrotting > whatever random people say on the net. They have not necessarily thought > things through before saying "git can learn from X". You need to do the > thinking for them to decide if they are making any sense when you read > these things. I was just listing what he said ;-) -- Jakub Narebski Poland -- 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