|
Okay, that all makes sense. Thanks. Another question: I wanted to see what would happen if I did this in Git Bash, so I tried it out code:So I opened Git Bash up and didn't do anything except commit the repo, and then everything worked in Git GUI as you would expect. Does that mean anything I add to the stage will remain there, even after I close Git Bash, and be able to safely be commited at some other time? Or could that gently caress something up?
|
#
?
May 8, 2012 22:21
|
|
|
|
| # ? May 13, 2024 05:39 |
|
|
The stage is on disk in that magic .git folder. You can reboot your computer and it will still be there.
|
|
#
?
May 8, 2012 23:38
|
|
|
Optimus Prime Ribs posted:Does that mean anything I add to the stage will remain there, even after I close Git Bash, and be able to safely be commited at some other time? Or could that gently caress something up? git-bash isn't really a git "session", it's just a command line interface pre-configured to be easy to use git from. Git doesn't know (or care) whether you're using one git-bash window, multiple windows, git-gui, etc - as far as git is concerned there's no difference between you doing "git add; git commit" in one window, or going "git add" in one, closing that window, shutting down the computer, installing a new video card, making tea, switching ISPs, and then powering it back up and using the GUI to commit. This applies not just to add and commit but to any sequence of git commands. There's no background process keeping track of the repo or anything, so everything it needs to remember from one command to the next is stored to disk in the .git directory.
|
|
#
?
May 9, 2012 14:03
|
|
|
ToxicFrog posted:or going "git add" in one, closing that window, shutting down the computer, installing a new video card, making tea, switching ISPs, and then powering it back up and using the GUI to commit.
|
|
#
?
May 9, 2012 14:25
|
|
|
Hey, I'm loving baffled about how to squash commits in Git for a pull request. Basically, my history is something like: Forked project Made changes, committed Pulled upstream, merged into my fork Made changes, committed Want to do pull request How the gently caress do I squash my changes into a single commit and avoid the "merged" one? I did my pull request without squashing and it came out as code:
|
|
#
?
May 9, 2012 20:58
|
|
|
If you have the original branch at origin/master, and your branch in master, then:code:
|
|
#
?
May 9, 2012 21:11
|
|
|
GitHub for Windows was just released. Imagine the Zune UI for you GitHub account. I'm just installing it at work (we use TFS) to see what it looks like. I hope this ends the whole "git isn't for Windows" argument.
|
|
#
?
May 21, 2012 18:40
|
|
|
gariig posted:GitHub for Windows was just released. Imagine the Zune UI for you GitHub account. I'm just installing it at work (we use TFS) to see what it looks like. I hope this ends the whole "git isn't for Windows" argument.
|
|
#
?
May 21, 2012 19:45
|
|
|
Physical posted:I didn't think there was a debate. I use git extensions (it gives context menus AND integrates into Visual Studio), and older git gui (MYSgit I think) and also the Team plugin for eclipse. Start here for the epic thread derail of 2011.
|
|
#
?
May 21, 2012 19:57
|
|
|
Modern Pragmatist posted:Start here for the epic thread derail of 2011. I wish I could read his article to see what he was unhappy about. Maybe the installer was crappier back then, but its only been a year. It was as hard as "do you want us to do it this way, or that way?" "How about this next thing, how would you like us to handle this?" It was a very polite and thoughtful installer. The git bash does act a little screw for me though. So I just use the windows commands instead. I guess it might be because I don't have cywin installed or something. Physical fucked around with this message at 20:16 on May 21, 2012 |
|
#
?
May 21, 2012 20:13
|
|
|
I don't remember the article very well, but I do remember thinking it was pretty unreasonable. And that's coming from someone who had a decidedly poor Windows Git experience.
|
|
#
?
May 21, 2012 20:42
|
|
|
The article was basically "the installer asked me questions I didn't know the answer to and I refused to just accept the defaults."
|
|
#
?
May 21, 2012 20:50
|
|
|
Physical posted:I didn't think there was a debate. I use git extensions (it gives context menus AND integrates into Visual Studio), and older git gui (MYSgit I think) and also the Team plugin for eclipse. You're right, there was no debate because it was pretty clear that Git on Windows was a pretty crappy experience. (And I personally think Hg is better anyway, so whatever.)
|
|
#
?
May 21, 2012 21:40
|
|
|
Meanwhile, my advisor and I still can't figure out why the git context menu extensions aren't showing up on his machine. Git on windows is honestly not a fun experience if you aren't comfortable with the command line, even if the context menu entries are working, but I'm not sure how much of that is git and how much is my bias against version control GUIs in general.
|
|
#
?
May 21, 2012 22:14
|
|
|
ToxicFrog posted:Meanwhile, my advisor and I still can't figure out why the git context menu extensions aren't showing up on his machine. I'm not one to pick on people for being ignorant...everyone is ignorant about something. But why the hell would a programmer not be familiar with the command line? I mean...if you can grasp the concepts behind programming computers and using version control, not being familiar with the command line (or at least taking a few minutes to learn what you need) just seems bizarre.
|
|
#
?
May 22, 2012 01:02
|
|
|
Thermopyle posted:But why the hell would a programmer not be familiar with the command line? I mean...if you can grasp the concepts behind programming computers and using version control, not being familiar with the command line (or at least taking a few minutes to learn what you need) just seems bizarre. Because they've only ever programmed in an IDE? Lots of lovely programmers exist, could it be that you're ignorant of their existance  But seriously, version control can be useful to people in other fields and they might feel intimidated by the command line and not use it. Programmers have no excuse though, gently caress them for being ignorant of the command line.
|
|
#
?
May 22, 2012 15:30
|
|
|
MEAT TREAT posted:Because they've only ever programmed in an IDE? Lots of lovely programmers exist, could it be that you're ignorant of their existance Yeah, I get that lovely programmers exist, I was ineptly trying to make the observation that if you're a programmer who is not familiar with the command line, that's pretty strong evidence that you are a lovely programmer. It's not proof, of course, you may not ever have needed to use the command line, but given that curiosity is probably a component of being a good programmer, not being familiar with the command line should be a minor obstacle to you anyway. I didn't think about non-programmers using version control, though. (That's a lot of commas.)
|
|
#
?
May 22, 2012 17:24
|
|
|
Maybe I'm just one of those ignorant developers (or just missing something), but I would strongly consider using version control from the command line very much "not a fun experience".
|
|
#
?
May 22, 2012 18:08
|
|
|
Zhentar posted:Maybe I'm just one of those ignorant developers (or just missing something), but I would strongly consider using version control from the command line very much "not a fun experience". Yeah, that's different from not being familiar with the command line and is a pretty defensible position.
|
|
#
?
May 22, 2012 18:34
|
|
|
I actually have had a much better time using git and github from the command line in OS X than with github's Mac client, but I think that's mostly because the documentation for command line git is much much much much more substantial around the internet. It's a system that, I think, works very well on the command line since that's what it was built for.
|
|
#
?
May 22, 2012 19:07
|
|
|
gariig posted:GitHub for Windows was just released. Imagine the Zune UI for you GitHub account. I'm just installing it at work (we use TFS) to see what it looks like. I hope this ends the whole "git isn't for Windows" argument. Trip report: it modified a bunch of files in some existing repos (540 different files in one of them!) it found that I had sitting around just to build stuff and then refused to let me do anything with them until I checked in my 'changes'. I just deleted them because I don't feel like cleaning up the mess. Hey, it sure does look pretty.
|
|
#
?
May 23, 2012 18:38
|
|
|
Munkeymon posted:Trip report: it modified a bunch of files in some existing repos (540 different files in one of them!) it found that I had sitting around just to build stuff GitHub for Windows does not have a build system. What kinds of changes did it make?
|
|
#
?
May 23, 2012 19:36
|
|
|
Suspicious Dish posted:GitHub for Windows does not have a build system. What kinds of changes did it make? Not sure - all the diffs had the same content in both old and new sections, but all of the files in question had their modification times changed. Git tracks permissions, right? Maybe the GH client has different ideas about what the Windows permissions mean than does the CygWin git system, which I normally use (and by 'normally' I mean I pull down code to use libraries - I'm not a regular git user).
|
|
#
?
May 23, 2012 19:47
|
|
|
Munkeymon posted:Not sure - all the diffs had the same content in both old and new sections, but all of the files in question had their modification times changed. Could this possibly due to the handling of line endings or something of the sort?
|
|
#
?
May 23, 2012 20:02
|
|
|
Munkeymon posted:]Git tracks permissions, right? Maybe the GH client has different ideas about what the Windows permissions mean than does the CygWin git system, which I normally use (and by 'normally' I mean I pull down code to use libraries - I'm not a regular git user). I've dealt with then when switching between msysgit and cygwin on the same repo. I think it has to do with the core.filemode setting. See https://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/d0474d7afdcd36cc?pli=1 for a decent explanation.
|
|
#
?
May 23, 2012 20:19
|
|
|
I just finished uninstalling GitHub for Windows - I noticed that whenever I ran the GitHub client, it installed a Git Shell shortcut onto my desktop without asking. I don't actually use Git or GitHub, but I thought I'd at least check out the program. Right now it seems awfully invasive, which is irritating.
|
|
#
?
May 23, 2012 20:28
|
|
|
Munkeymon posted:Trip report: it modified a bunch of files in some existing repos (540 different files in one of them!) it found that I had sitting around just to build stuff and then refused to let me do anything with them until I checked in my 'changes'. I just deleted them because I don't feel like cleaning up the mess. Hey, it sure does look pretty. This is actually really similar behavior to what I've seen in the Mac client too. I think it had something to do with submodules or repos inside repos (so it was finding other .git folders and choking somehow), but I never really bothered to figure it out and just went back to the command line.
|
|
#
?
May 24, 2012 19:59
|
|
|
Dromio posted:I've dealt with then when switching between msysgit and cygwin on the same repo. I think it has to do with the core.filemode setting. See https://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/d0474d7afdcd36cc?pli=1 for a decent explanation. No dice - it still fucks with files with core.filemode false This is fairly ironic since I have no earthly clue how to pull a repo from inside their interface, if there is even a way. I guess I could try some other git client and see if I see the same problem, but I'm not really motivated enough right now. edit:  I see - there's a button on GitHub to do it for me so I don't get the crazy idea that I might use this thing as a general git GUI client.edit 2: Ha ha it still fucks up when I use their own client to do the clone. Only 36 uncommitted 'changes' instead of the 300+ I was seeing, but I'm still not gonna consider this for an actual project at this rate. Munkeymon fucked around with this message at 13:53 on May 29, 2012 |
|
#
?
May 25, 2012 22:49
|
|
|
hg question. I currently use hg to keep track of code as it moves from development to test to production. I have three repositories, and three branches. When a change is ready for testing it gets pulled to the test repository and merged in. Once the change is approved, it gets pulled from test to prod and merged. The graph looks something like this: code:code:
|
|
#
?
May 31, 2012 22:13
|
|
|
So at the company I work for (large US health insurance company) our IT organization uses ClearCase. I work on the business side of the company however they use it to store all our requirements documentation and project deliverable's not just for code version control. Does anyone have any experience with ClearCase? When attempting to use it to review documents and other things I just find it extremely difficult to work with. Most of the time I can just have one of the project managers just pull everything I need into an email but wanted to see if it was just me.
|
|
#
?
May 31, 2012 23:16
|
|
|
clearcase is terrible and jumping through dumb hoops to avoid having to touch it is usually worth it
|
|
#
?
Jun 1, 2012 05:40
|
|
|
Jethro posted:Assuming the changes are independent, is there a good way (or a better process) to merge the later changes from QA into Prod in such a way that later I can merge in the earlier changes? I have been using transplant to pull in newer changes while an old change is still being tested. If you do this, you will end up with a complex mess if people don't correctly label their commits, or if they don't commit them to their original branch and then remerge their branch back into your test environment. This works for my team because we have many small minor releases (transplant them to our Prod branch, push that) and then we have a bi-weekly high-impact release that pushes everything on Test out, giving time to the QA team for a semi-stable test environment. If you (or anyone else) has better options, please let me know because sometimes it gets bad (ie: a high-impact release is delayed a few weeks, now have ~50 transplanted changes between Test -> Prod branches). We do our work similar to git flow and generally do most work in branches, which allows us to do internal code reviews and automated testing before it hits our Release branch that QA will then go over.
|
|
#
?
Jun 3, 2012 23:05
|
|
|
Can anyone suggest a clean way to check Eclipse projects into version control? In particular, how should I handle the .classpath file? There are several .jar files from third-party libraries, and Eclipse likes to put the absolute path to those files in .classpath, but those paths will be different when the project is checked out into a different folder. So if .classpath is in version control, it will almost certainly have incorrect paths when checked out; and will also constantly be seen as different and get checked in whenever someone uses "git commit -a" or whatever. I found a few suggestions via Google, such as "convert it to a Maven project", which didn't seem to help (unless I did it wrong somehow), or "don't check .classpath into version control", which is fine except for all the manual steps that will now be required when checking out the project or when someone adds a new third-party library dependency. Ideally I'd like something that "just works" when you check it out, like we can do with our Visual Studio projects.
|
|
#
?
Jun 14, 2012 16:36
|
|
|
Olly the Otter posted:I found a few suggestions via Google, such as "convert it to a Maven project", which didn't seem to help (unless I did it wrong somehow), or "don't check .classpath into version control", which is fine except for all the manual steps that will now be required when checking out the project or when someone adds a new third-party library dependency. Ideally this is what you probably need to do. On every project I've worked on, the goal is to keep any editor-specific files out of version control. This is important for the reasons you said (differing paths for different machines) and to allow people to use various editors. Each person can maintain their own editor-specific files. Maybe just have information to help setting them up for your project?
|
|
#
?
Jun 14, 2012 18:13
|
|
|
Olly the Otter posted:Can anyone suggest a clean way to check Eclipse projects into version control? In particular, how should I handle the .classpath file? There are several .jar files from third-party libraries, and Eclipse likes to put the absolute path to those files in .classpath, but those paths will be different when the project is checked out into a different folder. So if .classpath is in version control, it will almost certainly have incorrect paths when checked out; and will also constantly be seen as different and get checked in whenever someone uses "git commit -a" or whatever.  If not Maven, then are you at least using Ant or some other build tool? You shouldn't really be building poo poo from the "Compile..." option in Eclipse. For the very problem you're describing, among others.
|
|
#
?
Jun 14, 2012 18:29
|
|
|
Modern Pragmatist posted:Ideally this is what you probably need to do. On every project I've worked on, the goal is to keep any editor-specific files out of version control. This is important for the reasons you said (differing paths for different machines) and to allow people to use various editors. Each person can maintain their own editor-specific files. Maybe just have information to help setting them up for your project? Right, but now every time a new library is added, everyone has to manually update their class paths. And what about when I want to check out a different branch or an old version -- what's the correct list of libraries to include in my class path to go with that? The reason I don't want to leave .classpath out of version control is really very simple: because then it's not version-controlled. I was just hoping there was some way I could make it work like Visual Studio projects, where I can check the .vcxproj file into version control. This file is very stable, and lets you specify relative paths to any .lib files that are required. pigdog posted:Don't check it in version control. If you are using Maven and are still worried about external third party dependencies not making it into the project and its classpath, then yes, you are doing something quite wrong. I suppose I just don't really understand Maven. I tried converting an existing project to Maven (using Configure > Convert to Maven Project in Eclipse), but that doesn't seem to have made a difference -- external .jar file locations are still stored in .classpath. I'm still pretty new to Java and Eclipse, but I like that Eclipse builds stuff for me automatically while I type. I certainly don't want to sacrifice that and have to constantly tab over to a shell to run Ant or whatever. I understand that in some sense Eclipse has built-in support for Ant and Maven, but I can't quite figure out what exactly that means or how to properly make use of it.
|
|
#
?
Jun 14, 2012 20:28
|
|
|
quote:I suppose I just don't really understand Maven. I tried converting an existing project to Maven (using Configure > Convert to Maven Project in Eclipse), but that doesn't seem to have made a difference -- external .jar file locations are still stored in .classpath. Of course you will be able to compile stuff on the fly while you type. However, really building any non-trivial Java application involves more than just compiling .java files to .class files. It can be copying various resources, generating code or documentation, packaging the application into a .jar/.war, running optinal integration tests, deploying it on an appserver, and can also include finding, downloading and using external libraries in case with say Maven. You really, really wouldn't want to do this all by hand. All the IDEs these days are also really well integrated with Ant and Maven, and running a build and doing everything needed to produce the final product won't take more than a single click (or a keypress). Which is indeed the point.
|
|
#
?
Jun 14, 2012 20:45
|
|
|
What is a good free git host that offers private repositories? I just need one repo for one user (me) to host my thesis. I don't want to pay for private repos on github and I don't want to do it myself with my EC2 server because I'd rather just have someone else do the backing up and other admin stuff.
|
|
#
?
Jun 28, 2012 13:31
|
|
|
Boris Galerkin posted:What is a good free git host that offers private repositories? I just need one repo for one user (me) to host my thesis. I don't want to pay for private repos on github and I don't want to do it myself with my EC2 server because I'd rather just have someone else do the backing up and other admin stuff. http://bitbucket.org does free private repos and hosts git too.
|
|
#
?
Jun 28, 2012 13:34
|
|
|
|
| # ? May 13, 2024 05:39 |
|
|
If you just want backups, can't you use dropbox?
|
|
#
?
Jun 28, 2012 15:57
|
|
