* Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-18 22:43 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: Petr Baudis, git
In-Reply-To: <200903182258.31113.agruen@suse.de>
Hi
On Wed, 18 Mar 2009, Andreas Gruenbacher wrote:
> On Wednesday, 18 March 2009 22:46:22 Johannes Schindelin wrote:
> > Suggested by Pasky.
>
> Works here now. Thanks a lot!
You're welcome! Was fun, too...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-gui: minor spelling fix and string factorisation.
From: Sam Hocevar @ 2009-03-18 22:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdq6bgzv.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 18, 2009, Junio C Hamano wrote:
> Don't you also need to adjust the existing translations if you are
> changing the key strings used by mc?
I assumed a typical workflow where the translation coordinator
decides when to update .pot (typically at string freeze before a
release). I can provide the appropriate patch nonetheless.
--
Sam.
^ permalink raw reply
* Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-18 22:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Andreas Gruenbacher, git
In-Reply-To: <7vr60ubgul.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 18 Mar 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Suggested by Pasky.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> In the longer term who suggested matters much less than why such a
> feature is desirable, how it is used, and without it what is impossible
> and/or cumbersome. What's the motivation behind this?
>
> You do not have to explain it to me, but you should explain it to the
> history that records this commit, and to the users who read doccos.
And that's not all... Documentation updates and tests for % and %<branch>
are missing, too.
My main motivation to make this patch was to see how fast I could come up
with something working that does not hurt my eyes.
But I do not have time to do more today: My main project as well as Git
got accepted into the Google Summer of Code program, so I am even more
swamped than usually.
So... if anybody feels like it, I would be very thankful for a proper
commit message, documentation and tests...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 00/11] Test on Windows - prequel
From: Junio C Hamano @ 2009-03-18 22:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <cover.1237410682.git.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> t7300: fix clean up on Windows
>
> Johannes Sixt (9):
> t9400, t9401: Do not force hard-linked clone
> test suite: Use 'say' to say something instead of
> 'test_expect_success'
> Call 'say' outside test_expect_success
> test-lib: Replace uses of $(expr ...) by POSIX shell features.
> test-lib: Simplify test counting.
> test-lib: Introduce test_chmod and use it instead of update-index
> --chmod
> t2200, t7004: Avoid glob pattern that also matches files
> t5300, t5302, t5303: Do not use /dev/zero
> t5602: Work around path mangling on MSYS
Do you have an 11-patch series, or 10-patch series with a cover letter? I
am wondering what happened to [PATCH 11/11].
^ permalink raw reply
* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
From: Amos King @ 2009-03-18 22:41 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0903171206490.19665@iabervon.org>
I got push working. I wanted to ask one thing before I submit. I
know that it is nice to keep changes local. There is a method in
remote.c called add_url, but it is not exposed. Right now to keep the
changes local I moved the internals of that method inline, but is it
ok for me to expose that method instead?
Amos
PS - Junio sorry for the double send. I didn't notice that we weren't
on the list.
On Tue, Mar 17, 2009 at 11:24 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Mon, 16 Mar 2009, Junio C Hamano wrote:
>
>> Amos King <amos.l.king@gmail.com> writes:
>>
>> > Junio,
>> >
>> > I'm working with Mike on the http auth stuff, and I was testing out
>> > your patch. I can get it to work for fetch but push is giving me some
>> > grief. Looking through the code I noticed that online 219 of
>> > http-push.c that http_init is being called with NULL instead of a
>> > remote. If I pass in the remote then there is no remotre-url. I've
>> > been digging around and can't find where or when that is being set.
>> > It has been a while since I worked with C but I'd love to jump in and
>> > help out here. Can you point me in the right direction to get the
>> > remote->url[0] set for the http_auth_init to use?
>>
>> Daniel is the primary culprit who introduced the transport abstraction,
>> and I think he muttered something about his work-in-progress that involves
>> in some change in the API. Perhaps he has some insights here?
>>
>> Naah. I forgot that the transport abstraction on the fetch side is much
>> more integrated but curl_transport_push() simply launches http-push.c that
>> has a world on its own. Worse yet, "remote" in http-push.c is not even
>> the "struct remote"; it is something private to http-push.c called "struct
>> repo".
>>
>> I am not sure how much work would be involved in converting (or if it is
>> even worth to convert) http-push.c to fit better into the transport API,
>> but if that is feasible, it might be a better longer-term solution.
>
> I think it would be a good thing to do. With the new transport push
> method, it could even get support for updating the tracking refs that
> track the refs you changed, since I broke that out of the git-native
> protocol code and into the transport code.
>
> My guess is that converting http-push to be called in-process would
> actually be pretty easy, because the two sides don't look at the same data
> currently. (Some things were tricky with fetch, because the same process
> sometimes wants to do fetches multiple times, for getting tags; this isn't
> as big a deal.)
>
> I think it should just be a matter of breaking http-push's main() into a
> function that deals with the http-push command line and a function that
> does the work, setting up a header file like send-pack.h, and changing
> transport.c to just call the function.
>
>> Right now, builtin-push.c does all the remote inspection and when
>> http-push is called, the latter gets the information at the lowest level
>> only; the higher level information such as what nickname was used by the
>> user to initiate the "git push" process and whether the refspecs came from
>> the command line or from the config are all lost, which is quite sad.
>
> What I did short-term for the send-pack version was introduce an optional
> command line argument, "--remote", that names the remote used, so the
> other program could get the configuration as well. It's a pretty easy
> step, but I don't think it's too worthwhile in this case.
>
>> But as a much lower impact interim solution, I suspect that you can fake a
>> minimally usable remote. The http_push() codepath only cares about
>> remote->http_proxy and remote->url settings as far as I can tell, so
>> perhaps you can start (with a big warning that the remote you are creating
>> is a fake one) by filling the absolute minimum?
>>
>> That is, something along these lines (this comes on top of an obvious
>> patch that renames existing "remote" variable in http-push. to "repo").
>>
>> diff --git a/http-push.c b/http-push.c
>> index dfbb247..f04ac74 100644
>> --- a/http-push.c
>> +++ b/http-push.c
>> @@ -2197,6 +2197,7 @@ int main(int argc, char **argv)
>> int new_refs;
>> struct ref *ref;
>> char *rewritten_url = NULL;
>> + struct remote *remote;
>>
>> git_extract_argv0_path(argv[0]);
>>
>> @@ -2258,12 +2259,14 @@ int main(int argc, char **argv)
>> if (!repo->url)
>> usage(http_push_usage);
>>
>> + remote = remote_get(repo->url);
>> +
>> if (delete_branch && nr_refspec != 1)
>> die("You must specify only one branch name when deleting a remote branch");
>>
>> memset(remote_dir_exists, -1, 256);
>>
>> - http_init(NULL);
>> + http_init(remote);
>>
>> no_pragma_header = curl_slist_append(no_pragma_header, "Pragma:");
>
> This should work, although it obviously won't figure out the proxy for the
> configuration for the remote that was actually used.
>
> -Daniel
> *This .sig left intentionally blank*
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Amos King
http://dirtyInformation.com
http://github.com/Adkron
--
Looking for something to do? Visit http://ImThere.com
^ permalink raw reply
* Re: [PATCH] git-gui: minor spelling fix and string factorisation.
From: Shawn O. Pearce @ 2009-03-18 22:54 UTC (permalink / raw)
To: Sam Hocevar; +Cc: Junio C Hamano, git
In-Reply-To: <20090318224301.GH27280@zoy.org>
Sam Hocevar <sam@zoy.org> wrote:
> On Wed, Mar 18, 2009, Junio C Hamano wrote:
>
> > Don't you also need to adjust the existing translations if you are
> > changing the key strings used by mc?
>
> I assumed a typical workflow where the translation coordinator
> decides when to update .pot (typically at string freeze before a
> release). I can provide the appropriate patch nonetheless.
Well, we are only adjusting the English translation. The .pot
and .po files use the English translation as the message keys.
I don't see a reason why we can't fix them for the translators
when the message keys are being modified in ways that shouldn't
impact the translated text.
Unless the translators translated the typos. I doubt they did.
--
Shawn.
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-18 23:16 UTC (permalink / raw)
To: saurabh gupta; +Cc: david, Junio C Hamano, git
In-Reply-To: <ab9fa62a0903121303v5a6cbf0ax413cc440b9c32e77@mail.gmail.com>
Hi,
On Fri, 13 Mar 2009, saurabh gupta wrote:
> On Fri, Mar 13, 2009 at 1:29 AM, <david@lang.hm> wrote:
> > On Fri, 13 Mar 2009, saurabh gupta wrote:
> >
> >> Very well described, David. I agree with you and providing these
> >> merge options to the user, merge drivers can do the work and mark the
> >> conflicts according to the option. The work to do is to modify the
> >> merge driver. I think in this way, even people who have only a
> >> terminal can also gain from it. They can choose the apt option to see
> >> the conflict markers in their way. So, the aim is to make merge
> >> driver configurable and create the merged/conflicted file according
> >> to the options.
> >
> > for the GSOC I suspect that the right thing to do is the define one or
> > more merge drivers to create, and list what applications are going to
> > be used for testing these merges.
> >
> > you and the mentor can decide what is a reasonable amount of work.
>
> I will very glad to hear about this thing from the mentor (Johannes
> Schindelin, according to wiki). I will try to plan out the things in a
> proper way to carry out this project if I get a chance to work on this
> for GSoC 2009.
Well, now that we have been accepted as an organization, we can move
forward with this idea!
My main concern is that we define early on what should be the user
interface, preferably with a quick sketch.
The technical details, we can hash them out later, I have no doubt that
with the help of the complete Git community, we can overcome almost every
problem handling XML data or some such.
> > it may be just doing an XML merge driver is a summer's worth of work,
> > or it may be that it's not really enough and you should try to do
> > another one or two.
> >
> > it also may be that there is a lot of overlap between different merge
> > drivers, and once you have the XML driver the others become fairly
> > trivial to do. (I'm thinking the config file examples I posted earlier
> > in the thread)
>
> with the options given to the user, one can handle the config files
> also where order doesn't matter and also the whitespaces problem can
> also be handled in the similar way.
In my humble opinion, we should focus on the data types we want to be
able to support at the end of the summer first.
For example, if we decide that OOXML is a must (as it is a proper
standard, and many people will benefit from it), we will most likely end
up in having to write a merge _driver_ (to handle those .zip files), _and_
a merge _helper_, although we can avoid writing our own GUI, as we can
create an OOXML that has its own version of conflict markers.
If we decide that SVG is something we want to support by the end of the
summer, then we can probably avoid writing a merge _driver_, as plain text
is handled reasonably well in Git. OTOH it could turn out that there are
_real_ conflicts in overlapping tag ids, and it would still be easier to
write a merge driver, too.
IOW the details are not as important as
- knowing what data types we want to support _at the least_, and what data
types we keep for the free skate,
- a clear picture of the user interface we want to be able to provide,
- a timeline (weekly milestones should be fine, I guess) what should be
achieved when, and
- being flexible in how to support that (IOW if a merge driver appears
unnecessary first, but necessary later, we should be able to fit that
into both the design and the timeline).
How does that sound?
Ciao,
Dscho
^ permalink raw reply
* git cvsserver and database permissions
From: Samuel Lucas Vaz de Mello @ 2009-03-18 23:20 UTC (permalink / raw)
To: git
Hi
I'm trying to set up git cvsserver in a shared repository.
It works very well, but the database file for each branch (for example "gitcvs.master.sqlite") is created by the first user which access it and without group-write permissions, then I have to manually fix the permissions.
Shouldn't it honor core.sharedrepository?
Is there any place where I can configure it to create files with group-write permissions?
Thank you,
- Samuel
^ permalink raw reply
* [PATCHv2] git-gui: minor spelling fix and string factorisation.
From: Sam Hocevar @ 2009-03-18 23:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce
In-Reply-To: <20090318225423.GI23521@spearce.org>
Properly spell "successful" and slightly rewrite a couple of strings
that actually say the same thing in order to reduce translation work.
Update .pot and .po files accordingly since no new translation is
required.
Signed-off-by: Sam Hocevar <sam@zoy.org>
---
This new version of the patch updates .po and .pot files, following
Junio's and Shawn's wishes.
lib/branch_delete.tcl | 4 ++--
lib/remote_branch_delete.tcl | 4 +---
lib/tools.tcl | 2 +-
po/de.po | 12 +-----------
po/fr.po | 12 +-----------
po/git-gui.pot | 9 +--------
po/hu.po | 12 +-----------
po/it.po | 12 +-----------
po/ja.po | 12 +-----------
po/nb.po | 12 +-----------
po/ru.po | 10 ----------
po/sv.po | 12 +-----------
po/zh_cn.po | 10 ----------
13 files changed, 12 insertions(+), 111 deletions(-)
diff --git a/lib/branch_delete.tcl b/lib/branch_delete.tcl
index ef1930b..20d5e42 100644
--- a/lib/branch_delete.tcl
+++ b/lib/branch_delete.tcl
@@ -51,7 +51,7 @@ constructor dialog {} {
$w.check \
[mc "Delete Only If Merged Into"] \
]
- $w_check none [mc "Always (Do not perform merge test.)"]
+ $w_check none [mc "Always (Do not perform merge checks)"]
pack $w.check -anchor nw -fill x -pady 5 -padx 5
foreach h [load_all_heads] {
@@ -112,7 +112,7 @@ method _delete {} {
}
if {$to_delete eq {}} return
if {$check_cmt eq {}} {
- set msg [mc "Recovering deleted branches is difficult. \n\n Delete the selected branches?"]
+ set msg [mc "Recovering deleted branches is difficult.\n\nDelete the selected branches?"]
if {[tk_messageBox \
-icon warning \
-type yesno \
diff --git a/lib/remote_branch_delete.tcl b/lib/remote_branch_delete.tcl
index 89eb0f7..4e02fc0 100644
--- a/lib/remote_branch_delete.tcl
+++ b/lib/remote_branch_delete.tcl
@@ -213,9 +213,7 @@ method _delete {} {
-type yesno \
-title [wm title $w] \
-parent $w \
- -message [mc "Recovering deleted branches is difficult.
-
-Delete the selected branches?"]] ne yes} {
+ -message [mc "Recovering deleted branches is difficult.\n\nDelete the selected branches?"]] ne yes} {
return
}
diff --git a/lib/tools.tcl b/lib/tools.tcl
index 6ae63b6..95e6e55 100644
--- a/lib/tools.tcl
+++ b/lib/tools.tcl
@@ -146,7 +146,7 @@ proc tools_complete {fullname w {ok 1}} {
}
if {$ok} {
- set msg [mc "Tool completed succesfully: %s" $fullname]
+ set msg [mc "Tool completed successfully: %s" $fullname]
} else {
set msg [mc "Tool failed: %s" $fullname]
}
diff --git a/po/de.po b/po/de.po
index a6f730b..51abb50 100644
--- a/po/de.po
+++ b/po/de.po
@@ -773,16 +773,6 @@ msgstr "Immer (ohne Zusammenführungstest)"
msgid "The following branches are not completely merged into %s:"
msgstr "Folgende Zweige sind noch nicht mit »%s« zusammengeführt:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"Gelöschte Zweige können nur mit größerem Aufwand wiederhergestellt werden.\n"
-"\n"
-"Gewählte Zweige jetzt löschen?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2506,7 +2496,7 @@ msgstr "Starten: %s"
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "Werkzeug erfolgreich abgeschlossen: %s"
#: lib/tools.tcl:151
diff --git a/po/fr.po b/po/fr.po
index eb5f68e..2abf524 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -780,16 +780,6 @@ msgstr "Toujours (Ne pas faire de test de fusion.)"
msgid "The following branches are not completely merged into %s:"
msgstr "Les branches suivantes ne sont pas complètement fusionnées dans %s :"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"Il est difficile de récupérer des branches supprimées.\n"
-"\n"
-"Supprimer les branches sélectionnées ?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2412,7 +2402,7 @@ msgstr "Lancement de : %s"
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "L'outil a terminé avec succès : %s"
#: lib/tools.tcl:151
diff --git a/po/git-gui.pot b/po/git-gui.pot
index 15aea0d..53b7d36 100644
--- a/po/git-gui.pot
+++ b/po/git-gui.pot
@@ -753,13 +753,6 @@ msgstr ""
msgid "The following branches are not completely merged into %s:"
msgstr ""
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2220,7 +2213,7 @@ msgstr ""
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr ""
#: lib/tools.tcl:151
diff --git a/po/hu.po b/po/hu.po
index f761b64..0f87bc1 100644
--- a/po/hu.po
+++ b/po/hu.po
@@ -776,16 +776,6 @@ msgstr "Mindig (Ne legyen merge teszt.)"
msgid "The following branches are not completely merged into %s:"
msgstr "A következő branchek nem teljesen lettek merge-ölve ebbe: %s:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"A törölt branchek visszaállítása bonyolult. \n"
-"\n"
-" Biztosan törli a kiválasztott brancheket?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2399,7 +2389,7 @@ msgstr "Futtatás: %s..."
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "Az eszköz sikeresen befejeződött: %s"
#: lib/tools.tcl:151
diff --git a/po/it.po b/po/it.po
index 294e595..762632c 100644
--- a/po/it.po
+++ b/po/it.po
@@ -778,16 +778,6 @@ msgstr "Sempre (Non effettuare verifiche di fusione)."
msgid "The following branches are not completely merged into %s:"
msgstr "I rami seguenti non sono stati fusi completamente in %s:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"Ricomporre rami cancellati può essere complicato. \n"
-"\n"
-" Eliminare i rami selezionati?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2418,7 +2408,7 @@ msgstr "Eseguo: %s"
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "Il programma esterno è terminato con successo: %s"
#: lib/tools.tcl:151
diff --git a/po/ja.po b/po/ja.po
index 09d60be..63c4695 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -773,16 +773,6 @@ msgstr "無条件(マージテストしない)"
msgid "The following branches are not completely merged into %s:"
msgstr "以下のブランチは %s に完全にマージされていません:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"ブランチを削除すると元に戻すのは困難です。 \n"
-"\n"
-" 選択したブランチを削除しますか？"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2382,7 +2372,7 @@ msgstr "実行中: %s"
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "ツールが完了しました: %s"
#: lib/tools.tcl:151
diff --git a/po/nb.po b/po/nb.po
index 1c5137d..6de93c2 100644
--- a/po/nb.po
+++ b/po/nb.po
@@ -761,16 +761,6 @@ msgstr "Alltid (Ikke utfør sammenslåingstest.)"
msgid "The following branches are not completely merged into %s:"
msgstr "Følgende grener er ikke fullstendig slått sammen med %s:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"Gjenoppretting av fjernede grener er vanskelig. \n"
-"\n"
-" Fjern valgte grener?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2331,7 +2321,7 @@ msgstr "Kjører: %s"
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "Verktøyet ble fullført med suksess: %s"
#: lib/tools.tcl:151
diff --git a/po/ru.po b/po/ru.po
index db55b3e..04df2aa 100644
--- a/po/ru.po
+++ b/po/ru.po
@@ -661,16 +661,6 @@ msgstr "Всегда (не выполнять проверку на объеди
msgid "The following branches are not completely merged into %s:"
msgstr "Следующие ветви объединены с %s не полностью:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"Восстанавливать удаленные ветви сложно. \n"
-"\n"
-" Удалить выбранные ветви?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
diff --git a/po/sv.po b/po/sv.po
index 167654c..c1535f9 100644
--- a/po/sv.po
+++ b/po/sv.po
@@ -780,16 +780,6 @@ msgstr "Alltid (utför inte sammanslagningstest)."
msgid "The following branches are not completely merged into %s:"
msgstr "Följande grenar är inte till fullo sammanslagna med %s:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"Det är svårt att återställa borttagna grenar.\n"
-"\n"
-" Ta bort valda grenar?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2398,7 +2388,7 @@ msgstr "Exekverar: %s"
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "Verktyget avslutades framgångsrikt: %s"
#: lib/tools.tcl:151
diff --git a/po/zh_cn.po b/po/zh_cn.po
index d2c6866..91c1be2 100644
--- a/po/zh_cn.po
+++ b/po/zh_cn.po
@@ -676,16 +676,6 @@ msgstr "总是合并 (不作合并测试.)"
msgid "The following branches are not completely merged into %s:"
msgstr "下列分支没有完全被合并到 %s:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"恢复被删除的分支非常困难.\n"
-"\n"
-"是否要删除所选分支?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
--
1.6.2.1
^ permalink raw reply related
* git svn unhandled.log compression
From: Tim Blechmann @ 2009-03-18 23:30 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 880 bytes --]
hi all,
is there a way to compress the unhandled.log files, generated by git svn?
tracking several projects with git svn, the unhandled.log files are
larger, than the actual data ...
e.g. the mirror of the svn repository of the boost library gives me:
135M .git/objects
283M .git/svn
the unhandled.log files can be compressed at pretty high rates, these
are the differently compressed files from the trunk of boost svn:
9.0M unhandled.log
584K unhandled.log.gz
396K unhandled.log.bz2
344K unhandled.log.lzma
i am not familiar with the git svn codebase, so i am not sure, whether
it is feasible to implement a compression of the unhandled.log files,
but it would definitely save me quite a lot of hd space ...
thnx, tim
--
tim@klingt.org
http://tim.klingt.org
The most wonderful opportunity which life offers is to be human.
Henry Miller
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 1/2] Changed remote in push_http.c to repo so it won't be confused with how remote is used else where in the system.
From: Amos King @ 2009-03-18 23:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This patch is a first step in getting http-push to use http
authentication via prompts. The patch renames remote to repo so that
it doesn't get confusing with the same remote that is passed around
when using http.
This is just recreating a patch from Junio that I couldn't get to apply locally.
Signed-off-by: Amos King <amos.l.king@gmail.com>
---
http-push.c | 154 +++++++++++++++++++++++++++++-----------------------------
1 files changed, 77 insertions(+), 77 deletions(-)
diff --git a/http-push.c b/http-push.c
index 48e5f38..9ac2664 100644
--- a/http-push.c
+++ b/http-push.c
@@ -97,7 +97,7 @@ struct repo
struct remote_lock *locks;
};
-static struct repo *remote;
+static struct repo *repo;
enum transfer_state {
NEED_FETCH,
@@ -324,7 +324,7 @@ static void start_fetch_loose(struct
transfer_request *request)
git_SHA1_Init(&request->c);
- url = get_remote_object_url(remote->url, hex, 0);
+ url = get_remote_object_url(repo->url, hex, 0);
request->url = xstrdup(url);
/* If a previous temp file is present, process what was already
@@ -389,7 +389,7 @@ static void start_fetch_loose(struct
transfer_request *request)
request->state = RUN_FETCH_LOOSE;
if (!start_active_slot(slot)) {
fprintf(stderr, "Unable to start GET request\n");
- remote->can_update_info_refs = 0;
+ repo->can_update_info_refs = 0;
release_request(request);
}
}
@@ -399,7 +399,7 @@ static void start_mkcol(struct transfer_request *request)
char *hex = sha1_to_hex(request->obj->sha1);
struct active_request_slot *slot;
- request->url = get_remote_object_url(remote->url, hex, 1);
+ request->url = get_remote_object_url(repo->url, hex, 1);
slot = get_active_slot();
slot->callback_func = process_response;
@@ -434,10 +434,10 @@ static void start_fetch_packed(struct
transfer_request *request)
struct transfer_request *check_request = request_queue_head;
struct active_request_slot *slot;
- target = find_sha1_pack(request->obj->sha1, remote->packs);
+ target = find_sha1_pack(request->obj->sha1, repo->packs);
if (!target) {
fprintf(stderr, "Unable to fetch %s, will not be able to update
server info refs\n", sha1_to_hex(request->obj->sha1));
- remote->can_update_info_refs = 0;
+ repo->can_update_info_refs = 0;
release_request(request);
return;
}
@@ -450,9 +450,9 @@ static void start_fetch_packed(struct
transfer_request *request)
snprintf(request->tmpfile, sizeof(request->tmpfile),
"%s.temp", filename);
- url = xmalloc(strlen(remote->url) + 64);
+ url = xmalloc(strlen(repo->url) + 64);
sprintf(url, "%sobjects/pack/pack-%s.pack",
- remote->url, sha1_to_hex(target->sha1));
+ repo->url, sha1_to_hex(target->sha1));
/* Make sure there isn't another open request for this pack */
while (check_request) {
@@ -469,7 +469,7 @@ static void start_fetch_packed(struct
transfer_request *request)
if (!packfile) {
fprintf(stderr, "Unable to open local file %s for pack",
request->tmpfile);
- remote->can_update_info_refs = 0;
+ repo->can_update_info_refs = 0;
free(url);
return;
}
@@ -505,7 +505,7 @@ static void start_fetch_packed(struct
transfer_request *request)
request->state = RUN_FETCH_PACKED;
if (!start_active_slot(slot)) {
fprintf(stderr, "Unable to start GET request\n");
- remote->can_update_info_refs = 0;
+ repo->can_update_info_refs = 0;
release_request(request);
}
}
@@ -554,10 +554,10 @@ static void start_put(struct transfer_request *request)
request->buffer.buf.len = stream.total_out;
strbuf_addstr(&buf, "Destination: ");
- append_remote_object_url(&buf, remote->url, hex, 0);
+ append_remote_object_url(&buf, repo->url, hex, 0);
request->dest = strbuf_detach(&buf, NULL);
- append_remote_object_url(&buf, remote->url, hex, 0);
+ append_remote_object_url(&buf, repo->url, hex, 0);
strbuf_add(&buf, request->lock->tmpfile_suffix, 41);
request->url = strbuf_detach(&buf, NULL);
@@ -648,7 +648,7 @@ static int refresh_lock(struct remote_lock *lock)
static void check_locks(void)
{
- struct remote_lock *lock = remote->locks;
+ struct remote_lock *lock = repo->locks;
time_t current_time = time(NULL);
int time_remaining;
@@ -788,7 +788,7 @@ static void finish_request(struct transfer_request *request)
if (request->curl_result != CURLE_OK) {
fprintf(stderr, "Unable to get pack file %s\n%s",
request->url, curl_errorstr);
- remote->can_update_info_refs = 0;
+ repo->can_update_info_refs = 0;
} else {
off_t pack_size = ftell(request->local_stream);
@@ -798,7 +798,7 @@ static void finish_request(struct transfer_request *request)
request->filename)) {
target = (struct packed_git *)request->userData;
target->pack_size = pack_size;
- lst = &remote->packs;
+ lst = &repo->packs;
while (*lst != target)
lst = &((*lst)->next);
*lst = (*lst)->next;
@@ -806,7 +806,7 @@ static void finish_request(struct transfer_request *request)
if (!verify_pack(target))
install_packed_git(target);
else
- remote->can_update_info_refs = 0;
+ repo->can_update_info_refs = 0;
}
}
release_request(request);
@@ -889,7 +889,7 @@ static int add_send_request(struct object *obj,
struct remote_lock *lock)
get_remote_object_list(obj->sha1[0]);
if (obj->flags & (REMOTE | PUSHING))
return 0;
- target = find_sha1_pack(obj->sha1, remote->packs);
+ target = find_sha1_pack(obj->sha1, repo->packs);
if (target) {
obj->flags |= REMOTE;
return 0;
@@ -930,8 +930,8 @@ static int fetch_index(unsigned char *sha1)
struct slot_results results;
/* Don't use the index if the pack isn't there */
- url = xmalloc(strlen(remote->url) + 64);
- sprintf(url, "%sobjects/pack/pack-%s.pack", remote->url, hex);
+ url = xmalloc(strlen(repo->url) + 64);
+ sprintf(url, "%sobjects/pack/pack-%s.pack", repo->url, hex);
slot = get_active_slot();
slot->results = &results;
curl_easy_setopt(slot->curl, CURLOPT_URL, url);
@@ -956,7 +956,7 @@ static int fetch_index(unsigned char *sha1)
if (push_verbosely)
fprintf(stderr, "Getting index for pack %s\n", hex);
- sprintf(url, "%sobjects/pack/pack-%s.idx", remote->url, hex);
+ sprintf(url, "%sobjects/pack/pack-%s.idx", repo->url, hex);
filename = sha1_pack_index_name(sha1);
snprintf(tmpfile, sizeof(tmpfile), "%s.temp", filename);
@@ -1018,8 +1018,8 @@ static int setup_index(unsigned char *sha1)
return -1;
new_pack = parse_pack_index(sha1);
- new_pack->next = remote->packs;
- remote->packs = new_pack;
+ new_pack->next = repo->packs;
+ repo->packs = new_pack;
return 0;
}
@@ -1037,8 +1037,8 @@ static int fetch_indices(void)
if (push_verbosely)
fprintf(stderr, "Getting pack list\n");
- url = xmalloc(strlen(remote->url) + 20);
- sprintf(url, "%sobjects/info/packs", remote->url);
+ url = xmalloc(strlen(repo->url) + 20);
+ sprintf(url, "%sobjects/info/packs", repo->url);
slot = get_active_slot();
slot->results = &results;
@@ -1223,11 +1223,11 @@ static struct remote_lock *lock_remote(const
char *path, long timeout)
struct curl_slist *dav_headers = NULL;
struct xml_ctx ctx;
- url = xmalloc(strlen(remote->url) + strlen(path) + 1);
- sprintf(url, "%s%s", remote->url, path);
+ url = xmalloc(strlen(repo->url) + strlen(path) + 1);
+ sprintf(url, "%s%s", repo->url, path);
/* Make sure leading directories exist for the remote ref */
- ep = strchr(url + strlen(remote->url) + 1, '/');
+ ep = strchr(url + strlen(repo->url) + 1, '/');
while (ep) {
char saved_character = ep[1];
ep[1] = '\0';
@@ -1319,8 +1319,8 @@ static struct remote_lock *lock_remote(const
char *path, long timeout)
} else {
lock->url = url;
lock->start_time = time(NULL);
- lock->next = remote->locks;
- remote->locks = lock;
+ lock->next = repo->locks;
+ repo->locks = lock;
}
return lock;
@@ -1330,7 +1330,7 @@ static int unlock_remote(struct remote_lock *lock)
{
struct active_request_slot *slot;
struct slot_results results;
- struct remote_lock *prev = remote->locks;
+ struct remote_lock *prev = repo->locks;
struct curl_slist *dav_headers;
int rc = 0;
@@ -1356,8 +1356,8 @@ static int unlock_remote(struct remote_lock *lock)
curl_slist_free_all(dav_headers);
- if (remote->locks == lock) {
- remote->locks = lock->next;
+ if (repo->locks == lock) {
+ repo->locks = lock->next;
} else {
while (prev && prev->next != lock)
prev = prev->next;
@@ -1375,9 +1375,9 @@ static int unlock_remote(struct remote_lock *lock)
static void remove_locks(void)
{
- struct remote_lock *lock = remote->locks;
+ struct remote_lock *lock = repo->locks;
- fprintf(stderr, "Removing remote locks...\n");
+ fprintf(stderr, "Removing repo locks...\n");
while (lock) {
unlock_remote(lock);
lock = lock->next;
@@ -1457,7 +1457,7 @@ static void handle_remote_ls_ctx(struct xml_ctx
*ctx, int tag_closed)
}
}
if (path) {
- path += remote->path_len;
+ path += repo->path_len;
ls->dentry_name = xstrdup(path);
}
} else if (!strcmp(ctx->name, DAV_PROPFIND_COLLECTION)) {
@@ -1480,7 +1480,7 @@ static void remote_ls(const char *path, int flags,
void (*userFunc)(struct remote_ls_ctx *ls),
void *userData)
{
- char *url = xmalloc(strlen(remote->url) + strlen(path) + 1);
+ char *url = xmalloc(strlen(repo->url) + strlen(path) + 1);
struct active_request_slot *slot;
struct slot_results results;
struct strbuf in_buffer = STRBUF_INIT;
@@ -1496,7 +1496,7 @@ static void remote_ls(const char *path, int flags,
ls.userData = userData;
ls.userFunc = userFunc;
- sprintf(url, "%s%s", remote->url, path);
+ sprintf(url, "%s%s", repo->url, path);
strbuf_addf(&out_buffer.buf, PROPFIND_ALL_REQUEST);
@@ -1574,7 +1574,7 @@ static int locking_available(void)
struct xml_ctx ctx;
int lock_flags = 0;
- strbuf_addf(&out_buffer.buf, PROPFIND_SUPPORTEDLOCK_REQUEST, remote->url);
+ strbuf_addf(&out_buffer.buf, PROPFIND_SUPPORTEDLOCK_REQUEST, repo->url);
dav_headers = curl_slist_append(dav_headers, "Depth: 0");
dav_headers = curl_slist_append(dav_headers, "Content-Type: text/xml");
@@ -1586,7 +1586,7 @@ static int locking_available(void)
curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
- curl_easy_setopt(slot->curl, CURLOPT_URL, remote->url);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, repo->url);
curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PROPFIND);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
@@ -1617,15 +1617,15 @@ static int locking_available(void)
XML_ParserFree(parser);
if (!lock_flags)
error("Error: no DAV locking support on %s",
- remote->url);
+ repo->url);
} else {
error("Cannot access URL %s, return code %d",
- remote->url, results.curl_result);
+ repo->url, results.curl_result);
lock_flags = 0;
}
} else {
- error("Unable to start PROPFIND request on %s", remote->url);
+ error("Unable to start PROPFIND request on %s", repo->url);
}
strbuf_release(&out_buffer.buf);
@@ -1801,10 +1801,10 @@ static void one_remote_ref(char *refname)
ref = alloc_ref(refname);
- if (http_fetch_ref(remote->url, ref) != 0) {
+ if (http_fetch_ref(repo->url, ref) != 0) {
fprintf(stderr,
"Unable to fetch ref %s from %s\n",
- refname, remote->url);
+ refname, repo->url);
free(ref);
return;
}
@@ -1813,7 +1813,7 @@ static void one_remote_ref(char *refname)
* Fetch a copy of the object if it doesn't exist locally - it
* may be required for updating server info later.
*/
- if (remote->can_update_info_refs && !has_sha1_file(ref->old_sha1)) {
+ if (repo->can_update_info_refs && !has_sha1_file(ref->old_sha1)) {
obj = lookup_unknown_object(ref->old_sha1);
if (obj) {
fprintf(stderr, " fetch %s for %s\n",
@@ -1853,10 +1853,10 @@ static void add_remote_info_ref(struct
remote_ls_ctx *ls)
ref = alloc_ref(ls->dentry_name);
- if (http_fetch_ref(remote->url, ref) != 0) {
+ if (http_fetch_ref(repo->url, ref) != 0) {
fprintf(stderr,
"Unable to fetch ref %s from %s\n",
- ls->dentry_name, remote->url);
+ ls->dentry_name, repo->url);
aborted = 1;
free(ref);
return;
@@ -1931,12 +1931,12 @@ static void update_remote_info_refs(struct
remote_lock *lock)
static int remote_exists(const char *path)
{
- char *url = xmalloc(strlen(remote->url) + strlen(path) + 1);
+ char *url = xmalloc(strlen(repo->url) + strlen(path) + 1);
struct active_request_slot *slot;
struct slot_results results;
int ret = -1;
- sprintf(url, "%s%s", remote->url, path);
+ sprintf(url, "%s%s", repo->url, path);
slot = get_active_slot();
slot->results = &results;
@@ -1966,8 +1966,8 @@ static void fetch_symref(const char *path, char
**symref, unsigned char *sha1)
struct active_request_slot *slot;
struct slot_results results;
- url = xmalloc(strlen(remote->url) + strlen(path) + 1);
- sprintf(url, "%s%s", remote->url, path);
+ url = xmalloc(strlen(repo->url) + strlen(path) + 1);
+ sprintf(url, "%s%s", repo->url, path);
slot = get_active_slot();
slot->results = &results;
@@ -2082,7 +2082,7 @@ static int delete_remote_branch(char *pattern, int force)
"of your current HEAD.\n"
"If you are sure you want to delete it,"
" run:\n\t'git http-push -D %s %s'",
- remote_ref->name, remote->url, pattern);
+ remote_ref->name, repo->url, pattern);
}
}
@@ -2090,8 +2090,8 @@ static int delete_remote_branch(char *pattern, int force)
fprintf(stderr, "Removing remote branch '%s'\n", remote_ref->name);
if (dry_run)
return 0;
- url = xmalloc(strlen(remote->url) + strlen(remote_ref->name) + 1);
- sprintf(url, "%s%s", remote->url, remote_ref->name);
+ url = xmalloc(strlen(repo->url) + strlen(remote_ref->name) + 1);
+ sprintf(url, "%s%s", repo->url, remote_ref->name);
slot = get_active_slot();
slot->results = &results;
curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
@@ -2134,7 +2134,7 @@ int main(int argc, char **argv)
setup_git_directory();
- remote = xcalloc(sizeof(*remote), 1);
+ repo = xcalloc(sizeof(*repo), 1);
argv++;
for (i = 1; i < argc; i++, argv++) {
@@ -2167,14 +2167,14 @@ int main(int argc, char **argv)
continue;
}
}
- if (!remote->url) {
+ if (!repo->url) {
char *path = strstr(arg, "//");
- remote->url = arg;
- remote->path_len = strlen(arg);
+ repo->url = arg;
+ repo->path_len = strlen(arg);
if (path) {
- remote->path = strchr(path+2, '/');
- if (remote->path)
- remote->path_len = strlen(remote->path);
+ repo->path = strchr(path+2, '/');
+ if (repo->path)
+ repo->path_len = strlen(repo->path);
}
continue;
}
@@ -2187,7 +2187,7 @@ int main(int argc, char **argv)
die("git-push is not available for http/https repository when not
compiled with USE_CURL_MULTI");
#endif
- if (!remote->url)
+ if (!repo->url)
usage(http_push_usage);
if (delete_branch && nr_refspec != 1)
@@ -2199,13 +2199,13 @@ int main(int argc, char **argv)
no_pragma_header = curl_slist_append(no_pragma_header, "Pragma:");
- if (remote->url && remote->url[strlen(remote->url)-1] != '/') {
- rewritten_url = xmalloc(strlen(remote->url)+2);
- strcpy(rewritten_url, remote->url);
+ if (repo->url && repo->url[strlen(repo->url)-1] != '/') {
+ rewritten_url = xmalloc(strlen(repo->url)+2);
+ strcpy(rewritten_url, repo->url);
strcat(rewritten_url, "/");
- remote->path = rewritten_url + (remote->path - remote->url);
- remote->path_len++;
- remote->url = rewritten_url;
+ repo->path = rewritten_url + (repo->path - repo->url);
+ repo->path_len++;
+ repo->url = rewritten_url;
}
/* Verify DAV compliance/lock support */
@@ -2217,20 +2217,20 @@ int main(int argc, char **argv)
sigchain_push_common(remove_locks_on_signal);
/* Check whether the remote has server info files */
- remote->can_update_info_refs = 0;
- remote->has_info_refs = remote_exists("info/refs");
- remote->has_info_packs = remote_exists("objects/info/packs");
- if (remote->has_info_refs) {
+ repo->can_update_info_refs = 0;
+ repo->has_info_refs = remote_exists("info/refs");
+ repo->has_info_packs = remote_exists("objects/info/packs");
+ if (repo->has_info_refs) {
info_ref_lock = lock_remote("info/refs", LOCK_TIME);
if (info_ref_lock)
- remote->can_update_info_refs = 1;
+ repo->can_update_info_refs = 1;
else {
fprintf(stderr, "Error: cannot lock existing info/refs\n");
rc = 1;
goto cleanup;
}
}
- if (remote->has_info_packs)
+ if (repo->has_info_packs)
fetch_indices();
/* Get a list of all local and remote heads to validate refspecs */
@@ -2388,8 +2388,8 @@ int main(int argc, char **argv)
}
/* Update remote server info if appropriate */
- if (remote->has_info_refs && new_refs) {
- if (info_ref_lock && remote->can_update_info_refs) {
+ if (repo->has_info_refs && new_refs) {
+ if (info_ref_lock && repo->can_update_info_refs) {
fprintf(stderr, "Updating remote server info\n");
if (!dry_run)
update_remote_info_refs(info_ref_lock);
@@ -2402,7 +2402,7 @@ int main(int argc, char **argv)
free(rewritten_url);
if (info_ref_lock)
unlock_remote(info_ref_lock);
- free(remote);
+ free(repo);
curl_slist_free_all(no_pragma_header);
--
1.6.2.GIT
^ permalink raw reply related
* [PATCH 2/2] Created a faux remote to pass to http_init. This allows http_push to authenticate http through a prompt.
From: Amos King @ 2009-03-18 23:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This patch allows http_push to use http authentication via prompts.
You may notice that there is a remote struct that only contains the
url from the repo struct. This struct is a temporary fix for a larger
issue, but gets http authentication via prompts out the door, and
keeps users from having to store passwords in plain text files.
Signed-off-by: Amos King <amos.l.king@gmail.com>
---
http-push.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/http-push.c b/http-push.c
index 9ac2664..885378b 100644
--- a/http-push.c
+++ b/http-push.c
@@ -2195,7 +2195,14 @@ int main(int argc, char **argv)
memset(remote_dir_exists, -1, 256);
- http_init(NULL);
+ //This is a faked remote so that http_init can get the correct data for
+ //builidng out athorization.
+ struct remote *remote;
+ remote = xcalloc(sizeof(*remote), 1);
+ ALLOC_GROW(remote->url, remote->url_nr + 1, remote->url_alloc);
+ remote->url[remote->url_nr++] = repo->url;
+
+ http_init(remote);
no_pragma_header = curl_slist_append(no_pragma_header, "Pragma:");
--
1.6.2.GIT
^ permalink raw reply related
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-18 23:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: saurabh gupta, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903190003100.10279@pacific.mpi-cbg.de>
On Thu, 19 Mar 2009, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 13 Mar 2009, saurabh gupta wrote:
>
>> On Fri, Mar 13, 2009 at 1:29 AM, <david@lang.hm> wrote:
>>> On Fri, 13 Mar 2009, saurabh gupta wrote:
>>>
>>> it may be just doing an XML merge driver is a summer's worth of work,
>>> or it may be that it's not really enough and you should try to do
>>> another one or two.
>>>
>>> it also may be that there is a lot of overlap between different merge
>>> drivers, and once you have the XML driver the others become fairly
>>> trivial to do. (I'm thinking the config file examples I posted earlier
>>> in the thread)
>>
>> with the options given to the user, one can handle the config files
>> also where order doesn't matter and also the whitespaces problem can
>> also be handled in the similar way.
>
> In my humble opinion, we should focus on the data types we want to be
> able to support at the end of the summer first.
>
> For example, if we decide that OOXML is a must (as it is a proper
> standard, and many people will benefit from it), we will most likely end
> up in having to write a merge _driver_ (to handle those .zip files), _and_
> a merge _helper_, although we can avoid writing our own GUI, as we can
> create an OOXML that has its own version of conflict markers.
do you mean OOXML (the microsoft format) or ODF (the open office format)?
> If we decide that SVG is something we want to support by the end of the
> summer, then we can probably avoid writing a merge _driver_, as plain text
> is handled reasonably well in Git. OTOH it could turn out that there are
> _real_ conflicts in overlapping tag ids, and it would still be easier to
> write a merge driver, too.
>
> IOW the details are not as important as
>
> - knowing what data types we want to support _at the least_, and what data
> types we keep for the free skate,
>
> - a clear picture of the user interface we want to be able to provide,
>
> - a timeline (weekly milestones should be fine, I guess) what should be
> achieved when, and
>
> - being flexible in how to support that (IOW if a merge driver appears
> unnecessary first, but necessary later, we should be able to fit that
> into both the design and the timeline).
it's up to the student, but I suspect that the best approach would be to
start with defining a merge driver to handle XML (with a minimum set of
capabilities, and additional optional ones), and go from there.
David Lang
> How does that sound?
>
> Ciao,
> Dscho
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Introduce a filter-path argument to git-daemon, for doing custom path transformations
From: Johannes Schindelin @ 2009-03-19 0:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Sørensen, git
In-Reply-To: <7vprgkarq5.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2072 bytes --]
Hi,
On Sat, 14 Mar 2009, Junio C Hamano wrote:
> Johan Sørensen <johan@johansorensen.com> writes:
>
> >> Do you run git-daemon from inetd, or standalone, by the way?
> >
> > Standalone.
> >
> >> I am wondering how well it would scale if you spawn an external
> >>"filter path" script every time you get a request.
> >
> > A quick test of 250 consecutive requests with ls-remote to localhost
> > (all without the --verbose flag), slowest run:
> > - Baseline (no --filter-path agument): 3.39s
> >
> > $ cat filter.c
> > #import "stdio.h"
> > int main (int argc, char const *argv[]) {
> > printf("%s", "/existing.git\0");
> > return 0;
> > }
> > - 3.84s
> >
> > $ cat filter.rb
> > #!/usr/bin/ruby
> > print "/existing.git\0"
> > - 4.76s
> >
> > So, obviously highly dependent on how long it takes the script to
> > launch and how much work it does. And yes, neither of the above really
> > does anything :) nor takes any increased cpu load into account
> >
> > Another approach is to keep the external script running and feed it on
> > stdin, but that would involve a bit more micro-management of the
> > external process. I will revisit that idea if I find out that's
> > needed.
>
> I actually was hoping (especially we have Dscho on Cc: list) that somebody
> like you would start suggesting a "plug in" approach to load .so files,
> which would lead to a easy-to-port dso support with the help from msysgit
> folks we can use later in other parts of the system (e.g. customizable
> filters used for diff textconv, clean/smudge, etc.)
I do not like that at all. Dynamic libraries -- especially on Windows --
are a major hassle.
However, I cannot think of anything Johan might want to do that would not
be possible using a bunch of regular expressions together with
substitions.
FWIW I have experimental code in my personal tree that sports
strbuf_regsub(), a function to replace matches of a regular expression
(possibly with groups) by a given string (which may contain \0 .. \9,
being replaced with the respective group's contents).
Ciao,
Dscho
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-19 0:43 UTC (permalink / raw)
To: david; +Cc: saurabh gupta, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.10.0903181645440.16753@asgard.lang.hm>
Hi,
On Wed, 18 Mar 2009, david@lang.hm wrote:
> On Thu, 19 Mar 2009, Johannes Schindelin wrote:
>
> > On Fri, 13 Mar 2009, saurabh gupta wrote:
> >
> > > On Fri, Mar 13, 2009 at 1:29 AM, <david@lang.hm> wrote:
> > > > On Fri, 13 Mar 2009, saurabh gupta wrote:
> > > >
> > > > it may be just doing an XML merge driver is a summer's worth of
> > > > work, or it may be that it's not really enough and you should try
> > > > to do another one or two.
> > > >
> > > > it also may be that there is a lot of overlap between different
> > > > merge drivers, and once you have the XML driver the others become
> > > > fairly trivial to do. (I'm thinking the config file examples I
> > > > posted earlier in the thread)
> > >
> > > with the options given to the user, one can handle the config files
> > > also where order doesn't matter and also the whitespaces problem can
> > > also be handled in the similar way.
> >
> > In my humble opinion, we should focus on the data types we want to be
> > able to support at the end of the summer first.
> >
> > For example, if we decide that OOXML is a must (as it is a proper
> > standard, and many people will benefit from it), we will most likely
> > end up in having to write a merge _driver_ (to handle those .zip
> > files), _and_ a merge _helper_, although we can avoid writing our own
> > GUI, as we can create an OOXML that has its own version of conflict
> > markers.
>
> do you mean OOXML (the microsoft format) or ODF (the open office
> format)?
Oops.
EOVERLOAD
> > If we decide that SVG is something we want to support by the end of
> > the summer, then we can probably avoid writing a merge _driver_, as
> > plain text is handled reasonably well in Git. OTOH it could turn out
> > that there are _real_ conflicts in overlapping tag ids, and it would
> > still be easier to write a merge driver, too.
> >
> > IOW the details are not as important as
> >
> > - knowing what data types we want to support _at the least_, and what
> > data types we keep for the free skate,
> >
> > - a clear picture of the user interface we want to be able to provide,
> >
> > - a timeline (weekly milestones should be fine, I guess) what should
> > be achieved when, and
> >
> > - being flexible in how to support that (IOW if a merge driver appears
> > unnecessary first, but necessary later, we should be able to fit
> > that into both the design and the timeline).
>
> it's up to the student, but I suspect that the best approach would be to
> start with defining a merge driver to handle XML (with a minimum set of
> capabilities, and additional optional ones), and go from there.
Well, the thing is: if the student decides to have a go at an XML driver
first and foremost, then I'll just flatly refuse to mentor that. Because
I sincerely believe that this project is best designed from top to bottom,
not the other way round.
After all, the project is based on a user's request, not just a
playthingie for an XML enthusiast (if such a thing exists).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 08/10] t2200, t7004: Avoid glob pattern that also matches files
From: Junio C Hamano @ 2009-03-19 0:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <3827d7fab3e9e233a0ac528b84ab2d6a36658365.1237410682.git.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> On Windows, there is an unfortunate interaction between the MSYS bash and
> git's command line processing:
>
> - Since Windows's CMD does not do the wildcard expansion, but passes
> arguments like path* through to the programs, the programs must do the
> expansion themselves. This happens in the startup code before main() is
> entered.
>
> - bash, however, passes the argument "path*" to git, assuming that git will
> see the unquoted word unchanged as a single argument.
>
> But actually git expands the unquoted word before main() is entered.
Doesn't this mean on Windows, the glob pathspec git supports is not useful
at all?
I am wondering if we want to treat any feature that involves globs as
unusable like any feature that involves pathnames with a TAB in it.
> In t2200, not all names that the test case is interested in exist as files
> at the time when 'git ls-files' is invoked. git expands "path?" to only
> the subset of files the exist, and only that subset was listed, so that the
> test failed. We now list all interesting paths explicitly.
But that conversion misses the whole point of that particular test,
doesn't it? It wants to see path2 that was unmerged and existed only in
the index but not in the work tree has disappeared, while the similarly
unmerged path1 resolved after "add -u". IOW, you are not testing that
"add -u" notices a removal of path2 from the work tree anymore.
^ permalink raw reply
* Re: Local clone checks out wrong branch based on remote HEAD
From: Jeff King @ 2009-03-19 4:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Tom Preston-Werner, git
In-Reply-To: <49C0C769.8020401@drmicha.warpmail.net>
On Wed, Mar 18, 2009 at 11:05:29AM +0100, Michael J Gruber wrote:
> One might even argue that in case of ambiguities, checking out a
> detached head would be most appropriate. Really, why impose creation of
> certain local branches on a user at all, unless asked for? Detached
> heads are natural in git! But I don't really expect positive consensus
> on that one...
I'm not sure that detached HEADs are all that natural. It means that:
git clone repo-with-ambiguous-HEAD foo
cd foo
hack hack hack
git commit -a -m msg
is putting your commits "nowhere" (i.e., not on any ref). They are not
accessible for pushing, and when you checkout another branch, they will
be lost (except to the reflog).
So it clearly requires that the user be aware of what is going on, and
that they understand the subtleties of detached HEADs (something that
has caused new user confusion before, I think).
-Peff
^ permalink raw reply
* Re: Local clone checks out wrong branch based on remote HEAD
From: Jeff King @ 2009-03-19 4:04 UTC (permalink / raw)
To: Jay Soffian; +Cc: Michael J Gruber, Tom Preston-Werner, git
In-Reply-To: <76718490903181411p743382f1qb053363f28a800b1@mail.gmail.com>
On Wed, Mar 18, 2009 at 05:11:25PM -0400, Jay Soffian wrote:
> I think there are two reasonable paths forward:
>
> 1) Address Jeff's concerns above so that the symref can be sent.
> 2) In lieu of (1), have clone at least warn that multiple branches
> match and that it just picked one.
I think we should do (2) regardless. Even with an updated client,
remote servers may have an older git which does not support (1) for some
time.
So I guess it's time to refactor guess_remote_head _again_. :)
-Peff
^ permalink raw reply
* Re: t5505-remote fails on Windows
From: Jeff King @ 2009-03-19 4:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jay Soffian, Git Mailing List
In-Reply-To: <49C0DE23.8020809@viscovery.net>
On Wed, Mar 18, 2009 at 12:42:27PM +0100, Johannes Sixt wrote:
> --- expect Wed Mar 18 11:22:53 2009
> +++ output Wed Mar 18 11:22:54 2009
> @@ -12,8 +12,8 @@
> and with remote topic-c
> rebase rebases onto remote master
> Local refs configured for 'git push':
> - master pushes to master (local out of date)
> master pushes to upstream (create)
> + master pushes to master (local out of date)
> * remote two
> URL: ../two
> HEAD branch (remote HEAD is ambiguous, may be one of the following):
> * FAIL 8: show
>
>
> As you can see, the entries for "master pushes to..." are reversed. It
> seems that this output is not stable. Before I delve into this, do you
> know whether there is some data structure involved that does not guarantee
> the order? Such as a hash table, a opendir/readdir sequence, or perhaps
> while reading the config file?
That is quite curious, because it is sorted immediately before printing:
$ sed -n 1034,1040p builtin-remote.c
for_each_string_list(add_push_to_show_info, &states.push, &info);
sort_string_list(info.list);
if (info.list->nr)
printf(" Local ref%s configured for 'git push'%s:\n",
info.list->nr > 1 ? "s" : "",
no_query ? " (status not queried)" : "");
for_each_string_list(show_push_info_item, info.list, &info);
can you step through in a debugger and make sure the sort_string_list is
actually sorting?
-Peff
^ permalink raw reply
* Re: t5505-remote fails on Windows
From: Jeff King @ 2009-03-19 4:43 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jay Soffian, Git Mailing List
In-Reply-To: <20090319041837.GA32642@coredump.intra.peff.net>
On Thu, Mar 19, 2009 at 12:18:37AM -0400, Jeff King wrote:
> > As you can see, the entries for "master pushes to..." are reversed. It
> > seems that this output is not stable. Before I delve into this, do you
> > know whether there is some data structure involved that does not guarantee
> > the order? Such as a hash table, a opendir/readdir sequence, or perhaps
> > while reading the config file?
>
> That is quite curious, because it is sorted immediately before printing:
>
> $ sed -n 1034,1040p builtin-remote.c
> for_each_string_list(add_push_to_show_info, &states.push, &info);
> sort_string_list(info.list);
Oh, nevermind. I didn't look closely enough at your issue, which is one
ref pushing to two different places. For that, the sort needs to take
into account the util field, which holds the destination.
The patch below probably fixes it, but as I can't actually reproduce
here, it is largely untested.
As a side note, I find this solution a little bit ugly. String lists
should sort on their strings, not on some other random magic in the util
field. This usage really abuses string_list a bit as a data type because
we have no generic "list" type.
---
diff --git a/builtin-remote.c b/builtin-remote.c
index 993acd6..f94ecd6 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -922,6 +922,16 @@ int add_push_to_show_info(struct string_list_item *push_item, void *cb_data)
return 0;
}
+static int push_cmp(const void *va, const void *vb)
+{
+ const struct string_list_item *a = va;
+ const struct string_list_item *b = vb;
+ const struct push_info *a_push = a->util;
+ const struct push_info *b_push = b->util;
+ int cmp = strcmp(a->string, b->string);
+ return cmp ? cmp : strcmp(a_push->dest, b_push->dest);
+}
+
int show_push_info_item(struct string_list_item *item, void *cb_data)
{
struct show_info *show_info = cb_data;
@@ -1032,7 +1042,7 @@ static int show(int argc, const char **argv)
info.width = info.width2 = 0;
for_each_string_list(add_push_to_show_info, &states.push, &info);
- sort_string_list(info.list);
+ sort_string_list_with_fn(info.list, push_cmp);
if (info.list->nr)
printf(" Local ref%s configured for 'git push'%s:\n",
info.list->nr > 1 ? "s" : "",
diff --git a/string-list.c b/string-list.c
index 1ac536e..f404a26 100644
--- a/string-list.c
+++ b/string-list.c
@@ -163,9 +163,15 @@ static int cmp_items(const void *a, const void *b)
return strcmp(one->string, two->string);
}
+void sort_string_list_with_fn(struct string_list *list,
+ int (*fn)(const void *, const void *))
+{
+ qsort(list->items, list->nr, sizeof(*list->items), fn);
+}
+
void sort_string_list(struct string_list *list)
{
- qsort(list->items, list->nr, sizeof(*list->items), cmp_items);
+ sort_string_list_with_fn(list, cmp_items);
}
int unsorted_string_list_has_string(struct string_list *list, const char *string)
diff --git a/string-list.h b/string-list.h
index 14bbc47..4bbc7e8 100644
--- a/string-list.h
+++ b/string-list.h
@@ -37,6 +37,8 @@ struct string_list_item *string_list_lookup(const char *string, struct string_li
/* Use these functions only on unsorted lists: */
struct string_list_item *string_list_append(const char *string, struct string_list *list);
void sort_string_list(struct string_list *list);
+void sort_string_list_with_fn(struct string_list *list,
+ int (*fn)(const void *, const void *));
int unsorted_string_list_has_string(struct string_list *list, const char *string);
#endif /* PATH_LIST_H */
^ permalink raw reply related
* Re: t5505-remote fails on Windows
From: Jay Soffian @ 2009-03-19 4:56 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <20090319044313.GA341@coredump.intra.peff.net>
On Thu, Mar 19, 2009 at 12:43 AM, Jeff King <peff@peff.net> wrote:
> The patch below probably fixes it, but as I can't actually reproduce
> here, it is largely untested.
Thanks.
> As a side note, I find this solution a little bit ugly. String lists
> should sort on their strings, not on some other random magic in the util
> field. This usage really abuses string_list a bit as a data type because
> we have no generic "list" type.
I really don't think so. The string_list API accommodates this case
quite nicely. So why not?
(And anyway, what sane configuration pushes a single local branch to
multiple remote branches? But the refspecs allow it, so I accommodated
it in builtin-remote and tested for it. I never actually tested
whether git push works with it tho.) :-)
j.
^ permalink raw reply
* Re: t5505-remote fails on Windows
From: Jeff King @ 2009-03-19 5:03 UTC (permalink / raw)
To: Jay Soffian; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <76718490903182156y3b2b9d8aw708829a6ed151aa@mail.gmail.com>
On Thu, Mar 19, 2009 at 12:56:37AM -0400, Jay Soffian wrote:
> > As a side note, I find this solution a little bit ugly. String lists
> > should sort on their strings, not on some other random magic in the util
> > field. This usage really abuses string_list a bit as a data type because
> > we have no generic "list" type.
>
> I really don't think so. The string_list API accommodates this case
> quite nicely. So why not?
I think the code would be more natural as a list of structs, each with a
source and dest. But C does not make it pleasant to write generic data
types, so things end up stuffed into string_lists with a magic util
field. So I think leaving it as a string_list is probably the most sane
thing to do.
-Peff
^ permalink raw reply
* Re: [PATCH] git-gui: various French translation fixes
From: Christian Couder @ 2009-03-19 5:09 UTC (permalink / raw)
To: Sam Hocevar; +Cc: Git List, Alexandre Bourget
In-Reply-To: <20090318205410.GA900@zoy.org>
Le mercredi 18 mars 2009, Sam Hocevar a écrit :
> Mostly grammar, spelling and typography fixes, but also a few wording
> enhancements here and there.
It looks mostly good to me.
> Signed-off-by: Sam Hocevar <sam@zoy.org>
> ---
> po/fr.po | 196
> +++++++++++++++++++++++++++++++------------------------------- 1 files
> changed, 98 insertions(+), 98 deletions(-)
>
> #: git-gui.sh:2484 lib/index.tcl:410
> msgid "Revert Changes"
> -msgstr "Annuler les modifications (revert)"
> +msgstr "Révoquer les modifications"
I am not sure that "Révoquer" is better than "Annuler".
[...]
> #: lib/index.tcl:326
> msgid "Ready to commit."
> @@ -1719,18 +1719,18 @@ msgstr "Ajout de %s"
> #: lib/index.tcl:396
> #, tcl-format
> msgid "Revert changes in file %s?"
> -msgstr "Annuler les modifications dans le fichier %s ? "
> +msgstr "Révoquer les modifications dans le fichier %s ? "
>
> #: lib/index.tcl:398
> #, tcl-format
> msgid "Revert changes in these %i files?"
> -msgstr "Annuler les modifications dans ces %i fichiers ?"
> +msgstr "Révoquer les modifications dans ces %i fichiers ?"
>
> #: lib/index.tcl:406
> msgid "Any unstaged changes will be permanently lost by the revert."
> msgstr ""
> "Toutes les modifications non-indexées seront définitivement perdues par
> " -"l'annulation."
> +"la révocation."
Same thing for the 3 strings above.
[...]
> #: lib/index.tcl:427
> msgid "Reverting selected files"
> -msgstr "Annuler modifications dans fichiers selectionnés"
> +msgstr "Révocation en cours des fichiers selectionnés"
>
> #: lib/index.tcl:431
> #, tcl-format
> msgid "Reverting %s"
> -msgstr "Annulation des modifications dans %s"
> +msgstr "Révocation en cours de %s"
Same thing above.
> #: lib/remote_branch_delete.tcl:47
> msgid "From Repository"
> @@ -2244,7 +2244,7 @@ msgid ""
> "One or more of the merge tests failed because you have not fetched the
> " "necessary commits. Try fetching from %s first."
> msgstr ""
> -"Une ou plusieurs des tests de fusion ont échoués parce que vous n'avez
> pas "
> +"Un ou plusieurs des tests de fusion ont échoué parce que vous
> n'avez pas "
> "récupéré les commits nécessaires. Essayez de récupéré à
> partir de %s d'abord."
The last "récupéré" should be changed to "récupérer".
Thanks,
Christian.
^ permalink raw reply
* Re: Google Summer of Code 2009 - Accepted!
From: Christian Couder @ 2009-03-19 5:24 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.00.0903182218330.10279@pacific.mpi-cbg.de>
Hi,
Le mercredi 18 mars 2009, Johannes Schindelin a écrit :
> Hi,
>
> On Wed, 18 Mar 2009, Shawn O. Pearce wrote:
> > Google has announced the selected organizations for GSoC 2009:
> >
> > http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009
> >
> > Students interested in applying should look at Git's ideas list,
> > or any other accepted org's ideas list:
> >
> > http://git.or.cz/gitwiki/SoC2009Ideas
> >
> >
> > Mentors for Git are really needed. I'm going to be too busy this
> > summer to mentor a student myself. If we have no mentors, we'll
> > have to pull out late, upsetting everyone, including my boss,
> > and worse, LH.
>
> I think you need not be scared of a mentor shortage. In any case, I am
> available.
I am available too, though I will have a 2 week long vacation away from
computer from July 10 to July 25.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH] git-gui: various French translation fixes
From: Christian Couder @ 2009-03-19 6:14 UTC (permalink / raw)
To: Sam Hocevar; +Cc: Git List, Alexandre Bourget
In-Reply-To: <200903190609.25344.chriscool@tuxfamily.org>
Hi Sam,
Le jeudi 19 mars 2009, Christian Couder a écrit :
> Le mercredi 18 mars 2009, Sam Hocevar a écrit :
> > Mostly grammar, spelling and typography fixes, but also a few wording
> > enhancements here and there.
>
> It looks mostly good to me.
>
> > Signed-off-by: Sam Hocevar <sam@zoy.org>
> > ---
> > po/fr.po | 196
> > +++++++++++++++++++++++++++++++------------------------------- 1 files
> > changed, 98 insertions(+), 98 deletions(-)
> >
> > #: git-gui.sh:2484 lib/index.tcl:410
> > msgid "Revert Changes"
> > -msgstr "Annuler les modifications (revert)"
> > +msgstr "Révoquer les modifications"
>
> I am not sure that "Révoquer" is better than "Annuler".
Perhaps "Inverser"?
Thanks,
Christian.
^ permalink raw reply
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