|
I finally came to appreciate the git merge versus rebase debate the other day. I normally only do anything at all interesting with team projects outside of work, so I was used to just merging. Now I have somebody telling me their work team's policy has been using rebase to join branches back to the master. I looked it up and I'm flabbergasted. That's a lot of history alteration and undoing it is a real pain in the rear end. I had assumed when they originally told me they rebased that they were using it to collapse multiple commits before making a merge, or maybe they were rebasing to incorporate master into their branch. But really... rebasing your branch onto the master?
|
#
?
May 11, 2016 16:28
|
|
|
|
| # ? May 12, 2024 17:56 |
|
|
uXs posted:Is there some way in Git to just checkout the latest commit, skipping over all the intermediate ones? A shallow-clone should pull only the latest commit, but eventually I think you need the rest of the history? I haven't really looked into shallow clones.
|
|
#
?
May 11, 2016 16:47
|
|
|
uXs posted:Is there some way in Git to just checkout the latest commit, skipping over all the intermediate ones? Is the problem that your current working copy (on Windows) has files with too long paths, which then can't be removed? If that's the case, you will probably have to remove them manually. The easiest way, that doesn't need special software, is usually to rename folders above the "victim" files until the total paths are sufficiently short. You may have to do some hard resetting or other nasty stuff after that, to get your working copy working again.
|
|
#
?
May 11, 2016 17:35
|
|
|
22 Eargesplitten posted:I made a pretty embarrassing typo in one of my commit messages. I've updated a lot of the contents, but stuff like the project file and other basic stuff that doesn't get changed still has it. Basically I started trying to write a commit message within my commit message when I had just started out with .git. I want to use this project as part of my portfolio, so I want to make it look nice. Or, since I also cleaned up a really messy file system, would it look most professional to just delete that repo and push the finished project to a new one?
|
|
#
?
May 11, 2016 20:00
|
|
|
I've been running into problems a lot where I don't like the changes I made and I want to get rid of them and pull the last commit I had. What's the best way to do that? I just got a bunch of weird merge errors when I tried git reset --hard and then git pull origin master. Now the script I was wanting to work on has gibberish all over the place.
|
|
#
?
May 13, 2016 20:10
|
|
|
22 Eargesplitten posted:I've been running into problems a lot where I don't like the changes I made and I want to get rid of them and pull the last commit I had. What's the best way to do that? I just got a bunch of weird merge errors when I tried git reset --hard and then git pull origin master. Now the script I was wanting to work on has gibberish all over the place. git reset <commit id you want to go back to> --hard Or to just go back to the place you were when you last pushed to origin: git reset origin/branchname --hard
|
|
#
?
May 13, 2016 20:52
|
|
|
Okay, that's what I did, I'm not sure why it screwed up like that.
|
|
#
?
May 13, 2016 20:58
|
|
|
If you're looking at a gitbhub PR, and you have a non-trivial suggestion to make, or an alternative implementation, how do you relay that? Make a PR to the submitter's fork? Or submit a new PR to the original repo, on top of their PR?
|
|
#
?
May 18, 2016 03:29
|
|
|
if it's an alternative implementation i'd only bother if it's objectively much better and i'd do it as it's own pr. otherwise i'd just comment on the pr or move along
|
|
#
?
May 18, 2016 23:37
|
|
|
Fork the repo, checkout the PR's branch, make your change, commit, push, then link the diff on github in the PR comments e.g. code:
|
|
#
?
May 19, 2016 00:10
|
|
|
I feel like there should be an obvious answer to this question, but googling isn't finding it. Is there some sort of setting for github to let people download a repo without my needing to approve it? Or does it do that automatically? I just see that it's called a pull request, which sounds like I need to approve it.
|
|
#
?
May 21, 2016 19:07
|
|
|
22 Eargesplitten posted:I feel like there should be an obvious answer to this question, but googling isn't finding it. Is there some sort of setting for github to let people download a repo without my needing to approve it? Or does it do that automatically? I just see that it's called a pull request, which sounds like I need to approve it. A pull request is someone asking you to integrate a change of theirs. (Requesting you to pull a change from them.) If your repository is public, anyone can clone it, i.e. make a copy for themselves.
|
|
#
?
May 21, 2016 19:28
|
|
|
Oh, okay. I always think of pulls as being from the repo rather than to the repo. That makes more sense. Cool, I just wanted to make sure I wasn't linking to my github on my resume and then giving potential employers no way to actually get my code.
|
|
#
?
May 21, 2016 19:33
|
|
|
22 Eargesplitten posted:Oh, okay. I always think of pulls as being from the repo rather than to the repo. That makes more sense. Cool, I just wanted to make sure I wasn't linking to my github on my resume and then giving potential employers no way to actually get my code. Thunk of it like this: they are Requesting that you Pull their changes into your repo.
|
|
#
?
May 22, 2016 00:27
|
|
|
I just pushed to github, and git status reports that my local branch is up-to-date with the remote, but the push isn't reflected on Github. It's like it never happened. Any ideas?
|
|
#
?
May 23, 2016 16:59
|
|
|
raminasi posted:I just pushed to github, and git status reports that my local branch is up-to-date with the remote, but the push isn't reflected on Github. It's like it never happened. Any ideas? Github appears to be having some issues at the moment.
|
|
#
?
May 23, 2016 17:02
|
|
|
good jovi posted:Github appears to be having some issues at the moment. lmao, but that never happens
|
|
#
?
May 23, 2016 22:00
|
|
|
If only they had a way to roll back to a more stable version.
|
|
#
?
May 25, 2016 16:46
|
|
|
In Git, say I were to push one of my branches up to origin for others in my team to look at, via git push origin ovm_optimize. When they're done looking at it, should I then delete it on origin via git push origin :ovm_optimize, or does it really not matter at all/depends on my team policy (which I'm pretty much making up as I go along anyway)? For that matter, is there a nicer way to delete a remote branch than that? I understand what it means and why it works, it just looks doofy  (ed: I guess I could write an alias, huh)
|
|
#
?
Jun 4, 2016 00:28
|
|
|
Ciaphas posted:In Git, say I were to push one of my branches up to origin for others in my team to look at, via git push origin ovm_optimize. When they're done looking at it, should I then delete it on origin via git push origin :ovm_optimize, or does it really not matter at all/depends on my team policy (which I'm pretty much making up as I go along anyway)? I'm not familiar with that colon syntax, what is it? The manual just says to do this: code:
|
|
#
?
Jun 4, 2016 01:38
|
|
|
Stringent posted:I'm not familiar with that colon syntax, what is it? [edit] I was wrong! It's actually way more complicated than that! http://stackoverflow.com/questions/7303687/why-git-use-the-colon-branch-to-delete-remote-branch
|
|
#
?
Jun 4, 2016 02:34
|
|
|
Stringent posted:I'm not familiar with that colon syntax, what is it? It's what I was taught from the git book--read as "take nothing and overwrite the remote's branch called ovm_optimize with it". Like I said, kinda doofy! Guess they must have added --delete in a later revision.
|
|
#
?
Jun 4, 2016 02:49
|
|
|
--delete was added in version 1.7.0. https://github.com/gitster/git/blob/master/Documentation/RelNotes/1.7.0.txt
|
|
#
?
Jun 5, 2016 18:00
|
|
|
We've got updated books at work now and, yeah, they both mention the colon delete syntax as historical footnotes. The one I was referencing appears to have been written with 1.6.1 in mind. Still kinda wracking my brain on what sort of policy to set with our team re: pushing and deleting topic branches to central: whether to push them at all, whether to delete them, whether to rebase onto master and fast forward when done or always merge with --no-ff, etc. Being the CM guy is hard even on a small team of four 
|
|
#
?
Jun 9, 2016 01:01
|
|
|
Ciaphas posted:We've got updated books at work now and, yeah, they both mention the colon delete syntax as historical footnotes. The one I was referencing appears to have been written with 1.6.1 in mind. We push feature branches to remote. Make a pull request to the target branch. That gets merged into the target branch, ff if possible optionally --squash if you want to do all your merge conflicts in one go. Then the remote feature branch is deleted.
|
|
#
?
Jun 9, 2016 02:07
|
|
|
Stringent posted:We push feature branches to remote. Make a pull request to the target branch. That gets merged into the target branch, ff if possible optionally --squash if you want to do all your merge conflicts in one go. Then the remote feature branch is deleted. The nice thing if you're using github, is there is a "Delete branch" button after you press the merge button. Also, for your local sanity, add to your .gitconfig: [alias] cleanfeature = branch --merged | grep "feature/" | xargs -n 1 git branch -d Then, run "git cleanfeature" from your development branch, and it will delete all local branches that start with "feature/" and have been fully merged.
|
|
#
?
Jun 9, 2016 13:34
|
|
|
Ciaphas posted:
We have a script that deletes merged branches with the last commit greater than 30 days ago and sends an email if it's not merged but last commit of 60 days ago unless that commit also has a note to not send mail.
|
|
#
?
Jun 9, 2016 14:52
|
|
|
Ciaphas posted:Still kinda wracking my brain on what sort of policy to set with our team re: pushing and deleting topic branches to central: whether to push them at all, whether to delete them, whether to rebase onto master and fast forward when done or always merge with --no-ff, etc. As for merge vs. rebase, I really believe there's no one right policy. Any change that's one commit in size (possibly because it's been squashed) should probably be rebased so you don't burn a merge commit and there's no real downside. But if there's been work done on a feature branch for a while, where the historical context is important, then a merge is definitely appropriate. For things in the middle, it's more of a question of whether individual commits on a feature branch actually communicate anything, and if they don't then squash them. For some people it's important to track each branch merge explicitly in which you probably never want to rebase, but I don't think that has any inherent value.
|
|
#
?
Jun 9, 2016 17:19
|
|
|
I lean toward rebasing, personally, but the boss of my team is a little squirmy on the idea of  losing history in that manner. Part of the clearcase background, I guess, where history is nearly immutable (and branches are totally different concepts, eugh).
|
|
#
?
Jun 9, 2016 22:23
|
|
|
There's situations in which rebasing is a measurably worse. Rebasing a stack of commits that have regular merge conflicts with the main branch is very painful to churn through. There's also a good chance that the nature of the conflicts renders the interim commits broken or moot--certainly you're not testing each individual commit as you churn through the rebase. It's much better to do either a regular merge and resolve the conflicts at once, or a squash and rebase which is effectively the same but results in a simpler history. On the other hand, rebasing a small number of conflict-free commits is just as easy as a merge and results in a linear history as well. If the rebased changes are really orthogonal to whatever development was going on the main branch there's no downside. My point is that it's very much situation dependent, and "always merge" or "always rebase" policies don't take into account the specifics of any particular situation for which one approach may well be superior to the other.
|
|
#
?
Jun 10, 2016 18:29
|
|
|
ExcessBLarg! posted:There's situations in which rebasing is a measurably worse. Rebasing a stack of commits that have regular merge conflicts with the main branch is very painful to churn through. There's also a good chance that the nature of the conflicts renders the interim commits broken or moot--certainly you're not testing each individual commit as you churn through the rebase.
|
|
#
?
Jun 10, 2016 18:53
|
|
|
I do compile checks at most when a git conflict crops up, but that's mostly because in our shop and the way our databases are structured going back to past versions of the software is a bit of a fool's errand anyway.
|
|
#
?
Jun 10, 2016 20:37
|
|
|
Got a question about working with a large team. Let's say the team is big enough such that somebody is pushing code every 10 minutes. If it takes 40 minutes to compile & run tests, it seems impossible to compile & run tests before you push your code. I mean you can do it with a fairly recent commit to be reasonable sure it will work when the build server picks up your changes. I'm wondering, what are some ways to improve this situation? It seems like maybe splitting up the single huge repo into multiple smaller ones would help a bit.
|
|
#
?
Jun 10, 2016 23:40
|
|
|
fletcher posted:Got a question about working with a large team. Let's say the team is big enough such that somebody is pushing code every 10 minutes. If it takes 40 minutes to compile & run tests, it seems impossible to compile & run tests before you push your code. I mean you can do it with a fairly recent commit to be reasonable sure it will work when the build server picks up your changes. 40 minutes on a developer machine? How long of that is spent building versus running tests? Are the tests integration tests, unit tests, functional tests, etc? A few ways to address this kind of thing, off the top of my head: - If the application itself takes a long time to build, either switch to a microservice architecture with versioned APIs or start using a package manager so you can build and test only what's changing instead of the whole application. - If the tests take a long time to run, look at the tests. Unit tests: Make sure they're actually unit tests (by which I mean everything that's not the code under test is being mocked). Make sure that each test case actually tests a unique, valid scenario. I've seen plenty of times where someone wrote 15 tests of which 14 are testing the same thing. If an individual test takes under 5-10 milliseconds to run it's probably not worth worrying about, unless you have thousands of tests. Are they integration tests? Make sure they shouldn't be unit tests, but someone was being lazy and didn't feel like mocking the data access layer, or something like that. Are they functional tests (like a UI test)? Don't run those so frequently, those work best as smoke tests as a post-deployment step before the QA team gets their hands on it. Then you can do actual CI against the pieces of the application as they change, and do a big "everything and the kitchen sink" build/test run as frequently as makes sense for the size of the codebase (every hour? two hours? Twice a day?)
|
|
#
?
Jun 11, 2016 01:44
|
|
|
fletcher posted:Got a question about working with a large team. Let's say the team is big enough such that somebody is pushing code every 10 minutes. If it takes 40 minutes to compile & run tests, it seems impossible to compile & run tests before you push your code. I mean you can do it with a fairly recent commit to be reasonable sure it will work when the build server picks up your changes. What we've done is parallelize the tests and minimize the chance of failures, then run them in a queued fashion first in first tested. It can still be hour+ before your change is on master if 4-5 people push at the same time.
|
|
#
?
Jun 11, 2016 02:07
|
|
|
fletcher posted:Got a question about working with a large team. Let's say the team is big enough such that somebody is pushing code every 10 minutes. If it takes 40 minutes to compile & run tests, it seems impossible to compile & run tests before you push your code. I mean you can do it with a fairly recent commit to be reasonable sure it will work when the build server picks up your changes. Would it make sense to get people to switch to committing larger units of work? Normally you'd have people working in a private branch for a while, and only run a full test suite and merge to master once their feature or fix or whatever is complete and reviewed. You also want a pool of machines to parallelize test runs, of course.
|
|
#
?
Jun 11, 2016 02:09
|
|
|
Yup we're running tests in parallel, and folks are working on private branches and then merging in larger chunks of changes when they are ready. Thanks for the other suggestions as well, I will explore those further.
|
|
#
?
Jun 11, 2016 02:38
|
|
|
Ithaqua posted:I have a client who is currently using centralized VC (and they're not switching; they would be miserable using Git). However, they have literally 20 GB of images in their application, mixed in liberally among the code. They have a weird content deploy process in place, but it doesn't synchronize across all their enviroments, only production. And it's flaky enough that it's okay, but every build they do that's going to eventually make it to prod has to include all the content, which means they have tons of 20 GB build artifacts clogging up their servers, when 19.8 of the 20 GB is exactly the same and static between every single build they've done. Anyone have any thoughts on this? I just got a panicked call from this client because their content deployment process mysteriously deleted a bunch of files from production and I'm going to spend the next day or two trying to reproduce the issue so we can figure out what the hell happened.
|
|
#
?
Jun 22, 2016 19:48
|
|
|
Ithaqua posted:Anyone have any thoughts on this? I just got a panicked call from this client because their content deployment process mysteriously deleted a bunch of files from production and I'm going to spend the next day or two trying to reproduce the issue so we can figure out what the hell happened. git-lfs works well but if they won't use that you can do something vaguely similar with a roll your own that I've used before git-lfs was a thing: Check in a manifest file, containing a list of files and their SHA for the current version. Store each file by SHA in Amazon S3. Have a small script that reads the manifest file and downloads each file that doesn't exist to a permanent storage location. (By SHA) Have a second or same script to hard-link the file in it's final path/name from the SHA. Bonus: rolling back content is instantaneous as you just need to relink it.
|
|
#
?
Jun 29, 2016 21:24
|
|
|
|
| # ? May 12, 2024 17:56 |
|
|
I'm having some weird permissions issue when trying to load an SVN dump file on my local machine. I'm on Windows 7. I received an SVN dump file from a vendor of ours, and I'm trying to load it to verify that it's a valid dump file. https://blog.codinghorror.com/setting-up-subversion-on-windows/ - I used this guide to set up an SVN server as a service on my local machine. The service seems to be running fine, and I can checkout/commit as well. I've also set up the service to Log On as myself, where I am a local administrator on my machine. Now, I'm trying to run this command from an Administrator shell: code:code: Every group or user name has Full Control permissions. The folder myproject\format also has the same exact permissions. I've scoured Google for the past 6 hours with no results. I know Windows permissions are a weird beast compared to Unix permissions, but I'm stumped at this point. What the gently caress am I missing? Thank you much for any and all help!
|
|
#
?
Jul 7, 2016 23:48
|
|
