New Git repository

Raphael Hertzog · External Since: May 28, 2005 Posts: 461

Hello everybody,

I just finished creating the git repository with as much history as I
could reasonably gather (old tarballs from Ian, CVS history, tarballs of
uploads during the Arch period, and finally SVN history).

http://git.debian.org/?p=dpkg/dpkg.git;a=summary

I've already setup git commit notices that are sent out whenever someone
pushes stuff in the repository. I had to hack the post-receive-email hook
script provided by git. I shall test it soon with a small commit. Smile

For committers:
---------------

You get read/write access if you use the ssh url:
$ git clone ssh://git.debian.org/git/dpkg/dpkg.git

For anonymous access:
---------------------
$ git clone git://git.debian.org/git/dpkg/dpkg.git

Basic commands:
---------------

Doing changes and committing and pushing:
$ cd dpkg.git
$ vi file
$ git add file
$ git commit
$ git push

Getting latest changes:
$ git pull

This works well as long as you work only in the master branch (equivalent
of "trunk" in git world). For more advanced usage, you'll have to read
some git documentation. Smile

Try out
-------
There's a "sandbox" repository at ssh://git.debian.org/git/dpkg/test.git
if you want to play and try out because you're not yet familiar with git.

Future
------
The repository is up-to-date with the SVN, so it would be best if we would
switch directly so that I don't have to reimport the newer commits in git. Smile

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Raphael Hertzog · External Since: May 28, 2005 Posts: 461

Hi,

On Tue, 24 Jul 2007, Raphael Hertzog wrote:
> I just finished creating the git repository with as much history as I
> could reasonably gather (old tarballs from Ian, CVS history, tarballs of
> uploads during the Arch period, and finally SVN history).
>
> http://git.debian.org/?p=dpkg/dpkg.git;a=summary

I just made some crude last-minute updates in the tags. So if you have
already cloned the repository, the easiest is to scratch it and reclone
it.

> Future
> ------
> The repository is up-to-date with the SVN, so it would be best if we would
> switch directly so that I don't have to reimport the newer commits in git. Smile

Commits to SVN have been blocked with a pre-commit script. Guillem made
his first commit in the Git tree, so it looks like the Git repository is
official now. Smile

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Peter Karlsson · External Since: Jul 27, 2005 Posts: 20

Raphael Hertzog:

> I just finished creating the git repository with as much history as I
> could reasonably gather (old tarballs from Ian, CVS history, tarballs
> of uploads during the Arch period, and finally SVN history).

How does this change work relating to how translations are done, for
those of us who had direct commit access to the subversion repository?

--
\\// Peter - http://www.softwolves.pp.se/

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Raphael Hertzog · External Since: May 28, 2005 Posts: 461

Hi,

On Fri, 27 Jul 2007, Peter Karlsson wrote:
> Raphael Hertzog:
>
> > I just finished creating the git repository with as much history as I
> > could reasonably gather (old tarballs from Ian, CVS history, tarballs
> > of uploads during the Arch period, and finally SVN history).
>
> How does this change work relating to how translations are done, for
> those of us who had direct commit access to the subversion repository?

I wanted to discuss this topic Christian Perrier, it's not 100% clear yet.
Git is probably a bit more difficult to handle for people not familiar
with distributed revision control system.

Those who can learn git, definitely should do so and integrate their work
directly. There's the sandbox repository precisely so that you can make
some tries and learn.

Ideally we'll come up with some documentation for translators. It will
probably be integrated in this wiki page:
http://wiki.debian.org/Teams/Dpkg/GitUsage

In the mean time, feel free to send patches and to ask questions
concerning git usage. Just don't mess up with the main repository if
you're not yet confident with Git.

There are various possible workflows:
- people can push translation updates in the main repository directly
- we can have a single repository dedicated to translators and the
developers will regularly pull updates there (this reduce the chance
that a translator accidentally mess up the main repository)
- translators only use git to get the latest tree and send patches created
by git-format-patch (and a dpkg developer uses git-am to apply them
quickly and efficiently)
- ...

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Peter Karlsson · External Since: Jul 27, 2005 Posts: 20

Christian Perrier:

> If we commit to the same branch all the time, I don't think so. That means
> using 3 commands for checkoutupdate/commit and nothing more.

Yeah, if git is set up with a central repository, it should be just like
cvs/svn (with the extra bonus that I can do incremental commits locally
while I'm updating and just push everything when I'm done).

> The important point for translators is having a solid and very easy to
> identify reference. This is indeed why distributed development makes our
> life hard:

That depends on how often the various developer branches are merged, I
think, and how difficult it is to identify the "master" branch that will go
into production. It should also be easy to update and regenerate the .pot
and .po files to make it easy to keep track of updates (I'm not quite sure
how to do it with the dpkg repositories yet).

> But, of course, the final freeze MUST include a string freeze.

Indeed.

--
\\// Peter - http://www.softwolves.pp.se/

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Peter Karlsson · External Since: Jul 27, 2005 Posts: 20

Peter Karlsson:

> Yeah, if git is set up with a central repository, it should be just like
> cvs/svn (with the extra bonus that I can do incremental commits locally
> while I'm updating and just push everything when I'm done).

This seems to work fine. I did all my changes on a local branch in my cloned
repository, then updated from the remote, merged [1] and pushed my changes.
They now all show up in the web interface at git.debian.org, complete with
the history of when I did the partial commits that I did while working on
the translation.

[1] It seems that the "git merge branchname" that is listed in all the
tutorials doesn't work, at least not with the version of git in
Etch. I had to use a more complicated command line on the form
"git merge 'commit message' master branchname".

--
\\// Peter - http://www.softwolves.pp.se/

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Raphael Hertzog · External Since: May 28, 2005 Posts: 461

On Tue, 31 Jul 2007, Peter Karlsson wrote:
> [1] It seems that the "git merge branchname" that is listed in all the
> tutorials doesn't work, at least not with the version of git in
> Etch. I had to use a more complicated command line on the form
> "git merge 'commit message' master branchname".

Right, it's highly advisabe to use "git 1.5.x" which simplified many
command lines and is thus less error-prone.

There's an etch backports in www.backports.org (we have that installed on
Alioth).

Git 1.5 also sets up some standard configuration during the clone to
keep the remote bracnh distinct so that you can directly work in the local
"master" branch and so that any merge is automatically done with the
parent branch.

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org