Front page | perl.perl5.porters |
Postings from November 2008
Re: git workflow (was Re: git?)
November 15, 2008 11:36
Re: git workflow (was Re: git?)
Message ID: email@example.com
2008/11/15 Craig A. Berry <firstname.lastname@example.org>:
> On Fri, Nov 14, 2008 at 11:43 AM, demerphq <email@example.com> wrote:
>> 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.
> I understand that, but it doesn't mean I have to like it. It's a lot
> like trying to get a recipe from a master chef when you are hungry:
> you get theory and esoteric variations when what you need is a
> straightforward how-to. Sure, git is intellectually interesting, and
> people can follow that interest as far as they want. I hope to have
> time to get a bit further down that road myself. But unless we want
> p5p to become a graduate seminar in git, the answer to "What do I do?"
> should be what to do, not a lecture on how to think about version
> control or embark on a journey of enlightenment in The Git Way. Our
> cookbook needs to be "Meals in a Minute," not Julia Childs' "The Way
> to Cook."
Sorry, I didn't realize this question was aimed at what a new
contributor would do. I thought this question was what you as a perl
committer might do. The two are quite different. For a new user the
process is pretty much as Chris Prather says.
git clone $somewhere
git commit -a -m'i made some changes to the blah blah'
git format patch -1
[send mail to perl mailing list]
>> Frankly if you havent used git before it will take some unlearning,
>> but eventually it will become clear.
> I may have less unlearning than you think because that assumes I
> already know something :-). But let's not worry about me, let's worry
> about the hypothetical person who has figured out how to use perlbug
> and has ended up here, patch in hand, wondering what the heck "blead"
> is and how to get it and submit changes to it. If, in explaining what
> to do, we use phrases like, "eventually it will become clear," I think
> we will lose them and their work instantly. IMO, without a good,
> Perl-specific cheat sheet, we are somewhat ill-prepared for the git
> transition. I will do what I can to help, but I'm short on both tuits
> and expertise to write such a document.
I dont think you will need to. There are a lot kicking around. Git is
gaining momentum quickly. I think its entirely possible that we will
find that a lot of users will already be familiar with git and wont
require the help. There are huge numbers of projects already on git.
Its not like we will be an "early adopter", on the contrary.
Also you asked this from the point of view of having multiple branches
around etc, I viewed that as suggestive that your were looking for
committer level guidance.
>>> 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.
> Maybe conceptually they are the same, but as the ssh discussion in the
> other fork of this thread makes clear, the syntax is quite a bit
> different. You can understand the concepts and still not know what
> commands to type.
Basically its the same syntax. Its easiest to explain from the point
of view of clone:
git clone $path $name
git clone git://$host/$path $name
git clone ssh://$host/$path $name
git clone http://$host/$path $name
git clone $user@$host/$path $name
git clone $host:/$path $name
All of these clone a repository from somewhere, and put it in the
subdirectory $name from where you executed the command. $name may not
exist (it cannot even be an empty directory).
For there under default conditions your can push changes to where you
cloned it with the command:
and you fetch changes (that is fetch them into your repo without
modifying your working directory) with
and you can pull changes (that is fetch them into your repo and update
your working directory with the relevent changes to the branch you are
working on) with
>> 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.
> Maybe I will eventually become one of those people who can visualize
> in full color all of the sinuously intertwining directed acyclic
> graphs harmoniously dancing in and through my local and remote
> repositories and the repositories of others. Maybe not. But no one
> should have to know anything about how git works internally in order
> to track a couple of branches of Perl and submit their changes back.
> If they do, that's a fail.
It wont. Really. I know "trust me" isnt very helpful now, but thats
about all I can say.
Ive noticed that git raises a lot of hysteria. Thats partly because
the approach in many ways is kinda low level, meaning that yes, you
will have to learn something about how git works internally to use it
to its best advantage. Luckily there is not much to learn (despite the
appearances) and for simple purposes its almost identical to svn as
Tracking a couple of branches of perl is about as simple as :
git clone ....
Making some changes to one of the branches is about as simple as:
git checkout -b my_5.8.8 origin/v5.8.8
this creates a branch that you can work in which will automatically be
updated with changes from the branch v5.8.8 when you do a
the real v5.8.8 will also simultaneously exist as the branch
"origin/v5.8.8", (branches and tags in git follow the same naming
conventions as path/filespecs). Anytime you do a pull "origin/v5.8.8"
will be updated with the authoritative state from the repository your
cloned with, additionally any changes made since you created your
branch will be automatically merged into your working branch
'my_5.8.8' , when the user is done with their changes they publish
them somehow, either by using git-format-patch or by using "git push"
(if they are a committer). At that point practice varies. You can
delete your "my_5.8.8" as it is no longer necessary. Or you could keep
it. Doesnt much matter.
* Regarding learning git internals. I personally think learning the
git internals is about as complex as learning the command set of svn
or cvs or perforce. And the advantage is that once you learn it you
haven't just learned "Magic Recipies" you have learned the underlying
basis of how it works, from there you can be productive in figuring
out how other commands work and how difficult things that you could
never do in another vc can be done, usually relatively simply.
perl -Mre=debug -e "/just|another|perl|hacker/"