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)

Dromio: Oct 16, 2002; Sleeper

Just found gource and had to share. If you've got a few minutes, download this and point it at your git repository. Hypnotic AND informative

# ¿ Sep 23, 2009 22:36

Adbot: ADBOT LOVES YOU

# ¿ May 7, 2024 09:20

Dromio: Oct 16, 2002; Sleeper

BizarroAzrael posted:

Okay, back to my recurring problem with conflicts in SVN. If a guy has an unversioned file in the project, and someone commits a file by the same name, the resulting conflict kills the update. Updates can take over an hour so it's done at night, and is followed by a build on the resources within, so this leads to a lot of lost time.

Maybe I misunderstand the problem, but if you don't want the files in source control it's usually a good idea to use svn:ignore.

# ¿ Oct 8, 2009 00:44

Dromio: Oct 16, 2002; Sleeper

I've used SharpSVN to interact directly with a repository as a client. I forget how well it works against an existing working copy, but I expect it should be fine.

# ¿ Feb 3, 2010 16:03

Dromio: Oct 16, 2002; Sleeper

Fly posted:

It depends on how firm the management position is. Some shops just continue to use VSS because they started with it, and changing processes is disruptive. If one were committed to staying at the place, then eventually reasonable management should be open to well-reasoned proposals for change from respected team members.

I think the choice of source control systems also says something about the culture of the development group. During my last interview the dev manager asked "What are your thoughts on source control?" and I replied "it's a requirement for any serious development team, I've used most major ones but prefer a distributed model like git/mercurial, blah blah". He looked at me blankly and then muttered that they didn't have anything in place yet. That was a very big negative in the interview-- It indicated to me just how lacking the dev team was in disciplined processes.

I've also had multiple discussions with people who were so afraid of not having locked access to a file like VSS. "What if I work on something while Bill does?" Again, this is a good indicator that their code architecture is hurting and they haven't really paid attention to separation of concerns.

So yeah, I think knowing something about a group's source control system is a HUGE indicator of what you're getting yourself into. It hasn't stopped me, but it prepared me for how much I'll have to work with the team on improving some aspects of their craft.

# ¿ Feb 14, 2010 14:54

Dromio: Oct 16, 2002; Sleeper

I'm trying to create a new remote repository for my git repo using the guide I found here. It seems pretty straitforward, but I'm failing.

I'm at my work machine (behind a NAT firewall), trying to push to my home machine. The home machine is running cygwin openssh.

First I ssh into the home machine and do the following:

code:

ssh myhomemachine
mkdir myapp.git
cd myapp.git
git --bare init

Then on my work machine I tried pushing to the home machine:

code:

cd myapp
git remote add origin ssh://myhomemachine/myapp.git
git push origin master

But it fails with "fatal: The remote end hung up unexpectedly". Anyone have any clues on what I might be doing wrong?

# ¿ Mar 9, 2010 15:17

Dromio: Oct 16, 2002; Sleeper

Lysidas posted:

Try this instead:
code:
git remote add origin myhomemachine:myapp.git

This worked-- thank you!

I'm not a fan of using the gui for git either. I relied heavily on tortoisesvn to get things done, but with git I feel like it just doesn't cover everything I need. I only want UI tools for diffs and logs.

# ¿ Mar 9, 2010 20:55

Dromio: Oct 16, 2002; Sleeper

I think big diffs in binary files slow it down too. So if you check-in images or dlls that change often that could hurt.

# ¿ Sep 16, 2010 21:20

Dromio: Oct 16, 2002; Sleeper

Mithaldu posted:

Are you sure you're using straight git and not git-svn?

As a git-svn user, it's not slower for me. "git log" is near instant for me. Even tortoisegit log is near instant. The only slowdowns I hit are when the designer checks in 400M+ video files

I'm trying to move from msysgit's bash to msysgit inside cygwin's shell. I'm sick of having to switch back and forth between the environments, and I had a bad time with cygwin's git-svn. I'm doing pretty well with it EXCEPT when I have my laptop clone the repo from my desktop machine.

So, my desktop machine has my main git repo. I use git-svn to keep it in sync with our svn server out there. Then on my laptop I've cloned the repo off my desktop. Worked fine. But now if I "git pull origin" I get the following error:

"bash: git-upload-pack: command not found"

I don't see a git-upload-pack command in my msysgit folder on either machine. Any clues what's going on?

# ¿ Apr 19, 2011 15:06

Dromio: Oct 16, 2002; Sleeper

Dromio posted:

As a git-svn user, it's not slower for me. "git log" is near instant for me. Even tortoisegit log is near instant. The only slowdowns I hit are when the designer checks in 400M+ video files

I'm trying to move from msysgit's bash to msysgit inside cygwin's shell. I'm sick of having to switch back and forth between the environments, and I had a bad time with cygwin's git-svn. I'm doing pretty well with it EXCEPT when I have my laptop clone the repo from my desktop machine.

So, my desktop machine has my main git repo. I use git-svn to keep it in sync with our svn server out there. Then on my laptop I've cloned the repo off my desktop. Worked fine. But now if I "git pull origin" I get the following error:

"bash: git-upload-pack: command not found"

I don't see a git-upload-pack command in my msysgit folder on either machine. Any clues what's going on?

I found git-upload-pack, it was in the libexec folder of msysgit. I added that to my PATH and got past that issue.

But now my git pull origin gives me a new error-- "fatal: '/cygdrive/d/Projects/theProject' does not appear to be a git repository". Of course if I ssh to that server and browse to that folder it IS a repository. And it was initially cloned from there!

# ¿ Apr 19, 2011 19:37

Dromio: Oct 16, 2002; Sleeper

My original clone was from a cygwin git installation, not msysgit. So it turns out msysgit doesn't actually know about the cygwin paths. I had to change my origin path from /cygdrive/d/Projects/theProject to D:/Projects/theProject. Now everything is smooth.

# ¿ Apr 20, 2011 17:14

Dromio: Oct 16, 2002; Sleeper

Sharrow posted:

Can someone recommend a workflow for a small team starting out with git?

I know enough to get by, but only really as a single user. Most of the others have only used SVN. We'd also like to use Github as a central repository.

This kind of branch model looks interesting and easy enough to follow, but like I say, I don't know enough to tell if it's actually terrible or not.

I've heard good things about git-flow. This guy gives a nice concise example of it.

# ¿ May 27, 2011 14:56

Dromio: Oct 16, 2002; Sleeper

epswing posted:

I begrudgingly opted for SVN instead of a DVCS because I didn't want to deal with teaching the designers how DVCS works. (They barely get SVN.)

This is why I use git-svn. The people who just aren't ready for git use svn. But me, I get all the power of local branches and rebases and squashing commits and blah blah blah. It's wonderful.

# ¿ Aug 18, 2011 17:06

Dromio: Oct 16, 2002; Sleeper

I'm switching our team from svn to git. I've been using git-svn for a long time and thought I had a pretty good handle on it, but now that I've got everyone using git I see I need to change my workflow a little bit.

How do you handle feature branches and collaboration? Especially if you want to merge more than once. Say I make a new branch from master called features/AddAWidget. I hack on that branch for a while until I want to incorporate it in the build, so I merge features/AddAWidget into master and push it. Then later I want to refine that feature a bit, so I checkout that same branch. Here's where I get confused...

I used to 'git rebase master' to keep my feature branch up to date. But now that I'm sometimes pushing and sharing that branch, it seems that's a bad idea. So what do I do? Do I merge feature into master, then merge master back into feature?

I'm getting a little confused here.

# ¿ Oct 25, 2011 15:58

Dromio: Oct 16, 2002; Sleeper

Mithaldu posted:

Once you've merged it into master it's best to leave it at that and just make a new branch if you want to change that feature again.

What if I'm doing something like described here? If I merge the feature branch into the "develop" branch using "--no-ff" will I be able to continue working on the feature branch and merge it into develop again later? Even if I don't keep the feature branch up-to-date from changes others have put into develop elsewhere?

# ¿ Oct 25, 2011 17:14

Dromio: Oct 16, 2002; Sleeper

Mithaldu posted:

But honestly, i'd suggest to gently caress merging and rebase your poo poo.

That's what I had been doing when I was working in the remote repository alone. But now it complains if I push a branch to origin after rebasing. And that makes sense-- I can't rewrite history if someone else might have checked it out elsewhere. I want to do collaborative work on features moving forward, so it's going to be a bit of trouble.

# ¿ Oct 25, 2011 20:29

Dromio: Oct 16, 2002; Sleeper

I'm think I'm "doing it wrong" with git and trying to force it to follow my desired workflow.

I have a branch called "Production" that contains the code that's currently on Production.
I have a branch called "Development" that contains all the code that's been in development and the developers feel like might be ready for release, but is untested.
I have multiple feature branches like "feature/addTotalCountToReport" where a developer implemented a specific feature.

When a developer starts a task, they make a branch off "Development" and start their work. When they're done with the task, they push their feature branch to origin and merge it back into Development so it gets automatically built on our shared dev server for testing.

Then our QA guy comes to me and says "I want to deploy feature/addTotalCountToReport, but not feature/bigGiantChange because it still needs work". Originally I thought it was as easy as merging feature/addTotalCountToReport into my Production branch and building. But because that was branched from Devlopment originally, when I merge it'll bring in code from previous development branches that might not be wanted.

So how do I fix this? Should feature branches be built off Production, not Development? I think this might confuse the developers because they won't see the bugfix they did yesterday.

Or do I cherry-pick all the commits from the feature branch into Production? That seems kind of nasty, but seems to work.

# ¿ Nov 2, 2011 15:45

Dromio: Oct 16, 2002; Sleeper

Mithaldu posted:

Can we get a screenshot of what tortoisegit thinks this looks like? I have the feeling that that split right there is your issue. Normally you'd use tags, and if appropiate, localized small bugfix branches, to mark production stuff.

I'm having a terrible time uploading to imgur, but suffice it to say that the history log looks like a complete mess.

I'm not sure how to use tags to do what I want here. I want three devs to be able to work on 9 different features, and be able to pick and choose to only include code from feature 4 of 9 into production, then later be able to come back and add feature 3. But maybe it's just not really feasible.

My current thinking is that we can do it if we start branching features from Production and forget about the "Dev" branch altogether. So the workflow might be

code:

git checkout Production
git checkout -b feature/Whatever
... do the work and make the commit(s)
... ready to hand off for QA
git checkout Production
git checkout -b QA
git merge feature/Whatever
git push origin QA (so the CI server can see it and build/test)
... QA PASSES
git checkout Production
git merge QA
git push origin Production
git branch -d QA
git push origin :QA
... build and push to production server

Would this accomplish my goals? I think I SHOULD be able to easily merge a feature branch back into production code (with the usual possible conflicts for long-running branches). What other pitfalls would I encounter?

# ¿ Nov 2, 2011 17:49

Dromio: Oct 16, 2002; Sleeper

Not REALLY a git question, but it's a problem I'm sure many people have to deal with. How are you handling "transient" code for feature branches in git?

I need to write a new feature. That feature includes the need for an "ALTER TABLE" script on our database to add a new column.

The only thing I can think of is to create a "/Migration/SomeArbitraryName" folder inside the repository on that branch. But then when you merge back to master you end up with a whole bunch of subfolders under the /Migration folder. This seems "nasty" to me. And what would the name of that subfolder be? I could use a bug-tracking ticket number, but sometimes I want to develop without having to deal with a bug tracking system.

Or maybe just a single "Migration.sql" file. When I merge multiple branches in, it'd build up a big script to do all the changes just for those branches. Sounds neat, but maybe I'm missing something important with that.
EDIT: But then I'd end up needing some way to clear it out after pushing it to production. Seemed smart, but that's a bit of a mess.

As of right now I don't have an automated build/deploy for SQL changes, but I'd like to be able to do so eventually when I push these changes to master. How are you handling this sort of thing?

Dromio fucked around with this message at 17:33 on Nov 10, 2011

# ¿ Nov 10, 2011 17:28

Dromio: Oct 16, 2002; Sleeper

I've been deleting branches from our remote git repository using git push origin :feature/DoThisThing and I thought it was working. But now I go to my OSX machine and do a git fetch; git branch -r and the branch still appears there! How can this be? If I try to delete it again from the OSX machine it tells me that it's an "unqualified destination".

My list of remote branches on this machine is getting really long! Any ideas how to clean this up?

# ¿ Nov 16, 2011 15:39

Dromio: Oct 16, 2002; Sleeper

But how?

pre:

$ git branch -r
...
origin/feature/thisIsDone
...

$ git push origin :feature/thisIsDone

error: unable to push to unqualified destination: feature/thisIsDone
The destination refspec neither matches an existing ref on the remote nor
begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to 'git@ourserver:ourrepo'

$ git branch -D feature/thisIsDone
error: branch 'feature/thisIsDone' not found.

$ git branch -D origin/feature/thisIsDone
error: branch 'origin/feature/thisIsDone' not found.

We're using gitolite for the origin repository, if that makes any difference. It's weird that they're showing up here on the OSX machine but not on my Windows/msysgit machine.

# ¿ Nov 16, 2011 15:59

Dromio: Oct 16, 2002; Sleeper

Lysidas posted:

git remote prune origin will delete your local copies of remote branches that no longer exist. This process is not automatic.

That did it! Thank you very much.

I love using git, but every time I have to tell my team about one more esoteric thing like this I see their faces grow a little bit darker. The benefits are enormous, but there really are a lot of :wtf:

moments.

# ¿ Nov 16, 2011 16:08

Dromio: Oct 16, 2002; Sleeper

My (all windows based) team has started to get used to git and we've got a pretty good convention around branch names. However, every once in a while someone will accidentally push a branch with the something in the wrong case. For example, the original branch was "ticket/3092--FixSomething" and the guy checks it out but then somehow pushes to "Ticket/3092--FixSomething".

So now, whenever I do a git fetch it tells me there's something new:

code:

$ git fetch
From theserver
 * [new branch]      Ticket/3092--FixSomething -> origin/Ticket/3092--FixSomething.  
$ git fetch
From theserver
 * [new branch]      Ticket/3092--FixSomething -> origin/Ticket/3092--FixSomething.

Over and over again. It makes me worry that if I push origin :Ticket/3092--FixSomething it might get confused and delete the wrong branch.

Any ideas on how to get out of this mess?

# ¿ Jan 16, 2012 03:45

Dromio: Oct 16, 2002; Sleeper

I talked with the Dev and he'd already realized his mistake and put his changes into the right branch, so I was able to just push origin :Ticket/3092--FixSomething and all is fine.

But this is the third time it's happened and it's really getting annoying.

# ¿ Jan 16, 2012 16:07

Dromio: Oct 16, 2002; Sleeper

They've managed to do it with msysgit, smartgit and tortoise.

# ¿ Jan 16, 2012 19:45

Dromio: Oct 16, 2002; Sleeper

Mithaldu posted:

Maybe they're using this stickykeys feature that uppercases the start of words, or are typing on a cellphone ...

This might not be too far off really. I do expect he has to use special accessibility tools that might be too vigorous in trying to make sure his text entry is correct-- this particular developer is partially paralyzed. I suppose I should ask him if our naming conventions are difficult with his tools.

# ¿ Jan 16, 2012 21:07

Dromio: Oct 16, 2002; Sleeper

Rescue Toaster posted:

This is a little beyond the scope of just 'source control' but maybe someone can point me in the right direction.

I'm getting into later stages of a CS degree, and starting to work on more serious projects (in C#/C++/VS2010 and java/intellij). And I'll be starting to work on more small team projects.

At a minimum, I'd like to setup a small repository, but also...

I'm looking to do a lot of CUDA/OpenCL programming, and rather than spend $1500+ on some portable workstation laptop, I figure it must be possible to setup some kind of central build/debug server where I can load up one or two high end GPUs for a pittance compared to any real laptop. I know at least Team Foundation can do this, but it seems like it's more geared for automated unit testing and the like, not actual live step-by-step debugging and tracing. And short of constantly using remote desktop, I don't see any way to interact with the programs as they're running. And of course Team Foundation doesn't help with any java work I want to do. (I do have full MSDN and can get TF server for free.)

I guess the simplest is just remote into a normal machine running VS/IntelliJ that's also setup with source control, check out, build and run. But that seems really clunky. I've run VS through remote desktop before and it's painful.

You probably want a "Continuous Integration" system. Most simply, it can watch your source control repository for changes and do a new build whenever code is checked in. Of course there's a ton of flexibility in what else it can do.

I prefer TeamCity for this. It has a ton of flexibility while still being relatively easy to set up. It's free for small projects and teams.

# ¿ Mar 7, 2012 21:11

Dromio: Oct 16, 2002; Sleeper

Anyone using gitolite to manage their git repository hosting? I've got a very simple setup where all users have full access to my repository there.

And today one developer managed to do something stupid with their GUI git client and pushed a bunch of code into our master branch right before a deployment. That sucked badly. Now I need to lock it down so only one or two developers can push to the master branch.

I'm having a terrible time figuring out gitolite's configuration syntax. Anyone had any experience with this?

# ¿ Mar 7, 2012 21:17

Dromio: Oct 16, 2002; Sleeper

Mithaldu posted:

Bullshit, that's not your dev being stupid. That's your devops being stupid and deploying from master instead of a dedicated release branch.

Ok, so I'm the stupid "DevOps". And the way I build for deployment is I create a new branch off the current production code (master), merge in the branches we want to release, then deploy. After that I merge this deployment branch back into master so it is always up to date.

So yeah, 'master' is the dedicated release branch. In fact we've renamed it to 'Production' here just to drive that point home. The only thing I think I should have done differently to prevent this is take a more carefully look at the master history when I started my latest deployment branch.

How else can I do this better?

# ¿ Mar 8, 2012 02:17

Dromio: Oct 16, 2002; Sleeper

Mithaldu posted:

Well, first off, step by step, what did happen here:

Whew... wasn't looking for all this. I know our process could use a bit of improvement, and that's not exactly what I was hoping to fix today. But since you asked, here goes:

Basic Development/Deployment Process

Our process is pretty simple. We have one "Production" branch which should ALWAYS be deployable. Developers create new branches from there to do their work. When the work is done they mark it "ready for QA" in our ticketing system.

Our product manager comes to me and says "I'm thinking about rolling out tickets 1,2, and 3". I create a new branch off Production. I merge in the branches created by developers for tickets 1, 2, and 3. I push this as a "QA" branch back to origin. Unit tests are run. The build is deployed to a QA server where we look over things and make sure they look right.

When we feel everything is good, I merge the QA branch back into Production. I run unit tests again. I deploy the result to our production server. I push Production back to origin so everyone who creates new branches will do so from the latest code base.

We do not automate deployment to production because I haven't been able to find a way to copy files from our CI system (in the office) directly to the production system (at our hosting service) without human interaction (entering a password). I'm still working on that part, but for now I simply enter a single command on my machine and it builds, runs tests, prompts me for the password, then copies and deploys. I know it's not ideal and I promise I'll try to find a better way.

Where *I* Went Wrong
This release took more time. When I made sure my local copy of Production was up to date, some files had been changed since QA was built. This isn't too unusual-- our designer will often update some minor UI assets without going through QA. But this wasn't one of those times. Instead, it was code changes from another developer. I absolutely SHOULD have examined these changes before rolling out. I failed. I updated my local copy of Production, then merged in QA. I ran the automated tests (which passed), then deployed.

What the Developer Did
The developer doesn't/can't use CLI git for various reasons. He's finally settled on SmartGit. Apparently he set up a tracking branch in SmartGit wrong when creating a new branch to do some work. SmartGit was pushing his changes back to Production without his even knowing it. He was as surprised as I was when I told him he had put code directly into the Production branch.

AND, he wasn't ready for this code to be shared, so he'd commented out the unit tests around this particular code so he could experiment. I've discouraged this practice, but he did it anyway. So when I ran my tests, all was green.

So...
We both made mistakes. I know that. He knows that. He doesn't WANT to be able to commit directly production, and has no real reason to. Which is why I asked about it. And hopefully Golbez's answer will do the trick.

# ¿ Mar 8, 2012 20:37

Dromio: Oct 16, 2002; Sleeper

Munkeymon posted:

]Git tracks permissions, right? Maybe the GH client has different ideas about what the Windows permissions mean than does the CygWin git system, which I normally use (and by 'normally' I mean I pull down code to use libraries - I'm not a regular git user).

I've dealt with then when switching between msysgit and cygwin on the same repo. I think it has to do with the core.filemode setting. See https://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/d0474d7afdcd36cc?pli=1 for a decent explanation.

# ¿ May 23, 2012 20:19

Dromio: Oct 16, 2002; Sleeper

My team is asking why some code is not where it's expected, and I'm confused by git for the first time in a very long time. Maybe someone here can tell me what's wrong.

I've got a branch with quite a few merges going on. Here's the history of the file in question:

pre:

*   95c2e96 Merge in stubGPGCC    (CODE IS GONE!)
|\  
| * 46dde8e remove URLME from Eprise 1 veps  (CODE WAS ADDED HERE)
* |   4e3c9d2 merged into prod                         (CODE DOES NOT EXIST HERE)
|\ \  
| |/  
| * 161e11a added signature and metadata for msgs and body

The code was added in 46dde8 but are NOT in the 95c2e96. The diff does not show it being removed in 05c2e96. Why did this happen?

Dromio fucked around with this message at 14:33 on Jul 9, 2012

# ¿ Jul 9, 2012 14:23

Dromio: Oct 16, 2002; Sleeper

ToxicFrog posted:

Diff 95c2e96 specifically against 46dde8 and see what it looks like.

At a guess, the merge used all the changes from 4e3c9d2 and dropped the ones from 46dde8e.

Yeah, git diff 46dde8 Path\To\TheFileInQuestion does show the changes. But gitk Path\To\TheFileInQuestion does not. Why wouldn't gitk show this?

So that merge was bad... and *I* was the one who did it. How did I mess this up? I'm pretty sure I didn't do something like "select all from theirs". Maybe I was just tired that day.

# ¿ Jul 9, 2012 16:31

Dromio: Oct 16, 2002; Sleeper

ToxicFrog posted:

git merge -s theirs would do this, as would accidentally hitting "use all from theirs" in mergetool. It's also possibly that it auto-merged and got it badly wrong, which is (a) a good reason to use --no-commit when merging and (b) probably worth a bug report if you can reproduce it.

I'm absolutely sure I didn't git merge -s theirs. It's kind of possible that I might have accidentally hit "use all from theirs" in a mergetool.

I'll keep the --no-commit flag in mind as I go forward, and see about reproducing it. For now, I get to untangle my mess and try to fix the code.

Thanks.

# ¿ Jul 9, 2012 17:15

Dromio: Oct 16, 2002; Sleeper

We've been using feature branches with git for some time and gotten pretty comfortable with them. However, there's one issue I don't have a good answer for. I often use "git branch -r --merged" on our current QA branch to see what features have been put into the latest build, but this only works until a developer updates a feature branch without telling me. Since the --merged option only shows branches FULLY merged into the current branch, I'll end up not seeing that feature/AddedReallyCoolStuff is partially in QA but isn't fully up to date.

Any ideas on how to handle this sort of situation without keeping some sort of list myself outside of git? I'm not so good at that sort of thing.

# ¿ Sep 4, 2012 16:15

Dromio: Oct 16, 2002; Sleeper

I think my local git repository just blew up. Any time I try to change branches it says "fatal: bad revision 'refs/heads/temp'". Any ideas on recovery?

# ¿ Sep 21, 2012 17:00

Dromio: Oct 16, 2002; Sleeper

Lysidas posted:

What does .git/refs/heads/temp contain?

What does .git/HEAD contain?

What is the output of git fsck?

1. There is no refs/heads/temp! There's a refs/heads/TEMP (not what the error says!) and that folder is empty.
2. git/HEAD is a file. It has a hash in it. This is the hash that is showing up in my prompt (that usually shows what branch I have checkedout).
3. git fsck gives that same error, then a long long list of dangling blobs, trees, and commits.

EDIT: All of this was using cygwin git. When I switched to msysgit I was able to change branches and clean things up. But it's still giving the error about refs/heads/temp, which has me pretty nervous.

Dromio fucked around with this message at 19:13 on Sep 21, 2012

# ¿ Sep 21, 2012 18:56

Dromio: Oct 16, 2002; Sleeper

No Safe Word posted:

File systems in Windows** are not case-sensitive so they're the same thing.

Maybe, but most things in Cygwin do care about the case. I think git under Cygwin does.

Anyway, the folder is empty. No idea what if anything should be in there.

# ¿ Sep 22, 2012 04:14

Dromio: Oct 16, 2002; Sleeper

Edison was a dick posted:

You shouldn't have a folder there, folders only exist in .git/refs when it's the beginning of another ref, such as refs/heads/TEMP/foo. Remove the folder, to see if that fixes it.

I seem to have quite a few empty folders in there. Deleting that one did get rid of the error. git fsck still complains about a lot of other dangling items.

I've made a new clone of the remote repository and copied over my local branches from the bad one. I don't trust it anymore.

# ¿ Sep 23, 2012 00:57

Dromio: Oct 16, 2002; Sleeper

I'm looking at the history of my master branch. I see one John has made a change to a script. I see Alice has done a merge. John's change to the script are gone after the merge. git log thescriptfilename does not show John's commit. I can only tell it happened using gitk. So the tree is like so:

pre:

*   40bd7b0 - Merge branch 'master' of github.com:MyProject  (2 days ago) <Alice>
|\
| * d829a37 -Fixed the script (3 days ago) <John>
* | e4f98be - Did some work on something else (2 days ago) <Alice>

What happened o John's changes? Is there anything I can do to see what Alice actually did in 40bd7b0? git diff 40bd7b^..40bd7b gives me nothing.

# ¿ Oct 3, 2014 15:44

Adbot: ADBOT LOVES YOU

# ¿ May 7, 2024 09:20

Dromio: Oct 16, 2002; Sleeper

The only reason not to always prune is that you might still want that reference to a deleted branch. Someone at work accidentally performed a 'git push origin :master' on us once.

Luckily, it's a distributed system and we have about 10 machines that still knew what master was. It was easy to push it back.

I prune only when I get annoyed at how long my list of remote branches is, and I have a pretty high tolerance

# ¿ May 7, 2016 04:43

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