|
chutwig posted:Does anyone have a recommendation for a good Windows diff tool? Doesn't need to be free. On OS X, I am very used to Kaleidoscope. In particular, I like having a list of all added/deleted/changed files on the left. All the Windows tools I've tried react to git difftool by opening one file at a time, then moving to the next one when I close that file, but maybe this is just me invoking the tool the wrong way from Git. Jetbrains GoLand as an IDE and it’s built in diff tool.
|
#
?
Feb 13, 2018 14:51
|
|
|
|
| # ? May 28, 2024 01:26 |
|
|
chutwig posted:Does anyone have a recommendation for a good Windows diff tool? Doesn't need to be free. On OS X, I am very used to Kaleidoscope. In particular, I like having a list of all added/deleted/changed files on the left. All the Windows tools I've tried react to git difftool by opening one file at a time, then moving to the next one when I close that file, but maybe this is just me invoking the tool the wrong way from Git. Git Extensions has this sort of functionality built into the UI itself, not as a third-party diff tool, but that might involve shaking up your workflow too much.
|
|
#
?
Feb 15, 2018 00:49
|
|
|
New Yorp New Yorp posted:Beyond compare This guy gets it. Beyond compare is a fantastic tool.
|
|
#
?
Feb 15, 2018 01:52
|
|
|
Kdiff3 that's bundled with tortoisehg sometimes does not merge nicely. Beyond Compare never fails.
|
|
#
?
Feb 15, 2018 19:04
|
|
|
Beyond Compare is probably what I’m looking for, thanks.
|
|
#
?
Feb 16, 2018 14:14
|
|
|
I have two git repositories, one called "dotfiles" and one called "useful-scripts." I'd like to combine useful-scripts into dotfiles and then delete useful-scripts. What's the "appropriate way" to do this? I'd like to keep all history from useful-scripts in tact so I can figure out what I've done in the past.
|
|
#
?
Feb 17, 2018 14:57
|
|
|
You could either do a full history rewrite, to put everything into a single branch history, or otherwise you could do something where you import one repository into the other as a disconnected branch, then merge them to a single branch going forward.
|
|
#
?
Feb 17, 2018 15:13
|
|
|
On the "rewriting history"* front, there's sure to be some filter-branch invocation that will make it look like you always built these things in lockstep. I'd be interested in seeing it, but I've not spent much time using it in anger. Actually, does anyone have any good use cases for filter-branch and friends? There's the old "sensitive data in the repo" case, this article on Rust's documentation repository. * This increasingly strikes me as a poor term for the process. It's understood, but combining understanding of 'here is an alternative series of changes' and 'I've removed commits from this label' seems to complicate things.
|
|
#
?
Feb 17, 2018 22:37
|
|
|
Boris Galerkin posted:I have two git repositories, one called "dotfiles" and one called "useful-scripts." I'd like to combine useful-scripts into dotfiles and then delete useful-scripts. I haven’t used it but it came up at work that ‘git submodule absorbgitdirs’ may do what you want or it may not. If it doesn’t what I had done is basically this: Git clone dotfiles Git add remote place containing useful-scripts Git merge useful-scripts master Git push dotfiles. I’ve also used that to ‘remove’ submodules. IE: RepoA has submodule of RepoB at location RepoB: In RepoB: Mkdir RepoB Git my * RepoB Git commit In RepoA: Git submodule remove RepoB Git remote add RepoB Git merge RepoB/master There’s one commit of the moving the hierarchy down but git log —follow works as expected.
|
|
#
?
Feb 17, 2018 22:45
|
|
|
Anybody ever buys Perforce for new non-games teams? Is it very expensive or just expensive when you go above free workload? I saw they no longer show pricing for some reason.
|
|
#
?
Feb 21, 2018 08:29
|
|
|
Shy posted:Anybody ever buys Perforce for new non-games teams? Is it very expensive or just expensive when you go above free workload? I saw they no longer show pricing for some reason. I don't think many people currently buy p4 like that. It's new company market share has really fallen. It's fairly expensive and per seat, but the reason why they no longer show pricing is they were acquired recently and are trying to pivot to being enterprise software with cloud licensing. So unless you talk to your sales manager you won't get a price out of them. I just went back to p4 for a project after 6 years with git and it amazes me how bad the tooling is around it these days. There are so many 3rd party tools that just have no concept that p4 could exist and workflow breaks in horrible ways.
|
|
#
?
Feb 21, 2018 15:14
|
|
|
Something like $800/seat and it's forever, but you have to reach a certain number of seats. Else $350/seat/year. Also, they are egregious Windows devs and their documentation is super loving garbage especially for running a Linux server. Also poo poo defaults to case insensitive and you can't change it later. It's still better than git.
|
|
#
?
Feb 23, 2018 04:53
|
|
|
smackfu posted:What does Git LFS look like if someone doesn’t have the LFS client? Do they just get stub files instead of the binaries? A page and three weeks late but: they will get the stub files and be confused as to why things break. Having a 500 MB file in a git repo where work is happening is probably not a good idea. You could use LFS or just have a bootstrap script or makefile download it if this is an environment where that makes sense. A possible compromise is to make a submodule with only the binary. That at least isolates the giant binary data from the repository where work happens, while keeping the binary reasonably easy to update at need. The downside is that now you have a submodule and submodules are evil.
|
|
#
?
Feb 23, 2018 08:08
|
|
|
Submodules aren't that bad, especially now that the UI has had some love  You'd just be badly reimplementing LFS, though.
|
|
#
?
Feb 25, 2018 04:12
|
|
|
Ralith posted:Submodules aren't that bad, especially now that the UI has had some love What’s the UI changes? Also git lfs is just a bad implementation of manifest files people have used for years
|
|
#
?
Mar 4, 2018 22:05
|
|
|
Tried Beyond Compare after a bunch of people recommending it and wow it's something I didn't know I needed so much.
|
|
#
?
Mar 16, 2018 16:01
|
|
|
Shy posted:Tried Beyond Compare after a bunch of people recommending it and wow it's something I didn't know I needed so much. I needed a tool to do folder and file diffs last week and dug up the thread recommendation and ‘Beyond Compare’ is easily the best windows diff tool I’ve ever used.
|
|
#
?
Mar 16, 2018 18:27
|
|
|
How are you supposed to deal with versioning with git? For instance in a version in an `__init__.py` or `Cargo.toml` file. Like if you have 3 branches off of 0.2 that should up the version to 0.3, should you just wait until you merge them to bump the version? I've been doing it differently but it just seems to result in a bunch of merge obnoxiousness where you have to constantly revise the version number. I generally don't like the log looking like: Merged branch foo, Bumped version Because conceptually to me, merging the branch should be part of bumping the version. But I'm not sure if that's better than doing the version bump right before you merge Foo or after. I guess it's hair splitting and preference, just curious if there are any benefits I haven't thought of. I just noticed my current way of bumping at the start of the branch is not working.
|
|
#
?
Mar 16, 2018 22:45
|
|
|
I always figure you should do one of two things 1. Every merge creates a monotonically increasing version bump, and you release under that version number even if there are “holes” in the sequence 2. Keep an “internal” monotonically increasing version as above, but map it to an independent “external” version with explicit manual links, and that version is what users see That’s just me though, no idea whether it’s best practice or not
|
|
#
?
Mar 16, 2018 22:53
|
|
|
Can't you make the version bump an amendment to the merge commit? It's not illegal to have more changes than just the strict merge in a merge commit, although might be unusual.
|
|
#
?
Mar 16, 2018 23:14
|
|
|
nielsm posted:Can't you make the version bump an amendment to the merge commit? It's not illegal to have more changes than just the strict merge in a merge commit, although might be unusual. Yeah, that's a good point. I think part of me is just lazy and wants to use github's make it easy button. I'll try and do that.
|
|
#
?
Mar 16, 2018 23:15
|
|
|
Please do not ever put functional changes into a merge commit.
|
|
#
?
Mar 16, 2018 23:56
|
|
|
I use a release branch that sets the version number when the branch is created. All feature branches get merged into that release branch but don't touch the version number.
|
|
#
?
Mar 16, 2018 23:59
|
|
|
At work we use GitVersion and have it pipe version numbers into our deployment tools that overwrite whatever version numbers are needed wherever they are. Version numbers as such don't live in our source code. We're still working out the particular workflow kinks but for the most part it works decently.
|
|
#
?
Mar 17, 2018 00:56
|
|
|
Is there a way to have 2 different accounts on github with the same ssh public key? If not (which seems to be the case) can the key to be used be specified in a repo's config?
|
|
#
?
Mar 17, 2018 01:26
|
|
|
Volguus posted:Is there a way to have 2 different accounts on github with the same ssh public key? You connect to the server with the username "git" and your public key. Since the username is fixed the only thing you've got left to identify the account is your public key so it can only map to one account.
|
|
#
?
Mar 17, 2018 10:50
|
|
only
|
Version numbers exist strictly for people who don't have access to source code. For developers who do, branch name and commit tag are all you need and work much better. So, never touch your version info file during actual development, at all (Do edit the changelog / release notes, though).. When want to publish a new release, commit a change directly to master with the version bump and nothing else.
|
|
#
?
Mar 17, 2018 11:14
|
|
|
I'm quietly going insane from CRLF/LF issues that are somehow appearing in an entirely windows shop running Git under TFS. Does anyone know what the correct settings to make this poo poo stop happening are, either in .gitattributes, git config, or VS or TFS themselves? (ed) While I'm at it is there a way to make TFS2015+ count whitespace-only diffs in a pull request as not-diffs so they don't show up?
|
|
#
?
Mar 22, 2018 19:47
|
|
|
Ciaphas posted:I'm quietly going insane from CRLF/LF issues that are somehow appearing in an entirely windows shop running Git under TFS. Does anyone know what the correct settings to make this poo poo stop happening are, either in .gitattributes, git config, or VS or TFS themselves? What specific issues are you encountering?
|
|
#
?
Mar 22, 2018 20:09
|
|
|
VS throws up a crlf dialog whenever a file is opened Both team explorer in commits and TFS in pull request insist that tons of files changed but diff in VS/TFS shows either nothing or whitespace only. Git status is correct Ciaphas fucked around with this message at 20:29 on Mar 22, 2018 |
|
#
?
Mar 22, 2018 20:26
|
|
|
We had this pop up recently. I bet you're got someone issuing the git bash command line, and they chose to override eols. You might try git diff --ignore-space-at-eol Or seeing when things go haywire and yelling with the committing dev.
|
|
#
?
Mar 22, 2018 20:42
|
|
|
boo_radley posted:Or seeing when things go haywire and yelling with the committing dev. this is the solution also for posterity make sure everyone is using the same autocrlf setting
|
|
#
?
Mar 22, 2018 20:51
|
|
|
boo_radley posted:We had this pop up recently. I bet you're got someone issuing the git bash command line, and they chose to override eols. And it's happening to everyone--we all get asked to convert by VS when we open files that we haven't modified in the current commit yet, and everyone's getting the same massive amount of fake changes according to Team Explorer. Worse, I'm the only one on the team who's any good at the Git command line, which also probably means no one has hosed with their configs. ChickenWing posted:this is the solution
|
|
#
?
Mar 22, 2018 22:20
|
|
|
The problem seems to be that, for the first commit in a new branch, Visual Studio thinks all of the files in the repo have changed, where the git shell does not. So what the devs are doing (including myself, previously) is committing a bunch of arbitrary whitespace changes of unknown nature introduced by Visual Studio, then when it comes time to do a pull request in TFS, it highlights those as diffs but marks them as whitespace only and provides no option to show the diff so I can see whether the whitespace is line endings or some other thing--and because git can't see it, I have no other way to see the differences. So. VS Git integration sucks. I need to learn how to tell VS two things: 1) Stop automatically including changes in a commit. Change it so that the developer has to stage files for commit manually, just like in normal Git. I don't know how to make it do this. 2) Stop making whatever damned changes you're making. I don't know how to do this, either. Option 3 is telling the developers to stop using the VS integration and start using command line/gitk/git gui, but I can guarantee that will cause a lot of pushback and frankly I'd rather not do it anyway (rebasing is much easier in VS for example).
|
|
#
?
Mar 23, 2018 00:10
|
|
|
Ciaphas posted:So. VS Git integration sucks. I'm assuming this is VS2015? VS2017 is better about a lot of this stuff, if for no other reason than they're transitioning everyone in the company to using Git and dogfooding all of this stuff, so if VS's Git client sucks, the VS team hears about it. (but yes, VS's Git client has traditionally been awkward at best)
|
|
#
?
Mar 23, 2018 00:20
|
|
|
New Yorp New Yorp posted:I'm assuming this is VS2015? VS2017 is better about a lot of this stuff, if for no other reason than they're transitioning everyone in the company to using Git and dogfooding all of this stuff, so if VS's Git client sucks, the VS team hears about it. Yeah, this is 2015. We're getting the latest version of 2017 Soon® (pending security approval, airgapped network etc). I think what I might do is tell everyone to just stop using the Team Explorer window in VS entirely and give a crash course tomorrow on git gui while walking around and fixing everyone's topic branches after I do whatever the gently caress I gotta do to fix the problem forevermore in master. At least there's only four of us, including me. What would you recommend for settings in the future? Repos created via cloning in VS's team explorer window seem to always have core.autocrlf=true, which makes sense since it's a Windows product, but then what happens when you're doing edits in vim or whatever in the git bash mingw window? Do LFs sans CRs get reintroduced? Either way, perhaps the better option is to set * text=auto in .gitattributes, do a big Fix Everything commit in master, let Git internalize everything as LF and checkouts can be whatever the developer's system is, and be done with it? Ciaphas fucked around with this message at 00:32 on Mar 23, 2018 |
|
#
?
Mar 23, 2018 00:28
|
|
|
Scenario: main dev branch gets a bad merge, wiping out a huge chunk of work. This is not noticed until later in the day, after two feature branches are merged into the dev branch and ??? people merge dev into their feature branches. How would you fix? In the heat of the moment my brain shut down and so I checked out the last good commit on dev and cherry-picked the two feature branch merges and the work that had been done as part of the bad merge, then renamed bad branch bad/dev and good branch to the original dev branch name. Then, told everyone to git branch -D dev, git fetch --prune, git checkout dev, and if they'd pulled from dev since the bad merge, to remake their branch and cherry-pick their commits. I didn't do a revert because the bad merge contained a significant enough amount of work that I figured putting a bit of load on everyone was better than making that one person redo a solid day's worth of work. Could I have reverted the merge, then cherry picked the merged commits to reapply the changes? God I hate bad merges. I've had to deal with two of these in the last week 
|
|
#
?
Mar 28, 2018 13:34
|
|
|
Revert the merge and redo it correctly.
|
|
#
?
Mar 28, 2018 14:02
|
|
|
Stringent posted:Revert the merge and redo it correctly. The commits are already in the history, though, so you'd just get an "already up to date"
|
|
#
?
Mar 28, 2018 14:04
|
|
|
|
| # ? May 28, 2024 01:26 |
|
|
Yeah, but in the future that's how you should handle this, imo.
|
|
#
?
Mar 28, 2018 14:07
|
|