Ah, answering my own question
I can see git svn reset does exactly what I need.
jon.
On Mon, Mar 18, 2013 at 4:03 PM, Jon Seymour wrote:
> G'day,
>
> I managed to lose sync between the git-svn repo that I am using to
> track an svn repo. In particular, the git-svn repo lost the content of
>
On 15-Mar-2013, at 6:44 PM, Magnus Bäck wrote:
>>
>
> Right, but that's R/W permissions. Almost any piece of Git hosting
> software supports restriction of pushes. Discriminating *read* access
> between developers and maintenance people sounds like a disaster if it's
> the same organisation.
Hello list,
I have implemented git pre-received hook successfully. And it works on the repo
level.
Could anyone suggest how to call branch level hook please ?--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 03/16/2013 02:38 PM, Michael Haggerty wrote:
> On 03/16/2013 10:34 AM, Jeff King wrote:
>> On Sat, Mar 16, 2013 at 09:48:42AM +0100, Michael Haggerty wrote:
>>
>>> My patch series is nearly done. I will need another day or two to
>>> review and make it submission-ready, but I wanted to give you
Signed-off-by: Michael Haggerty
and ACK for the whole series, once Junio's points are addressed.
Regarding Junio's readability suggestion: I agree that his versions are
a bit more readable, albeit at the expense of having to evaluate a bit
more logic for each reference rather than just once when
Hi,
I can't say from a first glance. Maybe git@vger can help?
On Sun, Mar 17, 2013 at 10:08 PM, 方栋 wrote:
> hello
>
> i don't understand this:
> src in builtin/pack-objects.c find_deltas() function, line 1800:
>
>
> static void find_deltas(struct object_entry **list, unsigned *list_size,
>
On Mon, Mar 18, 2013 at 4:55 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> This flag is equivalent to builtin/ls-files.c:strip_trailing_slashes()
>> and is intended to replace that function when ls-files is converted to
>> use parse_pathspec.
>>
>> Signed-off-by: Nguyễn Thái Ngọc
Rob Hoelz writes:
> git push currently doesn't consider pushInsteadOf when
> using pushurl; this tests and fixes that.
>
> If you use pushurl with an alias that has a pushInsteadOf configuration
> value, Git does not take advantage of it. For example:
>
> [url "git://github.com/"]
> insteadO
git push currently doesn't consider pushInsteadOf when
using pushurl; this tests and fixes that.
If you use pushurl with an alias that has a pushInsteadOf configuration
value, Git does not take advantage of it. For example:
[url "git://github.com/"]
insteadOf = github:
[url "git://github.com
On Sun, 17 Mar 2013 15:14:32 -0700
Junio C Hamano wrote:
> Rob Hoelz writes:
>
> > Hi everyone! I found a bug in Git today and wrote up a fix; I did
> > my best to conform to the rules layed out in
> > Documentation/SubmittingPatches, but please let me know if I need
> > to change anything to
Antoine Pelisse writes:
> +/* Coalesce new lines into base by finding LCS */
> +static struct lline *coalesce_lines(struct lline *base, int *lenbase,
> + struct lline *new, int lennew,
> + unsigned long parent)
> +{
Don't you want t
Daniel Stenberg writes:
> On Sun, 17 Mar 2013, Antoine Pelisse wrote:
>
>>> With redirects taken into account, I can't think of any really good way
>>> around avoiding this init...
>>
>> Is there any way for curl to initialize SSL on-demand ?
>
> Yes, but not without drawbacks.
>
> If you don't c
Syntax branchname@{upstream} should interpret its argument as a name of
a branch. Add the test to check that it doesn't try to interpret it as a
refname if the branch in question does not exist.
Signed-off-by: Kacper Kornet
---
Maybe I'm too cautious adding this test. But just in case here it is
Rob Hoelz writes:
> Hi everyone! I found a bug in Git today and wrote up a fix; I did my best to
> conform to the rules layed out in Documentation/SubmittingPatches, but please
> let me know if I need to change anything to get my work merged. =) I have
> CC'ed Josh Triplet, as
> he was the l
On Sun, 17 Mar 2013, Antoine Pelisse wrote:
With redirects taken into account, I can't think of any really good way
around avoiding this init...
Is there any way for curl to initialize SSL on-demand ?
Yes, but not without drawbacks.
If you don't call curl_global_init() at all, libcurl will
Nguyễn Thái Ngọc Duy writes:
> GUARD_PATHSPEC() marks pathspec-sensitive code (basically anything in
> 'struct pathspec' except fields "nr" and "original"). GUARD_PATHSPEC()
> is not supposed to fail. The steps for a new pathspec magic or
> optimization would be:
>
> - update parse_pathspec, ad
Nguyễn Thái Ngọc Duy writes:
> This flag is equivalent to builtin/ls-files.c:strip_trailing_slashes()
> and is intended to replace that function when ls-files is converted to
> use parse_pathspec.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> pathspec.c | 9 +
> pathspec.h | 1 +
> 2
Hi everyone! I found a bug in Git today and wrote up a fix; I did my best to
conform to the rules layed out in Documentation/SubmittingPatches, but please
let me know if I need to change anything to get my work merged. =) I have
CC'ed Josh Triplet, as
he was the last one to touch the line I mo
Hopefully, my patch takes about the same time as git 1.7.9.5 and
produces the same output on that commit ;)
Unfortunately on a commit that would remove A LOT of lines (1)
from 7 parents, the times goes from 0.01s to 1.5s... I'm pretty sure
that scenario is quite uncommon though.
On Sun, Mar 17
Duy Nguyen writes:
> This env comes from jc/sha1-lookup in 2008 (merge commit e9f9d4f), 5
> years ago. I wonder if it's good enough to turn on by default and keep
> improving from there, or is it still experimental?
The algorithm has been used in production in other codepaths like
patch-ids and
Antoine Pelisse writes:
> This replaces the greedy implementation to coalesce lost lines by using
> dynamic programming to find the Longest Common Subsequence.
>
> The O(n²) time complexity is obviously bigger than previous
> implementation but it can produce shorter diff results (and most likely
danny.tho...@blackboard.com wrote on Wed, 13 Mar 2013 13:51 -0400:
> By default, newly added binary files are exclusively locked by Perforce:
>
> 'add default change (binary+l) *exclusive*'
>
> This results in a 'Could not determine file type' error as the regex
> expects
> the line to end after
Jeff King writes:
> From: Michael Haggerty
>
> Older versions of pack-refs did not write peel lines for
> refs outside of refs/tags. This meant that on reading the
> pack-refs file, we might set the REF_KNOWS_PEELED flag for
> such a ref, even though we do not know anything about its
> peeled va
Steven Walter writes:
> If two processes are racing to create the same directory tree, they will
> both see that the directory doesn't exist, both try to mkdir(), and one
> of them will fail. This is okay, as we only care that the directory
> gets created. So, we add a check for EEXIST from mkd
> With redirects taken into account, I can't think of any really good way
> around avoiding this init...
Is there any way for curl to initialize SSL on-demand ?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo in
Am 17.03.2013 06:40, schrieb Jeff King:
We do have the capability to roll out to one or a few of our servers
(the granularity is not 0.2%, but it is still small). I'm going to try
to keep us more in sync with upstream git, but I don't know if I will
get to the point of ever deploying "master" or
If two processes are racing to create the same directory tree, they will
both see that the directory doesn't exist, both try to mkdir(), and one
of them will fail. This is okay, as we only care that the directory
gets created. So, we add a check for EEXIST from mkdir, and continue if
the director
> I'm also having a hard time trying it with more than two parents. How I
> am supposed to have more than two parents while octopus merge refuses if
> there are conflicts ?
OK, creating the merge commit myself solves the issue:
git init
>test
git add test
git commit -m initial
seq 100 >test
git
On Thu, Jan 31, 2013 at 6:06 PM, Duy Nguyen wrote:
> On Wed, Jan 30, 2013 at 09:16:29PM +0700, Duy Nguyen wrote:
>> Perhaps we could store abbrev sha-1 instead of full sha-1. Nice
>> space/time trade-off.
>
> Following the on-disk format experiment yesterday, I changed the
> format to:
>
> - a li
This replaces the greedy implementation to coalesce lost lines by using
dynamic programming to find the Longest Common Subsequence.
The O(n²) time complexity is obviously bigger than previous
implementation but it can produce shorter diff results (and most likely
easier to read).
List of lost lin
On 03/17/2013 03:57 AM, David Aguilar wrote:
> In some cases, the default branch background color (green) isn't
> an optimal choice, thus it can be difficult to read.
I'm just curious -- is it "difficult to read" because gitk does not
specify a foreground color, thus causing it to pickup a sys
Am 17.03.2013 08:10, schrieb Junio C Hamano:
@@ -1158,16 +1159,16 @@ static void diagnose_invalid_sha1_path(const char
*prefix,
if (!get_tree_entry(tree_sha1, fullname,
sha1, &mode)) {
die("Path '%s' exists, but not '%s'
On Fri, Mar 15, 2013 at 10:24 PM, Nguyễn Thái Ngọc Duy
wrote:
> This is pretty useful in `%<(100)%s%Cred%>(20)% an' where %s does not
s/% an/%an/
> use up all 100 columns and %an needs more than 20 columns. By
> replacing %>(20) with %>>(20), %an can steal spaces from %s.
>
> diff --git a/Docume
On Fri, Mar 15, 2013 at 10:24 PM, Nguyễn Thái Ngọc Duy
wrote:
> Either %<, %> or %<> standing before a placeholder specifies how many
s/%<>/%> diff --git a/Documentation/pretty-formats.txt
> b/Documentation/pretty-formats.txt
> index 8734224..87ca2c4 100644
> --- a/Documentation/pretty-formats.t
On Fri, Mar 15, 2013 at 10:24 PM, Nguyễn Thái Ngọc Duy
wrote:
> This is not simply convenient over $C(auto,xxx). Some placeholders
s/\$/%/
> (actually only one, %d) do multi coloring and we can't emit a multiple
> colors with %C(auto,xxx).
>
> diff --git a/Documentation/pretty-formats.txt
> b/D
On Fri, Mar 15, 2013 at 10:24 PM, Nguyễn Thái Ngọc Duy
wrote:
> The commit encoding is parsed by logmsg_reencode, there's no need for
> the caller to re-parse it again. The reencoded message now have the
s/have/has/
> new encoding, not the original one. The caller would need to read
> commit obj
On Sun, Mar 17, 2013 at 10:28:06AM +0700, Nguyen Thai Ngoc Duy wrote:
> This avoids unnecessary re-allocations and reinsertions. On webkit.git
> (i.e. about 182k inserts to the name hash table), this reduces about
> 100ms out of 3s user time.
Good idea.
I had a similar thought when analyzing the
On Sat, Mar 16, 2013 at 11:17:18PM -0700, Junio C Hamano wrote:
> > I almost wonder if we should cut it out entirely. It is definitely a
> > possible race condition, but I wonder if anybody actually hits it in
> > practice (and if they do, the consequence is that the fetch fails and
> > needs to b
When fast-export wants to export a blob object, it first
calls parse_object to get a "struct object" and check
whether we have already shown the object. If we haven't
shown it, we then use read_sha1_file to pull it from disk
and write it out.
That means we load each blob from disk twice: once for
The handle_object function is rather vaguely named; it only
operates on blobs, and its purpose is to export the blob to
the output stream. Let's call it "export_blob" to make it
more clear what it does.
Signed-off-by: Jeff King
---
builtin/fast-export.c | 6 +++---
1 file changed, 3 insertions(+
While grepping through all of the calls to parse_object (to see how they
handled error conditions, for the other series I just posted), I noticed
this opportunity for a small speedup in fast-export (5-15%). The first
patch is a cleanup, the second is the interesting bit.
[1/2]: fast-export: rena
From: Michael Haggerty
Older versions of pack-refs did not write peel lines for
refs outside of refs/tags. This meant that on reading the
pack-refs file, we might set the REF_KNOWS_PEELED flag for
such a ref, even though we do not know anything about its
peeled value.
The previous commit updated
When we pack an annotated tag ref, we write not only the
sha1 of the tag object along with the ref, but also the sha1
obtained by peeling the tag. This lets readers of the
pack-refs file know the peeled value without having to
actually load the object, speeding up upload-pack's ref
advertisement.
Some call-sites do:
o = parse_object(sha1);
if (!o)
die("bad object %s", some_name);
We can now handle that as a one-liner, and get more
consistent output.
In the third case of this patch, it looks like we are losing
information, as the existing message also outputs the sha1
hex; h
Many call-sites of parse_object assume that they will get a
non-NULL return value; this is not the case if we encounter
an error while parsing the object.
This patch adds a wrapper function around parse_object that
handles dying automatically, and uses it anywhere we
immediately try to access the
Here's a re-roll that takes into account the feedback from round 1:
[1/4]: avoid segfaults on parse_object failure
[2/4]: use parse_object_or_die instead of die("bad object")
These two patches are new; they are conceptually independent of the rest
of the series, but there's a textual dependen
René Scharfe writes:
> The only caller of diagnose_invalid_sha1_path() extracts a substring from
> an object name by creating a NUL-terminated copy of the interesting part.
> Add a length parameter to the function and thus avoid the need for an
> allocation, thereby simplifying the code.
>
> Sign
47 matches
Mail list logo
