|
Rocko Bonaparte posted:I had actually tried this so maybe I have something else to ask about here. I'm working on Windows here, using Git Extensions. The closest I found to being able to mount sshfs is DokanSSHFS. For simple copy kind of operations it was working fine. However, I couldn't even init a repository with it. Something in the Git Bash with Git Extensions was also getting in the way; it was flipping around path separators and then not finding the path. I have no idea what the deal was there. I imagine you were thinking about mounting sshfs on Linux, but I'm wondering instead if there's a well-vetted method for doing the same on windows. To be honest, I have no idea. I was rather thinking about doing it on linux; I do none of my development on windows and don't really know if there's a good sshfs implementation for it. There wasn't last time I checked, but that was years ago. If you're using windows you'll probably have a much easier time either backing it up using dumb storage, or installing git on something you can ssh into and pushing to that.
|
#
?
Apr 3, 2012 19:34
|
|
|
|
| # ? May 12, 2024 20:10 |
|
|
Is there some way to maintain metadata about a branch in git? I'd like to be able to keep track of which branches are currently in testing, waiting for more feedback, in testing but also getting new features, when it was last updated, etc. all in one place without having to resort to maintaining an external spreadsheet. Or, is there a way to simply get a list of the git branches, and have it display when they were last merged into test or what not? Right now to do this I think I'd have to go through each branch individually and check its status.
|
|
#
?
Apr 5, 2012 14:52
|
|
|
uXs posted:Seems ok to me. Pull. Do work, commit. Repeat that step until you feel like pushing. Then pull & merge anything that changed while you were working, and push. It sound simple in theory until I have made about sixteen commits, pull and everything breaks so I have to create a new clean branch and cherry-pick every single commit. Deus Rex posted:is there any reason you're not putting those config files in .gitignore, or the repo exclude? it seems that would streamline your workflow quite a bit This sounds like what I want, but do I have to do this for every new branch I create? Because whenever I want to start working on a new feature I have to clone the master into a new branch nexus6 fucked around with this message at 15:28 on Apr 5, 2012 |
|
#
?
Apr 5, 2012 15:21
|
|
|
nexus6 posted:It sound simple in theory until I have made about sixteen commits, pull and everything breaks so I have to create a new clean branch and cherry-pick every single commit. Merge early, merge often.
|
|
#
?
Apr 5, 2012 15:43
|
|
|
uXs posted:Merge early, merge often. I learned that, but it just seems wrong to me that I have to start every day downloading the updates or I risk loving everything up.
|
|
#
?
Apr 5, 2012 15:54
|
|
|
uXs posted:Merge early, merge often. I guess my main workflow issue is this: We've been using CVS through Eclipse (since we mainly do Java development), and Eclipse's built-in CVS support is really nice. It doesn't matter how much work my teammate does since my last checkout, if he's checked in a bunch of changes and I have a bunch of pending changes as well, it's super easy for me to synchronize with the repo, view all the changes, commit my non-conflicting ones, check out his non-conflicting ones, and then interactively merge where conflicts exist and then commit those back. We've tried using our old workflow with git/eGit (remote on Github), and while eGit is nice it definitely doesn't feel as mature as the CVS support. It's been a clusterfuck a couple times when we both had changes to the same resources, which made me think that git's distributed model might encourage a different/better workflow for this.
|
|
#
?
Apr 5, 2012 16:04
|
|
|
Flobbster posted:I guess my main workflow issue is this: We've been using CVS through Eclipse (since we mainly do Java development), and Eclipse's built-in CVS support is really nice. It doesn't matter how much work my teammate does since my last checkout, if he's checked in a bunch of changes and I have a bunch of pending changes as well, it's super easy for me to synchronize with the repo, view all the changes, commit my non-conflicting ones, check out his non-conflicting ones, and then interactively merge where conflicts exist and then commit those back. I read this until I get to "I merge my UNCOMMITTED changes with ..." which makes me cry. Flobbster posted:We've tried using our old workflow with git/eGit (remote on Github), and while eGit is nice it definitely doesn't feel as mature as the CVS support. It's been a clusterfuck a couple times when we both had changes to the same resources, which made me think that git's distributed model might encourage a different/better workflow for this. Workflow for a DCVS system is: -I do something. -Some other guy does something. -Other guy commits, pulls (but there's nothing to pull), and pushes. -I commit. -I pull the other guy's changes. -I merge. If my merge fails because of whatever, I can just throw everything away and retry the merge. Nothing is ever lost because I have already committed. This step can be retried as much as you like. If there's a lot of commits you have to merge with, you could also merge in steps. But I've never needed to. -I commit the merge, pull again (because the merge has taken some time), and push. If a merge is trivial, the DCVS tool should do almost everything automatically. If the merge isn't trivial, you need some brains and a good merge tool. What merge tool you use doesn't really depend on the source control system you use. The biggest advantage to a DCVS, to me, is that you commit first, and only then merge. A merge can be retried as much as you like, because everybody's changes have already been committed and are safe. There is no such thing as 'pending changes'.
|
|
#
?
Apr 5, 2012 17:10
|
|
|
Flobbster posted:Can anyone recommend a good resource that just lays it out in simple terms, "here's the best way to set up your workflow for a small number of users working concurrently"? I don't need any of that dictator-model stuff -- both of us know what we're doing on the project and don't need to complicate things by adding access tiers. What uXs said (although I prefer explicit git-fetch/merge to git-pull, since I deal with lots and lots of branches). You might also find gitworkflows(7) helpful.
|
|
#
?
Apr 8, 2012 15:27
|
|
|
Am I the only one who gets to coding and does lots of bug fixes and whatnot and then realizes the last 10 git commits were done to the wrong branch? What's your preferred way of handling this?
|
|
#
?
Apr 9, 2012 02:54
|
|
|
Takes about 30 seconds to cherry-pick them over to the right branch if there's no conflicts. Alternatively, make a temp branch and interactively rebase it onto the correct branch, discarding all of the commits from the bad branch, then reset the correct branch to the temp branch.
|
|
#
?
Apr 9, 2012 04:06
|
|
|
Thermopyle posted:Am I the only one who gets to coding and does lots of bug fixes and whatnot and then realizes the last 10 git commits were done to the wrong branch? http://asemanfar.com/Current-Git-Branch-in-Bash-Prompt As for my own question: has anyone here tried git notes? I can't think of a good use for them.
|
|
#
?
Apr 9, 2012 09:47
|
|
only
|
I added all my local config files to .gitignore but in the diff log generated by our server it appears that those files have been committed anyway. What gives? Or am I misunderstanding something?
|
|
#
?
Apr 10, 2012 11:05
|
|
|
nexus6 posted:I added all my local config files to .gitignore but in the diff log generated by our server it appears that those files have been committed anyway. What gives? Or am I misunderstanding something? Had they already been added and committed before you added the .gitignore file?
|
|
#
?
Apr 10, 2012 14:04
|
|
|
musclecoder posted:Had they already been added and committed before you added the .gitignore file? No, I've since been advised to move my .gitignore file to the root dir instead and that seems to have done the trick.
|
|
#
?
Apr 10, 2012 14:15
|
|
|
Yeah, that's how they work. You can even put multiple .gitignore files in nested directories if there's certain kinds of files you only want to ignore in certain folders, like generated fixtures or whatever.
|
|
#
?
Apr 11, 2012 03:21
|
|
|
I'm wondering something, out of interest - I've got the following structure in subversion:code:
|
|
#
?
Apr 12, 2012 16:18
|
|
|
Rohaq posted:I'm wondering something, out of interest - I've got the following structure in subversion: add a check to precommit hooks, hopefully there's some simple way you can distinguish between just another directory being added and a whole copy of the tree being added.
|
|
#
?
Apr 14, 2012 05:59
|
|
|
I have the following git history in a repository.code:EDIT: git rebase -p causes git to attempt to recreate merges, but when squashing everything it still asks me to re-resolve the conflicts. EDIT2: More messing around with git rebase -p, especially git rebase -i -p HEAD~2 and squashing from there, seemed to have done the trick. Catalyst-proof fucked around with this message at 04:44 on Apr 16, 2012 |
|
#
?
Apr 16, 2012 04:26
|
|
|
How do you force Git to ignore CHANGES to a file but keep the initial version? I know about git update-index --assume-unchanged, but that doesn't propogate the changes to the master repo, just local, and if I add the file to .gitignore it deletes it. I need to keep a bunch of config files but ignore all changes. Can't find this in the Git book anywhere.
|
|
#
?
Apr 20, 2012 13:41
|
|
|
You append .template or .original or somesuch to the file name and rename or copy the file during deployment.
|
|
#
?
Apr 20, 2012 14:23
|
|
|
revmoo posted:How do you force Git to ignore CHANGES to a file but keep the initial version? I know about git update-index --assume-unchanged, but that doesn't propogate the changes to the master repo, just local, and if I add the file to .gitignore it deletes it. I need to keep a bunch of config files but ignore all changes. Can't find this in the Git book anywhere. Someone posted an answer to this using Git a few pages back, but I agree with pseudorandom name. I have configure.template and configure in my codebase. configure.template is version controlled, and has placeholder values for database configs, 3rd party API keys, or any other data that shouldn't be versioned. My build process for my local development box would add development configuration data, and likewise when a build is pushed to production, the production parameters are added.
|
|
#
?
Apr 20, 2012 14:31
|
|
|
I'd rather just keep the file as-is. I know it can be done because I've worked on systems that were already configured to do this.
|
|
#
?
Apr 20, 2012 14:41
|
|
|
uXs posted:
I don't want to be fussy here or anything but this behavior is not a feature of a dvcs. you can do the same thing in svn (or cvs iirc)
|
|
#
?
Apr 21, 2012 09:34
|
|
|
I think uXs is talking about local changes that are only in your working copy/repository -- running svn update or cvs update does a small merge at that time. If there's no textual conflict between what changed in the repository and your local modifications, I believe SVN will gracefully merge them. Otherwise, you get a conflict marker in your file. Even if you're working on a branch, your local uncommitted changes are in danger whenever you update. Git, on the other hand, will abort a merge if any of the affected files have local modifications. The intent is that your local modifications should be commits instead of modified files; this helps in merging the history, and most importantly you don't have any risk of losing your work.
|
|
#
?
Apr 21, 2012 14:31
|
|
|
This may be a stupid question, so apologies if I'm missing a basic facet of version control. I'm kind of learning as I go and I didn't see anything right off hand while Googling this. Submodules are confusing. Anyways, I have a git repo (https://github.com/seubert/dotfiles) with a bunch of submodules for my vim plugins and a couple other things. If I edit one of these submodules how do I track/commit/push these changes? Should I not be using submodules at all in this case? To be more specific, I added a new theme in oh-my-zsh and I want to be able to push that but it doesn't track it since my changes are in a submodule. edit: I see this: http://stackoverflow.com/questions/5542910/how-do-i-commit-changes-in-a-git-submodule but I'm still not totally sure what to do. etcetera08 fucked around with this message at 19:36 on Apr 21, 2012 |
|
#
?
Apr 21, 2012 19:33
|
|
|
Git submodules are just you telling git that you're going to have a repository in your repository. Git will track the state of the submodule by the commit hash of some commit in the submodule. When you update the submodule (and presumably put these changes somewhere), in the parent repository you git add and git commit the submodule as if it were a file. The resulting diff will show you the old and new commit hash. In your specific case, I would expect you would need to fork oh-my-zsh, use the fork url for your submodule url, and manage changes to the submodule as you would any other project, except you would update your dotfiles repo when you wanted to point to a new commit in the submodule.
|
|
#
?
Apr 21, 2012 20:38
|
|
|
sklnd posted:Git submodules are just you telling git that you're going to have a repository in your repository. Git will track the state of the submodule by the commit hash of some commit in the submodule. When you update the submodule (and presumably put these changes somewhere), in the parent repository you git add and git commit the submodule as if it were a file. The resulting diff will show you the old and new commit hash. Makes perfect sense, thanks!
|
|
#
?
Apr 21, 2012 20:46
|
|
|
Is there a way to tag multiple git branches with the same identifier? I'm working on a game, and I'm trying to keep all of my commits small, but that sometimes means that various branches will crash on launch, or what-have-you, and I'd like to mark them all with some 'broken' token in source control.
|
|
#
?
Apr 26, 2012 19:01
|
|
|
You can use git notes to add notes to commits. git log, git show, etc. will show them as if they were a part of the commit message.
|
|
#
?
Apr 26, 2012 19:27
|
|
|
Fren posted:Is there a way to tag multiple git branches with the same identifier? I'm working on a game, and I'm trying to keep all of my commits small, but that sometimes means that various branches will crash on launch, or what-have-you, and I'd like to mark them all with some 'broken' token in source control. You can prefix them. broken/resource-caching, wip/gles-only, etc.
|
|
#
?
Apr 27, 2012 01:08
|
|
|
One of my projects has a module that's rapidly outgrowing the project it's a part of. I'd like to pull it out into its own separate repository, but I'd like to pull its commit history with it. Specifically, I've got a repository like this: code:I'd like to build a new repository and populate it with all of the commits from this repository that touch any files in the module3 subtree. It's okay if this pulls a few extra files along with it since I can clean those out of the new repository by hand, but how do I extract the directory with its commit history?
|
|
#
?
Apr 28, 2012 10:49
|
|
|
Nippashish posted:One of my projects has a module that's rapidly outgrowing the project it's a part of. I'd like to pull it out into its own separate repository, but I'd like to pull its commit history with it. I have not used it myself, but I'm pretty sure that git filter-branch --subdirectory-filter module3 is what you're after, possibly with --prune-empty as well (although I think --subdirectory-filter makes that unnecessary in this case). Do that on a clone of the original repo, then delete the original branches from it and the origin remote and you have a new repo containing all of the history, and only the history, of module3, with the contents of module3 as the repo root.
|
|
#
?
Apr 28, 2012 18:11
|
|
|
An odd problem I've encountered, that _might_ be to do with Mercurial. Or not. Bear with me: We use this large and popular genomics webapp Galaxy to wrap and link some complex tools. A recent innovation in Galaxy is the concept of a "toolshed", a separate webapp that people can upload their own tools to and other can download and install into their own application instances. And these toolsheds store the uploaded tools as Mercurial changesets. Anyway, our own toolshed is consistently generating errors when it's used, that looks like a unicode error involved with the Mercurial repo, where a unicode filename fails to be forced into an ascii one. I've been back and forth with the Galaxy developers and basically I'm the only one ever, anywhere, who has ever seen this error. So, after that long build up: what sort of things might cause encoding errors with Mercurial? Is there any obvious configuration or settings that I might look at?
|
|
#
?
May 2, 2012 15:46
|
|
|
Hey all, I had a question concerning version control best practices. I've written a decent sized application, and use subversion as version control. I have begun the process of placing the front end and the back end into their own separate assemblies. Does it make sense to maintain separate repositories for both? My reasoning is this would allow me to revert back to earlier revisions in the back end, for example, without losing changes to the front end. Is this the way to go, or is there a better way?
|
|
#
?
May 3, 2012 15:43
|
|
|
You don't have to revert the entire repository. You can perform operations on items within it separately.
|
|
#
?
May 3, 2012 19:03
|
|
|
Github talk: We have a repo that houses our production source. We want to be able to have a dev branch, and a production branch. The dev side will be doing things like feature development and bug fixes. I'm a noob to git/github and am wondering how other people/repo's handle situations where they have a feature branch that they are 3 months from deploying, but simultaneously have a bug fix that needs to be deployed to production immediately. And then that bug-fix needs incorporated into the feature branch. Are there any write-up's on this kind of thing? What would you recommend? edit: here is a thing http://nvie.com/posts/a-successful-git-branching-model/ Physical fucked around with this message at 20:24 on May 3, 2012 |
|
#
?
May 3, 2012 20:21
|
|
|
Make the fix on a hotfix branch, put it in production, then rebase your feature branch or cherry pick that fix or merge it or really whatever suits your fancy.
|
|
#
?
May 4, 2012 05:07
|
|
|
bootleg robot posted:I've written a decent sized application, and use subversion as version control. I have begun the process of placing the front end and the back end into their own separate assemblies. Does it make sense to maintain separate repositories for both? Of course, I'm speaking from developing a project with 4-10 developers who work on both the frontend and backend at different times, so having separate repos makes a lot of sense since about 90% of our changes are either completely on one side or the other.
|
|
#
?
May 4, 2012 06:19
|
|
|
Recently this week I finally got around to using Git. I've gotten the hang of it, and can create repos/commit my changes and all that junk now, but there's just something I'd like clarification on. When I do git add foo.py does that just mean "add this to the list of items that will be commited" and nothing else? That's what it seems to mean (and that's what the help files seem to be saying), but I just want to be sure. The only other version control I have experience with is TortoiseSVN (which I hated) so pardon my stupid question. 
|
|
#
?
May 8, 2012 21:26
|
|
|
|
| # ? May 12, 2024 20:10 |
|
|
Optimus Prime Ribs posted:When I do git add foo.py does that just mean "add this to the list of items that will be commited" and nothing else? There's three 'sections' active when using git, your working set, the stage and the repository. The working set is the current set of files, just as they appear on disk. The repository is a series of snapshots you can check out (potentially overwriting) to the working set. The stage is a set of changes that can be written to a new snapshot in the repository. Adding a file writes the state of the file at the time add is run to the stage. This means if you add foo to the stage, then edit foo, none of those edits will make it into the commit unless you readd the file.
|
|
#
?
May 8, 2012 21:47
|
|
