|
Ithaqua posted:Agreed, that's the perfect case for a comment saying "this exists in this form because of reasons X, Y, Z." That sounds p deece, but the VS we have at work (2013) doesn't do that... or maybe Perforce doesn't offer this? Would be nice.
|
#
?
Jun 12, 2015 16:27
|
|
|
|
| # ? May 21, 2024 02:25 |
|
|
Ithaqua posted:Agreed, that's the perfect case for a comment saying "this exists in this form because of reasons X, Y, Z." JetBrains stuff does something similar. Well at least PyCharm does, I can't remember if its in IntelliJ/WebStorm/etc, but I would assume so.
|
|
#
?
Jun 12, 2015 16:35
|
|
|
Hammerite posted:That sounds p deece, but the VS we have at work (2013) doesn't do that... or maybe Perforce doesn't offer this? Would be nice. It's part of CodeLens, which is in 2013 Ultimate (and 2015 Pro+). It only works for TFVC and Git, though.
|
|
#
?
Jun 12, 2015 16:48
|
|
|
Thermopyle posted:JetBrains stuff does something similar. Well at least PyCharm does, I can't remember if its in IntelliJ/WebStorm/etc, but I would assume so. I don't seem to have this in phpstorm, unless it's just not working.
|
|
#
?
Jun 12, 2015 17:21
|
|
itskage posted:I don't seem to have this in phpstorm, unless it's just not working. select the method, right click, git -> show history for selection
|
|
|
#
?
Jun 12, 2015 17:37
|
|
|
Ｏｈ ｍｙ ｇｏｄ！ This is great.
|
|
#
?
Jun 12, 2015 18:05
|
|
|
TheresaJayne posted:What made me laugh was "at midnight dec 31st 1999 any plane in the air will suddenly turn off , and baby incubators and heart lung machines will stop working because they will think its 1900 and they didnt exist then so cannot continue to work" i write all of my code to check the current date and if the current date is before the code's last revision date then i start formatting the nearest disk
|
|
#
?
Jun 12, 2015 18:49
|
|
|
QuarkJets posted:i write all of my code to check the current date and if the current date is before the code's last revision date then i start formatting the nearest disk Same but emailing the data to China first
|
|
#
?
Jun 12, 2015 18:54
|
|
|
QuarkJets posted:i write all of my code to check the current date and if the current date is before the code's last revision date then i start formatting the nearest disk Bernard S. Greenberg came up with an interesting strategy to prevent that happening in Multics.
|
|
#
?
Jun 12, 2015 22:11
|
|
|
itskage posted:Ｏｈ ｍｙ ｇｏｄ！ 
|
|
#
?
Jun 12, 2015 23:24
|
|
|
Factor Mystic posted:http://blog.parse.com/learn/how-we-moved-our-api-from-ruby-to-go-and-saved-our-sanity/ Oh man this whole Go thing pissed so many people off. Introducing yet another language to FB's infra is exactly what people wanted to do with their day.
|
|
#
?
Jun 13, 2015 01:09
|
|
|
ultramiraculous posted:Oh man this whole Go thing pissed so many people off. Introducing yet another language to FB's infra is exactly what people wanted to do with their day. I'd say it would be higher up on my list than dealing with rails.
|
|
#
?
Jun 13, 2015 03:19
|
|
|
Bognar posted:I think you should go a step further and remove the commented code entirely, but leave a note saying "This was changed from XXX on 06/06/06, see commit YYY for reference". All commented code is gone, but there's a trail for the developer to follow in case they need it. A datestamp lets them know how relevant it is. What happens if you change your VCS? Becomes kinda less useful.
|
|
#
?
Jun 13, 2015 15:01
|
|
|
uncurable mlady posted:What happens if you change your VCS? Becomes kinda less useful. And if you use a VCS with hashy revision IDs like git, and someone for some reason rewrites history (or even just yourself doing some rebasing shortly after writing those comments, before pushing them) you also risk them going bad. Having a date of the change in the comment as well largely makes up for that, however.
|
|
#
?
Jun 13, 2015 15:12
|
|
|
It seems like git encourages "rewriting history" to somehow clarify the course of your project. I do not see the purpose of doing this unless something gets committed by accident and needs to be amended.
|
|
#
?
Jun 13, 2015 16:20
|
|
|
You should almost never rewrite the history of the main integration branch. However, when you work on a feature or something locally, you will end up with a series of commits that have not been integrated yet to the main branch. Sometimes you can make the history read better by amending or re-arranging the commits. This is usually accomplished with amend or rebase interactive.
|
|
#
?
Jun 13, 2015 16:29
|
|
|
I have often 'rewrote' history by realizing I need to refactor something or clean up a source file before I work on it while I am in the middle of working on a feature. The history and changes are much easier to read and review if you can separate out this refactoring from the changes required for the feature. So, I rebase the refactoring to happen before my feature's changes even though chronologically I did not actually work this way. Another benefit from doing this is that I can easily undo bad changes and go back to a good state w/ my refactorings without accidentally undoing my refactorings. This isn't some esoteric edge case thing b/c it's essentially part of my daily workflow whenever I clean up or refactor something.
|
|
#
?
Jun 13, 2015 16:34
|
|
|
As above, I can turn a local history of 1) WIP 2) Added foo method 3) asdfhkdsa 4) quitting time 5) fix up: import asdf library 6) almost works 7) yessss Into 1) Added foo method to the Bar implementation, which will aid in fizzing the zequod. 2) Full zequod implementation, as per feature request DILZ47. Which looks more professional when sent upstream, and which functions correctly for each commit.
|
|
#
?
Jun 13, 2015 21:52
|
|
|
Rewrite aggressively until your commit is merged upstream and after that only if you really hate the people you work with.
|
|
#
?
Jun 13, 2015 22:41
|
|
|
apseudonym posted:Rewrite aggressively until your commit is merged upstream and after that only if you really hate the people you work with. This. There's a few cases like "accidentally committed 10G of binaries" or "accidentally committed confidential data" where you will revise history of upstream but in general you never do it. Your local branch? Go wild.
|
|
#
?
Jun 14, 2015 07:46
|
|
|
I've often wondered why git doesn't keep a history file that shows history rewrites, rebases, etc. I fully understand it's a content-addressable file system and how the hashing works. My assumption is the history file would only preserve history for pushed branches. But assuming the actual content didn't change (just the hash as a result of the parent hash changing) then it should be trivial for your client to realize you don't actually have three unmerged commits, your coworker just force pushed a rewritten history. Even if the content did change at least git could tell you that it's possibly the result of a rebase. The whole rewriting of history seems like it should be a first-class citizen. I do it almost daily, yet one tiny mistake can completely screw up many people's day.
|
|
#
?
Jun 14, 2015 07:49
|
|
|
Mercurial does history rewriting well with phases. Allows it by default on local commits, prevents it after they've been pushed (unless forced to).
|
|
#
?
Jun 14, 2015 07:56
|
|
|
Ender.uNF posted:I've often wondered why git doesn't keep a history file that shows history rewrites, rebases, etc. git reflog isn't enough?
|
|
#
?
Jun 14, 2015 09:01
|
|
|
Doctor w-rw-rw- posted:git reflog isn't enough? I always read that as re-flog and I'm like, hasn't the repo history had enough punishment?
|
|
#
?
Jun 14, 2015 09:03
|
|
|
Doctor w-rw-rw- posted:git reflog isn't enough? I want the (partial) reflog to be pushed and shared; any rewriting of history that involves already pushed commits should include a log of what was done and whether any content was changed in a commit (or just the parent hash). I can sit down with a list of hashes and figure out what happened after a bad force push by a coworker. (Or in reality by matching up commit comments), why can't git just handle it for me? The answer is that it could, it just doesn't.
|
|
#
?
Jun 14, 2015 09:32
|
|
|
Ender.uNF posted:I want the (partial) reflog to be pushed and shared; any rewriting of history that involves already pushed commits should include a log of what was done and whether any content was changed in a commit (or just the parent hash). Why should reflog info be pushed? Do you want to see twenty commits resulting from git commit --amend? Why? When should they get gc'd away since you're suddenly sharing a lot of garbage commits. If you have a coworker screw you over with a force push you A) shame them B) use git rebase --onto to base your branch(es) off the new ToT after you shame them C) Shame them harder.
|
|
#
?
Jun 14, 2015 10:04
|
|
|
Ender.uNF posted:I want the (partial) reflog to be pushed and shared; any rewriting of history that involves already pushed commits should include a log of what was done and whether any content was changed in a commit (or just the parent hash). It'd be really nice if unchanged commits could somehow retain their hashes, but as I understand, that would require completely different internals. Every time I've had to do a force push, it's been some really dumb thing like 20 commits back that just had to be done, and now all the following commits are changed too  Makes sense though, deep down. Git can't know how whatever is in your local branches should be applied to a different history. What if the file your changes are on doesn't exist any more? Does that mean it's supposed to be completely gone, and your changes aren't important anymore, or does it mean that it has been refactored into several other things where your changes are still relevant? In the end, we annoyingly have to handle some of it manually.
|
|
#
?
Jun 14, 2015 11:01
|
|
|
nielsm posted:And if you use a VCS with hashy revision IDs like git, and someone for some reason rewrites history (or even just yourself doing some rebasing shortly after writing those comments, before pushing them) you also risk them going bad. The discussion went off on a tangent, but note that if this is an issue or if you switch VCS or whatever, revision IDs are unique so you can write scripts to fix this up.
|
|
#
?
Jun 14, 2015 12:06
|
|
|
Skuto posted:The discussion went off on a tangent, but note that if this is an issue or if you switch VCS or whatever, revision IDs are unique so you can write scripts to fix this up. As a practical example, when go moved from mercurial to gerrit git, they simply hid all cls behind golang.org/cl/# which decides if that commit belonged to mercurial, in which case it would be on codereview.appspot.com. Otherwise, it links to go-review.googlesource.com. This made it possible to migrate every issue from the code.google.com issue tracker to github's tracker without breaking any references to cls.
|
|
#
?
Jun 14, 2015 12:25
|
|
|
Using git sure sounds complicated. I mean it's like reading stuff written in a foreign language. At our place we don't really make use of branches on a daily basis, it's used for release management and is something that the project managers do relatively infrequently and people doing maintenance work on the project not at all; work done on the project is just done on trunk. Is that really unusual or does git just push you into branching all the time?
|
|
#
?
Jun 14, 2015 12:50
|
|
|
I guess everyone is rebasing all the time then? And nobody ever does a quick bug fix in the middle of their normal work? I dunno that does sound really unusual. Branches in git are extremely well designed compared to some other VCS. The basic CLI commands are a bit weird but you only have to know like 3 or 4. I wouldn't be surprised if the lack of using branches is what makes git seem complicated as you're likely abusing other features for the same effect. Edit: Remote and remote tracking branches is a concept that may take a bit getting used to. I wish remote tracking branches contained their remotes' name by default, would probably help beginners a lot. Hiowf fucked around with this message at 13:04 on Jun 14, 2015 |
|
#
?
Jun 14, 2015 13:01
|
|
|
Skuto posted:I guess everyone is rebasing all the time then? And nobody ever does a quick bug fix in the middle of their normal work? I don't know offhand what "rebasing" is. I took a quick look at this page but couldn't really follow what the difference is with just merging changes. It looks as though the codebase would end up in exactly the same state either way? Of course we do quick fixes of stuff in the middle of doing other things. I don't follow why you would think we don't.
|
|
#
?
Jun 14, 2015 14:22
|
|
|
Hammerite posted:Using git sure sounds complicated. I mean it's like reading stuff written in a foreign language. SupSuper fucked around with this message at 14:37 on Jun 14, 2015 |
|
#
?
Jun 14, 2015 14:35
|
|
|
Hammerite posted:I don't know offhand what "rebasing" is. I took a quick look at this page but couldn't really follow what the difference is with just merging changes. It looks as though the codebase would end up in exactly the same state either way? Of course we do quick fixes of stuff in the middle of doing other things. I don't follow why you would think we don't. a merge literally merges two branches, it creates a special commit that has two parents rather than one (and whatever changes you did to fix merge conflicts). a rebase lops off a series of commits and makes the tail of the place you're rebasing onto the parent of the first commit you're rebasing. there's still only one parent for each commit. it's nice because you don't get merge commits everywhere but it does remove the history of the branch.... it's a preference thing really.
|
|
#
?
Jun 14, 2015 14:56
|
|
|
git is good because branches are cheap as hell and this is a good feature for a time machine to have.
|
|
#
?
Jun 14, 2015 15:34
|
|
|
Snapchat A Titty posted:It'd be really nice if unchanged commits could somehow retain their hashes, but as I understand, that would require completely different internals. Every time I've had to do a force push, it's been some really dumb thing like 20 commits back that just had to be done, and now all the following commits are changed too This is buried somewhere in this talk that Torvalds gave: https://www.youtube.com/watch?v=4XpnKHJAok8
|
|
#
?
Jun 14, 2015 17:09
|
|
|
Hammerite posted:Using git sure sounds complicated. I mean it's like reading stuff written in a foreign language. One of the main benefits of using branching is for creating individual features or bug fixes. If everyone uses a branch to develop and test a feature in isolation, this means that you do not see the in-progress work and half-baked commits of unfinished functionality of other developers and vice versa. This makes testing and development easier, because you are not worried if the stupid poo poo you are seeing is because of in-progress unfinished work. It also makes it easier to develop incremental changes because you are not afraid of breaking everyone else when you commit. You're not ridiculously stuck in the office on a Friday evening trying to fix the CI server for your unfinished development. This also makes it so the main integration branch is kept free of half-baked development and that it always contains features (or parts of features) that have been developed and tested. A discussion of this workflow is here: https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow Usually, it is best to keep the scope of the developed feature short and break up developing the feature into a bunch of smaller "complete enough" smaller features leading to completing the overall feature so that integration with the rest of the project happens frequently. This will result in less complicated merging scenarios. If you try to do this seemingly simple workflow in SVN, you will crash and burn. I have tried this on SVN releases with the mergeinfo stuff, and it is god awful trying to merge your branch back in. The history of the branch also is annoying difficult to get at (and may even be lost) if you want to delete the branch after you're done with it so you don't see 1000s of feature branches. lol comedyblissoption fucked around with this message at 17:22 on Jun 14, 2015 |
|
#
?
Jun 14, 2015 17:17
|
|
|
In addition, I find it's generally best to take a policy of always rebasing before merging, because I find it makes histories much less confusing, but that's contentious and a lot of people disagree.
|
|
#
?
Jun 14, 2015 17:26
|
|
|
Rebasing is essentially what SVN does whenever you get latest and have to fix your commit. Git just requires you to be explicit about it. Rebase will make the history easier to look at and is also my preferred default. You should use a merge commit when there's actually a complicated merge conflict though. Using rebase with a story workflow will usually require force push permissions on story branches and people understanding what that entails. If you force push, make sure you use the recent --force-with-lease parameter for push. This will deny the force push if the relevant git history looks different on the remote than in your local history at the time of force pushing. This should honestly be the new default setting. Git has had some dumbass defaults. You should almost never force push the main integration branches and set up the permissions so this is difficult to acquire.
|
|
#
?
Jun 14, 2015 17:34
|
|
|
|
| # ? May 21, 2024 02:25 |
|
|
Jsor posted:In addition, I find it's generally best to take a policy of always rebasing before merging, because I find it makes histories much less confusing, but that's contentious and a lot of people disagree. Same, I try to avoid merge commits as much as possible, ideally everything I push would be a fast-forward. Luckily this is simple in a lot of cases by just changing git pull to automatically rebase instead of merge, then for merging feature branches just use rebase before merge. code:
|
|
#
?
Jun 14, 2015 17:44
|
|
