Clean up git?

[random_id]

So, I started using git a while ago.

Now that I have been using it for a while, I have been realizing that I am doing certain things 'wrong'. There are a lot of file types that I don't really need within source control (e.g., binary builds, VS and XCode build junk, etc.). They have been included in the repo forever.

The other thing is that I am using WDL-OL, which is a repo that Oli maintains on github. Whenever there are changes, I pull them and manually copy the files into my repo. There are a few files that I have to open and copy/paste, because I have some modifications within my own WDL version. If I were slick, I would be able to pull straight into my own WDL, and do the diff/merge there.

My question is this: Should I try to clean up what I got, or should I 'freeze' my stuff as is and start another repo? I wouldn't want to loose any of my existing info, but the chances that I would need to use it are slim at this point in my development cycle. If I had a new repo and saved the other one, I could always open the old one up and go back to it if needed.

[Miles1981]

You can reimport your current git repository with additional filters to remove binaries and other temp files. It's called rewriting history, and your case is one of the few ones where history rewrite is "authorized".

[mystran]

There are a few files that I have to open and copy/paste, because I have some modifications within my own WDL version.

After you do the pull and change the files, can't you just commit locally? Then next time you pull, git will try to merge the local changes with the new version from upstream and you only need to resolve conflicts (if any).

[Tale]

I think I would start over... However, I would probably do this on an orphan branch, so you can keep your old work in the same repository.

And I would add WDL-OL as a remote, so you have a complete copy of WDL-OL inside your repository, but you can also let Git merge in changes from WDL-OL.

[random_id]

Thank you for the advice. I still have more of "Pro Git" to read before I decide what to do.
Does anyone have a .gitignore they would like to share?

[Tale]

Does anyone have a .gitignore they would like to share?

Not really, my working dir is seldomly clean...

EDIT: WDL-OL contains a .gitignore, so that might be a good starting point.

[mystran]

I normally treat my .gitignore more or less as "keep these from showing in TortoiseGit dialogs" rather than try to explicitly list every single thing that I don't want to add to the repository. Instead I'd just explicitly add whatever I want to add. The downside is that it's possible to forget some new files this way .. but really I think it's less of a problem (it won't go unnoticed for very long, unless you only version things on a single computer and practically never pull; I use git to sync between my laptop and desktop so don't really have that problem) than having to rewrite history in order to cleanup some large binaries that accidentally got added.

[Miles1981]

I agree with this workflow, it's less error prone, as soemtimes some files can be ignored because they are filtered by the .gitigone, but you didn't notice it until it's too late!

[cpr]

re: miles1981 comment on 'less error prone', I disagree. But, maybe both yours, and mystrans, comments come from people who use git to manage source code that only they work on, and/or small projects, and/or workflow differences. But, I find it very valuable, to have a clear view of what files have changed, and/or are new, and thus a well populated .gitignore is important. While typing this I also realized a context where it is even more important (and I find myself in regularly), which is when working with a cross-platform tool-chain that generates platform specific build files (such as cmake or The Introjucer for JUCE). In this case you do not want to check any of those generated files in.

Here is a sample of one I use in a JUCE based project. It ignores the embedded JUCE files (JuceLibraryCode), the files generated by a build, platform specific (VS and XCode) project files, and platform specific temporary files:

Code: Select all

# oonet project files to ignore 
Core/JuceLibraryCode/**
Core/Builds/**
XBeeTest/JuceLibraryCode/**
XBeeTest/Builds/**
*.xcuserdatad
oonet.sln
oonet.vcxproj
oonet.vcxproj.filters
*.vcxproj.user
*.bak

[ZenPunkHippy]

Almost every question anyone could possibly ask about Git has been posted to StackOverlow at some point in the last few years, and because of the StackOverflow points system the answers have been refined over time.

The links are generally at the top of the Google search results (at least within the first 50 results), if you get your search terms right.

Combined with the manual, it's an invaluable resource for Git problems and maintenance.

Peace,
Andy.

[mystran]

re: miles1981 comment on 'less error prone', I disagree. But, maybe both yours, and mystrans, comments come from people who use git to manage source code that only they work on, and/or small projects, and/or workflow differences.

Oh, I'm not trying to disagree on importance of a good .gitignore (mine are typically longer than the one you posted; they just don't make that good examples), rather I don't like blindly relying on ignores to filter what goes in and what doesn't (rather "these you don't need to even consider").

An example: I normally add graphics required for a build into git (since i think you should be able to do a pull, hit "build" and get a working result). So adding *.png into git-ignore doesn't work. On the other hand, I don't want to blindly add any .png (or a couple of thousands of them, that I might have dumped as a debug video dump or whatever) just because it (or they) happened to be the wrong place (and when I see them in the commit dialog, I can then put them somewhere that I can ignore, etc).

That said, I certainly have some weird workflows and my average working directory is a big heap of all kinds of garbage (more so for my personal projects; for shared stuff I try to separate the garbage from the shared project in separate directories). YMMV.