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 »

Johnny Cache Hit: Oct 17, 2011

Jethro posted:

Named branches are permanent yes, and the branch name is an attribute of a changeset, so they do have to "exist everywhere

Cool - so named branches are still the heavy things I remembe...

Jethro posted:

but there has never been anything "heavy" about them

... oh.

# ? Nov 29, 2011 18:35

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 19:17

Mithaldu: Sep 25, 2007; Let's cuddle.

Jethro posted:

Named branches are permanent yes

So, an hg repo of the scope of the kernel git repo would have literally tens of thousands of branches stuck forevermore?

# ? Nov 29, 2011 18:53

Jethro: Jun 1, 2000; I was raised on the dairy, Bitch!

Kim Jong III posted:

Cool - so named branches are still the heavy things I remembe...

... oh.

Maybe I'm just being picky about the term heavy. If by heavy you mean "exist everywhere and everywhen a changeset does", then yes they are heavy, but so is a commit message.

Mithaldu posted:

So, an hg repo of the scope of the kernel git repo would have literally tens of thousands of branches stuck forevermore?

Just to clarify, named branches are as permanent as the changesets committed with those branch names. So, if you created a named branch in hg every time you would create a branch in git, and you pushed the changesets on those branches to some central repository, then those branches would exist in that repository and any repository that pulled those changesets from it.

But you wouldn't do that. You only create a named branch in hg when you want to make something permanent. Otherwise, if you want to branch you just do it. The problem with named branches in hg isn't that they stick around, it's that they're called "branches". It's true that the usual time to create them is when you want to create a new, long-lived branch, but they don't really have any connection to the concept of a branch, except that a changeset will inherit the named branch of its parent unless otherwise specified. I guess "group of changesets which may or may not correspond to a single, separate conceptual branch" is a bit much to type on the command line, though. On the other hand, "commit which is usually (but not always) the head of a conceptual branch" would be a little hard to type on the git command line.

Part of the "problem" with hg branches is that (I think) git culture leans more towards maintaining the fiction of a linear history whereas the standard hg workflow leans more towards branching and merging and keeping the history intact. There are some extensions (and a new feature in hg 2.0 called graft that is like git's cherry-pick) that let you do more "history munging", and I haven't even begun to wrap my head around mercurial queues, but in general the hg way isn't quite the git way.

If you really like how git handles branches, hg has a feature (formerly an extension) called "bookmarks" which more or less work the same.

# ? Nov 29, 2011 21:15

Mithaldu: Sep 25, 2007; Let's cuddle.

Jethro posted:

git culture leans more towards maintaining the fiction of a linear history

Nah. It leans towards viewing a repository as a directed acyclic graph, which can be refactored at any time and comes with some affordances so you don't end up with thousands of merge commits when hundred people work on the same thing. You CAN go all-out on having a linear history, but that's not what it's meant for.

Jethro posted:

You only create a named branch in hg when you want to make something permanent. Otherwise, if you want to branch you just do it.

What.

Can i have that in english?

I mean honestly now. I use branches for two things:

1. To temporarily store an experiment or feature i'm working on, which means for backup purposes it WILL be pushed upstream.
2. To share something with some other dude without messing around with master, meaning i have to push it by default.

In both cases i need to give the thing some sort of name. So how would a branch without a name I can do that in git too, since commits stick around for 30 days even if they aren't attached to a ref. be useful?

# ? Nov 29, 2011 22:01

Jethro: Jun 1, 2000; I was raised on the dairy, Bitch!

Mithaldu posted:

Jethro posted:
git culture leans more towards maintaining the fiction of a linear history
Nah. It leans towards viewing a repository as a directed acyclic graph, which can be refactored at any time and comes with some affordances so you don't end up with thousands of merge commits when hundred people work on the same thing. You CAN go all-out on having a linear history, but that's not what it's meant for.

My feeling is that hg is more or less the same way but without the refactoring at any time, but instead refactoring if you really want to. Not that I'm any sort of expert.

Mithaldu posted:

Jethro posted:
You only create a named branch in hg when you want to make something permanent. Otherwise, if you want to branch you just do it.
What.

Can i have that in english?

I mean honestly now. I use branches for two things:

1. To temporarily store an experiment or feature i'm working on, which means for backup purposes it WILL be pushed upstream.
2. To share something with some other dude without messing around with master, meaning i have to push it by default.

In both cases i need to give the thing some sort of name. So how would a branch without a name I can do that in git too, since commits stick around for 30 days even if they aren't attached to a ref. be useful?

In hg, changesets stick around forever (unless you undo the most recent commit or use some history editing extension). You don't need to give a special name to branches (in the DAG sense) because you can always refer to the changeset directly (by revision number or changeset identifier (i.e. hash code)) as well as by branch name or tag or bookmark.
So let's say you've got a repository with three changesets

code:

1-2-3

Unless you specifically created a new named branch, all three will be on the "default" branch. Let's say you want to make a new branch off of revision 2. hg update 2 will update the contents of the working directory to revision 2. Make a change and commit. The repository now looks like

code:

1-2-3
  \-4

There, you've got a new branch without needing to name it. You can do all your wonderful branchy things (including merging, switching between branches, pushing to a repository, etc.). The stuplor thing about hg branches is that the branch name of revision 4 (and any of it's children) is still "default" (unless you specifically committed to a new branch). That's because branch name is an attribute of the changeset, not of the actual branch itself, and a named branch isn't really a branch (in the DAG sense), but rather a group of changesets that should be considered related (but not necessarily in the parent-child sense).

# ? Nov 29, 2011 23:26

nexus6: Sep 2, 2011; If only you could see what I've seen with your eyes

We've started using git instead of SVN recently and none of us have been trained to use it. I'm getting a basic grasp on it through articles and videos online (the intro to git in the OP helped) but the fact git and SVN use the same terms to describe different things was tough (branches, checkout, etc).

My current situation is:
- There is a central server holding the "master" repository
- I have cloned it to my local server
- Every time I start work on a new feature I create a new branch based on my clone, make my changes then push the branch back to the central server.

This is working well (thus far) and makes sense, but I do have one issue. In order to test my changes locally I need to modify certain files and I need these to be present across any branches I create. However, I only want each branch to contain the modifications I've made, not any of these config changes. I don't want any config changes pushed up to the central server.

What's the best way to do this? Currently my config changes to the main branch are uncommitted and get merged when I make a new branch. I've been told this will prevent them from being uploaded when I push but I don't think it's very clean.

# ? Dec 1, 2011 18:06

Golbez: Oct 9, 2002; 1 2 3!
If you want to take a shot at me get in line, line
1 2 3!
Baby, I've had all my shots and I'm fine

We switched to git a few weeks ago and just had the first circumstance (using gitolite) where the other developer completed a branch and I needed to merge it to master (I'm the only one with permissions to do so). To give me access to it, he did:

git push -u origin foo

I then pulled it and merged it.

However, we can't seem to kill the thing. I've run git branch -rd foo and it appears to delete, but even when he deletes it locally and then pulls, it comes back. It's still showing up when I run git branch in ~git/repositories/fnord.git.

Am I going to have to delete this using the git user? From what I understand of gitolite, all maintenance like this is supposed to be conducted remotely.

# ? Dec 1, 2011 18:20

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

git push origin :branchname to delete a remote branch.

nexus6 posted:

This is working well (thus far) and makes sense, but I do have one issue. In order to test my changes locally I need to modify certain files and I need these to be present across any branches I create. However, I only want each branch to contain the modifications I've made, not any of these config changes. I don't want any config changes pushed up to the central server.

The approach I've taken for this is to have the following structure: master --> dev --> feature branch, where dev has the configuration changes committed, and then rebase the feature branch onto master before pushing.

Plorkyeran fucked around with this message at 18:45 on Dec 1, 2011

# ? Dec 1, 2011 18:42

pseudorandom name: May 6, 2007

git push also has a --delete option.

# ? Dec 1, 2011 18:48

Johnny Cache Hit: Oct 17, 2011

Golbez posted:

However, we can't seem to kill the thing. I've run git branch -rd foo and it appears to delete, but even when he deletes it locally and then pulls, it comes back. It's still showing up when I run git branch in ~git/repositories/fnord.git.

^^^ They're right, but here's why: git doesn't automatically delete things remotely even if things have been deleted locally. This is actually a very valuable safety feature that has saved my bacon more than once.

You have to tell the remote to delete the branch. Beyond the git push options above, look at git remote prune (I think).

# ? Dec 1, 2011 18:53

Mithaldu: Sep 25, 2007; Let's cuddle.

Jethro posted:

Thanks for explaining. The whole thing makes a lot more sense now. It's basically git, only nothing ever gets deleted and everything is always visible. It has some unnice repercussions such as the fact that you can't share a temporary branch effectively and instead have to say "checkout commit XYZ or whatever child commits it has", but i guess it works when you're really paranoid about your history.

nexus6 posted:

What's the best way to do this?

Have a config branch and rebase your feature branches onto that for dev and back onto master for actual committing.

Mind, whenever you fetch (not pull, fetch) changes to the master branch you'll have to rebase the config branch and its child branches onto the new position of the remote master.

This however doesn't work very cleanly, since the feature branches would include the config commits if you move the config branch marker elsewhere. As such it's better to create a new config branch on the new master ref, cherry-pick the config commits, rebase the feature branches and then delete the old config branch.

Also keep in mind this means that you'll have to force push your dev stuff to the master repo. This is not an issue as long as everyone else working on your stuff is aware of it and uses a visual git tool, like qgit, tortoisegit to untangle things.

# ? Dec 1, 2011 19:12

Argue: Sep 29, 2005; I represent the Philippines

Is there a way to make gitk draw a bit more intelligently? I realize that to git, one parent is as good as another, but when you're using it with git-svn then I think the rule for drawing is a bit clearer--since every commit is tracked by a unique and remote svn branch, you'll always know which commits belong to which branches, so I was hoping I could make it draw each branch as a straight line.

# ? Dec 2, 2011 09:16

Mithaldu: Sep 25, 2007; Let's cuddle.

Argue posted:

Is there a way to make gitk draw a bit more intelligently?

Try using qgit. Alternatively, fiddle around with Git-Garden.

# ? Dec 2, 2011 09:20

Newbsylberry: Dec 29, 2007; I Swim in drag shorts because I have a SMALL PENIS

I apologize if this is the wrong place for this question, but I am that much of a Newbie.

I would like to have a website with a number of sub sites, with each having their own separate views, and users (and all the content generated by users). I'm using rails, and my plan is to use git and clone the repositories of the master site (which will have all the functionality of the sub sites). Then I'll just edit the views and content of the sub sites. Does that sound like it will work? Is there a better way to do it, or can anyone think of issues I'll run into?

# ? Dec 4, 2011 19:34

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

If you make changes per-site, it's going to be difficult to have git keep track of them. You can either use git branches, with each deployment having one branch, or just implementing multi-site capability into your codebase.

# ? Dec 4, 2011 19:53

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

Newbsylberry posted:

I apologize if this is the wrong place for this question, but I am that much of a Newbie.

I would like to have a website with a number of sub sites, with each having their own separate views, and users (and all the content generated by users). I'm using rails, and my plan is to use git and clone the repositories of the master site (which will have all the functionality of the sub sites). Then I'll just edit the views and content of the sub sites. Does that sound like it will work? Is there a better way to do it, or can anyone think of issues I'll run into?

So each site will be a separate app that is deployed separately? Yes, those should be separated out into different repos.

I suggest looking into Rails engines. Implement the common functionality as an engine and then the particular apps can either just require it as a gem, or a submodule, or whatever works best for you. That way, setting up a new site is mostly just some trivial configuration, then implementing whatever specific features you need for that site.

# ? Dec 5, 2011 16:26

Strict 9: Jun 20, 2001; by Y Kant Ozma Post

What's a good recommendation for a bug tracking system that integrates easily with Github? I'm mostly looking for something quick and easy to setup and maintain here, don't need anything fancy. So far the candidates look to be either Trac or Redmine.

# ? Dec 8, 2011 15:10

wwb: Aug 17, 2004

I'm pretty fond of redmine, no reason it shouldn't work with git wherever it is hosted.

Even easier might be using github's integrated tracking, it is pretty not bad if you don't need fancy workflows.

# ? Dec 8, 2011 15:46

Strict 9: Jun 20, 2001; by Y Kant Ozma Post

wwb posted:

Even easier might be using github's integrated tracking, it is pretty not bad if you don't need fancy workflows.

I thought about that, but I'm having 10 people review a new site and report bugs, and with a self-hosted system I can just give them the URL. As I understand it with Github I'd have to create ten separate accounts.

# ? Dec 8, 2011 15:52

wwb: Aug 17, 2004

I'm not quite following here -- with github you'd be able to give them a url too. And in almost any case they'd need an account with the tracker.

You can make redmine take issues over email, but updates aren't so smooth if they can't login.

# ? Dec 8, 2011 16:50

taqueso: Mar 8, 2004

So I have a git repo that was giving me index errors. I removed the index file as the top answer to this SO question says

That seemed to work. But now, a couple commits later, I have this happening:

code:

taqueso@computername:~/repo$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   setup_items.c
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   setup_items.c
#

How can the same file be in both states? I lets me git add setup_items.c without error, but the status stays the same. Can I fix this?

# ? Dec 9, 2011 19:54

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

taqueso posted:

So I have a git repo that was giving me index errors. I removed the index file as the top answer to this SO question says

That seemed to work. But now, a couple commits later, I have this happening:
code:
taqueso@computername:~/repo$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   setup_items.c
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   setup_items.c
#
How can the same file be in both states?

You have some hunks of setup_items.c that are staged for commit, and some that aren't. This can happen if you git add, then work on the file again, or you git add --interactive.

taqueso posted:

I lets me git add setup_items.c without error, but the status stays the same. Can I fix this?

The best advice I can give you right now is to cp setup_items.c{,.bak}, git reset HEAD -- setup_items.c, cp setup_items.c.{.bak,c}, git add setup_items.c. See if that works.

# ? Dec 9, 2011 20:17

taqueso: Mar 8, 2004

Suspicious Dish posted:

The best advice I can give you right now is to cp setup_items.c{,.bak}, git reset HEAD -- setup_items.c, cp setup_items.c.{.bak,c}, git add setup_items.c. See if that works.

Thanks, that worked just fine.

# ? Dec 9, 2011 20:29

Mithaldu: Sep 25, 2007; Let's cuddle.

Start using a git gui that actually shows you what you've in the staging area and lets you modify it before committing, instead of using git add to do a wild blind grab of everything that happens to be around. Your git usage will get ten times more informed and productive, and it'll help you find bugs.

# ? Dec 9, 2011 23:11

taqueso: Mar 8, 2004

Mithaldu posted:

Start using a git gui that actually shows you what you've in the staging area and lets you modify it before committing, instead of using git add to do a wild blind grab of everything that happens to be around. Your git usage will get ten times more informed and productive, and it'll help you find bugs.

I'm not doing a blind grab, I add the files I change. It's not like I'm using commit -a. (Maybe you mean something else?)

# ? Dec 9, 2011 23:19

Mithaldu: Sep 25, 2007; Let's cuddle.

taqueso posted:

I'm not doing a blind grab, I add the files I change. It's not like I'm using commit -a. (Maybe you mean something else?)

Unless you use `git add -p`exclusively, you're doing blind grabs all the time. Have you even tried a gui yet where you can assemble commits in the staging area line by line?

# ? Dec 9, 2011 23:25

taqueso: Mar 8, 2004

Mithaldu posted:

Unless you use `git add -p`exclusively, you're doing blind grabs all the time. Have you even tried a gui yet where you can assemble commits in the staging area line by line?

(Forgive me, I am a git newbie who just manages to get by, and I have no helpful coworkers to bug about it...)

No I have not, only command line and a touch of tortoisegit on windows before I abandoned that. I didn't even know about 'add -p'...

What is a good linux gui that will let me assemble commits in the staging area?

What is the best way to do this on the command line when a gui is not available? 'add -p'?

Why is adding an a set of entire files a problem if I have isolated my changes to a single logical commit worth of work?

# ? Dec 9, 2011 23:29

Mithaldu: Sep 25, 2007; Let's cuddle.

taqueso posted:

(Forgive me, I am a git newbie who just manages to get by, and I have no helpful coworkers to bug about it...)

No I have not, only command line and a touch of tortoisegit on windows before I abandoned that. I didn't even know about 'add -p'...

Ah, alright. I thought i'd seen your name around here before, at a time where i made similar comments.

taqueso posted:

What is a good linux gui that will let me assemble commits in the staging area?

I develop on windows, where i usually use TortoiseGit only for the neat log, and MSysGit for committing, because MSysGit provides Git GUI. By the looks of it, Git GUI is actually a port of a Linux tool, so you may get it on linux just by running git gui.

taqueso posted:

What is the best way to do this on the command line when a gui is not available? 'add -p'?

Absolutely. I'm unsure how to interrogate the staging area on the command line, so you may have to google git commands a bit for that. But for just plain assembling a commit, add -p is great when you're bound to the command line.

taqueso posted:

Why is adding an a set of entire files a problem if I have isolated my changes to a single logical commit worth of work?

First off, you stunt your development process by assembling commits while developing. It becomes much less natural and fluid. It feels much more natural to get started on a task, hack for an hour or so, and then go back and separate your changes into logical commits after the fact.

Secondly, committing via git gui means you have to select and add the chunks or lines you want to commit. This means you're basically doing a code review on yourself, because you read them again and then decide whether they fit in the commit you're currently making. This gives you a great chance to make your commits more logical and to spot bugs. It also means you can leave debug changes in your working directory, without worrying about accidentally committing them.

But really, in short: The problem is that you miss out on a natural code review.

# ? Dec 9, 2011 23:37

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

taqueso posted:

(Forgive me, I am a git newbie who just manages to get by, and I have no helpful coworkers to bug about it...)

No I have not, only command line and a touch of tortoisegit on windows before I abandoned that. I didn't even know about 'add -p'...

What is a good linux gui that will let me assemble commits in the staging area?

What is the best way to do this on the command line when a gui is not available? 'add -p'?

Why is adding an a set of entire files a problem if I have isolated my changes to a single logical commit worth of work?

It's Magit!

# ? Dec 9, 2011 23:39

taqueso: Mar 8, 2004

Mithaldu posted:

First off, you stunt your development process by assembling commits while developing. It becomes much less natural and fluid. It feels much more natural to get started on a task, hack for an hour or so, and then go back and separate your changes into logical commits after the fact.

Secondly, committing via git gui means you have to select and add the chunks or lines you want to commit. This means you're basically doing a code review on yourself, because you read them again and then decide whether they fit in the commit you're currently making. This gives you a great chance to make your commits more logical and to spot bugs. It also means you can leave debug changes in your working directory, without worrying about accidentally committing them.

But really, in short: The problem is that you miss out on a natural code review.

Thanks, this explains it pretty well and is convincing.

Currently I try to do a git diff to make sure only the changes I'm anticipating make it in to the commit, for a similar effect.

I'll give git-gui a try.

I realized that I've been using git (poorly) for a long time and have spent about 0 seconds learning how to actually use it well. Always more important seeming things to worry about. :smith:

Is Pro Git good?

I doubt I will start using emacs just for Magit.

# ? Dec 9, 2011 23:57

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

On the other hand, if you use git add -p, there's no a priori guarantee that the states you're committing even compile, let alone work correctly. You're creating states in the repository that have never existed at any point before this, so you need to be careful not to commit e.g. a change to a function's signature without also committing changes to its usage everywhere. I typically commit the entire state of my working tree, but I do this often and after each logically separate change that still builds and doesn't break anything that isn't under active development. God help you if you want to use git bisect and the intermediate commits you're testing don't compile because you git add -p'd too much or too little.

You could conceivably write a script that will checkout each of your recent commits and verify that the project builds/passes unit tests, after which you can fix anything that's broken with git rebase -i. I find it a lot easier to commit my entire verified (syntactically correct) working tree after each incremental change I make.

Carelessly using git add -p reminds me of Subversion's misfeature that allows you to commit changes as long as the files you've modified don't have any newer changes in the repository. That makes me very uneasy, again because you're committing a state that has never existed before and has no guarantees of working.

Disclaimer: I use git add -p regularly, though not exclusively.

taqueso, Pro Git is excellent, as is gitref.org (by the same author).

# ? Dec 10, 2011 01:05

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

In an ideal world you'd have a pre-receive hook that builds the project and runs your comprehensive test suite on each individual commit.

# ? Dec 10, 2011 01:24

Zhentar: Sep 28, 2003; Brilliant Master Genius

Lysidas posted:

Carelessly using git add -p reminds me of Subversion's misfeature that allows you to commit changes as long as the files you've modified don't have any newer changes in the repository. That makes me very uneasy, again because you're committing a state that has never existed before and has no guarantees of working.

Wait, what? There are VCSes that don't work that way? Having to redo the update, build and test any time another developer committed something before you committed sounds pretty awful.

Edit: Suddenly SVN's poor performance seems so much more tolerable

Zhentar fucked around with this message at 02:08 on Dec 10, 2011

# ? Dec 10, 2011 02:03

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Zhentar posted:

Wait, what? There are VCSes that don't work that way? Having to redo the update, build and test any time another developer committed something before you committed sounds pretty awful.

No, I believe he means that if you modify files A, B, C and the latest version of the SVN repository has updates to D, E, F, you can commit the changes to A, B, C even if you don't have the changes from D, E, F, meaning that you potentially have this state where things won't work.

git is fundamentally different, you can commit at any time. Committing goes into a local repository. Because this is local, this effectively means that you have a fork, different from upstream's or your coworker's copy. You can have commits A, B, C, and your coworker can have D, E, F. If you push A, B, C to the upstream repo, your coworker has two main ways of dealing with the forking situation:

merge - This creates a new commit, called a merge commit, which has two parents, your C commit, and his F commit. The repository history would look like this:

code:

UPSTREAM --- A - B - C ---+ MERGE
         |               _+ COMMIT
         \ _ D _ E _ F _/

The merge commit having two parents is the reason the history is a directed acyclic graph, rather than a tree.

rebase - This supplants the his changes on top of your changes, keeping a linear history:

code:

UPSTREAM --- A - B - C - D - E - F

Rebase just basically picked up D, E, F, undid them, applied A, B, C (a fast-forward, in git terms), and then reapplied D, E, F. If you're curious, this is actually how it works internally.

# ? Dec 10, 2011 02:30

Johnny Cache Hit: Oct 17, 2011

Mithaldu posted:

First off, you stunt your development process by assembling commits while developing. It becomes much less natural and fluid. It feels much more natural to get started on a task, hack for an hour or so, and then go back and separate your changes into logical commits after the fact.

I dunno - to me, half the advantage of a VCS that lets you rewrite history is that I can make a ton of commits that represent logical, working snapshots of my code, each of which have a clean and sensible description.

That way if I break something and can't figure out what I've done, I can do a quick diff against the last commit to see exactly what's changed, reset, etc. And if everything works OK, I'm one git rebase away from taking 20 commit messages into one message that really reflects exactly what patch I'm landing.

Maybe it's just me v :shobon:

# ? Dec 10, 2011 02:44

ColdPie: Jun 9, 2006

taqueso posted:

Thanks, this explains it pretty well and is convincing. Currently I try to do a git diff to make sure only the changes I'm anticipating make it in to the commit, for a similar effect.

I'll give git-gui a try.

I realized that I've been using git (poorly) for a long time and have spent about 0 seconds learning how to actually use it well. Always more important seeming things to worry about. Is Pro Git good?

You certainly don't need a GUI to get a good understanding of the state of your tree. Use "git diff" to see all the changes in your tree that haven't yet been added. "git add [-p]" to add changes as you like. "git diff --cached" to see what's about to be committed. "git show <tree-ish>" to see the changes from a certain commit. You may find a GUI helpful and there's no shame in using one, but it's handy to be very familiar with the CLI tools, in case you ever need to use git on a remote machine or do some scripting or communicate with the git ML or whatever.

Also yes, ProGit is very good and what I recommend that everybody who will use Git read.

# ? Dec 10, 2011 02:52

Zhentar: Sep 28, 2003; Brilliant Master Genius

Suspicious Dish posted:

No, I believe he means that if you modify files A, B, C and the latest version of the SVN repository has updates to D, E, F, you can commit the changes to A, B, C even if you don't have the changes from D, E, F, meaning that you potentially have this state where things won't work.

I guess I was a little unclear - I did correctly understand what he was describing; I've been using SVN heavily for years. Even if it's just merging branches into trunk, it still sounds unmanageable to me.

# ? Dec 10, 2011 03:03

nexus6: Sep 2, 2011; If only you could see what I've seen with your eyes

My apologies if this has been asked, but the way we are handling git is doing my head in and this thread is pretty big already.

Basically, we started using git a few weeks ago and were given no formal training, so everything I know is from this thread/cheat sheets/Google.

I cloned a repository, created some branches and started making changes. It turns out the repository I was told to clone originally was not correct so now there are conflicts when merging branches or something and I need to remake my branches.

What's the best way to do this? I really don't want to have to switch to my old branch, try to figure out what's different, switch to the new branch and try to replicate it for every single file in every branch.

Can I do a diff between branches? Does the git patch apply here?

# ? Dec 12, 2011 13:58

Mithaldu: Sep 25, 2007; Let's cuddle.

nexus6 posted:

Can I do a diff between branches? Does the git patch apply here?

You can diff between any given SHA1 of two commits, no matter on what branch they are.

# ? Dec 12, 2011 14:25

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 19:17

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

nexus6 posted:

What's the best way to do this? I really don't want to have to switch to my old branch, try to figure out what's different, switch to the new branch and try to replicate it for every single file in every branch.

You can rebase onto a different branch. Assuming that the branches are like this:

code:

COMMON ---+- A - B - C - BRANCH1
PARENT     \
             D - E - F - BRANCH2
                      \
                       G - H - I - YOURBRANCH

Or something like that, you want to use:

code:

git rebase --onto BRANCH1 BRANCH2 YOURBRANCH

# ? Dec 12, 2011 16:18

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

«‹›100 »