I have forked a repo and branched that clone to code a story, and because I didn't understand the problem, wrote code that isn't solving my task at hand, but may prove useful later.

Should I:

  1. Delete it, and don't worry about it. Then commit without the extra code.
  2. Make yet another branch for just that work, commit it, but don't post a pull request on it.
  3. Just commit it with the existing code, and worry about the extra "fluff" later.

I was thinking #2. If I understand correctly, I could just keep the extra code on a branch I never use on my clone, and dig it up later if something comes up that may benefit from using it.

  • What do you want? Do you want to keep it? Is there something in there that you really might need? Voting to close because you are truly the only one who can correctly answer the question.
    – Caleb
    Nov 28 '12 at 22:40
  • Read Micheal's answer. He added something of value that I wouldn't have considered otherwise.
    – Droogans
    Nov 28 '12 at 22:46
  • Does anyone here who speaks both Git and TFS speak to what Git's version of the TFS shelveset is? This is exactly the kind of thing I have long used shelvesets for when requirements change underneath me. Nov 28 '12 at 23:05
  • @JimmyHoffa: The equivalent is stash, but it only works on the current repository (ie. locally). If you want to do the same thing and push it to a central repo, you'd use a branch.
    – pdr
    Nov 28 '12 at 23:58

You should have included option number 4....

4.  Commit it with the extra code, and then delete it and commit it again.

If you don't commit it, it is lost. If you commit it and leave it in, then you have an extra source of confusion -- you should try to avoid having other people scratching their heads and wondering WTF is going on here...

Commit it, delete it, commit it again -- add a couple of good commit comments and you're golden.

  • +1 unless someone can come up with an explanation of their version of a shelveset which exists in Git, perhaps just creating a new repository and committing those changes to it but never pushing them.. Nov 28 '12 at 23:20
  • Not a bad idea, however you assume that a) You remember you had it, and B) you remember where to find it. If the team is bigger than 1, you need to tell everyone else it's there just in case they get the job that needs it, and hope they can remember and find the code. Starts adding up to my experience -a) it rarely gets used, b) When it is, it's so old and unmaintained its a liability and c) the problem it solves is not quite the same problem you need to solve now.
    – mattnz
    Nov 29 '12 at 1:31
  • 1
    @mattnz: no, I assume that you MIGHT remember it and or be able to find it based upon comments in the commit log/bug tracker. Loosing it in the history is no worse than never committing or putting it into another branch and then forgetting about that. As for it being out of date -- better that than time spent maintaining something that was never used. And if it doesn't solve the problem you need to solve now, then don't use it.
    – jmoreno
    Nov 29 '12 at 1:59
  • This is exactly what I ended up doing as I thought about it.
    – Droogans
    Nov 29 '12 at 2:07
  • 2
    -1 this just makes the history harder to follow. If you're doing a git bisect, for example, you could end up with a range of commits which includes this code which was written and then deleted. Why not put it in a separate branch? Give the branch a name starting with 'obsolete_' if you want, but don't pollute the history of your main development branch with code you don't intend to use. I would vote for the OP's option #2.
    – MatrixFrog
    Nov 29 '12 at 4:04

Option #2 is legitimate if the code really could be useful later on. #3 is not the right answer.

Option #1 is probably the right answer. More often than not, the code should just be scrapped. As programmers, we don't like to delete code--if feels like throwing out our babies. One of the biggest rules of programming is "do not be afraid to delete code" (I think Jeff Atwood had a post to this effect, but I don't have the link handy). Unused code that gets squirreled away seldom finds its way into a working project. It just sort of molders there until someone finally deletes it (even in another branch) because it's been laying around forever and no one knows why it's there.

  • I can appreciate deleting code, but this is deleting functionality which I don't agree with if it may be useful later on. How many times have we all completed a feature only to hear they decided to change requirements, but we keep our changes on hand somewhere separate as we go about removing them and implementing the new functionality only for them to come back and say they actually want the first functionality? If you think the code will be helpful, squirrel it away on a drive somewhere. If you forget about it in time then it wasn't useful and it doesn't matter. Nov 28 '12 at 22:53
  • Isn't "Don't be afraid to delete code" stated under the assumption that it can be recovered from source control?
    – pdr
    Nov 28 '12 at 23:37
  • 2
    "Maybe used later" - in the physical world we call that hording - you know, people with houses so full of "stuff" it falls on top of them and crushes them to death. Call it a prototype and throw it away - Fred Brooks wrote that is what you should do. If it's really needed, you will be able to write it again when it is needed.
    – mattnz
    Nov 29 '12 at 1:28
  • 1
    @JimmyHoffa YAGNI applies here. Just like you don't put code into a project that you don't need, there is no reason to store code you don't need.
    – Michael
    Nov 29 '12 at 20:33
  • @Michael I can appreciate YAGNI but the work is already done. I'm not suggesting he leave it in the system, merely that he save the changes for later; though definitely they don't belong in the actual source control unless as a shelfset. Nov 29 '12 at 20:45

You need to make an assessment of whether it is likely that the code will be used in the future:

  • If it is (realistically) unlikely, then just get rid of it; i.e. #1
  • If it is likely #3 followed by some refactoring to make sure that the "fluff" code doesn't impact on your actual builds, test coverage, etc.

My reason for preferring #3 over #2 (or #4) is that code on old development branches or in the revision history is hard to find ... unless you know to look for it. When I look at a codebase to see if some bit of functionality is there to be reused, I look at HEAD:master. I don't trawl through the old branches, or through the commit logs.

Now in your case, there is a reasonable chance that you will remember that you implemented the functionality and then removed it from "master". But your co-workers are unlikely to know this, and even if you mention it to them they likely to forget it. However, if the code is still in HEAD:master, then there is a much better chance that they will find using IDE search.

Not the answer you're looking for? Browse other questions tagged or ask your own question.