[OT] complex GIT merging

LanX has asked for the wisdom of the Perl Monks concerning the following question:

Background

we have a rather complicated web-application where each "Page" is just implemented as a .pl script in a directory on our DEV server.

Since our team was growing, working on that instance became more an more unstable and SVN versioning was mostly broken.

That's why I created my own working environment on my laptop, developing my pages there and copying them to DEV for public testing when ready (before finally moving them to PROD)

Of course I started using GIT locally and commited every change.

Now, 18 month later I got a new laptop and copied the new working copy to have a clean base.

In the meantime some other colleagues started to use GIT too and commited their changes for their files into the copy of the DEV server.

One colleague even set up a GIT-lab server so that we can now push our changes to a central GIT instance.

Problem

What's the best way to retrofit my commit history on the old copy into the actual Master version? (don't wanna loose it)

From my understanding they would get lost because the Master is already up-to-date.

The best idea I had was to identify the files I changed, check out the first local versions, copy them to DEV, and to push all changes.

Another one is to just leave all local commits in a branch.

I never used GIT in an team environment with beginners and am puzzled about the best approach, I'm sure I'm not the first having this problem... :)

see also XKCD ;-)

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery
FootballPerl is like chess, only without the dice}

Comment on [OT] complex GIT merging

Replies are listed 'Best First'.
Re: [OT] complex GIT merging by atcroft (Abbot) on Sep 26, 2018 at 15:44 UTC
I ran into an issue some time ago where I needed to retain a history, and ran across the following: Lee, Eric. "Merging Two Git Repositories Into One Repository Without Losing File History." SaintGimp, 2013-01-22. http://saintgimp.org/2013/01/22/merging-two-git-repositories-into-one-repository-without-losing-file-history/. Hope that helps.	[reply]
Re: [OT] complex GIT merging by haukex (Archbishop) on Sep 26, 2018 at 19:02 UTC
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.	[reply]
Re: [OT] complex GIT merging by wjw (Priest) on Sep 27, 2018 at 00:10 UTC
Honestly, I would simply make a new branch, put my stuff there and leave it. I assume that your current local copy has been pulled and is recent. Munging git around to do what you want seems like an awful lot of work and at least some minimal risk. Were I you, I would rather work on the project itself than on patching things together in git. But that is just me. I guess it would depend on the ROI expected. You probably already know this, but I would certainly standardize on one system of version control. As long as you have a git server set up, it seems to me like that is the way to go. I worked for a time at a large insurance company where the developers were using svn, the test team cvs, and the other groups up the RUP ladder were using Harvest. Not a good situation, particularly since it was a huge project and a huge team. We finally got it down to svn and Harvest (Harvest had upper management behind it). I ended up writing the bridge between svn and Harvest. It would have been so much better had we simple been able to rely on a single system! Anyway, anecdotes aside, I thought I would toss in my $0.02 worth. While it would be great to go through the exercise and learn more about git, I would ask the ROI question. Best of luck with your project! ...the majority is always wrong, and always the last to know about it... A solution is nothing more than a clearly stated problem... wjw	[reply]
Re^2: [OT] complex GIT merging by LanX (Saint) on Sep 27, 2018 at 16:05 UTC
Thanks, everybody. I dared asking that question because I didn't want to miss any obvious solution > Honestly, I would simply make a new branch, put my stuff there and leave it. I assume that your current local copy has been pulled and is recent. I decided to go this way, and pushed a branch to gitlab. Not only because it's already a difficult task under normal circumstances, but because the commit history is a big mess on our server. Two colleagues did irregular big commits of all changed files (unfortunately including mine) with commit messages like "status" ,"new status", "last status". Probably I could ditch those, but it would be a waste of time trying to discuss with them. It's already difficult enough to keep my own house clean. Again thanks everybody! :) Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply]
Re: [OT] complex GIT merging by karlgoethebier (Abbot) on Sep 27, 2018 at 15:24 UTC
OK, i wasn‘t a GIT user. But under SVN in similar situations I moved my stuff to a branch. Else pain in the ass. Regards, Karl «The Crux of the Biscuit is the Apostrophe» `perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'`Help	[reply] [d/l]