|
I have a few people that are finding SVN "skips" on updating a certain folder in their working copy. You can update the contents fine, but an attempt to update on the directory just gets a "skipped" message. I've taken a look and the .svn directory is still there. Does anyone know what's going on?
|
#
?
Jun 29, 2010 10:07
|
|
|
|
| # ? May 10, 2024 10:16 |
|
|
epswing posted:Why is that? It'd work for a small group of people that you trust and who are familiar with Hg. But they could push conflicting branch names, or overwrite your branches, or whatnot. Basically, you're giving your entire team write permission into your repo. This is generally a bad idea, though of course it could work for your specific scenario.
|
|
#
?
Jun 29, 2010 12:49
|
|
|
I should have clarified that I'd have a clone specifically for accepting changes. In fact I could have as many clones as I have pushing developers, each hg serveing on a different port. However...I see what you're saying. It makes sense that I would clone from them so I can load their changes into my development environment, and then if I liked what I saw, I'd actually pull into my working repo.
|
|
#
?
Jun 29, 2010 16:24
|
|
|
epswing posted:I should have clarified that I'd have a clone specifically for accepting changes. In fact I could have as many clones as I have pushing developers, each hg serveing on a different port. So you'd be creating a "public" repository for each of them to push to? You've independently created the "integration manager" workflow described at http://whygitisbetterthanx.com/#any-workflow (ignore for the moment that this page is Git evangelism; the DVCS workflows described are mostly tool-agnostic). Having a clone for each developer to push to (that you create and manage) is a strange idea; it makes more sense for each developer to manage that clone themselves. Each of them can publish their code into their public repository, and you pull from those at your leisure. If you like what you see, push it to the central repository (which the developers should regularly pull from). It's a good idea for developers to have separate public/private repositories: one that is used for actual work and one that's used to publish changes to others when a feature/branch/etc. is stable enough to integrate. If you're pulling directly from their workspace without warning, you're likely to obtain half-done features/changes/etc.
|
|
#
?
Jun 29, 2010 17:07
|
|
|
In git is there any way of folding a series of commits into a single commit? I'm thinking of ways to embrace the 'it's cheap to branch' concept and was pondering linking save in my editor to an auto add/commit into a branch. Then I'd want to fold all of these micro commmits into a single large commit once a day or when regression tests pass. Then merge *THAT* commit and only that commit into the main branch so the main branch history only has the large commit and not hundreds of smaller ones all with an 'autocommit' comment.
|
|
#
?
Jun 29, 2010 17:26
|
|
|
git rebase --interactive commit-before-your-branch and read the instructions that show This is destructive since it rewrites history so I guess you may want to duplicate your branch before trying. Vanadium fucked around with this message at 17:29 on Jun 29, 2010 |
|
#
?
Jun 29, 2010 17:27
|
|
|
Lysidas posted:So one public repository per developer (read/write) and one public central repository (read-only). By public I mean 'available on the internet'. That makes sense. So I can take a look at their changes, and be able to push from their public repo to the central repo. code:Edit: Riiight, like this 
epswing fucked around with this message at 18:34 on Jun 29, 2010 |
|
#
?
Jun 29, 2010 18:15
|
|
|
Vanadium posted:This is destructive since it rewrites history so I guess you may want to duplicate your branch before trying.
|
|
#
?
Jun 29, 2010 20:05
|
|
|
Ah, I have not used the reflog apart from digging through it manually. I did not realise it counted as anything but an implementation detail. 
|
|
#
?
Jun 29, 2010 20:52
|
|
|
Vanadium posted:Ah, I have not used the reflog apart from digging through it manually. I did not realise it counted as anything but an implementation detail. One of the weird things about git that I have learned is that all the internal workings that you might think are "implementation details" are incredibly useful in specific scenarios.
|
|
#
?
Jun 29, 2010 21:00
|
|
|
I only ran into the reflog because git would not gc some multi-gb objects that were checked in at one point but since dropped through history rewriting, welp.
|
|
#
?
Jun 29, 2010 21:06
|
|
|
I have a directory that contains directories for three classes (A, B, and C). C is a subclass of both A and B. Basically I want to setup svn to be able to allow for different versioning of each of these classes while at the same time having the other developers only have to update the parent directory (as if the entire folder were just a single repository). Maybe there I'm way off and there is a better way to go about this. I am open to suggestions. There is also the possibility that this post is terribly incoherent, if so I can attempt to explain it a little better.
|
|
#
?
Jul 8, 2010 19:19
|
|
|
Modern Pragmatist posted:I have a directory that contains directories for three classes (A, B, and C). C is a subclass of both A and B. No idea about SVN, though you can do this with git submodules really easily. But it sounds to me like you're trying to solve a problem the wrong way; trying to hammer a VCS into something it doesn't want to be. You might want to step back and rethink how things are laid out. Describing your problem at a higher level (describe what you want, not how you want to get there) might help people in this thread give better suggestions.
|
|
#
?
Jul 8, 2010 23:12
|
|
|
I'm having a bit of difficulty getting a Git post-receive hook working. I'm working on a website, and what I want to happen is when I push the changes to the webserver, a post-receive hook will be executed, go to the directory where the website is, and pull in the latest changes. It's my understanding that this is how it should work rather than just pushing directly to the cloned repo in the web directory. So, in my home directory on the server, I have a bare repo that I've pushed to. It works fine, I can push to it just fine. I made the post-receive hook there as well to cd to the web directory and do a git pull /home/vmc/website.git/ master. If I'm on the actual server itself, I can execute the hook just fine and it works. However, if I set up the webserver as a remote push destination and push to it, I always get this error: code:code:Any help would be greatly appreciated. EDIT: Fixed this. Git has an environment variable, GIT_DIR that it sets to '.' when you push to it remotely. Unsetting the environment variable (unset GIT_DIR) fixed this. Now the script would look like: pre:#!/bin/bash cd /var/www/vhosts/website.com/ unset GIT_DIR git pull musclecoder fucked around with this message at 12:52 on Jul 17, 2010 |
|
#
?
Jul 9, 2010 14:12
|
|
|
I wonder if I understand how branches are supposed to work in git. I have a repository cloned that I've been pushing up for awhile now, but I have some speculative changes I'd like to do in a branch. I first create the branch with 'git checkout -b waaah' and then branch to it with 'git branch waaah.' I have found that if I edit a file there and then switch back to the master branch, the changes persist. Shouldn't it not persist into the master branch unless I merge it?
|
|
#
?
Jul 17, 2010 05:10
|
|
|
Your post didn't explicitly say this, and I want to rule it out before any more investigation: did you commit the change(s) before switching back to master? Checking out a new branch should preserve local un-committed modifications (and untracked files) that don't conflict with the branch you're switching to.
|
|
#
?
Jul 17, 2010 06:21
|
|
|
Rocko Bonaparte posted:I wonder if I understand how branches are supposed to work in git. I have a repository cloned that I've been pushing up for awhile now, but I have some speculative changes I'd like to do in a branch. I first create the branch with 'git checkout -b waaah' and then branch to it with 'git branch waaah.' I have found that if I edit a file there and then switch back to the master branch, the changes persist. Shouldn't it not persist into the master branch unless I merge it? Secondly, try committing changes to a branch before you expect the changes to be tracked by git.
|
|
#
?
Jul 17, 2010 06:28
|
|
|
Rocko Bonaparte posted:I wonder if I understand how branches are supposed to work in git. I have a repository cloned that I've been pushing up for awhile now, but I have some speculative changes I'd like to do in a branch. I first create the branch with 'git checkout -b waaah' and then branch to it with 'git branch waaah.' I have found that if I edit a file there and then switch back to the master branch, the changes persist. Shouldn't it not persist into the master branch unless I merge it? Yeah, you're pretty confused. I suggest reading up on the tool you're trying to use. There's a really good resource that I just discovered right here: http://progit.org/book/
|
|
#
?
Jul 17, 2010 14:39
|
|
|
How does one merge only one file over to another branch in git. I fixed a bug in one branch I was working on and need to merge the changes into another branch (the files are approximately 25% different before the change). Should I just copy both copies to somewhere else, merge there and then copy back into my tree on the branch I need?
|
|
#
?
Jul 18, 2010 20:38
|
|
|
HFX posted:How does one merge only one file over to another branch in git. I fixed a bug in one branch I was working on and need to merge the changes into another branch (the files are approximately 25% different before the change). Should I just copy both copies to somewhere else, merge there and then copy back into my tree on the branch I need? If it's only one commit, this might be useful: http://ftp.sunet.se/pub/Linux/kernel.org/software/scm/git/docs/git-cherry-pick.html
|
|
#
?
Jul 18, 2010 20:46
|
|
|
Mithaldu posted:If it's only one commit, this might be useful: http://ftp.sunet.se/pub/Linux/kernel.org/software/scm/git/docs/git-cherry-pick.html It is spread over several commits that may have other files with them. I should have specified that. It makes cherry picking not work.
|
|
#
?
Jul 18, 2010 20:49
|
|
|
HFX posted:How does one merge only one file over to another branch in git. I fixed a bug in one branch I was working on and need to merge the changes into another branch (the files are approximately 25% different before the change). Should I just copy both copies to somewhere else, merge there and then copy back into my tree on the branch I need? You don't merge files, you merge branches. You might want to do a cherry-pick operation here. With your target branch checked out, just do: 'git cherry-pick <commit that fixes bug>'. This is an "ugly" operation from a history perspective. If you care a lot about your history, you should have a bugfix branch, where you fixed that bug, which you then merge into your topic branch (and your maintenance branch, and your master branch, etc). But if you don't care a lot about history, then just do the cherry-pick. If you did more than fix that bug in that commit, then shame on you. You can still do the cherry-pick, but then revert the changes to files you didn't want to modify (git checkout -- <files>), add the revert, and amend your commit.
|
|
#
?
Jul 18, 2010 20:52
|
|
|
This is why we use git add then git commit rather than just git commit -a btw
|
|
#
?
Jul 18, 2010 20:55
|
|
|
ColdPie posted:You don't merge files, you merge branches. You might want to do a cherry-pick operation here. With your target branch checked out, just do: 'git cherry-pick <commit that fixes bug>'. This is an "ugly" operation from a history perspective. If you care a lot about your history, you should have a bugfix branch, where you fixed that bug, which you then merge into your topic branch (and your maintenance branch, and your master branch, etc). But if you don't care a lot about history, then just do the cherry-pick. Yeah I realized the fix should have been applied somewhere else but it was discovered while making more significant chances to a larger section of code. The platform I'm working on right now makes it very hard to actually do unit testing.
|
|
#
?
Jul 18, 2010 20:55
|
|
|
I guess you might want something like: git diff $(git merge-base branchA branchB)..branchB -- your_file > my.patch git checkout branchA patch -p1 < my.patch git add your_file git commit Might not have the syntax totally right. This will get you the difference of that one file on branchB, then apply it to branchA and commit the change. E: Make the example a little more clear. E2: I guess this squashes the history of the bugfix. ColdPie fucked around with this message at 21:07 on Jul 18, 2010 |
|
#
?
Jul 18, 2010 21:04
|
|
|
ColdPie posted:I guess you might want something like: Yeah, that was my only issue was losing the history on the bug fix. I might have to just suck it up at this point. Thanks guys.
|
|
#
?
Jul 18, 2010 21:24
|
|
|
git checkout your_branch your/file/path.txt this will copy that branches version of this file, and replace your current directories version of it.
|
|
#
?
Jul 19, 2010 06:32
|
|
|
king_kilr posted:git checkout your_branch your/file/path.txt I don't want to replace. I want to merge. Anyway, I ended up doing it by pulling both files, doing a merge and then copying it back in to commit with a note of the merge and why.
|
|
#
?
Jul 19, 2010 09:35
|
|
|
I don't normally do this but...king_kilr posted:branches branch's directory's Learn and understand the difference or you'll be confusing people for generations.
|
|
#
?
Jul 19, 2010 14:48
|
|
|
What do you guys suggest for a web interface for SVN that also has project management type features such as tasks, timelines and whatnot? I know of websvn but it lacks the project management features I'm looking for.
|
|
#
?
Jul 19, 2010 21:10
|
|
|
Trac is really great
|
|
#
?
Jul 19, 2010 21:13
|
|
|
Redmine integrates with SVN (and others) and does those things.
|
|
#
?
Jul 19, 2010 21:14
|
|
|
Yakattak posted:What do you guys suggest for a web interface for SVN that also has project management type features such as tasks, timelines and whatnot? I know of websvn but it lacks the project management features I'm looking for. I have no personal experience with it but this sounds like a job for Trac: http://trac.edgewall.org
|
|
#
?
Jul 19, 2010 21:15
|
|
|
Was just reading up on Trac actually. Looks like I need to test both of these and see which I like best. Thanks guys!
|
|
#
?
Jul 19, 2010 21:17
|
|
|
Speaking of maintaining consistent & clean histories in Git, this link popped up on the Git mailing list the other day, and I found it very clarifying. http://thread.gmane.org/gmane.comp.video.dri.devel/34739/focus=34744
|
|
#
?
Jul 19, 2010 23:12
|
|
|
Got redmine up finally, I think it's a keeper (however it was quite a pain to get google apps setup with it for email purposes).
|
|
#
?
Jul 20, 2010 04:25
|
|
|
If anyone here is using git and working with remote teams, or just want to keep track of what is going on in a project, my company has just soft-launched a new webapp https://www.utsup.com. It allows project managers to track what people using the git project repository are doing in near real-time. We made it because we got tired of having to ask people, "what are you working on?" It makes it really easy to monitor a team of people just by tying in a private twitter account to see all the updates come in through a constant stream, especially when you get people to start using the "sup in" command which then kicks off a process that sends out an update every 5 minutes with a file diff even if they haven't committed anything yet.
|
|
#
?
Jul 27, 2010 02:29
|
|
|
I'm a git newbie, so I'm still wrapping my head around the whole DVCS concept. I have a basic project right now with the following structure code:So how do I add in the changes I want to experimental, then create a new branch for the feature I'm adding (without losing what's in my working directory,) then finally go back to the clean + bugfixed experimental branch? My only idea is to backup the whole directory somewhere, revert my working directory, diff + merge the backup & working directory to add in the bugfixes, commit, create a new branch, then copy back in all of the backup directory to the working directory, and commit to the new branch, before finally pulling from experimental again. That whole thing (with the backup directory and all) seems like a huge PITA, though. Is there a better way?
|
|
#
?
Aug 2, 2010 06:06
|
|
|
You can put uncommitted changes into the stash, do your merging and branching, and then pop the stash back onto what you want to work with.
|
|
#
?
Aug 2, 2010 06:52
|
|
|
|
| # ? May 10, 2024 10:16 |
|
|
git add -i is also likely to be helpful. Basically, commit everything you want to keep in the experimental branch (even if it's not done; at worst you can later change this commit), stash everything else, make the new branch, then unstash.
|
|
#
?
Aug 2, 2010 08:09
|
|