On 17 Oct 2006, Shawn Pearce <spearce@xxxxxxxxxxx> wrote: > Aaron Bentley <aaron.bentley@xxxxxxxxxxx> wrote: > > Jakub Narebski wrote: > > > One cannot have universally valid revision numbers (even > > > only per branch) in distributed development. Subversion can do that only > > > because it is centralized SCM. Global numbering and distributed nature > > > doesn't mix... hence contents based sha1 as commit identifiers. > > > > Sure. Our UI approach is that unique identifiers can usefully be > > abstracted away with a combination of URL + number, in the vast majority > > of cases. > > But this only works when the URL is public. In Git I can just lookup > the unique SHA1 for a revision in my private repository and toss it > into an email with a quick copy and paste. Yes, but then people need to know how to get it out of your private repository. For stuff that goes into well-known repositories I suppose it just propagates. > With Bazaar it sounds like I'd have to do that relative to some known > public repository, which just sounds like more work to me. You can also name a revision using its UUID, in which case things will work similarly to git. We tend to often say "in r1234 of dev". > But I don't want to see this otherwise interesting thread devolve into > a "we do X better!" match so I'm not going to say anything further here. Sure. > > > I wonder if any SCM other than git has easy way to "rebase" a branch, > > > i.e. cut branch at branching point, and transplant it to the tip > > > of other branch. For example you work on 'xx/topic' topic branch, > > > and want to have changes in those branch but applied to current work, > > > not to the version some time ago when you have started working on > > > said feature. > > > > If I understand correctly, in Bazaar, you'd just merge the current work > > into 'xx/topic'. > > Git has two approaches: > > - merge: The two independent lines of development are merged > together under a new single graph node. This is a merge commit > and has two parent pointers, one for each independent line of > development which was combined into one. Up to 16 independent > lines can be merged at once, though 12 is the record. > > - rebase: The commits from one line of development are replayed > onto a totally different line of development. This is often > used to reapply your changes onto the upstream branch after the > upstream has changed but before you send your changes upstream. > It can often generate more readable commit history. > > I believe what you are talking about in Bazaar is the former (merge) > while what Jakub was talking about was the latter (rebase). For the 'rebase' operation in Bazaar you can use 'bzr graft': http://spacepants.org/src/bzrgraft/ -- Martin - 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