But make sure that the ONLY difference between the tagged version with the functionality and the next commit is the removal. Don't pretty the code, don't correct one typo, don't do ANYTHING but remove files.
If, you have to do anything in addition to removing files, I would do that stuff in the first commit after the tag, the removals in a second commit and I'd take all three with something like: FUNCTIONALITY_A_WORKS FUNCTIONALITY_A_CODED_OUT FUNCTIONALITY_A_FILES_REMOVED On Tue, Sep 27, 2016 at 8:41 AM, Konstantin Khomoutov < [email protected]> wrote: > On Tue, 27 Sep 2016 15:29:07 +0300 > Konstantin Khomoutov <[email protected]> wrote: > > > > I have a client that wishes to have some functionality removed from > > > a website that I'm building but I'm not totally convinced they won't > > > want the functionality added back to the site at a later date. > > > > > > Is there a way to handle this type of situation with git? Basically > > > deleting code in one commit then easily finding that code again in > > > the future (potentially months or years from now) to either restore > > > or use as a reference for reimplementing it if the site has changed > > > to much for it to be directly restored. > > > > > > I realise in code I can use if an if statement, comment it out or > > > various other ways to achieve this but I wanted to see if it can be > > > handled just with git as retrieving previously deleted code seems > > > like the find of thing a VCS should be better at handling. > > > > You can roll like this: > > > > 1. Attach an annotated tag to the top (last) commit containing the > > change the client wants to be removed. > > > > Give it a meaningful name and in the annotation, explain clearly > > what this tag is about. > > > > 1. Remove the offending change. > > > > Either to it by hand, or, if that change was specifically > > introduced by a commit or a series of commits, you can use `git > > revert` which records a new commit which textually undoes the > > specified changes. > > > > When the client wants their feaure back, you can easily find it by > > that tag. > > > > Getting it back would amount to cherry-picking the change of that > > tagged commit. If the change spans several commits, you could > > cherry-pick all of them. > > > > If you did `git revert`, it's possible to `git revert` the revert > > commit itself -- which effectively brings the reverted changes back. > > Oh, and also consider that you can easily search through the commit > log, so even creating a tag is not necessary: you will be able to find > your commit reverting the change either by certain key words in its > message or even by code changes (see the "-S", "-G" and "--pickaxe-*" > command-line options to `git log`). > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Matthew O. Persico -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
