also sprach Sam Vilain <[EMAIL PROTECTED]> [2008.11.20.2221 +0100]: > potentially do this; I don't know that there is a normal UI way of doing > it; it's the sort of thing I normally do using my 'git-amend' script > (http://utsl.gen.nz/git/git-amend ) which just pops open HEAD in an > editor and lets you mess with it. In this way the previous merge commit > can be removed from the history, which makes it equivalent to the case > where you re-merged continuously, but you get the merge behaviour you > desire.
This sounds horribly like rewriting history and making it impossible to work distributed. also sprach Sam Vilain <[EMAIL PROTECTED]> [2008.11.24.0105 +0100]: > It probably makes sense to make sure that TopGit can deal with the > use cases you describe; it possibly is most of the way there > already... Martin? My head's a bit in the clouds. What is it exactly that you seek from TopGit (which *never* rewrites history and builds on the premise that nothing else does[*]). [*] obviously, nothing is there to be said against git commit --amend or rebase -i to reorganise commits on branch heads that have not been published. -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems fashions have done more harm than revolutions. -- victor hugo
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-pkg-discuss mailing list firstname.lastname@example.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss