Front page | perl.perl5.porters |
Postings from November 2008
Re: git workflow (was Re: git?)
Thread Previous
|
Thread Next
From:
demerphq
Date:
November 14, 2008 09:43
Subject:
Re: git workflow (was Re: git?)
Message ID:
9b18b3110811140943i5f4446cdpd2e3af76a5a1c822@mail.gmail.com
2008/11/14 Craig A. Berry <craig.a.berry@gmail.com>:
> On Fri, Nov 14, 2008 at 3:59 AM, David Golden <xdaveg@gmail.com> wrote:
>> On Fri, Nov 14, 2008 at 4:32 AM, Nicholas Clark <nick@ccl4.org> wrote:
>>> One part of the documentation I know is missing is:
>>>
>>> There are no instructions on how to commit back to the repository.
>>
>> More importantly, there are no instructions yet on what the "workflow"
>> should be.
>
> And there's more than one workflow. Before I commit back to the
> repository, I have to know how to maintain my local repository. In
> other words, what comes after C<git clone>?
>
> Lets say I'm interested in being able to track both blead and
> maint-5.10 and to test merges back to maint-5.10 from blead. I would
> hope one of the things a new VCS would help with is increasing the
> likelihood that major patches come in with integration implications
> already worked out: does it break binary compatibility? what
> dependencies does it have? etc. Maybe I'm dreaming, but let's assume
> for the sake of argument that some people will do this and we need to
> make it as easy as possible for them to know how.
>
> So following the official git documentation, I've done a clone and
> created local branches named blead (tracking origin/blead) and
> maint-5.10 (tracking origin/maint-5.10). Of course my two local
> branches share a working directory (as the documentation emphasizes,
> the repository actually sits inside the working directory), which is a
> bit awkward since I can therefore only work on one branch at a time.
> People who use git in their day jobs laugh and say, "Don't do that."
> When I ask what to do instead, I get vigorous handwaving and something
> mumbled about using hard links to fake multiple working directories.
> If that's a good way to do things, why doesn't the official
> documentation describe how to do it that way (or does it, and I missed
> it)?
You can have multiple working directories. See the following
environment variables as documented in man git.
GIT_DIR
If the GIT_DIR environment variable is set then it specifies a
path to use instead of the default .git for the base of the
repository.
GIT_WORK_TREE
Set the path to the working tree. The value will not be used in
combination with repositories found automatically in a .git directory
(i.e. $GIT_DIR is not set). This can also be controlled by the
--work-tree command line option and the core.worktree configuration
variable.
Its a bit clunky and more meant for scripting purposes than end user
purposes, but it is possible. However, dont do it like that.
> The other obvious path to take is to maintain two completely separate
> copies of the repository and keep each one checked out to a different
> branch. Is that what people do? If so, how do you test merging your
> blead changes back to 5.10.x without simply submitting a patch to
> yourself (which kind of defeats the purpose of having a tool with
> highly touted merge capabilities)? Do I have to set up my local maint
> repository to track my local blead repository as if it were "remote"?
> If so, how exactly do I do that? If not, what should I do instead?
Yes you can do that. :-)
Git is the TMTOWDTI of version control systems. The reason there are a
lot of handwaving in the answers you get is because there is no
"right" answer to your questions.
Most likely however yes you would have multiple copies of the repo around.
There are different ways to set this up. You can have one which is
cloned from the canonical repository, and then make the others clones
of that, or you can make them all clones of the canonical.
It really doesnt matter. Also you would almost NEVER be "applying
patches from one to the other" It would much more likely be a
git-cherrypick, or even a git merge.
One thing to rememeber is that "branches" are pointers in git. They
arent "things" they are just a note that says "if you make a new
commit then update $somefile with the sha1 of the new commit". So
making branches, and stuff like that is an _extremely_ fast operation.
Frankly if you havent used git before it will take some unlearning,
but eventually it will become clear. The fact is git is an extremely
simple system. YET.... In the same way that Go is a very simple game
as compared to Chess. There are far more possible Go games than there
are Chess games. Same with git versus pretty well any other VC.
> Only at the end of this process does the question of how to push to
> the official repository become relevant.
Well not really. Pushing to the official repository will be much the
same as pushing, and fetching from your own clones.
Keep in mind, in git there is no upstream. Every clone is a completely
standalone full featured repository. You can make any clone talk to
any clone. You can have one clone "know" about many other clones. Its
all just a matter of labels.
Unfortunately until you have been using git for a while its a bit hard
to explain some of this stuff. Mostly because it is actually much
simpler than it sounds or is in other VC's.
Cheers,
yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next