How can I delete committed items that haven't been pushed to git yet?

Question

I tried to push files that were too big for the GitHub limit and couldn't push them. I removed them from the folder, but they're still there, waiting to be committed, and it's blocking other push attempts too.

Answer 1

Your problem is due to the fact that Git doesn't push files. Git pushes commits.

Git doesn't really store files either: Git stores commits. Commits themselves store files, but the key point is, you either have all of a commit, or none of it. There's no way to pick and choose just a few files out of it.

When you added the big files and committed, you made commits that have those files. Then you made additional, later commits that don't have those files.

So, keeping in mind that each commit stores a full and complete snapshot of all of your files—well, all of the files that are in that commit, which might be more or fewer files than some earlier commit—let's look at the rest of a commit. Besides the snapshot, a commit stores some metadata: some information about the commit itself. For instance, the commits you made have your name and email address in them, from your user.name and user.email settings. When you ran git commit, Git made you enter a log message, to say why you made the commit; the log message for each commit is part of that commit's metadata.

Commits are numbered, but not sequentially (that would be too easy!). They have big ugly hash IDs as their numbers. Every commit gets a unique hash ID, reserved for that commit forever more, and in a way, reserved for that commit long before you made it, except that the actual hash ID depends on all the metadata, and one of the items in the metadata is the date-and-time-stamp of when you made it. So until you actually chose a particular second of a particular minute of a particular hour of a particular day (etc), we wouldn't know what the hash ID would be. Still, that hash ID, from now on, means that commit. Your Git and any other Git can exchange commits, and know if they have each other's commits, by just comparing hash IDs.

The last key piece of metadata, though, is that every commit¹ stores its previous commit's hash ID as its parent. So every commit remembers which commit comes before it.

This means commits form a sort of backwards-pointing chain:

... <-F <-G <-H

where H stands for some big ugly hash ID. Commit H holds earlier commit G's big ugly hash ID as its parent; we say that H points to G. Commit G holds F's hash ID, so G points to F, and so on.

Note: the hash IDs are exquisitely sensitive to every bit of data in the commit. This means no part of any commit can ever change. (That's why it's OK to trust in the hash ID.)

When you run git push, your Git calls up another Git. Your Git says: Hey, I'd like to give you my latest commit H. Do you have it yet? They say: No, send it over. Your Git says: "To have H you need G, do you have it yet?* They say no, send that one too, and so on. This repeats until we reach a point where they say: Oh, yes, I have that one.

That's how your Git knows what it needs to send, and sends it all: just the right set of commits.

But you've got commit H, which doesn't have the big files, and commit G, which does, and then maybe you and they both have commit F. So your Git insists on sending both commits to them. That's because you can't have a commit, in Git, unless you have all of its parents.²

---

¹Some commits store two or more previous-commit hash IDs. These are merge commits. At least one commit in any non-empty repository stores no previous hash ID: the very first commit someone makes can't remember a parent, as there is no previous commit. This kind of commit is called a root commit.

²There are some ways to avoid having all of the parents, but they don't apply to this case.

---

What you need to do

What you need to do, then, is construct some new commit(s).

Commit H is sort of OK on its own, except it isn't on its own: it is indelibly linked to commit G, and commit G isn't OK because it has some really big files in it, that you don't want to have. Commit F is OK and they they already have F ... or maybe F is bad too, and it's E that's OK and they already have. Whatever your situation is, you have to figure out which commits are good and which aren't.

So, what we need to do is find out which commit they have, and which commits we have that are good and which are bad, and re-copy our good ones while leaving out our bad ones. There are a lot of ways to do this, but often the best one is to use git rebase -i:

git rebase -i origin/master

Our name origin/master is our Git's way of remembering their Git's master. This assumes your current branch name is master, i.e., that the picture we should draw really looks like this:

...--F   <-- origin/master
      \
       G--H   <-- master (HEAD)

Here, commit G is the one with the big file(s), and commit H is the one that takes them away again. We'd like to copy G-plus-H such that the big files are gone. Since H simply removes the file, we can use git rebase -i's squash command to combine G and H into one new commit, I, that does what G+H did, all in one:

pick <hash> subject line for commit G
pick <hash> subject line for commit H

becomes:

pick <hash> subject line for commit G
squash <hash> subject line for commit H

We write this out and git rebase goes and squashes the two and invokes our editor to let us write the new commit message.

When the whole thing is done, we end up with this:

       I   <-- master (HEAD)
      /
...--F   <-- origin/master
      \
       G--H   [abandoned]

That is, we kept existing commit F without touching it at all. Then we had Git extract G, pile H on top of it (removing the big files), and commit the result as new commit I. Our Git then took our name master off commit H, which was OK except that it linked to G. It now has our name master set to point to commit I.

We can now run git push origin master successfully: our Git will call up their Git, and say I'd like to offer you commit I if you don't have it. They'll say OK, what about I's parents? Our Git will say I's parent is F. They'll say Oh I have that one! Our Git will send commit I and then ask them to set their master to point to commit I.

If all goes well this time, they'll now have commit I. They never see our G and H again, and neither do we: we no longer have a name by which to find the big ugly hash ID of commit H.

Eventually—after 30 or more days, typically, though you can tweak this—our Git notices that no one seems to want H at all, and that G can only be found by starting at H and working backwards. So our Git will actually throw out commits H and G at this point (when the maintenance git gc command gets around to it, really), and our repository will shrink because we don't have the commit with the big file.

(If your commits are more complicated, you may need a somewhat fancier git rebase, or git rebase -i might no longer be the best tool for all of this. A great deal depends on exactly what's wrong and whether there's more than one way to fix it.)

Answer 2

Have you tried git rm {file1} {file2} ... {fileN}? You have to tell git to remove the files from the source tree even if you delete the files themselves.