Bug 3362 - hg graft should support -b X for "branch(X)"
Summary: hg graft should support -b X for "branch(X)"
Status: RESOLVED ARCHIVED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: unspecified
Hardware: All All
: wish feature
Assignee: Bugzilla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-10 03:05 UTC by Alexander Becher
Modified: 2014-07-31 13:23 UTC (History)
3 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Becher 2012-04-10 03:05 UTC
It would be nice if the graft command supported the -b option as a shortcut
for selecting all changesets on a specific branch, like allowed by hg log.

Note that the following entry in hgrc works quite nicely:

[alias]
graftb = graft "branch($1)"
Comment 1 Matt Mackall 2012-04-10 08:26 UTC
Revsets exist precisely so we don't need to add dozens of selection options
to each command.
Comment 2 Alexander Becher 2012-04-11 09:36 UTC
Agreed. I see that indeed only log, incoming and outgoing seem to support -b.

Maybe it is enough to add a sentence like this to graft --help:

    To copy all changes from a branch to the current branch, specify
    "branch(X)" as the REVISION argument.

And/or maybe add a reference to revsets, like the one in log --help:

    See "hg help revisions" and "hg help revsets" for more about specifying
    revisions.

Sometimes I still get confused when a branch name refers to the tip on that
branch, to all changesets in a branch, or to all changes since the last
common predecessor revision. A reminder like the above could help.
Comment 3 Matt Mackall 2012-04-11 09:39 UTC
I don't think we want to document that particular use case. In general, if
you want to import _all_ the changes from a branch, you want merge instead
of graft.
Comment 4 Alexander Becher 2012-04-12 01:31 UTC
Merge is not really useful for backporting. I should probably elaborate a
bit on the reasons for that use case.

Consider a typical project with released versions 1.0 and 2.0, and the next
version 3.0 in active development. Assume their repository structure uses a
single repository with named branches v1, v2, and the default branch.

Now someone finds and fixes a bug on the v2 branch. Assume the bugfix is
complicated, and so comprises several commits on a separate branch, say,
bug_123. The developer merges his bugfix branch into the v2 and default
branches, and everything is well. Some time later, someone realises that
version 1.0 is also affected by that bug, and decides to backport the fix
from the bug_123 branch.

In that situation, merge is unhelpful: It would merge not only the changes
on the bug_123 branch, but also all their ancestors on the v2 branch, which
is its job. Here, graft comes to the rescue: It saves the developer from
using diff+patch or manually porting the changes.

Is that use case so unusual?

I independently uphold the proposal to add a reference to revsets to the
help message of graft. Should we split this issue in two?
Comment 5 Bugzilla 2012-05-12 09:29 UTC

--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:29 EDT  ---

This bug was previously known as _bug_ 3361 at http://mercurial.selenic.com/bts/issue3361
Comment 6 Matt Mackall 2014-07-25 17:23 UTC
Bulk close: no activity for >2 years -> WONTFIX
Comment 7 Matt Mackall 2014-07-31 13:23 UTC
Bulk change recent WONTFIX -> new, more descriptive ARCHIVED state (sorry for the spam)