* support for bzr shelve/unshelve in vc-dir @ 2009-12-01 19:47 Dan Nicolaescu 2009-12-01 20:48 ` Xavier Maillard 2009-12-01 22:11 ` Stefan Monnier 0 siblings, 2 replies; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-01 19:47 UTC (permalink / raw) To: emacs-devel Are the bzr shelve/unshelve commands popular? Do we want something similar to the vc-dir support for "git stash" for bzr shelve/unshelve? If yes, I can try to whip up a patch before the feature freeze... ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-01 19:47 support for bzr shelve/unshelve in vc-dir Dan Nicolaescu @ 2009-12-01 20:48 ` Xavier Maillard 2009-12-02 5:43 ` Dan Nicolaescu 2009-12-01 22:11 ` Stefan Monnier 1 sibling, 1 reply; 57+ messages in thread From: Xavier Maillard @ 2009-12-01 20:48 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: emacs-devel Are the bzr shelve/unshelve commands popular? Do we want something similar to the vc-dir support for "git stash" for bzr shelve/unshelve? If yes, I can try to whip up a patch before the feature freeze... Speaking for myself, I'd vote for this feature. Xavier -- http://www.gnu.org http://www.april.org http://www.lolica.org ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-01 20:48 ` Xavier Maillard @ 2009-12-02 5:43 ` Dan Nicolaescu 2009-12-02 6:37 ` Óscar Fuentes 0 siblings, 1 reply; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-02 5:43 UTC (permalink / raw) To: Xavier Maillard; +Cc: emacs-devel Xavier Maillard <xma@gnu.org> writes: > Are the bzr shelve/unshelve commands popular? > > Do we want something similar to the vc-dir support for "git stash" for > bzr shelve/unshelve? > > If yes, I can try to whip up a patch before the feature freeze... > > Speaking for myself, I'd vote for this feature. Here's a quick port of the git code (It still uses the "stash" name). It can create and remove shelves. I don't see a way to display the diff for a shelf. Index: vc-bzr.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/vc-bzr.el,v retrieving revision 1.86 diff -u -3 -p -u -p -r1.86 vc-bzr.el --- vc-bzr.el 26 Nov 2009 14:50:32 -0000 1.86 +++ vc-bzr.el 2 Dec 2009 05:25:45 -0000 @@ -703,11 +705,33 @@ stream. Standard error output is discar (vc-exec-after `(vc-bzr-after-dir-status (quote ,update-function)))) +(defvar vc-bzr-stash-map + (let ((map (make-sparse-keymap))) + (define-key map "\C-k" 'vc-bzr-stash-delete-at-point) + (define-key map "=" 'vc-bzr-stash-show-at-point) + (define-key map "\C-m" 'vc-bzr-stash-show-at-point) + map)) + +(defvar vc-bzr-extra-menu-map + (let ((map (make-sparse-keymap))) + (define-key map [bzr-st] + '(menu-item "Stash..." vc-bzr-stash + :help "Stash away changes")) + (define-key map [bzr-ss] + '(menu-item "Show Stash..." vc-bzr-stash-show + :help "Show stash contents")) + map)) + +(defun vc-bzr-extra-menu () vc-bzr-extra-menu-map) + +(defun vc-bzr-extra-status-menu () vc-bzr-extra-menu-map) + (defun vc-bzr-dir-extra-headers (dir) (let* ((str (with-temp-buffer (vc-bzr-command "info" t 0 dir) (buffer-string))) + (stash (vc-bzr-stash-list)) (light-checkout (when (string-match ".+light checkout root: \\(.+\\)$" str) (match-string 1 str))) @@ -721,18 +745,81 @@ stream. Standard error output is discar (if (string-match "parent branch: \\(.+\\)$" str) (match-string 1 str) "None") - 'face 'font-lock-variable-name-face) + 'face 'font-lock-variable-name-face) "\n" - (when light-checkout - (concat - (propertize "Light checkout root: " 'face 'font-lock-type-face) - (propertize light-checkout 'face 'font-lock-variable-name-face) - "\n")) - (when light-checkout-branch - (concat - (propertize "Checkout of branch : " 'face 'font-lock-type-face) - (propertize light-checkout-branch 'face 'font-lock-variable-name-face) - "\n"))))) + (when light-checkout + (concat + (propertize "Light checkout root: " 'face 'font-lock-type-face) + (propertize light-checkout 'face 'font-lock-variable-name-face) + "\n")) + (when light-checkout-branch + (concat + (propertize "Checkout of branch : " 'face 'font-lock-type-face) + (propertize light-checkout-branch 'face 'font-lock-variable-name-face) + "\n")) + (if stash + (concat + (propertize "Stash :\n" 'face 'font-lock-type-face) + (mapconcat + (lambda (x) + (propertize x + 'face 'font-lock-variable-name-face + 'mouse-face 'highlight + 'keymap vc-bzr-stash-map)) + stash "\n")) + (concat + (propertize "Stash : " 'face 'font-lock-type-face) + (propertize "Nothing stashed" + 'face 'font-lock-variable-name-face)))))) + + +(defun vc-bzr-stash (name) + "Create a stash." + (interactive "sStash name: ") + (let ((root (vc-bzr-root default-directory))) + (when root + (vc-bzr-command "shelve" nil 0 nil "--all" "-m" name) + (vc-resynch-buffer root t t)))) + +(defun vc-bzr-stash-show (name) + "Show the contents of stash NAME." + (interactive "sStash name: ") + (vc-setup-buffer "*vc-bzr-stash*") + ;; FIXME: how can you show the contents of a shelf? + (vc-bzr-command "shelve" "*vc-bzr-stash*" 'async nil name) + (set-buffer "*vc-bzr-stash*") + (diff-mode) + (setq buffer-read-only t) + (pop-to-buffer (current-buffer))) + +(defun vc-bzr-stash-list () + (with-temp-buffer + (vc-bzr-command "shelve" (current-buffer) 1 nil "--list") + (delete + "" + (split-string + (buffer-substring (point-min) (point-max)) + "\n")))) + +(defun vc-bzr-stash-get-at-point (point) + (save-excursion + (goto-char point) + (beginning-of-line) + (if (looking-at "^ +\\([0-9]+\\):") + (match-string 1) + (error "Cannot find stash at point")))) + +(defun vc-bzr-stash-delete-at-point () + (interactive) + (let ((stash (vc-bzr-stash-get-at-point (point)))) + (when (y-or-n-p (format "Remove stash %s ?" stash)) + (vc-bzr-command "unshelve" nil 0 nil "--delete-only" stash) + (vc-dir-refresh)))) + +(defun vc-bzr-stash-show-at-point () + (interactive) + (vc-bzr-stash-show (vc-bzr-stash-get-at-point (point)))) + ;;; Revision completion ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-02 5:43 ` Dan Nicolaescu @ 2009-12-02 6:37 ` Óscar Fuentes 0 siblings, 0 replies; 57+ messages in thread From: Óscar Fuentes @ 2009-12-02 6:37 UTC (permalink / raw) To: emacs-devel Dan Nicolaescu <dann@ics.uci.edu> writes: > I don't see a way to display the diff for a shelf. `shelf1' does a lot of operations with shelves: bzr help shelf1 That command is from the bzrtools plugin, which is not guaranteed to be installed along with bzr, although is probably the most popular and considered a "must have". [snip] -- Óscar ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-01 19:47 support for bzr shelve/unshelve in vc-dir Dan Nicolaescu 2009-12-01 20:48 ` Xavier Maillard @ 2009-12-01 22:11 ` Stefan Monnier 2009-12-01 22:50 ` Óscar Fuentes ` (2 more replies) 1 sibling, 3 replies; 57+ messages in thread From: Stefan Monnier @ 2009-12-01 22:11 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: emacs-devel > Are the bzr shelve/unshelve commands popular? > Do we want something similar to the vc-dir support for "git stash" for > bzr shelve/unshelve? That would be welcome, yes. > If yes, I can try to whip up a patch before the feature freeze... There's no hurry on my side. I'm probably more eager to see support for things like pull/push. Stefan ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-01 22:11 ` Stefan Monnier @ 2009-12-01 22:50 ` Óscar Fuentes 2009-12-01 23:18 ` Óscar Fuentes 2009-12-02 3:03 ` Dan Nicolaescu 2009-12-03 7:48 ` Dan Nicolaescu 2 siblings, 1 reply; 57+ messages in thread From: Óscar Fuentes @ 2009-12-01 22:50 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> If yes, I can try to whip up a patch before the feature freeze... > > There's no hurry on my side. I'm probably more eager to see support for > things like pull/push. ... and `merge' -- Óscar ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-01 22:50 ` Óscar Fuentes @ 2009-12-01 23:18 ` Óscar Fuentes 2009-12-02 3:00 ` Dan Nicolaescu 0 siblings, 1 reply; 57+ messages in thread From: Óscar Fuentes @ 2009-12-01 23:18 UTC (permalink / raw) To: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: >> There's no hurry on my side. I'm probably more eager to see support for >> things like pull/push. > > ... and `merge' oh, and `missing' too. -- Óscar ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-01 23:18 ` Óscar Fuentes @ 2009-12-02 3:00 ` Dan Nicolaescu 0 siblings, 0 replies; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-02 3:00 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > Óscar Fuentes <ofv@wanadoo.es> writes: > > >> There's no hurry on my side. I'm probably more eager to see support for > >> things like pull/push. > > > > ... and `merge' > > oh, and `missing' too. That's easy. It can be directly derived from vc-outgoing, whenever I manage to check it in. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-01 22:11 ` Stefan Monnier 2009-12-01 22:50 ` Óscar Fuentes @ 2009-12-02 3:03 ` Dan Nicolaescu 2009-12-02 3:31 ` Óscar Fuentes 2009-12-03 7:48 ` Dan Nicolaescu 2 siblings, 1 reply; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-02 3:03 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > > If yes, I can try to whip up a patch before the feature freeze... > > There's no hurry on my side. I'm probably more eager to see support for > things like pull/push. The "no problem" case for those is easy, just run the corresponding command. If someone does the design for those, I can help with the implementation. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-02 3:03 ` Dan Nicolaescu @ 2009-12-02 3:31 ` Óscar Fuentes 2009-12-02 4:35 ` Stefan Monnier 0 siblings, 1 reply; 57+ messages in thread From: Óscar Fuentes @ 2009-12-02 3:31 UTC (permalink / raw) To: emacs-devel Dan Nicolaescu <dann@ics.uci.edu> writes: > Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > > > > If yes, I can try to whip up a patch before the feature freeze... > > > > There's no hurry on my side. I'm probably more eager to see support for > > things like pull/push. > > The "no problem" case for those is easy, just run the corresponding > command. > If someone does the design for those, I can help with the implementation. Being vc/vc-dir, I guess that the design must cover all dominant dVCS today (git, mercurial, bazaar). I remember just a bit about git, and know nothing about mercurial but, for the case of bazaar, adding basic support for pull/push/merge seems fairly easy: execute the command, report the result and refresh the displayed VC info. One extra goodie that is not too hard to implement is to support an invocation mode where the user can provide an alternative location (C-u perhaps?). IIRC you must provide a location when you invoke push/merge for the first time on Bazaar, so detecting and handling this condition may be a bit tricky. Providing a location would be useful for `diff' too, for showing the differences among two branches. A system for storing named bookmarks (locations) so you are not forced to write the same cumbersome URLs again and again and use names instead would be very handy. I don't know how much work this requires. Finally, implementing invocation parameters for supporting all the useful variants 'merge' has seems a bit daunting to integrate on the current interface and maybe warrants using a specific buffer where you can preview what's available for merging (retrieved with `missing' or with `diff') and then choose how to perform the operarion. This seems very backend-dependent and a lot of work, but would add a lot of value to vc/vc-dir. -- Óscar ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-02 3:31 ` Óscar Fuentes @ 2009-12-02 4:35 ` Stefan Monnier 2009-12-02 5:06 ` Óscar Fuentes 2009-12-02 6:16 ` Stephen J. Turnbull 0 siblings, 2 replies; 57+ messages in thread From: Stefan Monnier @ 2009-12-02 4:35 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > may be a bit tricky. Providing a location would be useful for `diff' > too, for showing the differences among two branches. C-u C-v x = does allow you to specify a branch. > A system for storing named bookmarks (locations) so you are not forced > to write the same cumbersome URLs again and again and use names instead > would be very handy. I don't know how much work this requires. This really belongs in `bzr' in my opinion. `git' is a lot better in this respect. > Finally, implementing invocation parameters for supporting all the > useful variants 'merge' has seems a bit daunting to integrate on the Not sure what you're referring to here. Stefan ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-02 4:35 ` Stefan Monnier @ 2009-12-02 5:06 ` Óscar Fuentes 2009-12-02 6:16 ` Stephen J. Turnbull 1 sibling, 0 replies; 57+ messages in thread From: Óscar Fuentes @ 2009-12-02 5:06 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> may be a bit tricky. Providing a location would be useful for `diff' >> too, for showing the differences among two branches. > > C-u C-v x = does allow you to specify a branch. Thanks. [snip] >> Finally, implementing invocation parameters for supporting all the >> useful variants 'merge' has seems a bit daunting to integrate on the > > Not sure what you're referring to here. Execute bzr help merge some options listed there are really useful and it would be nice to use them from vc. -- Óscar ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-02 4:35 ` Stefan Monnier 2009-12-02 5:06 ` Óscar Fuentes @ 2009-12-02 6:16 ` Stephen J. Turnbull 2009-12-02 6:42 ` Óscar Fuentes 1 sibling, 1 reply; 57+ messages in thread From: Stephen J. Turnbull @ 2009-12-02 6:16 UTC (permalink / raw) To: Stefan Monnier; +Cc: Óscar Fuentes, emacs-devel Stefan Monnier writes: > > A system for storing named bookmarks (locations) so you are not forced > > to write the same cumbersome URLs again and again and use names instead > > would be very handy. I don't know how much work this requires. > > This really belongs in `bzr' in my opinion. `git' is a lot better in > this respect. Doesn't bzr's branch nickname feature serve here? If it does, it has the advantage that names you use in Emacs will also serve in the shell. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-02 6:16 ` Stephen J. Turnbull @ 2009-12-02 6:42 ` Óscar Fuentes 0 siblings, 0 replies; 57+ messages in thread From: Óscar Fuentes @ 2009-12-02 6:42 UTC (permalink / raw) To: emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > Stefan Monnier writes: > > > > A system for storing named bookmarks (locations) so you are not forced > > > to write the same cumbersome URLs again and again and use names instead > > > would be very handy. I don't know how much work this requires. > > > > This really belongs in `bzr' in my opinion. `git' is a lot better in > > this respect. > > Doesn't bzr's branch nickname feature serve here? Not really. Bazaar has no problems working with multiple branches with the same nick and, unless you explicitly name them with `bzr nick <name>', the nick will be the same as the parent's. OTOH, the nick doesn't tell bazaar the location of the branch. AFAIK, git has a bookmark system built-in. There is a plugin for bazaar, but I don't know how well it works. [snip] -- Óscar ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-01 22:11 ` Stefan Monnier 2009-12-01 22:50 ` Óscar Fuentes 2009-12-02 3:03 ` Dan Nicolaescu @ 2009-12-03 7:48 ` Dan Nicolaescu 2009-12-03 8:25 ` Óscar Fuentes 2 siblings, 1 reply; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-03 7:48 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > > Are the bzr shelve/unshelve commands popular? > > Do we want something similar to the vc-dir support for "git stash" for > > bzr shelve/unshelve? > > That would be welcome, yes. Done. I couldn't find a way to display the content of a shelf, so support for that is missing. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-03 7:48 ` Dan Nicolaescu @ 2009-12-03 8:25 ` Óscar Fuentes 2009-12-03 8:32 ` Bojan Nikolic 2009-12-03 9:07 ` Dan Nicolaescu 0 siblings, 2 replies; 57+ messages in thread From: Óscar Fuentes @ 2009-12-03 8:25 UTC (permalink / raw) To: emacs-devel; +Cc: Dan Nicolaescu Dan Nicolaescu <dann@ics.uci.edu> writes: > > > Are the bzr shelve/unshelve commands popular? Do we want > > > something similar to the vc-dir support for "git stash" for bzr > > > shelve/unshelve? > > > > That would be welcome, yes. > > Done. The implementation shelves all the changes on the current branch. Although this is useful, an usual application of `shelve' is for temporarily removing out of your way some changes (allowing to commit only specific changes of the edited files, for example.) An ideal implementation of `shelve' for vc would show the output of `bzr diff', mark the hunks you want to shelve, and then run the command. Sadly, it seems impossible to non-interactively indicate to bzr which hunks it should shelve. > I couldn't find a way to display the content of a shelf, so support for > that is missing. As mentioned on a previous message, `bzr shelf1 list' should do what you need. It is from bzrtools, which is a popular plugin. However, the command either is broken or I don't know how to use it. I'll ask on the bazaar ml. -- Óscar ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-03 8:25 ` Óscar Fuentes @ 2009-12-03 8:32 ` Bojan Nikolic 2009-12-03 9:07 ` Dan Nicolaescu 1 sibling, 0 replies; 57+ messages in thread From: Bojan Nikolic @ 2009-12-03 8:32 UTC (permalink / raw) To: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > As mentioned on a previous message, `bzr shelf1 list' should do what you > need. It is from bzrtools, which is a popular plugin. However, the > command either is broken or I don't know how to use it. I'll ask on the > bazaar ml. I think: bzr shelve --list should do the trick and it is in the core bzr package. Best, Bojan -- Bojan Nikolic || http://www.bnikolic.co.uk ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-03 8:25 ` Óscar Fuentes 2009-12-03 8:32 ` Bojan Nikolic @ 2009-12-03 9:07 ` Dan Nicolaescu 2009-12-03 17:05 ` Splitting changes (was: support for bzr shelve/unshelve in vc-dir) Stefan Monnier 2009-12-03 17:24 ` support for bzr shelve/unshelve in vc-dir Óscar Fuentes 1 sibling, 2 replies; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-03 9:07 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > > > Are the bzr shelve/unshelve commands popular? Do we want > > > > something similar to the vc-dir support for "git stash" for bzr > > > > shelve/unshelve? > > > > > > That would be welcome, yes. > > > > Done. > > The implementation shelves all the changes on the current > branch. Although this is useful, an usual application of `shelve' is for > temporarily removing out of your way some changes (allowing to commit > only specific changes of the edited files, for example.) An ideal > implementation of `shelve' for vc would show the output of `bzr diff', > mark the hunks you want to shelve, and then run the command. Sadly, it > seems impossible to non-interactively indicate to bzr which hunks it > should shelve. That's exactly the reason for the current implementation. Patches to add other methods to create shelves (including an interactive) are surely welcome. > > I couldn't find a way to display the content of a shelf, so support for > > that is missing. > > As mentioned on a previous message, `bzr shelf1 list' should do what you > need. It is from bzrtools, which is a popular plugin. However, the > command either is broken or I don't know how to use it. I'll ask on the > bazaar ml. bzr shelf1 list doesn't even show shelves created with bzr shelve... ^ permalink raw reply [flat|nested] 57+ messages in thread
* Splitting changes (was: support for bzr shelve/unshelve in vc-dir) 2009-12-03 9:07 ` Dan Nicolaescu @ 2009-12-03 17:05 ` Stefan Monnier 2009-12-03 17:46 ` Eli Zaretskii 2009-12-03 19:47 ` Óscar Fuentes 2009-12-03 17:24 ` support for bzr shelve/unshelve in vc-dir Óscar Fuentes 1 sibling, 2 replies; 57+ messages in thread From: Stefan Monnier @ 2009-12-03 17:05 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Óscar Fuentes, emacs-devel >> The implementation shelves all the changes on the current >> branch. Although this is useful, an usual application of `shelve' is for >> temporarily removing out of your way some changes (allowing to commit >> only specific changes of the edited files, for example.) An ideal >> implementation of `shelve' for vc would show the output of `bzr diff', >> mark the hunks you want to shelve, and then run the command. Sadly, it >> seems impossible to non-interactively indicate to bzr which hunks it >> should shelve. > That's exactly the reason for the current implementation. > Patches to add other methods to create shelves (including an > interactive) are surely welcome. I've been interested in this issue for a while now: I've been using a local patch to VC which adds a command "vc-prepare-for-partial-commit", which allows to choose which part of some local changes should be committed and which part should be kept for later. I've never installed it in the trunk for various reasons, but I've use it extensively for many years. In this time I noticed the following: - selecting only by files is not a fine enough granularity. - selecting only by hunks is sometimes sufficient, but even that is too coarse in my experience. The typical problem is that I want to split a change into a cleanup part and an actual new feature, but in most cases all the cleanup changes touch the exact same code as the new feature, so many of the hunks mix both. So the way my hack works is the following: - it takes ("stashes") a copy of the current state. - then it lets you make any changes you want (the intention is that you're going to revert the changes you want to keep for later). You can do this part at any granularity: files, hunks, or even by hand. - when done, you commit, after which the saved files are re-instated. This gives me great flexibility, and lets me use any tool I want to select which parts to keep and which parts not. So I really like it. But it has some serious drawbacks: - if the final commit fails because the tree is not uptodate (any more), the backend won't know that the update should apply to both the file and its "stashed" copy. So you end up having to deal with updates missing from the stashed copy, or abort the partial commit (i.e. revert to the stashed copy), then update, then re-do the split by hand. - when doing the split by hand, you can make any change you want. The intention is for those changes to "undo" part of the local changes, but nothing prevents you from adding new changes during this time (as you revisit the code to choose how to split your changes, you may bump into new opportunities for cleanup and it's sometimes difficult to refrain from doing them at that point). And if you do add local changes, then these will be undone after commit when the saved files are re-instated. So I'd like VC to support something like that, but in a way that is a bit more robust. The way I see it working ideally is something like the following: - the copy is taken by committing the local changes on a new temporary branch (IIUC, that's pretty much what "git stash" does). - then revert to the original branch and reapply those same changes (without committing them). - at this point the user can use any tool he likes to remove parts of those changes he doesn't want to commit yet. She can also "update" her tree when needed. - when she's ready, she can perform the "commit", after which VC will ask to merge the temporary branch (without committing the result), which will hopefully result in pretty much the same as the original code before this whle partial commit took place. The advantage here, is that because we use branches rather than manually copying files behind the VCS's back, the VCS has all the needed meta-data to ensure that no change is accidentally lost or undone. The disadvantage is that the final merge is likely to introduce spurious conflicts since it will re-apply the parts of the changes that were just committed. But if "same change conflicts" are automatically resolved by your merge tool, then all the changes that were selected at the granularity of a hunk (or larger) should be merged without conflict. I.e. you should only see conflicts when you actually take advantage of the extra flexibility. Stefan ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Splitting changes (was: support for bzr shelve/unshelve in vc-dir) 2009-12-03 17:05 ` Splitting changes (was: support for bzr shelve/unshelve in vc-dir) Stefan Monnier @ 2009-12-03 17:46 ` Eli Zaretskii 2009-12-03 19:26 ` Splitting changes Stefan Monnier 2009-12-03 19:47 ` Óscar Fuentes 1 sibling, 1 reply; 57+ messages in thread From: Eli Zaretskii @ 2009-12-03 17:46 UTC (permalink / raw) To: Stefan Monnier; +Cc: ofv, dann, emacs-devel > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Date: Thu, 03 Dec 2009 12:05:49 -0500 > Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org > > I've been interested in this issue for a while now: I've been using > a local patch to VC which adds a command > "vc-prepare-for-partial-commit", which allows to choose which part of > some local changes should be committed and which part should be kept > for later. Sounds like you want to clone the current branch, make some changes there, commit those changes upstream, then merge them with your original branch and return there for more hacking. Is that right? If so, why do we need a VC feature for that -- don't modern VCS support such a workflow already? ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Splitting changes 2009-12-03 17:46 ` Eli Zaretskii @ 2009-12-03 19:26 ` Stefan Monnier 0 siblings, 0 replies; 57+ messages in thread From: Stefan Monnier @ 2009-12-03 19:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ofv, dann, emacs-devel >> I've been interested in this issue for a while now: I've been using >> a local patch to VC which adds a command >> "vc-prepare-for-partial-commit", which allows to choose which part of >> some local changes should be committed and which part should be kept >> for later. > Sounds like you want to clone the current branch, make some changes > there, commit those changes upstream, then merge them with your > original branch and return there for more hacking. Is that right? If > so, why do we need a VC feature for that -- don't modern VCS support > such a workflow already? I want that support right there in VC. Stefan ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Splitting changes 2009-12-03 17:05 ` Splitting changes (was: support for bzr shelve/unshelve in vc-dir) Stefan Monnier 2009-12-03 17:46 ` Eli Zaretskii @ 2009-12-03 19:47 ` Óscar Fuentes 2009-12-03 20:50 ` Stefan Monnier 1 sibling, 1 reply; 57+ messages in thread From: Óscar Fuentes @ 2009-12-03 19:47 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: [snip] > So the way my hack works is the following: > - it takes ("stashes") a copy of the current state. > - then it lets you make any changes you want (the intention is that > you're going to revert the changes you want to keep for later). > You can do this part at any granularity: files, hunks, or even > by hand. > - when done, you commit, after which the saved files are re-instated. This can be achieved with the feature Dan is requesting for Bazaar (and git already has): > > 2. something similar to "git stash apply", i.e. apply the shelf but do > > not remove it. This makes it easy to split changes for example. With that feature you would do bzr shelve --all bzr unshelve --keep # that option would prevent removing the shelve <hack, hack, hack> bzr commit etc bzr unshelve > This gives me great flexibility, and lets me use any tool I want to > select which parts to keep and which parts not. So I really like it. > But it has some serious drawbacks: > - if the final commit fails because the tree is not uptodate (any more), > the backend won't know that the update should apply to both the file > and its "stashed" copy. So you end up having to deal with updates > missing from the stashed copy, or abort the partial commit > (i.e. revert to the stashed copy), then update, then re-do the split > by hand. > > - when doing the split by hand, you can make any change you want. > The intention is for those changes to "undo" part of the local > changes, but nothing prevents you from adding new changes during this > time (as you revisit the code to choose how to split your changes, you > may bump into new opportunities for cleanup and it's sometimes > difficult to refrain from doing them at that point). And if you do > add local changes, then these will be undone after commit when the > saved files are re-instated. `bzr unshelve' merges the patch it contains, instead of blindly applying it. It is enough for solving those problems? [snip] -- Óscar ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Splitting changes 2009-12-03 19:47 ` Óscar Fuentes @ 2009-12-03 20:50 ` Stefan Monnier 0 siblings, 0 replies; 57+ messages in thread From: Stefan Monnier @ 2009-12-03 20:50 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel >> So the way my hack works is the following: >> - it takes ("stashes") a copy of the current state. >> - then it lets you make any changes you want (the intention is that >> you're going to revert the changes you want to keep for later). >> You can do this part at any granularity: files, hunks, or even >> by hand. >> - when done, you commit, after which the saved files are re-instated. > This can be achieved with the feature Dan is requesting for Bazaar (and > git already has): >> > 2. something similar to "git stash apply", i.e. apply the shelf but do >> > not remove it. This makes it easy to split changes for example. > With that feature you would do > bzr shelve --all > bzr unshelve --keep # that option would prevent removing the shelve > <hack, hack, hack> > bzr commit etc > bzr unshelve Yes, that sounds about right. IIUC "bzr unshelve --keep" is what Dan calls "bzr apply". So the fundamental backend operations that are needed are shelve/stash (with a vc-fileset), unshelve-keep/apply, and unshelve. We could even provide a default implementation that "shelves" by storing a patch, and unshelves by apply that patch, for those backends that don't support anything similar. Stefan ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-03 9:07 ` Dan Nicolaescu 2009-12-03 17:05 ` Splitting changes (was: support for bzr shelve/unshelve in vc-dir) Stefan Monnier @ 2009-12-03 17:24 ` Óscar Fuentes 2009-12-03 18:18 ` Óscar Fuentes 1 sibling, 1 reply; 57+ messages in thread From: Óscar Fuentes @ 2009-12-03 17:24 UTC (permalink / raw) To: emacs-devel; +Cc: Dan Nicolaescu Dan Nicolaescu <dann@ics.uci.edu> writes: [snip] > > > I couldn't find a way to display the content of a shelf, so support for > > > that is missing. > > > > As mentioned on a previous message, `bzr shelf1 list' should do what you > > need. It is from bzrtools, which is a popular plugin. However, the > > command either is broken or I don't know how to use it. I'll ask on the > > bazaar ml. > > bzr shelf1 list doesn't even show shelves created with bzr shelve... Someone told me that bzrtools' `shelf1' only works with bzrtools' `shelve1'. It is incompatible with with bzr's `shelve'. For looking at the changes on a shelve1, you need `bzr shelf1 list', which lists the patches, and `bzr shelf1 show PATCH', which actually shows the patch: scar@qcore:~/dev/other/bzr-emacs/trunk$ bzr shelve1 --all Shelving to 1/00: "Changes shelved on 2009-12-03 18:12:08" oscar@qcore:~/dev/other/bzr-emacs/trunk$ bzr shelf1 list Patches on shelf '1': 00: Changes shelved on 2009-12-03 18:12:08 oscar@qcore:~/dev/other/bzr-emacs/trunk$ bzr shelf1 show 00 # Shelved patch: Changes shelved on 2009-12-03 18:12:08 --- INSTALL 2009-09-13 22:15:10 +0000 +++ INSTALL 2009-12-03 17:12:01 +0000 @@ -811,3 +811,4 @@ You should have received a copy of the GNU General Public License along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. +foo --- README 2009-06-21 04:46:07 +0000 +++ README 2009-12-03 17:12:01 +0000 @@ -107,3 +107,4 @@ You should have received a copy of the GNU General Public License along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. +zoo ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-03 17:24 ` support for bzr shelve/unshelve in vc-dir Óscar Fuentes @ 2009-12-03 18:18 ` Óscar Fuentes 2009-12-03 18:48 ` Dan Nicolaescu 0 siblings, 1 reply; 57+ messages in thread From: Óscar Fuentes @ 2009-12-03 18:18 UTC (permalink / raw) To: emacs-devel; +Cc: Dan Nicolaescu Óscar Fuentes <ofv@wanadoo.es> writes: >> bzr shelf1 list doesn't even show shelves created with bzr shelve... > > Someone told me that bzrtools' `shelf1' only works with bzrtools' > `shelve1'. It is incompatible with with bzr's `shelve'. [snip] Further discussion on the bazaar ml indicates that using shelve1/shelf1 is not a good idea. -- Óscar ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-03 18:18 ` Óscar Fuentes @ 2009-12-03 18:48 ` Dan Nicolaescu 2009-12-03 19:00 ` Óscar Fuentes 0 siblings, 1 reply; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-03 18:48 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > Óscar Fuentes <ofv@wanadoo.es> writes: > > >> bzr shelf1 list doesn't even show shelves created with bzr shelve... > > > > Someone told me that bzrtools' `shelf1' only works with bzrtools' > > `shelve1'. It is incompatible with with bzr's `shelve'. > [snip] > > Further discussion on the bazaar ml indicates that using shelve1/shelf1 > is not a good idea. Can you please forward 2 feature requests for shelve/unshelve then: 1. some way to show the diff 2. something similar to "git stash apply", i.e. apply the shelf but do not remove it. This makes it easy to split changes for example. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-03 18:48 ` Dan Nicolaescu @ 2009-12-03 19:00 ` Óscar Fuentes 2009-12-03 19:17 ` Dan Nicolaescu 0 siblings, 1 reply; 57+ messages in thread From: Óscar Fuentes @ 2009-12-03 19:00 UTC (permalink / raw) To: emacs-devel; +Cc: Dan Nicolaescu Dan Nicolaescu <dann@ics.uci.edu> writes: > > Further discussion on the bazaar ml indicates that using shelve1/shelf1 > > is not a good idea. > > Can you please forward 2 feature requests for shelve/unshelve then: > 1. some way to show the diff This is underway. > 2. something similar to "git stash apply", i.e. apply the shelf but do > not remove it. This makes it easy to split changes for example. Would you care to describe a plausible scenario where this is useful? I can't think of one rigth now. -- Óscar ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-03 19:00 ` Óscar Fuentes @ 2009-12-03 19:17 ` Dan Nicolaescu 2009-12-03 21:30 ` Óscar Fuentes 0 siblings, 1 reply; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-03 19:17 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > > Further discussion on the bazaar ml indicates that using shelve1/shelf1 > > > is not a good idea. > > > > Can you please forward 2 feature requests for shelve/unshelve then: > > 1. some way to show the diff > > This is underway. Good, code to support it is there, but commented out. > > 2. something similar to "git stash apply", i.e. apply the shelf but do > > not remove it. This makes it easy to split changes for example. > > Would you care to describe a plausible scenario where this is useful? > I can't think of one rigth now. Say you have something shelved. You want to try to refine the change, unshelve it and continue working on it. If you realize that what you had before was better, there's no easy way to go back. Or if you want to split a change: shelve apply remove the part you don't want shelve the partial change unshelve the original remove some other part shelve again ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-03 19:17 ` Dan Nicolaescu @ 2009-12-03 21:30 ` Óscar Fuentes 2009-12-03 22:57 ` Dan Nicolaescu 0 siblings, 1 reply; 57+ messages in thread From: Óscar Fuentes @ 2009-12-03 21:30 UTC (permalink / raw) To: emacs-devel; +Cc: Dan Nicolaescu Dan Nicolaescu <dann@ics.uci.edu> writes: > > > Can you please forward 2 feature requests for shelve/unshelve then: > > > 1. some way to show the diff > > > 2. something similar to "git stash apply", i.e. apply the shelf but do > > > not remove it. This makes it easy to split changes for example. [snip] Support for unshelve --keep : https://bugs.launchpad.net/bzr/+bug/492095 Support for shelve -F : https://bugs.launchpad.net/bzr/+bug/492091 For showing the contents of a shelve there are already 2 reports: bzr unshelve --dry-run should produce a diff: https://bugs.launchpad.net/bzr/+bug/317896 No reliable way to show shelved changes: https://bugs.launchpad.net/bzr/+bug/308122 Don't hold your breath. -- Óscar ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-03 21:30 ` Óscar Fuentes @ 2009-12-03 22:57 ` Dan Nicolaescu 2009-12-04 0:42 ` Stephen J. Turnbull 0 siblings, 1 reply; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-03 22:57 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > > > Can you please forward 2 feature requests for shelve/unshelve then: > > > > 1. some way to show the diff > > > > 2. something similar to "git stash apply", i.e. apply the shelf but do > > > > not remove it. This makes it easy to split changes for example. > > [snip] > > Support for unshelve --keep : > https://bugs.launchpad.net/bzr/+bug/492095 > Support for shelve -F : > https://bugs.launchpad.net/bzr/+bug/492091 > > For showing the contents of a shelve there are already 2 reports: > > bzr unshelve --dry-run should produce a diff: > https://bugs.launchpad.net/bzr/+bug/317896 > > No reliable way to show shelved changes: > https://bugs.launchpad.net/bzr/+bug/308122 > > Don't hold your breath. I know nothing about bzr, but unshelve --keep is gotta be trivial to implement... ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-03 22:57 ` Dan Nicolaescu @ 2009-12-04 0:42 ` Stephen J. Turnbull 2009-12-04 1:47 ` Dan Nicolaescu 0 siblings, 1 reply; 57+ messages in thread From: Stephen J. Turnbull @ 2009-12-04 0:42 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Óscar Fuentes, emacs-devel Dan Nicolaescu writes: > I know nothing about bzr, but unshelve --keep is gotta be trivial to > implement... It's not, because the shelf is kept in the history. Unshelving needs to rewind the history so that tip points to the pre-shelve revision. bzr has no refs, so recovering the shelved revision after an unshelve is non-trivial. It may not be hard, either, except that for it to be reliable may require the bzr developers to make promises about internal storage management. Looms (requires an incompatible branch format) and pipelines (like Mercurial queues or Stacked Git) provide the necessary scaffolding. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-04 0:42 ` Stephen J. Turnbull @ 2009-12-04 1:47 ` Dan Nicolaescu 2009-12-04 2:57 ` Óscar Fuentes 0 siblings, 1 reply; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-04 1:47 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Óscar Fuentes, emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > Dan Nicolaescu writes: > > > I know nothing about bzr, but unshelve --keep is gotta be trivial to > > implement... > > It's not, because the shelf is kept in the history. Unshelving needs > to rewind the history so that tip points to the pre-shelve revision. > bzr has no refs, so recovering the shelved revision after an unshelve > is non-trivial. It may not be hard, either, except that for it to be > reliable may require the bzr developers to make promises about internal > storage management. A several months old bzr tree happens to be my playground for testing VC changes on bzr. I changed "delete_shelf" to always be True in bzrlib/shelf_ui.py, and now "bzr unshelve --apply" does not remove shelves, and they seem to be valid and can be applied multiple times. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-04 1:47 ` Dan Nicolaescu @ 2009-12-04 2:57 ` Óscar Fuentes 2009-12-04 6:36 ` Stephen J. Turnbull 2009-12-04 21:18 ` Dan Nicolaescu 0 siblings, 2 replies; 57+ messages in thread From: Óscar Fuentes @ 2009-12-04 2:57 UTC (permalink / raw) To: emacs-devel; +Cc: Dan Nicolaescu Dan Nicolaescu <dann@ics.uci.edu> writes: > "Stephen J. Turnbull" <stephen@xemacs.org> writes: > > > Dan Nicolaescu writes: > > > > > I know nothing about bzr, but unshelve --keep is gotta be trivial to > > > implement... > > > > It's not, because the shelf is kept in the history. Unshelving needs > > to rewind the history so that tip points to the pre-shelve revision. > > bzr has no refs, so recovering the shelved revision after an unshelve > > is non-trivial. It may not be hard, either, except that for it to be > > reliable may require the bzr developers to make promises about internal > > storage management. > > A several months old bzr tree happens to be my playground for testing > VC changes on bzr. > I changed "delete_shelf" to always be True in bzrlib/shelf_ui.py, and > now "bzr unshelve --apply" does not remove shelves, and they seem to be > valid and can be applied multiple times. Exactly my findings. As unshelve essentially does a merge, I do not understand why what Stephen explains is relevant here. Furthermore, Bazaar allows having multiple shelves and unshelving them out-of-order. But I'm not an expert on this area either and possibly I'm missing something. BTW, coding the feature is trivial. Getting it into Bazaar is the difficult part. They have a slow, very stringent process for incorporating changes. They require to sign copyright papers too, something I did for Emacs but wont do for a private business. -- Óscar ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-04 2:57 ` Óscar Fuentes @ 2009-12-04 6:36 ` Stephen J. Turnbull 2009-12-04 21:18 ` Dan Nicolaescu 1 sibling, 0 replies; 57+ messages in thread From: Stephen J. Turnbull @ 2009-12-04 6:36 UTC (permalink / raw) To: Óscar Fuentes; +Cc: Dan Nicolaescu, emacs-devel Óscar Fuentes writes: > > I changed "delete_shelf" to always be True in bzrlib/shelf_ui.py, and > > now "bzr unshelve --apply" does not remove shelves, and they seem to be > > valid and can be applied multiple times. > > Exactly my findings. Well, if it works, it works. Good news! I had thought that bzr's implementation was like git's, but apparently it's more like a Mercurial queue. I apologize for the misinformation. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-04 2:57 ` Óscar Fuentes 2009-12-04 6:36 ` Stephen J. Turnbull @ 2009-12-04 21:18 ` Dan Nicolaescu 2009-12-04 21:59 ` Óscar Fuentes 1 sibling, 1 reply; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-04 21:18 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > "Stephen J. Turnbull" <stephen@xemacs.org> writes: > > > > > Dan Nicolaescu writes: > > > > > > > I know nothing about bzr, but unshelve --keep is gotta be trivial to > > > > implement... > > > > > > It's not, because the shelf is kept in the history. Unshelving needs > > > to rewind the history so that tip points to the pre-shelve revision. > > > bzr has no refs, so recovering the shelved revision after an unshelve > > > is non-trivial. It may not be hard, either, except that for it to be > > > reliable may require the bzr developers to make promises about internal > > > storage management. > > > > A several months old bzr tree happens to be my playground for testing > > VC changes on bzr. > > I changed "delete_shelf" to always be True in bzrlib/shelf_ui.py, and > > now "bzr unshelve --apply" does not remove shelves, and they seem to be > > valid and can be applied multiple times. > > Exactly my findings. > > As unshelve essentially does a merge, I do not understand why what > Stephen explains is relevant here. Furthermore, Bazaar allows having > multiple shelves and unshelving them out-of-order. But I'm not an expert > on this area either and possibly I'm missing something. > > BTW, coding the feature is trivial. Getting it into Bazaar is the > difficult part. They have a slow, very stringent process for > incorporating changes. They require to sign copyright papers too, > something I did for Emacs but wont do for a private business. Please don't give up. The change quite likely would not require copyright assignment: it's very small and it's probably the only way to implement the feature. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-04 21:18 ` Dan Nicolaescu @ 2009-12-04 21:59 ` Óscar Fuentes 2009-12-04 22:57 ` Dan Nicolaescu 2009-12-04 23:52 ` Glenn Morris 0 siblings, 2 replies; 57+ messages in thread From: Óscar Fuentes @ 2009-12-04 21:59 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: emacs-devel Dan Nicolaescu <dann@ics.uci.edu> writes: > Óscar Fuentes <ofv@wanadoo.es> writes: > > BTW, coding the feature is trivial. Getting it into Bazaar is the > > difficult part. They have a slow, very stringent process for > > incorporating changes. They require to sign copyright papers too, > > something I did for Emacs but wont do for a private business. > > Please don't give up. > The change quite likely would not require copyright assignment: it's > very small and it's probably the only way to implement the feature. They require copyright assignment even for one-liners. Contributing to Bazaar is difficult, they know it, and the developers are trying to alleviate the process. But in the end, Bazaar is a Canonical product and its development is guided by Canonical's business strategy. -- Óscar ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-04 21:59 ` Óscar Fuentes @ 2009-12-04 22:57 ` Dan Nicolaescu 2009-12-04 23:52 ` Glenn Morris 1 sibling, 0 replies; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-04 22:57 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > Óscar Fuentes <ofv@wanadoo.es> writes: > > > BTW, coding the feature is trivial. Getting it into Bazaar is the > > > difficult part. They have a slow, very stringent process for > > > incorporating changes. They require to sign copyright papers too, > > > something I did for Emacs but wont do for a private business. > > > > Please don't give up. > > The change quite likely would not require copyright assignment: it's > > very small and it's probably the only way to implement the feature. > > They require copyright assignment even for one-liners. Bummer, then maybe just describe the change you did and say that it works, that way someone else might be able to pick it up. Maybe Karl Fogel can help with this... ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-04 21:59 ` Óscar Fuentes 2009-12-04 22:57 ` Dan Nicolaescu @ 2009-12-04 23:52 ` Glenn Morris 2009-12-05 3:57 ` Stephen J. Turnbull ` (3 more replies) 1 sibling, 4 replies; 57+ messages in thread From: Glenn Morris @ 2009-12-04 23:52 UTC (permalink / raw) To: Óscar Fuentes; +Cc: Dan Nicolaescu, emacs-devel Óscar Fuentes wrote: > Contributing to Bazaar is difficult, they know it, and the developers > are trying to alleviate the process. But in the end, Bazaar is a > Canonical product and its development is guided by Canonical's business > strategy. It's also a GNU project. People ought to be able to feel confident about contributing to GNU projects. But when I had a quick look at the conditions for becoming one: http://www.gnu.org/help/evaluation.html I couldn't immediately see anything that would alleviate your worries. But, I'm not sure exactly what your worries are. While reading the conditions on that page, a first glance at the bzr 2.0.2 source shows: it is distributed under GPLv2+ rather than v3+, http://www.gnu.org/software/bzr does not exist, it does not have texinfo documentation, it contains numerous references to the "Linux" operating system, and there doesn't seem to be any reference in the --version output or man-page to it being a GNU project. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-04 23:52 ` Glenn Morris @ 2009-12-05 3:57 ` Stephen J. Turnbull 2009-12-05 6:49 ` Jan Djärv 2009-12-05 19:59 ` Glenn Morris ` (2 subsequent siblings) 3 siblings, 1 reply; 57+ messages in thread From: Stephen J. Turnbull @ 2009-12-05 3:57 UTC (permalink / raw) To: Glenn Morris; +Cc: Óscar Fuentes, Dan Nicolaescu, emacs-devel Glenn Morris writes: > I couldn't immediately see anything that would alleviate your worries. > But, I'm not sure exactly what your worries are. Simply that a patch will never be applied to the canonical Bazaar, thus making better support for shelve in vc.el dependent on the user having a patched bzr. The Bazaar project has an extremely strict and centralized (!) process, compared to which Emacs might well be considered an anarchy: 2 committers are required to approve each patch, and even the assignment policy is stricter (all contributions to the core, no matter how small, must be assigned -- third party plugins may remain the property of the developer, though). Until about three weeks ago, patches that didn't fit any of the committers' agendas tended to languish in the queue. They've long recognized that this is a problem, and after dithering for a bit have established a "patch pilot" program which is intended to guide 3rd party patches through the process. So far (less than a month of experience, but it's indicative) it's been very successful in getting doc and minor improvements through. However, changes in UI still tend to get stuck (for everybody, including the core committers) in bikeshedding. > While reading the conditions on that page, a first glance at the bzr > 2.0.2 source shows: it is distributed under GPLv2+ rather than v3+, > http://www.gnu.org/software/bzr does not exist, it does not have > texinfo documentation, it contains numerous references to the "Linux" > operating system, and there doesn't seem to be any reference in the > --version output or man-page to it being a GNU project. Nope, and Canonical management is pushing in the direction of emphasizing that it's a *Canonical product*: eg, all of the URLs are moving from "bazaar-vcs.org" to "bazaar.canonical.com". They got some pushback from the peanut gallery, but no committers seem to have a problem with that. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-05 3:57 ` Stephen J. Turnbull @ 2009-12-05 6:49 ` Jan Djärv 2009-12-05 7:12 ` Miles Bader 2009-12-05 12:09 ` Stephen J. Turnbull 0 siblings, 2 replies; 57+ messages in thread From: Jan Djärv @ 2009-12-05 6:49 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Óscar Fuentes, Dan Nicolaescu, emacs-devel Stephen J. Turnbull skrev: > Glenn Morris writes: > > > While reading the conditions on that page, a first glance at the bzr > > 2.0.2 source shows: it is distributed under GPLv2+ rather than v3+, > > http://www.gnu.org/software/bzr does not exist, it does not have > > texinfo documentation, it contains numerous references to the "Linux" > > operating system, and there doesn't seem to be any reference in the > > --version output or man-page to it being a GNU project. > > Nope, and Canonical management is pushing in the direction of > emphasizing that it's a *Canonical product*: eg, all of the URLs are > moving from "bazaar-vcs.org" to "bazaar.canonical.com". They got some > pushback from the peanut gallery, but no committers seem to have a > problem with that. > Does this mean that bazaar is no longer preferred, as the reason for that was that it was a GNU project? Can we now go for git instead? :-). Jan D. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-05 6:49 ` Jan Djärv @ 2009-12-05 7:12 ` Miles Bader 2009-12-05 16:12 ` Stefan Monnier 2009-12-05 12:09 ` Stephen J. Turnbull 1 sibling, 1 reply; 57+ messages in thread From: Miles Bader @ 2009-12-05 7:12 UTC (permalink / raw) To: Jan Djärv; +Cc: Fuentes, Stephen J. Turnbull, Dan Nicolaescu, emacs-devel Jan Djärv <jan.h.d@swipnet.se> writes: > Does this mean that bazaar is no longer preferred, as the reason for > that was that it was a GNU project? Can we now go for git instead? :-). It's still technically a GNU project AFAIK... though I'm surprised to hear canonical requires copyright assignment to themselves -- I sort of thought official GNU projects were all copyright FSF? [This sort of talk does tend to reinforce doubts I've always had about canonical's motivations for making it a GNU project, but I'm not sure what the practical effects of such practices are, other than being kind of annoying.] -Miles -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- Donald Knuth ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-05 7:12 ` Miles Bader @ 2009-12-05 16:12 ` Stefan Monnier 0 siblings, 0 replies; 57+ messages in thread From: Stefan Monnier @ 2009-12-05 16:12 UTC (permalink / raw) To: Miles Bader Cc: Fuentes, emacs-devel, Nicolaescu, Stephen J. Turnbull, Jan Djärv > It's still technically a GNU project AFAIK... though I'm surprised to > hear canonical requires copyright assignment to themselves -- I sort of > thought official GNU projects were all copyright FSF? No, some GNU packages require an FSF copyright assignment, but others don't require any assignment at all. The guidelines for being a GNU package are fairly loose, Stefan ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-05 6:49 ` Jan Djärv 2009-12-05 7:12 ` Miles Bader @ 2009-12-05 12:09 ` Stephen J. Turnbull 1 sibling, 0 replies; 57+ messages in thread From: Stephen J. Turnbull @ 2009-12-05 12:09 UTC (permalink / raw) To: Jan Djärv; +Cc: Óscar Fuentes, Dan Nicolaescu, emacs-devel Jan Djärv writes: > Does this mean that bazaar is no longer preferred, as the reason > for that was that it was a GNU project? Nothing has changed. The situation was acceptable then, why wouldn't it be now? > Can we now go for git instead? :-). You've always been able to go for git instead. It's a little bit annoying to manage a bidirectional gateway, but well worth it IM very personal O. To repeat: I don't recommend that for everybody, that's just the way I like it. And dVCS means I can dance to my own drumbeat, thank you very much! ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-04 23:52 ` Glenn Morris 2009-12-05 3:57 ` Stephen J. Turnbull @ 2009-12-05 19:59 ` Glenn Morris 2009-12-06 19:27 ` Richard Stallman 2009-12-10 0:16 ` support for bzr shelve/unshelve in vc-dir Martin Pool 3 siblings, 0 replies; 57+ messages in thread From: Glenn Morris @ 2009-12-05 19:59 UTC (permalink / raw) To: emacs-devel Glenn Morris wrote: > http://www.gnu.org/software/bzr does not exist http://www.gnu.org/software/bazaar exists, as a redirect. I should have checked properly. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-04 23:52 ` Glenn Morris 2009-12-05 3:57 ` Stephen J. Turnbull 2009-12-05 19:59 ` Glenn Morris @ 2009-12-06 19:27 ` Richard Stallman 2009-12-06 20:11 ` GNU bzr [was Re: support for bzr shelve/unshelve in vc-dir] Glenn Morris 2009-12-10 0:16 ` support for bzr shelve/unshelve in vc-dir Martin Pool 3 siblings, 1 reply; 57+ messages in thread From: Richard Stallman @ 2009-12-06 19:27 UTC (permalink / raw) To: Glenn Morris; +Cc: ofv, dann, emacs-devel texinfo documentation, it contains numerous references to the "Linux" operating system, and there doesn't seem to be any reference in the --version output or man-page to it being a GNU project. Can you tell me the precise URLs where it talks about the "Linux" system? ^ permalink raw reply [flat|nested] 57+ messages in thread
* GNU bzr [was Re: support for bzr shelve/unshelve in vc-dir] 2009-12-06 19:27 ` Richard Stallman @ 2009-12-06 20:11 ` Glenn Morris 2009-12-09 13:20 ` Richard Stallman 0 siblings, 1 reply; 57+ messages in thread From: Glenn Morris @ 2009-12-06 20:11 UTC (permalink / raw) To: rms; +Cc: emacs-devel Richard Stallman wrote: > Can you tell me the precise URLs where it talks about the "Linux" system? I was talking about the source tar ball for the latest bzr release. http://launchpad.net/bzr/2.0/2.0.2/+download/bzr-2.0.2.tar.gz Simply download, extract, and `grep -r Linux'. A selection of matches: INSTALL: When installing bzr you need the ability to build C extensions. Some Linux distributions package the necessary headers separately from the main Python package. NEWS: * On Linux bzr additionally looks for plugins in arch-independent site directory. (Toshio Kuratomi) doc/en/user-guide/installing_bazaar.txt: Linux ----- Bazaar packages are available for most popular Linux distributions including Ubuntu/Debian, Red Hat and Gentoo. See http://bazaar-vcs.org/Download for the latest instructions. Other operating systems ----------------------- Beyond Linux and Windows, Bazaar packages are available for a large range of other operating systems... ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: GNU bzr [was Re: support for bzr shelve/unshelve in vc-dir] 2009-12-06 20:11 ` GNU bzr [was Re: support for bzr shelve/unshelve in vc-dir] Glenn Morris @ 2009-12-09 13:20 ` Richard Stallman 2009-12-09 16:50 ` GNU bzr Karl Fogel 0 siblings, 1 reply; 57+ messages in thread From: Richard Stallman @ 2009-12-09 13:20 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel Thanks for that info about the problems in BZR. It will be another couple of weeks, probably, before I can bring it up with them, but I will. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: GNU bzr 2009-12-09 13:20 ` Richard Stallman @ 2009-12-09 16:50 ` Karl Fogel 2009-12-15 23:11 ` Karl Fogel 0 siblings, 1 reply; 57+ messages in thread From: Karl Fogel @ 2009-12-09 16:50 UTC (permalink / raw) To: rms; +Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > Thanks for that info about the problems in BZR. > > It will be another couple of weeks, probably, before I can bring it up > with them, but I will. I will bring it up with them today. -Karl ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: GNU bzr 2009-12-09 16:50 ` GNU bzr Karl Fogel @ 2009-12-15 23:11 ` Karl Fogel 0 siblings, 0 replies; 57+ messages in thread From: Karl Fogel @ 2009-12-15 23:11 UTC (permalink / raw) To: Karl Fogel; +Cc: rms, emacs-devel Karl Fogel <karl.fogel@canonical.com> writes: > Richard Stallman <rms@gnu.org> writes: >> Thanks for that info about the problems in BZR. >> >> It will be another couple of weeks, probably, before I can bring it up >> with them, but I will. > > I will bring it up with them today. By the way, I did ask, and it appears there wasn't any conscious decision not to use "GNU/Linux". It's just that there hasn't been much centralized editorial control over the docs, so they get written by whoever writes them. I take that to mean that patches would be welcome. -Karl ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-04 23:52 ` Glenn Morris ` (2 preceding siblings ...) 2009-12-06 19:27 ` Richard Stallman @ 2009-12-10 0:16 ` Martin Pool 2009-12-10 3:46 ` Stefan Monnier 2009-12-10 14:02 ` Dan Nicolaescu 3 siblings, 2 replies; 57+ messages in thread From: Martin Pool @ 2009-12-10 0:16 UTC (permalink / raw) To: emacs-devel On Fri, 04 Dec 2009 18:52:04 -0500, Glenn Morris wrote: > Óscar Fuentes wrote: > >> Contributing to Bazaar is difficult, they know it, and the developers >> are trying to alleviate the process. But in the end, Bazaar is a >> Canonical product and its development is guided by Canonical's business >> strategy. It's guided by Canonical, since they fund a lot of development, but also by the patches and proposals that people put up, including non-Canonical people and employees in their personal or discretionary time. Other GNU projects have been like this. We had got into a pattern of being two conservative and we are indeed trying to make it easier. If you think it's too tough to get a patch in, please tell me or tell Karl. > It's also a GNU project. People ought to be able to feel confident about > contributing to GNU projects. But when I had a quick look at the > conditions for becoming one: > > http://www.gnu.org/help/evaluation.html > > I couldn't immediately see anything that would alleviate your worries. > But, I'm not sure exactly what your worries are. > While reading the conditions on that page, a first glance at the bzr > 2.0.2 source shows: it is distributed under GPLv2+ rather than v3+, > http://www.gnu.org/software/bzr does not exist, it does not have texinfo > documentation, We talked about texinfo documentation at the time of accession to GNU. I understand the value in having every GNU program consistent but texinfo is not very technically easy given our platform and the technical environment of 2009, and in my opinion not a good use of time. However, if someone has an idea by which we can for example produce texinfo as an output, we will look at it. We also don't use automake because it is not a good match for Python, and we don't use GUILE. The document mixes technical recommendations with more long-term issues. > it contains numerous references to the "Linux" operating > system, Apparently Richard will be in touch about this. > and there doesn't seem to be any reference in the --version > output or man-page to it being a GNU project. There are references in the documentation and on the web site, but possibly not enough. I thought I had fixed --version already, but it will be fixed now. These are just bugs. Reports or patches are always welcome. -- /home/mbp/.signature ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-10 0:16 ` support for bzr shelve/unshelve in vc-dir Martin Pool @ 2009-12-10 3:46 ` Stefan Monnier 2009-12-10 4:19 ` Martin Pool 2009-12-10 14:02 ` Dan Nicolaescu 1 sibling, 1 reply; 57+ messages in thread From: Stefan Monnier @ 2009-12-10 3:46 UTC (permalink / raw) To: Martin Pool; +Cc: emacs-devel > We talked about texinfo documentation at the time of accession to GNU. > I understand the value in having every GNU program consistent but > texinfo is not very technically easy given our platform and the > technical environment of 2009, and in my opinion not a good use > of time. I have no idea what you're referring to. We all know that Texinfo is not as sexy as HTML and has its share of shortcomings, but it does its job fairly well and has several features still mostly unmatched by any other format (especially when accessed via an Info viewer such as the one in Emacs). I think the question shouldn't be "should we do provide Texinfo", but "how are we going to do it". > However, if someone has an idea by which we can for example produce > texinfo as an output, we will look at it. Not knowing exactly how you generate your documentation, it's hard for me to help, but at least if you can generate docbook output (which you supposedly can from ReST), you can pass it on to docbook2x to get Texinfo output. Or maybe Pandoc can do it better straight from ReST to Texinfo. Stefan ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-10 3:46 ` Stefan Monnier @ 2009-12-10 4:19 ` Martin Pool 0 siblings, 0 replies; 57+ messages in thread From: Martin Pool @ 2009-12-10 4:19 UTC (permalink / raw) To: emacs-devel On Wed, 09 Dec 2009 22:46:46 -0500, Stefan Monnier wrote: >> We talked about texinfo documentation at the time of accession to GNU. >> I understand the value in having every GNU program consistent but >> texinfo is not very technically easy given our platform and the >> technical environment of 2009, and in my opinion not a good use of >> time. > > I have no idea what you're referring to. We all know that Texinfo is > not as sexy as HTML and has its share of shortcomings, but it does its > job fairly well and has several features still mostly unmatched by any > other format (especially when accessed via an Info viewer such as the > one in Emacs). We've talked about this before, including in the bazaar list thread "Printable Documentation" in January this year, and in <https:// bugs.edge.launchpad.net/bzr/+bug/219334> (filed by Stefan.) Let's discuss the practicalities in that bug not on the emacs list. > I think the question shouldn't be "should we do provide Texinfo", but > "how are we going to do it". I agree we should, it is just a question of someone getting around to doing the research and making a patch. Regardless of GNU-ness, there are people who find it convenient to read their documentation inside Info and we'd like to help them. -- Martin ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-10 0:16 ` support for bzr shelve/unshelve in vc-dir Martin Pool 2009-12-10 3:46 ` Stefan Monnier @ 2009-12-10 14:02 ` Dan Nicolaescu 2009-12-11 4:02 ` Martin Pool 2009-12-11 5:53 ` Martin Pool 1 sibling, 2 replies; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-10 14:02 UTC (permalink / raw) To: Martin Pool; +Cc: emacs-devel Martin Pool <mbp@sourcefrog.net> writes: > On Fri, 04 Dec 2009 18:52:04 -0500, Glenn Morris wrote: > > > Óscar Fuentes wrote: > > > >> Contributing to Bazaar is difficult, they know it, and the developers > >> are trying to alleviate the process. But in the end, Bazaar is a > >> Canonical product and its development is guided by Canonical's business > >> strategy. > > It's guided by Canonical, since they fund a lot of development, but also > by the patches and proposals that people put up, including non-Canonical > people and employees in their personal or discretionary time. Other GNU > projects have been like this. > > We had got into a pattern of being two conservative and we are indeed > trying to make it easier. If you think it's too tough to get a patch in, > please tell me or tell Karl. This discussion started in part because of the perceived difficulty of getting a patch integrated to implement "bzr unshelve --keep" (https://bugs.launchpad.net/bzr/+bug/492091) bzr shelves are not very usable without this option, you can't go back and forth between shelved versions. The patch would change bzrlib/shelf_ui.py:Unshelver.from_args to set delete_shelf to False when "--keep" is passed. So about 3 lines total. Would such a patch need copyright assignment? Even if it does, given the above description, a bzr developer can reproduce the change needed in a few seconds... Can you please help get this solved? ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-10 14:02 ` Dan Nicolaescu @ 2009-12-11 4:02 ` Martin Pool 2009-12-18 15:39 ` Dan Nicolaescu 2009-12-11 5:53 ` Martin Pool 1 sibling, 1 reply; 57+ messages in thread From: Martin Pool @ 2009-12-11 4:02 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: emacs-devel 2009/12/11 Dan Nicolaescu <dann@ics.uci.edu>: > This discussion started in part because of the perceived difficulty of > getting a patch integrated to implement "bzr unshelve --keep" > (https://bugs.launchpad.net/bzr/+bug/492091) I would be the first to agree that we have made it too hard to get changes in in the past, and that while we are doing better now we can still do more. However, I can't find any history with this particular request, just a recently-filed bug? > bzr shelves are not very usable without this option, you can't go back > and forth between shelved versions. > The patch would change bzrlib/shelf_ui.py:Unshelver.from_args to set > delete_shelf to False when "--keep" is passed. So about 3 lines total. > > Would such a patch need copyright assignment? > Even if it does, given the above description, a bzr developer can > reproduce the change needed in a few seconds... > Can you please help get this solved? Yes, it would need copyright assignment. We do this on every patch because our legal opinion said that there is no globally-recognized concept of "too small to copyright", and because we want to have clear copyright. Many developers, both at Canonical and otherwise, have given feedback that they think the FSF approach of saying "about a paragraph" (or whatever it precisely is) is a reasonable commonsense tradeoff.. I'll have a look at doing this. Thanks for looking into it. -- Martin <http://launchpad.net/~mbp/> ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-11 4:02 ` Martin Pool @ 2009-12-18 15:39 ` Dan Nicolaescu 2009-12-21 1:49 ` Martin Pool 0 siblings, 1 reply; 57+ messages in thread From: Dan Nicolaescu @ 2009-12-18 15:39 UTC (permalink / raw) To: Martin Pool; +Cc: emacs-devel Martin Pool <mbp@canonical.com> writes: > 2009/12/11 Dan Nicolaescu <dann@ics.uci.edu>: > > This discussion started in part because of the perceived difficulty of > > getting a patch integrated to implement "bzr unshelve --keep" > > (https://bugs.launchpad.net/bzr/+bug/492091) > > I would be the first to agree that we have made it too hard to get > changes in in the past, and that while we are doing better now we can > still do more. However, I can't find any history with this particular > request, just a recently-filed bug? I don't think that's the whole history here. > > bzr shelves are not very usable without this option, you can't go back > > and forth between shelved versions. > > The patch would change bzrlib/shelf_ui.py:Unshelver.from_args to set > > delete_shelf to False when "--keep" is passed. So about 3 lines total. > > > > Would such a patch need copyright assignment? > > Even if it does, given the above description, a bzr developer can > > reproduce the change needed in a few seconds... > > Can you please help get this solved? > > Yes, it would need copyright assignment. We do this on every patch > because our legal opinion said that there is no globally-recognized > concept of "too small to copyright", and because we want to have clear > copyright. Many developers, both at Canonical and otherwise, have > given feedback that they think the FSF approach of saying "about a > paragraph" (or whatever it precisely is) is a reasonable commonsense > tradeoff.. FYI: the FSF policy is to require a copyright assignment from someone that submits a number of small patches, so it's not possible to work around the copyright requirement by splitting a larger change into many smaller ones. It looks like bzr unshelve --keep will make it into the next version, thanks for taking care of it! ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-18 15:39 ` Dan Nicolaescu @ 2009-12-21 1:49 ` Martin Pool 0 siblings, 0 replies; 57+ messages in thread From: Martin Pool @ 2009-12-21 1:49 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: emacs-devel 2009/12/19 Dan Nicolaescu <dann@ics.uci.edu>: > FYI: the FSF policy is to require a copyright assignment from someone > that submits a number of small patches, so it's not possible to work > around the copyright requirement by splitting a larger change into many > smaller ones. OK, noted. > It looks like bzr unshelve --keep will make it into the next version, > thanks for taking care of it! In fact it's in bzr 2.1b4 <https://edge.launchpad.net/bzr/+milestone/2.1.0b4> released last week. 2.1 will have its final release in February next year but it's quite ok to use now. If you think anything else is stalling or needs help, don't hesitate to ask. I know there is one more request there about just showing the diff (not applying it) for which someone is being mentored iirc. -- Martin ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: support for bzr shelve/unshelve in vc-dir 2009-12-10 14:02 ` Dan Nicolaescu 2009-12-11 4:02 ` Martin Pool @ 2009-12-11 5:53 ` Martin Pool 1 sibling, 0 replies; 57+ messages in thread From: Martin Pool @ 2009-12-11 5:53 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: emacs-devel 2009/12/11 Dan Nicolaescu <dann@ics.uci.edu>: > This discussion started in part because of the perceived difficulty of > getting a patch integrated to implement "bzr unshelve --keep" > (https://bugs.launchpad.net/bzr/+bug/492091) > bzr shelves are not very usable without this option, you can't go back > and forth between shelved versions. > The patch would change bzrlib/shelf_ui.py:Unshelver.from_args to set > delete_shelf to False when "--keep" is passed. So about 3 lines total. > > Would such a patch need copyright assignment? > Even if it does, given the above description, a bzr developer can > reproduce the change needed in a few seconds... > Can you please help get this solved? It's now up for review at <https://code.edge.launchpad.net/~mbp/bzr/492091-unshelve-keep/+merge/16001>. (You can review it if you have or make a Launchpad account.) I expect it will be in our December 2.1b4. -- Martin <http://launchpad.net/~mbp/> ^ permalink raw reply [flat|nested] 57+ messages in thread
end of thread, other threads:[~2009-12-21 1:49 UTC | newest] Thread overview: 57+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-12-01 19:47 support for bzr shelve/unshelve in vc-dir Dan Nicolaescu 2009-12-01 20:48 ` Xavier Maillard 2009-12-02 5:43 ` Dan Nicolaescu 2009-12-02 6:37 ` Óscar Fuentes 2009-12-01 22:11 ` Stefan Monnier 2009-12-01 22:50 ` Óscar Fuentes 2009-12-01 23:18 ` Óscar Fuentes 2009-12-02 3:00 ` Dan Nicolaescu 2009-12-02 3:03 ` Dan Nicolaescu 2009-12-02 3:31 ` Óscar Fuentes 2009-12-02 4:35 ` Stefan Monnier 2009-12-02 5:06 ` Óscar Fuentes 2009-12-02 6:16 ` Stephen J. Turnbull 2009-12-02 6:42 ` Óscar Fuentes 2009-12-03 7:48 ` Dan Nicolaescu 2009-12-03 8:25 ` Óscar Fuentes 2009-12-03 8:32 ` Bojan Nikolic 2009-12-03 9:07 ` Dan Nicolaescu 2009-12-03 17:05 ` Splitting changes (was: support for bzr shelve/unshelve in vc-dir) Stefan Monnier 2009-12-03 17:46 ` Eli Zaretskii 2009-12-03 19:26 ` Splitting changes Stefan Monnier 2009-12-03 19:47 ` Óscar Fuentes 2009-12-03 20:50 ` Stefan Monnier 2009-12-03 17:24 ` support for bzr shelve/unshelve in vc-dir Óscar Fuentes 2009-12-03 18:18 ` Óscar Fuentes 2009-12-03 18:48 ` Dan Nicolaescu 2009-12-03 19:00 ` Óscar Fuentes 2009-12-03 19:17 ` Dan Nicolaescu 2009-12-03 21:30 ` Óscar Fuentes 2009-12-03 22:57 ` Dan Nicolaescu 2009-12-04 0:42 ` Stephen J. Turnbull 2009-12-04 1:47 ` Dan Nicolaescu 2009-12-04 2:57 ` Óscar Fuentes 2009-12-04 6:36 ` Stephen J. Turnbull 2009-12-04 21:18 ` Dan Nicolaescu 2009-12-04 21:59 ` Óscar Fuentes 2009-12-04 22:57 ` Dan Nicolaescu 2009-12-04 23:52 ` Glenn Morris 2009-12-05 3:57 ` Stephen J. Turnbull 2009-12-05 6:49 ` Jan Djärv 2009-12-05 7:12 ` Miles Bader 2009-12-05 16:12 ` Stefan Monnier 2009-12-05 12:09 ` Stephen J. Turnbull 2009-12-05 19:59 ` Glenn Morris 2009-12-06 19:27 ` Richard Stallman 2009-12-06 20:11 ` GNU bzr [was Re: support for bzr shelve/unshelve in vc-dir] Glenn Morris 2009-12-09 13:20 ` Richard Stallman 2009-12-09 16:50 ` GNU bzr Karl Fogel 2009-12-15 23:11 ` Karl Fogel 2009-12-10 0:16 ` support for bzr shelve/unshelve in vc-dir Martin Pool 2009-12-10 3:46 ` Stefan Monnier 2009-12-10 4:19 ` Martin Pool 2009-12-10 14:02 ` Dan Nicolaescu 2009-12-11 4:02 ` Martin Pool 2009-12-18 15:39 ` Dan Nicolaescu 2009-12-21 1:49 ` Martin Pool 2009-12-11 5:53 ` Martin Pool
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).