Junio C Hamano wrote:I agree with this, though I can see the motivation (for example that git-patch-id, and hence git-cherry, often do not work because of context changes). This thread, however, spurred one observation and a question. Observation: it seems to me that cherry-picking and merging are mutually exclusive workflows. You cherry-pick from a development branch to a stable branch, you merge or rebase in the other direction. Is this true in general? (I can see the obvious exception: you might cherry-pick that very important bugfix, if you're not ready to do a full merge; but if you rebase, that commit will go away as soon as you do it). Question: how are topic branches managed in git.git? In particular, how are "graduations to master" done? Do you cherry-pick the merge commit that went into "next"? Paolo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Eric W. Biederman | [PATCH 02/10] sysfs: Support for preventing unmounts. |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Linus Torvalds | Re: LSM conversion to static interface |
git: | |
| Antonio Almeida | HTB accuracy for high speed |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 18/37] dccp: Support for Mandatory options |
| Timo Teräs | Re: xfrm_state locking regression... |
