* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Jan Hudec @ 2008-08-03 20:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Johannes Sixt, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807261613120.26810@eeepc-johanness>
On Sat, Jul 26, 2008 at 16:14:33 +0200, Johannes Schindelin wrote:
> When the program 'git' is in the PATH, the argv[0] is set to the basename.
> However, argv0_path needs the full path, so add a function to discover the
> program by traversing the PATH manually.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> So it is not easily possible to reuse this function in
> compat/mingw.c, as Junio said that compat/ should not depend
> (at least too much) on libgit.a.
>
> Of course, we could try to follow a symlinked git, too, but I
> think this is overkill until someone proves me wrong.
On UNIX, not only that argv[0] can contain the program without path -- it can
contain anything the user thinks of. However most systems provide some way to
get the path of the executable. On Linux (and some other unices, but not all
of them) a reliable way is to readlink("/proc/self/exe", ...). Maybe since
it's only needed for resolving a relative exec dir, relative exec dir could
be supported only on systems that have such method (which is most of them).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Alex Riesen @ 2008-08-03 20:12 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Boaz Harrosh, cte, git
In-Reply-To: <32541b130807311155v50ee6ddaha1bba2f56e9bd61d@mail.gmail.com>
Avery Pennarun, Thu, Jul 31, 2008 20:55:26 +0200:
> On 7/31/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> > Boaz Harrosh, Thu, Jul 31, 2008 15:04:50 +0200:
> > > Produce a C file and header that defines some stable API to your
> > > GUI application, that does not expose any git internal headers.
> > > Then compile that, say git_api.c, with C compiler in Makefile
> > > and extern "C" link that file to your C++ application. This will
> > > completely insulate you from any git code.
> >
> > no, it wont. He still have to resolve name conflicts at the link time.
>
> Language keywords (as opposed to function names) like 'new' and
> 'typename' are definitely not exported to the object files. Moreover,
> function parameter names aren't either.
>
Didn't mean them. Meant the globally visible names. libgit does not
use a prefix for its exported symbols. They will clash with the
symbols of the programs it is linked to.
^ permalink raw reply
* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Johannes Sixt @ 2008-08-03 19:55 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Junio C Hamano, Björn Steinbrink
In-Reply-To: <1217065304-27815-1-git-send-email-prohaska@zib.de>
Zitat von Steffen Prohaska <prohaska@zib.de>:
> With MinGW's
>
> gcc.exe (GCC) 3.4.5 (mingw special)
> GNU ld version 2.17.50 20060824
>
> the old define caused link errors:
>
> git.o: In function `main':
> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
> collect2: ld returned 1 exit status
>
> The modified define works.
>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
I was not aware that my version (block-scoped static function forward
declaration) is not valid C. Thanks, Björn, for pointing out the gcc bugzilla
entries.
-- Hannes
> ---
> compat/mingw.h | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/compat/mingw.h b/compat/mingw.h
> index 290a9e6..a52e657 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -228,9 +228,10 @@ char **env_setenv(char **env, const char *name);
> * A replacement of main() that ensures that argv[0] has a path
> */
>
> -#define main(c,v) main(int argc, const char **argv) \
> +#define main(c,v) dummy_decl_mingw_main(); \
> +static int mingw_main(); \
> +int main(int argc, const char **argv) \
> { \
> - static int mingw_main(); \
> argv[0] = xstrdup(_pgmptr); \
> return mingw_main(argc, argv); \
> } \
> --
> 1.6.0.rc0.42.g186458
^ permalink raw reply
* Re: [PATCH] gitweb: remove PATH_INFO from $my_url and $my_uri
From: Petr Baudis @ 2008-08-03 19:10 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski
In-Reply-To: <1217786545-30685-1-git-send-email-giuseppe.bilotta@gmail.com>
On Sun, Aug 03, 2008 at 08:02:25PM +0200, Giuseppe Bilotta wrote:
> This patch (combined with appropriate server configuration) allows usage
> of the gitweb CGI script as DirectoryIndex for the server root even when
> the pathinfo feature is enabled.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
(In case anyone is wondering, on repo.or.cz I used to just override
$my_uri manually from the config file.)
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Tarmigan @ 2008-08-03 18:54 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Steffen Prohaska, Avery Pennarun, Eyvind Bernhardsen,
Johannes Schindelin, Joshua Jensen, Junio C Hamano, git
In-Reply-To: <20080803173339.GQ7008@dpotapov.dyndns.org>
On Sun, Aug 3, 2008 at 10:33 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Sun, Aug 03, 2008 at 09:54:42AM -0700, Tarmigan wrote:
>>
>> For all I care, git can consider the files as binary, but by *default*
>> I should get back the same as I put in.
>
> Sorry, but Git is a source control system,
I think this is the heart of the disagreement. What I love about git
is that git trusts me, the user, and it trusts my files. It doesn't
change the encoding of my filenames by default. It doesn't do keyword
expansion by default. It doesn't change the case of filenames by
default.
If git is not willing to change the encoding/case of file*names* by
default, how is it acceptable to change the *content* of the files
themselves?
Yes, some systems that define themselves as "source control
management" systems make these changes for you. But that sometimes
leads to frustrating and hard to understand (to the user) behavior.
Git has a very simple and transparent mental model, which is one of
it's greatest strengths. In my humble opinion, autocrlf breaks this
simple "content tracker" model.
Breaking this mental model bothers me much more than the practical
issues involved with autocrlf, so I'm just going to drop that line of
argument.
Thanks,
Tarmigan
^ permalink raw reply
* Re: Moving .git around
From: Jan Hudec @ 2008-08-03 18:51 UTC (permalink / raw)
To: Geoff Russell; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <93c3eada0807231936ib103824u9204f1109119e1c2@mail.gmail.com>
On Thu, Jul 24, 2008 at 12:06:28 +0930, Geoff Russell wrote:
> On Thu, Jul 24, 2008 at 11:42 AM, Nguyen Thai Ngoc Duy
> <pclouds@gmail.com> wrote:
> > On 7/24/08, Geoff Russell <geoffrey.russell@gmail.com> wrote:
> >> For reasons which would take a while to explain, I'm building a repository
> >> in a directory using "--git-dir=xxxx/.git --work-tree=." and
> >> then doing an "mv xxxx/.git ./.git" and then trying to work with
> >> that repository --- but can't
> >>
> >> Below is a sample script. The last line (git add) fails with
> >>
> >> fatal: unable to create
> >> '/usr/local/AusTop/AuPrograms/AuServer/testgit/aaa/bbb/.git/index.lock':
> >> No such file or directory
> >>
> >> git doesn't seem to realise that there is a .git back up the tree.
> >
> > It's because when you did git --work-tree=. init, worktree is stored
> > in .git/config. The code that chdir() in setup_git_directory()
> > probably forgot to chdir() back to toplevel worktree. Workaround could
> > be just remove core.worktree in .git/config.
>
> Many thanks, the work-around works. I'm not sure if this is a bug or
> a feature, but I'm happy either way.
That depends on what the value of core.worktree is:
- If it is '.', than I think it should be considered a bug in git init,
because that value is just plain nonsense.
- If it is '..', than it's a user error and the right thing is to just
remove it when you relocate the .git directory.
- If it was '/usr/local/AusTop/AuPrograms/AuServer/testgit/' than it would
have worked, so it's not that.
Best regards,
Jan
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Jan Hudec @ 2008-08-03 18:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.DEB.1.00.0807231753240.8986@racer>
Hello,
sorry for replying to an old thread, but I am a bit puzzled here,
On Wed, Jul 23, 2008 at 17:55:14 +0100, Johannes Schindelin wrote:
> On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> > On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:
> > >
> > > > So in short, sparse prefix will be stored in config,
> > > > core.sparsecheckout.
> > >
> > > Do you really think the prefix should be stored anywhere else than the
> > > index?
> > >
> > > With core.sparseCheckout you have to introduce a _sh*tload_ of config
> > > loaders.
> > >
> > > And with core.sparseCheckout you are at the whim of the user, since
> > > .git/config is _supposed_ to be user-editable.
> > >
> > > From a logical point of view, I'd say that the sparse prefix has
> > > nothing to do with the "configuration" of the local repository.
> >
> > Well, whatever place. I chose .git/config because I did not want to
> > introduce a new config place. But then how about .git/sparsecheckout?
>
> No, I did mean the index. This is an attribute of the index: either it is
> sparsely checked out or not. You can even have multiple indices
> (switching between them by setting GIT_INDEX_FILE) which have different
> prefixes.
Um, but does the prefix we want to use depend on what files are physically
present in the tree? That would however imply that it's /not/ an attribute of
the index, but the tree and therefore should be stored in a separate object.
The question whether it goes in the .git/config or .git/sparsecheckout is
than that of semantics -- if it's in .git/config, than user changes that by
editing the file or git config and no other way, while if it's in
.git/sparsecheckout, user changes it by running checkout with appropriate
arguments.
By the way, why is it *prefix*? Wouldn't a *path limit* be better?
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* [PATCH] gitweb: remove PATH_INFO from $my_url and $my_uri
From: Giuseppe Bilotta @ 2008-08-03 18:02 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Giuseppe Bilotta
This patch (combined with appropriate server configuration) allows usage
of the gitweb CGI script as DirectoryIndex for the server root even when
the pathinfo feature is enabled.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ba1f71b..9c8bcab 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -26,6 +26,10 @@ our $cgi = new CGI;
our $version = "++GIT_VERSION++";
our $my_url = $cgi->url();
our $my_uri = $cgi->url(-absolute => 1);
+if (my $path_info = $ENV{"PATH_INFO"}) {
+ $my_url =~ s,$path_info$,,;
+ $my_uri =~ s,$path_info$,,;
+}
# core git executable to use
# this can just be "git" if your webserver has a sensible PATH
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-08-03 17:33 UTC (permalink / raw)
To: Tarmigan
Cc: Steffen Prohaska, Avery Pennarun, Eyvind Bernhardsen,
Johannes Schindelin, Joshua Jensen, Junio C Hamano, git
In-Reply-To: <905315640808030954j7487a010p136c73406298ee29@mail.gmail.com>
On Sun, Aug 03, 2008 at 09:54:42AM -0700, Tarmigan wrote:
>
> For all I care, git can consider the files as binary, but by *default*
> I should get back the same as I put in.
Sorry, but Git is a source control system, and by definition the
main focus is on *text* files. Storying binary files is *exception*
not the rule. And the default settings should respect exactly that
fact.
> > For git's
> > autocrlf mechanism to work, a text file is only allowed to have a
> > *single* type of line endings.
>
> Git's autocrlf mechanism can be a nice feature. But by default it
> should not be on (even on windows) because it can modify screw up my
> files.
>
> To be clear: when I say "git checkout" I want to get EXACTLY the same
> bits as went in when I did "git add" and "git commit". Any other
> default is broken.
You will get exactly the same unless you change your autocrlf settings.
There are very rare situation where automatic heuristic can be wrong,
but even then you will be warned about that the file you are going to
checkout different. See core.safecrlf.
>
> > Otherwise it is broken and git tries to
> > help you fixing it.
>
> My files were NOT broken when I put them into git. I committed them
> known good state. If msysgit changes them by *default* , then msysgit
> is broken.
Text files committed with CRLF inside of your repository is BROKEN by
definition! So you had BROKEN state in the first place.
Of course, changing the global autocrlf setting should not change
autocrlf settings in already existing repositories, as it currently
does. Care to provide patch?
Dmitry
^ permalink raw reply
* Re: German translation of git man pages
From: Fabio Scotoni @ 2008-08-03 17:26 UTC (permalink / raw)
To: git
In-Reply-To: <1217408012.9486.13.camel@hydra.esse.ch>
Hello,
I ran into another problem: Should i write something like "translated by
Fabio Scotoni <fabio@esse.ch>" in the Author-Part of the man pages, or
just translate it without any note (It wouldn't be a problem for me)?
With best regards,
Fabio Scotoni
^ permalink raw reply
* [PATCH] gitk: Update swedish translation.
From: Mikael Magnusson @ 2008-08-03 17:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List, Peter Karlsson
[-- Attachment #1: Type: text/plain, Size: 31 bytes --]
attached
--
Mikael Magnusson
[-- Attachment #2: 0001-Update-swedish-translation.patch --]
[-- Type: application/octet-stream, Size: 24702 bytes --]
From 987cad56bf801488a911f9a80b96bb6db0495ff1 Mon Sep 17 00:00:00 2001
From: Mikael Magnusson <mikachu@gmail.com>
Date: Sun, 3 Aug 2008 19:04:21 +0200
Subject: [PATCH] gitk: Update swedish translation.
---
gitk-git/po/sv.po | 492 ++++++++++++++++++++++++++++-------------------------
1 files changed, 260 insertions(+), 232 deletions(-)
diff --git a/gitk-git/po/sv.po b/gitk-git/po/sv.po
index f6b080d..e1ecfb7 100644
--- a/gitk-git/po/sv.po
+++ b/gitk-git/po/sv.po
@@ -3,687 +3,724 @@
# This file is distributed under the same license as the gitk package.
#
# Peter Karlsson <peter@softwolves.pp.se>, 2008.
+# Mikael Magnusson <mikachu@gmail.com>, 2008.
msgid ""
msgstr ""
"Project-Id-Version: sv\n"
"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2008-03-14 15:03+0100\n"
-"PO-Revision-Date: 2008-03-14 16:06CET-1\n"
-"Last-Translator: Peter Karlsson <peter@softwolves.pp.se>\n"
+"POT-Creation-Date: 2008-08-03 18:58+0200\n"
+"PO-Revision-Date: 2008-08-03 19:03+0200\n"
+"Last-Translator: Mikael Magnusson <mikachu@gmail.com>\n"
"Language-Team: Swedish <sv@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit"
+"Content-Transfer-Encoding: 8bit\n"
-#: gitk:111
-msgid "Error executing git rev-list:"
-msgstr "Fel vid körning av git rev-list:"
+#: gitk:102
+msgid "Couldn't get list of unmerged files:"
+msgstr "Kunde inta hämta lista över ej sammanslagna filer:"
+
+#: gitk:329
+msgid "No files selected: --merge specified but no files are unmerged."
+msgstr ""
+"Inga filer valdes: --merge angavs men det finns inga filer som inte har "
+"slagits samman."
+
+#: gitk:332
+msgid ""
+"No files selected: --merge specified but no unmerged files are within file "
+"limit."
+msgstr ""
+"Inga filer valdes: --merge angavs men det finns inga filer inom "
+"filbegränsningen."
+
+#: gitk:354
+msgid "Error executing git log:"
+msgstr "Fel vid körning av git log:"
-#: gitk:124
+#: gitk:369
msgid "Reading"
msgstr "Läser"
-#: gitk:151 gitk:2191
+#: gitk:400 gitk:3356
msgid "Reading commits..."
msgstr "Läser incheckningar..."
-#: gitk:275
-msgid "Can't parse git log output:"
-msgstr "Kan inte tolka utdata från git log:"
-
-#: gitk:386 gitk:2195
+#: gitk:403 gitk:1480 gitk:3359
msgid "No commits selected"
msgstr "Inga incheckningar markerade"
-#: gitk:500
+#: gitk:1358
+msgid "Can't parse git log output:"
+msgstr "Kan inte tolka utdata från git log:"
+
+#: gitk:1557
msgid "No commit information available"
msgstr "Ingen incheckningsinformation är tillgänglig"
-#: gitk:599 gitk:621 gitk:1955 gitk:6423 gitk:7923 gitk:8082
+#: gitk:1654 gitk:1676 gitk:3150 gitk:7620 gitk:9149 gitk:9317
msgid "OK"
msgstr "OK"
-#: gitk:623 gitk:1956 gitk:6107 gitk:6178 gitk:6275 gitk:6321 gitk:6425
-#: gitk:7924 gitk:8083
+#: gitk:1678 gitk:3151 gitk:7296 gitk:7367 gitk:7470 gitk:7516 gitk:7622
+#: gitk:9150 gitk:9318
msgid "Cancel"
msgstr "Avbryt"
-#: gitk:661
+#: gitk:1716
msgid "File"
msgstr "Arkiv"
-#: gitk:663
+#: gitk:1718
msgid "Update"
msgstr "Uppdatera"
-#: gitk:664
+#: gitk:1719
+msgid "Reload"
+msgstr "Ladda om"
+
+#: gitk:1720
msgid "Reread references"
msgstr "Läs om referenser"
-#: gitk:665
+#: gitk:1721
msgid "List references"
msgstr "Visa referenser"
-#: gitk:666
+#: gitk:1722
msgid "Quit"
msgstr "Avsluta"
-#: gitk:668
+#: gitk:1724
msgid "Edit"
msgstr "Redigera"
-#: gitk:669
+#: gitk:1725
msgid "Preferences"
msgstr "Inställningar"
-#: gitk:672 gitk:1892
+#: gitk:1728 gitk:3087
msgid "View"
msgstr "Visa"
-#: gitk:673
+#: gitk:1729
msgid "New view..."
msgstr "Ny vy..."
-#: gitk:674 gitk:2133 gitk:8722
+#: gitk:1730 gitk:3298 gitk:9932
msgid "Edit view..."
msgstr "Ändra vy..."
-#: gitk:676 gitk:2134 gitk:8723
+#: gitk:1732 gitk:3299 gitk:9933
msgid "Delete view"
msgstr "Ta bort vy"
-#: gitk:678
+#: gitk:1734
msgid "All files"
msgstr "Alla filer"
-#: gitk:682
+#: gitk:1738
msgid "Help"
msgstr "Hjälp"
-#: gitk:683 gitk:1317
+#: gitk:1739 gitk:2399
msgid "About gitk"
msgstr "Om gitk"
-#: gitk:684
+#: gitk:1740
msgid "Key bindings"
msgstr "Tangentbordsbindningar"
-#: gitk:741
+#: gitk:1797
msgid "SHA1 ID: "
msgstr "SHA1-id: "
-#: gitk:791
+#: gitk:1828
+msgid "Row"
+msgstr "Rad"
+
+#: gitk:1859
msgid "Find"
msgstr "Sök"
-#: gitk:792
+#: gitk:1860
msgid "next"
msgstr "nästa"
-#: gitk:793
+#: gitk:1861
msgid "prev"
msgstr "föreg"
-#: gitk:794
+#: gitk:1862
msgid "commit"
msgstr "incheckning"
-#: gitk:797 gitk:799 gitk:2356 gitk:2379 gitk:2403 gitk:4306 gitk:4369
+#: gitk:1865 gitk:1867 gitk:3511 gitk:3534 gitk:3558 gitk:5441 gitk:5512
msgid "containing:"
msgstr "som innehåller:"
-#: gitk:800 gitk:1778 gitk:1783 gitk:2431
+#: gitk:1868 gitk:2866 gitk:2871 gitk:3586
msgid "touching paths:"
msgstr "som rör sökväg:"
-#: gitk:801 gitk:2436
+#: gitk:1869 gitk:3591
msgid "adding/removing string:"
msgstr "som lägger/till tar bort sträng:"
-#: gitk:810 gitk:812
+#: gitk:1878 gitk:1880
msgid "Exact"
msgstr "Exakt"
-#: gitk:812 gitk:2514 gitk:4274
+#: gitk:1880 gitk:3667 gitk:5409
msgid "IgnCase"
msgstr "IgnVersaler"
-#: gitk:812 gitk:2405 gitk:2512 gitk:4270
+#: gitk:1880 gitk:3560 gitk:3665 gitk:5405
msgid "Regexp"
msgstr "Reg.uttr."
-#: gitk:814 gitk:815 gitk:2533 gitk:2563 gitk:2570 gitk:4380 gitk:4436
+#: gitk:1882 gitk:1883 gitk:3686 gitk:3716 gitk:3723 gitk:5532 gitk:5599
msgid "All fields"
msgstr "Alla fält"
-#: gitk:815 gitk:2531 gitk:2563 gitk:4336
+#: gitk:1883 gitk:3684 gitk:3716 gitk:5471
msgid "Headline"
msgstr "Rubrik"
-#: gitk:816 gitk:2531 gitk:4336 gitk:4436 gitk:4827
+#: gitk:1884 gitk:3684 gitk:5471 gitk:5599 gitk:6000
msgid "Comments"
msgstr "Kommentarer"
-#: gitk:816 gitk:2531 gitk:2535 gitk:2570 gitk:4336 gitk:4763 gitk:5956
-#: gitk:5971
+#: gitk:1884 gitk:3684 gitk:3688 gitk:3723 gitk:5471 gitk:5936 gitk:7142
+#: gitk:7157
msgid "Author"
msgstr "Författare"
-#: gitk:816 gitk:2531 gitk:4336 gitk:4765
+#: gitk:1884 gitk:3684 gitk:5471 gitk:5938
msgid "Committer"
msgstr "Incheckare"
-#: gitk:845
+#: gitk:1913
msgid "Search"
msgstr "Sök"
-#: gitk:852
+#: gitk:1920
msgid "Diff"
msgstr "Diff"
-#: gitk:854
+#: gitk:1922
msgid "Old version"
msgstr "Gammal version"
-#: gitk:856
+#: gitk:1924
msgid "New version"
msgstr "Ny version"
-#: gitk:858
+#: gitk:1926
msgid "Lines of context"
msgstr "Rader sammanhang"
-#: gitk:868
+#: gitk:1936
msgid "Ignore space change"
msgstr "Ignorera ändringar i blanksteg"
-#: gitk:926
+#: gitk:1994
msgid "Patch"
msgstr "Patch"
-#: gitk:928
+#: gitk:1996
msgid "Tree"
msgstr "Träd"
-#: gitk:1053 gitk:1068 gitk:6022
+#: gitk:2121 gitk:2136 gitk:7211
msgid "Diff this -> selected"
msgstr "Diff denna -> markerad"
-#: gitk:1055 gitk:1070 gitk:6023
+#: gitk:2123 gitk:2138 gitk:7212
msgid "Diff selected -> this"
msgstr "Diff markerad -> denna"
-#: gitk:1057 gitk:1072 gitk:6024
+#: gitk:2125 gitk:2140 gitk:7213
msgid "Make patch"
msgstr "Skapa patch"
-#: gitk:1058 gitk:6162
+#: gitk:2126 gitk:7351
msgid "Create tag"
msgstr "Skapa tagg"
-#: gitk:1059 gitk:6255
+#: gitk:2127 gitk:7450
msgid "Write commit to file"
msgstr "Skriv incheckning till fil"
-#: gitk:1060 gitk:6309
+#: gitk:2128 gitk:7504
msgid "Create new branch"
msgstr "Skapa ny gren"
-#: gitk:1061
+#: gitk:2129
msgid "Cherry-pick this commit"
msgstr "Plocka denna incheckning"
-#: gitk:1063
+#: gitk:2131
msgid "Reset HEAD branch to here"
msgstr "Återställ HEAD-grenen hit"
-#: gitk:1079
+#: gitk:2147
msgid "Check out this branch"
msgstr "Checka ut denna gren"
-#: gitk:1081
+#: gitk:2149
msgid "Remove this branch"
msgstr "Ta bort denna gren"
-#: gitk:1087
+#: gitk:2155
msgid "Highlight this too"
msgstr "Markera även detta"
-#: gitk:1089
+#: gitk:2157
msgid "Highlight this only"
msgstr "Markera bara detta"
-#: gitk:1318
+#: gitk:2159
+msgid "External diff"
+msgstr "Extern diff"
+
+#: gitk:2400
msgid ""
"\n"
"Gitk - a commit viewer for git\n"
"\n"
-"Copyright © 2005-2006 Paul Mackerras\n"
+"Copyright © 2005-2008 Paul Mackerras\n"
"\n"
"Use and redistribute under the terms of the GNU General Public License"
msgstr ""
"\n"
"Gitk - en incheckningsvisare för git\n"
"\n"
-"Copyright © 2005-2006 Paul Mackerras\n"
+"Copyright © 2005-2008 Paul Mackerras\n"
"\n"
"Använd och vidareförmedla enligt villkoren i GNU General Public License"
-#: gitk:1326 gitk:1387 gitk:6581
+#: gitk:2408 gitk:2469 gitk:7799
msgid "Close"
msgstr "Stäng"
-#: gitk:1345
+#: gitk:2427
msgid "Gitk key bindings"
msgstr "Tangentbordsbindningar för Gitk"
-#: gitk:1347
+#: gitk:2429
msgid "Gitk key bindings:"
msgstr "Tangentbordsbindningar för Gitk:"
-#: gitk:1349
+#: gitk:2431
#, tcl-format
msgid "<%s-Q>\t\tQuit"
msgstr "<%s-Q>\t\tAvsluta"
-#: gitk:1350
+#: gitk:2432
msgid "<Home>\t\tMove to first commit"
msgstr "<Home>\t\tGå till första incheckning"
-#: gitk:1351
+#: gitk:2433
msgid "<End>\t\tMove to last commit"
msgstr "<End>\t\tGå till sista incheckning"
-#: gitk:1352
+#: gitk:2434
msgid "<Up>, p, i\tMove up one commit"
msgstr "<Upp>, p, i\tGå en incheckning upp"
-#: gitk:1353
+#: gitk:2435
msgid "<Down>, n, k\tMove down one commit"
msgstr "<Ned>, n, k\tGå en incheckning ned"
-#: gitk:1354
+#: gitk:2436
msgid "<Left>, z, j\tGo back in history list"
msgstr "<Vänster>, z, j\tGå bakåt i historiken"
-#: gitk:1355
+#: gitk:2437
msgid "<Right>, x, l\tGo forward in history list"
msgstr "<Höger>, x, l\tGå framåt i historiken"
-#: gitk:1356
+#: gitk:2438
msgid "<PageUp>\tMove up one page in commit list"
msgstr "<PageUp>\tGå upp en sida i incheckningslistan"
-#: gitk:1357
+#: gitk:2439
msgid "<PageDown>\tMove down one page in commit list"
msgstr "<PageDown>\tGå ned en sida i incheckningslistan"
-#: gitk:1358
+#: gitk:2440
#, tcl-format
msgid "<%s-Home>\tScroll to top of commit list"
msgstr "<%s-Home>\tRulla till början av incheckningslistan"
-#: gitk:1359
+#: gitk:2441
#, tcl-format
msgid "<%s-End>\tScroll to bottom of commit list"
msgstr "<%s-End>\tRulla till slutet av incheckningslistan"
-#: gitk:1360
+#: gitk:2442
#, tcl-format
msgid "<%s-Up>\tScroll commit list up one line"
msgstr "<%s-Upp>\tRulla incheckningslistan upp ett steg"
-#: gitk:1361
+#: gitk:2443
#, tcl-format
msgid "<%s-Down>\tScroll commit list down one line"
msgstr "<%s-Ned>\tRulla incheckningslistan ned ett steg"
-#: gitk:1362
+#: gitk:2444
#, tcl-format
msgid "<%s-PageUp>\tScroll commit list up one page"
msgstr "<%s-PageUp>\tRulla incheckningslistan upp en sida"
-#: gitk:1363
+#: gitk:2445
#, tcl-format
msgid "<%s-PageDown>\tScroll commit list down one page"
msgstr "<%s-PageDown>\tRulla incheckningslistan ned en sida"
-#: gitk:1364
+#: gitk:2446
msgid "<Shift-Up>\tFind backwards (upwards, later commits)"
msgstr "<Skift-Upp>\tSök bakåt (uppåt, senare incheckningar)"
-#: gitk:1365
+#: gitk:2447
msgid "<Shift-Down>\tFind forwards (downwards, earlier commits)"
msgstr "<Skift-Ned>\tSök framåt (nedåt, tidigare incheckningar)"
-#: gitk:1366
+#: gitk:2448
msgid "<Delete>, b\tScroll diff view up one page"
msgstr "<Delete>, b\tRulla diffvisningen upp en sida"
-#: gitk:1367
+#: gitk:2449
msgid "<Backspace>\tScroll diff view up one page"
msgstr "<Baksteg>\tRulla diffvisningen upp en sida"
-#: gitk:1368
+#: gitk:2450
msgid "<Space>\t\tScroll diff view down one page"
msgstr "<Blanksteg>\tRulla diffvisningen ned en sida"
-#: gitk:1369
+#: gitk:2451
msgid "u\t\tScroll diff view up 18 lines"
msgstr "u\t\tRulla diffvisningen upp 18 rader"
-#: gitk:1370
+#: gitk:2452
msgid "d\t\tScroll diff view down 18 lines"
msgstr "d\t\tRulla diffvisningen ned 18 rader"
-#: gitk:1371
+#: gitk:2453
#, tcl-format
msgid "<%s-F>\t\tFind"
msgstr "<%s-F>\t\tSök"
-#: gitk:1372
+#: gitk:2454
#, tcl-format
msgid "<%s-G>\t\tMove to next find hit"
msgstr "<%s-G>\t\tGå till nästa sökträff"
-#: gitk:1373
+#: gitk:2455
msgid "<Return>\tMove to next find hit"
msgstr "<Return>\t\tGå till nästa sökträff"
-#: gitk:1374
+#: gitk:2456
msgid "/\t\tMove to next find hit, or redo find"
msgstr "/\t\tGå till nästa sökträff, eller sök på nytt"
-#: gitk:1375
+#: gitk:2457
msgid "?\t\tMove to previous find hit"
msgstr "?\t\tGå till föregående sökträff"
-#: gitk:1376
+#: gitk:2458
msgid "f\t\tScroll diff view to next file"
msgstr "f\t\tRulla diffvisningen till nästa fil"
-#: gitk:1377
+#: gitk:2459
#, tcl-format
msgid "<%s-S>\t\tSearch for next hit in diff view"
msgstr "<%s-S>\t\tGå till nästa sökträff i diffvisningen"
-#: gitk:1378
+#: gitk:2460
#, tcl-format
msgid "<%s-R>\t\tSearch for previous hit in diff view"
msgstr "<%s-R>\t\tGå till föregående sökträff i diffvisningen"
-#: gitk:1379
+#: gitk:2461
#, tcl-format
msgid "<%s-KP+>\tIncrease font size"
msgstr "<%s-Num+>\tÖka teckenstorlek"
-#: gitk:1380
+#: gitk:2462
#, tcl-format
msgid "<%s-plus>\tIncrease font size"
msgstr "<%s-plus>\tÖka teckenstorlek"
-#: gitk:1381
+#: gitk:2463
#, tcl-format
msgid "<%s-KP->\tDecrease font size"
msgstr "<%s-Num->\tMinska teckenstorlek"
-#: gitk:1382
+#: gitk:2464
#, tcl-format
msgid "<%s-minus>\tDecrease font size"
msgstr "<%s-minus>\tMinska teckenstorlek"
-#: gitk:1383
+#: gitk:2465
msgid "<F5>\t\tUpdate"
msgstr "<F5>\t\tUppdatera"
-#: gitk:1896
+#: gitk:3091
msgid "Gitk view definition"
msgstr "Definition av Gitk-vy"
-#: gitk:1921
+#: gitk:3116
msgid "Name"
msgstr "Namn"
-#: gitk:1924
+#: gitk:3119
msgid "Remember this view"
msgstr "Spara denna vy"
-#: gitk:1928
-msgid "Commits to include (arguments to git rev-list):"
-msgstr "Incheckningar att ta med (argument till git rev-list):"
+#: gitk:3123
+msgid "Commits to include (arguments to git log):"
+msgstr "Incheckningar att ta med (argument till git log):"
-#: gitk:1935
+#: gitk:3130
msgid "Command to generate more commits to include:"
msgstr "Kommando för att generera fler incheckningar att ta med:"
-#: gitk:1942
+#: gitk:3137
msgid "Enter files and directories to include, one per line:"
msgstr "Ange filer och kataloger att ta med, en per rad:"
-#: gitk:1989
+#: gitk:3184
msgid "Error in commit selection arguments:"
msgstr "Fel i argument för val av incheckningar:"
-#: gitk:2043 gitk:2127 gitk:2583 gitk:2597 gitk:3781 gitk:8688 gitk:8689
+#: gitk:3238 gitk:3290 gitk:3736 gitk:3750 gitk:4951 gitk:9896 gitk:9897
msgid "None"
msgstr "Inget"
-#: gitk:2531 gitk:4336 gitk:5958 gitk:5973
+#: gitk:3684 gitk:5471 gitk:7144 gitk:7159
msgid "Date"
msgstr "Datum"
-#: gitk:2531 gitk:4336
+#: gitk:3684 gitk:5471
msgid "CDate"
msgstr "Skapat datum"
-#: gitk:2680 gitk:2685
+#: gitk:3833 gitk:3838
msgid "Descendant"
msgstr "Avkomling"
-#: gitk:2681
+#: gitk:3834
msgid "Not descendant"
msgstr "Inte avkomling"
-#: gitk:2688 gitk:2693
+#: gitk:3841 gitk:3846
msgid "Ancestor"
msgstr "Förfader"
-#: gitk:2689
+#: gitk:3842
msgid "Not ancestor"
msgstr "Inte förfader"
-#: gitk:2924
+#: gitk:4078
msgid "Local changes checked in to index but not committed"
msgstr "Lokala ändringar sparade i indexet men inte incheckade"
-#: gitk:2954
+#: gitk:4111
msgid "Local uncommitted changes, not checked in to index"
msgstr "Lokala ändringar, ej sparade i indexet"
-#: gitk:4305
+#: gitk:5440
msgid "Searching"
msgstr "Söker"
-#: gitk:4767
+#: gitk:5940
msgid "Tags:"
msgstr "Taggar:"
-#: gitk:4784 gitk:4790 gitk:5951
+#: gitk:5957 gitk:5963 gitk:7137
msgid "Parent"
msgstr "Förälder"
-#: gitk:4795
+#: gitk:5968
msgid "Child"
msgstr "Barn"
-#: gitk:4804
+#: gitk:5977
msgid "Branch"
msgstr "Gren"
-#: gitk:4807
+#: gitk:5980
msgid "Follows"
msgstr "Följer"
-#: gitk:4810
+#: gitk:5983
msgid "Precedes"
msgstr "Föregår"
-#: gitk:5093
+#: gitk:6267
msgid "Error getting merge diffs:"
msgstr "Fel vid hämtning av sammanslagningsdiff:"
-#: gitk:5778
+#: gitk:6970
msgid "Goto:"
msgstr "Gå till:"
-#: gitk:5780
+#: gitk:6972
msgid "SHA1 ID:"
msgstr "SHA1-id:"
-#: gitk:5805
+#: gitk:6991
#, tcl-format
msgid "Short SHA1 id %s is ambiguous"
msgstr "Förkortat SHA1-id %s är tvetydigt"
-#: gitk:5817
+#: gitk:7003
#, tcl-format
msgid "SHA1 id %s is not known"
msgstr "SHA-id:t %s är inte känt"
-#: gitk:5819
+#: gitk:7005
#, tcl-format
msgid "Tag/Head %s is not known"
msgstr "Tagg/huvud %s är okänt"
-#: gitk:5961
+#: gitk:7147
msgid "Children"
msgstr "Barn"
-#: gitk:6018
+#: gitk:7204
#, tcl-format
msgid "Reset %s branch to here"
msgstr "Återställ grenen %s hit"
-#: gitk:6049
+#: gitk:7206
+msgid "Detached head: can't reset"
+msgstr "Frånkopplad head: kan inte återställa"
+
+#: gitk:7238
msgid "Top"
msgstr "Topp"
-#: gitk:6050
+#: gitk:7239
msgid "From"
msgstr "Från"
-#: gitk:6055
+#: gitk:7244
msgid "To"
msgstr "Till"
-#: gitk:6078
+#: gitk:7267
msgid "Generate patch"
msgstr "Generera patch"
-#: gitk:6080
+#: gitk:7269
msgid "From:"
msgstr "Från:"
-#: gitk:6089
+#: gitk:7278
msgid "To:"
msgstr "Till:"
-#: gitk:6098
+#: gitk:7287
msgid "Reverse"
msgstr "Vänd"
-#: gitk:6100 gitk:6269
+#: gitk:7289 gitk:7464
msgid "Output file:"
msgstr "Utdatafil:"
-#: gitk:6106
+#: gitk:7295
msgid "Generate"
msgstr "Generera"
-#: gitk:6142
+#: gitk:7331
msgid "Error creating patch:"
msgstr "Fel vid generering av patch:"
-#: gitk:6164 gitk:6257 gitk:6311
+#: gitk:7353 gitk:7452 gitk:7506
msgid "ID:"
msgstr "Id:"
-#: gitk:6173
+#: gitk:7362
msgid "Tag name:"
msgstr "Taggnamn:"
-#: gitk:6177 gitk:6320
+#: gitk:7366 gitk:7515
msgid "Create"
msgstr "Skapa"
-#: gitk:6192
+#: gitk:7381
msgid "No tag name specified"
msgstr "Inget taggnamn angavs"
-#: gitk:6196
+#: gitk:7385
#, tcl-format
msgid "Tag \"%s\" already exists"
msgstr "Taggen \"%s\" finns redan"
-#: gitk:6202
+#: gitk:7391
msgid "Error creating tag:"
msgstr "Fel vid skapande av tagg:"
-#: gitk:6266
+#: gitk:7461
msgid "Command:"
msgstr "Kommando:"
-#: gitk:6274
+#: gitk:7469
msgid "Write"
msgstr "Skriv"
-#: gitk:6290
+#: gitk:7485
msgid "Error writing commit:"
msgstr "Fel vid skrivning av incheckning:"
-#: gitk:6316
+#: gitk:7511
msgid "Name:"
msgstr "Namn:"
-#: gitk:6335
+#: gitk:7530
msgid "Please specify a name for the new branch"
msgstr "Ange ett namn för den nya grenen"
-#: gitk:6364
+#: gitk:7559
#, tcl-format
msgid "Commit %s is already included in branch %s -- really re-apply it?"
-msgstr "Incheckningen %s finns redan på grenen %s -- skall den verkligen appliceras på nytt?"
+msgstr ""
+"Incheckningen %s finns redan på grenen %s -- skall den verkligen appliceras "
+"på nytt?"
-#: gitk:6369
+#: gitk:7564
msgid "Cherry-picking"
msgstr "Plockar"
-#: gitk:6381
+#: gitk:7576
msgid "No changes committed"
msgstr "Inga ändringar incheckade"
-#: gitk:6404
+#: gitk:7601
msgid "Confirm reset"
msgstr "Bekräfta återställning"
-#: gitk:6406
+#: gitk:7603
#, tcl-format
msgid "Reset branch %s to %s?"
msgstr "Återställa grenen %s till %s?"
-#: gitk:6410
+#: gitk:7607
msgid "Reset type:"
msgstr "Typ av återställning:"
-#: gitk:6414
+#: gitk:7611
msgid "Soft: Leave working tree and index untouched"
msgstr "Mjuk: Rör inte utcheckning och index"
-#: gitk:6417
+#: gitk:7614
msgid "Mixed: Leave working tree untouched, reset index"
msgstr "Blandad: Rör inte utcheckning, återställ index"
-#: gitk:6420
+#: gitk:7617
msgid ""
"Hard: Reset working tree and index\n"
"(discard ALL local changes)"
@@ -691,19 +728,19 @@ msgstr ""
"Hård: Återställ utcheckning och index\n"
"(förkastar ALLA lokala ändringar)"
-#: gitk:6436
+#: gitk:7633
msgid "Resetting"
msgstr "Återställer"
-#: gitk:6493
+#: gitk:7690
msgid "Checking out"
msgstr "Checkar ut"
-#: gitk:6523
+#: gitk:7741
msgid "Cannot delete the currently checked-out branch"
msgstr "Kan inte ta bort den just nu utcheckade grenen"
-#: gitk:6529
+#: gitk:7747
#, tcl-format
msgid ""
"The commits on branch %s aren't on any other branch.\n"
@@ -712,16 +749,16 @@ msgstr ""
"Incheckningarna på grenen %s existerar inte på någon annan gren.\n"
"Vill du verkligen ta bort grenen %s?"
-#: gitk:6560
+#: gitk:7778
#, tcl-format
msgid "Tags and heads: %s"
msgstr "Taggar och huvuden: %s"
-#: gitk:6574
+#: gitk:7792
msgid "Filter"
msgstr "Filter"
-#: gitk:6868
+#: gitk:8086
msgid ""
"Error reading commit topology information; branch and preceding/following "
"tag information will be incomplete."
@@ -729,117 +766,125 @@ msgstr ""
"Fel vid läsning av information om incheckningstopologi; information om "
"grenar och föregående/senare taggar kommer inte vara komplett."
-#: gitk:7852
+#: gitk:9072
msgid "Tag"
msgstr "Tagg"
-#: gitk:7852
+#: gitk:9072
msgid "Id"
msgstr "Id"
-#: gitk:7892
+#: gitk:9118
msgid "Gitk font chooser"
msgstr "Teckensnittsväljare för Gitk"
-#: gitk:7909
+#: gitk:9135
msgid "B"
msgstr "F"
-#: gitk:7912
+#: gitk:9138
msgid "I"
msgstr "K"
-#: gitk:8005
+#: gitk:9231
msgid "Gitk preferences"
msgstr "Inställningar för Gitk"
-#: gitk:8006
+#: gitk:9232
msgid "Commit list display options"
msgstr "Alternativ för incheckningslistvy"
-#: gitk:8009
+#: gitk:9235
msgid "Maximum graph width (lines)"
msgstr "Maximal grafbredd (rader)"
-#: gitk:8013
+#: gitk:9239
#, tcl-format
msgid "Maximum graph width (% of pane)"
msgstr "Maximal grafbredd (% av ruta)"
-#: gitk:8018
+#: gitk:9244
msgid "Show local changes"
msgstr "Visa lokala ändringar"
-#: gitk:8023
+#: gitk:9249
msgid "Auto-select SHA1"
msgstr "Välj SHA1 automatiskt"
-#: gitk:8028
+#: gitk:9254
msgid "Diff display options"
msgstr "Alternativ för diffvy"
-#: gitk:8030
+#: gitk:9256
msgid "Tab spacing"
msgstr "Blanksteg för tabulatortecken"
-#: gitk:8034
+#: gitk:9260
msgid "Display nearby tags"
msgstr "Visa närliggande taggar"
-#: gitk:8039
+#: gitk:9265
msgid "Limit diffs to listed paths"
msgstr "Begränsa diff till listade sökvägar"
-#: gitk:8044
+#: gitk:9272
+msgid "External diff tool"
+msgstr "Externt diff-verktyg"
+
+#: gitk:9274
+msgid "Choose..."
+msgstr "Välj..."
+
+#: gitk:9279
msgid "Colors: press to choose"
msgstr "Färger: tryck för att välja"
-#: gitk:8047
+#: gitk:9282
msgid "Background"
msgstr "Bakgrund"
-#: gitk:8051
+#: gitk:9286
msgid "Foreground"
msgstr "Förgrund"
-#: gitk:8055
+#: gitk:9290
msgid "Diff: old lines"
msgstr "Diff: gamla rader"
-#: gitk:8060
+#: gitk:9295
msgid "Diff: new lines"
msgstr "Diff: nya rader"
-#: gitk:8065
+#: gitk:9300
msgid "Diff: hunk header"
msgstr "Diff: delhuvud"
-#: gitk:8071
+#: gitk:9306
msgid "Select bg"
msgstr "Markerad bakgrund"
-#: gitk:8075
+#: gitk:9310
msgid "Fonts: press to choose"
msgstr "Teckensnitt: tryck för att välja"
-#: gitk:8077
+#: gitk:9312
msgid "Main font"
msgstr "Huvudteckensnitt"
-#: gitk:8078
+#: gitk:9313
msgid "Diff display font"
msgstr "Teckensnitt för diffvisning"
-#: gitk:8079
+#: gitk:9314
msgid "User interface font"
msgstr "Teckensnitt för användargränssnitt"
-#: gitk:8095
+#: gitk:9339
#, tcl-format
msgid "Gitk: choose color for %s"
msgstr "Gitk: välj färg för %s"
-#: gitk:8476
+#: gitk:9720
msgid ""
"Sorry, gitk cannot run with this version of Tcl/Tk.\n"
" Gitk requires at least Tcl/Tk 8.4."
@@ -847,41 +892,24 @@ msgstr ""
"Gitk kan tyvärr inte köra med denna version av Tcl/Tk.\n"
" Gitk kräver åtminstone Tcl/Tk 8.4."
-#: gitk:8565
+#: gitk:9812
msgid "Cannot find a git repository here."
msgstr "Hittar inget gitk-arkiv här."
-#: gitk:8569
+#: gitk:9816
#, tcl-format
msgid "Cannot find the git directory \"%s\"."
msgstr "Hittar inte git-katalogen \"%s\"."
-#: gitk:8612
+#: gitk:9853
#, tcl-format
msgid "Ambiguous argument '%s': both revision and filename"
msgstr "Tvetydigt argument \"%s\": både revision och filnamn"
-#: gitk:8624
+#: gitk:9865
msgid "Bad arguments to gitk:"
msgstr "Felaktiga argument till gitk:"
-#: gitk:8636
-msgid "Couldn't get list of unmerged files:"
-msgstr "Kunde inta hämta lista över ej sammanslagna filer:"
-
-#: gitk:8652
-msgid "No files selected: --merge specified but no files are unmerged."
-msgstr "Inga filer valdes: --merge angavs men det finns inga filer som inte har slagits samman."
-
-#: gitk:8655
-msgid ""
-"No files selected: --merge specified but no unmerged files are within file "
-"limit."
-msgstr ""
-"Inga filer valdes: --merge angavs men det finns inga filer inom "
-"filbegränsningen."
-
-#: gitk:8716
+#: gitk:9925
msgid "Command line"
msgstr "Kommandorad"
-
--
1.5.6.GIT
^ permalink raw reply related
* Re: small merge tool for temporary merges
From: Petr Baudis @ 2008-08-03 16:58 UTC (permalink / raw)
To: Marc Weber; +Cc: git
In-Reply-To: <20080803163415.GB14513@gmx.de>
Hi,
On Sun, Aug 03, 2008 at 06:34:15PM +0200, Marc Weber wrote:
> I'd like to announce the exisntance of my small git test merge tool.
>
> After reading
> Linux kernel mailing list may remember that Linus complained about such
> too frequent test merges when a subsystem maintainer asked to pull from
> a branch full of "useless merges"
> in the man page of git-rerere I had to start it..
>
> $ git clone git://mawercer.de/git-test-merge
for the mildly curious ones, your friendly gitweb provider service
offers
http://repo.or.cz/w/git-test-merge.git
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Tarmigan @ 2008-08-03 16:54 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Avery Pennarun, Eyvind Bernhardsen, Dmitry Potapov,
Johannes Schindelin, Joshua Jensen, Junio C Hamano, git
In-Reply-To: <56C07978-D6C9-4219-8B92-6217BD33F6D4@zib.de>
On Wed, Jul 30, 2008 at 12:25 PM, Steffen Prohaska <prohaska@zib.de> wrote:
>
> On Jul 30, 2008, at 8:33 PM, Avery Pennarun wrote:
>
>> On 7/30/08, Steffen Prohaska <prohaska@zib.de> wrote:
>>
>>> What matters is that git gives you exactly back what you committed. It
>>> does so with core.autocrlf=true, unless you check out with a different
>>> setting for autocrlf.
>>
>> You can tell that this statement isn't quite true because if you have
>> a file with mixed LF and CRLF line endings, which I do (thanks,
>> Windows!) then CRLF->LF conversion is not a reversible operation.
>> Interestingly LF->CRLF still is (because an LF->CRLF'd file will never
>> have a bare LF, and on such a subset of files, CRLF->LF is
>> reversible).
>>
>> Also note that core.autocrlf=input is *definitely* not a perfectly
>> reversible operation.
>
> You are absolutely right. The files your describe are modified by git,
> because they are "invalid" text files, as git defines them.
For all I care, git can consider the files as binary, but by *default*
I should get back the same as I put in.
[For the rest of my rant, I am referring to the default configuration
of autocrlf on windows]
> For git's
> autocrlf mechanism to work, a text file is only allowed to have a
> *single* type of line endings.
Git's autocrlf mechanism can be a nice feature. But by default it
should not be on (even on windows) because it can modify screw up my
files.
To be clear: when I say "git checkout" I want to get EXACTLY the same
bits as went in when I did "git add" and "git commit". Any other
default is broken.
> Otherwise it is broken and git tries to
> help you fixing it.
My files were NOT broken when I put them into git. I committed them
known good state. If msysgit changes them by *default* , then msysgit
is broken.
IF you are working on a cross platform project, then setting autocrlf
on windows might be nice. But having it on by *default* is broken.
Thanks,
Tarmigan
^ permalink raw reply
* small merge tool for temporary merges
From: Marc Weber @ 2008-08-03 16:34 UTC (permalink / raw)
To: git
Hi at all,
I'd like to announce the exisntance of my small git test merge tool.
After reading
Linux kernel mailing list may remember that Linus complained about such
too frequent test merges when a subsystem maintainer asked to pull from
a branch full of "useless merges"
in the man page of git-rerere I had to start it..
$ git clone git://mawercer.de/git-test-merge
============= =======================================================
small HOWTO:
$ alias gtm=git-test-merge
$ gtm h # show the help
$ gtm s mytestmerge branch{1,2} # define testmerge "mytestmerge" which is formed by merging branch1 and branch2
$ gtm u mytestmerge # merge first using octopus, if it fails merge with
# the previous merge result with next branch until
# no branches are left to merge
If the merge fails you can resolve the conflicts and run
$ gtm c # you don't have to git-add the resolved files, will be done by the script
I hope its useful for you as well. If you have patches you may push them
instantly.
If it's obsolete because there is a better tool I appreciat you pointing
me to it
Sincerly
Marc Weber
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-08-03 16:21 UTC (permalink / raw)
To: Eyvind Bernhardsen
Cc: Johannes Schindelin, Avery Pennarun, Joshua Jensen,
Junio C Hamano, git
In-Reply-To: <3687C337-63B7-4F3E-9682-8B140FFB4D53@orakel.ntnu.no>
On Sat, Aug 02, 2008 at 02:51:28PM +0200, Eyvind Bernhardsen wrote:
> On 30. juli. 2008, at 23.45, Dmitry Potapov wrote:
>
> >On Tue, Jul 29, 2008 at 11:17:23PM +0200, Eyvind Bernhardsen wrote:
> >>
> >>My point was that autocrlf penalises Windows users just as much as it
> >>does Linux users, so why should it be turned on by default on
> >>Windows?
> >
> >Because it does make sense on Windows (I mentioned some reasons for
> >that
> >in my previous email), and it does NOT make any sense on Linux unless
> >you copy files from Windows.
>
> It doesn't make any more sense on Windows than it does on Linux,
> unless the user is careless about CRLFs and the repository will be
> shared with Linux users.
It does, because LF is the only EOL that Git recognize internally,
and if CRLF sometimes works, but it is an artifact. With the same
success you can rely on a value of uninitialized variable or any
other kind of undefined behavior.
> If you have to work with undisciplined
> Windows users but don't actually use Windows yourself, it might _seem_
> to make sense, but that is an illusion.
Illusion? Is the most logical objection that you capable to produce
to all my explanation? I think it is very convenient approach, but
shall we follow it a bit further and declare all your problem with
line endings just an illusion...
> >You can compile it on Linux and Windows (using Microsoft Visual C).
> >Now, if you run it on Linux, it will print 13 symbols (exactly
> >as many as there are symbols in the printf string) while on Windows
> >you will get 14 bytes. It means that printf and as many other C
> >function on Windows does conversion and penalize you already!
>
> But I don't use printf to store files. What does printf have to do
> with anything?
You missed the point entirely, did you? LF is the standard EOL in C (as
well as in many other languages that is used by Git developers). Thus,
naturally Git internally considers only LF as the only true EOL, and if
it happened that you store files with different EOLs, they should be
converted during import to the Git repository. And, yes, C programs
do use printf and other C library functions to write text files...
Why do you think Microsoft C library does convert CRLF on reading and
writing for text files? Or that is another illusion?
> >>You can have anything you like in _your_ repository, of course, but
> >>if
> >>you're not publishing it anywhere, who cares what your line endings
> >>are? Your line endings only matter when you publish.
> >
> >You can publish only what you have. So, it must decided before.
>
> Yes! Someone should decide that the repository should only have LFs
> in it, then flag it as such so that Git can respect that decision.
What is your point?! Git *does* respect your autocrlf choice. But it
also respects *other* people choice to have what they want in *their*
repositories.
>
> >>That's why I
> >>want a setting that is propagated: so that when you clone a
> >>repository
> >>with a LF-only policy, Git knows what to do.
> >
> >LF-only policy is the only sane policy for any text files. It has
> >nothing
> >to do with clone.
>
> Gah! So close, but so far. What about a repository which already has
> CRLFs in it? You're telling me that it shouldn't have CRLFs in it,
> which is almost entirely unhelpful.
What I am saying is that having CRLF for text files is a mistake, and it
should be dealt as that. Perhaps, something can be added to help people
to deal with their past mistakes, but by no means, we should encourage
to produce more crap... So far, I have not heard any rational suggestion,
let alone seeing your code that implements it.
>
> My point is that if I commit two files with different line endings, I
> want Git to store them that way.
If you want something insane, you can have that, but the insane mode is
not for normal users. So, it should not be default.
> Works on Linux by default, doesn't
> work on Windows by default.
So what? Sane people do NOT store text files with different endings,
especially on Linux...
> >>>Of course, those who are very careful and have good editors can set
> >>>autocrlf=false even on Windows...
> >>
> >>Right, or who know that the repository they're using will only be
> >>shared with other Windows users.
> >
> >WRONG! Using storing CRLF in text files is a completely idiotic idea.
> >Those who do so asked for troubles, so they should not complain!
>
> But some text files need CRLFs, the autocrlf mechanism even caters for
> them. And it's not like the extra CR actually hurts anything; I use
> Git on Windows with "autocrlf=false", and I've yet to see any problems
> with it. The reason I've changed from the default "autocrlf=true" is
> that I've seen plenty of problems with that.
What problems? Isn't true that these problems were caused in the first
place by having autocrlf=false? If you prefer CRLF for your text files
what exactly is your problem with having crlf=true? Your old history?
But why should other users suffer because you have messed up file
endings in your repository?
Perhaps, it would be nicer if Git saved autocrlf when created a new
repository, so if the global setting is changed, it will not affect
already existing repositories. I believe something like that can be
added. In fact, Junio mentioned about this possibility before, but
you do not seem to care to do _anything_ to improve the situation,
and when I say to do something, I don't mean just empty flame.
>
> >>Internally, Git doesn't really care, does it?
> >
> >It DOES!!! Such things like merges and diffs and many other every day
> >commands do care about end-of-lines and the ONLY end-of-line they
> >recognize is '\n'. In fact, there are more than 400 places in Git
> >where
> >'\n' is used. Of course, not all of them may be qualified as internals
> >but many of them do.
>
> Buh? That's crazy talk. The only time CRLFs cause trouble with git
> is when autocrlf is enabled. Try this:
>
>
> git init
> echo -n "testing\r\ntesting 2\r\n" > testing
> git add testing
> git commit
> git config --bool --add core.autocrlf true
> touch testing
> git diff
That is *exactly* why autocrlf=true should be default on Windows, as you
want to have at the very moment when a new repository is created! Thanks!
And, yes, the file is shown changed. You can have the same effect with
SVN if you did not set svn:eol-style=native when added a file and then
change it to svn:eol-style=native later. The issue here is that you have
wrong ending for text files in the first place.
> >So, as long as Git internally consider only LF as the end-of-line.
>
> Bah. To the extent it "cares", Git just sees CR as an extra white
> space character before the end-of-line LF, and you know it.
I know, and I also know that I don't like crap in my repository and
I don't like any tool that encourages users to put every crap in it.
And, no, I don't think that that check-in-all-crap-I-have should be
the default mode for Git. If you like that mode, you probably can set
autocrlf=false and also create some nice alias for git commit -a, so
you check-in all crap crap at once, but I can't care less about all
problems that you'll have after that.
>
> >>Heh. Where I work, we hacked CVS for Windows to get away from that
> >>behaviour :)
> >
> >Maybe, you used Cygwin version of CVS, which had LF, but those Windows
> >versions of CVS I used produced CRLF on Windows.
>
> No, we just compiled our own, precisely because we didn't want CVS to
> mangle our data, even on Windows.
*Shrug* All I can say I don't remember any problem like this with CVS,
and it did conversion automatically for us. Unfortunately, it converted
binary files too, so new users had to be taught about using 'cvs -kb'
or their binary files would be mutilated. So, I am pretty sure about
this. Perhaps, the difference was that we has always had our CVS server
on Linux, but we have not recompiled anything.
> The CVS repositories are used by
> Linux and Windows clients, and some developers had their working
> directories on cross-platform network shares, so eol conversion just
> caused unnecessary problems.
Sharing working directories is a real issue. I hit it myself once with
CVS. Fortunately, git provides a good solution: autocrlf=input.
>
> >>Well, what I want is to be able to say "it is necessary to do eol
> >>conversion in this repository",
> >
> >You always can do that in _your_ repository:
> >git config core.autocrlf ...
>
> I can, except that (a) any CRLFs already in the repository will cause
> trouble,
Sure, they will. It is insane ending to store in your repo. It was
exactly my point all way along, but somehow you missed that...
> and (b) everyone who clones from me has to make the same
> setting manually, or they won't follow the same convention.
If people follow sane settings, they do not have to change anything
manually, and they can edit file using *their* preferable EOLs. However,
if you publish a repo with CRLF for text files, *you* create problems
for other people, and they have every right to blame you for that.
>
> Yes. Other people may have other preferences which will lead them to
> push CRLFs to my repository. That is why the setting should be
> propagated.
Add the update hook, which will prevent pushes with the wrong ending.
>
> >>I want it to be versioned because you might want to change it without
> >>messing with the content that's already in the repository. This is
> >>actually my main motivation, since I have lots of CRLF-infused CVS
> >>history to deal with.
> >
> >Well, you can try to use .gitattributes, but I believe it would be far
> >more reasonable to clean this mess with line-ending than finding a
> >way to continue insanity with different ending in different text
> >files.
>
> But I'd rather not change the historical data in every repository. So
> yes, I think it's a good idea to clean up the line endings, but I
> would like to do it in a way that allows me to check out an old
> version with mixed line endings while still ensuring that newly
> committed files are normalised.
Well, I don't see much historical value in seeing what files had
what ending and at what time. So, usually, it is a good idea to
clean up them when you convert your repo into Git. But as I said
above, you can try to use .gitattributes.
Anyway, autocrlf=true makes much more sense as default, because
newly created repositories and files in them will have the correct
ending.
> >>It would probably be okay to have a setting that turns all
> >>conversion off, but wouldn't that be kind of rude?
> >
> >How so?
>
> You're explicitly saying "I don't care if I commit CRLFs into a
> repository that requests only LFs".
Naw! autocrlf=false means you take responsibility for EOL in files that
you check in. In fact, no version control system that can verify that
all what you check-in makes sense. So it can only _facilitate_ you in
creating good patches, but it cannot force you to do things in the right
way. Thus, any option that helps people to do their job is good, but you
cannot foresee all use cases, so it should be always choice to turn this
automatically thing off when it is necessary.
> So you're probably only saying it
> because you know you won't commit CRLFs anyway, but since the cost is
> so low, why not make sure?
Who are you to tell what cost is high and low? Why do you think that
you should dictate your idea of cost to *everyone*?
Dmitry
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Jonas Fonseca @ 2008-08-03 14:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, Scott Chacon, Junio C Hamano, git
In-Reply-To: <20080726203216.GV10151@machine.or.cz>
On Sat, Jul 26, 2008 at 10:32 PM, Petr Baudis <pasky@suse.cz> wrote:
> On Sat, Jul 26, 2008 at 01:24:05PM -0700, Jakub Narebski wrote:
>> P.S. What about http://git-scm.org/ ?
>
> This domain is kept by Jonas Fonseca and it seems to be used at
> occassions. It traditionally pointed to git.or.cz; thus I think it would
> make sense for it to keep following git.or.cz unless/until we decide to
> repoint that to git-scm.com. Jonas?
I claimed git-scm.org after the last survey since a few people
mentioned that they found the git.or.cz domain name a bit obscure. I
am aware that the my current lack of involvement in git development
(which is mostly limited to documentation improvements) and the
resulting possible lack of trust from the community has limited its
use. However, I hope that it can serve some purpose in the future
whether it will be as an alias or not. I have am open for suggestions,
but for now I trust you and will follow your advice in this matter.
--
Jonas Fonseca
^ permalink raw reply
* Re: [ANNOUNCE] TopGit - A different patch queue manager
From: Jon Smirl @ 2008-08-03 14:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080803031424.GV32184@machine.or.cz>
On 8/2/08, Petr Baudis <pasky@suse.cz> wrote:
> TopGit is meant as a fresh start in the steps of StGIT, quilt-in-git
> and others, of course in an attempt to Get It Right this time around.
> TopGit is absolutely minimal porcelain layer that will manage your
> patch queue for you using topic branches, one patch per branch.
> And do _ONLY_ that. Unlike with StGIT, you can actually use the index.
It is very helpful to block git commands that will mess up the state
of topgit. For example 'git rebase' is a good way to mess up stgit.
Instead you need to do 'stg rebase'. It is quite easy to type the
wrong command when switching between trees and some are under stgit
and others aren't.
I believe there is a stgit rewrite due any day now that completely
changes how it deals with the index.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH 5/5] add --no-filters option to git hash-object
From: Dmitry Potapov @ 2008-08-03 14:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, git, Eric Wong, Dmitry Potapov
In-Reply-To: <1217774182-28566-4-git-send-email-dpotapov@gmail.com>
If this option is given then the file is hashed as is ignoring all filters
specified in the configuration. This option is incompatible with --path
and --stdin-paths options.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
Documentation/git-hash-object.txt | 8 +++++++-
hash-object.c | 17 +++++++++++++----
t/t1007-hash-object.sh | 24 ++++++++++++++++++++++++
3 files changed, 44 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
index fececbf..340e49c 100644
--- a/Documentation/git-hash-object.txt
+++ b/Documentation/git-hash-object.txt
@@ -9,7 +9,7 @@ git-hash-object - Compute object ID and optionally creates a blob from a file
SYNOPSIS
--------
[verse]
-'git hash-object' [-t <type>] [-w] [--path=<file>] [--stdin] [--] <file>...
+'git hash-object' [-t <type>] [-w] [--path=<file>|--no-filters] [--stdin] [--] <file>...
'git hash-object' [-t <type>] [-w] --stdin-paths < <list-of-paths>
DESCRIPTION
@@ -47,6 +47,12 @@ OPTIONS
temporary files located outside of the working directory or files
read from stdin.
+--no-filters::
+ If this option is given then the file is hashed as is ignoring
+ all filters specified in the configuration, including crlf
+ conversion. If the file is read from standard input then no
+ filters is always implied unless the --path option is given.
+
Author
------
Written by Junio C Hamano <gitster@pobox.com>
diff --git a/hash-object.c b/hash-object.c
index b11f459..3070a3e 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -51,7 +51,7 @@ static void hash_stdin_paths(const char *type, int write_objects)
}
static const char * const hash_object_usage[] = {
- "git hash-object [-t <type>] [-w] [--path=<file>] [--stdin] [--] <file>...",
+ "git hash-object [-t <type>] [-w] [--path=<file>|--no-filters] [--stdin] [--] <file>...",
"git hash-object --stdin-paths < <list-of-paths>",
NULL
};
@@ -60,6 +60,7 @@ static const char *type;
static int write_object;
static int hashstdin;
static int stdin_paths;
+static int no_filters;
static const char *vpath;
static const struct option hash_object_options[] = {
@@ -67,6 +68,7 @@ static const struct option hash_object_options[] = {
OPT_BOOLEAN('w', NULL, &write_object, "write the object into the object database"),
OPT_BOOLEAN( 0 , "stdin", &hashstdin, "read the object from stdin"),
OPT_BOOLEAN( 0 , "stdin-paths", &stdin_paths, "read file names from stdin"),
+ OPT_BOOLEAN( 0 , "no-filters", &no_filters, "store file as is without filters"),
OPT_STRING( 0 , "path", &vpath, "file", "process file as it were from this path"),
OPT_END()
};
@@ -98,9 +100,15 @@ int main(int argc, const char **argv)
errstr = "Can't specify files with --stdin-paths";
else if (vpath)
errstr = "Can't use --stdin-paths with --path";
+ else if (no_filters)
+ errstr = "Can't use --stdin-paths with --no-filters";
+ }
+ else {
+ if (hashstdin > 1)
+ errstr = "Multiple --stdin arguments are not supported";
+ if (vpath && no_filters)
+ errstr = "Can't use --path with --no-filters";
}
- else if (hashstdin > 1)
- errstr = "Multiple --stdin arguments are not supported";
if (errstr) {
error (errstr);
@@ -115,7 +123,8 @@ int main(int argc, const char **argv)
if (0 <= prefix_length)
arg = prefix_filename(prefix, prefix_length, arg);
- hash_object(arg, type, write_object, vpath ? vpath : arg);
+ hash_object(arg, type, write_object,
+ no_filters ? NULL : vpath ? vpath : arg);
}
if (stdin_paths)
diff --git a/t/t1007-hash-object.sh b/t/t1007-hash-object.sh
index dbe1f04..12195a5 100755
--- a/t/t1007-hash-object.sh
+++ b/t/t1007-hash-object.sh
@@ -65,6 +65,14 @@ test_expect_success "Can't use --path with --stdin-paths" '
echo example | test_must_fail git hash-object --stdin-paths --path=foo
'
+test_expect_success "Can't use --stdin-paths with --no-filters" '
+ echo example | test_must_fail git hash-object --stdin-paths --no-filters
+'
+
+test_expect_success "Can't use --path with --no-filters" '
+ test_must_fail git hash-object --no-filters --path=foo
+'
+
# Behavior
push_repo
@@ -117,6 +125,22 @@ test_expect_success 'check that approperiate filter is invoke when --path is use
git config --unset core.autocrlf
'
+test_expect_success 'check that --no-filters option works' '
+ echo fooQ | tr Q "\\015" > file0 &&
+ cp file0 file1 &&
+ echo "file0 -crlf" > .gitattributes &&
+ echo "file1 crlf" >> .gitattributes &&
+ git config core.autocrlf true &&
+ file0_sha=$(git hash-object file0) &&
+ file1_sha=$(git hash-object file1) &&
+ test "$file0_sha" != "$file1_sha" &&
+ nofilters_file1=$(git hash-object --no-filters file1) &&
+ test "$file0_sha" = "$nofilters_file1" &&
+ nofilters_file1=$(cat file1 | git hash-object --stdin) &&
+ test "$file0_sha" = "$nofilters_file1" &&
+ git config --unset core.autocrlf
+'
+
pop_repo
for args in "-w --stdin" "--stdin -w"; do
--
1.6.0.rc1.58.gacdf
^ permalink raw reply related
* [PATCH 4/5] add --path option to git hash-object
From: Dmitry Potapov @ 2008-08-03 14:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, git, Eric Wong, Dmitry Potapov
In-Reply-To: <1217774182-28566-3-git-send-email-dpotapov@gmail.com>
The --path option allows to make filters work as if the file specified
while the actual its location may be different. It is mostly useful for
hashing temporary files outside of the working directory.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
Documentation/git-hash-object.txt | 12 +++++++++++-
hash-object.c | 19 +++++++++++++------
t/t1007-hash-object.sh | 24 ++++++++++++++++++++++++
3 files changed, 48 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
index a4703ec..fececbf 100644
--- a/Documentation/git-hash-object.txt
+++ b/Documentation/git-hash-object.txt
@@ -9,7 +9,7 @@ git-hash-object - Compute object ID and optionally creates a blob from a file
SYNOPSIS
--------
[verse]
-'git hash-object' [-t <type>] [-w] [--stdin] [--] <file>...
+'git hash-object' [-t <type>] [-w] [--path=<file>] [--stdin] [--] <file>...
'git hash-object' [-t <type>] [-w] --stdin-paths < <list-of-paths>
DESCRIPTION
@@ -37,6 +37,16 @@ OPTIONS
--stdin-paths::
Read file names from stdin instead of from the command-line.
+--path::
+ Hash object as it were located at the given path. The location of
+ file does not directly influence on the hash value, but path is
+ used to determine what git filters should be applied to the object
+ before it can be placed to the object database, and, as result of
+ applying filters, the actual blob put into the object database may
+ differ from the given file. This option is mainly useful for hashing
+ temporary files located outside of the working directory or files
+ read from stdin.
+
Author
------
Written by Junio C Hamano <gitster@pobox.com>
diff --git a/hash-object.c b/hash-object.c
index b658fae..b11f459 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -21,13 +21,14 @@ static void hash_fd(int fd, const char *type, int write_object, const char *path
printf("%s\n", sha1_to_hex(sha1));
maybe_flush_or_die(stdout, "hash to stdout");
}
-static void hash_object(const char *path, const char *type, int write_object)
+static void hash_object(const char *path, const char *type, int write_object,
+ const char *vpath)
{
int fd;
fd = open(path, O_RDONLY);
if (fd < 0)
die("Cannot open %s", path);
- hash_fd(fd, type, write_object, path);
+ hash_fd(fd, type, write_object, vpath);
}
static void hash_stdin_paths(const char *type, int write_objects)
@@ -43,14 +44,14 @@ static void hash_stdin_paths(const char *type, int write_objects)
die("line is badly quoted");
strbuf_swap(&buf, &nbuf);
}
- hash_object(buf.buf, type, write_objects);
+ hash_object(buf.buf, type, write_objects, buf.buf);
}
strbuf_release(&buf);
strbuf_release(&nbuf);
}
static const char * const hash_object_usage[] = {
- "git hash-object [-t <type>] [-w] [--stdin] [--] <file>...",
+ "git hash-object [-t <type>] [-w] [--path=<file>] [--stdin] [--] <file>...",
"git hash-object --stdin-paths < <list-of-paths>",
NULL
};
@@ -59,12 +60,14 @@ static const char *type;
static int write_object;
static int hashstdin;
static int stdin_paths;
+static const char *vpath;
static const struct option hash_object_options[] = {
OPT_STRING('t', NULL, &type, "type", "object type"),
OPT_BOOLEAN('w', NULL, &write_object, "write the object into the object database"),
OPT_BOOLEAN( 0 , "stdin", &hashstdin, "read the object from stdin"),
OPT_BOOLEAN( 0 , "stdin-paths", &stdin_paths, "read file names from stdin"),
+ OPT_STRING( 0 , "path", &vpath, "file", "process file as it were from this path"),
OPT_END()
};
@@ -84,6 +87,8 @@ int main(int argc, const char **argv)
if (write_object) {
prefix = setup_git_directory();
prefix_length = prefix ? strlen(prefix) : 0;
+ if (vpath && prefix)
+ vpath = prefix_filename(prefix, prefix_length, vpath);
}
if (stdin_paths) {
@@ -91,6 +96,8 @@ int main(int argc, const char **argv)
errstr = "Can't use --stdin-paths with --stdin";
else if (argc)
errstr = "Can't specify files with --stdin-paths";
+ else if (vpath)
+ errstr = "Can't use --stdin-paths with --path";
}
else if (hashstdin > 1)
errstr = "Multiple --stdin arguments are not supported";
@@ -101,14 +108,14 @@ int main(int argc, const char **argv)
}
if (hashstdin)
- hash_fd(0, type, write_object, NULL);
+ hash_fd(0, type, write_object, vpath);
for (i = 0 ; i < argc; i++) {
const char *arg = argv[i];
if (0 <= prefix_length)
arg = prefix_filename(prefix, prefix_length, arg);
- hash_object(arg, type, write_object);
+ hash_object(arg, type, write_object, vpath ? vpath : arg);
}
if (stdin_paths)
diff --git a/t/t1007-hash-object.sh b/t/t1007-hash-object.sh
index 6d505fa..dbe1f04 100755
--- a/t/t1007-hash-object.sh
+++ b/t/t1007-hash-object.sh
@@ -61,6 +61,10 @@ test_expect_success "Can't pass filenames as arguments with --stdin-paths" '
echo example | test_must_fail git hash-object --stdin-paths hello
'
+test_expect_success "Can't use --path with --stdin-paths" '
+ echo example | test_must_fail git hash-object --stdin-paths --path=foo
+'
+
# Behavior
push_repo
@@ -93,6 +97,26 @@ test_expect_success 'git hash-object --stdin file1 <file0 first operates on file
test "$obname1" = "$obname1new"
'
+test_expect_success 'check that approperiate filter is invoke when --path is used' '
+ echo fooQ | tr Q "\\015" > file0 &&
+ cp file0 file1 &&
+ echo "file0 -crlf" > .gitattributes &&
+ echo "file1 crlf" >> .gitattributes &&
+ git config core.autocrlf true &&
+ file0_sha=$(git hash-object file0) &&
+ file1_sha=$(git hash-object file1) &&
+ test "$file0_sha" != "$file1_sha" &&
+ path1_sha=$(git hash-object --path=file1 file0) &&
+ path0_sha=$(git hash-object --path=file0 file1) &&
+ test "$file0_sha" = "$path0_sha" &&
+ test "$file1_sha" = "$path1_sha" &&
+ path1_sha=$(cat file0 | git hash-object --path=file1 --stdin) &&
+ path0_sha=$(cat file1 | git hash-object --path=file0 --stdin) &&
+ test "$file0_sha" = "$path0_sha" &&
+ test "$file1_sha" = "$path1_sha" &&
+ git config --unset core.autocrlf
+'
+
pop_repo
for args in "-w --stdin" "--stdin -w"; do
--
1.6.0.rc1.58.gacdf
^ permalink raw reply related
* [PATCH 3/5] use parse_options() in git hash-object
From: Dmitry Potapov @ 2008-08-03 14:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, git, Eric Wong, Dmitry Potapov
In-Reply-To: <1217774182-28566-2-git-send-email-dpotapov@gmail.com>
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
hash-object.c | 122 +++++++++++++++++++++++++--------------------------------
1 files changed, 53 insertions(+), 69 deletions(-)
diff --git a/hash-object.c b/hash-object.c
index ac44b4e..b658fae 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -7,6 +7,7 @@
#include "cache.h"
#include "blob.h"
#include "quote.h"
+#include "parse-options.h"
static void hash_fd(int fd, const char *type, int write_object, const char *path)
{
@@ -48,87 +49,70 @@ static void hash_stdin_paths(const char *type, int write_objects)
strbuf_release(&nbuf);
}
-static const char hash_object_usage[] =
-"git hash-object [-t <type>] [-w] [--stdin] [--] <file>...\n"
-" or: git hash-object --stdin-paths < <list-of-paths>";
+static const char * const hash_object_usage[] = {
+ "git hash-object [-t <type>] [-w] [--stdin] [--] <file>...",
+ "git hash-object --stdin-paths < <list-of-paths>",
+ NULL
+};
-int main(int argc, char **argv)
+static const char *type;
+static int write_object;
+static int hashstdin;
+static int stdin_paths;
+
+static const struct option hash_object_options[] = {
+ OPT_STRING('t', NULL, &type, "type", "object type"),
+ OPT_BOOLEAN('w', NULL, &write_object, "write the object into the object database"),
+ OPT_BOOLEAN( 0 , "stdin", &hashstdin, "read the object from stdin"),
+ OPT_BOOLEAN( 0 , "stdin-paths", &stdin_paths, "read file names from stdin"),
+ OPT_END()
+};
+
+int main(int argc, const char **argv)
{
int i;
- const char *type = blob_type;
- int write_object = 0;
const char *prefix = NULL;
int prefix_length = -1;
- int no_more_flags = 0;
- int hashstdin = 0;
- int stdin_paths = 0;
+ const char *errstr = NULL;
+
+ type = blob_type;
git_config(git_default_config, NULL);
- for (i = 1 ; i < argc; i++) {
- if (!no_more_flags && argv[i][0] == '-') {
- if (!strcmp(argv[i], "-t")) {
- if (argc <= ++i)
- usage(hash_object_usage);
- type = argv[i];
- }
- else if (!strcmp(argv[i], "-w")) {
- if (prefix_length < 0) {
- prefix = setup_git_directory();
- prefix_length =
- prefix ? strlen(prefix) : 0;
- }
- write_object = 1;
- }
- else if (!strcmp(argv[i], "--")) {
- no_more_flags = 1;
- }
- else if (!strcmp(argv[i], "--help"))
- usage(hash_object_usage);
- else if (!strcmp(argv[i], "--stdin-paths")) {
- if (hashstdin) {
- error("Can't use --stdin-paths with --stdin");
- usage(hash_object_usage);
- }
- stdin_paths = 1;
-
- }
- else if (!strcmp(argv[i], "--stdin")) {
- if (stdin_paths) {
- error("Can't use %s with --stdin-paths", argv[i]);
- usage(hash_object_usage);
- }
- if (hashstdin)
- die("Multiple --stdin arguments are not supported");
- hashstdin = 1;
- }
- else
- usage(hash_object_usage);
- }
- else {
- const char *arg = argv[i];
-
- if (stdin_paths) {
- error("Can't specify files (such as \"%s\") with --stdin-paths", arg);
- usage(hash_object_usage);
- }
-
- if (hashstdin) {
- hash_fd(0, type, write_object, NULL);
- hashstdin = 0;
- }
- if (0 <= prefix_length)
- arg = prefix_filename(prefix, prefix_length,
- arg);
- hash_object(arg, type, write_object);
- no_more_flags = 1;
- }
+ argc = parse_options(argc, argv, hash_object_options, hash_object_usage, 0);
+
+ if (write_object) {
+ prefix = setup_git_directory();
+ prefix_length = prefix ? strlen(prefix) : 0;
}
- if (stdin_paths)
- hash_stdin_paths(type, write_object);
+ if (stdin_paths) {
+ if (hashstdin)
+ errstr = "Can't use --stdin-paths with --stdin";
+ else if (argc)
+ errstr = "Can't specify files with --stdin-paths";
+ }
+ else if (hashstdin > 1)
+ errstr = "Multiple --stdin arguments are not supported";
+
+ if (errstr) {
+ error (errstr);
+ usage_with_options(hash_object_usage, hash_object_options);
+ }
if (hashstdin)
hash_fd(0, type, write_object, NULL);
+
+ for (i = 0 ; i < argc; i++) {
+ const char *arg = argv[i];
+
+ if (0 <= prefix_length)
+ arg = prefix_filename(prefix, prefix_length, arg);
+ hash_object(arg, type, write_object);
+ }
+
+ if (stdin_paths)
+ hash_stdin_paths(type, write_object);
+
return 0;
}
--
1.6.0.rc1.58.gacdf
^ permalink raw reply related
* [PATCH 2/5] correct usage help string for git-hash-object
From: Dmitry Potapov @ 2008-08-03 14:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, git, Eric Wong, Dmitry Potapov
In-Reply-To: <1217774182-28566-1-git-send-email-dpotapov@gmail.com>
The usage string is corrected to make it fit in 80 columns and to make it
unequivocal about what options can be used with --stdin-paths.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
Documentation/git-hash-object.txt | 4 +++-
hash-object.c | 3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
index ac928e1..a4703ec 100644
--- a/Documentation/git-hash-object.txt
+++ b/Documentation/git-hash-object.txt
@@ -8,7 +8,9 @@ git-hash-object - Compute object ID and optionally creates a blob from a file
SYNOPSIS
--------
-'git hash-object' [-t <type>] [-w] [--stdin | --stdin-paths] [--] <file>...
+[verse]
+'git hash-object' [-t <type>] [-w] [--stdin] [--] <file>...
+'git hash-object' [-t <type>] [-w] --stdin-paths < <list-of-paths>
DESCRIPTION
-----------
diff --git a/hash-object.c b/hash-object.c
index ce027b9..ac44b4e 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -49,7 +49,8 @@ static void hash_stdin_paths(const char *type, int write_objects)
}
static const char hash_object_usage[] =
-"git hash-object [ [-t <type>] [-w] [--stdin] <file>... | --stdin-paths < <list-of-paths> ]";
+"git hash-object [-t <type>] [-w] [--stdin] [--] <file>...\n"
+" or: git hash-object --stdin-paths < <list-of-paths>";
int main(int argc, char **argv)
{
--
1.6.0.rc1.58.gacdf
^ permalink raw reply related
* [PATCH 1/5] correct argument checking test for git hash-object
From: Dmitry Potapov @ 2008-08-03 14:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, git, Eric Wong, Dmitry Potapov
In-Reply-To: <20080803055602.GN7008@dpotapov.dyndns.org>
Because the file name given to stdin did not exist, git hash-object
will fail to open it and exit with non-zero error code even if there
is no check of arguments. Thus the test may pass despite the obvious
error in argument checking.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
t/t1007-hash-object.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t1007-hash-object.sh b/t/t1007-hash-object.sh
index 1ec0535..6d505fa 100755
--- a/t/t1007-hash-object.sh
+++ b/t/t1007-hash-object.sh
@@ -49,16 +49,16 @@ setup_repo
# Argument checking
test_expect_success "multiple '--stdin's are rejected" '
- test_must_fail git hash-object --stdin --stdin < example
+ echo example | test_must_fail git hash-object --stdin --stdin
'
test_expect_success "Can't use --stdin and --stdin-paths together" '
- test_must_fail git hash-object --stdin --stdin-paths &&
- test_must_fail git hash-object --stdin-paths --stdin
+ echo example | test_must_fail git hash-object --stdin --stdin-paths &&
+ echo example | test_must_fail git hash-object --stdin-paths --stdin
'
test_expect_success "Can't pass filenames as arguments with --stdin-paths" '
- test_must_fail git hash-object --stdin-paths hello < example
+ echo example | test_must_fail git hash-object --stdin-paths hello
'
# Behavior
--
1.6.0.rc1.58.gacdf
^ permalink raw reply related
* Re: [PATCH] [TopGit] Check for pre-commit hook existence.
From: Petr Baudis @ 2008-08-03 14:26 UTC (permalink / raw)
To: Russell Steicke; +Cc: git
In-Reply-To: <20080803141030.GC11179@maggie.localnet>
On Sun, Aug 03, 2008 at 10:14:01PM +0800, Russell Steicke wrote:
> Running tg in a repo without an active pre-commit hook fails
> saying
>
> grep: .git/hooks/pre-commit: No such file or directory
> cat: .git/hooks/pre-commit: No such file or directory
>
> Even "tg help" does this! So add extra checks for existence
> of the pre-commit hook.
Thanks, applied.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] Update to it.po
From: Michele Ballabio @ 2008-08-03 14:24 UTC (permalink / raw)
To: Paolo Ciarrocchi, spearce; +Cc: git
In-Reply-To: <4d8e3fd30808030516g64f5cdb7r884632ac109063cb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
On Sunday 03 August 2008, Paolo Ciarrocchi wrote:
> > Here is a patch against current master (attached to prevent encoding issues).
> >
> > The strings missing translation now is "Buckets". I know what
> > it means but I can't came up with a translation that I like.
>
> Confused. Even in the repo i used buckets was the only missing translation.
> If you look at my patch:
>
> #: lib/choose_repository.tcl:628
> msgid "buckets"
> -msgstr ""
> +msgstr "buckets"
>
> you'll notice that we agree on not translating that word :)
Ok, but translating it with "buckets" has no real sense since it is not
commonly used in Italian, IMO. I'd leave it empty (the default English
word - "buckets" - will show up anyway) and hope that someone will come up
with an idea :)
> That said, I'd like too see the following hunk be part of your patch as well:
> #: lib/spellcheck.tcl:80
> -#, fuzzy
> msgid "Unrecognized spell checker"
> -msgstr "Correttore ortografico sconosciuto"
> +msgstr "Correttore ortografico non riconosciuto"
Ok, done in this version (attached).
> Can you please clarify how you are working on the po file?
> I was used to use gtransalator and I'm a bit confused by hunks like
> the following:
> -#: lib/option.tcl:192
> +#: lib/option.tcl:194
Some explanation is in po/README. The workflow is/should be:
* normal development in git-gui.git happens
* nearing a release, Shawn updates po/git-gui.pot
* all translators update their po/*.po files with
$ msgmerge -U po/it.po po/git-gui.pot
where "it" is an example. This command updates strings and line numbers
in the .po file (as in the two lines you quoted), and adds "fuzzy"
to old/machine-guessed translations.
* now the translator can use his tool of choice (but nearly any editor
should do) to search for fuzzy or new strings and update it all.
[-- Attachment #2: 0001-git-gui-update-po-it.po.patch.gz --]
[-- Type: application/x-gzip, Size: 8766 bytes --]
^ permalink raw reply
* [PATCH] [TopGit] Check for pre-commit hook existence.
From: Russell Steicke @ 2008-08-03 14:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080803031424.GV32184@machine.or.cz>
Running tg in a repo without an active pre-commit hook fails
saying
grep: .git/hooks/pre-commit: No such file or directory
cat: .git/hooks/pre-commit: No such file or directory
Even "tg help" does this! So add extra checks for existence
of the pre-commit hook.
---
tg.sh | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/tg.sh b/tg.sh
index 56c5709..15005db 100644
--- a/tg.sh
+++ b/tg.sh
@@ -21,9 +21,11 @@ die()
setup_hook()
{
hook_call="\"\$(tg --hooks-path)\"/$1 \"\$@\""
- if fgrep -q "$hook_call" "$git_dir/hooks/$1"; then
- # Another job well done!
- return
+ if [ -x "$git_dir/hooks/$1" ]; then
+ if fgrep -q "$hook_call" "$git_dir/hooks/$1"; then
+ # Another job well done!
+ return
+ fi
fi
# Prepare incanation
if [ -x "$git_dir/hooks/$1" ]; then
@@ -35,7 +37,7 @@ setup_hook()
{
echo "#!/bin/sh"
echo "$hook_call"
- cat "$git_dir/hooks/$1"
+ [ -x "$git_dir/hooks/$1" ] && cat "$git_dir/hooks/$1"
} >"$git_dir/hooks/$1+"
chmod a+x "$git_dir/hooks/$1+"
mv "$git_dir/hooks/$1+" "$git_dir/hooks/$1"
--
1.6.0.rc1
--
Russell Steicke
-- Fortune says:
I got the bill for my surgery. Now I know what those doctors were
wearing masks for.
-- James Boren
^ 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