I am maintainer of a CPAN distribution whose most recent official release is version 2.12.
Since 2.12 was published, we have made the following development releases:
2.12_001
2.12_002
2.12_003
2.12_004
In the git repository, we have tags for:
2.12_002
2.12_003
2.12_004
(Somehow 2.12_001 was overlooked or has not yet been set.)
I now realize that much of the code (mostly tests, but some source) added in 2.12_003 and 2.12_004 is conceptually flawed. For other developers and myself to treat 2.12_004 as the starting point for future development would not be fruitful.
What I would like to do is to go back to 2.12_002 and start development anew from there -- but without pretending that 2.12_003 and 2.12_004 were never released. I would like 2.12_005 to be equivalent to 2.12_002 but with only very safe, minor touchups.
Would the following be the recommended sequence of git commands?
$ git checkout master
$ git checkout -b start-anew
$ git reset --soft 2.12_002
$ git commit -m "Rewind to tag 2.12_002"
# hack, hack, hack
$ git add ...
$ git commit -m "Slight touchups to what was 2.12_002"
$ git checkout master
$ git merge start-anew
$ git tag "2.12_005"
Thank you very much.
|
Re: [OT] What is best practice for 'git reset'? (updated)
by haukex (Archbishop) on Apr 20, 2017 at 13:46 UTC
|
Not a git expert, but a quick test seemed to show me that git reset --soft 2.12_002 will leave the changes from the newer versions in the index, I don't think that's what you want, because a commit afterwards would put those changes back into the repo.
If you want to begin your work with a commit that undoes all the changes since 2.12_002, the following seems to work, even directly on master.
git revert --no-commit 2.12_002..
git commit -m "Rewind to tag 2.12_002"
# continue work here
Another approach might be to base the new branch on 2.12_002 and then later merge that branch back into master, clobbering all the changes in master at the same time auto-resolving all conflicting hunks by favoring the start-anew branch. (Update 2: Changed wording of the previous sentence after re-reading the git-merge docs. This is a significant difference because changes in the master branch that don't conflict will still be reflected into the merge result! Perhaps the "ours" instead of "recursive" merge strategy might be better for clobbering, untested. If in doubt, use the above solution instead!)
git checkout -b start-anew 2.12_002
# - make edits here -
git checkout master
git merge -s recursive -X theirs \
-m 'Merge branch "start-anew" (based on 2.12_002)' \
start-anew
git branch -d start-anew
git log --oneline --decorate --graph
Update: Here's how I generated the fake repo for testing:
Update 2017-04-21: Just noticed this cross-posting to perl.module-authors. Also, it appears we're talking about File::Path version 2.12_004 (GitHub). | [reply]
[d/l]
[select] |
Re: [OT] What is best practice for 'git reset'?
by shmem (Chancellor) on Apr 20, 2017 at 12:06 UTC
|
I would mark this question as [OT] (off-topic), nonwithstanding that the repository holds a CPAN module (which one?). This is a git question, so perl wisdom doesn't apply.
That being said, you git sequence looks sensible to me. But I am far from being a "git expert".
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] |
Re: What is best practice for 'git reset'?
by Mr. Muskrat (Canon) on Apr 21, 2017 at 15:43 UTC
|
| [reply] |
