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

Junio C Hamano writes: > Duy Nguyen writes: > >> What do you mean by "partial history"? Do we have dangling pointers >> after doing that commit walker? > > "^C" will leave the objects and it is safe because it will not > update refs. > > But your code that does not verify the full connectivity f

Re: Another use of "@"?

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 continue my work on machine B. I wou

Re[3]: [PATCH 4/5] git-svn: fix bottleneck in stash_placeholder_list()

EW>> Ilya Basin wrote: >>> Hi. I won't send you updated patches until I import and test my huge >>> repo. Everything will be here: >>> https://github.com/basinilya/git/commits/v1.8.2.2-git-svn-fixes >>> >>> At the moment I've decided not to implement the Junio's proposal: >>> > >> JCH> comment li

Re: Another use of "@"?

On Thu, May 2, 2013 at 9:51 PM, Duy Nguyen wrote: > Hi, > > 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

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

links of london Meant for Way Partners

A good cutting edge on line store by using a main difference, you bet What i'm saying is any * links of london sale * . It's an individual retail outlet the fact that justifies way that will a a fact feel. Pc training courses merchandise or simply ea

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

Duy Nguyen writes: > What do you mean by "partial history"? Do we have dangling pointers > after doing that commit walker? "^C" will leave the objects and it is safe because it will not update refs. But your code that does not verify the full connectivity from such an object (that is outside th

Re: Another use of "@"?

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 before resuming my work. What I > u

Re: [PATCH] lookup_object: prioritize recently found objects

On Fri, May 03, 2013 at 02:02:44AM -0400, Jeff King wrote: > > Can we be sure that the function is never invoked in concurrently from > > different threads? I attempted to audit code paths, but quickly gave up > > because I know too little about this machinery. > > I didn't check explicitly, but

Re: [PATCH] lookup_object: prioritize recently found objects

On Fri, May 03, 2013 at 07:59:09AM +0200, Johannes Sixt wrote: > Am 5/2/2013 17:46, schrieb Jeff King: > > On Thu, May 02, 2013 at 09:05:01AM +0200, Johannes Sixt wrote: > >> BTW, do you notice that the function is now modifying an object (the hash > >> table) even though this is rather unexpected

Re: [PATCH] lookup_object: prioritize recently found objects

Am 5/2/2013 17:46, schrieb Jeff King: > On Thu, May 02, 2013 at 09:05:01AM +0200, Johannes Sixt wrote: >> BTW, do you notice that the function is now modifying an object (the hash >> table) even though this is rather unexpected from a "lookup" function? > > I think this is fine. The function is co

Re[2]: [PATCH 4/5] git-svn: fix bottleneck in stash_placeholder_list()

EW> Ilya Basin wrote: >> Hi. I won't send you updated patches until I import and test my huge >> repo. Everything will be here: >> https://github.com/basinilya/git/commits/v1.8.2.2-git-svn-fixes >> >> At the moment I've decided not to implement the Junio's proposal: >> > >> JCH> comment line "# a

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

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. Signed-off-by: Felipe Contreras --- fast-import.c | 9 +++-- 1 file changed, 7 insertion

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

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(+), 1 deletion(-) diff --git a/builtin/fas

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

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 information with sha1_object_info(); Before

[PATCH 0/4] fast-export: speed improvements

Hi, Parsing the marks of an import of the emacs repository moves fast-export to a crawl. It takes 14 minutes in my setup, after these patches, it takes 1 second. The important patches are #2 and #3, the rest are niceities. Felipe Contreras (4): fast-{import,export}: use get_sha1_hex() directly

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

There's no point in calling get_sha1() if we know they are SHA-1s. Signed-off-by: Felipe Contreras --- builtin/fast-export.c | 2 +- fast-import.c | 10 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/builtin/fast-export.c b/builtin/fast-export.c index d60d675.

[PATCH v5 2/3] 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 v5 3/3] 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 v5 1/3] 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: * Yes: Start to do cleaning. * No: Nothing will be deleted. * Edit (default for the first time): Enter the edit mode. When the user chooses the edit mode, the us

[PATCH v5 0/3] interactive git clean

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. WARNING: The following ite

Re: [PATCH v4 3/3] Add colors to interactive git-clean

2013/5/2 Matthieu Moy : > Jiang Xin writes: > >> Show help, error messages, and prompt in colors for interactive >> git-clean. > > I find the red WARNING a bit agressive. Also, the NOTE: is the same > color as the WARNING, hence visually similar. I first thought it was > repeating the same message

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

On Fri, May 3, 2013 at 2:27 AM, Junio C Hamano wrote: >> Object islands (in the new pack) by definition are not connected to >> the main DAG and so invisible to/unreachable from rev-list. index-pack >> examines all objects in the pack and checks links of each object. With >> this approach, islands

Suggestion for improving the manual page for "git submodule"

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 manual page for "git submodule", but my error was enhance

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

2013/5/2 Matthieu Moy : > Jiang Xin writes: > >> Signed-off-by: Jiang Xin > > This lacks a proper commit message (why is this a good thing?), and Rewrite the log as following: Show items of interactive git-clean in columns When there are lots of items to be cleaned, it is hard to see them all

Re: trouble on windows network share

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 MBL is failing, but am still

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

On Thu, May 02, 2013 at 08:23:53PM +0100, Ramsay Jones wrote: > > Hi Junio, > I'm not sure if this is a request that's valid or not. But for me it would be appriciated if you could send patch-series as a reply to the first e-mail in the patch-series. The way git send-email does. That is: If you

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

Ramsay Jones writes: > Version 2 changes: > >- minor edit to commit message to Patch #1 > (s.%s/NATIVE_WINDOWS/.%s/WINDOWS_NATIVE/.) ;-) > >- add some additional explanation to commit message > of Patch #2. Thanks. > Note: Since I don't have a commit ID for the first patch, >

Re: [PATCH 4/5] git-svn: fix bottleneck in stash_placeholder_list()

Ilya Basin wrote: > Hi. I won't send you updated patches until I import and test my huge > repo. Everything will be here: > https://github.com/basinilya/git/commits/v1.8.2.2-git-svn-fixes > > At the moment I've decided not to implement the Junio's proposal: > > >> JCH> comment line "# added by gi

Re: [PATCH 4/5] git-svn: fix bottleneck in stash_placeholder_list()

Ilya Basin wrote: > EW> My personal philosophy has always been: git svn users should leave > EW> no trace or indication they're using a non-standard SVN client. > > Placeholders aren't pushed back to svn. Right, I was confused, as I often am :x -- To unsubscribe from this list: send the line "un

Re: [PATCH v2 8/8] revision.c: discount UNINTERESTING parents

Kevin Bracey writes: > On 01/05/2013 00:18, Junio C Hamano wrote: > >>> These rules paying more attention to UNINTERESTING do add a tricky >>> wrinkle to behaviour. Because limited revision lists are conventionally >>> expressed as A..B (ie B ^A), the bottom commit is UNINTERESTING. >> OK. >> >>>

Re: [PATCH v2] sha1_name: reorganize get_sha1_basic()

On Thu, May 2, 2013 at 2:47 PM, Ramkumar Ramachandra wrote: > A small suggestion. Squash this in if you like; optionally submit it > as a separate part. > > diff --git a/sha1_name.c b/sha1_name.c > index 6428001..109ab41 100644 > --- a/sha1_name.c > +++ b/sha1_name.c > @@ -448,11 +448,12 @@ stati

Re: [PATCH v2] sha1_name: reorganize get_sha1_basic()

A small suggestion. Squash this in if you like; optionally submit it as a separate part. diff --git a/sha1_name.c b/sha1_name.c index 6428001..109ab41 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -448,11 +448,12 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)

Re: [PATCH] Documentation/git-commit: Typo under --edit

Anders Granskogen Bjørnstad writes: > -C takes a commit object, not a file. > > Signed-off-by: Anders Granskogen Bjørnstad > --- > Documentation/git-commit.txt |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/git-commit.txt b/Documentation/git-commi

[PATCH v2 1/2] mingw: rename WIN32 cpp macro to GIT_WINDOWS_NATIVE

From: Jonathan Nieder Throughout git, it is assumed that the WIN32 preprocessor symbol is defined on native Windows setups (mingw and msvc) and not on Cygwin. On Cygwin, most of the time git can pretend this is just another Unix machine, and Windows-specific magic is generally counterproductive.

[PATCH v2 0/2] Remove the CYGWIN_V15_WIN32API build variable

Hi Junio, Version 2 changes: - minor edit to commit message to Patch #1 (s.%s/NATIVE_WINDOWS/.%s/WINDOWS_NATIVE/.) ;-) - add some additional explanation to commit message of Patch #2. Note: Since I don't have a commit ID for the first patch, I didn't know how to refer to it in

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

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_MINGW_HEADERS) to conditionally compile the cygwin.c source f

[PATCH v2] path: Fix a sparse warning

On MinGW, sparse issues an "'get_st_mode_bits' not declared. Should it be static?" warning. The MinGW and MSVC builds do not see the declaration of this function, within git-compat-util.h, due to its placement within an preprocessor conditional. In order to suppress the warning, we simply move th

Re: [PATCH v2] sha1_name: reorganize get_sha1_basic()

Felipe Contreras wrote: >> Looking at this closely once again. >> You've already hit the beginning. What are you continuing? Take the >> example of a compound expression with @{- > > Yeah, we could break, but I would prefer the break to happen naturally > when in the for loop check. This is foll

Re: [PATCH v2] sha1_name: reorganize get_sha1_basic()

On Thu, May 2, 2013 at 1:55 PM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> [...] > > Okay, you used nth_prior in this one. > >> There is no need to call this function recursively with the branch of >> @{-N} substituted because dwim_{ref,log} already replaces it. > > I figured that th

Re: [PATCH v2 8/8] revision.c: discount UNINTERESTING parents

On 01/05/2013 00:18, Junio C Hamano wrote: These rules paying more attention to UNINTERESTING do add a tricky wrinkle to behaviour. Because limited revision lists are conventionally expressed as A..B (ie B ^A), the bottom commit is UNINTERESTING. OK. Thus its connection to the INTERESTING gra

Re: [PATCH 4/5] git-svn: fix bottleneck in stash_placeholder_list()

On Wed, May 1, 2013 at 10:49 PM, Eric Wong wrote: > Junio C Hamano wrote: > >> Eric Wong writes: > >> That however is not a property of the directory containing it (or >> the path to that .gitignore file) that is valid throughout the >> history of the project. It is a property of a specific tre

Re: [PATCH v2] sha1_name: reorganize get_sha1_basic()

Felipe Contreras wrote: > [...] Okay, you used nth_prior in this one. > There is no need to call this function recursively with the branch of > @{-N} substituted because dwim_{ref,log} already replaces it. I figured that the recursion is because dwim_{ref,log} didn't exist when this was written.

[PATCH v2.2 8/8] revision.c: discount side branches when computing TREESAME

Add a BOTTOM flag to commit objects, and use it to define priority for pruning. Priority commits are those that are !UNINTERESTING or BOTTOM, and this allows us to identify irrelevant side branches (UNINTERESTING && !BOTTOM). If a merge has priority parents, and it is TREESAME to them, then do not

[PATCH] Documentation/git-commit: Typo under --edit

-C takes a commit object, not a file. Signed-off-by: Anders Granskogen Bjørnstad --- Documentation/git-commit.txt |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 9b1be55..8172938 100644 --- a/Documentati

Re: git-svn: problem with svn cp trunk/subdir tags/subdir_1.0

IB> When creating a tag or branch from a subdir, a disjoint branch IB> is created. Then git-svn re-imports the commits using this dir as IB> strip path. IB> Why? I would instead keep the current commit as parent, delete IB> everything except the subdir and move its contents to root directory. Eve

Re: [PATCH v2] sha1_name: reorganize get_sha1_basic()

On Thu, May 2, 2013 at 12:48 PM, Felipe Contreras wrote: > Through the years the functionality to handle @{-N} and @{u} has moved > around the code, and as a result, code that once made sense, doesn't any > more. > > There is no need to call this function recursively with the branch of > @{-N} sub

[PATCH v2.1 8/8] revision.c: discount side branches when computing TREESAME

Add a BOTTOM flag to commit objects, and use it to define priority for pruning. Priority commits are those that are !UNINTERESTING or BOTTOM, and this allows us to identify irrelevant side branches (UNINTERESTING && !BOTTOM). If a merge has priority parents, and it is TREESAME to them, then do not

Re: [PATCH] sha1_name: reorganize get_sha1_basic()

On Thu, May 2, 2013 at 5:19 AM, Duy Nguyen wrote: > On Thu, May 2, 2013 at 7:49 AM, Felipe Contreras > wrote: >> Through the years the functionality to handle @{-N} and @{u} has moved >> around the code, and as a result, code that once made sense, doesn't any >> more. >> >> There is no need to ca

[PATCH v2] sha1_name: reorganize get_sha1_basic()

Through the years the functionality to handle @{-N} and @{u} has moved around the code, and as a result, code that once made sense, doesn't any more. There is no need to call this function recursively with the branch of @{-N} substituted because dwim_{ref,log} already replaces it. However, there'

Re: [PATCH 5/9] t1508 (at-combinations): document @{N} versus HEAD@{N}

Felipe Contreras wrote: >> +# Document differences between @{N} and HEAD@{N}. > > That's enough explanation, except that we not documenting them, we are > testing them. The difference is subtle, and I couldn't find this documented clearly anywhere else. If someone comes asking what the difference

Re: [PATCH v2 0/9] A natural solution to the @ -> HEAD problem

Felipe Contreras wrote: > I'm generally OK with them, but the one for 'symbolic refs' is relying > on a symbolic ref named '@', so it would immediately conflict with my > patch series. Right. I'll re-roll when we've finished with the rest. -- To unsubscribe from this list: send the line "unsubscr

Re: [PATCH 5/9] t1508 (at-combinations): document @{N} versus HEAD@{N}

On Thu, May 2, 2013 at 12:30 PM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >>> +test_expect_success 'switch to old-branch' ' >>> + git checkout old-branch >>> +' >>> + >>> +check HEAD refs/heads/old-branch >>> +check "HEAD@{1}" commit new-two >>> +check "@{1}" commit old-one >> >

Re[2]: [PATCH 4/5] git-svn: fix bottleneck in stash_placeholder_list()

Hi. I won't send you updated patches until I import and test my huge repo. Everything will be here: https://github.com/basinilya/git/commits/v1.8.2.2-git-svn-fixes At the moment I've decided not to implement the Junio's proposal: > >> JCH> comment line "# added by git-svn only to keep the director

Re: [PATCH 2/9] t1508 (at-combinations): test branches separately

On Thu, May 2, 2013 at 12:28 PM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> I'm not sure about this. If we introduce a check that fails, we would >> have to do: >> >> check HEAD refs/heads/new-branch "" failure >> >> Which doesn't seem clean. Perhaps it makes more sense to always add

Re: [PATCH 5/9] t1508 (at-combinations): document @{N} versus HEAD@{N}

Felipe Contreras wrote: >> +test_expect_success 'switch to old-branch' ' >> + git checkout old-branch >> +' >> + >> +check HEAD refs/heads/old-branch >> +check "HEAD@{1}" commit new-two >> +check "@{1}" commit old-one > > And here we are testing something completely different. How? I'm show

Re: [PATCH 2/9] t1508 (at-combinations): test branches separately

Felipe Contreras wrote: > I'm not sure about this. If we introduce a check that fails, we would > have to do: > > check HEAD refs/heads/new-branch "" failure > > Which doesn't seem clean. Perhaps it makes more sense to always add > the type of check: > > check HEAD ref refs/heads/new-branch I thin

Re: [PATCH 5/9] t1508 (at-combinations): document @{N} versus HEAD@{N}

On Thu, May 2, 2013 at 8:39 AM, Ramkumar Ramachandra wrote: > All the tests so far check that @{N} is the same as HEAD@{N} (for > positive N). However, this is not always the case: write a couple of > tests for this. > > Signed-off-by: Ramkumar Ramachandra > --- > t/t1508-at-combinations.sh | 1

Re: [PATCH v2 0/9] A natural solution to the @ -> HEAD problem

On Thu, May 2, 2013 at 12:18 PM, Ramkumar Ramachandra wrote: > Ramkumar Ramachandra wrote: >> Felipe Contreras (3): >> t1508 (at-combinations): simplify setup >> t1508 (at-combinations): test branches separately >> t1508 (at-combinations): improve nonsense() >> >> Ramkumar Ramachandra (6): >

Re: [PATCH 2/9] t1508 (at-combinations): test branches separately

On Thu, May 2, 2013 at 8:39 AM, Ramkumar Ramachandra wrote: > From: Felipe Contreras > > In the tests involving @{-1} and @{u} as the final component, what we > really want to check is if it's pointing to the right ref. We > currently check the tip commit of the ref, but we can clarify this by >

Re: [PATCH v2 0/9] A natural solution to the @ -> HEAD problem

Ramkumar Ramachandra wrote: > Felipe Contreras (3): > t1508 (at-combinations): simplify setup > t1508 (at-combinations): test branches separately > t1508 (at-combinations): improve nonsense() > > Ramkumar Ramachandra (6): > t1508 (at-combinations): increase coverage > t1508 (at-combinatio

Re: [PATCH 1/5] t1508 (at-combinations): more tests; document failures

Felipe Contreras wrote: > We probably should fix those, but that is orthogonal to the '@' shortcut. > > We can have the '@' shortcut *today*, with minimal changes to the code > and the documentation, in a limited and understood scope, with no > surprises. > > We can fix the symbolic ref stuff slowl

Re: [PATCH 1/5] t1508 (at-combinations): more tests; document failures

On Thu, May 2, 2013 at 12:02 PM, Ramkumar Ramachandra wrote: > Ramkumar Ramachandra wrote: >> HEAD has been special right from the start, and we cannot elevate >> anything else to its status now. > > As to why I agree with you: I audited the callers of branch_get() and > found out there are some t

Re: [PATCH v2] upload-pack: ignore 'shallow' lines with unknown obj-ids

Junio C Hamano writes: > Michael Heemskerk writes: > >> When the client sends a 'shallow' line for an object that the server does >> not have, the server currently dies with the error: "did not find object >> ... >> Documentation/technical/pack-protocol.txt | 3 +-- >> t/t5500-fetch-pack.sh

Re: [PATCH 1/5] t1508 (at-combinations): more tests; document failures

Ramkumar Ramachandra wrote: > HEAD has been special right from the start, and we cannot elevate > anything else to its status now. As to why I agree with you: I audited the callers of branch_get() and found out there are some things that cannot be fixed just by fixing branch_get(): For instance,

Re: [PATCH 1/5] t1508 (at-combinations): more tests; document failures

On Thu, May 2, 2013 at 11:56 AM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> Your approach can NOT be documented. > > Ah, I missed that. The explanation I was looking for is: > > HEAD has been special right from the start, and we cannot elevate > anything else to its status now. We

Re: [PATCH 7/9] remote.c: teach branch_get() to treat symrefs other than HEAD

On Thu, May 2, 2013 at 8:39 AM, Ramkumar Ramachandra wrote: > $ git symbolic-ref M refs/heads/master > $ git show M@{u} > $ git branch -u ram/master M > > This patch fixes branch_get() directly, making these work. It's not a fix, it's implementing brand new functionality, and changin

Re: [PATCH 1/5] t1508 (at-combinations): more tests; document failures

Felipe Contreras wrote: > Your approach can NOT be documented. Ah, I missed that. The explanation I was looking for is: HEAD has been special right from the start, and we cannot elevate anything else to its status now. Thanks. And sorry it took me so long. -- To unsubscribe from this list: sen

Re: [PATCH v2] upload-pack: ignore 'shallow' lines with unknown obj-ids

Michael Heemskerk writes: > When the client sends a 'shallow' line for an object that the server does > not have, the server currently dies with the error: "did not find object > ... > Documentation/technical/pack-protocol.txt | 3 +-- > t/t5500-fetch-pack.sh | 13 ++

Re: [PATCH v2 5/6] Add new @ shortcut for HEAD

Duy Nguyen writes: > On Wed, May 1, 2013 at 4:49 AM, Felipe Contreras > wrote: >> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can >> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we >> can't remove '{0}'? >> >> This patch allows '@' to be the same

Re: [PATCH 1/5] t1508 (at-combinations): more tests; document failures

On Thu, May 2, 2013 at 6:03 AM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> But HEAD is special, @ is not. HEAD is documented, @ is not. > > Your point being? That we should document @? Yes, I agree. Where? >> Where is it documented that @ points to HEAD? Where is it documented >>

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

Duy Nguyen writes: > On Thu, May 2, 2013 at 6:35 AM, Junio C Hamano wrote: >> Nguyễn Thái Ngọc Duy writes: >> >>> --not-so-strict only checks if all links from objects in the pack >>> point to real objects (either in current repo, or from the pack >>> itself). It's like check_everything_connec

Re: [PATCH] lookup_object: prioritize recently found objects

On Thu, May 02, 2013 at 08:46:08AM -0700, Junio C Hamano wrote: > Johannes Sixt writes: > > > BTW, do you notice that the function is now modifying an object (the hash > > table) even though this is rather unexpected from a "lookup" function? > > At the philosophical level, "lookup" ought to be

Re: [PATCH] lookup_object: prioritize recently found objects

On Thu, May 02, 2013 at 09:05:01AM +0200, Johannes Sixt wrote: > > I figured the lengthy description in the commit message would be > > sufficient, > > It's absolutely sufficient *if* one reads the commit message. In this > case, though it goes more like "this function should be trivial, and it i

Re: [PATCH] lookup_object: prioritize recently found objects

Johannes Sixt writes: > BTW, do you notice that the function is now modifying an object (the hash > table) even though this is rather unexpected from a "lookup" function? At the philosophical level, "lookup" ought to be operating on a "const" table. But at the implementation level, the table do

Re: [PATCH 7/9] remote.c: teach branch_get() to treat symrefs other than HEAD

Ramkumar Ramachandra wrote: > So sorry about this, but this breaks some tests in t1507 > (rev-parse-upstream). I'm looking into this now. > > In the meantime, reviewers can focus on the commit message. So, it turns out that some callers expect it to read_config(). If we're still adamant about no

Re: [PATCH] lookup_object: prioritize recently found objects

Jeff King writes: > I figured the lengthy description in the commit message would be > sufficient, but I don't mind adding something like your suggestion to > point readers of the code in the right direction when they see it. Yeah, I'll squash J6t's comment in and requeue. If somebody is learni

Re: [PATCH v4 3/3] Add colors to interactive git-clean

Jiang Xin writes: > Show help, error messages, and prompt in colors for interactive > git-clean. I find the red WARNING a bit agressive. Also, the NOTE: is the same color as the WARNING, hence visually similar. I first thought it was repeating the same message. I think it would make more sense t

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

Jiang Xin writes: > Signed-off-by: Jiang Xin This lacks a proper commit message (why is this a good thing?), and documentation (you introduce column.clean) but the code sounds good (that's a very quick look from me, not a "review" sorry). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To

[PATCH v2] upload-pack: ignore 'shallow' lines with unknown obj-ids

When the client sends a 'shallow' line for an object that the server does not have, the server currently dies with the error: "did not find object for shallow ". The client may have truncated the history at the commit by fetching shallowly from a different server, or the commit may have been garba

Re: [PATCH 7/9] remote.c: teach branch_get() to treat symrefs other than HEAD

Ramkumar Ramachandra wrote: > [...] So sorry about this, but this breaks some tests in t1507 (rev-parse-upstream). I'm looking into this now. In the meantime, reviewers can focus on the commit message. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

Re: [PATCH 4/9] t1508 (at-combinations): increase coverage

On Thu, May 2, 2013 at 9:39 AM, Ramkumar Ramachandra wrote: > Add more tests exercising documented functionality. > > It is worth nothing that HEAD@{-} is senseless because @{-} s/nothing/noting/ > cannot be used with anything other than HEAD anyway. > > [fc: contribute a couple of tests] > > Si

Re: [PATCH v3] Add support for -i/--interactive to git-clean

2013/5/1 Matthieu Moy : > Jiang Xin writes: > >> Show what would be done and the user must confirm before actually >> cleaning. In the confirmation dialog, the user has three choices: >> >> * Yes: Start to do cleaning. >> * No: Nothing will be deleted. >> * Edit (default): Enter edit mode. > >

[PATCH 8/9] sha1_name.c: fix @-parsing bug in interpret_branch_name()

Symbolic refs work in the general case, but making @ a symbolic-ref doesn't work due to a parsing bug in interpret_branch_name(). Update the function to parse "@{", not '@' (since '@' is a valid symbolic ref). This makes a failing test in t1508 (at-combinations) pass. In other words, you can now

[PATCH 4/9] t1508 (at-combinations): increase coverage

Add more tests exercising documented functionality. It is worth nothing that HEAD@{-} is senseless because @{-} cannot be used with anything other than HEAD anyway. [fc: contribute a couple of tests] Signed-off-by: Ramkumar Ramachandra --- t/t1508-at-combinations.sh | 8 1 file change

[PATCH 9/9] refs.c: make @ a pseudo-ref alias to HEAD

First, make sure that check_refname_format() rejects the a refname beginning with a '@'. Add a test to t1400 (update-ref) demonstrating that update-ref forbids the user from updating a ref named "@". Now, resolve_ref_unsafe() is built to resolve any refs that have a corresponding file inside $GIT

[PATCH 7/9] remote.c: teach branch_get() to treat symrefs other than HEAD

Broadly, there are two ways to resolve a command-line argument. The first approach is to treat it as a revision and resolve it using the revision-parsing mechanism get_sha1(). The other approach is to treat it as a ref, and use a reduced mechanism like branch_get(). Compare and contrast the impl

[PATCH 6/9] t1508 (at-combinations): test with symbolic refs

Symbolic refs don't work with @{u}. Document this failure. Also create a symbolic-ref @ (which is a valid ref name), and test everything with it to make sure that there is no bug in the @-parser. Signed-off-by: Ramkumar Ramachandra --- t/t1508-at-combinations.sh | 13 + 1 file chan

[PATCH 5/9] t1508 (at-combinations): document @{N} versus HEAD@{N}

All the tests so far check that @{N} is the same as HEAD@{N} (for positive N). However, this is not always the case: write a couple of tests for this. Signed-off-by: Ramkumar Ramachandra --- t/t1508-at-combinations.sh | 14 ++ 1 file changed, 14 insertions(+) diff --git a/t/t1508-a

[PATCH 3/9] t1508 (at-combinations): improve nonsense()

From: Felipe Contreras nonsense() is checking at the wrong abstraction layer: it doesn't need to invoke a 'git log' at all; it is sufficient to check that 'git rev-parse' can't resolve the argument. [rr: commit message, minor modification] Signed-off-by: Ramkumar Ramachandra --- t/t1508-at-co

[PATCH 1/9] t1508 (at-combinations): simplify setup

From: Felipe Contreras Instead of setting the configuration variables branch..merge and branch..remote by hand, use the shortcut 'git branch -u', which is exactly equivalent. It's much more readable now. [rr: commit message] Signed-off-by: Ramkumar Ramachandra --- t/t1508-at-combinations.sh

[PATCH 2/9] t1508 (at-combinations): test branches separately

From: Felipe Contreras In the tests involving @{-1} and @{u} as the final component, what we really want to check is if it's pointing to the right ref. We currently check the tip commit of the ref, but we can clarify this by separating out checking for commits versus checking for refs at check()

[PATCH v2 0/9] A natural solution to the @ -> HEAD problem

Hi, So, we're back with v2 of the series. Six patches add comprehensive tests to at-combinations, guarding against any future bugs. [7/9] is the most important part, where I've fixed branch_get() with a long justification. [8/9] and [9/9] are almost trivial. As Felipe pointed out, [9/9] might

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

Signed-off-by: Jiang Xin --- builtin/clean.c | 63 + 1 file changed, 46 insertions(+), 17 deletions(-) diff --git a/builtin/clean.c b/builtin/clean.c index 407744e5..ac48e 100644 --- a/builtin/clean.c +++ b/builtin/clean.c @@ -13,9 +13,11 @

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

Show help, error messages, and prompt in colors for interactive git-clean. Re-use config variables from git-add--interactive: * color.interactive: When set to always, always use colors for interactive prompts and displays. When false (or never), never. When set to true or auto, use colors o

[PATCH v4 1/3] 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: * Yes: Start to do cleaning. * No: Nothing will be deleted. * Edit (default for the first time): Enter edit mode. When the user chooses the edit mode, the user c

Re: [PATCH 1/5] t1508 (at-combinations): more tests; document failures

Ramkumar Ramachandra wrote: > [...] Disclaimer: I'm not saying that my implementation is Correct and Final. I will be more thorough in my re-roll about justifying my changes. What I am saying is that we should fix symbolic refs, and that @ should be implemented at the ref-level to maximize usefu

Re: [PATCH 1/5] t1508 (at-combinations): more tests; document failures

Felipe Contreras wrote: > But HEAD is special, @ is not. HEAD is documented, @ is not. Your point being? That we should document @? Yes, I agree. > Where is it documented that @ points to HEAD? Where is it documented > that 'branch -u foo @' would replace @ with HEAD? > Documentation/revisions.

Re: removing a bad commit

On Thu, May 2, 2013 at 12:15 PM, shawn wilson wrote: > I've got a commit that was done about a week ago that I want to remove > (preferably remove and rewrite history as it's in a branch and it > doesn't need to be in this branch until the branch is working) but if > a reverse patch is the only wa

Re: [PATCH] sha1_name: reorganize get_sha1_basic()

On Thu, May 2, 2013 at 7:49 AM, Felipe Contreras wrote: > Through the years the functionality to handle @{-N} and @{u} has moved > around the code, and as a result, code that once made sense, doesn't any > more. > > There is no need to call this function recursively with the branch of > @{-N} subs

  1   2   >