0

Hi I'm currently using SVN. Let's say I have some files with some changes that should be locally presented on my pc (I need them to run it on my configuration) but they shouldn't be committed to server. I case of SVN it is ok to add them to .ignore and just do not commit them, but this works only in case of changing other files during my work. If I need to change something in files that are marked as ignore - I need before commit to backup these files, revert ignored changes, commit and restore them after backup. Sometimes this can be very annoying.

I heard about git, that it is built upon changesets not files. Can I use git-svn to ignore some changeset?

Archeg
  • 8,364
  • 7
  • 43
  • 90

3 Answers3

1

If you're using git-svn, you might be interested in its create-ignore and show-ignore options, which will create a .gitignore file matching the existing svn:ignore settings.

If the files you want to ignore are purely local and not even known by svn:ignore, putting their names/patterns in .gitignore should be enough for them to be ignored by git and git-svn (unless you've added them explicitly to the index).

If you want to ignore a changeset (which is different to ignore a file as part of your git commits), you should put them on a different branch, one that you don't "dcommit" with git-svn.

Bruno
  • 119,590
  • 31
  • 270
  • 376
0

I have a bit of trouble to understand your question but I try:

If you add a file to svn:ignore, it's ignored by SVN. So there should be no need to backup or restore it before/after a commit. Are you sure you didn't add those file accidentally? SVN ignores files in svn:ignore but if you do svn add ignorefile.bak the file will be added to the repository.

The same is true for git. It also has an ignore file but you can still force add a file.

That said, you should never have files in your project that are not committed. Either the file is important, then you should commit it. If that would disrupt the work of others, commit it under a different name (say arched.config instead of project.config). Otherwise, it will be very hard for another user to maintain the software. Or for yourself, if your PC suddenly dies.

If the file is unrelated to the project, it should not be in the project at all. Put it somewhere else.

And with Git, you even have another option: You can create a branch that contains the file just like it contains any other file. Name that branch "archeg-work". Now you can always work on this branch and the project will work out of the box. Just clone it and no further changes are necessary.

When you're happy with your work, merge the changes back into the master branch. Unlike with SVN, branching really works with Git. Linus Torvalds merges thousands of branches every day without problems.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
0

This is not really related to git or svn specifically.

The usual practice in the case you're in is put under version control a template of this file (config.in for example) and to ignore the real config file. When cloning the repository all you have to do is to copy the template, and the real file that will be used is ignored by your version control system.

CharlesB
  • 86,532
  • 28
  • 194
  • 218