Current version: 2.10.2
Example workflow:
* I would do a global substitution across a source tree, e.g. `perl -i
-pe 's{OLD_FOO\(x\)}{NEW_BAR(x, 0)}' *.c`
* Using `git add -p`, I would verify each of the substitutions that they
make sense in their respective locations, and, based on that,
On Thu, 20 Feb 2014 12:06:17, Michael Haggerty wrote:
>On 02/19/2014 11:58 PM, Jan Engelhardt wrote:
>>
>> Looking at it from one more angle, `git fetch r --tags` and
>> `git push r --tags` is now no longer symmetric :(
>
>I'm glad you brought this up, bec
On Thursday 2014-02-20 00:40, Junio C Hamano wrote:
>On Wed, Feb 19, 2014 at 2:58 PM, Jan Engelhardt wrote:
> Looking at it from one more angle, `git fetch r --tags` and
>`git push r --tags` is now no longer symmetric :(
>
>
>I would have loved to hear such comments _duri
On Wednesday 2014-02-19 21:01, Junio C Hamano wrote:
>Jan Engelhardt writes:
>> The release notes for 1.9.0 read:
>>
>>> * The "--tags" option to "git fetch" no longer tells the command to
>>> fetch _only_ the tags. It instead fetches tag
Greetings.
The release notes for 1.9.0 read:
> * The "--tags" option to "git fetch" no longer tells the command to
> fetch _only_ the tags. It instead fetches tags _in addition to_
> what are fetched by the same command line without the option.
I think the release notes should also say -- l
On Thursday 2013-05-23 20:16, Bernhard R. Link wrote:
>>
>> Not sure if German users would know what "hunk" means, in case we
>> leave it untranslated. And I'm not sure if I would understand "Kontext".
>> I tend to leave it untranslated.
>
>Anyone found a German translation of the Patch manpage? T
On Wednesday 2013-05-22 17:52, Holger Hellmuth (IKS) wrote:
>>
>> Not sure if German users would know what "hunk" means, in case we
>> leave it untranslated. And I'm not sure if I would understand "Kontext".
>> I tend to leave it untranslated.
>
> I don't think "Bereich" is a bad choice. As "hunk"
On Wednesday 2013-05-15 17:31, Holger Hellmuth (IKS) wrote:
>>>
>>> I actually had the '-' in there too until I tried to look up "Zip-Datei"
>>> in the Duden. While I don't get the leading '.' (I cannot remember having
>>> seen that anywhere, AFAIK the file extensions are always used without the
>
On Wednesday 2013-05-15 14:27, Jens Lehmann wrote:
>>
>> While it's spoken Packdatei, the way to actually write it is
>> .pack-Datei or ".pack"-Datei.
>
>I actually had the '-' in there too until I tried to look up "Zip-Datei"
>in the Duden. While I don't get the leading '.' (I cannot remember hav
On Wednesday 2013-05-15 13:26, Jens Lehmann wrote:
>
>Hmm, I rather tend towards using "Repository" instead of "Archiv" too, as
>"Archiv" can mean anything from a tar-file to a git repository
It's exactly the reasoning I made in my git-glossary.txt sample
(of which the reasoning apparently has no
On Monday 2013-05-13 20:57, Ralph Haußmann wrote:
>
>There is a glossary for the pro-git book (see [2]) but it is not up-to-date
>and it is also mixed. Therefor I would like to avoid using this glossary.
>I like the idea of a shared wiki (git de.po and pro-git).
>I suggest a single page as over
On Monday 2013-05-13 14:54, Thomas Rast wrote:
>As I am sure you are all aware, there are two main religions as to how
>one can translate technical material into German: leave the technical
>terms mostly in English, or translate them to an appropriate
>corresponding word. I'll denote them G+E and
On Tuesday 2012-10-02 10:26, Johannes Sixt wrote:
>
>Note that git commit -m A --allow-empty *DID* create a commit. Only, that
>it received the same name (SHA1) as the commit you created before it
>because it had the exact same contents (files, parents, author, committer,
>and timestamps). Obvious
On Wednesday 2012-10-03 21:03, Junio C Hamano wrote:
>
>I said that "git reset --keep" started out as an ugly workaround for
>the lack of "git checkout -B $current_branch". Now we have it, so
>we can afford to make "reset --keep" less prominently advertised in
>our tool set. As I already said ba
On Wednesday 2012-09-26 18:36, Ronan Bignaux wrote:
>I wrote this little patch to add a restrict option to bind only to a
>specific network interface.
>
>I'd not deal with --inetd since there are some bugs in xinetd with ipv6
>( and no more maintener ) , systemd/upstart are also Linux centric and
On Monday 2012-09-24 14:57, Michael J Gruber wrote:
>Currently, all paths in the config file are subject to tilde expansion
>for user paths while the argument to --git-dir is not expanded, and
>neither are paths in the environment such as GIT_DIR. From the user
>perspective, though, the two comma
On Sunday 2012-09-23 17:04, Ralf Thielow wrote:
>>
>> Original:
>> ... and I wonder if you are in the middle of another rebase.
>>
>> German git translation:
>> ... und es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist.
>
>We try to avoid translating terms like "I wonder if.." and sim
On Saturday 2012-09-15 19:08, Junio C Hamano wrote:
>
>If you plan to use "git send-email" to send the final results out,
>you should consider "git send-email" as your "MUA" in the quoted
>paragraph. And that will be very platform independent viewpoint to
>see things from.
>
>"git format-patch -o
On Wednesday 2012-09-19 19:54, Joachim Schmitz wrote:
>> From: Jan Engelhardt [mailto:jeng...@inai.de]
>> Sent: Wednesday, September 19, 2012 7:48 PM
>> To: Joachim Schmitz
>> Cc: 'Junio C Hamano'; git@vger.kernel.org
>> Subject: Re: [PATCH] Port to HP No
On Wednesday 2012-09-19 12:03, Joachim Schmitz wrote:
>+#ifdef NO_INTPTR_T
>+/*
>+ * On I16LP32, ILP32 and LP64 "long" is the save bet, however
>+ * on LLP86, IL33LLP64 and P64 it needs to be "long long",
>+ * while on IP16 and IP16L32 it is "int" (resp. "short")
>+ * Size needs to match (or excee
On Friday 2012-08-24 22:43, Joachim Schmitz wrote:
>
>> By the way, is "int" wide enough [for intptr_t/uintptr_t],
>> or should they be "long"?
>
>int and long have the same size, 32-bit, here on NonStop.
>But we do have 64-bit types too. Not sure which to take though.
intptr_t is supposed to hol
On Saturday 2012-09-15 15:24, Yi, EungJun wrote:
>"bee-lob" or "bla:b"?
http://en.wiktionary.org/wiki/blob
BLOB as a Binary Large OBject reeks of a retronym.
>I guess "bee-lob" is correct if it means binary large object. But I'm
>not sure because gitglossary does not tell me about that.
--
To u
On Saturday 2012-09-08 20:59, Junio C Hamano wrote:
>> diff --git a/daemon.c b/daemon.c
>> index 4602b46..eaf08c2 100644
>> --- a/daemon.c
>> +++ b/daemon.c
>> @@ -1,3 +1,4 @@
>> +#include
>> #include "cache.h"
>> #include "pkt-line.h"
>> #include "exec_cmd.h"
>
>Platform agnostic parts of the
On Saturday 2012-09-08 20:57, Junio C Hamano wrote:
>Please don't throw a pull request for a patch whose worth hasn't
>been justified in a discussion on the list. Thanks.
Let me postulate that people like to get cover letters with the
git:// URL so they can fetch+look at it, a diffstat and short
: restore getpeername(0,...) use (2012-09-08 19:00:35 +0200)
Jan Engelhardt (1):
daemon: restore getpeername(0,...) use
daemon.c | 55 +++
1 file changed, 51 insertions(+), 4
he code in execute()
and subfunctions can stay as-is.
Signed-off-by: Jan Engelhardt
---
daemon.c | 55 +++
1 file changed, 51 insertions(+), 4 deletions(-)
diff --git a/daemon.c b/daemon.c
index 4602b46..eaf08c2 100644
--- a/daemon.c
+++ b/daemon
On Tuesday 2012-08-14 17:52, Joachim Schmitz wrote:
> @@ -98,6 +99,11 @@
> #include
> #include
> #include
>+#ifdef __TANDEM
>+# include /* for strcasecmp() */
>+ typedef int intptr_t; /* not "int *" ?!? */
>+ typedef unsigned int uintptr_t; /* not "unsigned int *" ?!? */
Of course not. intp
translation.
Patch is fine from a translation POV;
but I wonder where my contributions had gone.
Ævar, were they ever merged?
commit 0c3db7e983a58f53cbd468e11937750e155de179
Author: Jan Engelhardt
Date: Thu Oct 7 20:52:26 2010 +0200
po/de.po: complete German translation
On Monday 2012-07-30 16:58, Mojca Miklavec wrote:
>>
>> COLUMNS=YourNumber git log YourArgs > YourFile
>
>Wow, perfect, thank you very much. Setting COLUMNS=200 (the high
>number just in case) solved the problem.
200 ought to be enough for everybody? PATH_MAX is never enough...
--
To unsubscribe f
On Monday 2012-07-30 14:11, Thomas Badie wrote:
>Hi all,
>
>When I should fixup or squash a commit, I nearly never
>remember how to get the sha1 of the commit I want to fixup.
>Because sometimes HEAD~n is not enough, I make `git log`,
>copy the sha1 of the right commit and paste it in my git
>fixu
30 matches
Mail list logo
