Currently, tag.sh has a side effect where the branch it leaves your checkouts in is not the same branch your checkouts were in when it found them. This has a negative effect because typically after running tag.sh, you will start a non-scratch build using ./builder.py which assumes your checkouts are on the branch you want to build. This caused me to submit an old version to koji which failed. expected behavior: I expect that after running tag.sh pulp, pulp_puppet, and pulp_rpm are all on the same branch they started on. How to Reproduce: 1. checkout pulp, pulp_rpm, pulp_puppet in the same directory. 2. Switch all of them to the pulp-2.4 branch 3. Run the tagging script using `./pulp/tag.sh -ab pulp-2.4` 4. Answer Y when it asks if you want to ensure everything is on pulp-2.4 5. Answer Y to all commit questions 6. Observe tagging script finishes 7. Observe that the pulp, pulp_puppet, and pulp_rpm checkouts are all on master!
Is this bug reproducible? I've never noticed tag.sh checking out master when I build before.
I bet this is reproducable, but since it auto pushes the tag to the real repos I didn't want to run it. The next time tag.sh is actually used it would be good to observe the branch result from the tag.sh script. I read through tag.sh and it seems that it does 3 things for each root: 1. ensure the branch of interest is checked out with the latest 2. tag with tito 3. merge into the parent branch which defaults to master or the specified parent It seems that the last thing tag.sh does is merge forward the branch into the parent. It's important to merge forward, but we do that anyway for all of our other commits. I figure tag.sh would just tag and make sure it tags the right thing and that is all. Chris and Randy, do you think we should remove the merge forward step from tag.sh?
Yeah, but I also think we should just remove tag.sh since we are moving away from lock stepping our repos.
tag.sh is going to be removed soon (likely this sprint). This bug should no longer even be relevant.