thomas sabo charms - Barbie Charm bracelets

This early history on the attraction bracelet possesses manufactured an enormous comeback while using the * thomas sabo charms * . No matter if you wish to allow the item absent to be a memento, wear it for equipment or maybe treat the item, this Tho

Re: [PATCH 4/4] fast-import: only store commit objects

On 05/07/2013 06:47 AM, Felipe Contreras wrote: > On Mon, May 6, 2013 at 10:27 PM, Michael Haggerty > wrote: > >> You conjectured earlier that nobody uses blob marks, and I provided a >> counterexample. Then you proposed a workaround that would require >> changes to the cvs2git documentation, a

Re: [PATCH 0/4] fix packed-refs races

Thanks. I queued this, and will push the result out on the side of 'pu' closer to 'next'. Could you double check the conflict resolution? I haven't got around to the peel-ref-cleanup yet. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.

Re: [PATCH] deprecate core.statinfo at Git 2.0 boundary

Junio C Hamano writes: > For now, add core.checkstat, and warn people who have core.statinfo > in their configuration file that we will remove it in Git 2.0. And an obvious follow-up for the 2.0 looks like this. -- >8 -- Subject: [PATCH] core.statinfo: remove as promised in Git 2.0 Signed-off-

Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config

Matthieu Moy writes: > More precisely: you should have a look at git-multimail (in directory > contrib/, in branch for now pu/, or from > https://github.com/mhagger/git-multimail) before spending time on > post-receive-email. Oh, by the way, is this a vote of confidence in that topic, hinting th

[PATCH] deprecate core.statinfo at Git 2.0 boundary

c08e4d5b5cfa (Enable minimal stat checking, 2013-01-22) advertised the configuration variable core.checkstat in the documentation and its log message, but the code expected core.statinfo instead. For now, add core.checkstat, and warn people who have core.statinfo in their configuration file that w

Re: [PATCH] merge-tree: handle directory/empty conflict correctly

Andreas Jacobsen writes: > On 6 May 2013 17:20, John Keeping wrote: >> Andreas, can you try this patch and see if it fixes your test case? > > Worked perfectly. Thank you, John :) Thanks, both. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord.

Re: [PATCH v3] Enable minimal stat checking

Jeff King writes: > On Tue, Jan 22, 2013 at 08:49:22AM +0100, Robin Rosenberg wrote: > >> Specifically the fields uid, gid, ctime, ino and dev are set to zero >> by JGit. Other implementations, eg. Git in cygwin are allegedly also >> somewhat incompatible with Git For Windows and on *nix platform

Re: [PATCH] merge-tree: handle directory/empty conflict correctly

On 6 May 2013 17:20, John Keeping wrote: > Andreas, can you try this patch and see if it fixes your test case? Worked perfectly. Thank you, John :) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http:

Re: [RFC] git: make signoff header configurable

"Arend van Spriel" writes: > I had an itch to scratch. Like the -s command line parameter to > get the signed-off message added, but not all projects use the > same signature format. So let me know what you think about this > idea. Never contributed to git before so decided to make it an > RFC fi

Re: [PATCH 4/4] fast-import: only store commit objects

On Mon, May 6, 2013 at 11:39 PM, Johannes Schindelin wrote: > Hi, > > On Tue, 7 May 2013, Michael Haggerty wrote: > >> On 05/06/2013 11:04 PM, Felipe Contreras wrote: >> > On Mon, May 6, 2013 at 5:45 AM, Michael Haggerty >> > wrote: >> >> On 05/06/2013 12:32 PM, Thomas Rast wrote: > >> >> So the

[PATCHv2] l10n: de.po: translate 44 new messages

Translate 44 new messages came from git.pot update in c6bc7d4 (l10n: git.pot: v1.8.3 round 2 (44 new, 12 removed)). Signed-off-by: Ralf Thielow Acked-by: Thomas Rast --- po/de.po | 138 +++ 1 file changed, 76 insertions(+), 62 deletion

Re: [PATCH 4/4] fast-import: only store commit objects

On Mon, May 6, 2013 at 10:27 PM, Michael Haggerty wrote: > You conjectured earlier that nobody uses blob marks, and I provided a > counterexample. Then you proposed a workaround that would require > changes to the cvs2git documentation, and I even explained how your > proposed workaround is not

Re: another packed-refs race

On Tue, May 07, 2013 at 06:32:12AM +0200, Michael Haggerty wrote: > Another potential problem caused by the non-atomicity of loose reference > reading could be to confuse reachability tests if process 1 is reading > loose references while process 2 is renaming a reference: > > 1. Process 1 looks

Re: [PATCH 4/4] fast-import: only store commit objects

Hi, On Tue, 7 May 2013, Michael Haggerty wrote: > On 05/06/2013 11:04 PM, Felipe Contreras wrote: > > On Mon, May 6, 2013 at 5:45 AM, Michael Haggerty > > wrote: > >> On 05/06/2013 12:32 PM, Thomas Rast wrote: > >> So the proposed change would break a documented use of cvs2git. > > > > It's d

Re: [PATCH 4/4] fast-import: only store commit objects

On Mon, May 6, 2013 at 9:58 PM, Michael Haggerty wrote: > On 05/06/2013 11:19 PM, Felipe Contreras wrote: >> On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano wrote: >>> Michael Haggerty writes: >>> Yes, it can be handy to start loading the first "blobfile" in parallel with the later sta

Re: [PATCH 4/4] fast-import: only store commit objects

On Mon, May 6, 2013 at 11:32 PM, Johannes Schindelin wrote: > Hi Michael, > > On Tue, 7 May 2013, Michael Haggerty wrote: > >> I knew about the "type" command but I was under the impression that it >> is intended for text files and can corrupt binary files. Are you sure >> that using "type" as yo

Re: another packed-refs race

On 05/06/2013 08:41 PM, Jeff King wrote: > On Mon, May 06, 2013 at 02:03:40PM +0200, Michael Haggerty wrote: > [...] >> The loose refs cache is only used by the for_each_ref() functions, not >> for looking up individual references. Another approach would be to >> change the top-level for_each_ref(

Re: [PATCH 4/4] fast-import: only store commit objects

Hi Michael, On Tue, 7 May 2013, Michael Haggerty wrote: > I knew about the "type" command but I was under the impression that it > is intended for text files and can corrupt binary files. Are you sure > that using "type" as you suggest is binary-clean? "type" is not binary-clean. At least on so

Re: [PATCH v6 7/7] git-clean: update document for interactive git-clean

2013/5/7 Jiang Xin : > Signed-off-by: Jiang Xin > --- > Documentation/git-clean.txt | 70 > - > 1 file changed, 63 insertions(+), 7 deletions(-) > > diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt > index f5572..56d60 100644 > --

Re: [PATCH v6 4/7] git-clean: use a git-add-interactive compatible UI

2013/5/7 Jiang Xin : > Rewrite menu using a new method `list_and_choose`, which is borrowed > from `git-add--interactive.perl`. We can reused this method later for > more actions. > > Please NOTE: > > * Method `list_and_choose` return an array of integers, and > * it is up to you to free the allo

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

On Mon, May 6, 2013 at 8:59 PM, Junio C Hamano wrote: > Felipe Contreras writes: > How? >>> >>> * if we teach fast-import to optionally not write marks for blobs >>>and trees out, your remote-bzr can take advantage of it, >> >> I already said remote-bzr is irrelevant. *Everybody* benefi

Re: [PATCH 4/4] fast-import: only store commit objects

On 05/06/2013 11:04 PM, Felipe Contreras wrote: > On Mon, May 6, 2013 at 5:45 AM, Michael Haggerty wrote: >> On 05/06/2013 12:32 PM, Thomas Rast wrote: >>> Michael Haggerty writes: >>> On 05/03/2013 08:23 PM, Felipe Contreras wrote: > On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote:

Re: [PATCH 4/4] fast-import: only store commit objects

On 05/06/2013 11:36 PM, Felipe Contreras wrote: > This would simplify the documentation, and obliterate the need to use > mark files at all: As explained in my other email, this documentation change does not remove all of the reasons that users might want to use mark files. I would still like to

[PATCH 2/2] peel_ref: refactor for safety with simultaneous update

The peel_ref function lets a caller peel an object, taking advantage of the fact that we may have the peeled value cached for a packed ref. However, this function is not necessarily safe in the face of simultaneous ref updates. The caller has typically already loaded the ref from disk (e.g., as p

Re: [PATCH 4/4] fast-import: only store commit objects

On 05/06/2013 11:19 PM, Felipe Contreras wrote: > On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano wrote: >> Michael Haggerty writes: >> >>> Yes, it can be handy to start loading the first "blobfile" in parallel >>> with the later stages of the conversion, before the second "dumpfile" is >>> ready

[PATCH 1/2] peel_ref: rename "sha1" argument to "peeled"

The "sha1" argument of peel_ref is meant to hold the peeled object name for output. Let's call it "peeled" which makes it more clear that it is not an input sha1 (especially as we will be adding such an input sha1 in the next patch). Signed-off-by: Jeff King --- Simple cleanup for the next step.

[PATCH 0/2] peel_ref cleanups changes

On Mon, May 06, 2013 at 10:43:13PM -0400, Jeff King wrote: > I hooked the refreshing into get_packed_refs, since then all callers get > it for free. It makes me a little nervous, though, just in case some > caller really cares about calling get_packed_refs but not having the > list of packed-refs

[PATCH 4/4] for_each_ref: load all loose refs before packed refs

If we are iterating through the refs using for_each_ref (or any of its sister functions), we can get into a race condition with a simultaneous "pack-refs --prune" that looks like this: 0. We have a large number of loose refs, and a few packed refs. refs/heads/z/foo is loose, with no matchin

[PATCH 3/4] get_packed_refs: reload packed-refs file when it changes

Once we read the packed-refs file into memory, we cache it to save work on future ref lookups. However, our cache may be out of date with respect to what is on disk if another process is simultaneously packing the refs. Normally it is acceptable for us to be a little out of date, since there is no

[PATCH 2/4] add a stat_validity struct

It can sometimes be useful to know whether a path in the filesystem has been updated without going to the work of opening and re-reading its content. We trust the stat() information on disk already to handle index updates, and we can use the same trick here. This patch introduces a "stat_validity"

[PATCH 1/4] resolve_ref: close race condition for packed refs

When we attempt to resolve a ref, the first thing we do is call lstat() to see if it is a symlink or a real ref. If we find that the ref is missing, we fall back to looking it up in the packed-refs file. If we find the loose ref does exist (and is a regular file), we continue with trying to open it

[PATCH 0/4] fix packed-refs races

This fixes the races I brought up in the surrounding thread: http://thread.gmane.org/gmane.comp.version-control.git/223299 The individual races are describe in more detail in each commit, but for reference, here is the complete reproduction recipe (which I posted already in several parts throug

Re: [PATCH 0/7] Make "$remote/$branch" work with unconventional refspecs

Johan Herland writes: > Ok, so whereas I consider the refspec to be "king", and that the expansion > from convenient shorthands to full remote-tracking refnames should be > derived from the chosen refspec, you would (if I understand you correctly) > rather have a constant (i.e. independent of rem

git apply --interactive

I'd love for "git apply" to have an equivalent to "git add -p". (I'm guessing it would be called --interactive since "git apply -p" is taken and --patch would be confusing.) Has anyone thought about this? After taking a quick look at git-add--interactive.perl, it seems like the main steps would

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

Felipe Contreras writes: >>> How? >> >> * if we teach fast-import to optionally not write marks for blobs >>and trees out, your remote-bzr can take advantage of it, > > I already said remote-bzr is irrelevant. *Everybody* benefits. Everybody who does _not_ need to look at marks for non-comm

Re: [PATCH 6/7] refname_match(): Caller must declare if we're matching local or remote refs

Johan Herland writes: > refname_match() is used to check whether a given shorthand name matches a > given full refname, but that full refname does not always belong in the > local repo, rather it is sometimes taken from list of refs sent over from > a remote repo. That "local vs remote" is a wro

Re: [PATCH 5/7] refs.c: Refactor code for shortening full refnames into shorthand names

Johan Herland writes: > This patch removes the only remaining user of ref_rev_parse_rules. > It has now been fully replaced by ref_expand_rules. Hence this patch > also removes ref_rev_parse_rules. Yeah, I was wondering when you would do this while reading [4/7], as removing the parse_rules[] wo

Re: [PATCH 4/7] refs.c: Refactor rules for expanding shorthand names into full refnames

Johan Herland writes: > diff --git a/refs.c b/refs.c > index 7231f54..8b02140 100644 > --- a/refs.c > +++ b/refs.c > @@ -1724,7 +1724,24 @@ const char *prettify_refname(const char *name) > 0); > } > > -const char *ref_rev_parse_rules[] = { > +static void ref_expand_txtly(const st

Re: [PATCH 3/7] t7900: Demonstrate failure to expand "$remote/$branch" according to refspecs

Johan Herland writes: > This test verifies that the following expressions all evaluate to the > full refname "refs/remotes/origin/heads/master": As I've aleady said, I am not convinced that local refname resolution should pay attention to refspec mapping, so I won't look at this step. -- To unsu

Re: [PATCH 2/7] t7900: Start testing usability of namespaced remote refs

Johan Herland writes: > +test_expect_success 'work-around "clone" with namespaced remote refs' ' > + rm -rf client && > + git init client && > + ( > + cd client && > + git remote add origin ../server && > + git config --unset-all remote.origin.fetch

Re: [PATCH] revision.c: Fix a sparse warning

Kevin Bracey writes: > On 04/05/2013 20:25, Ramsay Jones wrote: >> Sparse issues an "'sole_interesting' not declared. Should it be static?" >> warning. In order to suppress the warning, since this symbol does not >> need more than file visibility, we simply add the static modifier to >> its decla

Re: [PATCH 0/7] Make "$remote/$branch" work with unconventional refspecs

On Mon, May 6, 2013 at 7:06 PM, Junio C Hamano wrote: > Johan Herland writes: >> Let me try to summarize my views on how refnames should work in Git, to >> see if we can identify where we differ on the principles (or if we, in >> fact, differ at all): > > Thanks; I think I already said where I th

Re: [PATCH v3] Enable minimal stat checking

On Tue, Jan 22, 2013 at 08:49:22AM +0100, Robin Rosenberg wrote: > Specifically the fields uid, gid, ctime, ino and dev are set to zero > by JGit. Other implementations, eg. Git in cygwin are allegedly also > somewhat incompatible with Git For Windows and on *nix platforms > the resolution of the

Re: another packed-refs race

On Mon, May 06, 2013 at 02:41:22PM -0400, Jeff King wrote: > That is a weaker guarantee, and I think we can provide it with: > > 1. Load all loose refs into cache for a particular enumeration. > > 2. Make sure the packed-refs cache is up-to-date (by checking its > stat() information and

Re: [PATCH 4/4] fast-import: only store commit objects

On Mon, May 6, 2013 at 4:19 PM, Felipe Contreras wrote: > On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano wrote: >> Michael Haggerty writes: >> >>> Yes, it can be handy to start loading the first "blobfile" in parallel >>> with the later stages of the conversion, before the second "dumpfile" is

[RFC] git: make signoff header configurable

When using -s for commit, revert, and format-patch (there may be more) command the comments message gets a generated and hard-coded signed-off-by message. For some projects a different header is used, eg. HostAP. Adding a config parameter named 'signoff.label'. Signed-off-by: Arend van Spriel ---

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

On Mon, May 6, 2013 at 3:58 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >>> The story is different on the fast-import side, where we do say we >>> dump the full table and a later run can depend on these marks. >> >> Yes, and gaining nothing but increased disk-space. > > I thought that

Re: [PATCH v3 10/9] revision.c: treat A...B merge bases as if manually specified

Kevin Bracey writes: > The documentation assures users that "A...B" is defined as 'r1 r2 --not > $(git merge-base --all r1 r2)'. This isn't in fact quite true, because > the calculated merge bases are not sent to add_rev_cmdline(). We want the commands to be able to tell which ones in revs->pend

Re: [PATCH 4/4] fast-import: only store commit objects

On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano wrote: > Michael Haggerty writes: > >> Yes, it can be handy to start loading the first "blobfile" in parallel >> with the later stages of the conversion, before the second "dumpfile" is >> ready. In that case the user needs to pass --export-marks t

Re: [PATCH 4/4] fast-import: only store commit objects

On Mon, May 6, 2013 at 7:20 AM, Johannes Schindelin wrote: > Hi Thomas, > > On Mon, 6 May 2013, Thomas Rast wrote: > >> The proposed patch wants to stop writing marks (in --export-marks) for >> anything but commits. > > Then it should not go in. If that rationale was valid, no change in behavior

Re: [PATCH 4/4] fast-import: only store commit objects

On Mon, May 6, 2013 at 5:45 AM, Michael Haggerty wrote: > On 05/06/2013 12:32 PM, Thomas Rast wrote: >> Michael Haggerty writes: >> >>> On 05/03/2013 08:23 PM, Felipe Contreras wrote: On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote: > Felipe Contreras writes: > How do we kn

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

Felipe Contreras writes: >> The story is different on the fast-import side, where we do say we >> dump the full table and a later run can depend on these marks. > > Yes, and gaining nothing but increased disk-space. I thought that the "gaining nothing" has already been refuted by the discussion

Re: [PATCH v3 5/9] revision.c: Make --full-history consider more merges

Kevin Bracey writes: > diff --git a/revision.c b/revision.c > index a67b615..c88ded8 100644 > --- a/revision.c > +++ b/revision.c > @@ -429,10 +429,100 @@ static int rev_same_tree_as_empty(struct rev_info > *revs, struct commit *commit) > return retval >= 0 && (tree_difference == REV_TREE_

Re: [PATCH v3 3/9] t6111: new TREESAME test set

Kevin Bracey writes: > +#,---E--. *H--. * marks !TREESAME parent paths > +# /\ / \* > +# *A--*B---D--*F-*G-K-*L-*M > +# \ /* \ / > +#`-C-' `-*I-*J > +# > +# A creates "file", B and F change it. > +# Odd

Re: git rev-list | git cherry-pick --stdin is leaky

On 04/30/13 15:47, René Scharfe wrote: > Am 30.04.2013 02:11, schrieb Stephen Boyd: >> (resending since the attachment seems to make vger sad) >> >> Hi, >> >> I'm running git rev-list | git cherry-pick --stdin on a range of about >> 300 commits. Eventually the chery-pick dies with: >> >> error

Re: [PATCH v3 3/9] t6111: new TREESAME test set

Kevin Bracey writes: > Some side branching and odd merging to illustrate various flaws in > revision list scans, particularly when limiting the list. > > Many expected failures, which will be gone by the end of the "history > traversal refinements" series. > > Signed-off-by: Kevin Bracey > --- >

Re: [PATCH] l10n: de.po: translate 44 new messages

Ralf Thielow writes: > #: branch.c:275 > -#, fuzzy, c-format > +#, c-format > msgid "Not a valid branch point: '%s'." > -msgstr "Ungültiger Zweig-Name: '%s'" > +msgstr "Ungültige Zweig-Version: '%s'" That's a bit strange and calls for a proper translation of "branch point". "Abzweigung" is re

[PATCH v6 7/7] git-clean: update document for interactive git-clean

Signed-off-by: Jiang Xin --- Documentation/git-clean.txt | 70 - 1 file changed, 63 insertions(+), 7 deletions(-) diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt index f5572..56d60 100644 --- a/Documentation/git-clean.txt +++ b/D

[PATCH v6 6/7] git-clean: rm -i style interactive cleaning

Add a "rm -i" style interactive cleaning method. User must confirm one by one before starting to delete. Signed-off-by: Jiang Xin --- builtin/clean.c | 36 1 file changed, 36 insertions(+) diff --git a/builtin/clean.c b/builtin/clean.c index 3b07f..f36ad 100

[PATCH v6 5/7] git-clean: interactive cleaning by select numbers

Draw a multiple choice menu using `list_and_choose` to select items to be deleted by numbers. User can input: * 1,5-7 : select 1,5,6,7 items to be deleted * * : select all items to be deleted * -*: unselect all, nothing will be deleted *: (empty) finish selecting, and retur

[PATCH v3 10/9] revision.c: treat A...B merge bases as if manually specified

The documentation assures users that "A...B" is defined as 'r1 r2 --not $(git merge-base --all r1 r2)'. This isn't in fact quite true, because the calculated merge bases are not sent to add_rev_cmdline(). Previously, the effect was pretty minor - all that I can think of is that "git rev-list --anc

[PATCH v6 4/7] git-clean: use a git-add-interactive compatible UI

Rewrite menu using a new method `list_and_choose`, which is borrowed from `git-add--interactive.perl`. We can reused this method later for more actions. Please NOTE: * Method `list_and_choose` return an array of integers, and * it is up to you to free the allocated memory of the array. * The a

[PATCH v6 2/7] Show items of interactive git-clean in columns

When there are lots of items to be cleaned, it is hard to see them all in one screen. Show them in columns instead of in one column will solve this problem. Since no longer show items to be cleaned using the "Would remove ..." format (only plain filenames) in interactive mode, we add instructions

[PATCH v6 3/7] Add colors to interactive git-clean

Show header, help, error messages, and prompt in colors for interactive git-clean. Re-use config variables for other git commands, such as git-add--interactive and git-stash: * color.interactive: When set to always, always use colors for interactive prompts and displays. When false (or never),

[PATCH v6 1/7] Add support for -i/--interactive to git-clean

Show what would be done and the user must confirm before actually cleaning. In the confirmation dialog, the user has three choices: * y/yes: Start to do cleaning. * n/no: Nothing will be deleted. * e/edit: Exclude items from deletion using ignore patterns. When the user chooses the edit mod

[PATCH v6 0/7] interactive git clean

Implement a 'git add --interactive' style of interactive git-clean. It will show what would be done before start to clean. See ``Interactive mode`` for details. Interactive mode When the command enters the interactive mode, it shows the files and directories to be cleaned, and go

Re: [PATCH 0/7] Make "$remote/$branch" work with unconventional refspecs

El 06/05/2013 19:11, "Junio C Hamano" va escriure: > > Santi Béjar writes: > > > The next question could be: why not make it work with $url too? As in: > > > > $ git merge git://git.kernel.org/pub/scm/git/git.git//master > > You need to remember "merge" is a local operation, working in your > loc

Re: Fwd: Uninit'ed submodules

Am 06.05.2013 02:19, schrieb Chris Packham: > This did get me thinking. Why does an uninitialized submodule need to > have an empty directory? If it didn't the maintainer in question > probably would have realized that he needed to run "git submodule > update --init" when his "cd submodule" command

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

On Mon, May 6, 2013 at 2:11 PM, Jeff King wrote: > On Mon, May 06, 2013 at 02:02:13PM -0500, Felipe Contreras wrote: > >> > I did a double-take on reading this subject line and first paragraph, >> > thinking "surely fast-export needs to actually output blobs?". >> >> If you think that, then you ar

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

On Mon, May 6, 2013 at 11:20 AM, Jeff King wrote: > On Mon, May 06, 2013 at 08:08:45AM -0700, Junio C Hamano wrote: > >> > I'm also not sure why your claim "we don't care about blobs" is true, >> > because naively we would want future runs of fast-export to avoid having >> > to write out the whole

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

On Mon, May 06, 2013 at 02:02:13PM -0500, Felipe Contreras wrote: > > I did a double-take on reading this subject line and first paragraph, > > thinking "surely fast-export needs to actually output blobs?". > > If you think that, then you are not familiar with the code. > > --export-marks=:: > [

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

On Mon, May 6, 2013 at 10:08 AM, Junio C Hamano wrote: > Jeff King writes: > >> On Sun, May 05, 2013 at 05:38:53PM -0500, Felipe Contreras wrote: >> >>> We don't care about blobs, or any object other than commits, but in >>> order to find the type of object, we are parsing the whole thing, which

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

On Mon, May 6, 2013 at 7:31 AM, Jeff King wrote: > On Sun, May 05, 2013 at 05:38:53PM -0500, Felipe Contreras wrote: > >> We don't care about blobs, or any object other than commits, but in >> order to find the type of object, we are parsing the whole thing, which >> is slow, specially in big repo

Re: another packed-refs race

On Mon, May 06, 2013 at 02:12:29PM +0200, Michael Haggerty wrote: > > I think that would be correct (modulo that step 1 cannot happen for > > enumeration). But we would like to avoid loading all loose refs if we > > can. Especially on a cold cache, it can be quite slow, and you may not > > even ca

Re: another packed-refs race

On Mon, May 06, 2013 at 02:03:40PM +0200, Michael Haggerty wrote: > > We could fix this by making sure our packed-refs file is up to date > > s/file/cache/ Yeah, I meant "our view of the packed-refs file", but I think "cache" says that more succinctly. I'll be sure to make it clear when I start

Bug: git-p4: Sometimes p4 generates Windows-style output on OS X

I've observed that the p4 command that git-p4 delegates to occasionally outputs Windows-style line endings even on the OS X platform. When this happens, git-p4 gets very confused and crashes out. I've attached a patch which seems to fix the issue in my case. Now this patch is a pretty bad hack

Re: [PATCH 1/7] shorten_unambiguous_ref(): Allow shortening refs/remotes/origin/HEAD to origin

Johan Herland writes: > ... there is AFAICS _no_ way for sscanf() - having > already done one or more format extractions - to indicate to its caller > that the input fails to match the trailing part of the format string. Yeah, we can detect when we did not have enough, but we cannot tell where i

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

On Mon, May 06, 2013 at 01:19:35PM -0400, Jeff King wrote: > > Here is what I tentatively queued. > > [...] > > Yeah, that is much for to understand (to me, at least). Ugh. That was supposed to be "much easier to understand". Perhaps I will learn to type one day. -Peff -- To unsubscribe from th

Re: [PATCH 0/7] Make "$remote/$branch" work with unconventional refspecs

Junio C Hamano writes: Just a few typofixes... > Johan Herland writes: > >> Let me try to summarize my views on how refnames should work in Git, to >> see if we can identify where we differ on the principles (or if we, in >> fact, differ at all): > > Thanks; I think I already said where I think

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

On Mon, May 06, 2013 at 10:17:41AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > So yes, I think this is an obviously correct optimization. Thanks for > > clarifying, and sorry to be so slow. > > No need to be sorry. It just shows that the log message could have > been more helpful. >

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

Jeff King writes: > So yes, I think this is an obviously correct optimization. Thanks for > clarifying, and sorry to be so slow. No need to be sorry. It just shows that the log message could have been more helpful. Here is what I tentatively queued. commit 83582e91d22c66413b291d4d6d45bbeafddc

Re: [PATCH 0/7] Make "$remote/$branch" work with unconventional refspecs

Santi Béjar writes: > The next question could be: why not make it work with $url too? As in: > > $ git merge git://git.kernel.org/pub/scm/git/git.git//master You need to remember "merge" is a local operation, working in your local repository. Like it or not, the UI of Git makes distinction betw

Re: [PATCH 0/7] Make "$remote/$branch" work with unconventional refspecs

Johan Herland writes: > Let me try to summarize my views on how refnames should work in Git, to > see if we can identify where we differ on the principles (or if we, in > fact, differ at all): Thanks; I think I already said where I think we differ in a separate message, but a short version is th

[PATCH] l10n: de.po: translate 44 new messages

Translate 44 new messages came from git.pot update in c6bc7d4 (l10n: git.pot: v1.8.3 round 2 (44 new, 12 removed)). Signed-off-by: Ralf Thielow --- po/de.po | 139 +++ 1 file changed, 77 insertions(+), 62 deletions(-) diff --git a/po/d

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

On Mon, May 06, 2013 at 09:32:41AM -0700, Junio C Hamano wrote: > > OK. If the argument is "we do not write them, so do not bother reading > > them back in", I think that is reasonable. > > The way I read builtin/fast-export.c::import_marks() is that it is > more like "we do not write them, and w

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

Jeff King writes: > On Mon, May 06, 2013 at 08:08:45AM -0700, Junio C Hamano wrote: > >> > I'm also not sure why your claim "we don't care about blobs" is true, >> > because naively we would want future runs of fast-export to avoid having >> > to write out the whole blob content when mentioning t

Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config

Matthieu Moy writes: >>> The included patch attempts to improve post-receive-email. It's a >> >> Please don't ;-) > > More precisely: you should have a look at git-multimail (in directory > contrib/, in branch for now pu/, or from > https://github.com/mhagger/git-multimail) before spending time o

Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config

Junio C Hamano writes: > But when you send a patch the next time around, please have the > above and the next three lines (i.e. "introductory text") _below_ > the three-dash line. Allright, noted. >> From 878a7af9088e2bcc3afc9b09b9023f1f188c844b Mon Sep 17 00:00:00 2001 >> From: Trond Hasle Amu

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

On Mon, May 06, 2013 at 08:08:45AM -0700, Junio C Hamano wrote: > > I'm also not sure why your claim "we don't care about blobs" is true, > > because naively we would want future runs of fast-export to avoid having > > to write out the whole blob content when mentioning the blob again. > > The ex

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

Junio C Hamano writes: > By discarding marks on blobs, we may be robbing some optimization > possibilities, and by discarding marks on tags, we may be robbing > some features, from users of fast-export; we might want to add an > option "--use-object-marks={blob,commit,tag}" or something to both >

Re: offtopic: ppg design decisions - encapsulation

On Mon, May 06, 2013 at 11:34:28AM -0400, Martin Langhoff wrote: > [ Unashamedly offtopic... asking here because I like git design and > coding style, and ppg is drawing plenty of inspiration from the old > git shell scripts. Please kindly flame me privately... ] > > ppg is a wrapper around git to

Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config

Junio C Hamano writes: > Trond Hasle Amundsen writes: > >> Hello, >> >> The included patch attempts to improve post-receive-email. It's a > > Please don't ;-) More precisely: you should have a look at git-multimail (in directory contrib/, in branch for now pu/, or from https://github.com/mhagge

Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config

Trond Hasle Amundsen writes: > Hello, > > The included patch attempts to improve post-receive-email. It's a Please don't ;-) Eh, actually, thanks for the patch. But when you send a patch the next time around, please have the above and the next three lines (i.e. "introductory text") _below_ the

offtopic: ppg design decisions - encapsulation

[ Unashamedly offtopic... asking here because I like git design and coding style, and ppg is drawing plenty of inspiration from the old git shell scripts. Please kindly flame me privately... ] ppg is a wrapper around git to maintain and distribute Puppet configs, adding a few niceties. Now, ppg w

Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config

Trond Hasle Amundsen writes: > The included patch attempts to improve post-receive-email. It's a > trivial change, but one that helps us Gitolite users. Comments are > welcome, and this is my first attempt at contributing to the Git > project. Please keep me on CC as I'm not on the list. Bah.. I

[PATCH] merge-tree: handle directory/empty conflict correctly

git-merge-tree causes a null pointer dereference when a directory entry exists in only one or two of the three trees being compared with no corresponding entry in the other tree(s). When this happens, we want to handle the entry as a directory and not attempt to mark it as a file merge. Do this b

Re: [PATCH] t/Makefile: don't define TEST_RESULTS_DIRECTORY recursively

John Keeping writes: > Commit 54bb901 (t/Makefile: fix result handling with > TEST_OUTPUT_DIRECTORY - 2013-04-26) incorrectly defined > TEST_RESULTS_DIRECTORY relative to itself, when it should be relative to > TEST_OUTPUT_DIRECTORY. Fix this. > > Signed-off-by: John Keeping > --- > t/Makefile

Re: [PATCH 4/4] fast-import: only store commit objects

Michael Haggerty writes: > Yes, it can be handy to start loading the first "blobfile" in parallel > with the later stages of the conversion, before the second "dumpfile" is > ready. In that case the user needs to pass --export-marks to the first > fast-import process to export marks on blobs so

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

Jeff King writes: > On Sun, May 05, 2013 at 05:38:53PM -0500, Felipe Contreras wrote: > >> We don't care about blobs, or any object other than commits, but in >> order to find the type of object, we are parsing the whole thing, which >> is slow, specially in big repositories with lots of big file

  1   2   >