0

This is perhaps a question of strategy more than anything else. I am new to version control and I guess I should count myself lucky to have relatively more mature systems like Mercurial and Git at my disposal as compared to the older systems.

I started with Hg because I read somewhere that it's more Pythonlike in its approach. The few tutorials that I went through (examples and videos) consistently use the command hg add *. After using that command for some time now on my project, I have a long list of files which have ! in front of the files that have been deleted. I am speaking of the output of the command hg st of course.

I guess using hg addremove * will solve my problem. If that's the case, why isn't it the default command to teach Hg to a beginner? Is there a pitfall I am missing? Wouldn't it be reasonable to assume that typically a person working on a folder would want the files which are deleted to visibly disappear from the output of hg st (esp. since they are stored in the repository by Hg anyways)?

4

hg add * is a terribly idea. The tutorials you've read/watched probably weren't very good. Most repositories contain many files that you don't want to put under version control: Generated artifacts, junk from experiments you did, and files that should be part of the repository but only later (i.e., are not ready to be committed). You don't want to version control those. Unless they are only temporary, they should be listed in .hgignore so they won't pollute the output of hg status with ?s and won't be added accidentally. hg add and hg addremove already consider all files, except ignored ones, and hg add * and hg addremove * override this sane default. So it's not only redundant, but also breaks a very useful feature.

You should only add the files that make sense of have under version control. Then files "suddenly disappearing" is not a problem, because the only files Mercurial tracks are the important ones, which you rarely remove, and if so, only manually after careful consideration. In that case, use hg rm file1 file2 to remove those files both from the file system and from mercurial — no need for addremove.

hg addremove is a useful shorthand if you screwed up and made significant changes to the project layout via some tool other than Mercurial, especially since it properly handles copies/renames. Note that you can restrict it to some files by giving, for example, hg addremove src/. But it should never override good judgement of what belongs under source control and what doesn't. If you accidentally added a file that shouldn't be under source control, use hg forget the-file before committing.

  • Even though I accepted your answer a week ago, I have fully realized the extent of my error just yet. My repo size is unnecessarily high. Of course I will correct this when I start fresh on my other projects, but what would be a good way to make repairs on my current repo? Should I untrack all files and then just add the ones I really need to follow? – Shashank Sawant Mar 12 '15 at 18:00
  • 1
    @ShashankSawant Tough place to be in. You should certainly throw out files that have no reason to be tracked so the future looks brighter, but the history would still be a mess. If you care about repo size and a clean history, you could create a new repository and replay a cleaned-up version of history (same commits at the same date/time, omitting pointless files), but automating this is beyond my expertise and doing it manually is probably too much work and too error-prone. Maybe ask a new question? – user7043 Mar 12 '15 at 18:05
  • Related question: programmers.stackexchange.com/questions/276132/… – Shashank Sawant Mar 12 '15 at 18:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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