Re: [PATCH v2 4/5] index-pack, unpack-objects: add --not-so-strict for connectivity check

On Thu, May 02, 2013 at 11:55:57PM -0700, Junio C Hamano wrote: > Let's illustrate. Imagine your project as a whole has this history: [snip] OK I agree my approach is flawed. But if all these are met, we can be sure the new refs are good, correct? - all refs point to an object in the pack - t

Information Towards Level of popularity for pandora jewerly

Earliest attention for Pandora, you may realise with regards to the wonder * pandora jewelry * ? Good, such as the glistening brightness with your girlfriend, Pandora earrings at the same time does well everyone and the great approximately everyone. Wouldn't

thomas sabo uk -- Name brand Revealed Perfectly By using Classy Rings

* thomas sabo charms * for a make really likes a advantage to be revealed perfectly by using excellent plus really sophisticated jewellery. This is certainly mainly real by using charms plus silver products and solutions. Products and solutions offe

Re: [PATCH v2 4/5] index-pack, unpack-objects: add --not-so-strict for connectivity check

On Fri, May 3, 2013 at 3:09 AM, Duy Nguyen wrote: > Subject: [PATCH] clone: open a shortcut for connectivity check > > In order to make sure the cloned repository is good, we run "rev-list > --objects --not --all $new_refs" on the repository. This is expensive > on large repositories. This patch a

Re: [PATCH v2 2/2] cygwin: Remove the CYGWIN_V15_WIN32API build variable

On Thu, May 2, 2013 at 3:29 PM, Ramsay Jones wrote: > Commit 380a4d92 ("Update cygwin.c for new mingw-64 win32 api headers", > 11-11-2012) solved an header include order problem on cygwin 1.7 when > using the new mingw-64 WIN32 API headers. The solution involved using > a new build variable (V15_M

Astounding Jewellery Manufactured from pandora jewellery uk

* pandora uk * building start out outside around Denmark together with the human being labeled Enevoldsen. Enevoldsen appeared to be your goldsmith plus your dog as well as girlfriend viewed as considering and even promotion rings manufactured from drops

another packed-refs race

I found another race related to the packed-refs code. Consider for a moment what happens when we are looking at refs and another process does a simultaneous "git pack-refs --all --prune", updating packed-refs and deleting the loose refs. If we are resolving a single ref, then we will either find i

Re: Another use of "@"?

Duy Nguyen writes: > On Fri, May 3, 2013 at 4:38 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >>> Duy Nguyen writes: >>> My setup is a bit peculiar where I do git development on three different machines. Say I updated branch long-branch-name on machine A. Then I contin

Re: another packed-refs race

On Fri, May 3, 2013 at 10:38 AM, Jeff King wrote: > I found another race related to the packed-refs code. Consider for a > moment what happens when we are looking at refs and another process does > a simultaneous "git pack-refs --all --prune", updating packed-refs and > deleting the loose refs. >

Re: trouble on windows network share

deg writes: > I'm having this same problem. > > Here's one more clue that may help: The problem is dependent on the exact > type of NAS drive. > I moved from a Buffalo LS-X2.0, which worked fine, to a WD "My Book Live" > (MBL), which has this problem. > > I don't know much more yet about why the

Re: [PATCH v5 0/3] interactive git clean

Usability observations below... On Thu, May 2, 2013 at 11:49 PM, Jiang Xin wrote: > The interactive git clean combines `git clean -n` and `git clean -f` > together to do safe cleaning, and has more features. > > First it displays what would be removed in columns (so that you can > see them all in

[PATCH v3 0/4] check_everything_connected replacement

v3 is more like check_everything_connected's special case for clone because check_everything_connected is not really replaced. GIT_SHALLOW_FILE in 2/4 is now replaced by --shallow-file to avoid unintended propagation to child processes. Nguyễn Thái Ngọc Duy (4): clone: let the user know when che

[PATCH v3 1/4] clone: let the user know when check_everything_connected is run

check_everything_connected could take a long time, especially in the clone case where the whole DAG is traversed. The user deserves to know what's going on. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/clone.c | 4 1 file changed, 4 insertions(+) diff --git a/builtin/clone.c b/builtin/c

[PATCH v3 2/4] fetch-pack: prepare updated shallow file before fetching the pack

index-pack --strict looks up and follows parent commits. If shallow information is not ready by the time index-pack is run, index-pack may be lead to non-existent objects. Make fetch-pack save shallow file to disk before invoking index-pack. git learns new global option --shallow-file to pass on t

[PATCH v3 3/4] index-pack: remove dead code (it should never happen)

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/index-pack.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 79dfe47..f52a04f 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -747,8 +747,7 @@ static void sha1_

[PATCH v3 4/4] clone: open a shortcut for connectivity check

In order to make sure the cloned repository is good, we run "rev-list --objects --not --all $new_refs" on the repository. This is expensive on large repositories. This patch attempts to mitigate the impact in this special case. In the "good" clone case, we only have one pack. If all of the followi

Re: [PATCH v3 2/4] fetch-pack: prepare updated shallow file before fetching the pack

On Fri, May 3, 2013 at 8:35 AM, Nguyễn Thái Ngọc Duy wrote: > index-pack --strict looks up and follows parent commits. If shallow > information is not ready by the time index-pack is run, index-pack may > be lead to non-existent objects. Make fetch-pack save shallow file to s/lead/led/ > disk be

Re: [PATCH v3 4/4] clone: open a shortcut for connectivity check

On Fri, May 3, 2013 at 8:35 AM, Nguyễn Thái Ngọc Duy wrote: > In order to make sure the cloned repository is good, we run "rev-list > --objects --not --all $new_refs" on the repository. This is expensive > on large repositories. This patch attempts to mitigate the impact in > this special case. >

Re: [PATCH v4 2/3] Show items of interactive git-clean in columns

Jiang Xin writes: > Rewrite the log as following: That's probably more than needed ;-). Thanks, > 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 >

Re: [PATCH v5 0/3] interactive git clean

Jiang Xin writes: > The interactive git clean combines `git clean -n` and `git clean -f` > together to do safe cleaning, and has more features. > > First it displays what would be removed in columns (so that you can > see them all in one screen). The user must confirm before actually > cleaning.

Re: [PATCH v3 4/4] clone: open a shortcut for connectivity check

Nguyễn Thái Ngọc Duy writes: > In order to make sure the cloned repository is good, we run "rev-list > --objects --not --all $new_refs" on the repository. This is expensive > on large repositories. This patch attempts to mitigate the impact in > this special case. > > In the "good" clone case, w

Re: another packed-refs race

On Fri, May 03, 2013 at 11:26:11AM +0200, Johan Herland wrote: > You don't really need to be sure that packed-refs is up-to-date. You > only need to make sure that don't rely on lazily loading loose refs > _after_ you have loaded packed-refs. True. As long as you load them both together, and alwa

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

Felipe Contreras writes: > There's no point in storing blob, they would increase the time of > loading the marks, and the vast majority of them will never be used > again. > > This also makes fast-export and fast-import marks compatible. [...] > - if (m->data.marked[k]) > +

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

On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote: > Felipe Contreras writes: > How do we know that this doesn't break any users of fast-import? Your > comment isn't very reassuring: > >> the vast majority of them will never be used again > > So what's with the minority? Actually I don't thin

Re: another packed-refs race

On Fri, May 03, 2013 at 01:28:53PM -0400, Jeff King wrote: > > The following solution might work in both the resolve-a-single-ref and > > enumerating-refs case: > > > > 0. Look for ref already cached in memory. If found, OK. > > > > 1. Look for loose ref. If found, OK. > > > > 2. If not found,

Re: submodules

Am 03.05.2013 15:45, schrieb shawn wilson: > So, I actually have another question I wasn't able to get to in this > example (which has color - sorry - less -F displays it decently) > > What is shown here is that trying to add submodules in this repo > doesn't add the .gitmodules file - I can do it

Re: Suggestion for improving the manual page for "git submodule"

Am 03.05.2013 03:23, schrieb Dale R. Worley: > Several people have made similar mistakes in beliving that "git > submodule init" can be used for adding submodules to a working > directory, whereas "git submodule add" is the command that should be > used. That *is* documented at the top of the manu

Re: another packed-refs race

On Fri, May 3, 2013 at 8:26 PM, Jeff King wrote: > On Fri, May 03, 2013 at 01:28:53PM -0400, Jeff King wrote: >> > The following solution might work in both the resolve-a-single-ref and >> > enumerating-refs case: >> > >> > 0. Look for ref already cached in memory. If found, OK. >> > >> > 1. Look

Re: another packed-refs race

On Fri, May 03, 2013 at 04:38:47AM -0400, Jeff King wrote: > For reference, here's a script that demonstrates the problem during > enumeration (sometimes for-each-ref fails to realize that > refs/heads/master exists at all): > > # run this in one terminal > git init repo && > cd repo && >

[PATCH] completion: zsh: don't override suffix on _detault

zsh is smart enough to add the right suffix while completing, there's no point in trying to do the same as bash. Signed-off-by: Felipe Contreras --- contrib/completion/git-completion.zsh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.zsh b/

Re: [PATCH 1/4] fast-{import,export}: use get_sha1_hex() directly

Felipe Contreras writes: > There's no point in calling get_sha1() if we know they are SHA-1s. If we know they _have to be_ 40-hex object names, calling get_sha1() is not just pointless but outright wrong and these calls have to be get_sha1_hex(). Looks like a good change to me. > > Signed-off-

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

Felipe Contreras writes: > 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 files. > > There's no need for that, we can query the object informati

Re: [PATCH 3/4] fast-export: don't parse all the commits

Felipe Contreras writes: > We don't need the parsed objects at this point, merely the information > that they have marks. > > Seems to be three times faster in my setup with lots of objects. > > Signed-off-by: Felipe Contreras > --- > builtin/fast-export.c | 2 +- > 1 file changed, 1 insertion(

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

Thomas Rast writes: > IIUC, you are unconditionally storing only marks to commit objects. > > Are you allowed to do that at this point? I notice that > git-fast-export(1) says > >--export-marks= >Dumps the internal marks table to when complete. Marks are >written one per lin

Re: Another use of "@"?

Junio C Hamano writes: > Duy Nguyen writes: > >> My setup is a bit peculiar where I do git development on three >> different machines. Say I updated branch long-branch-name on machine >> A. Then I continue my work on machine B. I would want to hard reset >> that long-branch-name on machine B bef

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

On Fri, May 3, 2013 at 5:08 PM, Junio C Hamano wrote: > Thomas Rast writes: > >> IIUC, you are unconditionally storing only marks to commit objects. >> >> Are you allowed to do that at this point? I notice that >> git-fast-export(1) says >> >>--export-marks= >>Dumps the internal mark

Pitfalls in auto-fast-forwarding heads that are not checked out?

I am building a small git wrapper around puppet, and one of the actions it performs is auto-fastforwarding of branches without checking them out. In simplified code... we ensure that we are on a head called master, and in some cases "ppg commit", will commit to master and... ## early on # san

[PATCH] git-svn: added an --include-path flag

The SVN::Fetcher module is now able to filter for inclusion as well as exclusion (as used by --ignore-path). Also added tests, documentation changes and git completion script. If you have an SVN repository with many top level directories and you only want a git-svn clone of some of them then using

[ANNOUNCE] Git v1.8.3-rc1

A release candidate Git v1.8.3-rc1 is now available for testing at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 68160a9e9246a4857ccab0e68b466e0e442c1da5 git-1.8.3.rc1.tar.gz eecfe00a46a4b26b1f1a4a83f66a

What's cooking in git.git (May 2013, #01; Fri, 3)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The tip of the 'master' branch is tagged as v1.8.3-rc1. We seem to have a few interesting topics that are being discussed but it is unlikely I'

[RESEND/PATCH] transport-helper: improve push messages

If there's already a remote-helper tracking ref, we can fetch the SHA-1 to report proper push messages (as opposed to always reporting [new branch]). The remote-helper currently can specify the old SHA-1 to avoid this problem, but there's no point in forcing all remote-helpers to be aware of git c

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

Felipe Contreras writes: >> A safe and sane approach may be to teach these an option to tell >> them to omit non-commits or to emit all kinds, and make remote-bzr >> use that to exclude non-commits. > > This has nothing to do with remote-bzr, or any remote helper. These > objects are not useful,

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

On Fri, May 3, 2013 at 6:45 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >>> A safe and sane approach may be to teach these an option to tell >>> them to omit non-commits or to emit all kinds, and make remote-bzr >>> use that to exclude non-commits. >> >> This has nothing to do with rem

[PATCH v2 0/2] Show suggested refs when ref unknown

If origin/foo exists, but foo doesn't: $ git merge foo fatal: foo - not something we can merge This patch series improves the error message. If a remote branch exists with the same name, it now says: $ git merge foo fatal: foo - not something we can merge Did you mean this?

[PATCH v2 1/2] help: add help_unknown_ref

When a ref is not known, currently functions call die() with an error message. Add helper function help_unknown_ref to take care of displaying an error message along with a list of suggested refs the user might have meant. Example: $ git merge foo merge: foo - not something we can

[PATCH v2 2/2] merge: use help_unknown_ref

Use help.c:help_unknown_ref instead of die to provide a friendlier error message before exiting, when one of the refs specified in a merge is unknown. Signed-off-by: Vikrant Varma --- builtin/merge.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/builtin/merge.c b/built

Re: [PATCH 3/4] fast-export: don't parse all the commits

On Fri, May 3, 2013 at 4:54 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> We don't need the parsed objects at this point, merely the information >> that they have marks. >> >> Seems to be three times faster in my setup with lots of objects. >> >> Signed-off-by: Felipe Contreras >> --

[PATCH 0/2] remote-bzr: couple of fixes

Hi, A few fixes to be applied on top of the massive changes already queued. Nothing major. Felipe Contreras (2): remote-bzr: convert all unicode keys to str remote-bzr: avoid bad refs contrib/remote-helpers/git-remote-bzr | 32 1 file changed, 20 insertions

[PATCH 1/2] remote-bzr: convert all unicode keys to str

Otherwise some versions of bazaar might barf. Signed-off-by: Felipe Contreras --- contrib/remote-helpers/git-remote-bzr | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr index 161f831..bbaaa8f 10

[PATCH 2/2] remote-bzr: avoid bad refs

Turns out fast-export throws bad 'reset' commands because of a behavior in transport-helper that is not even needed. We should ignore them, otherwise we will threat them as branches and fail. This was fixed in v1.8.2, but some people use this script in older versions of git. Also, check if the r

Re: [PATCH 0/2] remote-bzr: couple of fixes

On Fri, May 3, 2013 at 7:22 PM, Felipe Contreras wrote: > A few fixes to be applied on top of the massive changes already queued. > Nothing major. > > Felipe Contreras (2): > remote-bzr: convert all unicode keys to str > remote-bzr: avoid bad refs There's a problem with the second patch. Re-

[PATCH v2 0/2] remote-bzr: couple of fixes

Hi, The previous version had an indentation bug (did I mention I hate python?). A few fixes to be applied on top of the massive changes already queued. Nothing major. Felipe Contreras (2): remote-bzr: convert all unicode keys to str remote-bzr: avoid bad refs contrib/remote-helpers/git-rem

[PATCH v2 1/2] remote-bzr: convert all unicode keys to str

Otherwise some versions of bazaar might barf. Signed-off-by: Felipe Contreras --- contrib/remote-helpers/git-remote-bzr | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr index 161f831..bbaaa8f 10

[PATCH v2 2/2] remote-bzr: avoid bad refs

Turns out fast-export throws bad 'reset' commands because of a behavior in transport-helper that is not even needed. We should ignore them, otherwise we will threat them as branches and fail. This was fixed in v1.8.2, but some people use this script in older versions of git. Also, check if the r

Re: [PATCH v5 0/3] interactive git clean

2013/5/3 Eric Sunshine : >> WARNING: The following items will be removed permanently. Press "y" >> WARNING: to start cleaning, and press "n" to abort the cleaning. >> WARNING: You can also enter the "edit" mode, and select items >> WARNING: to be excluded from the cleaning. > > The

Re: [PATCH v3 4/4] clone: open a shortcut for connectivity check

On Fri, May 3, 2013 at 11:15 PM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> In order to make sure the cloned repository is good, we run "rev-list >> --objects --not --all $new_refs" on the repository. This is expensive >> on large repositories. This patch attempts to mitigate the

[PATCH v2] clone: allow cloning local paths with colons in them

Usually "foo:bar" is interpreted as an ssh url. This patch allows to clone from such paths by putting at least one slash before the colon (i.e. /path/to/foo:bar or just ./foo:bar). file://foo:bar should also work, but local optimizations are off in that case, which may be unwanted. While at there,

Re: [PATCH v2] remove the impression of unexpectedness when access is denied

Hi, Heiko Voigt wrote: > --- a/connect.c > +++ b/connect.c > @@ -49,6 +49,16 @@ static void add_extra_have(struct extra_have_objects > *extra, unsigned char *sha1 > extra->nr++; > } > > +static void die_initial_contact(int got_at_least_one_head) > +{ > + if (got_at_least_one_head) >

Re: Another use of "@"?

On Sat, May 4, 2013 at 5:09 AM, Matthieu Moy wrote: > The A/@ could make sense, but I'm wondering whether we're taking the > direction of implementing some kind of Brainfuck dialect in Git revision > specifiers. I'm not sure we want to add more special characters here and > there with subtly diffe

[PATCH] get_sha1: improve ambiguity warning regarding SHA-1 and ref names

When we get 40 hex digits, we immediately assume it's an SHA-1. Warn about ambiguity if there's also refs/heads/$sha1 (or similar) on system. When we successfully resolve a ref like "1234abc" and "1234abc" happens to be valid abbreviated SHA-1 on system, warn also. Signed-off-by: Nguyễn Thái Ngọc

Re: Another use of "@"?

On Sat, May 4, 2013 at 10:26 AM, Duy Nguyen wrote: > On Sat, May 4, 2013 at 5:09 AM, Matthieu Moy > wrote: >> The A/@ could make sense, but I'm wondering whether we're taking the >> direction of implementing some kind of Brainfuck dialect in Git revision >> specifiers. I'm not sure we want to add

How do I modify the commit message (not the topmost one) of a git commit?

Hi, I did a series of commits and now I find one of my commit (not the topmost one) has an incorrect commit message. How can I change that specific one? I believe "git commit --amend" works only for the last commit. Thanks, Norah Jones -- To unsubscribe from this list: send the line "unsubs