Rubberduck: Create a default .gitignore for VBA projects

[rubberduck203]

As a VBA dev, I want to keep my documents in the same ire tort as my repository, but exclude it from the repository. I also don't want the user form binary files in the repository.

Create a default .gitignore file that can be used. Exclude all Microsoft documents and the *.frx user form binary files. Initializing a VBA project through the GUI should use this file by default, however I'm undecided about how this should work through COM client code.

[retailcoder]

.frx includes any images that might be embedded in forms, and other
information too - user might want them under version control

Sent from my Samsung mobile

[rubberduck203]

Yeah. I thought that at first too, but the binaries change every time they get exported/imported. It causes a real headache. I think the default behavior should be to ignore them. Let people opt in if they want to. Nothing will stop anyone from altering the .gitignore file.

[INOPIAE]

What are your plans about the .gitignore file?
Is the idea to ship a default file?
What is if a user wants to customize his own default file?
Where do want to place the opt-in option?

[rubberduck203]

1. Yes. I plan on creating a default .gitignore on "create new VBA repository" action.
2. The default file will be an actual file stored in RD's program data. There fore it could be modified by a user.
3. The process will be opt _out_. The UX is extremely poor without git ignoring certain file extensions.

---

1. Ignore *.frx files so they don't pollute the history.
2. Ignore Office document file extensions.

[INOPIAE]

Would it not be a better idea to have a default "Rubberduck .gitignore" template and to give the user to create his own .gitignore templates. Afterwards the user should be able to define which template should be taken as default file if .gitignore is not optout.

[rubberduck203]

In a perfect world, _maybe_, but since the *.frx file changes each time it's imported into a project it's important that this be on by default. Otherwise, after you commit, it shows right back up in the "pending changes". This causes the user to be unable to switch between branches. I would also note that when you use Visual a Studio to init a new Git repo, it also creates a default .gitignore file.

Like I said. The default file will be stored in the AppData folder, so the user could modify the default file. Also, there's a button in the GUI that opens up the .gitignore file for the repository so it can be edited.

[BenBE]

I think allowing the user to choose from different templates and create his own is the best compromise we have here. That way we can offer some default templates where various default file extensions (e.g. temp files) can be filtered, while providing a sane, customizable default to the user.

As binary files should be usually avoided in a repository you should investigate if there is a sane alternative for (auto-)regenerating them while retaining the feature set. Thus if such auto-generated files manage e.g. display/embedding of images, you should have a look whether you can provide a similar feature without relying on that binary file (e.g. an API used in auto-generated/managed code in OnCreate of that object).

[INOPIAE]

@ckuhn203
I am currently ignoring the problem with the *.frx file for my discussion.
Your approach reminds me of the usage of the normal.dot and the problems that arise when Microsoft updates the default normal.dot.
What will happen if the developer of RD decide to update the default .gitignore file e.g. to add MS Project or Visio files?
In your case all the user defined changes in the default .gitignore will get lost.

Based on the model to have a RD .gitignore and a user .gitignore there could be a comment in he first line of the :gitignore file that holds a version information and tells the user that the RD .gitignore has changed in comparision to his file.

[rubberduck203]

Pull requests are encouraged gentlemen. I'll accept any sane solution, but we _can't_ ignore the UserForm *.frx problem.

[rubberduck203]

@BenBE the *.frx file is not something I could just replace. UserForm's are comprised of several files. One for the code and another that defines the form itself. The IDE itself creates and manages these files and there is no hook for us to intervene.

[Hosch250]

Is this done? There seems to be a default currently, is it still under construction?

[rubberduck203]

It's half done, and not well implemented. It's currently hardcover into the settings as a string, but never actually wired into the source control stuff. If you look in the SourceControlSettings presenters and the actual GitProvider.InitVBAProject method, you'll see what I mean.

[retailcoder]

@ckuhn203 is that why I have a .gitignore file supposedly ignoring .frx files and still the SC panel lets me include the .frx files and treats them as "untracked"?

[rubberduck203]

Very possibly @retailcoder. Check the actual repository to see if the .gitignore exists in there.

[Merlin2001]

I strongly object to ignoring the .frx files by default. This makes the repo lose all "design" information of the forms which can be a lot of work to redo.

Instead I think we should be intelligent about only replacing the .frx file in the repo when it actually changed. VbaDeveloper (a VBE addin to export source code during each Excel file save) has a great feature idea regarding this. It sounds like quite some work but might really fix the problem for good.

Another really low-tech solution could be to just ignore .frx file changes under n bytes. A solution we already used internally: if the old and new .frx file had less than 7 different bytes, the old file would not be overwritten with the newly exported one.
This still leads to some unnecessary "changes" but far less than normally.

[retailcoder]

@Merlin2001 agreed - the .frx includes vital binary information including and not limited to embedded icons and whatnot: outright ignoring these files means data loss, and that can't work. Thanks for the ideas!

[JKAbrams]

As a workaround for people that wants to use the source control features today (knowing that forms will not be part of the source control), here is how to get branching to work (only tested with local branches but it likely works also online):

1. Figure out the name of the folder RubberDuck creates by creating a new local repository

2. Not sure it's needed but it might be a good idea to quit Excel here.

3. Empty the contents of the folder (including the .git folder)

4. Create a new .gitignore file in the folder containing:
   *.frx
   *.frm

5. Create a new local repository from within RubberDuck

Tested in Excel.

Now switching branches works. There is a further problem in creating new branches that I'll describe in a new bug, but for now let me just note that it creates branches not from the current state but from the state when the repository was first created.

Edit: spelling

Edit 2: The problem alluded to above is real but apparently rare, my trivial way of reproducing it did not work.

[JKAbrams]

On topic, would it not be possible to crate a thin shim between GIT and the actual code?

If it would be possible to create a deterministic ordering in the form file, the file is only presented to git in an ordered form, then changes would not be detected if they are only in ordering. When syncing back from GIT > VBA the ordered version will be used but that does not matter as they are equivalent.

Sorry if what I say does not make sense from a implementation pov, I'm just a RubberDuck user.

[retailcoder]

@JKAbrams that should be possible, yeah. I believe @ThunderFrame has some work that could be used for this.

[rubberduck203]

3758