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

First of all, 1000 thanks and please forgive me for the broken thread, I was
not subscribed to the list before so I did a copy-and-paste from the web
archive. 

Junio C. Hamano wrote:
> 
> 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 understood perfectly. I called them "dead" because really I do
not think to come back to them ever, but I want to maintain that as "old
story", something of the style "that was an error, store it so that you will
never fall in it again". 
> 
> 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.
>

What I have done (and it seems to work perfectly) is 

    git checkout master
    mkdir .git/refs/olds 
    mv .git/heads/test-bill-idea .git/olds

and it seems to work ok. Thanks! 

    
>         - 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
> 

Thanks. I will play a bit with it. I sometime have a bit of fear to not
being able to come back to a good state. I will do my homework and study a
bit more git checkout, branch and reset (this latter gives me a bit of
headheache last time... ;-) ).

Thanks a lot. 
          
-- 
Romano Giannetti             -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 596 569
http://www.dea.icai.upcomillas.es/romano/
-
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