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 »

Spatulater bro!: Aug 19, 2003; Punch! Punch! Punch!

ExcessBLarg! posted:

Maintain a development branch that's separate from deployment. For example, develop on "develop" and deploy from "master". Don't commit any compiled code to the develop branch, but do commit it to master. So, your procedure every time you deploy would be: commit outstanding changes to develop, checkout master, merge develop, run the compiler, add and commit the new compiled code, then push to your deploy remote.

Revisiting this. I've been following this procedure recently and it works well. But one thing that bugs me are the unnecessary "Compile CSS" commits. In addition to the merge commits, that's a lot of crufty commits in my log. Is using rebase instead of merge the solution to this?

# ? Jun 30, 2015 16:45

Adbot: ADBOT LOVES YOU

# ? May 30, 2024 23:14

ExcessBLarg!: Sep 1, 2001

If the deployment branch is really nothing more than merge commits and "compile CSS", just ignore it's history. It doesn't tell you anything about the code that "git log develop" won't tell you, aside from when exactly you've deployed.

Rebase isn't really a solution here. It can help avoid the merge commit, but it rewrites all the commit hashes, which divorces the history of your deployment and development branches. It also won't work if your develop branch contains merges too.

If you want, you can save the separate "compile CSS" commit by making it part of the merge commit. Just do "git merge --no-commit develop", generate and add the CSS, then commit the whole thing. There's even an argument for doing this, as it ensures that the generated CSS always reflects the post-merge source state.

# ? Jun 30, 2015 17:48

Spatulater bro!: Aug 19, 2003; Punch! Punch! Punch!

ExcessBLarg! posted:

If the deployment branch is really nothing more than merge commits and "compile CSS", just ignore it's history. It doesn't tell you anything about the code that "git log develop" won't tell you, aside from when exactly you've deployed.

Rebase isn't really a solution here. It can help avoid the merge commit, but it rewrites all the commit hashes, which divorces the history of your deployment and development branches. It also won't work if your develop branch contains merges too.

If you want, you can save the separate "compile CSS" commit by making it part of the merge commit. Just do "git merge --no-commit develop", generate and add the CSS, then commit the whole thing. There's even an argument for doing this, as it ensures that the generated CSS always reflects the post-merge source state.

Ah, that makes sense. In fact I think you even instructed me to do "--no-commit" on the last page and I just forgot. That should cut down on some of the superfluous commits.

# ? Jun 30, 2015 18:39

SurgicalOntologist: Jun 17, 2004

Is there a good way to use Jekyll with GitHub pages and include subrepos? The submodules need to be built, and the resulting files are in the respective .gitignores. But then the build files will need to be committed to the master repo to publish to GitHub. I'm scratching my head trying to figure out how to automate the build.

The builds are things like running scripts that create image files, run pandoc, latex, etc. Not like actual gcc or anything, but that probably doesn't matter. I use Makefiles everywhere so some kind of recursive make through the directories should work but I'm stuck at the part where I have to commit the static files. I could have a bunch of mv commands in my build scripts and put the static files in known places outside of their subrepos. But I'm wondering if there's a better way that won't require so much micromanaging.

# ? Jul 13, 2015 20:37

good jovi: Dec 11, 2000; 'm pro-dickgirl, and I VOTE!

SurgicalOntologist posted:

Is there a good way to use Jekyll with GitHub pages and include subrepos? The submodules need to be built, and the resulting files are in the respective .gitignores. But then the build files will need to be committed to the master repo to publish to GitHub. I'm scratching my head trying to figure out how to automate the build.

The builds are things like running scripts that create image files, run pandoc, latex, etc. Not like actual gcc or anything, but that probably doesn't matter. I use Makefiles everywhere so some kind of recursive make through the directories should work but I'm stuck at the part where I have to commit the static files. I could have a bunch of mv commands in my build scripts and put the static files in known places outside of their subrepos. But I'm wondering if there's a better way that won't require so much micromanaging.

Github claims that Pages will pull subrepos automatically.

If they need to have any kind of command run against them, though, I think you're beyond what Pages can provide. They're not gonna let you just run arbitrary commands on their machines with every push.

# ? Jul 13, 2015 20:54

SurgicalOntologist: Jun 17, 2004

good jovi posted:

Github claims that Pages will pull subrepos automatically.

If they need to have any kind of command run against them, though, I think you're beyond what Pages can provide. They're not gonna let you just run arbitrary commands on their machines with every push.

Right, that's the problem, so I'm trying to think of the best way to pull them myself and commit the resulting build files before pushing up to GH.

For example I could do

build.sh

code:

start_dir=$(pwd)

cd /tmp
git clone [url]https://github.com/SurgicalOntologist/cv[/url]
cd cv
make all
mv cv.pdf $start_dir/files/cv.pdf
mv cv.html $start_dir/_include/cv.html
cd $start_dir
git add files/cv.pdf
git add _include/cv.html

# ... etc for the other subrepos

git commit -m 'automated build'
git push

but it would be nice if it could be more automatic, for example pull all submodules, recursive make, then an automated add and commit. But in this case would I be hamstrung by the fact that build files are in the subrepos' .gitignores?

Maybe what I'm asking is "can I commit a file in a subrepo's .gitignore to the master repo?" but I didn't ask that directly because I strongly suspect this is an XY thing and there's a better way.

Edit: maybe

code:

mdkir -p subrepos/
cd subrepos/

for repo in ../subrepos.txt
  git clone $repo
end

for dir in *
  cd $dir
  make all
  rm .gitignore
  cd ..
end
cd ..

git add subrepos/*
git commit -m 'automated build'

SurgicalOntologist fucked around with this message at 21:18 on Jul 13, 2015

# ? Jul 13, 2015 21:04

EvilRic: May 18, 2007; come have a nice cup of tea!

Does anyone know of a good book or webpage for learning about Git over http(s) preferably using Apache?

I have been reading the Pro Git book and while it has some detail it's not very clear on setting it up.
I'm not sure if it's meant to run on top of a git:// setup or if it will run on its own.

I'm trying to get it setup with a self compiled Apache but not having much luck as i'm not entirely sure what URL to use once it's configured.

# ? Jul 16, 2015 15:13

ToxicFrog: Apr 26, 2008

EvilRic posted:

Does anyone know of a good book or webpage for learning about Git over http(s) preferably using Apache?

I have been reading the Pro Git book and while it has some detail it's not very clear on setting it up.
I'm not sure if it's meant to run on top of a git:// setup or if it will run on its own.

I'm trying to get it setup with a self compiled Apache but not having much luck as i'm not entirely sure what URL to use once it's configured.

I don't really know anything about git-over-http because the recommended approach is git-over-ssh instead; is there a particular reason you need http specifically?

# ? Jul 16, 2015 15:26

EvilRic: May 18, 2007; come have a nice cup of tea!

ToxicFrog posted:

I don't really know anything about git-over-http because the recommended approach is git-over-ssh instead; is there a particular reason you need http specifically?

My main reasons were that the book seemed to encourage it as a good way to access the server and when using svn in the past we used it over https as a secure way to perform checkouts and commits.
I think in that instance though it was as an alternative to the svn protocol though rather than SSH.
The other reason is that I already have https open to the internet but not SSH so I could have avoided opening another port.

However if the consensus is that SSH is the way to go then i will go for that.

# ? Jul 16, 2015 16:16

itskage: Aug 26, 2003

Anyone have any experience with initiating a large repo from existing files in git+github? It's an older base with over 64,000 files and I'm not really sure what the best way to approach it is. All of my searches keep leading me to topics about file size.

As it stands if I try to point git at the directory and add the files, then I just sit around as the CPU spikes to 100% for hours with no end in sight. Maybe I just need to be more patient and let it go overnight?

# ? Jul 22, 2015 02:18

chutwig: May 28, 2001; BURLAP SATCHEL OF CRACKERJACKS

itskage posted:

Anyone have any experience with initiating a large repo from existing files in git+github? It's an older base with over 64,000 files and I'm not really sure what the best way to approach it is. All of my searches keep leading me to topics about file size.

As it stands if I try to point git at the directory and add the files, then I just sit around as the CPU spikes to 100% for hours with no end in sight. Maybe I just need to be more patient and let it go overnight?

You could add the files one at a time with something like find . -not -path ./.git\* -not -name . -exec date \; -print -exec git add \{\} \;, which will print out a timestamp, the filename, and stage the file to the commit. It should not take Git a long time to create a repo of 65,000 files, though, unless you're checking in binary files of some sort.

# ? Jul 22, 2015 02:58

itskage: Aug 26, 2003

chutwig posted:

You could add the files one at a time with something like find . -not -path ./.git\* -not -name . -exec date \; -print -exec git add \{\} \;, which will print out a timestamp, the filename, and stage the file to the commit. It should not take Git a long time to create a repo of 65,000 files, though, unless you're checking in binary files of some sort.

Thanks for the reply. What I ended up doing was just adding and committing the larger directories one by one, instead of using the script. Everything worked out pretty well.

# ? Jul 22, 2015 19:08

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

I don't normally use git (I'm one of those weird Mercurial people) I want to make sure I am doing this right.

So there is master on a Gitlab server, which the team has cloned. A designer type (this is a web project) created a branch - style_changes - and made lots of changes. Per gitlab, they pushed their branch and made a "Merge Request" (which is like a pull request on github I guess?) I can view the diff via gitlab and that is great, but these are visual changes.

So what I need to do is get that remote branch down locally, look at the visual changes, and see if they are all well and good. To do that I should:

code:

git fetch
git checkout style_changes

Take a gander at the pretty, then I go back to my work by checking out my branch again. When the merge request happens and GitLab deletes the style_changes branch, it will be removed locally for me next time I do a pull, or will I have to do something on my end for that?

# ? Aug 4, 2015 15:35

wolffenstein: Aug 2, 2002; Pork Pro

since you probably don't care about the branch after you've looked at it, you can delete it with

code:

git branch -d style_changes

and be on your merry way

# ? Aug 4, 2015 15:47

ExcessBLarg!: Sep 1, 2001

Lumpy posted:

When the merge request happens and GitLab deletes the style_changes branch, it will be removed locally for me next time I do a pull, or will I have to do something on my end for that?

There's actually two branches that are created in your local repository and if you want to keep references to a minimum, you have to delete them both.

First, when you run "git fetch", it creates a new tracking branch "origin/style_changes". This branch automatically updates after any "git fetch" or related (e.g., git pull) command, and effectively gives you a local reference to the remote branch. However, the tracking branch does not delete automatically. After the remote branch is deleted, you have to run "git fetch -p" to prune your tracking branch of it.

Second, when you run "git checkout style_changes", you're actually creating a new, local branch that tracks "origin/style_changes". It's actually equivalent to the command "git checkout -b style_changes --track origin/style_changes", which in the old days of git you had to run explicitly. This branch neither automatically updates nor deletes. If you want to update the branch, you have to do "git checkout style_changes; git pull" which runs a "git fetch origin; git merge origin/style_changes" behind the scenes. To delete the branch, you have to run "git branch -D style_changes", in addition to the "git fetch -p" to remove the tracking branch as above.

If I were you, I wouldn't bother creating the local style_changes branch if you just want to temporarily checkout the remote branch to review it (and not make any commits). You can, instead, run "git fetch; git checkout origin/style_changes", which checks out the tracking branch directly. When the merge is done, you just have to run "git fetch -p" to clean up the tracking branch after.

# ? Aug 4, 2015 17:47

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

wolffenstein posted:

since you probably don't care about the branch after you've looked at it, you can delete it with
code:
git branch -d style_changes
and be on your merry way

ExcessBLarg! posted:

Lots of good stuff

Thank you both! Glad I am being "forced" to use git on this project, as it's making me actually learn a lot more about it than I had using lightly in other projects. It's interface is frustratingly baffling at times, but I like it a lot more the more I use it.

# ? Aug 4, 2015 20:16

Space Kablooey: May 6, 2009

I'm looking for a specific git tutorial where the author tries to illustrate git operations with actual files and folders. For example, each commit, the author copied the entire repository to a new folder, where then he explains that it is unsustainable and started copying only the changes and so on.

Does it ring a bell for anyone?

# ? Aug 6, 2015 16:53

Hyvok: Mar 30, 2010

How do I make a new repo from _part_ of an existing repository with git? I'm basically working on one (larger) project of mine, got some small lib from GitHub, ended up rewriting the whole thing and figured what the hell, I guess I could put it up to GitHub as a fork. So I would basically want to make a new repo from a couple of files from an existing repository. With quick googling I can just find info on how to make a new repo from a whole branch but that's not what I want to do, I think. Unless I make a new branch where I delete everything else, which sounds wrong.

# ? Aug 9, 2015 19:22

Dylan16807: May 12, 2010

HardDisk posted:

I'm looking for a specific git tutorial where the author tries to illustrate git operations with actual files and folders. For example, each commit, the author copied the entire repository to a new folder, where then he explains that it is unsustainable and started copying only the changes and so on.

Does it ring a bell for anyone?

That sounds like a weird way to start, since at a logical level git works with full snapshots and not changesets.

Then it deduplicates entire files, and sometimes compresses them together, but that gives a significantly different output from copying changes as changes.

Dylan16807 fucked around with this message at 19:33 on Aug 9, 2015

# ? Aug 9, 2015 19:30

ToxicFrog: Apr 26, 2008

Hyvok posted:

How do I make a new repo from _part_ of an existing repository with git? I'm basically working on one (larger) project of mine, got some small lib from GitHub, ended up rewriting the whole thing and figured what the hell, I guess I could put it up to GitHub as a fork. So I would basically want to make a new repo from a couple of files from an existing repository. With quick googling I can just find info on how to make a new repo from a whole branch but that's not what I want to do, I think. Unless I make a new branch where I delete everything else, which sounds wrong.

You probably want git subtree split, but not having used it myself I'm not sure exactly how to invoke it to get what you want.

# ? Aug 10, 2015 01:16

Space Kablooey: May 6, 2009

Dylan16807 posted:

That sounds like a weird way to start, since at a logical level git works with full snapshots and not changesets.

Then it deduplicates entire files, and sometimes compresses them together, but that gives a significantly different output from copying changes as changes.

It's entirely possible that I might be misremembering the progression.

The important part was that the author illustrated git using files and folders. His conclusion was that all those weird commands were somewhat similar to moving files around on special folders and keeping them around.

The reason I want this tutorial is that I may have to present a class/lecture to my classmates on git as a college assignment, and I thought that was a pretty nice starting point. :shobon:

# ? Aug 11, 2015 01:57

KoRMaK: Jul 31, 2012

I'm rebasing a branch, and I want a kind of specific behavior which seems available but I'm not completely sure.

I'm doing the following: git rebase -i

Then I edit the commits from 'pick' to 'edit'

What I'd like to happen is that each commit that is going to be commited paused before its commited but while it's staged. It seems to only be stopping at the staging process if there's a conflict. How do I get it to pause so I can view whats being added before I commit?

e: Hmm it seems like this might work git reset --soft HEAD^

KoRMaK fucked around with this message at 20:35 on Aug 12, 2015

# ? Aug 12, 2015 20:23

Chamook: Nov 17, 2006; wheeeeeeeeeeeeee

If you want to redo a bunch of commits, then you should probably just reset your branch to a certain commit and start again.

From my understanding, rebasing lets you gently caress around with your previous commits and adjust them quite a lot, but you've by default approved a bunch of commits in doing it so it won't pause for each.

# ? Aug 12, 2015 21:02

Vanadium: Jan 8, 2005

KoRMaK posted:

I'm rebasing a branch, and I want a kind of specific behavior which seems available but I'm not completely sure.

I'm doing the following: git rebase -i

Then I edit the commits from 'pick' to 'edit'

What I'd like to happen is that each commit that is going to be commited paused before its commited but while it's staged. It seems to only be stopping at the staging process if there's a conflict. How do I get it to pause so I can view whats being added before I commit?

e: Hmm it seems like this might work git reset --soft HEAD^

The idea seems to be that you just let the rebase process commit everything in the revision you want to edit, and then you adjust it with git commit --amend. With your git reset --soft, you'll basically lose out on the commit message when you finally decide to commit and otherwise the workflow would be the same as if you were amending, afaict?

# ? Aug 12, 2015 21:16

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

You also lose the commit date (unless you manually re-enter it).

# ? Aug 12, 2015 21:26

KoRMaK: Jul 31, 2012

I've been using it for a couple minutes now and it's just what I wanted. Commit dates and committer are preserved along with the commit message.

So here's the work flow

git rebase -i
change all the picks to edit
the rebase process starts
when it pauses, check the stuff that got comitted,
-if its all good then do git rebase --continue
-if its all bad, do git rebase --skip
-if its a mixed bag and I need to ditch some stuff, do git reset --soft HEAD^ then do normal workflow stuff with editing/staging. Once done and ready to move forward, do git rebase --continue and it commits with my altered stuff but retaining the date and committer

Just what I wanted!

# ? Aug 12, 2015 21:36

ToxicFrog: Apr 26, 2008

KoRMaK posted:

I've been using it for a couple minutes now and it's just what I wanted. Commit dates and committer are preserved along with the commit message.

So here's the work flow

git rebase -i
change all the picks to edit
the rebase process starts
when it pauses, check the stuff that got comitted,
-if its all good then do git rebase --continue
-if its all bad, do git rebase --skip
-if its a mixed bag and I need to ditch some stuff, do git reset --soft HEAD^ then do normal workflow stuff with editing/staging. Once done and ready to move forward, do git rebase --continue and it commits with my altered stuff but retaining the date and committer

Just what I wanted!

You should probably use git commit --amend here, since it's faster and handles weird edge cases properly.

# ? Aug 12, 2015 22:12

ExcessBLarg!: Sep 1, 2001

If I have to do some horribly complicated interactive rebase, I usually end up forking off the pre-rebase branch, "reset --hard" to the start commit, then manually cherry-pick and amending the commits as needed.

# ? Aug 13, 2015 17:39

KoRMaK: Jul 31, 2012

ExcessBLarg! posted:

If I have to do some horribly complicated interactive rebase, I usually end up forking off the pre-rebase branch, "reset --hard" to the start commit, then manually cherry-pick and amending the commits as needed.

That's basically what I'm doing but instead of cherry-pick, I'm rebasing interactive.

Also, i have to do git reset --soft HEAD@{0} after I do a HEAD^, then I can do an ammend and git rebase --continue

# ? Aug 13, 2015 17:41

SurgicalOntologist: Jun 17, 2004

I'm running into this bug on hg-git and the discussion on workaround is over my head.

I have a library that I initially started working on using hg, but eventually decided to put on github for more exposure. So I got hg-git set up, and developed a workflow where I would work on bitbucket and occasionally push everything to github. GitHub is where I set up the issue tracker and such.

I stopped working on it for a while and came back to it, made a new version through a series of hg commits. I try to push to GitHub, and I get

code:

abort: branch 'refs/heads/master' changed on the server, please pull and merge before pushing

So I pull from github, and I end up with every commit doubled. Basically hg can't see any correspondence between the two repositories. So I found the above issue, and apparently I must have switched hg-git versions (likely multiple times) and the changeset hashes don't align. I'm sure I've re-clone the repo at least once so I'm out of luck as far as I can tell.

What I would like to do is get rid of this stupid system of trying to have it both ways, and stick with git if only because that's where people have starred it and such. But I need to get this latest series of commits over there somehow. There are two options that I could handle with my limited knowledge:

1. Delete the github repo, create a new one, push to it using hg-git, then delete the local hg repo and clone again using git. Delete the bitbucket repo to avoid this happening again.
2. Clone using git, copy over the files from the hg repo, make a new commit. Push again, delete hg/bitbucket repos. Effectively a giant squash since the last time the repos were synced.

The problem with (1) is I lose everyone who's following the project (right?), the problem with (2) is I lose the recent history (i.e., I'd rather not squash). Is there a third way? Can I somehow use hg-git or git-remote-hg to grab only the new hg commits and rebase them onto the git repo? It's only 22 commits so if I have to do something by hand it's feasible. But I have basically 0 knowledge of git/hg internals and as I said, the discussion in the issue report I linked above is over my head, but obviously relevant.

Basically, how can I untangle this mess?

# ? Aug 25, 2015 18:58

Vanadium: Jan 8, 2005

You could probably convert your hg work into a fresh git history, use git format-patch to turn the new commits that don't have equivalents on github into series of patches, then switch to the github history and use git am to apply the patches as commits again.

Afterwards you can probably use hg-git all over again to convert the git history into a hg repos so you can keep working with hg, though that'd break your bitbucket history. I don't know enough about hg to figure out how that mapfile stuff would work

(For (1) you could also force-push your new git history to your existing github repostiory, that way you won't lose the stars or followers or whatever, but everybody will now have the problem you're having right now so it's a bad idea.)

# ? Aug 25, 2015 19:49

SurgicalOntologist: Jun 17, 2004

Thanks! Didn't know about format-patch and am, worked great.

# ? Aug 26, 2015 18:09

EvilRic: May 18, 2007; come have a nice cup of tea!

I have a repo on a server which I'll either be accessing on a local ip or via an ssh tunnel.

Is it possible to add both addresses to the client and check-in/out against which ever is accessible at the time?

I think I do the initial clone from the local address and then when I am first working remotely I would do "git add remote <remote address>"

Will that cause any problems where it gets confused because it's the same server?

# ? Sep 4, 2015 07:59

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

No. You'll have all the minor little annoyances of multiple remotes, but nothing additional due to them actually both pointing at the same remote repo.

# ? Sep 4, 2015 14:32

Vanadium: Jan 8, 2005

How much effort would it be to set up a no-op ssh tunnel when you're local? :v:

# ? Sep 4, 2015 20:53

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Git makes me feel stupid.

A few months ago I started hacking on an open source project hosted on Github. I cloned locally and started making a whole bunch of changes on a new branch. Today I made a very tiny, contained change that I want to submit as a pull request. I went back and clicked the "fork" link on Github and then set that up as a new remote so I could push to a repository I have permission to. Unfortunately I can't figure out how to isolate my tiny little changes (one commit) from all the other changes I've made on my branch.

In retrospect I think I should have created a clean branch from master and made my changes there, but I didn't. It seems like there should be an easy way to go back and do that now. It's only three lines so I could do it manually, but I know there's got to be a better way. I don't understand Git so I don't know what to Google for and quickly get confused by the results I do find.

# ? Sep 7, 2015 20:11

Vanadium: Jan 8, 2005

You can set up a clean branch from origin's master, and use git cherry-pick to grab a single commit (or a range of commits) from the branch you've worked on. Git will duplicate that commit as if the same changes had been made on top of the clean branch, with the same commit message and all.

# ? Sep 7, 2015 20:34

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Vanadium posted:

You can set up a clean branch from origin's master, and use git cherry-pick to grab a single commit (or a range of commits) from the branch you've worked on. Git will duplicate that commit as if the same changes had been made on top of the clean branch, with the same commit message and all.

That's just what I needed, thanks!

# ? Sep 7, 2015 20:56

Cingulate: Oct 23, 2012; by Fluffdaddy

Upstream is asking me to squash my horrible terrible branch. I'm not really sure what I'm supposed to be doing. I have followed this guide http://makandracards.com/makandra/527-squash-several-git-commits-into-a-single-commit (easy mode) and that's where I'm at right now, but I'm not entirely sure that's where I need to be - so I have my squashed head, but what do I push it to now? And how?

E: I think I solved it. Or rather, upstream told me what to do.

Cingulate fucked around with this message at 22:25 on Oct 4, 2015

# ? Oct 4, 2015 22:12

Adbot: ADBOT LOVES YOU

# ? May 30, 2024 23:14

Walked: Apr 14, 2003

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.

# ? Oct 5, 2015 15:04

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

«‹›100 »