Aaron Bentley wrote: > Andreas Ericsson wrote: >> Aaron Bentley wrote: >>> Ah. Bazaar uses negative numbers to refer to <n>th parents, and >>> positive numbers to refer to the number of commits that have been made >>> since the branch was initialized. >>> >> >> What do you do once a branch has been thrown away, or has had 20 other >> branches merged into it? Does the offset-number change for the revision >> then, or do you track branch-points explicitly? > > We always track the number of parents since the initial commit in the > project. Sorry, I don't think I said that clearly before. While this I think is quite reliable (there was idea to store "generation number" with each commit, e.g. using not implemented "note" header, or commit-id to generation number "database" as a better heuristic than timestamp for revision ordering in git-rev-list output), and probably independent on repository (it is global property of commit history, and commit history is included in sha1 of its parents), numbering branching points is unreliable, as is relying on branch names. >>> If I understand correctly, in Bazaar, you'd just merge the current work >>> into 'xx/topic'. >>> >> >> merge != rebase though, although they are indeed similar. Let's take the >> example of a 'master' branch and topic branch topicA. If you rebase >> topicA onto 'master', development will appear to have been serial. > > Ah, now I see what you mean, and the "graft" plugin mentioned by others > fills that role. I've never used it, though. Very useful as a kind of poor-man's-Quilt (or StGit). You develop some feature step by step, commit by commit in your repository cooking it in topic branch. Then before sending it to mailing list or maintainer as a series of patches (using git-format-patch and git-send-email) you rebase it on top of current work (current state), to ensure that it would apply cleanly. >> If >> you instead merge them, it will either register as a real merge or, if >> the branch tip of 'master' is the branch start-point of topicA, it will >> result in a "fast-forward" where 'master' is just updated to the >> branch-tip of 'topicA'. > > Interesting. We don't do 'fast-forward' in that case. Fast-forward is a really good idea. Perhaps you could implement it, if it is not hidden under different name? >>> I'm not sure what you mean by API, unless you mean the commandline. If >>> that's what you mean, surely all unix commands are extensible in that >>> regard. >>> >> >> I'm fairly certain he's talking about the API in the sense it's being >> talked about in every other application. Extensive work has been made to >> libify a lot of the git code, which means that most git commands are >> made up of less than 400 lines of C code, where roughly 80% of the code >> is command-specific (i.e., argument parsing and presentation). > > Ah, okay. > > So it sounds to me like git is extensible, though not as thoroughly as bzr. I think having good API for C, shell and Perl (and to lesser extent for any scripting language) means that it is extensible more. Git is not as of yet libified; when it would be we could think about bindings for other programming languages (there is preliminary Java binding/interface). -- 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