3

Today I was working on my project, and I tried a new algorithm that didn't work well. Thus, I don't want to include it in the project, but I'd like to have a commit with the code in the repository just in case I want to refer back to it later. Here is what I did:

git add .

git commit -m "Lorem ipsum..."

Wrote down the commit hash in my notebook with some notes.

git reset HEAD^

So now, that commit is not part of the branch history, but if, in the future, I need this commit, I can simply check it out by using the commit hash. But here is my question:

Will this commit ever be pushed to the remote? Or will it stay only on my local machine forever? Obviously, this would be bad, because if I ever have to move machines, etc., I will lose this commit when I re-clone.

Nick Foster
  • 164
  • 9
  • 1
    A naive approach might be to do a `git revert` on the commit you just made - this way the commit will be pushed to remote but it won't be in the `HEAD` – Lix Jun 29 '20 at 15:03
  • 2
    That sounds hideous! A better approach would be to make a personal WIP branch and push that to the remote, along with a WIP PR/MR if the remote has an associated issue-tracking system. Don't let everyone clog up `master` or any real branch with unfinished junk. – underscore_d Jun 29 '20 at 15:04
  • @Lix I understand that I can do a `git revert`, but honestly I'd rather it not be in the branch history at all. It was really just some throwaway code that I tried but don't want to just delete forever. That being said, that's probably a better idea than what I've described above. – Nick Foster Jun 29 '20 at 15:10
  • @underscore_d I understand that it's messy. My problem with WIP branches is I would have at least 6 of them by now with just random approaches I've tried that don't work. This commit isn't promising and I don't want to continue developing it (at least as of now). Honestly, I'd probably just delete it outright (not commit it at all), except that I've done that to code before and regretted it. – Nick Foster Jun 29 '20 at 15:12
  • 1
    You could have one WIP branch where you consecutively apply and then revert each variant, then push that. That way all the commits get kept, but each is based off the original code. That's OK if the mess isn't going to a 'live' branch. And it's definitely preferable to having isolated, cryptic, unintuitive commits floating in the aether without context, even if that were possible! – underscore_d Jun 29 '20 at 15:15
  • 3
    Note that your reset-away commit will, if it has no branch or tag or other permanent name, eventually be discarded by `git gc`. It will remain in your repository as long as it has *some* find-able name, including reflog entries, which count for this particular purpose. Reflog entries, however, eventually expire and are cleaned out. Once the only name for it is its hash ID, it becomes eligible for GC. – torek Jun 29 '20 at 17:29
  • 2
    The default lifetime for reflog entries is either 30 or 90 days. The 30-day lifetime applies in this particular case. After that, a `git reflog expire` as run by `git gc` will delete the reflog entry, and then a `git prune` as run by `git gc` will delete the commit. Exactly when `git gc` runs is hard to predict: various commands run `git gc --auto` for you and the `--auto` mode checks to see whether Git thinks a `gc` would be good. If not, the auto-gc exits immediately without doing anything, but if so, it runs the rest of its usual work in the background. – torek Jun 29 '20 at 17:32

2 Answers2

3

No, that commit will not be pushed. Only "active" commits on the branch you are pushing will make it to the remote repo.

My 2 suggestions are already in the comments:

  1. Create a separate branch. I prefer the naming convention user/first.last/some-branch which can be your personal backup of commits you (or someone else) may want to look at in the future. I typically have a bunch of these types of branches and I will purge out the garbage every few months.
  2. Commit the change, revert the change, and then when you push the history is preserved on your branch.

I nearly always prefer #1 over #2.

Note there are ways to push commits that aren't associated with a branch, but I don't recommend it because they are more difficult to find later, and may eventually be garbage collected if there is no branch or tag pointing to it. (See this comment from torek for more details.)

TTT
  • 22,611
  • 8
  • 63
  • 69
1

When you push to a remote you are most often pushing a branch:

git push <remote> <local branch>:<remote branch>

If when you push your branch your commit is not there it will not be pushed.

Just found this answer with more insight: Is it possible to push a commit which is not in any branch in git?

albeksdurf
  • 124
  • 8