In general, for copying parts of one git repo into another, I've had good experiences with format-patch combined with am. Also, for commits that you only have locally, including whole branches, as long as you haven't pushed them anywhere else, I've found rebase -i useful for reorganizing/squashing commits. Are you using git-svn? It's supposed to be a pretty good bridge.
However, am I understanding correctly that you are asking about scripts that have already been published to the main server, and you'd like to retroactively add a history to them? While it's certainly possible with rebasing, the problem with doing something like that in git is that of course every commit depends on every previous commit, which means that if you change the history, all commit hashes following the rewrite change, which might become a major problem if any of your colleagues have local branches etc.
Although I'm not a git expert, I believe one possible way to do this would be: first, practice the rebase on a local copy so that you know what you are doing. Then coordinate with your colleagues: make sure they've committed and pushed all of their local changes and branches, do the rebase on the server, and then make sure all your colleagues pull the new history, and are working off of that (AFAIK they'd also have to rebase their branches).
If that's too much work, and you just want to save a history for a couple of files, one idea for a workaround might be: make a branch of the repository at the point in history where your changes start, apply your commits to that branch, and then merge the branch back in (I think you'd probably need some trickery where you do a squash merge of the master into the branch before the final merge, not sure at the moment). Not the most elegant solution, but at least you'd have the history saved.
In reply to Re: [OT] complex GIT merging
by haukex
in thread [OT] complex GIT merging
by LanX
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |