|
I've been using git with an svn connector. I had been doing all rebase and commits from the master after merging local branches. However, the rebase operation has an unfortunate side effect of removing the local git history for the branch being merged back to trunk. Can someone recommend me a way to keep the history and still be able to do updates from SVN?
|
#
¿
Apr 14, 2010 15:44
|
|
|
|
| # ¿ Jun 2, 2024 11:29 |
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
Mithaldu posted:git stash You can combine those the checkout and branch as git -b <branchname> <commit-id> CHRISTS FOR SALE posted:Does anyone else here use git for large files? It does take a while for the repos to push to the backup server, but I've been using it to keep my Logic Pro tracks version-controlled. It's also AWESOME for collaboration, because we can branch the project and I could work off my own branch while my collaborator(s) can work off theirs simultaneously. I chose git based on its ability to make branches and merge them easily, because working collaboratively I have a feeling that such functionality will be crucial to our workflow. Repo size itself isn't a huge issue. However, I would not recommend checking in files larger then a gig or 2. You end up running out of memory often. What does everyone do about 3rd party libraries needed to compile their code. I'd rather not check in specific version tar.gz files into the repo (I actually hate seeing built binaries and tarballs in a repo). I guess I'm looking for an updated non retard version of GForge which will work with git. HFX fucked around with this message at 09:04 on Feb 25, 2011 |
|
#
¿
Feb 25, 2011 08:59
|
|
|
Sizzlechest posted:I had used git on Linux and through Cygwin. I had no idea the windows installer was so horrific. This is only true until you start having to maintain 3-4+ branches on the same client machine. At that point git becomes faster, smaller, and easier to use.
|
|
#
¿
Apr 14, 2011 19:21
|
|
|
Sizzlechest posted:If it's any consolation, there's always git-svn and Subversion 1.7 will have some long sought-after features like a single I've used it before. My experiences where less then stellar especially in the way most SVN users expect things to work (single large commits, no renaming of files, etc). Sizzlechest posted:That depends. If his checkout is extremely shallow for all branches, then probably it will be faster than git. It might have had something to do with the repository being ~2-3 gigs total. Edit: I will say you need to give git more time and try to wrap your head around the distributed model. I hated it at first, but after learning it, I don't ever want to go back to CVS or SVN, especially when working with teams from several companies and locations around the world. HFX fucked around with this message at 19:30 on Apr 14, 2011 |
|
#
¿
Apr 14, 2011 19:27
|
|
|
Sizzlechest posted:Err... Like mentioned before, he's not talking about the repository. He's referring to the working copy. I wasn't entirely clear. I even had made a mental note to go fix it and then got side tracked by other issues. The entire repository was much greater then 2-3 gigs (more like 60+). A single branch being pulled down was 2-3 gigs of space. I was usually working with 3-5 branches at a time. When they switched to git, and I just cloned the repo, the repo was ~4.5 gigs total. Thus, I was actually saving space. For what its worth, you don't have to completely clone a copy of the entire repository to your local directory in git. You can just pull a branch and even just keep the history of the files as they are the latest. In effect, you can make it behave like SVN. I did laugh about everyone using Windows. Jethro posted:For what it's worth, I also tried using git on Windows and very quickly reached the stage where I couldn't be bothered. The biggest problem for me was the fact that Cygwin or git bash or something involved in git couldn't handle network shares. So I gave up and went back to my uncontrolled ways. See now these are valid reasons. I know part of the problem with windows shares in cygwin and it is do the fact windows doesn't treat shared mounts as just another file. HFX fucked around with this message at 15:53 on Apr 15, 2011 |
|
#
¿
Apr 15, 2011 15:44
|
|
|
ianN posted:Anyone know of a good Linux SVN client? Comparable to Tortoise for Windows. You mean a GUI? Most Linux distro's come with an SVN client installed. You should go ahead and learn the command line as it opens a lot of powerful tools. As to a GUI, Nautilus already has support for SVN and there is RapidSVN. Edit: Has anyone here used RTC and could point me to a good tutorial of how best to use it and hopefully deals with ideas such as topic branches? We've been using it for a project, and to describe the current usage as painful is being kind. HFX fucked around with this message at 22:29 on Oct 25, 2011 |
|
#
¿
Oct 25, 2011 22:27
|
|
|
Vanadium posted:reset --hard is hardly worse than checkout . though, which sounds a lot more innocent. I'm not sure what you are talking about with checkout. If you have uncommited changes it won't do it without a warning about overwriting files. If you have files you have not yet added, it will warn you about those too. ExcessBLarg! posted:Annoyingly, the actual outcome I've seen with SVN is commit avoidance. Folks don't want to commit untested/potentially buggy code until "it's time", but due to time constraints the uncommitted code will end up running somewhere anyways. Obviously part of the solution here is to ensure that a VCS checkout/update is required as part of deployment, but having a tool and workflow that makes branching much easier is really helpful. I find SVN tends to encourage large monolithic commits. Touched 20 files, wrote 1000 lines of code for the new feature that possibly merge with at least 10 files. Yep one commit. Have fun figuring out if something went wrong. My own comment: Git is very difficult to understand if you have only used central code repo's. Once you change the way you think, it becomes easy and central VCS systems feel clunky and bad.
|
|
#
¿
Jul 2, 2014 06:42
|
|
|
Vanadium posted:I mean git checkout <path> where <path> is the current directory or w/e, which just throws away all unadded changes in <path> by overwriting them with the state of the index with no warning. That's also really the destructive thing that git reset --hard does, the bit where it makes the current branch point somewhere else is comparatively easy to undo. That honestly seems like a bug and definitely isn't consistent with checkout at all. Hopefully if you have been committing fairly often, you won't lose too much data. That said, it definitely should not occur by default. As to the reset command, that one probably gets tossed out as a solution when something else would suffice. It did take me a bit to understand what the reset really was doing. Suspicious Dish posted:Sure, but sometimes I have a big rewrite that's not too easy to break into pieces. I feel bad for pushing a giant commit, but sometimes that's the smallest logical change you can make. I will admit this does tend to happen with refactoring. The other item is that it sometimes points too tightly coupled code. Unfortunately, sometimes their is just no way around it. HFX fucked around with this message at 13:24 on Jul 2, 2014 |
|
#
¿
Jul 2, 2014 13:21
|
|
|
wwb posted:^^^ Sourcetree actually does pretty well on that front. Are you sure it isn't because they are just morons? Hell I rarely ever do a git add . Most everything is git add -p <filename> That said, I use Sourcetree quite a bit, especially if I can't drop a cygwin terminal on the system. I just wish it handled git svn. HFX fucked around with this message at 04:14 on Jul 3, 2014 |
|
#
¿
Jul 3, 2014 04:04
|
|
|
Volmarias posted:I very infrequently use git add -p. I do, however, habitually use git diff --cached to verify what I'm going to commit before I commit it. I'm not sure why everyone is on the git add -p bandwagon, when 99 out of 100 times you want to commit every change you made in the file. Sometimes I write more changes then makes sense to add at single time. Verifying what I am commiting goes without saying. But that is a good practice for ever vcs.
|
|
#
¿
Jul 3, 2014 05:42
|
|
|
Slanderer posted:Cross -posting from the general questions thread, since I accidentally posted there instead of here: I think based on the information you have given me, youbare on the right track with hooks.
|
|
#
¿
Mar 11, 2016 06:42
|
|
|
|
| # ¿ Jun 2, 2024 11:29 |
|
|
Does anyone here use GitLab? I've been playing with the merge options and don't like that it creates a merge even when I've rebased on to the head of the branch I'm merging. I would like it to behave more git does locally where it will FF if possible and only do a merge otherwise. Is there something in the settings I can set to allow for the desired behavior?
|
|
#
¿
Oct 19, 2016 15:00
|
|