Using Mercurial (hg), can you just "hg backout" all the commits you did for the files you don't want to push, and then do a push?

Using Mercurial (hg), can you just "hg backout" all the commits you did for the files you don't want to push, and then do a push?

Because Mercurial (or Git) won't let us push a single file or a single folder to another repo开发者_如何学Gository, so I am thinking:

1) How about, we just look at the commit we did, and hg backout the ones we don't want to push.

2) hg out -v to see the list of files that will be pushed

3) now do the push by hg push

Is this a good way?

This is because I got the following advice:

1) Don't commit that file if you don't want it to be pushed (but sometimes even just for experimentation, I do want to keep the intermediate revisions) (-- maybe I can hg commit and hg backout right away to prevent it from being pushed.)

2) Some people told me just to hg clone tmp from that repository i want to push to, and then copy the local file over to this tmp working directory, hg commit to this tmp repository, and then do a push. But I found that the hg clone tmp will take up 400MB of new data and files, and make the hard drive work very hard, just to push 1 file? So I would rather not use this method.

If you do hg backout, then the files will still be pushed, but be omitted in the tip revision. The remote repository will receive the changesets to add the files, and then receive the backout changesets to remove them. So it will have the history for the files you don't want to push.

Once you've committed a file, any move of changesets touching that file to another repository will include the changes for that file. If all you want to do is prevent a checkout of the tip of the remote repository from including the file, then what you describe will work. If not, then there is no history-preserving way to accomplish what you want aside from never pushing any changeset touching the file in question. You can remove it by using convert to create a new repository without any trace of the unwanted file, but that generates a new repository with new history.

Your measure of "work very hard" is flawed - the work of cloning a many gigabyte, thousands of commits repo is trivial for any modern hard drive, let alone yours, and, especially for a temporary repository, the space requirements are completely irrelevant.

The easiest way to do what you want to do is clone the repo to the revision you want to push, push that clone, and delete. While the solutions you're looking for will save a few spins of your disk, they are far more complicated than they are worth.

Mozilla and Python* both use Mercurial, and I promise you their repos are far larger and more complicated than what you're dealing with. If they're able to use them without a problem, surely you can too. Give it a try without stressing over the few bytes you use, it'll be worth your while.

*Python is in the process of switching to Mercurial

EDIT Addressing your comment to adymitruk, you're misunderstanding Joel's point. Commit early, commit often, and don't be afraid of wasting commits, but that doesn't mean you should backout whenever you make a mistake - that would defeat the whole point of versioning everything. If you commit something you don't like, fix it and commit again. Rolling back is a feature because it can be useful, not because you're supposed to do it all the time.

I'm not sure why you would not want to push certain files if you committed the changes.

I would make another branch and rebase -i on master in GIT to remove them. When you are ready to push the other files, you can rebase -i on another branch to pick those files and cherry-pick to master when ready.