* Re: [PATCH v2] Do not show "diff --git" metainfo with --no-prefix
From: Junio C Hamano @ 2008-01-16 4:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, Chris Ortman, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.1.00.0801151902080.2806@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> We do not want to make it particularly easy for people to create
> mind-bogglingly stupid diff output.
Although the discussion was triggered by that Tortoise thing,
the RFC patch was not about helping that. That's a new feature
asked long after we went into rc freeze, and I am not interested
in discussing such a feature, especially when I am sick.
The only objective was to make sure that a patch that is not
kosher in git-apply's eyes is not marked with "diff --git";
otherwise, its output will confuse git-apply. As --no-prefix
will be a new feature in 1.5.4, we would be shipping with a
known-to-be-bad new feature that is --no-prefix, unless we do
something about it. Fixing that breakage was the sole
motivation behind my patch.
I think a reasonable short-term solution might be to disable any
git specific stuff (renames, rewrites, etc) when --no-prefix and
its friends are used, along with the patch you are commenting on
to remove " --git" from the header. That would at least make
sure that the --no-prefix feature is safe.
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Randal L. Schwartz @ 2008-01-16 3:50 UTC (permalink / raw)
To: Mike; +Cc: git
In-Reply-To: <478D79BD.7060006@talkingspider.com>
>>>>> "Mike" == Mike <fromlists@talkingspider.com> writes:
Mike> I'm learning git and I'm really annoyed that the .git directory lives in
Mike> the same directory as my code. I don't want it there for three reasons:
Mike> 1. My code lives on a development web server docroot, and I don't want
Mike> the .git repository to end up getting published to the live site by
Mike> accident. (I would imagine this would be a common need.)
Sounds like you need an installer... something that copies your repo into the
live location with things you don't want included left out, and all the
permissions and ownership correct.
Mike> 2. If I tar/gz my code and deliver it to a client, I don't want the .git
Mike> dir slipping into the tarball, allowing my client to be able to peruse
Mike> the history of what we did and when.
git archive --help
Mike> 3. The .git respository will get big, especially with binary files in
Mike> it, and I want it someplace with a lot of disk space. And I don't want
Mike> it to get tarred up when we migrate the site to a different server. (And
Mike> tar isn't aware of hard links is it? wonderful.)
An installer helps here too.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH v2] Do not show "diff --git" metainfo with --no-prefix
From: Linus Torvalds @ 2008-01-16 4:22 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Chris Ortman, Johannes Schindelin, git
In-Reply-To: <alpine.LNX.1.00.0801152256480.13593@iabervon.org>
On Tue, 15 Jan 2008, Daniel Barkalow wrote:
>
> I don't think --no-prefix is sufficient for submodules; it means that
> git-apply will accidentally remove exactly one level, but if your
> submodule is two directory levels down, it won't work, and having the
> effective prefixes be "gitweb" and "gitweb" is a little hackish. You'd
> really want to generate a -p1 patch whose root is shifted from the actual
> project root, not a -p0 patch or -p2 patch or something.
.. and this is *exactly* what
cd gitweb
git diff --src-prefix=a/gitweb/ --dst-prefix=b/gitweb/
would do (obviously people wouldn't do this by hand - it would be
something that is done by the "git diff" hitting a subproject).
The point is, Junio's patch suggestion tied that prefix together with the
"gitness" of the patch, so Junio's patch would have broken the above: git
would decide that since it's not a standard -p1 prefix, it's not a git
diff, so it shouldn't have "--git" in it.
That's why tying "--git" together with any prefix handling is wrong:
because it's a totally different issue. It's true that "git-apply" right
now doesn't understand these things, but assuming we want to teach
git-apply to apply to subprojects eventually (we do, don't we?) we'll
eventually have to teach it.
Linus
^ permalink raw reply
* Re: [RFC/PATCH] Remove repo-config
From: Junio C Hamano @ 2008-01-16 4:23 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <1200453554-14163-1-git-send-email-dpmcgee@gmail.com>
I do not think it is unreasonable to add repo-config to feature
removal schedule in 1.5.4 release notes. Perhaps something like...
diff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt
index 7d2a973..97a9bd9 100644
--- a/Documentation/RelNotes-1.5.4.txt
+++ b/Documentation/RelNotes-1.5.4.txt
@@ -46,6 +46,10 @@ Deprecation notices
and works for all transports; "git peek-remote" will be removed in
the future.
+ * "git repo-config", which was an old name for "git config" command,
+ has been supported without being advertised for a long time. The
+ next feature release will remove it.
+
* From v1.6.0, the repack.usedeltabaseoffset config option will default
to true, which will give denser packfiles (i.e. more efficient storage).
The downside is that git older than version 1.4.4 will not be able
^ permalink raw reply related
* Re: I don't want the .git directory next to my code.
From: David Symonds @ 2008-01-16 4:24 UTC (permalink / raw)
To: Mike; +Cc: Randal L. Schwartz, git
In-Reply-To: <478D82FA.2030404@talkingspider.com>
On Jan 16, 2008 3:07 PM, Mike <fromlists@talkingspider.com> wrote:
>
>
> I got:
>
> $ git archive --help
> No manual entry for git-archive
What's your git version ("git version")? Try just "man git-archive".
Dave.
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Mike @ 2008-01-16 4:24 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0801152305050.13593@iabervon.org>
Daniel Barkalow wrote:
> On Tue, 15 Jan 2008, Mike wrote:
>
>
> Generate your tarballs with "git archive", which will also make sure
that
> you don't accidentally include anything else that's not committed.
> Likewise for sending to the live site, probably.
Thanks please see my response to David about why this isn't good.
>
> You'll probably want to keep your history, which is what's in .git, when
> you migrate to a different server; that's kind of the point of using
> version control...
The git repositories should be on the development server, but should
*never* be on the live server. Anywhere, ever.
> export GIT_DIR=/somewhere-else.git
>
> Note that this only really works if you've only got one repository;
> there's no good way to have the repository information outside of the
> working directory and still have which repository you're using depend on
> which directory you're working in.
>
Thanks. Damn. We do have several repositories, (several sites). I'll
try Dan's soft link suggestion.
thanks
m
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Mike @ 2008-01-16 4:29 UTC (permalink / raw)
To: David Symonds; +Cc: Randal L. Schwartz, git
In-Reply-To: <ee77f5c20801152024s1a30e5d2o575b74fce2e9e1f1@mail.gmail.com>
$ man git-archive
No manual entry for git-archive
David Symonds wrote:
>
> What's your git version ("git version")? Try just "man git-archive".
Mike wrote at 10:13PM:
>
> git version 1.5.2.1
thanks
^ permalink raw reply
* Re: Samba NTFS error "Could not rename the lock file?"
From: Sean @ 2008-01-16 4:32 UTC (permalink / raw)
To: Mike; +Cc: git
In-Reply-To: <478D765B.90905@talkingspider.com>
On Tue, 15 Jan 2008 22:13:31 -0500
Mike <fromlists@talkingspider.com> wrote:
> git version 1.5.2.1
>
> I have my repository on a linux server and I'm trying to create a "git
> clone" on an NTFS samba mount. So for example:
Mike,
You may be running into an issue due to filename case insensitivity when
using NTFS over Samba. Either way, it would be helpful if you could test
with the latest stable Git (v1.5.3.8) since the error you're hitting has
been removed and the code replaced with different logic.
Sean.
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Sean @ 2008-01-16 4:36 UTC (permalink / raw)
To: Mike; +Cc: Randal L. Schwartz, git
In-Reply-To: <478D82FA.2030404@talkingspider.com>
On Tue, 15 Jan 2008 23:07:22 -0500
Mike <fromlists@talkingspider.com> wrote:
> > git archive --help
> >
> I got:
>
> $ git archive --help
> No manual entry for git-archive
>
> Did I install it wrong? I have CentOS 5, and I did:
>
> su
> yum install git
>
Yes, on Centos you probably need "yum install git-core" which installs all
the assorted pieces and dependencies of Git.
HTH,
Sean
^ permalink raw reply
* Re: [RFC/PATCH] Remove repo-config
From: Dan McGee @ 2008-01-16 4:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzles8j8.fsf@gitster.siamese.dyndns.org>
On 01/15/2008 10:23 PM, Junio C Hamano wrote:
> I do not think it is unreasonable to add repo-config to feature
> removal schedule in 1.5.4 release notes. Perhaps something like...
>
> + * "git repo-config", which was an old name for "git config" command,
> + has been supported without being advertised for a long time. The
> + next feature release will remove it.
> +
Seems fine to me. Does it need to be put in command-list.txt for the time being too, or what all is that file used for? Sorry I am not familiar.
Something like:
git-repo-config ancillarymanipulators deprecated
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Daniel Barkalow @ 2008-01-16 4:44 UTC (permalink / raw)
To: Mike; +Cc: David Symonds, git
In-Reply-To: <478D85A9.6050807@talkingspider.com>
On Tue, 15 Jan 2008, Mike wrote:
> David Symonds wrote:
> > On Jan 16, 2008 2:27 PM, Mike <fromlists@talkingspider.com> wrote:
> > > 2. If I tar/gz my code and deliver it to a client, I don't want the .git
> > > dir slipping into the tarball, allowing my client to be able to peruse
> > > the history of what we did and when.
> >
> > Use git-archive.
> >
>
> Thanks but this isn't sufficient. If we have one directory of our web root in
> a git repository, say docroot/php, and we tar up docroot, it will include
> php/.git. We don't want that. We would have to go out of our way to avoid
> the .git directory. The point is, we don't want anything in docroot that
> shouldn't be made live.
I don't know about you, but my source directories get lots of other
junk: editor backup files, half-written scripts, debugging output, etc.
Furthermore, there's the issue of whether you can accidentally distribute
something you haven't added to your version control yet and therefore
can't reproduce. It's just a lot cleaner to deploy and distribute out of
the version control system instead of out of a working directory.
I don't know why you don't seem to have git-archive (or its manpage); it's
in the version you have. Maybe it didn't get into the deb-generation files
at the time? You might have git-tar-tree instead, though.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Luke Lu @ 2008-01-16 4:55 UTC (permalink / raw)
To: Mike; +Cc: David Symonds, git
In-Reply-To: <478D85A9.6050807@talkingspider.com>
On Jan 15, 2008, at 8:18 PM, Mike wrote:
>
> David Symonds wrote:
>> On Jan 16, 2008 2:27 PM, Mike <fromlists@talkingspider.com> wrote:
>>> 2. If I tar/gz my code and deliver it to a client, I don't want
>>> the .git
>>> dir slipping into the tarball, allowing my client to be able to
>>> peruse
>>> the history of what we did and when.
>> Use git-archive.
>
> Thanks but this isn't sufficient. If we have one directory of our
> web root in a git repository, say docroot/php, and we tar up
> docroot, it will include php/.git. We don't want that. We would
> have to go out of our way to avoid the .git directory. The point
> is, we don't want anything in docroot that shouldn't be made live.
git-archive generates an archive file *without* the .git directory.
From git-archive(1):
git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ &&
tar xf -)
Create a tar archive that contains the contents of the
latest
commit on the current branch, and extracts it in /var/
tmp/junk
directory.
git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >
git-1.4.0.tar.gz
Create a compressed tarball for v1.4.0 release.
git archive --format=tar --prefix=git-1.4.0/ v1.4.0^{tree} | gzip
>git-1.4.0.tar.gz
Create a compressed tarball for v1.4.0 release, but
without a
global extended pax header.
git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ >
git-1.4.0-docs.zip
Put everything in the current head's Documentation/
directory
into git-1.4.0-docs.zip, with the prefix git-docs/.
IMHO, git export is probably a better name for the command. git-
archive sounds like backup everything associated with git.
__Luke
^ permalink raw reply
* [PATCH] Documentation: fix and clarify grammar in git-merge docs.
From: dave @ 2008-01-16 5:16 UTC (permalink / raw)
To: git; +Cc: Dave Peticolas
From: Dave Peticolas <dave@krondo.com>
Signed-off-by: Dave Peticolas <dave@krondo.com>
---
Documentation/git-merge.txt | 25 ++++++++++++-------------
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index ed3a924..abf63fe 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -74,19 +74,18 @@ it happens. In other words, `git-diff --cached HEAD` must
report no changes.
[NOTE]
-This is a bit of lie. In certain special cases, your index are
-allowed to be different from the tree of `HEAD` commit. The most
-notable case is when your `HEAD` commit is already ahead of what
-is being merged, in which case your index can have arbitrary
-difference from your `HEAD` commit. Otherwise, your index entries
-are allowed have differences from your `HEAD` commit that match
-the result of trivial merge (e.g. you received the same patch
-from external source to produce the same result as what you are
-merging). For example, if a path did not exist in the common
-ancestor and your head commit but exists in the tree you are
-merging into your repository, and if you already happen to have
-that path exactly in your index, the merge does not have to
-fail.
+This is a bit of a lie. In certain special cases, your index is
+allowed to be different from the tree of the `HEAD` commit. The
+most notable case is when your `HEAD` commit is already ahead of
+what is being merged, in which case your index can have arbitrary
+differences from your `HEAD` commit. Also, your index entries may
+have differences from your `HEAD` commit that match the result of
+a trivial merge (e.g., you received the same patch from an external
+source to produce the same result as what you are merging). For example,
+if a path did not exist in the common ancestor and your head commit
+but exists in the tree you are merging into your repository, and if
+you already happen to have that path exactly in your index, the merge
+does not have to fail.
Otherwise, merge will refuse to do any harm to your repository
(that is, it may fetch the objects from remote, and it may even
--
1.5.3.8
^ permalink raw reply related
* Re: I don't want the .git directory next to my code.
From: Neil Macneale @ 2008-01-16 5:27 UTC (permalink / raw)
To: Mike; +Cc: git
In-Reply-To: <478D82FA.2030404@talkingspider.com>
Mike wrote:
> .... And as for permissions and ownership, rsync takes care of that.
Perhaps "rsync --exclude *.git"?
It seems to me that you are asking git to be your deployment software,
which is a bad fit.
Cheers,
Neil
^ permalink raw reply
* Re: Git Gui: initial french translation: fr.po
From: Shawn O. Pearce @ 2008-01-16 5:59 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, git
In-Reply-To: <20080115062426.8fd03852.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> wrote:
> Here are some of the choices made to translate Git Gui to french:
Thanks, this will be in git-gui 0.9.2. GNU msgfmt caught a minor
bug in the translation. The translation on line 466 needed to have
an LF, as the original text ended with an LF. I inserted it when
I applied the patch.
> I just attached the file instead of sending the patch because I fear
> some encoding breakages.
Next time could you please use a proper Git patch (git-format-patch)
but attach the .patch file to your email. Its far easier for me
to apply.
I don't mind applying translation patches sent as attachments
(as it does help avoid mangling) but I know many folks on the list
would still rather see them inline whenever possible.
--
Shawn.
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Mike @ 2008-01-16 6:00 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <478D8062.3090506@gmail.com>
Dan McGee wrote:
> On 01/15/2008 09:27 PM, Mike wrote:
>> How do I make the repository dir live somewhere else, the hell away from
>> my code? Thanks
>
> mv .git <location to move to>
> ln -s <location moved to> .git
>
> Did you try this before you sent your email?
No, good idea. But it didn't work. When I git commit -a, I get "fatal:
Not a git repository"
(And also even if that worked, it wouldn't work on an NTFS partiton,
right...)
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Mike @ 2008-01-16 6:09 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <478D9D60.9070807@talkingspider.com>
Mike wrote:
>
> No, good idea. But it didn't work. When I git commit -a, I get "fatal:
> Not a git repository"
>
> (And also even if that worked, it wouldn't work on an NTFS partiton,
> right...)
Wait, it worked! thanks!
Hmm although some of our code is (necessarily) on an NTFS partition... hmm..
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Mike Krier @ 2008-01-16 6:07 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <478D9D60.9070807@talkingspider.com>
Mike wrote:
>
> No, good idea. But it didn't work. When I git commit -a, I get "fatal:
> Not a git repository"
>
> (And also even if that worked, it wouldn't work on an NTFS partiton,
> right...)
Wait, it worked! thanks!
Hmm although some of our code is (necessarily) on an NTFS partition... hmm..
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Miles Bader @ 2008-01-11 3:03 UTC (permalink / raw)
To: public-Johannes.Schindelin-Mmb7MZpHnFY
Cc: Peter Karlsson, Junio C Hamano, Linus Torvalds, J. Bruce Fields,
Steffen Prohaska, Robin Rosenberg, Jeff King, Git Mailing List,
msysGit
In-Reply-To: <alpine.LSU.1.00.0801101155140.31053@racer.site>
Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org>
writes:
>> Windows has CRLF line endings. Just deal with it.
>
> No, I will not just deal with it.
Didn't Apple change their line-ending convention, moving to LF EOL with OSX?
-Miles
--
"I distrust a research person who is always obviously busy on a task."
--Robert Frosch, VP, GM Research
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Miles Bader @ 2008-01-11 3:03 UTC (permalink / raw)
To: public-Johannes.Schindelin-Mmb7MZpHnFY
Cc: Peter Karlsson, Junio C Hamano, Linus Torvalds, J. Bruce Fields,
Steffen Prohaska, Robin Rosenberg, Jeff King, Git Mailing List,
msysGit
In-Reply-To: <alpine.LSU.1.00.0801101155140.31053@racer.site>
Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org>
writes:
>> Windows has CRLF line endings. Just deal with it.
>
> No, I will not just deal with it.
Didn't Apple change their line-ending convention, moving to LF EOL with OSX?
-Miles
--
"I distrust a research person who is always obviously busy on a task."
--Robert Frosch, VP, GM Research
^ permalink raw reply
* Re: [PATCH] git-gui/Makefile - Don't convert gg_libdir on Cygwin
From: Shawn O. Pearce @ 2008-01-16 6:40 UTC (permalink / raw)
To: Mark Levedahl; +Cc: git
In-Reply-To: <1199572355-2720-1-git-send-email-mdl123@verizon.net>
Mark Levedahl <mdl123@verizon.net> wrote:
> gg_libdir was converted to an absolute Windows path as a remnant of
> logic to check for relative / absolute location of libraries, but that
> does not work on Cygwin. Converting gg_libdir to a Windows path has the
> nasty side-effect that it cannot be prefixed with $DESTDIR, and this
> precludes installing to a staging directory. So, don't convert it.
Hmmph. That bites.
> ifeq ($(uname_O),Cygwin)
> GITGUI_SCRIPT := `cygpath --windows --absolute "$(GITGUI_SCRIPT)"`
> - gg_libdir := $(shell cygpath --windows --absolute "$(gg_libdir)")
> else
The reason I'm doing the UNIX->Windows conversion here is I run
git-gui on a pure Win32 Tcl/Tk build, one that is a lot more recent
than the version that ships as a Cygwin package. The pure Win32
Tcl/Tk cannot read UNIX paths, so I cannot allow libdir to be a
UNIX path in that case.
Now earlier we used to use relative paths on Windows to find the
libdir at runtime, but we don't do that anymore either, and I'm
not really sure why. In theory it should still work to make it
relative when possible, and then my installation with the more
native Tcl/Tk would work just fine.
I guess I'm willing to apply your patch and carry the reverse of your
patch as a local-only hack for my needs, but I wonder if anyone else
is also using git-gui on Cygwin with a pure Win32 Tcl/Tk build...
--
Shawn.
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Miles Bader @ 2008-01-16 6:41 UTC (permalink / raw)
To: Jan Hudec; +Cc: Chris Ortman, Johannes Schindelin, git
In-Reply-To: <20080115201530.GA17239@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
> Git currently uses C, shell, perl and tcl/tk. There would probably be some
> resistance to adding more dependencies, but that would not apply to the
> contrib directory (so useful things written in something else are likely to
> end up there).
Is tcl/tk restricted to the GUI stuff?
-Miles
--
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Shawn O. Pearce @ 2008-01-16 6:54 UTC (permalink / raw)
To: Miles Bader; +Cc: Jan Hudec, Chris Ortman, Johannes Schindelin, git
In-Reply-To: <buo3asymfvh.fsf@dhapc248.dev.necel.com>
Miles Bader <miles.bader@necel.com> wrote:
> Jan Hudec <bulb@ucw.cz> writes:
> > Git currently uses C, shell, perl and tcl/tk. There would probably be some
> > resistance to adding more dependencies, but that would not apply to the
> > contrib directory (so useful things written in something else are likely to
> > end up there).
>
> Is tcl/tk restricted to the GUI stuff?
Yes. Currently the only users of Tcl (or Tk) within the core
Git distribution is gitk and git-gui.
--
Shawn.
^ permalink raw reply
* Re: Git Gui: initial french translation: fr.po
From: Christian Couder @ 2008-01-16 7:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio Hamano, Miklos Vajna, git
In-Reply-To: <20080116055920.GK24004@spearce.org>
Le mercredi 16 janvier 2008, Shawn O. Pearce a écrit :
> Christian Couder <chriscool@tuxfamily.org> wrote:
> > Here are some of the choices made to translate Git Gui to french:
>
> Thanks, this will be in git-gui 0.9.2. GNU msgfmt caught a minor
> bug in the translation. The translation on line 466 needed to have
> an LF, as the original text ended with an LF. I inserted it when
> I applied the patch.
Thanks.
> > I just attached the file instead of sending the patch because I fear
> > some encoding breakages.
>
> Next time could you please use a proper Git patch (git-format-patch)
> but attach the .patch file to your email. Its far easier for me
> to apply.
>
> I don't mind applying translation patches sent as attachments
> (as it does help avoid mangling) but I know many folks on the list
> would still rather see them inline whenever possible.
I pushed them to the mob branch of git-gui-i18n.git a few hours ago too as
Miklos suggested.
I will send them inline next time too.
Thanks,
Christian.
^ permalink raw reply
* [PATCH] Git Gui: add french glossary: glossary/fr.po
From: Christian Couder @ 2008-01-16 7:19 UTC (permalink / raw)
To: Shawn O. Pearce, Junio Hamano, Miklos Vajna; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
po/glossary/fr.po | 166 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 166 insertions(+), 0 deletions(-)
create mode 100644 po/glossary/fr.po
Here is another patch I pushed to the mob branch of git-gui-i18n.git.
Thanks.
diff --git a/po/glossary/fr.po b/po/glossary/fr.po
new file mode 100644
index 0000000..27c006a
--- /dev/null
+++ b/po/glossary/fr.po
@@ -0,0 +1,166 @@
+# translation of fr.po to French
+# Translation of git-gui glossary to French
+# Copyright (C) 2008 Shawn Pearce, et al.
+#
+# Christian Couder <chriscool@tuxfamily.org>, 2008.
+msgid ""
+msgstr ""
+"Project-Id-Version: fr\n"
+"POT-Creation-Date: 2008-01-15 21:04+0100\n"
+"PO-Revision-Date: 2008-01-15 21:17+0100\n"
+"Last-Translator: Christian Couder <chriscool@tuxfamily.org>\n"
+"Language-Team: French\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: KBabel 1.11.4\n"
+"Plural-Forms: nplurals=2; plural=(n > 1);\n"
+
+#. "English Definition (Dear translator: This file will never be visible to the user! It should only serve as a tool for you, the translator. Nothing more.)"
+msgid "English Term (Dear translator: This file will never be visible to the user!)"
+msgstr ""
+
+#. ""
+msgid "amend"
+msgstr "corriger"
+
+#. ""
+msgid "annotate"
+msgstr "annoter"
+
+#. "A 'branch' is an active line of development."
+msgid "branch [noun]"
+msgstr "branche"
+
+#. ""
+msgid "branch [verb]"
+msgstr "créer une branche"
+
+#. ""
+msgid "checkout [noun]"
+msgstr "emprunt"
+
+#. "The action of updating the working tree to a revision which was stored in the object database."
+msgid "checkout [verb]"
+msgstr "emprunter"
+
+#. ""
+msgid "clone [verb]"
+msgstr "cloner"
+
+#. "A single point in the git history."
+msgid "commit [noun]"
+msgstr "commit"
+
+#. "The action of storing a new snapshot of the project's state in the git history."
+msgid "commit [verb]"
+msgstr "commiter"
+
+#. ""
+msgid "diff [noun]"
+msgstr "différence"
+
+#. ""
+msgid "diff [verb]"
+msgstr "comparer"
+
+#. "A fast-forward is a special type of merge where you have a revision and you are merging another branch's changes that happen to be a descendant of what you have."
+msgid "fast forward merge"
+msgstr "fusion par avance rapide"
+
+#. "Fetching a branch means to get the branch's head from a remote repository, to find out which objects are missing from the local object database, and to get them, too."
+msgid "fetch"
+msgstr "récupérer"
+
+#. "A collection of files. The index is a stored version of your working tree."
+msgid "index (in git-gui: staging area)"
+msgstr "pré-commit"
+
+#. "A successful merge results in the creation of a new commit representing the result of the merge."
+msgid "merge [noun]"
+msgstr "fusion"
+
+#. "To bring the contents of another branch into the current branch."
+msgid "merge [verb]"
+msgstr "fusionner"
+
+#. ""
+msgid "message"
+msgstr "message"
+
+#. "Deletes all stale tracking branches under <name>. These stale branches have already been removed from the remote repository referenced by <name>, but are still locally available in 'remotes/<name>'."
+msgid "prune"
+msgstr "nettoyer"
+
+#. "Pulling a branch means to fetch it and merge it."
+msgid "pull"
+msgstr "tirer"
+
+#. "Pushing a branch means to get the branch's head ref from a remote repository, and ... (well, can someone please explain it for mere mortals?)"
+msgid "push"
+msgstr "pousser"
+
+#. ""
+msgid "redo"
+msgstr "refaire"
+
+#. "An other repository ('remote'). One might have a set of remotes whose branches one tracks."
+msgid "remote"
+msgstr "référentiel distant"
+
+#. "A collection of refs (?) together with an object database containing all objects which are reachable from the refs... (oops, you've lost me here. Again, please an explanation for mere mortals?)"
+msgid "repository"
+msgstr "référentiel"
+
+#. ""
+msgid "reset"
+msgstr "réinitialiser"
+
+#. ""
+msgid "revert"
+msgstr "inverser"
+
+#. "A particular state of files and directories which was stored in the object database."
+msgid "revision"
+msgstr "révision"
+
+#. ""
+msgid "sign off"
+msgstr "signer"
+
+#. ""
+msgid "staging area"
+msgstr "pré-commit"
+
+#. ""
+msgid "status"
+msgstr "état"
+
+#. "A ref pointing to a tag or commit object"
+msgid "tag [noun]"
+msgstr "marque"
+
+#. ""
+msgid "tag [verb]"
+msgstr "marquer"
+
+#. "A regular git branch that is used to follow changes from another repository."
+msgid "tracking branch"
+msgstr "branche de suivi"
+
+#. ""
+msgid "undo"
+msgstr "défaire"
+
+#. ""
+msgid "update"
+msgstr "mise à jour"
+
+#. ""
+msgid "verify"
+msgstr "vérifier"
+
+#. "The tree of actual checked out files."
+msgid "working copy, working tree"
+msgstr "copie de travail, arborescence de travail"
+
--
1.5.4.rc2.38.gd6da3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox