From: Randal L. Schwartz <hidden> Date: 2016-06-15 22:52:40
quoted
quoted
quoted
quoted
"hs" == hs glw [off-list ref] writes:
hs> Some clients have customizations of the code, some have version 5 of the
hs> software others have 5.2, 5.5 etc.
Create an empty repo.
Unpack the oldest release (I presume you still have the tarballs) you
might have forked a customer from. commit it, and tag it as v5.0 (or
whatever it is).
In the same dir, delete the files, and unpack the *next* release. git
add . again, and commit that, effectively recording the changes from one
release to the next. Tag it v5.1 or whatever.
Repeat for all releases.
git branch -m master release
That will remain your untouched release branch.
Now, take customer1. Figure out which release is closest to their
modified code. Let's say it's v5.2
git checkout -b customer1 v5.2
erase the files, copy their work in, and commit. You'll now have a
customer1 branch that comes off the right release.
repeat for each customer.
So now you have tags for each release, and every customer's code checked
in somewhere.
If you feel brave, you can try to move a customer to a later release:
git checkout customer1
git rebase v5.5
That will try to apply the diff between v5.2 and customer1 directly to
the top of v5.5. Might fail, might need some mopping up. But at least
the hard work is done.
Hope this helps.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[off-list ref] <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
Randal, thank you for the comprehensive answer. I have one follow-up: we
have the working files, then in our installation files we have .PL files
that are worked on by some iteration of "make" to insert paths both into
.cgi files and config files, should these installation files be setup as a
branch? or is there a more correct way of implementing this?
--
View this message in context: http://git.661346.n2.nabble.com/Big-Mess-How-to-use-Git-to-resolve-tp7103964p7104493.html
Sent from the git mailing list archive at Nabble.com.
Randal, thank you for the comprehensive answer. I have one follow-up: we
have the working files, then in our installation files we have .PL files
that are worked on by some iteration of "make" to insert paths both into
.cgi files and config files, should these installation files be setup as a
branch? or is there a more correct way of implementing this?
If I understand you correctly the working aka source files are patched
in place to adapt to a customer. I would suggest changing that a bit so
that the source filename is different from the installation filename.
Add the source file into the repo and add the installation filenames
into .gitignore
That way you don't have generated files in the repository. Which is
usually avoided because they easily get out of sync with their source.
The renaming should be done so you never erraneously add installation
files into the repository in place of the source files
The technique Randal described sounds like the 'vendor code drop' method
described in the git-rm manpage. There you will find detailed
instructions on the best way to 'erase' the previous version and drop in
a tarball of the 'newer' version.
Hope this helps.
v/r,
neal
Note that Randal's solution leaves with a branch named Release that has
the history of the generic version of your software, and various
custom(er) branches that fork from the Release branch...
On 12/17/2011 6:32 AM, hs_glw wrote:
Some clients have customizations of the code, some have version 5 of
the software others have 5.2, 5.5 etc.
My goal is to pull all the different versions in, put them all
> together, and create a master version of the software that runs for
> all clients.
Note that you don't have to make everyone run the same version. At my
shop we maintain dozens of concurrent divergent versions and that is the
main reason we chose git. We can maintain a generic version (which most
clients run) and also custom branches (for clients wanting to pay for
customizations) forked off of the generic branch. The custom branches
can periodically have the generic branch merged in to obtain the generic
fixes/enhancements. You can also merge the custom branches into the
generic branch if you want those custom features included in a new
release of the generic branch.
There will still be some files that are completely unique to each
client (style sheets and logos for instance).
If your logos are graphical files they are likely considered 'large
files' and are likely binary files in the context of git. It is
recommended you maintain these in a separate repository to keep them
from bogging down your main repo (performance and storage). You can
make the logo repo a submodule of the main repo (source repo). This
would then make your main repo a 'super project' (contains submodules)
in git terminology. Alternatively, I think your source repo and logo
repo can just both be submodules of a super project.
We are working on implementing this so some of what I said is
theoretical. Custom branches in combination with submodules seems like
it could get pretty unwieldy if not managed properly.
Some things to look into.
v/r,
neal
In message [off-list ref], Neal Kreitzinger writes:
We are working on implementing this so some of what I said is
theoretical. Custom branches in combination with submodules seems like
it could get pretty unwieldy if not managed properly.
You might want to consider using gitslave (http://gitslave.sf.net)
which is easier to use when you are developing both the superproject
and the subprojects at the same time. You don't have to use the
"mother-may-I" commit protocol.
The trick with gitslave is that normally you run all git commands on
all repositories at the same time. So all repositories which are part
of the superproject will be on the same branch. This sounds like it
is ideal for you.
However, you do lose the strong binding between the superproject
commit and the subproject commit, so you would want to tag all
projects (trivial when using gitslave) when you go through a release
so that you can later go back and check out synchronized repositories
for a particular release.
-Seth Robertson