Version Control Questions Megathread (SVN / git / whatever else)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›100 »

ToxicFrog: Apr 26, 2008

Walked posted:

So I'm trying to learn a bit about git; my background is not in coding but in IT infrastructure, and I do a lot with powershell.

I've been using Visual Studio Online for a bit; and all has been awesome.
Today I created a branch, did some editing on a script feature I wasnt 100% sure on, and merged back to master afterwards.

Now, in the VSO browser, under branches, my new branch (which I thought was good to go 100%) shows "Behind: 4, Ahead: 0"

Can anyone recommend what to look at or what I might have missed? My master branch all files look 100% as they should; but I figure I should at least learn what I did wrong and/or how I broke the branch to show as "Behind: 4". I assume this means 4 commits behind; but how would I fix this?

I'm just not quite sure to google or look for on this one; doubly as I'm really not a developer - I'm just trying to take advantage of versioning and source control in the most basic of ways.

"Behind 4, ahead 0" means that there are 4 commits on master that aren't on that branch, and 0 commits on that branch that aren't on master, which is exactly what you should expect -- "ahead 0" means that all the commits in that branch are merged into master, "behind 4" means you haven't been integrating changes on master into that branch. Generally at this point you either (a) discard the feature branch entirely, as it has served its purpose now that its changes are merged into master, or (b) merge master into it so that it's up to date and continue work on it.

# ? Oct 5, 2015 15:46

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 20:09

lord funk: Feb 16, 2004

Can someone help me out with main branch renaming on a remote? I just have no clue where to take care of the following config message:

code:

remote: error: By default, deleting the current branch is denied, because the next
remote: error: 'git clone' won't result in any file checked out, causing confusion.
remote: error: 
remote: error: You can set 'receive.denyDeleteCurrent' configuration variable to
remote: error: 'warn' or 'ignore' in the remote repository to allow deleting the
remote: error: current branch, with or without a warning message.
remote: error: 
remote: error: To squelch this message, you can set it to 'refuse'.

I know it's a setting on the remote, but where? The git config page isn't making things clear for me.

# ? Oct 6, 2015 21:25

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

It's not a setting on the remote; it's a setting that you have to set on the actual repo you want to push to.

# ? Oct 6, 2015 22:54

spacebard: Jan 1, 2007; Football~

lord funk posted:

Can someone help me out with main branch renaming on a remote? I just have no clue where to take care of the following config message:
code:
remote: error: By default, deleting the current branch is denied, because the next
remote: error: 'git clone' won't result in any file checked out, causing confusion.
remote: error: 
remote: error: You can set 'receive.denyDeleteCurrent' configuration variable to
remote: error: 'warn' or 'ignore' in the remote repository to allow deleting the
remote: error: current branch, with or without a warning message.
remote: error: 
remote: error: To squelch this message, you can set it to 'refuse'.
I know it's a setting on the remote, but where? The git config page isn't making things clear for me.

I think you want git remote set-head origin <branch>

# ? Oct 7, 2015 03:45

lord funk: Feb 16, 2004

spacebard posted:

I think you want git remote set-head origin <branch>

I'm doing this: git remote set-head origin otherBranchName

...but git remote show origin still reads:

HEAD branch: master

# ? Oct 7, 2015 17:34

revmoo: May 25, 2006; #basta

I'm doing a writeup comparing Git to SVN. Can someone please confirm that SVN does in fact discard commit history when merging branches? That's been my conclusion but I want to be sure of it before I go running my mouth about it.

# ? Oct 9, 2015 19:30

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

revmoo posted:

I'm doing a writeup comparing Git to SVN. Can someone please confirm that SVN does in fact discard commit history when merging branches? That's been my conclusion but I want to be sure of it before I go running my mouth about it.

http://stackoverflow.com/questions/3531989/how-to-merge-branch-back-to-trunk-in-svn-with-all-commit-history

# ? Oct 9, 2015 19:34

revmoo: May 25, 2006; #basta

Ithaqua posted:

http://stackoverflow.com/questions/3531989/how-to-merge-branch-back-to-trunk-in-svn-with-all-commit-history

That's a lot to parse, am I correct in understanding:

- Short answer, yes it does discard history, however it stays with your local copy
- Long answer, there are scripts you hack on top to retain it

# ? Oct 9, 2015 19:40

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

I upgraded my Git for Windows to 2.6.1 and now none of the y/n type prompts show up in MINGW64.

For example, the following python script just kinda hangs, I never get the prompt:

code:

test = raw_input('this is a test: ')
print(test)

edit: If I just hit enter, then I see the "this is a test: " output and the program quits

fletcher fucked around with this message at 08:28 on Oct 16, 2015

# ? Oct 16, 2015 07:11

wwb: Aug 17, 2004

revmoo posted:

I'm doing a writeup comparing Git to SVN. Can someone please confirm that SVN does in fact discard commit history when merging branches? That's been my conclusion but I want to be sure of it before I go running my mouth about it.

No SVN scientist but I had a solid decade of using and and administering it. If I'm understanding your question correctly I'd say the answer is yes and no. SVN merges don't work like git pull requests, more like a branch merge. You don't get the commits imported like a pull request (sans squashing) but the commits would still exist in the branch one did the work in. To some extent this is wrapped up in deep differences between DCVS and non distributed CVS.

# ? Oct 16, 2015 15:50

revmoo: May 25, 2006; #basta

wwb posted:

No SVN scientist but I had a solid decade of using and and administering it. If I'm understanding your question correctly I'd say the answer is yes and no. SVN merges don't work like git pull requests, more like a branch merge. You don't get the commits imported like a pull request (sans squashing) but the commits would still exist in the branch one did the work in. To some extent this is wrapped up in deep differences between DCVS and non distributed CVS.

Crazy poo poo, so you either keep around hundreds/thousands of feature branches so you can keep track of your commit history, or you say "eh, screw it" and merge/delete as you go. So basically your commit history is just a list of dates branches were merged in. To me, branching is an absolute requirement. Every ticket/task gets a branch, you do the work, test it, and merge in. But if you are using proper branching hygiene, then it means you get no commit history other than who/when a branch was merged. It almost seems pointless to use a VCS at that point if you're not tracking commit history. We often have feature branches that will stay open for months with hundreds, if not thousands of commits, and I couldn't fathom throwing all of that history away once the feature is complete.

I get how you can make it work, but it is a far, FAR weaker VCS just on this one issue alone. Hell, you can't even do something like 'git bisect' to track down the commit a bug was introduced if you have no commit history to bisect!

# ? Oct 16, 2015 15:58

Azhais: Feb 5, 2007; Switchblade Switcharoo

We use svnmerge.py and merge commits individually so the history is still there. We also have a wrapper script that interacts with a user exit that links the two revisions together to you can trace every commit back to its branch of origin (and from any branch see where the commit has gone).

# ? Oct 16, 2015 16:04

revmoo: May 25, 2006; #basta

Azhais posted:

We use svnmerge.py and merge commits individually so the history is still there. We also have a wrapper script that interacts with a user exit that links the two revisions together to you can trace every commit back to its branch of origin (and from any branch see where the commit has gone).

This is the issue I have every time I work in our old SVN repos, a bunch of hacky shell scripts and piped together commands to accomplish basic tasks. It's ugly as poo poo and I don't understand why people are still using this archaic poo poo in this day and age.

# ? Oct 16, 2015 16:06

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

revmoo posted:

Crazy poo poo, so you either keep around hundreds/thousands of feature branches so you can keep track of your commit history, or you say "eh, screw it" and merge/delete as you go. So basically your commit history is just a list of dates branches were merged in. To me, branching is an absolute requirement. Every ticket/task gets a branch, you do the work, test it, and merge in. But if you are using proper branching hygiene, then it means you get no commit history other than who/when a branch was merged. It almost seems pointless to use a VCS at that point if you're not tracking commit history. We often have feature branches that will stay open for months with hundreds, if not thousands of commits, and I couldn't fathom throwing all of that history away once the feature is complete.

I get how you can make it work, but it is a far, FAR weaker VCS just on this one issue alone. Hell, you can't even do something like 'git bisect' to track down the commit a bug was introduced if you have no commit history to bisect!

Why is the exact commit relevant? I thought the entire point of Git is that you're rewriting history so that the exact commit a bug was introduced in is combined with a bunch of other ones, anyway. At that point, aren't you back to just knowing "the bug came from Feature X"? I am admittedly not an expert in common Git workflows so I could be missing something important.

Anyway, there's no harm in keeping the old branches around. You can safely shuffle them off to some dark corner of the repository when you're done with them. I'm assuming that SVN works similar to TFVC in that it stores reverse deltas, so only the most recent version of a file is stored and older versions are built by progressively undoing changes.

# ? Oct 16, 2015 16:14

Seashell Salesman: Aug 4, 2005; Holy wow! That "Literally A Person" sure is a cool and good poster. He's smart and witty and he smells like a pure mountain stream. I posted in his thread and I got a FANCY NEW AVATAR!!!!

Is there a way, in Git, to checkout the commit at the head of a branch (not by looking up the hash) so that you end up with detached head? Sometimes for bug fixes I want to just get to the head of a team branch and start committing stuff and create a branch for the fix later, and I'm sick of having to reset --hard my copy of the team branch afterwards. This workflow just works when I'm working off a tag instead of a branch so I feel like there is a way to do it without too much pain.

# ? Oct 16, 2015 19:58

necrotic: Aug 2, 2005; I owe my brother big time for this!

Seashell Salesman posted:

Is there a way, in Git, to checkout the commit at the head of a branch (not by looking up the hash) so that you end up with detached head? Sometimes for bug fixes I want to just get to the head of a team branch and start committing stuff and create a branch for the fix later, and I'm sick of having to reset --hard my copy of the team branch afterwards. This workflow just works when I'm working off a tag instead of a branch so I feel like there is a way to do it without too much pain.

git checkout -b new-branch-name shared-branch-name creates a new branch named "new-branch-name" with the same HEAD as "shared-branch-name". https://git-scm.com/docs/git-checkout

# ? Oct 16, 2015 20:15

Seashell Salesman: Aug 4, 2005; Holy wow! That "Literally A Person" sure is a cool and good poster. He's smart and witty and he smells like a pure mountain stream. I posted in his thread and I got a FANCY NEW AVATAR!!!!

Thanks for the suggestion but I already know how to create a branch, what I'm trying to do is the opposite-- to checkout the commit at the head of a branch but be in detached head so that future commits don't move the head of the branch I checked out to the new commit.

Put it another, maybe less confusing way, 'git checkout A' then 'git commit' will move me to the head of A, create a new commit, and then make A point to the new commit. I don't want A to point to the new commit, and I don't want to create a new branch or have to look up the hash for the head of A beforehand.

Seashell Salesman fucked around with this message at 20:42 on Oct 16, 2015

# ? Oct 16, 2015 20:34

revmoo: May 25, 2006; #basta

Couldn't you just do 'git log <branch>' and then grab the hash at the top and then check out that hash?

# ? Oct 16, 2015 20:42

Seashell Salesman: Aug 4, 2005; Holy wow! That "Literally A Person" sure is a cool and good poster. He's smart and witty and he smells like a pure mountain stream. I posted in his thread and I got a FANCY NEW AVATAR!!!!

revmoo posted:

Couldn't you just do 'git log <branch>' and then grab the hash at the top and then check out that hash?

Yes, I'm looking for a way to do this without looking the hash up.

# ? Oct 16, 2015 20:43

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

git checkout `git rev-list --max-count 1 branchname`

# ? Oct 16, 2015 20:49

Seashell Salesman: Aug 4, 2005; Holy wow! That "Literally A Person" sure is a cool and good poster. He's smart and witty and he smells like a pure mountain stream. I posted in his thread and I got a FANCY NEW AVATAR!!!!

Plorkyeran posted:

git checkout `git rev-list --max-count 1 branchname`

Thanks

# ? Oct 16, 2015 20:58

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Ithaqua posted:

Why is the exact commit relevant? I thought the entire point of Git is that you're rewriting history so that the exact commit a bug was introduced in is combined with a bunch of other ones, anyway. At that point, aren't you back to just knowing "the bug came from Feature X"? I am admittedly not an expert in common Git workflows so I could be missing something important.

Anyway, there's no harm in keeping the old branches around. You can safely shuffle them off to some dark corner of the repository when you're done with them. I'm assuming that SVN works similar to TFVC in that it stores reverse deltas, so only the most recent version of a file is stored and older versions are built by progressively undoing changes.

That's why I hate rebasing to squash history. What's the point in cleaning up your history if you lose the date and time a bug might have been introduced?

# ? Oct 16, 2015 22:19

revmoo: May 25, 2006; #basta

Rebasing is retarded

# ? Oct 16, 2015 23:00

raminasi: Jan 25, 2005; a last drink with no ice

Rebasing is an absolute delight as long as you never do it to code anyone else has ever seen.

# ? Oct 16, 2015 23:44

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Gotta commit after every single keystoke because every bit of history is precious.

# ? Oct 16, 2015 23:46

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Plorkyeran posted:

Gotta commit after every single keystoke because every bit of history is precious.

gl with that git bisect

# ? Oct 16, 2015 23:53

fritz: Jul 26, 2003

fletcher posted:

gl with that git bisect

Log-time complexity is a hell of a thing.

# ? Oct 17, 2015 03:52

comedyblissoption: Mar 15, 2006

If you want to retain the history when you merge things in you have a few options (that can be used in tandem):

keep around a million feature branches
keep around a million tags (make sure you don't use lightweight tags)
put the work item/story/bug tracking id in the relevant commits themselves
put the work item/story/bug tracking id in the merge commit itself; ensure you always create a merge commit for this purpose even for a fast-forward merge

# ? Oct 17, 2015 04:44

Vanadium: Jan 8, 2005

I've been tracking a generated file in git for a while and noticed that the contents are basically unordered, and it gets generated in a seemingly random order every time, making diffs pretty bad to look at. I've looked at clean/smudge filters to just sort it arbitrarily but consistently on checkin, but I can't really figure out how to not make it freak out about unsaved changes every time I look at a commit that predates me adding those filters.

Is there a decent way to deal with that short of running a git filter-branch to rewrite history so I will always have been using that filter?

# ? Oct 17, 2015 14:08

necrotic: Aug 2, 2005; I owe my brother big time for this!

Seashell Salesman posted:

Put it another, maybe less confusing way, 'git checkout A' then 'git commit' will move me to the head of A, create a new commit, and then make A point to the new commit. I don't want A to point to the new commit, and I don't want to create a new branch or have to look up the hash for the head of A beforehand.

I'm curious why you would even want to do this.

# ? Oct 17, 2015 18:11

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

The primary purpose of commits I make is producing the solution.

The primary purpose of commits I share is communicating the solution.

The primary purpose of rebasing is to turn commits of the first kind into those of the latter kind.

It makes me sad when people don't know how good rebasing can be.

Vanadium posted:

I've been tracking a generated file in git for a while and noticed that the contents are basically unordered, and it gets generated in a seemingly random order every time, making diffs pretty bad to look at. I've looked at clean/smudge filters to just sort it arbitrarily but consistently on checkin, but I can't really figure out how to not make it freak out about unsaved changes every time I look at a commit that predates me adding those filters.

Is there a decent way to deal with that short of running a git filter-branch to rewrite history so I will always have been using that filter?

Are you tracking the source from which the file is generated? If so, instead of smudgery, you could just add the generated file to your .gitignore and, git rm --cached it. No more useless diffs, and old commits remain unchanged.

If the source is external to the repo, then I'm stumped.

# ? Oct 17, 2015 19:01

Seashell Salesman: Aug 4, 2005; Holy wow! That "Literally A Person" sure is a cool and good poster. He's smart and witty and he smells like a pure mountain stream. I posted in his thread and I got a FANCY NEW AVATAR!!!!

necrotic posted:

I'm curious why you would even want to do this.

I just find that when making lots of bug fixes and working on multiple copies of the same repo across multiple physical drives on my dev machine at work that it's sometimes easier to just start tearing into an issue making commits before I want to think of a branch name and point that at a commit. Of course if I leave for the day, for example, then I'll create a branch name and push my commits to a remote so there's a backup. Losing track of stuff is rare enough that I don't mind looking through 'git reflog --all' when it happens.

Seashell Salesman fucked around with this message at 19:25 on Oct 17, 2015

# ? Oct 17, 2015 19:23

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Doc Hawkins posted:

The primary purpose of commits I make is producing the solution.

The primary purpose of commits I share is communicating the solution.

The primary purpose of rebasing is to turn commits of the first kind into those of the latter kind.

It makes me sad when people don't know how good rebasing can be.

For the uninformed, can you explain the process you'd use (not commands) to determine how to take commits you make and turn them into commits you share? I have a lot of difficulty understanding the difference unless every commit you make is "WIP" or "gently caress WHY DOESN'T THIS WORK?"

# ? Oct 17, 2015 19:33

Seashell Salesman: Aug 4, 2005; Holy wow! That "Literally A Person" sure is a cool and good poster. He's smart and witty and he smells like a pure mountain stream. I posted in his thread and I got a FANCY NEW AVATAR!!!!

Blinkz0rz posted:

For the uninformed, can you explain the process you'd use (not commands) to determine how to take commits you make and turn them into commits you share? I have a lot of difficulty understanding the difference unless every commit you make is "WIP" or "gently caress WHY DOESN'T THIS WORK?"

There are plenty of obvious examples: Changes that break tests, changes that break builds, changes that work for some platform but breaks others. It's natural to not want to expose those commits because if people check them out then they are seeing an interstitial state that wasn't a real state of the product.

# ? Oct 17, 2015 19:38

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

Blinkz0rz posted:

For the uninformed, can you explain the process you'd use (not commands) to determine how to take commits you make and turn them into commits you share? I have a lot of difficulty understanding the difference unless every commit you make is "WIP" or "gently caress WHY DOESN'T THIS WORK?"

Well, even with commits no one else but me will see, I try to have a little more detail in the message than just "WIP," but those two examples do cover a lot of ground. Even for a simple change, I might update the tests first, then the code. For a sweeping change in a large codebase, I might commit updates section by section. In either case, I might make progress towards my initially planned solution, only to encounter a special case that forces me to rethink things and start working towards some other solution. All of those can get squashed together.

I might also struggle with a problem I believe I introduced, only to discover it was caused by some upstream change, or build server trouble. Sometimes I might make a change which makes my work easier to test (usually deleting something slow and unrelated), but which I obviously don't want to share with the world. In those cases, I can rebase and toss out the commits entirely.

While making one change, I frequently see some unrelated problem or potential for improvement. I can work on multiple things at once and keep them and myself from getting confused by giving each change its own commit with obvious messages, which can all be squashed and re-ordered into separate atomic commits in the final rebasing.

I agree with all of Seashell Salesman's examples as well; ideally every commit on trunk would be green, and I have a lot of co-workers who notice when it isn't. What's most helpful for development is commits which are frequent, and what's most helpful for collaboration are commits which are flawless.

# ? Oct 17, 2015 20:10

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Blinkz0rz posted:

For the uninformed, can you explain the process you'd use (not commands) to determine how to take commits you make and turn them into commits you share? I have a lot of difficulty understanding the difference unless every commit you make is "WIP" or "gently caress WHY DOESN'T THIS WORK?"

An actual wip bug-fix branch I have right now has the following commit messages: "DELETE poo poo", "test", "test", "test", "test", "fix", "fix", "test", "fix". The first commit removes code unrelated to the bug which makes debugging things more time consuming, and will be discarded entirely before I create the PR. The "test" commits are me writing/improving unit tests which reproduce the bug, and the "fix" commits fix the issues exposed by the new tests. Before creating the PR I will discard the DELETE poo poo commit, squash all the test and fix commits to two separate commits, rerun with just the "test" commit to verify that it does actually demonstrate the bug being fixed with no other changes, and then combine them to a single commit and give it an actually commit message describing what it does.

Pre-git my workflow was just not commit anything at all until that end point, and it was a giant headache that occasionally resulted in accidentally losing work.

This all assumes that the observed problem does all boil down to a single bug in the code; if there are multiple bugs that need to be fixed to resolve the reported problem then each one will get its own commit.

# ? Oct 17, 2015 23:58

ExcessBLarg!: Sep 1, 2001

Seashell Salesman posted:

I just find that when making lots of bug fixes and working on multiple copies of the same repo across multiple physical drives on my dev machine at work that it's sometimes easier to just start tearing into an issue making commits before I want to think of a branch name and point that at a commit.

Call it the "foo" branch then. When you think of a good name "git branch -m foo good_name".

Otherwise, to be honest, you're operating on the edge of sanity with this "it's only in reflog" stuff. There's a reason why git warns you when you get on a detached head to begin with. It's dangerous too, since the wrong invocation of "git gc" could blow that away.

# ? Oct 18, 2015 03:24

Edison was a dick: Apr 3, 2010; direct current only

Plorkyeran posted:

git checkout `git rev-list --max-count 1 branchname`

code:

git checkout `git rev-parse branchname`

rev-parse is the magic for when you want to know the commit sha1 of something (or the tree sha1 if you want that).

It's also the go-to tool for generating command-line parsers (with --parseopt), or querying a bunch of other information, like whether you've run the command in a git repository, where the top of the git repository is, which magic environment variables are set...

It's basically where they shoved all the shell utility commands.

# ? Oct 18, 2015 10:38

wwb: Aug 17, 2004

revmoo posted:

Crazy poo poo, so you either keep around hundreds/thousands of feature branches so you can keep track of your commit history, or you say "eh, screw it" and merge/delete as you go. So basically your commit history is just a list of dates branches were merged in. To me, branching is an absolute requirement. Every ticket/task gets a branch, you do the work, test it, and merge in. But if you are using proper branching hygiene, then it means you get no commit history other than who/when a branch was merged. It almost seems pointless to use a VCS at that point if you're not tracking commit history. We often have feature branches that will stay open for months with hundreds, if not thousands of commits, and I couldn't fathom throwing all of that history away once the feature is complete.

I get how you can make it work, but it is a far, FAR weaker VCS just on this one issue alone. Hell, you can't even do something like 'git bisect' to track down the commit a bug was introduced if you have no commit history to bisect!

I don't find it that crazy myself -- I *like* to have that granular level of primary source history around if I need it. You can filter branches pretty effectively when looking at SVN, and keep in mind you aren't carrying the entire repo history with you so this works a bit better in practice.

SVN is a very, very different model from perhaps a different era. If you want it to behave like git it sucks, just ask linus. On the flip side when you want git to behave like SVN that can also suck. Go figure.

# ? Oct 19, 2015 15:01

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 20:09

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

fletcher posted:

I upgraded my Git for Windows to 2.6.1 and now none of the y/n type prompts show up in MINGW64.

For example, the following python script just kinda hangs, I never get the prompt:
code:
test = raw_input('this is a test: ')
print(test)
edit: If I just hit enter, then I see the "this is a test: " output and the program quits

Got some more info on why this is happening https://github.com/git-for-windows/git/issues/491#issuecomment-149002033

# ? Oct 19, 2015 20:35

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›100 »