Michael,
There should be no problem..
First you / Git can host multiple independent branches / lines of
development -- see 'orphan' branches.
Second, You say one was forked from the other so they have the same base
commit, so they would simply be part of the same growing tree once you have
fetched/pulled in both remotes.
Third, you can then merge the different parts back together. I believe there
are sub-tree merge options as well to allow disparate tree stuctures to be
accomodated at the correct point in the merge as well. (Just need to resolve
where to push back upstream, PR/patch flow, etc)
I had a quick web view of the top level structure and didn't see the problem
you were expecting (beyond the need to add a readme about How to determine
the customizations to the gradle build script - resolvable with an email to
get it ).
Hope that helps.
Ta da; solved (*)
Philip
(*) doesn't need me to work on my computer ;-)
----- Original Message -----
From: "Michael" <keybou...@gmail.com>
To: <git-users@googlegroups.com>
Sent: Thursday, January 19, 2017 3:03 AM
Subject: [git-users] Working with a badly rooted project
Background: I'm doing maintenance work on a project called "Realistic Fluids
Overhaul". The original for this was at
https://bitbucket.org/4HeadTiger/minecraft-finite-fluids ; my current
version is at https://github.com/keybounce/Finite-Fluids
This is a forge mod for minecraft; as far as this question is concerned,
this means that there are some "template" compilation scripts (gradle based)
that assume that the code is located at ROOT/src/main/...
4Head did work on an improved 2.0 version, that I wanted to work with, and
start merging improvements in from. (NB: His 2.0 has not had a commit in
about 14 months, and is not ready as-is).
Recently, thanks to the discussion on this list, I came to understand that
just because my repository on my disk was cloned from his, and has a
"master" branch that is based on that first edition's master, this does not
prevent me from adding his new 2.0 repository (fetching / remote branches)
to mine, so I can do a read only check out, or pull some of those files into
my current HEAD.
So far, so good. Right?
Well, here is my problem, and the question: 4Head set up that repository,
and did his push, from the src directory, not from the root.
This means that anyone attempting to use it has two issues:
1. Redetermine the customizations to the gradle build script (a pain, but
probably resolvable with an email to him to get it), and
2. All the files are in the wrong place!
So if I want to do a "git checkout rfo2/master", and get a read-only copy of
the files to look at, everything checks out in the wrong directory, and
cannot be built even if I had the proper build script.
What is the best way to deal with this? I mean, one obvious solution would
be to do the checkout in the wrong directory, a mkdir + mv to fix the
directory, and then a branch and commit to get things in the right place.
Since all of the files are the same, they reuse the git blobs, and only one
new filetree blob is needed.
But:
1. Can I do a branch and commit from inside a remote tracking branch? (That
question alone probably explains my lack of understanding of what's going
on).
2. If 4HeadTiger does come back and do something, how the bleep do I keep my
modified branch in sync with his? Again, it's supposed to be a read-only
copy of what he's doing and yet I have to do a commit to fix a major whoops.
---
Entertaining minecraft videos
http://YouTube.com/keybounce
--
You received this message because you are subscribed to the Google Groups
"Git for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
