RFE: Discard hunks during `git add -p`
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,
answer "y" or "n" to the interactive prompting to stage good hunks.
* When done with add-p, I would commit the so-staged hunks,
and then use `git reset --hard` to discard all changes that were
not acknowledged during add-p.
Being able to discard hunks (reset working copy to index contents)
during add-p would alleviate the (quite broad) hard reset.
Similar approach:
* global substitution
* Using `git add -p`, some hunks may warrant some more editing, doable
with the "e" command. The index would be updated with the extra
change, but the working copy be left as-is.
* When rerunning `git add -p` in such a state, a difference is shown
again for such edited spots, which I would like to discard (bring
the working copy into sync with index).
Re: release-notes could be clearer on git-fetch changes
On Thursday 2014-02-20 00:40, Junio C Hamano wrote: On Wed, Feb 19, 2014 at 2:58 PM, Jan Engelhardt jeng...@inai.de 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 _during_ the discussion, not after a release is made, Perhaps, though I only became aware of this change because LWN reported about git 1.9.0. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: release-notes could be clearer on git-fetch changes
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, because I didn't really think about whether git push would need changes parallel to those in git fetch. I use git push in very conservative ways, so I don't know its ins and outs. What scenarios do you find asymmetric? Were they more symmetric before? `git push r --tags` pushes only tags, and `git fetch r --tags` only fetched tags. Starting from 1.9.0, `git fetch r --tags`, according to the release summary, changed to tags and other things. That's the asymmetric change I find. It is, as you say, undesirable to have `git push r --tags` push more than tags, which is why I am objecting (acknowledging it's after-the-fact) that the change to git-fetch was so-so. A new option `git fetch r --only-tags` could remedy the hard-to-remember syntax `git fetch r refs/tags/*:refs/tags/*`, though it would not fix the asymmetry. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
release-notes could be clearer on git-fetch changes
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 -- like it was done extensively for git add -- how to get back the old behavior (perhaps through now-different commands). thanks, Jan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
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? Translating the
English word-play here, I'd suggest Block or Patch-Block.
Hunk is like a chunk, and the dictionary offers some fun too:
dickes Stück; Brocken {m} :: chunk
(Holz)klotz {m} :: chunk (of wood)
and that is what many patches feel like indeed, especially
when they generate rejects :)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
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 is not a word with special meaning in cvs and not used in any commands I don't see a lot of reasons to keep it in english. hunk is chunk without a c, but otherwise with pretty much the same meaning. Especially when it rejects :) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
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 not made it into ralfth's latest wiki, but that's the most essential part of a glossary IMHO). but I believe Packdatei would be a much better translation (especially as the translation of pack(verb) is packen). I find it natural that a file with the extension .pack is named Packdatei While it's spoken Packdatei, the way to actually write it is .pack-Datei or .pack-Datei. extension .zip is a Zipdatei (known by the Duden) If that's how Duden specifies it, it's time to call wrong upon Duden. It's ZIP-Datei, of course, and follows the same origin (.zip-Datei). The history of ZIP-Datei can be explained by way of MSDOS showing the filename in the DIR command without the dot - which is also why we do not pronounce the dot in .zip- or .pack-Datei. Yup, im my experience committen (to commit), einchecken (to check in), auschecken (to check out) und taggen (to tag) made it into our daily German language use. To avoid e.g. having past tenses look strange (like committet) Not so strange. We have other words with -tet. bitten - erbittete - habe erbittet. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
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 having seen that anywhere, AFAIK the file extensions are always used without the dot), I'm not a grammar expert and will be fine either way. In UNIX-land, extension seemed to always include the dot. In DOS-land, it's without (inherited from VMS too, perhaps?) As such, either way to write it is acceptable. extension .zip is a Zipdatei (known by the Duden) If that's how Duden specifies it, it's time to call wrong upon Duden. Go ahead: http://www.duden.de/rechtschreibung/Zipdatei ;-) (There seems to be no way to send corrections. Sucks not to be a wiki.) Ah well that explains their cluelessness: nach englisch zip file, zu: to zip = (mit dem Reißverschluss) schließen und file = Datei ZIP-Datei kommt daher, weil die Erweiterung ZIP/.zip ist, nicht weil da ein symbolischer Reißverschluss zugezogen wird oder ein Programmicon selbiges suggerieren will. Wir haben ja schließlich auch RAR-Dateien, die deswegen so heißen, weil sie eben .rar als Endung tragen und nicht, weil sie wertvolle Mangelware sind. ;-) Not so strange. We have other words with -tet. bitten - erbittete - habe erbittet. That example was not the best, what about wenn Du das mergest(?) (if Konjugation wie merken, nur Aussprache mit [dʒ] statt [k]-Laut. merge/mergst/mergt/mergen/mergt/mergen/mergte/(habe,hatte) (ge)mergt. Ich sehe da keine Komplikationen. you merge that), I cannot really say how to write that correctly (as in German we would want to drop the last 'e', right?) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
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 dot), I'm not a grammar expert and will be fine either way. In UNIX-land, extension seemed to always include the dot. In DOS-land, it's without (inherited from VMS too, perhaps?) As such, either way to write it is acceptable. Even in unix-land no one adds a dot because usually the extension is named after the data format, only that the file extension is used as the common abbreviation (at least that is my interpretation). Compare with jpeg. You often write jpeg-Datei instead of jpg-Datei because the data format is called jpeg. That too is correct, and actually a third way of describing files. For example, .doc/.xls-Datei in speech is very seldom, if at all; MS Office output has had generally been called Word-Datei, Excel-Tabelle/-Datei and so on. What I meant however is that the extension is .jpg (or .jpeg) from a programming aspect (like, when naïvely trying to figure out the filetype) as in ($name, $ext) = (/^[^\.]+(\..+)?/) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
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 Ger, respectively. The problem is that there are often no technical equivalent terms in Ger, leaving you only with Eng which are paraphrased (in more or less detail) in the German-language manpages. treeish is one of those. The literal translation would be baumig, bäumlich. This is strange in German and at best only used by kids. In the SYNOPSIS section of e.g. git-ls-tree(1), you can get away with baumähnlich, but in flowtext (prose), the sane choices are, for example: git-ls-tree erfordert als ersten nicht-Options-Parameter... ~... einen tree-ish, d.h. eine Referenz, aus der sich ein Baum-Objekt ableiten lässt. ~... eine zu einem Baum-Objekt führende Refernz ~... eine Baum-Objekt-Referenz (dies kann auch ein Commit sein, da jedem Commit genau ein Baum-Objekt zugeordnet ist) My vote is G+E. Essentially, so is mine. German terms will be used where such have been used in prior computing (Bäume have been used in the 90s too, so that term is fine, for example). Stash however is something that could be seen as something that has had its first appearence in Git, with no corresponding native German term, in which case we should do it roughly like Wikipedia, that is, provide a German equivalent, but only for the introductory sake: Der Stash (dt: Versteck) bezeichnet einen Bereich ... afterwards which the meaning of stash is at most re-recognizable in the verb: ... mit `git stash` wird der aktuelle Zustand im Stash weggespeichert. That's my common-world use. glossary for git's de.po is [2]. I have no idea what Sven and Ralph do. Perhaps a github wiki page would be fine for everyone? A single wiki page might not suffice; we may need as much as one wiki page per term, so that there is ample visual space to record each person's comments and justification for choosing a particular German translation. (Just look at my go at treeish above, for example.) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AW: English/German terminology, git.git's de.po, and pro-git
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 overview and single pages for complicated terms. Maybe we can use our GitHub wiki (see also [3]). [2] https://github.com/progit/progit/blob/master/de/NOTES [3] https://github.com/progit-de/progit/wiki/Glossar This is how I envision a good glossary http://inai.de/files/git-glossary.txt Maybe the Benevolent Dictator model might be better suited instead of a wiki? (Think of the edit wars.) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
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). Obviously, your script was executed sufficiently fast that the two commits happend in the same second. What about introducing nanosecond-granular timestamps into Git? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
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 back then, reset --soft also has outlived its usefulness when commit --amend came, so that leaves only these modes of reset: Soft is still useful, partway. Consider patch splitting (where easily possible): $ git add foo.c bar.c $ git commit -m foo,bar [other commits] $ git rebase -i FOOBARCOMMIT^ [mark foo,bar for edit] $ git reset --soft HEAD^ $ git reset bar.c $ git commit -m foo $ git add bar.c $ git commit -m bar $ git rebase --continue -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git: expand user path in --git-dir
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 commands GIT_DIR=~user/foo git command git --git-dir=~user/foo command currently behave differently because in the first case the shell would perform tilde expansion, but not in the second. If git uses a standardized option logic (getopt-like) which accepts both '=' and (new argument) for long options, you could easily do git --git-dir ~user/foo command -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to create the [PATCH 0/5] first email?
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 my-series/ --cover-letter ... would treat my-series/ directory as MUA's drafts folder and prepares the messages you would want to send out, and you can proof-read and edit the files in there before telling your MUA to send them out, with git send-email ... my-series/*.patch or something. One can also send [0/n] with a normal MUA, and then use git send-email --in-reply-to 'messageid...@yourhost.no' commitrange It's not like 0/n has to be emitted at the same second 1/n is :) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] Support for HP NonStop
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 hold a void * pointer, so should be at least as big. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Port to HP NonStop
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 exceed) 'sizeof(void *)'. + * We can't take long long here as not everybody has it. Are you trying to port git to DOS or why would you mention IP16? :-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How do I pronounce blob?
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 unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Restore hostname logging in inetd mode
The following changes since commit 0ce986446163b37c7f663ce7a408e7f94c31ba63: The fourth batch for 1.8.0 (2012-09-07 11:25:22 -0700) are available in the git repository at: git://git.inai.de/git master for you to fetch changes up to 864633738f6432574402afc43b6bd83c83fc8916: daemon: 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 deletions(-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] daemon: restore getpeername(0,...) use
This reverts f9c87be6b42dd0f8b31a4bb8c6a44326879fdd1a, in a sense,
because that commit broke logging of Connection from ... when
git-daemon is run under xinetd.
This patch here computes the text representation of the peer and then
copies that to environment variables such that the code in execute()
and subfunctions can stay as-is.
Signed-off-by: Jan Engelhardt jeng...@inai.de
---
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.c
@@ -1,3 +1,4 @@
+#include stdbool.h
#include cache.h
#include pkt-line.h
#include exec_cmd.h
@@ -1164,6 +1165,54 @@ static int serve(struct string_list *listen_addr, int
listen_port,
return service_loop(socklist);
}
+static void inetd_mode_prepare(void)
+{
+ struct sockaddr_storage ss;
+ struct sockaddr *addr = (void *)ss;
+ socklen_t slen = sizeof(ss);
+ char addrbuf[256], portbuf[6] = ;
+
+ if (!freopen(/dev/null, w, stderr))
+ die_errno(failed to redirect stderr to /dev/null);
+
+ /*
+* Windows is said to not be able to handle this, so we will simply
+* ignore failure here. (It only affects a log message anyway.)
+*/
+ if (getpeername(0, addr, slen) 0)
+ return;
+
+ if (addr-sa_family == AF_INET) {
+ const struct sockaddr_in *sin_addr = (void *)addr;
+
+ if (inet_ntop(addr-sa_family, sin_addr-sin_addr,
+ addrbuf, sizeof(addrbuf)) == NULL)
+ return;
+ snprintf(portbuf, sizeof(portbuf), %hu,
+ntohs(sin_addr-sin_port));
+#ifndef NO_IPV6
+ } else if (addr-sa_family == AF_INET6) {
+ const struct sockaddr_in6 *sin6_addr = (void *)addr;
+
+ addrbuf[0] = '[';
+ addrbuf[1] = '\0';
+ if (inet_ntop(AF_INET6, sin6_addr-sin6_addr, addrbuf + 1,
+ sizeof(addrbuf) - 2) == NULL)
+ return;
+ strcat(addrbuf, ]);
+
+ snprintf(portbuf, sizeof(portbuf), %hu,
+ntohs(sin6_addr-sin6_port));
+#endif
+ } else {
+ snprintf(addrbuf, sizeof(addrbuf), AF %d,
+addr-sa_family);
+ }
+ if (setenv(REMOTE_ADDR, addrbuf, true) 0)
+ return;
+ setenv(REMOTE_PORT, portbuf, true);
+}
+
int main(int argc, char **argv)
{
int listen_port = 0;
@@ -1341,10 +1390,8 @@ int main(int argc, char **argv)
die(base-path '%s' does not exist or is not a directory,
base_path);
- if (inetd_mode) {
- if (!freopen(/dev/null, w, stderr))
- die_errno(failed to redirect stderr to /dev/null);
- }
+ if (inetd_mode)
+ inetd_mode_prepare();
if (inetd_mode || serve_mode)
return execute();
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Restore hostname logging in inetd mode
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 shortlog. And 'lo, that is exactly what git-request-pull thankfully generates. In my defense: Just because the command is called request-pull, does not mean you absolutely have to merge/pull it. In fact, it does not even mention merge/pull at all. The following changes since commit [SHA]: [Commit Message] are available in the git repository at: git://[...] for you to fetch changes up to [SHA]: [Commit Message] [diffstat,shortlog] In contrast to many a LKML postings which explicitly state the pull intent: Hi [Maintainer], Please pull from the git repository at [URL] to receive [...] [SHA] [Commit Message] on top of commit [SHA] [Commit Message] [diffstat,shortlog] -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] daemon: restore getpeername(0,...) use
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 stdbool.h #include cache.h #include pkt-line.h #include exec_cmd.h Platform agnostic parts of the code that use git-compat-util.h (users of cache.h are indirectly users of it) are not allowed to do platform specific include like this at their beginning. This is the first use of stdbool.h; what do you need it for? For the use in setenv(,,true). It was not entirely obvious in which .h to add it; the most reasonable place was daemon.c itself, since the other .c files do not seem to need it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git on HP NonStop
On Tuesday 2012-08-14 17:52, Joachim Schmitz wrote: @@ -98,6 +99,11 @@ #include stdlib.h #include stdarg.h #include string.h +#ifdef __TANDEM +# include strings.h /* for strcasecmp() */ + typedef int intptr_t; /* not int * ?!? */ + typedef unsigned int uintptr_t; /* not unsigned int * ?!? */ Of course not. intptr_t is an integral value capable of holding a pointer; it is not a pointer to int (because that would really be redundant to int*.) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: inconsistent logs when displayed on screen / piped to a file
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 from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] l10n: de.po: translate 4 new messages
On Monday 2012-07-30 18:08, Ralf Thielow wrote: Translate 4 new messages came from git.pot update in 0bbe5b4 (l10n: Update git.pot (4 new, 3 removed messages)). Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- Hi German l10n team, please review this small update on German 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 jeng...@medozas.de Date: Thu Oct 7 20:52:26 2010 +0200 po/de.po: complete German translation Translate all 689 currently translatable messages in Git into German. Making the German translation 100% complete. [Ævar Arnfjörð Bjarmason: Modified by running msgmerge(1) on it to normalize the line wrapping, and squashed two of Jan's commits together] Signed-off-by: Jan Engelhardt jeng...@medozas.de Signed-off-by: Ævar Arnfjörð Bjarmason ava...@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A new way to get a sha1?
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 fixup command. So I wrote a perl script to avoid the usage of the mouse. If you use screen(1), you can use the keyboard as well; it offers ^A [ and ^A ] for copy, and then paste. tmux and all those screen clones probably have something similar. Maybe ratpoison-like WMs do as well. Or, you can use `git log --oneline`, look for the commit and then type the (usually) 6-char part of the hash manually, which may be faster than ^A[, moving the cursor to the copy position, marking it, etc. So, what is your opinion? IMO, I thus never needed an extra tool to find and specify the hash for `git re -i hash^`.. my ¥2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
