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 »

ExcessBLarg!: Sep 1, 2001

Steve French posted:

If the argument is just that the tools should be shifted around and functionality grouped together differently and made "more consistent" or whatever, I'd be really interested to see if those of you who find git's command line interface to be so horrid could put your heads together and propose an alternate interface for the same functionality.

So this has happened before.

Originally Git was intended to provide the plumbing for a VCS but to have a more approachable/non-Linus interface on top. Cogito was an attempt at such an interface. What actually happened though is two-fold: First, Git itself did get more user friendly, and around v1.5 most of its serious warts had been handled appropriately. Second, folks, many of whom had come from CVS or Subversion, were able to sufficiently acclimate to Git's usage model--even come to appreciate it--that it wasn't really necessary to dress it up as something more cvs/svn-like.

There's also Mercurial. For those who aren't familiar with it, it's another DVCS that, like Git, was also started as a response to the BitKeeper blowup. The original goal of Mercurial was largely the same as Git (provide a sufficiently robust and efficient DVCS to host the Linux kernel), but the project philosophy and implementation details have always been different. On the service, I'd describe Mercurial as being more Subversion-like, or at least, being more familiar to someone coming from Subversion. It also avoids a lot of the complaints we hear about Git: there's no "git add", commands are "more intuitive", history is (well, was) immutable, etc.

Funny thing about Mercurial is that, over time, the project has come to embrace features via extensions that are part of core Git. In my opinion, the whole Mercurial Queues (MQ) extension was a giant workaround for the fact that Mercurial emphasized immutable history. Now there's a Rebase extension too. Mercurial also emphasized using repository clones as branches instead of having internal named branches. When they were finally implemented, named branches were still immutable, more like a traveling tag, although I'm not completely certain of the current behavior. Git-like branches were finally implemented using the Bookmarks extension.

These days Git and Mercurial effectively have feature parity at least through extensions. There's folks who prefer Mercurial for a variety of reasons, and I imagine that "Git gets it wrong" is a common one. Personally I used Mercurial for a few years in its early days and bought into the extensions (e.g., MQ) once I understood how they had genuine utility. I switched to Git though after 1.5 and realized exactly how flexible it was when all these workflows, enabled by Mercurial extensions, could be done with Git's primitive operations.

Anyways, that's a perspective colored by someone who switched from Mercurial to Git. Folks who went the other way would probably, and perhaps rightfully, describe things differently.

ExcessBLarg! fucked around with this message at 21:12 on Feb 21, 2014

# ? Feb 21, 2014 21:10

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 10:04

MononcQc: May 29, 2007

Mercurial has limited mutability and is somewhat safer in its approach: mutate locally, and stuff made public is immutable. It's basically what git users recommend as a convention, but baked in the tool.

# ? Feb 21, 2014 21:28

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

There really is no fixing git for people who work in constant fear of dropping to the command line, who require every feature of the system to be available from a right-click menu or not at all, who when faced with a task slightly out of the ordinary would really prefer to clicka-clicka for ten minutes rather than tappa-tappa for one. That's not the culture git comes out of (nor RCS, CVS and Subversion). And it's not the culture that TFS VC comes out of either, even if it ends up being sold there.

Gazpacho fucked around with this message at 22:06 on Feb 21, 2014

# ? Feb 21, 2014 21:53

shrughes: Oct 11, 2008; (call/cc call/cc)

I don't have any trouble or annoyance with textual merge conflicts. The "tools" just get in the way.

But. Please: git config --global merge.conflictstyle diff3

I don't know how many times I've had coworkers cry that merges are hard, only to go over and see that you can't even tell by looking what changes have been made.

# ? Feb 21, 2014 23:59

TasogareNoKagi: Jul 11, 2013

ExcessBLarg! posted:

Mercurial Queues

It's almost like git's index, just with the ability to push, pop, or reorder an arbitrary number of them on top of the parent commit, all versioned independently of the main repository! Diffs of diffs! What's not to like :v:

That said, mq lets me keep my sanity when around the brain damaged SVN setup I deal with at work. It also meant git's index was a conceptual non-issue when I started working with all the reprap stuff hosted on github.

# ? Feb 22, 2014 00:16

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

Is it recommended to have a .gitattributes file to prevent issues with line endings?

# ? Feb 22, 2014 03:42

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

Only if you specifically need non-native newlines for some files.

# ? Feb 22, 2014 03:48

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

Plorkyeran posted:

Only if you specifically need non-native newlines for some files.

I was thinking more along the lines of somebody on a different OS accidentally committing the wrong line endings

# ? Feb 22, 2014 03:51

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

These days autocrlf actually works, so as long as you can get everyone on Windows to set autocrlf=true it's pretty hard to accidentally end up with incorrect line endings without doing very unusual things (such as copying files from a Windows machine to a non-Windows machine not via git).

I suppose using a .gitattributes file to ensure that people have things configured correctly doesn't hurt, but it should be unnecessary.

# ? Feb 22, 2014 05:31

B-Nasty: May 25, 2005

Honest question for the git haters on Windows: have you tried a decent GUI interface like the fantastic Git Extensions https://code.google.com/p/gitextensions/ ? I consider myself a decent programmer, but I prefer the GUI clients for discoverability of the 8 billion options in git. Hmm, what does that stash button do? Click, oh, it saved my changes so that I could pull recent changes in the master repo and then reapply.

In addition, a nice commit interface with the files added/modified and a diff viewer on highlight of a changed file. If there's a conflict on a rebase, it will walk you through each step that needs to be fixed and you can abort if you screw something up half way through.

I guess one could argue that I'm supporting the tricky nature of git on the CL, but I just see it as preference. I'm not a CLI hacker, I prefer to memorize code instead of tool commands and I like a "full view" of what's going on.

# ? Feb 23, 2014 01:51

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

B-Nasty posted:

Honest question for the git haters on Windows: have you tried a decent GUI interface like the fantastic Git Extensions https://code.google.com/p/gitextensions/ ? I consider myself a decent programmer, but I prefer the GUI clients for discoverability of the 8 billion options in git. Hmm, what does that stash button do? Click, oh, it saved my changes so that I could pull recent changes in the master repo and then reapply.

In addition, a nice commit interface with the files added/modified and a diff viewer on highlight of a changed file. If there's a conflict on a rebase, it will walk you through each step that needs to be fixed and you can abort if you screw something up half way through.

I guess one could argue that I'm supporting the tricky nature of git on the CL, but I just see it as preference. I'm not a CLI hacker, I prefer to memorize code instead of tool commands and I like a "full view" of what's going on.

Sourcetree

# ? Feb 23, 2014 15:14

B-Nasty: May 25, 2005

Blinkz0rz posted:

Sourcetree

Tried it, but still prefer GE for my typical workflow, and as lame as it sounds, a "prettier" UI on Windows. That said, I'm glad it exists. In the fast moving software world, 6 months down the road, it may be the clear choice.

# ? Feb 23, 2014 16:16

Megaman: May 8, 2004; I didn't read the thread BUT...

git log --graph --pretty=oneline --abbrev-commit is all you'll ever need

# ? Feb 27, 2014 22:23

distortion park: Apr 25, 2011

Megaman posted:

git log --graph --pretty=oneline --abbrev-commit is all you'll ever need

git is so simple and intuitive, why doesn't everyone find it easy?

# ? Feb 28, 2014 00:17

Megaman: May 8, 2004; I didn't read the thread BUT...

pointsofdata posted:

git is so simple and intuitive, why doesn't everyone find it easy?

Because most people are unemployable retards who have no friends

# ? Feb 28, 2014 03:05

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

pointsofdata posted:

git is so simple and intuitive, why doesn't everyone find it easy?

If only you could map that to an alias so you could just type 'git lol' in the future, or there was a graphical tool you could use that came with git.

Hmm. No, command line arguments are hard, better stick to TFS and VSS.

# ? Feb 28, 2014 05:07

down with slavery: Dec 23, 2013; STOP QUOTING MY POSTS SO PEOPLE THAT AREN'T IDIOTS DON'T HAVE TO READ MY FUCKING TERRIBLE OPINIONS THANKS

Volmarias posted:

If only you could map that to an alias so you could just type 'git lol' in the future, or there was a graphical tool you could use that came with git.

Hmm. No, command line arguments are hard, better stick to TFS and VSS.

Honestly, it's hard to blame them when cmd.exe has been as bad as it is for as long as it has. Microsoft has been pretty intent on making sure you get to play with your mouse lots.

# ? Feb 28, 2014 05:53

Megaman: May 8, 2004; I didn't read the thread BUT...

down with slavery posted:

Honestly, it's hard to blame them when cmd.exe has been as bad as it is for as long as it has. Microsoft has been pretty intent on making sure you get to play with your mouse lots.

If people who dislike git can't handle simple command line commands they shouldn't be bothering with the command line anyway, so there's almost no point for them to complain about it.

# ? Feb 28, 2014 06:31

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

down with slavery posted:

Honestly, it's hard to blame them when cmd.exe has been as bad as it is for as long as it has. Microsoft has been pretty intent on making sure you get to play with your mouse lots.

My host OS is Windows 7 but I do everything in Linux VMs, I am very very fond of Terminator. I recently started using Vagrant so I've been using Git Bash in Windows and god drat it's painful to use after using Terminator. Since my SSD died today at work maybe I'll just go with Linux for my host OS now.

# ? Feb 28, 2014 06:37

Megaman: May 8, 2004; I didn't read the thread BUT...

fletcher posted:

My host OS is Windows 7 but I do everything in Linux VMs, I am very very fond of Terminator. I recently started using Vagrant so I've been using Git Bash in Windows and god drat it's painful to use after using Terminator. Since my SSD died today at work maybe I'll just go with Linux for my host OS now.

There's really no point to using windows at work unless you have a program that absolutely requires it, I can't think of any offhand though that wouldn't also be available for Linux in some form or another. There's also no reason to use it at home unless you're playing games, and even then you can use wine.

# ? Feb 28, 2014 06:59

enki42: Jun 11, 2001; #ATMLIVESMATTER

Put this Nazi-lover on ignore immediately!

I'm a git user who probably wouldn't switch if given the option (although I've been meaning to checkout mercurial), but the Git CLI is unforgivably horrible for UX even if you otherwise have no problem with the command line.

The switches are massively inconsistent. To remove files, I use `git rm`, to remove branches `git branch -d`. Sometimes I can force with `-D`, sometimes I can't (i.e. to remove a tag)
The commands themselves behave in weird, inconsistent ways. For instance, `git add .` will add untracked files, but won't stage deletions. `git add -p` will stage deletions, but won't add untracked files. There's no logical reason for this other than "that's how it works"
Some commands are destructive without any real safeguards. If I run `git checkout .`, I've lost everything I haven't committed or staged, without warning or any way to recover those files.
It's the leakiest abstraction ever. Once you get beyond the basics, it becomes necessary to know how the reflog works - in general, I shouldn't need to know how a program works "under the hood" for fairly normal usage.
There's too many ways to essentially break a repository (which can be recovered from, but not without knowing a lot about the internals of git) through relatively common stuff like rebasing shared branches. Nowhere in the git commands themselves is there a warning that this will get you into a world of pain.

enki42 fucked around with this message at 14:24 on Feb 28, 2014

# ? Feb 28, 2014 14:19

prefect: Sep 11, 2001; No one, Woodhouse.
No one.; Dead Man’s Band

enki42 posted:

I'm a git user who probably wouldn't switch if given the option (although I've been meaning to checkout mercurial), but the Git CLI is unforgivably horrible for UX even if you otherwise have no problem with the command line.

The switches are massively inconsistent. To remove files, I use `git rm`, to remove branches `git branch -d`. Sometimes I can force with `-D`, sometimes I can't (i.e. to remove a tag)

The commands themselves behave in weird, inconsistent ways. For instance, `git add .` will add untracked files, but won't stage deletions. `git add -p` will stage deletions, but won't add untracked files. There's no logical reason for this other than "that's how it works"

Some commands are destructive without any real safeguards. If I run `git checkout .`, I've lost everything I haven't committed or staged, without warning or any way to recover those files.

It's the leakiest abstraction ever. Once you get beyond the basics, it becomes necessary to know how the reflog works - in general, I shouldn't need to know how a program works "under the hood" for fairly normal usage.

There's too many ways to essentially break a repository (which can be recovered from, but not without knowing a lot about the internals of git) through relatively common stuff like rebasing shared branches. Nowhere in the git commands themselves is there a warning that this will get you into a world of pain.

I do not like that "git push origin $branchname" and "git push origin :$branchname" do essentially opposite things. I've seen users get tripped up by that.

# ? Feb 28, 2014 14:45

Gul Banana: Nov 28, 2003

Megaman posted:

There's really no point to using windows at work unless you have a program that absolutely requires it, I can't think of any offhand though that wouldn't also be available for Linux in some form or another. There's also no reason to use it at home unless you're playing games, and even then you can use wine.

well, i can think of a reason: you might be developing software for windows. it's actually quite a large market!

# ? Feb 28, 2014 14:58

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

Gul Banana posted:

well, i can think of a reason: you might be developing software for windows. it's actually quite a large market!

I suspect that would count as a "Program that requires it".

# ? Feb 28, 2014 15:19

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Megaman posted:

There's really no point to using windows at work unless you have a program that absolutely requires it, I can't think of any offhand though that wouldn't also be available for Linux in some form or another. There's also no reason to use it at home unless you're playing games, and even then you can use wine.

Or your company is standardized on windows, and you have to use the company managed image on company managed machines.

Or you do windows app development.

Or you want to play games without performance issues.

Or you have a family and "that weird program you make us use without the start button stinks, and why can't I install word, this Libby office or whatever doesn't match up when I send someone something"

# ? Feb 28, 2014 16:02

aerique: Jul 16, 2008

Does anyone here have experience with Plastic SCM and preferably compared to Git in an enterprise environment? These two are the last candidates for our new version control system.

Us software developers work on either Linux or Windows.

# ? Feb 28, 2014 16:06

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

Megaman posted:

There's really no point to using windows at work unless you have a program that absolutely requires it, I can't think of any offhand though that wouldn't also be available for Linux in some form or another. There's also no reason to use it at home unless you're playing games, and even then you can use wine.

Did I just get teleported to Slashdot in 2006?

# ? Feb 28, 2014 16:06

Sulla Faex: May 14, 2010; No man ever did me so much good, or enemy so much harm, but I repaid him with ENDLESS SHITPOSTING

Ithaqua posted:

Did I just get teleported to Slashdot in 2006?

There is literally no reason why every single person should not be using ArchLinux on a tractor as their sole work computer. Just to forestall any possible naysayers, I promise that this has nothing to do with the fact that I live on a farm and 100% of my computer usage involves using a tractor to tractorise corn and pigs and trees and whatever. That's unrelated. Why would you even think that was related

# ? Feb 28, 2014 16:12

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

prefect posted:

I do not like that "git push origin $branchname" and "git push origin :$branchname" do essentially opposite things. I've seen users get tripped up by that.

It's due to that the full command is git push origin $localbranchname:$remotebranchname, so leaving out the local branch pushes nothing to the remote branch, which "obviously" deletes it.

Fortunately git 1.7 added git push origin --delete $branchname.

# ? Feb 28, 2014 16:34

ExcessBLarg!: Sep 1, 2001

enki42 posted:

The switches are massively inconsistent. To remove files, I use `git rm`, to remove branches `git branch -d`. Sometimes I can force with `-D`, sometimes I can't (i.e. to remove a tag)

I'm not sure what a more sensible alternative to "git rm" would be, folks would probably complain more about "git add -d". It would be helpful if "git tag -D" was an alias for "-d", although come to think of it, deleting tags is such a rare operation I've never noticed.

enki42 posted:

The commands themselves behave in weird, inconsistent ways. For instance, `git add .` will add untracked files, but won't stage deletions. `git add -p` will stage deletions, but won't add untracked files. There's no logical reason for this other than "that's how it works"

Individually both behaviors seem reasonable. I suppose the issue is that they're both under the "git add" banner, so that's a fair point.

enki42 posted:

Some commands are destructive without any real safeguards. If I run `git checkout .`, I've lost everything I haven't committed or staged, without warning or any way to recover those files.

The whole point of running "git checkout ." is to discard non-staged changes. That's not a side effect, it's the only thing the command does. That's like complaining that "rm *" should warn before removing files.

There are other cases where git does warn and abort a destructive operation, e.g., when switching branches while there's non-staged changes. But that's because the destruction is a side-effect of some operation, not its primary purpose.

enki42 posted:

It's the leakiest abstraction ever. Once you get beyond the basics, it becomes necessary to know how the reflog works - in general, I shouldn't need to know how a program works "under the hood" for fairly normal usage.

I disgaree. You don't have to know anything about pack files, the object compression system, etc., in order to use Git. It's true that you do need to understand its abstracted data model, have some familiarity with what a refs is, a blob is, etc. But that is the absraction, there's considerable internals beyond that.

As far as what Git does require you to know, that's pretty fundamental. Advanced usage of any VCS is going to require more-and-more deeper understanding of the data model. There might be an exception for systems with immutable histories and fixed branches, but then you lose flexibility.

enki42 posted:

There's too many ways to essentially break a repository (which can be recovered from, but not without knowing a lot about the internals of git) through relatively common stuff like rebasing shared branches. Nowhere in the git commands themselves is there a warning that this will get you into a world of pain.

1. I've never had to understand the format/purpose/whatever of a pack file in order to "fix" a repository, so again, I disagree on the "understanding internals" claim.

2. Unlike a merge, a rebase is a potentially disruptive operation. Although it's a commonly performed one, folks really should undersand what it does. "git help rebase" points this out clearly:

git help rebase posted:

NOTES
You should understand the implications of using git rebase on a repository that you share. See also RECOVERING FROM UPSTREAM REBASE below.

And indeed, there's an entire section upstream rebases, why they're terrible, and how you can work with them.

The commands do warn about this. A "git rebase" alone isn't the problem, it's when a rebased-branch is shared both before and after the rebase. As it turns out, "git push" won't allow non-fast-foward pushes without the "--force" flag, and using "--force" is the warning:

git help push posted:

-f, --force
Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. This flag disables the check. This can cause the remote repository to lose commits; use it with care.

# ? Feb 28, 2014 20:15

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

ExcessBLarg! posted:

The whole point of running "git checkout ." is to discard non-staged changes. That's not a side effect, it's the only thing the command does. That's like complaining that "rm *" should warn before removing files.

With zsh it does. It has saved me the annoyance of restoring files from backup before.

# ? Feb 28, 2014 21:05

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

git question: when are the checksums normally calculated for files on a bare repository, and is there any way to force a remote to recalculate its checksums? I ask this because my coworker just experienced a bizarre problem with a versioned file - he pulled one of my feature branches, and got errors when he tried to recompile and link the code to our bootloader image. I did a copy of the hex file for the bootloader from my desktop to his, and git doesn't show the file as changed, but now it links without issues. It makes me wonder if the file got corrupted on the remote while the checksum of the uncorrupted version got retained.

# ? Feb 28, 2014 21:14

ExcessBLarg!: Sep 1, 2001

Plorkyeran posted:

With zsh it does. It has saved me the annoyance of restoring files from backup before.

Personally I find it annoying when I type an unambiguous, albeit somewhat "dangerous" command, and a tool asks "are you really, really sure?"

Of course I'm sure, I wouldn't have asked to do so otherwise.

# ? Feb 28, 2014 21:16

down with slavery: Dec 23, 2013; STOP QUOTING MY POSTS SO PEOPLE THAT AREN'T IDIOTS DON'T HAVE TO READ MY FUCKING TERRIBLE OPINIONS THANKS

ExcessBLarg! posted:

Of course I'm sure, I wouldn't have asked to do so otherwise.

Some people just get used to using sudo rm -rf as the way to delete a file and then wonder why there are no safeguards.

# ? Feb 28, 2014 21:55

ufarn: May 30, 2009

I get an error when trying to merge branches master and other-branch:

Bash code:

$ git merge other-branch
Auto-merging project/foo.py
Auto-merging project/static/css/style.css
E576: viminfo: Missing '>' in line: fkw7080000gn/T/psql.edit.55378
Press ENTER or type command to continue

From what I understand, my vim is borked, but I don't feel like running the sudo suggestions posted online without some goonput first.

EDIT: This is what .viminfo says under mark history:

code:

# History of marks within files (newest to oldest):

> ~/project/.git/MERGE_MSG
	"	7	6
	^	7	7
	.	7	6
	+	2	17
	+	3	0
	+	7	6
fkw7080000gn/T/psql.edit.55378

# History of marks within files (newest to oldest):

> /private/var/folders/8f/hm_q__wj6sl7pv68v6fkw7080000gn/T/psql.edit.55378
	"	1	0

ufarn fucked around with this message at 14:10 on Mar 1, 2014

# ? Mar 1, 2014 14:05

Dylan16807: May 12, 2010

ExcessBLarg! posted:

The whole point of running "git checkout ." is to discard non-staged changes. That's not a side effect, it's the only thing the command does. That's like complaining that "rm *" should warn before removing files.

"git checkout branch/commit" updates the index to branch/commit for all files (and HEAD), and preserves local changes.

"git checkout branch/commit $path" updates the index to branch/commit for $path files, and discards local changes.

It's not saying 'rm' should warn about every use, it's saying that 'cd' and 'rm' should be different commands.

# ? Mar 1, 2014 21:15

ToxicFrog: Apr 26, 2008

Git isn't even consistent about that, either; git clean, unlike git checkout, really does only have one purpose, the removal of untracked files and directories - but by default it won't do anything, requiring some combination of -d and -f to actually do what you just told it to.

I love git, but holy poo poo is its UI a trainwreck.

# ? Mar 2, 2014 00:39

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Update from awhile back...

Arcsech posted:

To get to 1GB, you almost certainly have some binary files in there, or you have a shitton of commits. Assuming it's the former, once you find the offending files, you want "git filter-branch", see here most of the way down: http://git-scm.com/book/ch6-4.html

Make sure to check that it came out the way you wanted before you push, filter-branch is really dangerous if you typo your regex or something.

I'm trying this right now, after poking around. It looks like a bunch of Visual Studio, precompiled header, .sdf bullshit wound up in my history. It found 577 of them, and those things get pretty big. I had set up a .gitignore for them at some point, but not before I guess it polluted everything.

Update: Went from 1GB to 78MB. Yeah, I'd say that helped!

Rocko Bonaparte fucked around with this message at 21:45 on Mar 3, 2014

# ? Mar 3, 2014 05:13

o.m. 94: Nov 23, 2009

Just getting into the crazy world of merge tools, and I'm using vimdiff.

So I've got the four windows:

LOCAL | BASE | REMOTE

MERGED

So, I'm in LOCAL and I skip to the first conflict. I want to take the line in LOCAL and put it as a replacement for the line in MERGED. When I type 'dp', I get the error:

'More than two buffers in diff mode, don't know which one to use'

I googled around but couldn't find a straight answer; how can I specify the target buffer to be MERGED?

Secondly, is there a way to close the middle BASE window?

# ? Mar 11, 2014 12:46

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 10:04

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

oiseaux morts 1994 posted:

Just getting into the crazy world of merge tools, and I'm using vimdiff.

So I've got the four windows:

LOCAL | BASE | REMOTE

MERGED

So, I'm in LOCAL and I skip to the first conflict. I want to take the line in LOCAL and put it as a replacement for the line in MERGED. When I type 'dp', I get the error:

'More than two buffers in diff mode, don't know which one to use'

I googled around but couldn't find a straight answer; how can I specify the target buffer to be MERGED?

Secondly, is there a way to close the middle BASE window?

To put code to a specific buffer: :diffput [0-n] where the number is the buffer you want to put the change into. To close any buffer, navigate to it with ctrl-w[movement] and then close it with :q. There is probably an easier way to do that last one, but it's how I've been doing it for far too long.

# ? Mar 11, 2014 14:07

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

«‹›100 »