Re: Two newbie question: "dead" branches and merging after cherry-pick.

> 
> You are done with what you did in the branch for now, but you
> have not merged the work to your day-to-day development "master"
> for some reason.  In the meantime you would want to switch to
> other topic branches to work on other topics, and while working
> on them you do not want to "git branch" and "git show-branch" to
> show the topic you are done with but not merged yet.  Later you
> would want to come back to it to do some interesting stuff with
> it (maybe finally merge into "master", or format-patch to send
> upstream).  Is that what is happening here?
> If so, I would have chosen "postponed" not "dead" to describe
> the situation but you said "dead" and that is why I am wondering
> if I am getting you correctly.

> 
> Yes.  You have the tag under .git/refs which points at the tip
> of that postponed branch head, so the development trail will not
> be lost.  When you are done with other topics and would want to
> come back to that topic again, you could do this:
> 

>     $ git tag hold/jc/gitlink jc/link ;# copy it to tags/
>        $ git branch -D jc/link             ;# delete it from heads/
> 
> Now "git branch" would not show it, but "gitk --all" still would.
>

>         - Easier: suppose I cheery-picked "abababab" from branch "testing"
>         to master branch. What will happen if later I decide to merge
>         all "testing" to master branch? I will have a merge conflict (trying
>         to apply two times the same fix) or not? 
> 
> This is easy to experiment so I'd suggest you to try it and tell
> us what you see, like this:
> 
>   $ git checkout -b test-merge-throwaway master
>        $ git cherry-pick abababab
>        $ ... play with it, maybe making a couple of commits
>        $ git pull . testing
> 
> I would not be surprised if this resolves cleanly. If abababab
> is the only thing that touches the set of paths it touches,
> other than what are in "testing" and what you did since
> "testing" forked from "master", it is likely that the merge
> would resolve cleanly.
> 
> Otherwise you would likely to see conflicts --- in which case
> you may want to suggest if/how we can reduce it.  "cherry-pick"
> without -r drops a hint of which commit was picked in the commit
> log so it _might_ be a good idea to teach git to optionally take
> that information into account while doing the merge.  I dunno.
> 
> Once you are done experimenting, you can come back to master and
> delete the test-merge-throwaway branch:
> 
>       $ git checkout master
>        $ git branch -D test-merge-throwaway
>