* Git tree object storing policy
From: Ivan Tolstosheyev @ 2012-02-21 9:22 UTC (permalink / raw)
To: git
Hello,
now tree object is a simple list of <attributes, hash, name>sorted by name
(tricky sorted, cause we assuming that directory name "$X" is actually "$X/"
in comparison function). The problem is, that if I want to insert 10k files
in empty git repository on / folder there will be 10k new
trees with sizes from (1 to 10k)*(hash+name+attribute)+eps .
itroot@localhost ~/tmp> cat git-test.sh
#!/usr/bin/env bash
git init test
cd test
for i in `seq 1 10000`
do
touch ${i} ; git add ${i} ; git commit -m "Add ${i}" ;
done
cd ..
du -hs test
itroot@localhost ~/tmp>
itroot@localhost ~/tmp> ./git-test.sh
...
180M test
itroot@localhost ~/tmp>
180 MB!!!?? and 7.4M after `git gc` - thanks to delta compression!
Ok, you can say that this example is artificial, and I can add 10k files
with 1 commit. Thats true. But manipulating files in big tree objects
(in a big directories) is storage-expensive, and if I need to store a
lot of files in one directory and frequently change them - git just
don't scales now properly at this use-case.
What do I propose?
We can add another git object, named for example "btree" ,
that contains another "btree" objects or files. This will be a simple
btree structure (tree entries sorted practically by name, BTW,
maybe it's time to fix sorting =] ), that allows us to do insertion,
removal, search in ln(n) time. But - we do not have troubles
with big direcories now. BTW, if all directories are small, btree
will be tree-like - just btree pointing to files.
So, one big tree with 10k files transforms to (hmm, for example...)
101 btrees - one, pointing to 100 btrees, and thay points to files.
(100 entries per btree is a wild guess =) )
Suggestions?
^ permalink raw reply
* Re: HTTP error 511 [Was: Secure (https) proxy authentification]
From: Julian Reschke @ 2012-02-21 9:28 UTC (permalink / raw)
To: Nicolas Mailhot; +Cc: squid3, ietf-http-wg, Jeff King, git, Daniel Stenberg
In-Reply-To: <39d91a07ae0beb19a734e52496ab5700.squirrel@arekh.dyndns.org>
On 2012-02-21 09:58, Nicolas Mailhot wrote:
>
> Le Dim 19 février 2012 11:22, Nicolas Mailhot a écrit :
>
>> 511 is exactly what I need. I was not aware of it. Is it simplemented in any
>> browser yet? Where should I point the browser writers to get it implemented?
>>
>> http://tools.ietf.org/id/draft-nottingham-http-new-status-04.txt ?
>
> I take that back. 511 is almost exactly what we need. However, when I pointed
> the authors of some of the tools that pass through our proxy to it (curl, git)
> they told me they could not parse html code in their tools, so they really
> need a location (or similar) field containing the address of the
> authentication portal to communicate it to the user. Without this field, they
> can only stop with 'Network authentication is needed' instead of 'Please open
> <url> in your browser to proceed'.
Yes. The definition of status code 511 did not attempt to solve more
problems than that.
> http://article.gmane.org/gmane.comp.version-control.git/191085
> http://article.gmane.org/gmane.comp.version-control.git/191087
> http://article.gmane.org/gmane.comp.version-control.git/191086
>
> (the nearest thing there is in the spec is the url in meta, but it's only in
> the example, not mandatory, and no one will write code for something they can
> not be sure will exist)
>
> We'd like to support those tools properly as their users' previous clumsy
> attempts to navigate our current non-standard redirection method resulted in
> internal security investigations.
>
> It is a problem in our setup as we only block some URLs (others are allowed
> transparently without auth), and we use several proxy farms in different
> physical sites (to avoid spofs). So just opening any url in a browser won't
> trigger an authentication request (the url may not be blocked, or the browser
> may pass through a gateway where the user IP is already authorized, while
> git/etc tried to access through another one).
>
> Could you please revise the error 511 definition to add such a field ?
The specification has already been approved, so it's too late to make
more than editorial changes.
Best regards, Julian
^ permalink raw reply
* Re: HTTP error 511 [Was: Secure (https) proxy authentification]
From: Nicolas Mailhot @ 2012-02-21 9:44 UTC (permalink / raw)
To: Julian Reschke; +Cc: squid3, ietf-http-wg, Jeff King, git, Daniel Stenberg, git
In-Reply-To: <4F4363C1.90902@gmx.de>
Le Mar 21 février 2012 10:28, Julian Reschke a écrit :
> On 2012-02-21 09:58, Nicolas Mailhot wrote:
>> Could you please revise the error 511 definition to add such a field ?
>
> The specification has already been approved, so it's too late to make
> more than editorial changes.
I know it has been approved, and we'll go with it as is for now on our network.
However, could it be extended to add this location field later please? (taking
into account the tool authors' feedback)
Best regards,
--
Nicolas Mailhot
^ permalink raw reply
* Re: [PATCH 0/8 v6] diff --stat: use the full terminal width
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-21 10:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael J Gruber, pclouds, j.sixt
In-Reply-To: <7vr4xois3l.fsf@alter.siamese.dyndns.org>
On 02/21/2012 08:05 AM, Junio C Hamano wrote:
> Zbigniew Jędrzejewski-Szmek<zbyszek@in.waw.pl> writes:
>
>> On 02/21/2012 12:41 AM, Junio C Hamano wrote:
>>> Zbigniew Jędrzejewski-Szmek<zbyszek@in.waw.pl> writes:
>>>
>>>> JC:
>>>>> Perhaps the maximum for garph_width should be raised to something like
>>>>> "min(80, stat_width) - name_width"?
>>>> I think that a graph like
>>>> a | 1000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> b | 1 -
>>>> is not very readable. I like the consistency forced by the 40-column limit.
>>>> But I guess that this is very subjective.
>>>
>>> The above makes it very obvious that there is a huge amount of change made
>>> to 'a' and a bit of deletion to 'b', compared to a mini-graph that is
>>> truncated to half the screen width.
>> Yes. But the same graph with 40 columns tells me exactly the same thing.
>
> That is a bogus argument, isn't it? You can say the same thing if you
> limited the length of the graph bars to 10-columns if you only compare
> between 1000 and 1. You can even do with just 5-columns. For that matter,
> without any graph bar at all, it tells us exactly the same thing because
> we have numbers. Does that mean we do not need any bar? Of course not.
> We use bars as visual aid.
Yes.
> Imagine what happens to the graph if you had paths with medium amount of
> changes like 980, 800, 40, in addition to 1000 and 1. By limiting the
> length of the bars more than necessary, you are losing the resolution
> without a good reason, and that is why I find 40-column limit a poor
> design choice.
You're right.
>>> Besides, the above is what you would get without your patch on 80-column
>>> terminal, no?
>>
>> Yes.
>
> I think this "use at most 40-places for the graph bar" was your response
> to somebody's observation that "on 200-column terminal, we will still see
> the commit log messages (and for many projects, also patch text) that are
> designed to be comfortably viewable within the 80-column on the left, and
> overlong graph bar stands out like an ugly sore thumb".
>
> While that "ugliness" observation might be a valid one to make, I do not
> think limiting the length of the graph bar without taking the length of
> the name part into account at all is the right solution to it.
>
> After all, that is exactly the same thinking that led to the bug in the
> current code that you fixed with your series, isn't it? Our safety code
> truncated the graph bar width too early without taking the width needed to
> show the names into account, and then when the names turn out to be all
> short, we ended up wasting space on the right hand side, because we made
> the bars too short and the decision was made too early in the code.
>
> If the problem you are addressing is to make sure that the diffstat part
> in the series of lines that are structured like this:
>
> log message part ~80 column
> diff stat part that can extend very very very very very very very long
> patch text part ~80 column
>
> does not become overly long, wouldn't it be a more natural solution to
> make sure that when the total (i.e. name and graph) length can fit to
> align with the message and patch (i.e. traditional ~80 col regardless of
> the terminal width), not to give it too much width? If the names are
> short, like "a" and "b", that may result in graph bar part to use ~70
> columns or so, and if the names are long, like in a Java project, you may
> allocate 50 columns to the name and leave only 50 columns or so for the
> graph part.
>
> A simple heuristic might be to see if name part (without truncation) and
> the graph part (without scaling) fits under 100-columns if the terminal is
> wider than that, and if so limit the whole thing to 100-columns before
> deciding the allocation of the total into two parts. If the name part
> alone is very wide, showing the name and the graph using the whole
> terminal width would give you a better result than using the bars that are
> artificially capped to a short limit, I would imagine.
This seem overly complex. A nice property to have would be
"if the window is wide enough so there's enough space for full
filenames, the graph part scales monotonically with the change count".
(If there's filename truncation, than there just isn't enough space for
everything and the graph may be compressed. But otherwise, if we have
two graphs which do not end at the edge of the screen, and the second
one is wider than the first one, then without looking at the change
counts we know that the second one has more changes).
For this property to be satisfied, the graph_width limit would have to
be independent of the filename width. So maybe it should be
71 = (available space if stat_width==80 and the filename is "a" and
the change count is in double digits).
Then if the filenames are longer, and the change counts are big enough,
the graph part starts gently extending above 80 columns.
What do you think about this approach?
Zbyszek
^ permalink raw reply
* Re: Git tree object storing policy
From: Thomas Rast @ 2012-02-21 10:18 UTC (permalink / raw)
To: Ivan Tolstosheyev; +Cc: git
In-Reply-To: <loom.20120221T094746-680@post.gmane.org>
Ivan Tolstosheyev <ivan.tolstosheyev@gmail.com> writes:
> #!/usr/bin/env bash
>
> git init test
> cd test
> for i in `seq 1 10000`
> do
> touch ${i} ; git add ${i} ; git commit -m "Add ${i}" ;
> done
> cd ..
> du -hs test
[...]
> 180 MB!!!?? and 7.4M after `git gc` - thanks to delta compression!
Most of those 180MB are waste from mostly unused 4KB (presumably) blocks
of your filesystem. You should be looking at the post-gc'd numbers.
Let's see the breakdown of 'du -h .git':
0 .git/rr-cache
1.5M .git/logs/refs/heads
1.5M .git/logs/refs
2.9M .git/logs
4.0K .git/objects/info
2.8M .git/objects/pack
2.8M .git/objects
0 .git/branches
12K .git/info
0 .git/remotes
88K .git/hooks
0 .git/refs/tags
0 .git/refs/heads
0 .git/refs
6.5M .git
So 2.9MB are git keeping a reflog of everything we did (on HEAD and on
master). Since merely storing a SHA1 for each of your 10000 operations
already takes 200K, that's not so far off -- the factor of 10 is in the
email, date and log message.
In my case 704K went into the index (not directly visible above, it's
the bulk of the top level). That's also not unreasonable: merely
storing the object SHA1 (20 bytes) and a bunch of timestamps for 10000
files also gets you into the 500K ballpark.
The pack index amazingly takes only about 500K, even though it is
indexing 10000 trees and 10000 commits, so again the SHA1s alone get you
into the 400K ballpark.
That leaves only 2.3MB for the actual pack (which contains all the
data!). But every commit must store a tree and a parent, so there are
at least 2*10000*20 = 400K uncompressable bytes in the commits
already[*]. So we are within a factor of 6 of just the data required to
save the shape of your history DAG, no content included. I'd say that's
not too bad.
[*] This is not quite true, the parents and trees might be pointers
within the pack. AFAIK the proposed pack v4 format does this, and would
yield a more efficient compression. So if you're going to waste energy
worrying about this, you should help with pack v4.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git-svn show-externals and svn version
From: Nikolaus Demmel @ 2012-02-21 11:14 UTC (permalink / raw)
To: git
In-Reply-To: <E59CCE45-6F92-4748-9B6E-2A562647904B@nikolaus-demmel.de>
Hi,
as a followup just another example of when the current show-externals gives a flaky output, namely when the line in the external definition is commented.
$ git svn show-externals
[...]
# /src/
/src/#https://codex.cs.bham.ac.uk/svn/nah/cogx/code/subarchitectures/vision.sa/tags/matlab-cosy-2008 matlab_cosy_2008
/src/#https://codex.cs.bham.ac.uk/svn/nah/cogx/code/subarchitectures/vision.sa/tags/matlab-review-2009 matlab_review_2009
Regards,
Nikolaus
Am 19.02.2012 um 19:53 schrieb Nikolaus Demmel:
> Hi,
>
> I am currently investigating getting support for svn externals in git-svn (you might have noticed my other mails).
>
> It turns out that there are quite a few scripts floating around that use the output of show-externals and then try to pull these externals with git-svn into independent repositories and add the folders as submodules to the root repository.
>
> However, none of them work for me, and the primary reason AFAICT is that they were written for the pre svn1.5 format of svn:externals. From 1.5 svn supports a new format of svn:externals, which changes the order of revision, repository-url, and local folder, and also adds the posibility to add relative urls, peg-revisions, etc [1].
>
> On top that it seems to me that the output of show-externals was purely designed for the old format. For example, if you compare the output of "git svn show-externals" with "git svn propget svn:externals" in an example repository using the new format [2], you find that the in the show-externals output the prepended "/" and "/instantiations/" at the beginning of each line does not make sense. If the target url (all relative with the ^ syntax in this case) and the sub-folder were swapped in order, as of pre 1.5 svn, it would make much more sense. Also apparently the code for show-externals was added in 2007 and not changed since, whereas svn 1.5 was released in 2008.
>
> What I am not completely clear about is, whether svn 1.5 and later enforces the new syntax, or whether it just adds the new syntax and still has to support the old syntax (which could be distinguished, I guess, by checking of the last part on an entry is an absolute URL instead of a subfolder). Also, I'm not sure if the format depends on the version of the svn-server or the client. I would assume you can check out a repository hosted with svn 1.4 with a 1.5 client. Does the client process the svn:externals and present it in the new format, or is this the text string just taken from the server unaltered (I have not much knowledge of how svn actually works internally)?
>
> Another question is whether the perl svn bindings present the svn:externals in some parsed, standard format, or do they just give you the raw text string?
>
> In order to make show-externals more useful with the svn 1.5 and later syntax, one would maybe need to check the underlying svn version. I guess it is also quite important to retain backwards compatibility, such that users of externals with the old syntax would still get the same output as before.
>
> I would suggest that the show-externals output should be as close as possible to the svn:externals syntax, possibly adapting the subfolder path for nested folders. However here the recursive display of externals for subfolders becomes a bit more tricky, since the URL can also be relative to the subfolder as of the new syntax. Maybe the easiest way to deal with the new syntax in show-externals would be to have each line like it is in the svn-properties, but add a space separated relative path to the corresponding subfolder at the beginning. A tool that uses this is then responsible for making sure the relative URLs are resolved correctly.
>
> To sum up, given that all the questions I have are answered like I think is most likely, it would boil down to changing the output of show-externals for svn 1.5 and later just slightly, namely by inserting an additional space between the prepended subfolder and the actual svn:externals definition in each line.
>
> Any thoughts and/or answers?
>
> Cheers,
> Nikolaus
>
>
> [1] http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html
> [2] http://paste.lisp.org/display/127858--
> 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: [PATCHv3] git-p4: add initial support for RCS keywords
From: Pete Wyckoff @ 2012-02-21 12:18 UTC (permalink / raw)
To: Luke Diamand; +Cc: git, Eric Scouten
In-Reply-To: <1329258835-17223-2-git-send-email-luke@diamand.org>
luke@diamand.org wrote on Tue, 14 Feb 2012 22:33 +0000:
> diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
[..]
> +git-p4.attemptRCSCleanup:
> + If enabled, 'git p4 submit' will attempt to sort cleanup RCS keywords
> + ($Header$, etc). These would otherwise cause merge conflicts and prevent
> + the submit going ahead. This option should be considered experimental at
> + present.
=> "attempt to cleanup"
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
[..]
> +#
> +# return the raw p4 type of a file (text, text+ko, etc)
> +#
> +def p4_type(file):
> + files = p4_read_pipe_lines(["files", file])
> + info = files[0]
> + m = re.search(r'\(([a-z0-9A-Z+]+)\)\s*$', info)
> + if m:
> + ret = m.group(1)
> + if verbose:
> + print "%s => %s" % (file, ret)
> + return ret
> + else:
> + die("Could not extract file type from '%s'" % info)
p4 fstat -T headType
gives just the type, no need to parse the info string
> +#
> +# Given a type base and modifier, return a regexp matching
> +# the keywords that can be expanded in the file
> +#
> +def p4_keywords_regexp_for_type(base, type_mods):
> + if base in ("text", "unicode", "binary"):
> + if "ko" in type_mods:
> + return r'\$(Id|Header)[^$]*\$'
> + elif "k" in type_mods:
> + return r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision)[^$]*\$'
Still no ":"? Won't that match too much?
> + def patchRCSKeywords(self, file, pattern):
Nice, clean.
> def p4UserForCommit(self,id):
[..]
> + for line in read_pipe_lines(diffcmd):
> + # read diff lines: for each file reported, if it can have
> + # keywords expanded, and the diff contains keywords, then
> + # try zapping the p4 file.
> + m = re.match(r'^diff --git a/(.*)\s+b/(.*)', line)
I'm still sort of iffy on this. You have editedFiles, and could
just use that directly. Grepping through the diff won't give you
any more information.
> + if pattern:
> + print line
Debugging? Maybe add a leading comment saying why this line.
> @@ -1585,15 +1685,11 @@ class P4Sync(Command, P4UserMap):
>
> # Note that we do not try to de-mangle keywords on utf16 files,
> # even though in theory somebody may want that.
> - if type_base in ("text", "unicode", "binary"):
> - if "ko" in type_mods:
> - text = ''.join(contents)
> - text = re.sub(r'\$(Id|Header):[^$]*\$', r'$\1$', text)
> - contents = [ text ]
> - elif "k" in type_mods:
> - text = ''.join(contents)
> - text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$', r'$\1$', text)
> - contents = [ text ]
> + pattern = p4_keywords_regexp_for_type(type_base, type_mods)
> + if pattern:
> + text = ''.join(contents)
> + text = re.sub(pattern, r'$\1$', text)
> + contents = [ text ]
Nice. Glad you refactored this.
Fix the colon thing at least, then happy to add my Acked-By.
Sorry for the delay.
-- Pete
^ permalink raw reply
* cvs2git failed in pass2 ...
From: supadhyay @ 2012-02-21 12:52 UTC (permalink / raw)
To: git
Hi All,
I am using cvs2svn tool to convert my CVS repository to GIT. I have
download the "cvs2svn-2.3.0.tar.gz" file.
I have created git user to install GIT and then using the same user (git) I
try to run "./cvs2git" command below way.
./cvs2git \ --blobfile=/home/git/tmp/git-files/git-blob.dat \
--dumpfile=/home/git/tmp/git-files/git-dump.dat \ --username=git
/opt/source/Repo_from_CVS/VD
It took around 10 mins to finish pass1 and for pass 2 it raised the warnings
and messages like below
==============================================================
Done
Time for pass1 (CollectRevsPass): 526.3 seconds.
----- pass 2 (CleanMetadataPass) -----
Converting metadata to UTF8...
WARNING: Problem decoding log message:
---------------------------------------------------------------------------
version 4 - Note concerning “Leave One” option for Internal Duplicate Check
added
---------------------------------------------------------------------------
WARNING: Problem decoding log message:
---------------------------------------------------------------------------
......
......
......
---------------------------------------------------------------------------
WARNING: Problem decoding log message:
---------------------------------------------------------------------------
all labels to be right-justified
all labels to end with “:”
removed Selected Error Codes label
‘Select One’ dropdowns are horizontally aligned with corresponding text
boxes
---------------------------------------------------------------------------
ERROR: There were warnings converting author names and/or log messages
to Unicode (see messages above). Please restart this pass
with one or more '--encoding' parameters or with
'--fallback-encoding'.
***********************************************************************************
can any one suggest me how to overcome this warning or any workaround ??
Thanks in advance...
--
View this message in context: http://git.661346.n2.nabble.com/cvs2git-failed-in-pass2-tp7304605p7304605.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Patchset NTLM-Authentication
From: Thomas Rast @ 2012-02-21 13:28 UTC (permalink / raw)
To: Schmidt, Marco; +Cc: git, gitster, avarab
In-Reply-To: <4CDEC141B5583D408E79F2931DB7708301802BE7@GSX300A.mxchg.m.corp>
"Schmidt, Marco" <Marco.Schmidt@cassidian.com> writes:
> Thanks for your reply. I have used the wereHamster bundler service and
> created the following patch. May I ask you to test the patch and check
> again for more style violations?
Please keep these discussions public, so that others can learn and
(heaven forbid...) point out _my_ mistakes.
I'll discuss the file you attached below. Keep in mind that unless
there is a compelling reason not to do that, you should send your
patches inline. This allows for much easier review on the list.
> Subject: [PATCH] Allow NTLM-Authentication against a http-proxy server - Add
> config option "http.proxyauthany" - Set CURLOPT_PROXYAUTH
> to CURLAUTH_ANY if option curl_http_proxyauthany is true.
>
> ---
You can already see that you did not adhere to the standard format of a
commit message: one line summary, followed by a blank line, followed by
a long description. So the above might have been written (dropping the
Subject: pseudoheader tag now):
} Allow NTLM-Authentication against a http-proxy server
}
} - Add config option "http.proxyauthany"
}
} - Set CURLOPT_PROXYAUTH to CURLAUTH_ANY if option
} curl_http_proxyauthany is true.
Now bear in mind that I have no clue about curl (except that it
downloads stuff ;-) and especially about its authentication parts. But
allow me to sketch a different commit message that highlights what I
would like to see answered. I am merely using the knowledge I could
glean from 2min of googling around; I am not saying that anything of it
is correct, so you should fix it as needed!
http/curl: let user configure "any" proxy authentication
Normally, curl uses only the "basic" authentication scheme when
talking to proxies, which may not be desirable (it sends the password
in cleartext) or sufficient (the author needs NTLM authentication for
his proxy).
Introduce the config setting http.proxyAuthAny. When enabled, we tell
curl to use any authentication scheme supported by the proxy.
This mostly parallels http.authAny which was introduced in b8ac923
(Add an option for using any HTTP authentication scheme, not only
basic, 2009-11-27). http.authAny was removed, and its feature
unconditionally enabled, in 525ecd2 (Remove http.authAny, 2009-12-28).
However the reasoning of the latter does not apply here because XXXX.
Some notes on the code/patch: There was some trailing whitespace, please
make sure you remove it.
Usually we introduce a setting (command line option or environment
variable) that can be tweaked to override the configuration. b8ac923
did this if you need some inspiration :-) Otherwise you should make an
argument why this is not needed.
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
> + if (curl_http_proxyauthany) {
> + curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
> + }
> +#endif
My google is failing me as to when this feature was introduced or how
common curls without it still are. But you could be extra doubly nice
to the user and warn if s/he enabled the feature, but git cannot adhere
to the request because curl doesn't support it. (Then again b8ac923
didn't go that far either.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: cvs2git failed in pass2 ...
From: supadhyay @ 2012-02-21 14:19 UTC (permalink / raw)
To: git
In-Reply-To: <1329828722466-7304605.post@n2.nabble.com>
Hi All,
Can any one know how to overcome this error... I tried with --encoding=UTF8
but the same error.
I also gave a try with --fallback-encoding but seems like its exclude
comments from their output as shown below:
Time for pass2 (CleanMetadataPass): 0.590 seconds.
cvs2svn Statistics:
------------------
Total CVS Files: 9025
Total CVS Revisions: 39243
Total CVS Branches: 76789
Total CVS Tags: 1276127
Total Unique Tags: 480
Total Unique Branches: 32
CVS Repos Size in KB: 872465
First Revision Date: Mon Aug 2 15:07:28 2004
Last Revision Date: Fri Feb 17 13:10:27 2012
------------------
*(These are unaltered CVS repository stats and do not
reflect tags or branches excluded via --exclude)
Timings (seconds):*
------------------
530.3 pass1 CollectRevsPass
0.6 pass2 CleanMetadataPass
530.9 total
--
View this message in context: http://git.661346.n2.nabble.com/cvs2git-failed-in-pass2-tp7304605p7304832.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH 1/4] t3900: add missing UTF-16.txt and mark the test successful
From: Nguyễn Thái Ngọc Duy @ 2012-02-21 14:24 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
t/t3900-i18n-commit.sh | 4 ++--
t/t3900/UTF-16.txt | Bin 0 -> 18 bytes
2 files changed, 2 insertions(+), 2 deletions(-)
create mode 100644 t/t3900/UTF-16.txt
diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh
index d48a7c0..a9e5662 100755
--- a/t/t3900-i18n-commit.sh
+++ b/t/t3900-i18n-commit.sh
@@ -34,9 +34,9 @@ test_expect_success 'no encoding header for base case' '
test z = "z$E"
'
-test_expect_failure 'UTF-16 refused because of NULs' '
+test_expect_success 'UTF-16 refused because of NULs' '
echo UTF-16 >F &&
- git commit -a -F "$TEST_DIRECTORY"/t3900/UTF-16.txt
+ test_must_fail git commit -a -F "$TEST_DIRECTORY"/t3900/UTF-16.txt
'
diff --git a/t/t3900/UTF-16.txt b/t/t3900/UTF-16.txt
new file mode 100644
index 0000000000000000000000000000000000000000..8d0945b8e0a734ced8948da29ed9f8c65e3ec775
GIT binary patch
literal 18
VcmezW&xIi$409P$8B!Ry7yv#b1kV5f
literal 0
HcmV?d00001
--
1.7.8.36.g69ee2
^ permalink raw reply related
* [PATCH 2/4] Do attempt pretty print in ASCII-incompatible encodings
From: Nguyễn Thái Ngọc Duy @ 2012-02-21 14:24 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1329834292-2511-1-git-send-email-pclouds@gmail.com>
We rely on ASCII everywhere. We print "\n" directly without conversion
for example. The end result would be a mix of some encoding and ASCII
if they are incompatible. Do not do that.
In theory we could convert everything to utf-8 as intermediate medium,
process process process, then convert final output to the desired
encoding. But that's a lot of work (unless we have a pager-like
converter) with little real use. Users can just pipe everything to
iconv instead.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
It seems half of the encodings "iconv -l" list does not pass
ascii_superset_encoding() test. I just assume they are either exotic
or duplicate names.
pretty.c | 7 +++++++
utf8.c | 15 +++++++++++++++
utf8.h | 1 +
3 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index 8688b8f..5c433a2 100644
--- a/pretty.c
+++ b/pretty.c
@@ -493,12 +493,19 @@ char *logmsg_reencode(const struct commit *commit,
const char *output_encoding)
{
static const char *utf8 = "UTF-8";
+ static const char *last_output_encoding = NULL;
const char *use_encoding;
char *encoding;
char *out;
if (!*output_encoding)
return NULL;
+ if (last_output_encoding != output_encoding) {
+ if (!ascii_superset_encoding(output_encoding))
+ die("encoding %s is not a superset of ASCII.",
+ output_encoding);
+ last_output_encoding = output_encoding;
+ }
encoding = get_header(commit, "encoding");
use_encoding = encoding ? encoding : utf8;
if (!strcmp(use_encoding, output_encoding))
diff --git a/utf8.c b/utf8.c
index 8acbc66..def93ee 100644
--- a/utf8.c
+++ b/utf8.c
@@ -482,3 +482,18 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
return out;
}
#endif
+
+int ascii_superset_encoding(const char *encoding)
+{
+ const char *sample = " !\"#$%&'()*+,-./0123456789:;<=>?@"
+ "ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`"
+ "abcdefghijklmnopqrstuvwxyz{|}~\n";
+ char *output;
+ int ret;
+ if (!encoding)
+ return 1;
+ output = reencode_string(sample, encoding, "US-ASCII");
+ ret = !output || !strcmp(sample, output);
+ free(output);
+ return ret;
+}
diff --git a/utf8.h b/utf8.h
index 81f2c82..75bc128 100644
--- a/utf8.h
+++ b/utf8.h
@@ -12,6 +12,7 @@ int strbuf_add_wrapped_text(struct strbuf *buf,
const char *text, int indent, int indent2, int width);
int strbuf_add_wrapped_bytes(struct strbuf *buf, const char *data, int len,
int indent, int indent2, int width);
+int ascii_superset_encoding(const char *encoding);
#ifndef NO_ICONV
char *reencode_string(const char *in, const char *out_encoding, const char *in_encoding);
--
1.7.8.36.g69ee2
^ permalink raw reply related
* [PATCH 3/4] utf8: die if failed to re-encoding
From: Nguyễn Thái Ngọc Duy @ 2012-02-21 14:24 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1329834292-2511-1-git-send-email-pclouds@gmail.com>
Return value NULL in this case means "no conversion needed", which is
not quite true when conv == -1.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
t/t4201-shortlog.sh | 2 +-
utf8.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
index 6872ba1..d445665 100755
--- a/t/t4201-shortlog.sh
+++ b/t/t4201-shortlog.sh
@@ -27,7 +27,7 @@ test_expect_success 'setup' '
tr 1234 "\360\235\204\236")" a1 &&
# now fsck up the utf8
- git config i18n.commitencoding non-utf-8 &&
+ git config i18n.commitencoding viscii &&
echo 4 >a1 &&
git commit --quiet -m "$(
echo "This is a very, very long first line for the commit message to see if it is wrapped correctly" |
diff --git a/utf8.c b/utf8.c
index def93ee..f918e9e 100644
--- a/utf8.c
+++ b/utf8.c
@@ -444,7 +444,7 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
return NULL;
conv = iconv_open(out_encoding, in_encoding);
if (conv == (iconv_t) -1)
- return NULL;
+ die("failed to convert from %s to %s", in_encoding, out_encoding);
insz = strlen(in);
outsz = insz;
outalloc = outsz + 1; /* for terminating NUL */
--
1.7.8.36.g69ee2
^ permalink raw reply related
* [PATCH 4/4] Only re-encode certain parts in commit object, not the whole
From: Nguyễn Thái Ngọc Duy @ 2012-02-21 14:24 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1329834292-2511-1-git-send-email-pclouds@gmail.com>
Commit object has its own format, which happens to be in ascii, but
not really subject to re-encoding.
There are only four areas that may be re-encoded: author line,
committer line, mergetag lines and commit body. Encoding of tags
embedded in mergetag lines is not decided by commit encoding, so leave
it out and consider it binary.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
pretty.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 57 insertions(+), 1 deletions(-)
diff --git a/pretty.c b/pretty.c
index 5c433a2..6ccc091 100644
--- a/pretty.c
+++ b/pretty.c
@@ -489,6 +489,62 @@ static char *replace_encoding_header(char *buf, const char *encoding)
return strbuf_detach(&tmp, NULL);
}
+/*
+ * Re-encode author, committer and commit body only, leaving the rest
+ * in ascii (or whatever the encoding it is in mergetag lines)
+ * regardless output encoding. We assume the commit is good, so no
+ * validation.
+ */
+static char *reencode_commit(const char *buffer,
+ const char *out_enc, const char *in_enc)
+{
+ struct strbuf out = STRBUF_INIT;
+ struct strbuf buf = STRBUF_INIT;
+ char *reencoded, *s, *e;
+
+ strbuf_addstr(&buf, buffer);
+
+ s = strstr(buf.buf, "\nauthor ");
+ assert(s != NULL);
+ s += 8; /* "\nauthor " */
+ strbuf_add(&out, buf.buf, s - buf.buf);
+ e = strchr(s, '\n');
+ *e = '\0';
+ reencoded = reencode_string(s, out_enc, in_enc);
+ if (reencoded && strchr(reencoded, '\n'))
+ die("your chosen encoding produces \\n out of nowhere?");
+ strbuf_addstr(&out, reencoded ? reencoded : s);
+ free(reencoded);
+
+ strbuf_addstr(&out, "\ncommitter ");
+ assert(!strncmp(e + 1, "committer ", 10));
+ s = e + 11; /* "\ncommitter " */
+ e = strchr(s, '\n');
+ *e = '\0';
+ reencoded = reencode_string(s, out_enc, in_enc);
+ if (reencoded && strchr(reencoded, '\n'))
+ die("your chosen encoding produces \\n out of nowhere?");
+ strbuf_addstr(&out, reencoded ? reencoded : s);
+ free(reencoded);
+ *e = '\n';
+
+ s = e;
+ e = strstr(s, "\n\n");
+ if (e) {
+ e += 2; /* "\n\n" */
+ strbuf_add(&out, s, e - s);
+
+ s = e;
+ reencoded = reencode_string(s, out_enc, in_enc);
+ strbuf_addstr(&out, reencoded ? reencoded : s);
+ free(reencoded);
+ } else
+ strbuf_addstr(&out, s);
+
+ strbuf_release(&buf);
+ return strbuf_detach(&out, NULL);
+}
+
char *logmsg_reencode(const struct commit *commit,
const char *output_encoding)
{
@@ -514,7 +570,7 @@ char *logmsg_reencode(const struct commit *commit,
else
return NULL; /* nothing to do */
else
- out = reencode_string(commit->buffer,
+ out = reencode_commit(commit->buffer,
output_encoding, use_encoding);
if (out)
out = replace_encoding_header(out, output_encoding);
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Allow NTLM-Authentication against a http-proxy server
From: Schmidt, Marco @ 2012-02-21 14:31 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 265 bytes --]
After some back and forward - here is my patch to support
NTLM-authentication against a http-proxy server again.
Big thanks are going to Thomas Rast for helping to fiddle the patch to a
more correct form and his commit message ;).
Marco Schmidt
[-- Attachment #2: 0001-http-curl-let-user-configure-any-proxy-authenticatio.patch --]
[-- Type: application/octet-stream, Size: 1835 bytes --]
From f4e112e41aef75f08532fda53a1b9021208a3774 Mon Sep 17 00:00:00 2001
From: Marco Schmidt <Marco.Schmidt@cassidian.com>
Date: Tue, 21 Feb 2012 12:30:29 +0100
Subject: [PATCH] http/curl: let user configure "any" proxy authentication
Normally, curl uses only the "basic" authentication scheme when
talking to proxies, which may not be desirable (it sends the password
in cleartext) or sufficient (the author needs NTLM authentication for
his proxy).
Introduce the config setting http.proxyAuthAny. When enabled, we tell
curl to use any authentication scheme supported by the proxy
---
http.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/http.c b/http.c
index 0ffd79c..5c55efd 100644
--- a/http.c
+++ b/http.c
@@ -41,6 +41,7 @@ static long curl_low_speed_limit = -1;
static long curl_low_speed_time = -1;
static int curl_ftp_no_epsv;
static const char *curl_http_proxy;
+static int curl_http_proxyauthany = 0;
static const char *curl_cookie_file;
static struct credential http_auth = CREDENTIAL_INIT;
static int http_proactive_auth;
@@ -190,6 +191,11 @@ static int http_options(const char *var, const char *value, void *cb)
}
if (!strcmp("http.proxy", var))
return git_config_string(&curl_http_proxy, var, value);
+
+ if (!strcmp("http.proxyauthany", var)) {
+ curl_http_proxyauthany = git_config_bool(var, value);
+ return 0;
+ }
if (!strcmp("http.cookiefile", var))
return git_config_string(&curl_cookie_file, var, value);
@@ -297,6 +303,12 @@ static CURL *get_curl_handle(void)
if (curl_http_proxy)
curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
+
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+ if (curl_http_proxyauthany) {
+ curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
+ }
+#endif
return result;
}
--
1.7.7.1.msysgit.0
^ permalink raw reply related
* Re: git status: small difference between stating whole repository and small subdirectory
From: Nguyen Thai Ngoc Duy @ 2012-02-21 14:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Jeff King, Piotr Krukowiecki, Git Mailing List
In-Reply-To: <20120220143644.GA13938@do>
On Mon, Feb 20, 2012 at 9:36 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Mon, Feb 20, 2012 at 03:09:57PM +0100, Thomas Rast wrote:
>> > Interestingly, on my git.git repo, I had an empty cache. Running "git
>> > read-tree HEAD" filled it (according to test-dump-cache-tree). It seems
>> > that running "git checkout" empties the cache. So perhaps git could do
>> > better about keeping the cache valid over time.
>>
>> test_expect_failure 'checkout gives cache-tree' '
>> git checkout HEAD^ &&
>> test_shallow_cache_tree
>> '
>>
>> ;-)
>
> Quick and dirty that passes that test.
I'm aware that Jeff's tackling at lower level, which retains
cache-tree for many more cases. But this patch seems simple and safe
to me, and in my experience this case happens quite often (or maybe I
tend to keep my index clean). Junio, any chance this patch may get in?
> -- 8< --
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index 5bf96ba..c06287a 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -319,6 +319,10 @@ static void show_local_changes(struct object *head, struct diff_options *opts)
> die(_("diff_setup_done failed"));
> add_pending_object(&rev, head, NULL);
> run_diff_index(&rev, 0);
> + if (!DIFF_OPT_TST(&rev.diffopt, HAS_CHANGES)) {
> + struct tree *tree = parse_tree_indirect(head->sha1);
> + prime_cache_tree(&active_cache_tree, tree);
> + }
> }
>
> static void describe_detached_head(const char *msg, struct commit *commit)
> @@ -493,13 +497,13 @@ static int merge_working_tree(struct checkout_opts *opts,
> }
> }
>
> + if (!opts->force && !opts->quiet)
> + show_local_changes(&new->commit->object, &opts->diff_options);
> +
> if (write_cache(newfd, active_cache, active_nr) ||
> commit_locked_index(lock_file))
> die(_("unable to write new index file"));
>
> - if (!opts->force && !opts->quiet)
> - show_local_changes(&new->commit->object, &opts->diff_options);
> -
> return 0;
> }
>
> -- 8< --
> --
> Duy
--
Duy
^ permalink raw reply
* Re: [PATCH 2/4] Do attempt pretty print in ASCII-incompatible encodings
From: Nguyen Thai Ngoc Duy @ 2012-02-21 14:53 UTC (permalink / raw)
To: git
In-Reply-To: <1329834292-2511-2-git-send-email-pclouds@gmail.com>
2012/2/21 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
> @@ -482,3 +482,18 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
> return out;
> }
> #endif
> +
> +int ascii_superset_encoding(const char *encoding)
> +{
> + const char *sample = " !\"#$%&'()*+,-./0123456789:;<=>?@"
> + "ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`"
> + "abcdefghijklmnopqrstuvwxyz{|}~\n";
> + char *output;
> + int ret;
> + if (!encoding)
> + return 1;
> + output = reencode_string(sample, encoding, "US-ASCII");
> + ret = !output || !strcmp(sample, output);
> + free(output);
> + return ret;
> +}
Side note about this function, which was written to ban all
ascii-incompatible charsets from entering commit objects. The idea of
mixing charsets in the same buffer without clear boundary does not
sound healthy. Plus, ident.c will silently drop '\n', '<' and '>' in
author/committer. If a hypothetical charset happens to place a letter
in those, um.. code points?, the letter will be dropped. But meh..
--
Duy
^ permalink raw reply
* Re: [PATCH 0/8 v6] diff --stat: use the full terminal width
From: Nguyen Thai Ngoc Duy @ 2012-02-21 15:16 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, gitster, Michael J Gruber, j.sixt
In-Reply-To: <1329775034-21551-1-git-send-email-zbyszek@in.waw.pl>
Not related to changes in the series, but on the same topic. Have you
considered grouping pathnames to reduce pressure on truncating them?
Instead of showing
a/b/c | ++--
a/b/d | --++
you could show
a/b:
c | ++--
d | --++
Optimal grouping strategy could be hard, but at least we could use it
for the case "git diff --stat -- one/path/deep/in/here"
--
Duy
^ permalink raw reply
* Re: cvs2git failed in pass2 ...
From: supadhyay @ 2012-02-21 15:17 UTC (permalink / raw)
To: git
In-Reply-To: <1329828722466-7304605.post@n2.nabble.com>
Hi All,
I am able to run cvs2git command successfully by adding --encoding=ascii
--encoding=utf8 --encoding=utf16 --encoding=latin
Thanks...
--
View this message in context: http://git.661346.n2.nabble.com/cvs2git-failed-in-pass2-tp7304605p7305031.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC/PATCH 0/3] push: add 'prune' option
From: Nguyen Thai Ngoc Duy @ 2012-02-21 15:30 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <1329505957-24595-1-git-send-email-felipe.contreras@gmail.com>
On Sat, Feb 18, 2012 at 2:12 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> As an example I put my use-case; I want to backup *all* my local branches to a
> personal repository, and I want to remove branches that I have removed from my
> local repository. git push personal 'refs/heads/*' mostly does the job, but it
> doesn't remove anything, and that's where 'prune' comes from.
Yeah, may I have "fetch --prune" too, please? Looking at diffstat
gives me a feeling that you only need to add maybe four lines to
builtin/fetch.c and my dream would come true.
--
Duy
^ permalink raw reply
* Re: [PATCH 0/8 v6] diff --stat: use the full terminal width
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-21 16:11 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, gitster, Michael J Gruber, j.sixt
In-Reply-To: <CACsJy8AXH6xm-ShH_HF6RwATFwsYtAZQfcWoB9VpaiCMj6e8vQ@mail.gmail.com>
On 02/21/2012 04:16 PM, Nguyen Thai Ngoc Duy wrote:
> Not related to changes in the series, but on the same topic. Have you
> considered grouping pathnames to reduce pressure on truncating them?
> Instead of showing
>
> a/b/c | ++--
> a/b/d | --++
>
> you could show
>
> a/b:
> c | ++--
> d | --++
>
> Optimal grouping strategy could be hard, but at least we could use it
> for the case "git diff --stat -- one/path/deep/in/here"
I use (or would like to be able to use) the --stat output to select with
the mouse and paste into something like
emacsclient -n <pathname>
This would be harder with the grouping, because I'd have to select two
parts and paste two times and type a slash. So for me this would be a minus.
Also, I'm not sure about grouping if there's more than one group. The
graph wouldn't be as readable. But if there's only one group, i.e. if
all filenames have a common prefix ending in a slash, like in your
example, this could be useful.
Zbyszek
^ permalink raw reply
* Re: [PATCHv3] git-p4: add initial support for RCS keywords
From: Eric Scouten @ 2012-02-21 16:54 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Luke Diamand, git
In-Reply-To: <20120221121834.GB18317@padd.com>
[Resent in plain-text. Apologies for dupe content to Pete and Luke.]
On Tue, Feb 21, 2012 at 04:18, Pete Wyckoff <pw@padd.com> wrote:
> luke@diamand.org wrote on Tue, 14 Feb 2012 22:33 +0000:
> > diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> > +#
> > +# Given a type base and modifier, return a regexp matching
> > +# the keywords that can be expanded in the file
> > +#
> > +def p4_keywords_regexp_for_type(base, type_mods):
> > + if base in ("text", "unicode", "binary"):
> > + if "ko" in type_mods:
> > + return r'\$(Id|Header)[^$]*\$'
> > + elif "k" in type_mods:
> > + return
> > r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision)[^$]*\$'
>
> Still no ":"? Won't that match too much?
> Fix the colon thing at least, then happy to add my Acked-By.
No, that would be an incorrect change. The colon is added by P4 when
it expands the keyword pattern, but it is *not* part of the pattern
required by P4 to trigger a keyword expansion.
http://kb.perforce.com/article/54/using-rcs-keywords
-Eric
--
Eric Scouten :: software developer, photographer :: Poulsbo, WA (near Seattle)
http://ericscouten.com :: click for Flickr, Facebook, Twitter, LinkedIn links
^ permalink raw reply
* Re: [PATCHv3] git-p4: add initial support for RCS keywords
From: Junio C Hamano @ 2012-02-21 17:25 UTC (permalink / raw)
To: Eric Scouten; +Cc: Pete Wyckoff, Luke Diamand, git
In-Reply-To: <CAEe=O8qui8PryuZiZNDwLk39+tKVDnh+5eP9m_WrHi=K9ekMNQ@mail.gmail.com>
Eric Scouten <eric@scouten.com> writes:
>> > r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision)[^$]*\$'
>>
>> Still no ":"? Won't that match too much?
>
>> Fix the colon thing at least, then happy to add my Acked-By.
>
> No, that would be an incorrect change. The colon is added by P4 when
> it expands the keyword pattern, but it is *not* part of the pattern
> required by P4 to trigger a keyword expansion.
>
> http://kb.perforce.com/article/54/using-rcs-keywords
I have this suspicion that both Pete and your last sentence is correct,
but the regexp in the patch and your "would be an incorrect change" are
wrong.
I am not a P4 expert, but I would be very surprised if P4 expands "$Ida$"
as if it is "$Id$" or "$Id: old expansion$", which the regexp would match.
Wouldn't it be more like this?
\$ # begins with a dollar, followed by...
( Id | Header | ... ) # one of these keywords, followed by ...
( :[^$]+ )? # possibly an old expansion, followed by
\$ # another dollar sign
^ permalink raw reply
* Re: [RFC/PATCH 0/3] push: add 'prune' option
From: Jeff King @ 2012-02-21 17:35 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Felipe Contreras, git, Junio C Hamano
In-Reply-To: <CACsJy8ACoF=2dEUoFvT8bQDmUsjJA2_VWvTSJV6fakqyCLBCYg@mail.gmail.com>
On Tue, Feb 21, 2012 at 10:30:31PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Sat, Feb 18, 2012 at 2:12 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > As an example I put my use-case; I want to backup *all* my local branches to a
> > personal repository, and I want to remove branches that I have removed from my
> > local repository. git push personal 'refs/heads/*' mostly does the job, but it
> > doesn't remove anything, and that's where 'prune' comes from.
>
> Yeah, may I have "fetch --prune" too, please? Looking at diffstat
> gives me a feeling that you only need to add maybe four lines to
> builtin/fetch.c and my dream would come true.
Huh? Don't we already have "fetch --prune"?
-Peff
^ permalink raw reply
* Re: [PATCH 3/4] utf8: die if failed to re-encoding
From: Junio C Hamano @ 2012-02-21 17:36 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1329834292-2511-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Return value NULL in this case means "no conversion needed", which is
> not quite true when conv == -1.
Doing this only when producing new commits to avoid spreading damage might
be a good idea.
But utf8.c::reencode_string() is sufficiently deep in the call-chains to
make me suspect that the codepaths this change affects are not limited to
creation ones. If this also forbids readers from resurrecting salvageable
bits while reading (imagine your commit had "encodign vscii" but your log
message was in English, except only your name had letters outside ASCII
that I cannot locally convert to utf-8 for viewing), I do not think it is
an acceptable change.
^ 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