|
I never understood why we don't have source control that just stores every change, google docs style. You could still create commits at certain states and have a git style branch structure on top so that the history isn't cluttered, but it's still a little funny that you have to save, add, commit, and push remotely before a particular piece of work is actually backed up.
|
#
?
Dec 29, 2013 20:31
|
|
|
|
| # ? May 14, 2024 02:02 |
|
|
Pardon my ignorance here, but is that the equivalent of working on a document for 180 hours and only hitting save 3 times? I don't git it.
|
|
#
?
Dec 29, 2013 20:36
|
|
|
bobua posted:Pardon my ignorance here, but is that the equivalent of working on a document for 180 hours and only hitting save 3 times? I don't git it. You're supposed to be using source control to simultaneously write a history of the codebase while you're developing it so anyone at any point can look through and see exactly how any line has changed over time. What they're doing is condensing 180 hours of changes in to three commits, and those three commits giving no details on why anything was changed, only that it was changed.
|
|
#
?
Dec 29, 2013 20:48
|
|
|
evensevenone posted:I never understood why we don't have source control that just stores every change, google docs style. You could still create commits at certain states and have a git style branch structure on top so that the history isn't cluttered, but it's still a little funny that you have to save, add, commit, and push remotely before a particular piece of work is actually backed up. Because that sort of workflow doesn't make sense for code. You're frequently editing multiple files at the same time, and the files are in a bad state (non-compiling, non-working) more often than they're not.
|
|
#
?
Dec 29, 2013 20:51
|
|
|
evensevenone posted:I never understood why we don't have source control that just stores every change, google docs style. You could still create commits at certain states and have a git style branch structure on top so that the history isn't cluttered, but it's still a little funny that you have to save, add, commit, and push remotely before a particular piece of work is actually backed up. I did this when I developed an online Python IDE for a beginners programming class I was teaching last year. Every edit was sent to the server and treated as a git commit (edits within some threshold, like 2 minutes, were amended since they were assumed to be part of the same edit and to keep from blowing up the repo). Then, every time the student was happy enough with the state of their code to check it for correctness against the automated tests, that was marked with a tag. It worked quite well (most of the gitness was hidden from students but they could view the whole history with their scores at each tag if they wanted), but what was awesome was catching a cheating student by using a git-playback script that I found to see that his code had a commit that just magically replaced all of the lines of his file, as if the correct solution had been pasted in from elsewhere... ^^ but yeah, what's great for a simple student experience would be rough for "real" development.
|
|
#
?
Dec 29, 2013 20:55
|
|
|
Don't know if this counts as a horror or just a "whoopsie!" but I noticed the naming of the three-tier architecture my project uses is out of order. We do Controller calls Repository calls DataService on our web server. Online I see Controller -> Service -> Repository. Over to the other side of the web service to what's sitting on top of our database, it's Service calls a ServiceLogicLayer calls a DataAccessLayer, which sits on the DB. THAT is in the right order at least, right? Meh.
|
|
#
?
Dec 29, 2013 21:41
|
|
|
bobua posted:Pardon my ignorance here, but is that the equivalent of working on a document for 180 hours and only hitting save 3 times? I don't git it. As a source control metaphor, that's probably pretty close. The real sin that doesn't translate over is that there's no history information, which means that there's no good information on how the software developed and why. When looking at something funny in a particular chunk of code, looking at the line-by-line history can be very enlightening in explaining why that came to be; if everything in the function is from one commit, except for one line which is from a later commit, you can look at the later commit's log and see that it happened because of bug FOO which caused behavior BAR, which is something you'll want to watch out for if you're going to proceed to change that line. This is the source control equivalent of dumping a binary in your lap along with source files created via binary decompilation and a post-it note of "Good luck!"
|
|
#
?
Dec 29, 2013 22:24
|
|
|
I haven't used sourcetree but I use gitextensions for my git gui and am pretty happy with it. Admittedly my use case is small personal projects and open source stuff, so ymmv
|
|
#
?
Dec 29, 2013 23:50
|
|
|
evensevenone posted:I never understood why we don't have source control that just stores every change, google docs style. You could still create commits at certain states and have a git style branch structure on top so that the history isn't cluttered, but it's still a little funny that you have to save, add, commit, and push remotely before a particular piece of work is actually backed up. In all seriousness, Sparkleshare. You save your file, it's saved to a Git repo. Not particularly the quickest and feature filled program in the world though, seeing as it's a Dropbox replacement for nerds.
|
|
#
?
Dec 29, 2013 23:58
|
|
|
evensevenone posted:I never understood why we don't have source control that just stores every change, google docs style. You could still create commits at certain states and have a git style branch structure on top so that the history isn't cluttered, but it's still a little funny that you have to save, add, commit, and push remotely before a particular piece of work is actually backed up. IntelliJ's IDEs call this feature "Local History", and it works nicely alongside their Git/Mercurial/Whatever integration. It's especially useful for exploratory coding as a kind of persistent infinite undo.
|
|
#
?
Dec 30, 2013 00:08
|
|
|
Westie posted:In all seriousness, Sparkleshare. I've not used Sparkleshare, but the git annex assistant seems to be another candidate for Dropbox replacement for nerds. Supposedly it was developed to get by Git's poor performance on large binaries, which was a problem with Sparkleshare.
|
|
#
?
Dec 30, 2013 00:55
|
|
only
|
WHY CAN'T YOU REVERT CHANGES ON JUST A SINGLE MOTHER loving FILE IN GIT Jesus Christ that would be the easiest feature in the entire universe to add and it just hasn't happened yet.
|
|
#
?
Dec 30, 2013 02:23
|
|
|
it is posted:WHY CAN'T YOU REVERT CHANGES ON JUST A SINGLE MOTHER loving FILE IN GIT http://lmgtfy.com/?q=revert+changes+on+a+single+file+in+git
|
|
#
?
Dec 30, 2013 02:26
|
|
|
it is posted:WHY CAN'T YOU REVERT CHANGES ON JUST A SINGLE MOTHER loving FILE IN GIT git checkout commit file, then git commit?
|
|
#
?
Dec 30, 2013 02:27
|
|
|
it is posted:WHY CAN'T YOU REVERT CHANGES ON JUST A SINGLE MOTHER loving FILE IN GIT I can do it just fine, the real question is why can't you? git checkout <SHA>~ -- path/to/file
|
|
#
?
Dec 30, 2013 03:34
|
|
|
The real question is why the gently caress that's part of git checkout. git's command line interface is terrible.
|
|
#
?
Dec 30, 2013 03:44
|
|
|
Checking out the version of a file before a commit isn't the same as reverting that commit; you'd clobber subsequent changes as well. Revert only removes the changes that were made on that specific commit. I'm surprised if "git revert <sha> --<filename>" doesn't work though.
|
|
#
?
Dec 30, 2013 04:00
|
|
|
evensevenone posted:Checking out the version of a file before a commit isn't the same as reverting that commit; you'd clobber subsequent changes as well. Revert only removes the changes that were made on that specific commit. You can do checkout -p or something if all you need is the delta. Revert creates a new commit as the inverse of the given commit though, doesn't it? That would blow away your unstaged changes just as much (or complain that it would happen without doing it)
|
|
#
?
Dec 30, 2013 04:19
|
|
|
You can revert commits while you have uncommitted changes as long as they don't conflict, but I have no idea why you'd want to unless you really like losing work whenever anything goes at all wrong. For reverting the changes made to only a single file in a commit when there have been further committed changes to the file that should be left alone, I'd revert the commit, do a soft reset to HEAD~1, add the file in question and commit, then do a hard reset. There may be a better way.
|
|
#
?
Dec 30, 2013 05:25
|
|
|
branch at the commit just before the one you want to revert, cherry pick the commit you are trying to partially revert, checkout/reset the file you wish to revert then interactively merge
|
|
#
?
Dec 30, 2013 06:32
|
|
|
As we all post about git, I realize this question might be better placed here
|
|
#
?
Dec 30, 2013 12:22
|
|
|
Westie posted:In all seriousness, Sparkleshare. I would like to thank you for this. I've been looking for something like this for a month or so now.
|
|
#
?
Dec 30, 2013 17:33
|
|
|
HORATIO HORNBLOWER posted:I feel responsible not because I physically typed the command but because this guy knows nothing about git and would have typed anything I told him to (despite the fact that he's been "using" git for years and I just started learning it a year ago). I found the horror. HORATIO HORNBLOWER posted:On the subject of git GUIs, I'm of the belief that they can be helpful to visualize the branches and the overall change history but none of them really expose the full power of git. If you don't learn the commands you haven't learned git. I think that was part of the problem here. All of our other team members use a GUI exclusively and don't know how to do much besides push and pull. They don't understand stashing, they don't understand branching, and so it's really no surprise that they only understand the necessity of committing in terms of being able to push to the remote so the build machine can churn out a WAR. GUIs are cool, but you still gotta understand what it is, first. They don't magically give you git understanding. And if you're treating git like its loving CVS, you're doing it wrong.  it is posted:WHY CAN'T YOU REVERT CHANGES ON JUST A SINGLE MOTHER loving FILE IN GIT  Well don't you feel silly?
Zaphod42 fucked around with this message at 17:53 on Dec 30, 2013 |
|
#
?
Dec 30, 2013 17:45
|
|
|
People seem to have trouble actually being productive with Git far more than any other VCS. If every commit potentially resulted in having to spend 30 minutes figuring out what command line arcana to invoke so that I could get back to work, I'd commit infrequently too.
|
|
#
?
Dec 30, 2013 18:13
|
|
|
Ithaqua posted:People seem to have trouble actually being productive with Git far more than any other VCS. If every commit potentially resulted in having to spend 30 minutes figuring out what command line arcana to invoke so that I could get back to work, I'd commit infrequently too. I think git is another case of "this is really easy until you think about it for a bit and you realise it's archaic and kinda dumb". A lot of things you know feel easy to you but are actually kinda terrible, and git's probably one of them. It's so obtuse in all the commands it has in my opinion, and while I still absolutely adore git from what I've seen of it, it's still really daunting to try and learn. Same as Vim/Emacs in a way.
|
|
#
?
Dec 30, 2013 18:34
|
|
|
I actually find that I'm a lot more productive with git than any other VCS, but I will admit that its UI is inconsistent and garbage. It tries to follow the UNIX philosophy of "do one thing and do it well", but instead becomes "do one absolutely useless thing in a different way from everything else". git branch -d foo vs. git remote rm foo is one example. I've often wondered if I could use libgit2 to create an alternate command line UI that doesn't suck.
|
|
#
?
Dec 30, 2013 19:14
|
|
|
No, because it also follows the UNIX philosophy of being a bunch of executables and shell scripts bound together with baling wire and chewing gum instead of being a C-callable shared library, the one true code reuse methodology.
|
|
#
?
Dec 30, 2013 19:23
|
|
|
I'm kinda sad that git seems to have triumphed over mercurial, because I've found hg to be much easier to learn.
|
|
#
?
Dec 30, 2013 19:26
|
|
|
pseudorandom name posted:No, because it also follows the UNIX philosophy of being a bunch of executables and shell scripts bound together with baling wire and chewing gum instead of being a C-callable shared library, the one true code reuse methodology. libgit2?
|
|
#
?
Dec 30, 2013 19:37
|
|
|
git doesn't use libgit2.
|
|
#
?
Dec 30, 2013 19:44
|
|
|
After a few months of very light git usage, I still have a lot of problems doing anything beyond simple committing, pulling, and merging, which I guess is 99% of what you should need to do anyway. But recently I found this cheat sheet: This is some help, but many of these commands I fear may be doing things other than what the cheat sheet suggests. For example, git reset --hard is under "resolve merge conflicts -- discard conflicting patch" and "return to the last committed state", but if you were naively trying to undo a merge and used this command with uncommitted changes then you'd also be losing those changes. But on the whole, this is a nice little guide to some basic git commands When when would you need git commit -a --amend? What does this do? This also doesn't tell you how to create a standalone git repository, which is really useful if you need to merge changes from one network to another and the networks aren't allowed to ever touch except via physical media. e: I guess that my problem with git is that all of the power is hidden behind an extremely obfuscated interface, which makes it hard to learn these commands without a very in-depth guide QuarkJets fucked around with this message at 19:47 on Dec 30, 2013 |
|
#
?
Dec 30, 2013 19:45
|
|
|
pseudorandom name posted:git doesn't use libgit2. Yes, I know. git itself uses a wacko katamari of shell scripts and Elmer's glue but libgit2 is a full shared library. So I was wondering what else "also follows the UNIX philosophy of being a bunch of executables and shell scripts bound together with baling wire and chewing gum"...
|
|
#
?
Dec 30, 2013 19:47
|
|
|
QuarkJets posted:When when would you need git commit -a --amend? What does this do? If I make a dumb mistake in my last commit (let's say I forget a semicolon, breaking the build), instead of having to make another commit saying "fix build", I can simply amend the change to the last commit. QuarkJets posted:This also doesn't tell you how to create a standalone git repository, which is really useful if you need to merge changes from one network to another and the networks aren't allowed to ever touch except via physical media. You mean the part where it says git init?
|
|
#
?
Dec 30, 2013 19:48
|
|
|
Well, if you're happy using a third-party reimplementation instead of the authoritative wacko katamari, more power to you.
|
|
#
?
Dec 30, 2013 19:50
|
|
|
Ithaqua posted:People seem to have trouble actually being productive with Git far more than any other VCS. If every commit potentially resulted in having to spend 30 minutes figuring out what command line arcana to invoke so that I could get back to work, I'd commit infrequently too. This is almost right. A lot of that seems to go away if you spend the time to really _get_ git. Then you just use it and don't think about it and man, I'm super productive because trying out different stuff and whatever is less of a big deal. But yeah, it's stupid that it's so difficult to do that.
|
|
#
?
Dec 30, 2013 20:02
|
|
|
QuarkJets posted:This is some help, but many of these commands I fear may be doing things other than what the cheat sheet suggests. For example, git reset --hard is under "resolve merge conflicts -- discard conflicting patch" and "return to the last committed state", but if you were naively trying to undo a merge and used this command with uncommitted changes then you'd also be losing those changes.
|
|
#
?
Dec 30, 2013 20:17
|
|
|
Plorkyeran posted:A cheat sheet which tried to mention every insane thing you could potentially do would be a very cluttered cheat sheet (if you have uncommitted changes unrelated to resolving a merge conflict while resolving a merge conflict you are almost certainly doing something insane). I'm in the middle of a git conversion myself (won't go into full swing at this company until mid-January). I found that the best thing to do is to write your own cheatsheet that covers the workflow that your team is already using, just with git, or a workflow that encourages what you'd like to see. It's easier to keep people in their comfort zone as much as possible.
|
|
#
?
Dec 30, 2013 20:39
|
|
|
Marsol0 posted:I found that the best thing to do is to write your own cheatsheet that covers the workflow that your team is already using, just with git, or a workflow that encourages what you'd like to see. It's easier to keep people in their comfort zone as much as possible. Git makes sense as an API, and less so when used as a command line util. What Marsol0 mentions here touches on what needs to happen before git ever becomes useful. Pick a tool that suits your team (SourceTree, TortoiseGit, etc.), inform everyone about the merge workflow and best practices for avoiding mind-bending merge conflicts (cherry picking commits, branch creation, stashing work, etc.), and have at it. Initially, I did more harm than good with the command line simply by trying to learn while working, and found that SourceTree provides functionality for 80% of what I need to do in git without needing to completely understand every command and associated params used on the back end.
|
|
#
?
Dec 30, 2013 21:08
|
|
|
Suspicious Dish posted:Yes, I know. git itself uses a wacko katamari of shell scripts and Elmer's glue but libgit2 is a full shared library. So I was wondering what else "also follows the UNIX philosophy of being a bunch of executables and shell scripts bound together with baling wire and chewing gum"... It's getting less so, new features tend to be written in c, and some components get reimplemented in c for speed, but libgit.a is still a tangled mess of global state, never freeing resources and calling exit instead of returning an error code. I would still prefer to shell out to git to handle changing refs or pushing though, as libgit2's api only appeared to support a subset of the operations on refs that the command line did. Since we're talking about how we learned git, I started out using it like SVN, and incrementally learned new features as I went. It got a bit weird after that though, as I started working on a product that used git internally, so developing the product WAS learning the tools.
|
|
#
?
Dec 30, 2013 21:42
|
|
|
|
| # ? May 14, 2024 02:02 |
|
|
jpotts posted:Git makes sense as an API, and less so when used as a command line util. I'm not sure if needing to have that level of knowledge is necessarily a bad thing, but just handwaving the complexity away by saying "people just need to spend some time getting to know it" isn't advice, it's a gently caress you. Most developers are terrible (case in point: this thread) and those kinds of developers will NEVER be able to use git properly. (btw, SVN is still worse, doing any kind of merging while trying to stay sane just sucks)
|
|
#
?
Dec 30, 2013 23:08
|
|