|
Thanks! CTRL+W into the buffer and :q seemed to break the terminal when I tried, but I'll have a fiddle.
|
#
?
Mar 11, 2014 14:16
|
|
|
|
| # ? May 16, 2024 22:37 |
|
|
In Git, is there a quick/easy way of merging a branch into master, and if there are any conflicts, to automatically take the version of the file from the branch I'm merging in? Basically, I need the contents of the other branch to become the new master branch, but retaining commit history etc. Is strategy=ours what I need here?
|
|
#
?
Mar 11, 2014 17:57
|
|
|
I think strategy uses the context of whatever branch you're in, which would be the merge target so you're probably looking for strategy=theirs.
|
|
#
?
Mar 12, 2014 03:19
|
|
|
Who here is using Git in a larger organization with more than, say, 50 or 100 developers? Do you use something like GitLab for managing users and repositories?
|
|
#
?
Mar 12, 2014 11:56
|
|
|
chippy posted:In Git, is there a quick/easy way of merging a branch into master, and if there are any conflicts, to automatically take the version of the file from the branch I'm merging in? You're asking for two different things here. "merge a branch into master, and if there are any conflicts, automatically take that branch's version": git checkout master && git merge -X theirs other-branch. The -X theirs tells the default merge strategy to proceed normally except when conflicts are detected, which will always be resolved in favour of the branch you're merging in. This is not the same as "I need the contents of the other branch to become the new master branch", which implies that you want to throw away all changes made by master including non-conflicting ones. For that, the natural thing to do would be to use the 'theirs' merge strategy (-s theirs, not to be confused with the 'theirs' merge option -X theirs) -- but it was removed several versions ago for some reason. The git devs recommend using git reset instead, but that'll throw away the history you want to keep. Probably the easiest workaround is something like: code:aerique posted:Who here is using Git in a larger organization with more than, say, 50 or 100 developers? Do you use something like GitLab for managing users and repositories? I am (both here and at my previous job), but probably not in a way that helps you. In both places we use Perforce as the backend and then individual developers use git locally - at the previous job using git-p4, and here using a custom git<->p4 bridge that also integrates with stuff like our code review tools. It's actually quite nice, but it also completely avoids answering the question of "how do you scale git to a large organization" by treating it as a single-developer productivity tool instead.
|
|
#
?
Mar 12, 2014 15:14
|
|
|
aerique posted:Who here is using Git in a larger organization with more than, say, 50 or 100 developers? Do you use something like GitLab for managing users and repositories? We have ~60 developers using Git in our organization. Currently we're on GitHub, but we have plans to move off to something else (maybe Stash, we already use Jira).
|
|
#
?
Mar 12, 2014 18:27
|
|
|
aerique posted:Who here is using Git in a larger organization with more than, say, 50 or 100 developers? Do you use something like GitLab for managing users and repositories? Raises hand. Our organization has about 150 developers, our source control is all on GitHub (github.com even, not GitHub Enterprise). We don't have any plans to migrate.
|
|
#
?
Mar 12, 2014 22:09
|
|
|
ToxicFrog posted:For that, the natural thing to do would be to use the 'theirs' merge strategy (-s theirs, not to be confused with the 'theirs' merge option -X theirs) -- but it was removed several versions ago for some reason. The git devs recommend using git reset instead, but that'll throw away the history you want to keep. But if you want to do it anyway, how about this for a workaround: code:
|
|
#
?
Mar 12, 2014 22:36
|
|
|
brae posted:Raises hand. Our organization has about 150 developers, our source control is all on GitHub (github.com even, not GitHub Enterprise). We don't have any plans to migrate. Bet it's a lot of fun when Github.com goes down for hours at a time, like yesterday. We use Github too but we're only three developers so our budget is tight, if we were any larger we'd totally rather have our own Gitlab server rather than be subject to Github's occasional but extremely annoying service problems.
|
|
#
?
Mar 13, 2014 01:57
|
|
|
Github's permissions model is also sort of garbage, which can be an issue for an even sort of small organization.
|
|
#
?
Mar 13, 2014 02:22
|
|
|
NOTinuyasha posted:Bet it's a lot of fun when Github.com goes down for hours at a time, like yesterday. We use Github too but we're only three developers so our budget is tight, if we were any larger we'd totally rather have our own Gitlab server rather than be subject to Github's occasional but extremely annoying service problems. I try not to let deploying our software/service depend on a third party service (like GitHub) where possible, so generally it's not a huge issue when GitHub goes down although I can see how it'd be frustrating. Anyway, it works well for us, but I've heard good things about Gitlab as a self-hosted solution.
|
|
#
?
Mar 13, 2014 03:21
|
|
|
Git works pretty well for text files, as every programmer here that uses it knows, but is there any other VCSs more suitable for other types of files, say images or 3D models?
|
|
#
?
Mar 13, 2014 04:17
|
|
|
Perforce is usually the answer to the "where do I put large binaries?" question.
|
|
#
?
Mar 13, 2014 05:45
|
|
|
necrotic posted:We have ~60 developers using Git in our organization. Currently we're on GitHub, but we have plans to move off to something else (maybe Stash, we already use Jira). We have a whole lot of devs on a huge project. We use gerrit.
|
|
#
?
Mar 13, 2014 06:46
|
|
|
NOTinuyasha posted:Bet it's a lot of fun when Github.com goes down for hours at a time, like yesterday. We use Github too but we're only three developers so our budget is tight, if we were any larger we'd totally rather have our own Gitlab server rather than be subject to Github's occasional but extremely annoying service problems. This was a problem for us when our deploy system simply checked out code from github.com on all 500+ of our servers. We build a slug on one box and ship it out to the rest now. Amazing how many problems that solved.
|
|
#
?
Mar 13, 2014 06:47
|
|
|
Thanks for the answers so far. I'm kind of surprised to hear larger companies storing their source code at external parties like GitHub. Not from a Git perspective (it is a DVCS after all) but more from a legal / security perspective.
|
|
#
?
Mar 13, 2014 09:45
|
|
|
HardDisk posted:Git works pretty well for text files, as every programmer here that uses it knows, but is there any other VCSs more suitable for other types of files, say images or 3D models? From what I've heard, the gaming industry is sticking with SVN for this. You can do large binaries with git-annex or git-fat though. git-annex requires more infrastructure, but with the git-annex-assistant, you can make it into a private dropbox. git-fat only requires you being able to run rsync somewhere. shameless plug time gitano is currently working on having an rsync repository with every git repository, to make it easier to use git-fat, and be able to apply the same access control rules for git repositories to the rsync repository.
|
|
#
?
Mar 13, 2014 09:57
|
|
only
|
necrotic posted:This was a problem for us when our deploy system simply checked out code from github.com on all 500+ of our servers. How do you keep that up to date vs github? IE: I'm an engineer I push to github and want to see a build kicked off within seconds. Does kicking off the build start with the slug pulling from github then notifying the 500+ servers?
|
|
#
?
Mar 13, 2014 14:36
|
|
|
Dylan16807 posted:Apparently the 'theirs' merge strategy was removed because they don't like that workflow. If you want to keep that unused history you're supposed to stick it in a different branch: http://marc.info/?l=git&m=121637513604413&w=2 I almost suggested that, actually, but it doesn't handle deletions properly - if master has files A B C, and other-branch adds D and deletes B, those commands may result in you having A B C D rather than A C D, depending on how the initial merge went. HardDisk posted:Git works pretty well for text files, as every programmer here that uses it knows, but is there any other VCSs more suitable for other types of files, say images or 3D models? That's part of why we use Perforce. There's also git-annex and git-media, neither of which I've used.
|
|
#
?
Mar 13, 2014 14:43
|
|
|
Hughlander posted:How do you keep that up to date vs github? IE: I'm an engineer I push to github and want to see a build kicked off within seconds. Does kicking off the build start with the slug pulling from github then notifying the 500+ servers? That's pretty much what we have. A push to github triggers a jenkins job which pulls from github, builds everything, then pushes (SCP, I think) everything out to each server. This relies on having the jenkins server be build identically to the production servers, but that's what puppet is for.
|
|
#
?
Mar 13, 2014 15:25
|
|
|
git-fat seems the more interesting to me. Thanks! 
|
|
#
?
Mar 13, 2014 16:19
|
|
|
Hughlander posted:How do you keep that up to date vs github? IE: I'm an engineer I push to github and want to see a build kicked off within seconds. Does kicking off the build start with the slug pulling from github then notifying the 500+ servers? We don't do continuous deployment yet, just integration tests. A deploy to all 500+ servers has a bit of process behind it... Sailor_Spoon posted:That's pretty much what we have. A push to github triggers a jenkins job which pulls from github, builds everything, then pushes (SCP, I think) everything out to each server. This relies on having the jenkins server be build identically to the production servers, but that's what puppet is for. Something similar to this. Any new PR (or changes to a PR) triggers a build on Jenkins for our testing platform, and when changes are ready for prod our team merges PRs into a release branch that also triggers a build. We then use an in-house tool to push the slug out to all of our servers (or a single facet, or a single server in each facet, or a percentage of servers, etc...). We plan on releasing the tool at some point to the public, but it's still changing a lot so thats some ways away yet  edit: Also, chef is the workhorse. If a new server spins up (EC2 auto scalers) it knows how to fetch the current production slug and install it. Once a server spins up Chef only does a few maintenance tasks (around user access and such).
|
|
#
?
Mar 13, 2014 18:15
|
|
|
In git, is there any way to interactively-rebase (for a fixup) back before a merge? Something like: A | B | \ C m | D and I want to squash A into C.
|
|
#
?
Mar 18, 2014 19:23
|
|
|
--preserve-merges might work, but it combines oddly with interactive rebases. If the merge is simple, you could just discard it during the rebase then remerge the branch after fixing up C.
|
|
#
?
Mar 18, 2014 19:36
|
|
|
I tried that, but there was a merge conflict which confused me because there was no conflict during the original merge, so I just aborted. (The merge wasn't trivial, though.) I've also oversimplified a bit, and the graph should really look like this: X | A | B | \ C m | D Where A should be squashed into C, but X substantially depends on the merge, so I can't really discard and re-merge. It's not a huge deal, it's just annoying (A is a single line).
|
|
#
?
Mar 18, 2014 20:01
|
|
|
With the discard-and-re-merge approach you could just discard X as well, then cherry-pick it after re-merging (or if X is actually a bunch of commits that would be annoying to cherry-pick individually, use rebase --onto to transplant the whole series). Somewhat relevant to this, if you don't have rerere enabled, you should fix that.
|
|
#
?
Mar 18, 2014 21:17
|
|
|
Is there any good way to do this without spending more time on the architecture of the program? Basically I want to maintain two separate versions of the same software, but only two of the files are different from eachother between versions. I want all of the other (thousands) of files to stay linked and edited between the two. We use (hosted) TFS if that matters at all. Thanks.
|
|
#
?
Mar 20, 2014 00:42
|
|
|
Knyteguy posted:Is there any good way to do this without spending more time on the architecture of the program? Is it some sort of config file or something? Just put them both in the same code base and control which of those two files are used with an environment variable or something.
|
|
#
?
Mar 20, 2014 00:48
|
|
|
Knyteguy posted:Is there any good way to do this without spending more time on the architecture of the program? There's always a solution but I don't understand your problem. What does the file do? Is it code that needs to be compiled? Is it configuration? Why do you need this one particular file to change when all of the other thousand files remain the same? If it's a config file Slow Cheetah is the first thing that pops into my head EDIT: Also beaten gariig fucked around with this message at 00:52 on Mar 20, 2014 |
|
#
?
Mar 20, 2014 00:48
|
|
|
Unfortunately it's not a config file or anything; it's two separate versions of a class (controller) in MVC. Basically I've been rolling back changes and compiling when we need one version, and then rolling "back" to the current version when we need the other. The software doesn't have controller methods that can be overridden. Anyway since it doesn't sound like there's an easy solution to this, I'll probably just throw a new setting flag in the database and change methodology based on that. Thanks for the help.
|
|
#
?
Mar 20, 2014 16:30
|
|
|
Knyteguy posted:Unfortunately it's not a config file or anything; it's two separate versions of a class (controller) in MVC. Basically I've been rolling back changes and compiling when we need one version, and then rolling "back" to the current version when we need the other. The software doesn't have controller methods that can be overridden. Another idea would be to customize the controller factory to return the correct controller implementation under whatever criteria dictate which version to use (that could be a config flag).
|
|
#
?
Mar 20, 2014 16:37
|
|
|
^^^^ something like that would be a pretty good approach. Could do it internally to the controller as well where you swap out underlying implementations. Other thing you could do is use #ifdef a bit and have 2 controllers in one file that chooses based on a build environment variable.
|
|
#
?
Mar 21, 2014 17:18
|
|
|
Or go whole hog with some dependency injection.
|
|
#
?
Mar 21, 2014 17:44
|
|
|
If I have a feature branch (git) and it comes time to merge it back into master. There was like 50 commits to the feature branch, so when I merge it I --squash it into a single commit to keep things clean. Is that a bad idea? I want to keep the commit log for master nice and clean, but I could see how those 50 commits might be useful down the road if there was a question about why something was done a certain way. Should I just keep the remote branch around there for that purpose?
|
|
#
?
Mar 22, 2014 01:15
|
|
|
fletcher posted:If I have a feature branch (git) and it comes time to merge it back into master. There was like 50 commits to the feature branch, so when I merge it I --squash it into a single commit to keep things clean. Is that a bad idea? I want to keep the commit log for master nice and clean, but I could see how those 50 commits might be useful down the road if there was a question about why something was done a certain way. Should I just keep the remote branch around there for that purpose? It totally depends on your workflow. You could always give a detailed message in your merge commit. I like to rebase my commits into reasonable, logical changes before merging (see: hiding the sausage).
|
|
#
?
Mar 22, 2014 02:05
|
|
|
Squashing 50 commits into one is almost certainly excessive, unless the whole series of commits is introducing just a single new thing and nearly all of the commits are just fixing bugs in that new thing.
|
|
#
?
Mar 22, 2014 02:17
|
|
|
fletcher posted:If I have a feature branch (git) and it comes time to merge it back into master. There was like 50 commits to the feature branch, so when I merge it I --squash it into a single commit to keep things clean. Is that a bad idea? I want to keep the commit log for master nice and clean, but I could see how those 50 commits might be useful down the road if there was a question about why something was done a certain way. Should I just keep the remote branch around there for that purpose? Have you pushed your feature branch anywhere? If so, neither squash nor rebase, for those are the tools of the devil.
|
|
#
?
Mar 22, 2014 02:27
|
|
|
prefect posted:Have you pushed your feature branch anywhere? If so, neither squash nor rebase, for those are the tools of the devil. Yea I've been pushing it to a remote branch at the end of every day. Most of the commits are just dumb little things and bug fixes for the new feature before it had a round of testing on it. Once testing starts each bug would then be handled in a separate ticket/commit.
|
|
#
?
Mar 22, 2014 02:38
|
|
|
I don't like the idea of "well, if you want to know the real history, look at the repo over there." But if you have to do a squashed merge (using gerrit or something), it's strictly better to provide a detailed history somewhere with a pointer to it in the commit message, then to eliminate it entirely. If you don't have to do a squashed merge, then either keep the entire feature history in place, or maybe clean up the most egregious commits. On the master branch, "git log --first-parent" will provide the summarized history you're looking for, while the detailed feature commits are still there for when you need them. Edit: The problem with squash and rebase isn't whether you're pushing to a remote repository. It's whether anyone else has access to that remote repository and is likely to have cloned/fetched from it.
|
|
#
?
Mar 23, 2014 20:46
|
|
|
|
| # ? May 16, 2024 22:37 |
|
|
Thanks for all the comments on my last question, very helpful! Got another one now. I've been using tags to label versions for release. Last release was 2.5.0 and I'm currently working on 2.6.0, but there's a hotfix that needs to go out before 2.6.0. So I created a new branch off 2.5.0: code:code:
|
|
#
?
Mar 27, 2014 20:08
|
|